Introduction 介绍

EDIT 7/16/23: Chromium added protections against this technique. Additional details can be found here: https://slyd0g.medium.com/debugging-cookie-dumping-failures-with-chromiums-remote-debugger-8a4c4d19429f
编辑 7/16/23：Chromium 添加了针对此技术的保护。其他详细信息可以在这里找到： https://slyd0g.medium.com/debugging-cookie-dumping-failures-with-chromiums-remote-debugger-8a4c4d19429f

This blogpost will describe the concept of cookie theft against Chromium browsers and how this technique can be utilized to access web applications without credentials. This technique is mapped to MITRE ATT&CK under Steal Web Session Cookie (T1539).
这篇博文将描述针对 Chromium 浏览器的 cookie 盗窃的概念，以及如何利用该技术在没有凭据的情况下访问 Web 应用程序。该技术映射到Steal Web Session Cookie (T1539)下的 MITRE ATT&CK。

On a recent engagement, my team was ceded access on a macOS box as a low-privileged user and needed access to Google Chrome cookies. Cookies are an extremely useful form of credential when up against an environment with services behind some form of single sign-on. By stealing cookies, an attacker can authenticate to web applications, without plaintext credentials, and bypass defensive controls such as multi-factor authentication (MFA).
在最近的一次合作中，我的团队作为低权限用户被授予了 macOS 盒子的访问权限，并且需要访问 Google Chrome cookie。当面对具有某种形式的单点登录服务的环境时，Cookie 是一种非常有用的凭证形式。通过窃取 cookie，攻击者无需明文凭据即可对 Web 应用程序进行身份验证，并绕过多因素身份验证 (MFA) 等防御控制。

Conveniently enough, a thread within the #mythic channel of the BloodHoundGang Slack discussed this exact topic:
很方便的是， BloodHoundGang Slack的#mythic 频道中的一个帖子讨论了这个确切的主题：

Within the thread, there was a fantastic blogpost from 2018 by @mangopdf that mentioned a method of stealing cookies using Chrome’s remote debug port. My coworker, @hotnops, was quickly able to write a Python script to gather the cookies from Chrome using the technique documented in the blogpost to achieve our objective.
在该线程中， @mangopdf在 2018 年发表了一篇精彩的博文，其中提到了一种使用 Chrome 远程调试端口窃取 cookie 的方法。我的同事@hotnops很快就能编写一个 Python 脚本，使用博文中记录的技术从 Chrome 收集 cookie，以实现我们的目标。

After the engagement, I wanted to implement the technique myself in Golang for two reasons:
合作后，我想自己在 Golang 中实现该技术，原因有两个：

• Learn more about how the technique works under the hood
  详细了解该技术的幕后工作原理
• Teach myself Golang by diving into a project
  通过深入项目自学 Golang

The tool can be found on my GitHub here: https://github.com/slyd0g/WhiteChocolateMacademiaNut
该工具可以在我的 GitHub 上找到： https://github.com/slyd0g/WhiteChocolateMacademiaNut

Before diving into the tool’s implementation, let’s understand what is happening under the hood.
在深入了解该工具的实现之前，让我们先了解一下幕后发生的事情。

Note: All credits go to @mangopdf for the original discovery of this technique, this work wouldn’t have been possible without it.
注意：所有的功劳都归功于@mangopdf，因为这项技术的最初发现，没有它，这项工作就不可能完成。

HTTP Cookies HTTP Cookie

At a high level, cookies are a small piece of data that keeps track of a user’s current “state” with a website.
从较高层面来说，cookie 是一小段数据，用于跟踪用户当前的网站“状态”。

Cookies are key-value pairs that have a name (life) and value (42) field. Each cookie is applicable to a specific domain (https://google.com) and a path (/). I’ve shown below how Chrome DevTools has defined the Cookie object:
Cookie 是具有name (life) 和value (42) 字段的键值对。每个 cookie 都适用于特定domain (https://google.com) 和path (/)。下面我展示了 Chrome DevTools 如何定义 Cookie 对象：

As attackers, we are particularly interested in cookies that are given to users after they have successfully authenticated to a website. These “authentication” cookies are how the website knows the user has already logged in so they don’t have to type their username/password again on their next visit.
作为攻击者，我们对用户成功通过网站身份验证后提供给用户的 cookie 特别感兴趣。这些“身份验证”cookie 是网站了解用户已经登录的方式，这样他们就不必在下次访问时再次输入用户名/密码。

How Google Chrome Protects Cookies
Google Chrome 如何保护 Cookie

Google Chrome encrypts cookies differently depending on the operating system (OS).
Google Chrome 根据操作系统 (OS) 的不同对 cookie 进行不同的加密。

• On macOS, Google Chrome’s encryption key is stored within the Keychain which can be unlocked with the user’s plaintext password
  在 macOS 上，Google Chrome 的加密密钥存储在钥匙串中，可以使用用户的明文密码解锁
• On Windows, Google Chrome version 80+ encrypts cookies with an AES-256 key that is encrypted with DPAPI
  在 Windows 上，Google Chrome 版本 80+ 使用 DPAPI 加密的 AES-256 密钥对 cookie 进行加密

By starting Chrome with a remote debug port, we are able to bypass this encryption and utilize Chrome to decrypt the cookies for us.
通过使用远程调试端口启动 Chrome，我们能够绕过此加密并利用 Chrome 为我们解密 cookie。

Chromium Remote Debugging
Chromium 远程调试

Note: This attack applies to all Chromium based browsers including Google Chrome and the new Microsoft Edge
注意：此攻击适用于所有基于 Chromium 的浏览器，包括 Google Chrome 和新的 Microsoft Edge

--remote-debugging-port=9222

Chromium provides the ability to specify a remote debugging port from the command line, which allows us to debug and interact with the browser.
Chromium 提供了从命令行指定远程调试端口的功能，这使得我们能够调试并与浏览器交互。

--headless

Additionally, Chromium allows us to run it in headless mode. This means it can be run without a window displayed to the user (!). This is great for attackers since they can start Chromium with a debug port completely transparent to the user.
此外，Chromium 允许我们以无头模式运行它。这意味着它可以在不向用户显示窗口的情况下运行（！）。这对于攻击者来说非常有用，因为他们可以使用对用户完全透明的调试端口来启动 Chromium。

--user-data-dir=/path/to/data_dir

This flag allows us to specify the user’s data directory, where Chromium stores all of its application data such as cookies and history.
该标志允许我们指定用户的数据目录，Chromium 在其中存储所有应用程序数据，例如 cookie 和历史记录。

If you start Chromium without specifying this flag, you’ll notice that none of your bookmarks, favorites, or history will be loaded into the browser. It will appears to be a fresh install of Chromium.
如果您在未指定此标志的情况下启动 Chromium，您会注意到您的任何书签、收藏夹或历史记录都不会加载到浏览器中。它看起来像是全新安装的 Chromium。

For a full list of command line switches refer to https://peter.sh/experiments/chromium-command-line-switches/.
有关命令行开关的完整列表，请参阅https://peter.sh/experiments/chromium-command-line-switches/ 。

A particularly “interesting” one was:
一个特别“有趣”的是：

The /json Endpoint /json 端点

Armed with the ability to start a headless instance of Chromium, with the user’s profile loaded, and the remote debug port enabled, what can an attacker do?
有了启动 Chromium 无头实例、加载用户配置文件并启用远程调试端口的能力，攻击者可以做什么？

Instead of navigating to the HTML page at http://localhost:9222, your application can discover available pages by requesting: http://localhost:9222/json and getting a JSON object with information about inspectable pages along with the WebSocket addresses that you could use in order to start instrumenting them. (Source)
您的应用程序可以通过请求 http://localhost:9222/json 并获取一个 JSON 对象来发现可用页面，而不是导航到 http://localhost:9222 处的 HTML 页面，其中包含有关可检查页面的信息以及该页面的 WebSocket 地址。您可以使用它来开始检测它们。 （来源）

Let’s curl this endpoint and see what information we can obtain.
让我们卷曲这个端点，看看我们可以获得什么信息。

slyd0g@mac:~|⇒  curl http://localhost:9222/json
[ {
   "description": "",
   "devtoolsFrontendUrl": "/devtools/inspector.html?ws=localhost:9222/devtools/page/B74953F6EF3844659A1A0DD0A7A1602A",
   "faviconUrl": "https://static.xx.fbcdn.net/rsrc.php/yo/r/iRmz9lCMBD2.ico",
   "id": "B74953F6EF3844659A1A0DD0A7A1602A",
   "title": "Facebook - Log In or Sign Up",
   "type": "page",
   "url": "https://www.facebook.com/",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/B74953F6EF3844659A1A0DD0A7A1602A"
}, {
   "description": "",
   "devtoolsFrontendUrl": "/devtools/inspector.html?ws=localhost:9222/devtools/page/70EAE4FE55B93F79DC2F1637AEE663EC",
   "faviconUrl": "https://miro.medium.com/1*m-R_BkNf1Qjr1YbyOIJY2w.png",
   "id": "70EAE4FE55B93F79DC2F1637AEE663EC",
   "title": "Editing Cookies rule the world, not my actual title – Medium",
   "type": "page",
   "url": "https://medium.com/p/34c4f468844e/edit",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/70EAE4FE55B93F79DC2F1637AEE663EC"
}, {
...
...
}, {
   "description": "",
   "devtoolsFrontendUrl": "/devtools/inspector.html?ws=localhost:9222/devtools/page/ED4BA5705C20D08C5DF0B5FD076799EE",
   "id": "ED4BA5705C20D08C5DF0B5FD076799EE",
   "title": "1Password extension (desktop app required)",
   "type": "background_page",
   "url": "chrome-extension://aomjjhallfgjeglblehebfpbcfeobpgk/_generated_background_page.html",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/ED4BA5705C20D08C5DF0B5FD076799EE"
}]

I’ve highlighted some interesting information returned by Chromium. This endpoint returns information about currently open tabs as well as installed browser extensions.
我重点介绍了 Chromium 返回的一些有趣的信息。此端点返回有关当前打开的选项卡以及已安装的浏览器扩展的信息。

Additionally, the webSocketDebuggerUrl field is of particular interest to us
此外，我们对webSocketDebuggerUrl字段特别感兴趣

All Your Cookies Are Belong To Us
您所有的 Cookie 都属于我们

Connecting to the webSocketDebuggerUrl using a Web Socket client such as wsc we are presented with a terminal of some sort:
使用 Web Socket 客户端（例如wsc连接到webSocketDebuggerUrl ，我们会看到某种终端：

slyd0g@mac:~|⇒  wsc ws://localhost:9222/devtools/page/69BCB23AE200374A0FE8E638E5F9783F
Connected to ws://localhost:9222/devtools/page/69BCB23AE200374A0FE8E638E5F9783F
> ls
< {"error":{"code":-32700,"message":"JSON: invalid token at position 0"}}

@mangopdf discovered the bug report that lead to the creation of the Network.getAllCookies feature. Lots of other interesting methods here 😉 Walking in their footsteps, we are able to dump all the unencrypted Chromium cookies.
@mangopdf发现了导致创建Network.getAllCookies功能的错误报告。这里还有很多其他有趣的方法；）跟随他们的脚步，我们能够转储所有未加密的 Chromium cookie。

Introducing WhiteChocolateMacademiaNut
介绍白巧克力澳洲坚果

I wrote WhiteChocolateMacademiaNut in Golang to automate the above process.
我用 Golang 编写了WhiteChocolateMacademiaNut来自动化上述过程。

The code used below can be found here: https://github.com/slyd0g/WhiteChocolateMacademiaNut
下面使用的代码可以在这里找到： https://github.com/slyd0g/WhiteChocolateMacademiaNut

The important command line switches are the port you set the debugger to listen on (-p || -port) and what you want to dump (-d || -dump). You can dump open tabs/extensions or cookies.
重要的命令行开关是您设置调试器侦听的端口（ -p || -port ）以及您想要转储的端口（ -d || -dump ）。您可以转储打开的选项卡/扩展程序或 cookie。

The format and grep switches are to assist operators by dumping the cookies in a JSON format that can easily be loaded into another browser. The format flag modified will output cookies in JSON format with an expirationDate field set to 10 years in the future.The following examples may show Microsoft Edge or Google Chrome, but it should be noted this applies to all Chromium-based browsers.
format 和 grep 开关旨在通过将 cookie 转储为 JSON 格式来帮助操作员，该格式可以轻松加载到另一个浏览器中。 modified的格式标志将输出 JSON 格式的 cookie，并将expirationDate字段设置为未来 10 年。以下示例可能显示 Microsoft Edge 或 Google Chrome，但应注意这适用于所有基于 Chromium 的浏览器。

Targeting Chromium on Windows
针对 Windows 上的 Chromium

Scenario 1: Targeting User’s Cookies
场景 1：针对用户的 Cookie

Start Chrome/Edge with the user’s profile, in headless mode, and start the debugging port.
使用用户的配置文件在无头模式下启动 Chrome/Edge，并启动调试端口。

Opsec Note: If performing this through C2 such as Cobalt Strike, consider spoofing your parent process ID (PPID) to a PID of a running chrome.exe or msedge.exe. Bonus points if you are able to pull the command line arguments and find the original parent process which starts with no command line arguments. Additionally, it’s preferred that you proxy WhiteChocolateMacademiaNut to your target instead of dropping it to disc.
Opsec 注意：如果通过 C2（例如 Cobalt Strike）执行此操作，请考虑将父进程 ID (PPID) 欺骗为正在运行的 chrome.exe 或 msedge.exe 的 PID。如果您能够提取命令行参数并找到不使用命令行参数启动的原始父进程，则会获得加分。此外，最好将 WhiteChocolateMacademiaNut 代理到您的目标，而不是将其拖放到光盘上。

# Microsoft EdgePS C:\Users\John\Desktop> Start-Process "msedge.exe" -ArgumentList '--remote-debugging-port=9222 --headless --user-data-dir="C:\Users\John\AppData\Local\Microsoft\Edge\User Data"'# Google ChromePS C:\Users\John\Desktop> Start-Process "chrome.exe" -ArgumentList '--remote-debugging-port=9222 --headless --user-data-dir="C:\Users\John\AppData\Local\Google\Chrome\User Data"'

Run WhiteChocolateMacademiaNut to dump cookies using the debug port:
运行WhiteChocolateMacademiaNut以使用调试端口转储 cookie：

Awesome, we dumped all of the user’s cookies!
太棒了，我们转储了所有用户的 cookie！

It should be noted that you can perform this attack even when an instance of the browser is already running. However, if we attempt to dump the user’s current open tabs/extensions this will fail.
应该注意的是，即使浏览器实例已经在运行，您也可以执行此攻击。但是，如果我们尝试转储用户当前打开的选项卡/扩展程序，则会失败。

This makes sense because we are interacting with the remote debug port for the headless instance we started, not the user’s current browser instance.
这是有道理的，因为我们正在与我们启动的无头实例的远程调试端口交互，而不是与用户当前的浏览器实例交互。

Scenario 2: Dumping Tabs and Browser Extensions
场景 2：转储选项卡和浏览器扩展

If we want to dump the user’s current tabs and browser extensions, we will have to start the debugging port on their current browser. Unfortunately, we can’t simply just start their current process with additional command line arguments.
如果我们想转储用户当前的选项卡和浏览器扩展，我们必须在他们当前的浏览器上启动调试端口。不幸的是，我们不能简单地使用额外的命令行参数来启动他们当前的进程。

Enter the --restore-last-session flag. This is used by Chromium when your browser unexpectedly crashes to help restore your previous tabs. As an attacker, we can simply kill all instances of Google Chrome and restart the browser with a remote debugging port. This is shown below in PowerShell:
输入--restore-last-session标志。当您的浏览器意外崩溃时，Chromium 会使用此功能来帮助恢复之前的选项卡。作为攻击者，我们可以简单地杀死 Google Chrome 的所有实例，并使用远程调试端口重新启动浏览器。在 PowerShell 中如下所示：

Get-Process "chrome" | Stop-ProcessStart-Process "chrome.exe" -ArgumentList '--remote-debugging-port=9222 --restore-last-session --user-data-dir="C:\Users\John\AppData\Local\Google\Chrome\User Data"'

Opsec Note: You can also restart the browser early in the morning before the user unlocks their machine. This will make it look like browser crashed while they were asleep.
Opsec 注意：您还可以在用户解锁其计算机之前清晨重新启动浏览器。这会让浏览器看起来像是在他们睡觉时崩溃了。

Once you’ve restarted the user’s browser, you can dump their open tabs, extensions, as well as cookies!
重新启动用户的浏览器后，您可以转储他们打开的选项卡、扩展程序以及 cookie！

Targeting Chromium on macOS
在 macOS 上瞄准 Chromium

Unfortunately, on macOS the --headless flag does not play well with the --user-data-dir flag.
不幸的是，在 macOS 上， --headless标志不能与--user-data-dir标志很好地配合。

Initially, I thought this was because another Chrome instance was locking access to the database file. However, the error still occurred when I tried to start a headless instance of Chrome without any other instances running.
最初，我认为这是因为另一个 Chrome 实例锁定了对数据库文件的访问。但是，当我尝试启动 Chrome 的无头实例而不运行任何其他实例时，错误仍然发生。

@_EthicalChaos pointed out the -2 error number was unusual and found where this occurs in Chromium source: https://chromium.googlesource.com/chromium/src/+/master/sql/database.cc#1433
@_EthicalChaos指出 -2 错误号不寻常，并在 Chromium 源中发现了这种情况发生的地方： https://chromium.googlesource.com/chromium/src/+/master/sql/database.cc#1433

I investigated different command line arguments but was unable to get headless Chrome to work with a user data directory that I specified. The exact command works when running headful Chrome:
我研究了不同的命令行参数，但无法让无头 Chrome 使用我指定的用户数据目录。运行 headful Chrome 时，确切的命令有效：

# Cannot dump cookies with headless/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir="/Users/slyd0g/Library/Application Support/Google/Chrome" --crash-dumps-dir=/tmp --disable-gpu --disk-cache-dir=/tmp --headless# Can dump cookies with the same command without --headless/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir="/Users/slyd0g/Library/Application Support/Google/Chrome" --crash-dumps-dir=/tmp --disable-gpu --disk-cache-dir=/tmp

This could be a bug within Chromium for macOS, but I haven’t had the chance to fully investigate it.
这可能是 macOS 版 Chromium 中的一个错误，但我还没有机会全面调查它。

EDIT 7/8/21: The bug stems from an issue with Chromium on macOS and has been filed here: https://bugs.chromium.org/p/chromium/issues/detail?id=1106082&q=cookies%20headless&can=2
编辑 21 年 7 月 8 日：该错误源于 macOS 上的 Chromium 问题，已在此处提交： https://bugs.chromium.org/p/chromium/issues/detail ?id=1106082&q=cookies%20headless&can=2

We can get around this with the same trick we used for Windows by killing the user’s Chrome processes and restarting it with the appropriate command line arguments.
我们可以使用与 Windows 相同的技巧来解决这个问题，即终止用户的 Chrome 进程并使用适当的命令行参数重新启动它。

Opsec Note: You can also restart the browser early in the morning before the user unlocks their machine. This will make it look like browser crashed while they were asleep. Additionally, it’s preferred that you proxy WhiteChocolateMacademiaNut to your target instead of dropping it to disc.
Opsec 注意：您还可以在用户解锁其计算机之前清晨重新启动浏览器。这会让浏览器看起来像是在他们睡觉时崩溃了。此外，最好将 WhiteChocolateMacademiaNut 代理到您的目标，而不是将其拖放到光盘上。

slyd0g@mac:~|⇒  killall Google\ Chrome
slyd0g@mac:~|⇒  /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir="/Users/slyd0g/Library/Application Support/Google/Chrome" --restore-last-sessionDevTools listening on ws://127.0.0.1:9222/devtools/browser/20054ab4-19af-4896-9b0d-7e3c44571d68
2020-12-16 15:31:01.926 1PasswordNativeMessageHost[2312:1080733] 70700015 [EXT_NMH:(Secondary Thread 0x7ff81eccf270):OPNMXPCConnection.swift] E connect() | Connection Established

From my testing, the user doesn’t even have to click anything to restore their tabs. The tabs they previously had open will automatically open again.
根据我的测试，用户甚至无需单击任何内容即可恢复其选项卡。他们之前打开的选项卡将自动再次打开。

Once our debugger port is listening, we can dump open tabs, installed extensions, and cookies like usual.
一旦我们的调试器端口正在侦听，我们就可以像往常一样转储打开的选项卡、已安装的扩展和 cookie。

Targeting Linux 针对Linux

The above techniques should work against Chromium browsers for Linux as well, but I’ll leave that as an exercise for the reader.
上述技术也应该适用于 Linux 的 Chromium 浏览器，但我将把它留给读者作为练习。

Go out and compile WhiteChocolateMacademia and give it a try 🙂
出去编译WhiteChocolateMacademia并尝试一下:)

Detections 检测结果

• Monitor for Chromium browsers starting with the --remote-debug-port command line argument. This shouldn’t be happening unless a user is doing some browser or extension development.
  从--remote-debug-port命令行参数开始监控 Chromium 浏览器。除非用户正在进行某些浏览器或扩展开发，否则这种情况不应该发生。
• Monitor parent-process relationships and look for processes that shouldn’t normally be spawning browser processes.
  监视父进程关系并查找通常不应生成浏览器进程的进程。

Conclusion 结论

To recap, cookie theft is a method for attackers to obtain access to web applications without the need for the user’s actual credentials. Additionally, stealing cookies can bypass defensive controls such as multi-factor authentication (MFA).
回顾一下，cookie 盗窃是攻击者无需用户实际凭据即可获取 Web 应用程序访问权限的一种方法。此外，窃取 cookie 可以绕过多重身份验证 (MFA) 等防御控制。

Chromium browsers have a command line argument that allow you to remotely debug the browser. Interacting with this remote debugger port, we are able to dump all open tabs, installed extensions, and cookies. It should be noted that this technique is OS independent.
Chromium 浏览器有一个命令行参数，允许您远程调试浏览器。通过与此远程调试器端口交互，我们能够转储所有打开的选项卡、已安装的扩展和 cookie。应该注意的是，该技术与操作系统无关。

Thanks for taking the time to read this post, I hope you learned a little about the cookie theft and Chromium remote debugging!
感谢您花时间阅读这篇文章，我希望您了解一些有关 cookie 盗窃和 Chromium 远程调试的知识！

I’d like to reiterate that the technique documented here is not novel and has been well documented by @mangopdf’s blogpost in my references. I wanted to bring light to the technique again as it was extremely useful for a recent engagement as well as take the opportunity to write something in Go.
我想重申，这里记录的技术并不新颖， @mangopdf的博客文章在我的参考文献中已经详细记录了。我想再次阐明这项技术，因为它对于最近的一次参与非常有用，并借此机会用 Go 编写一些东西。

References 参考

Since the BloodHound thread won’t be viewable in a few weeks as the messages become stale, I’d like to also credit @domchell and @rkervell for extensive discussion about the topic in the thread and linking to @mangopdf’s blogpost.
由于随着消息变得陈旧，BloodHound线程在几周内将无法查看，因此我还要感谢@domchell和@rkervell对线程中的主题进行了广泛的讨论并链接到@mangopdf的博客文章。