Cookies are the keys to the kingdom - In today’s enterprise and consumer environments, Single Sign-On (SSO) and SaaS applications dominate the web landscape. These platforms heavily rely on session cookies to maintain persistent authenticated states across multiple services and domains.

As a result, post-authentication session cookies have become highly valuable targets for attackers. With the proliferation of U2F MFA adversaries are focussing on the user’s browser as a post-compromise foothold seeking to extract cookies and tokens that grant ongoing access to sensitive systems without triggering additional authentication.

Chrome, as the most widely used browser, is a frequent target. While it implements multiple protections — including sandboxing, encrypted storage, and access controls — several attack vectors remain to exfiltrate these cookies. This post explores those vectors, from built-in browser functionality, malicious extensions to local disk encryption and enterprise policy hardening.

This post is part one of an n part series, where I will be covering various methods for attacking and defending sensitive data in the Chrome browser.

Chrome DevTools Protocol⌗

The Chrome remote debugger, exposed as part of the Chrome DevTools Protocol, is by far the best known method for dumping data from the browser and has been blogged about extensively. Abusing this feature requires killing and relaunching the browser with the --remote-debugging-port and optionally --restore-last-session to restore the previous session and attempt to hide your activities.

While other tools exist, WhiteChocolateMacademiaNut is a favourite as it is a stand-alone tool and doesn’t require an additional components such as websocat. Usage is straight forward, once the browser debugger is running simply run ./WhiteChocolateMacademiaNut --port <debugger port> --dump cookies to dump all cookies or optionally supply --grep to target cookies for specific domains.

The dumped cookies can also be injected back into a browser of your choice with ./WhiteChocolateMacademiaNut --port <debugger port> --load cookies.json, which makes leveraging the stolen cookies a single command away.

Remote Allow Origins⌗

In December of 2022 a feature was added to Chromium which introduced the --remote-allow-origins flag as an additional control to limit access to the debugger.

reject debugging web socket connections with a defined Origin header unless the browser is started with a new flag --remote-allow-origins=<origin>[,<origin>, ...].

This has also been covered in detail so I wont repeat it here. In short, interacting with the remote debugger now requires the use of an additional argument --remote-allow-origins=* when launching Chrome but the existing cookie dumping technique remains the same.

When enforced, connections to the debugger must present a matching Origin header otherwise the connection would be rejected. However, this can be overcome by using a websocket client that supports omitting the origin header.

In Python you can achieve this by supplying the suppress_origin argument to the connect() function as covered in the websocket documentation. Because this WebSocket connection lacks an Origin header, Chrome accepts the request without the need to supply to --remote-allow-origins argument.

Browser Extensions⌗

Browser extensions are incredibly powerful, often operating with a high level of trust with deep integration into the browser, making them a prime target for abuse. By requesting broad permissions during installation - such as the ability to read and change data on all websites - an extension gains privileged access to everything the user sees and types.

A good demonstration of this potential is Cursed Chrome, which provides an easy mechanism to synchronise the cookies to an attacker controlled location and full request proxying via a SOCKS proxy over websockets. While this serves as a good out of the box example, the same results can be achieved with any extension that requests the cookies permission and includes the relevant target domains in the extension host_permissions.

Attacking Extensions via CDP Injection⌗

Comfortably-run by mandatoryprogrammer makes it trivial to inject arbitrary JavaScript into Chrome extensions via the DevTools Protocol. This makes it possible to leverage the permissions of an existing, and likely trusted, extension to extract data from the browser. This is especially powerful in instances where enterprise policies limit interactions with sensitive domains, such as via the runtime.allowed_hosts directive.

Silent Installation⌗

The Silent Chrome project by asaurusrex, which builds on an earlier research by Marcus Brody, automates the installation of Chrome extensions without user interaction by modifying the Secure Preferences file to include an arbitrary extension, enabling developer mode, and finally recomputing the required HMAC values in order for Chrome to validate the file contents.

This method, while effective, is limited to Chrome profiles that allow enabling of Developer Mode, i.e. those that are not subject to an enterprise policy which enforces the ExtensionDeveloperModeSettings policy.

Chrome stores cookies in an SQLite database at ~/Library/Application Support/Google/Chrome/<Profile>/Cookies, however, the values in the encrypted_value column are encrypted using a passphrase stored in the keychain. This passphrase can be retrieved by using keychain APIs or by using native tools like /usr/bin/security.

Usage of security is straight forward, however this technique relies on some additional social engineering in order to convince the user to proceed through the password prompts or knowledge of the user’s password to unlock the keychain using security unlock-keychain.

security find-generic-password -s "Chrome Safe Storage" -w

Password prompt for keychain access via the security binary

Due to the way in which macOS presents these prompts, there is no easy way for the user to identify the application requesting access to the keychain beyond the name of the binary. As attackers we can abuse this to present a more convincing case by either renaming the security binary or building your own and giving it a name that is appropriate for the target environment.

If you’re operating in an environment where alerting is configured to monitor unexpected file read events for Chrome profile data, you may be able to overcome this by hard linking the profile to another location and reading the data from there.

Net Logging⌗

Chromium’s network logging feature is a little-known diagnostic tool that can be abused to dump sensitive data.

Launching Chrome with the arguments --log-net-log=/tmp/foo.json and --net-log-capture-mode=IncludeSensitive enables clear-text logging of items including cookies and HTTP headers to an arbitrary location on disk.

Mock Keychain⌗

Launching Chrome with the --use-mock-keychain argument results in cookies stored in ~/Library/Application Support/Google/Chrome/<Profile>/Cookies being encrypted using the password mock_password.

Using this, the entire cookies DB can be copied locally and injected into a local browser by launching it with the same --use-mock-keychain arg.

An important caveat here is that all previously stored data is erased, meaning previously active sessions cannot be restored and could raise suspicion among users.