Статья Into The Belly Of The Beast

In this post, we introduce a post-exploitation concept and tool designed to dump all cookies, session, and local storage entries to JSON files and it does this through a localhost WebSocket connection using Chrome/Brave/Edge's remote debug functionality (Для просмотра ссылки Войди или Зарегистрируйся).

The Belly - Chrome DevTools Protocol (CDP)​

CDP was created to allow developers to interact with and control Chromium-based browsers (Edge/Brave/Chrome/Opera, etc.) programmatically and enables things like inspecting web pages in real-time, debugging JavaScript, DOM manipulation, monitoring network activity (extremely useful), and performing nearly anything possible within DevTools. It essentially enables a communication channel between the browser and a client (e.g., a script or some other external application) via a WebSocket through a "debugging port".

When the --remote-debugging-port switch is enabled (supplied via the command line when launching the browser), external tools or scripts can connect to the browser over the network. It's typically used for tasks such as testing automation with tools like Playwright, Puppeteer, Selenium, etc., or just to debug web applications remotely.

For example, running chrome.exe --remote-debugging-port=9481 starts Chrome with debugging enabled on port 9481, and is accessible via Для просмотра ссылки Войди или Зарегистрируйся or via the CDP WebSocket (ws://localhost:9481)

You can learn more about CDP Для просмотра ссылки Войди или Зарегистрируйся.

The Concept​

1. Find the users' default browser​

This is usually done by querying the HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice registry path to determine which default program is associated with opening URLs. In this case, the value for ProgId gives us a hint as to what the default browser is. The ProgId is typically something like ChromeHTML, or BraveHTML, etc, but in the odd case where the default browser hasn't been set, it might look more like FirefoxURL-[RandomString]. Either way, we can usually determine the default browser by simply retrieving that ProgId value.

2. Relaunch the browser with the --remote-debugging-port enabled​

If the browser is already open and does not have remote debugging enabled (if it does already, something is unusual), we need to terminate it and relaunch it in order to enable the debug port. Unfortunately, the main caveat to this tool is that the debug port cannot just be enabled on an already running browser (that I know of). This may or may not spark some suspicion or curiosity from the end-user's perspective.

3. Dump all the things​

Once the browser is relaunched with the --remote-debugging-port switch enabled, we can interact with it freely, and have access to a number of things that are useful during engagements, particularly session information (auth tokens, cookies, etc.).

TokenTaker​

Для просмотра ссылки Войди или Зарегистрируйся is a proof-of-concept PowerShell script that automates the above process and dumps all cookies, session and local storage. It can be downloaded from our GitHub page Для просмотра ссылки Войди или Зарегистрируйся.

The script will first identify the default browser by querying the Windows registry for the ProgId of the application handling HTTPS links and uses a lookup table ($browserMap) to match ProgId values to known browser paths and user profile directories. Once it’s figured out which browser to use, it first checks if remote debugging is already enabled (it really shouldn’t be by default), but if it is, it will use that. If an existing browser session is detected without remote debugging (the more likely scenario), it is forcibly terminated and a new browser instance is started with --remote-debugging-port=9481.

Once it has confirmed that remote debugging is enabled, it will retrieve the list of open tabs from the debugging API, and extracts the WebSocket debugging URL from the /json endpoint. The /json endpoint returns a list of active tabs, each with a webSocketDebuggerUrl, which is used to send and receive debugging commands.



Example response from Для просмотра ссылки Войди или Зарегистрируйся

After it’s retrieved list of active tabs, it connects to the first one it finds using the webSocketDebuggerUrl:



Retrieving list of active tabs and initial WebSocket Connection

Extracting Cookies via the Network.getAllCookies Method

The first command sent over the WebSocket is:


The above command tells the browser to use the Network.getAllCookies method, which fetches all cookies accessible to the browser, along with assigning a request ID to track responses, and converted to JSON format.

The script then sends this JSON-encoded message over the WebSocket with the Send-WsMsg function:

Inside Send-WsMsg, the command is converted to UTF-8 bytes and sent to the browser WebSocket, and the WebSocket returns a JSON object with all of the stored cookies:

Example cookie output

Extracting Local Storage via the Runtime.evaluate Method​

Unlike cookies, Local Storage and Session Storage are not accessible via Network methods, and instead, JavaScript execution is required via the Runtime.evaluate method. To retrieve Local Storage, the script sends:


The Runtime.evaluate method runs JavaScript inside the active browser tab, and "params": { "expression": "JSON.stringify(localStorage)" } is used to convert the Local Storage into a JSON string. The $localStorageCommand is then sent to the WebSocket, and it returns something like the following:

Example Local Storage Output

Session Storage works the same way as Local Storage but is tab-specific and cleared when the browser is closed.
After retrieving cookies, local storage, and session storage, TokenTaker gracefully terminates the WebSocket connection. This sends a Close frame over the WebSocket, ensuring a clean disconnection.


All files are saved to a random GUID-named folder in $env:TEMP.

Для просмотра ссылки Войди или Зарегистрируйся