Security researchers have uncovered a post-exploitation method that activates the Chrome DevTools Protocol inside a running Google Chrome or Microsoft Edge browser on Windows systems, granting attackers access to cookies, stored credentials, and active authenticated sessions. SpecterOps detailed the technique in a disclosure published this week, emphasizing that it requires an operator to already have code execution on the target machine and doesn't exploit any browser security flaw. The requirement for prior code execution and sufficient permissions to manipulate the browser process means the technique sits in a more limited post-compromise scenario than a remotely exploitable vulnerability would.

The tool, called CDP-Enable-BOF, works by activating the debugging server from within an existing chrome.exe or msedge.exe process rather than launching the browser with debugging flags. This x64 Beacon Object File locates the requested live browser process and its top-level window, finds the loaded chrome.dll or msedge.dll module, resolves internal Chromium symbols using masked byte signatures, allocates remote memory for two small stubs and a context block, temporarily installs a remote window procedure, and executes the final call on the browser user interface thread to invoke Chromium's internal StartRemoteDebuggingServer function on the requested port. SpecterOps' CDP-Toolkit can then interact with the browser directly or automate its internal WebUI surfaces for cookie collection using Storage.getCookies, retrieval of history, bookmarks, installed extensions, screenshots, and saved-password metadata, and recovery of saved passwords by exercising Chromium's autofill workflow against a matching origin. The public repository lists Chrome 147.0.7727.102 and Edge 147.0.3912.98 as its tested versions and describes the signatures as version-specific, while Google moved Chrome 151.0.7922.47/.48 into Early Stable for a small percentage of Windows and macOS users on July 22, and Microsoft's Stable release notes list 151.0.4129.78, released August 10, as the latest Stable build as of August 14.

Google acknowledged in a March 2025 post that "since App-Bound Encryption was enabled, we've seen an increase in attackers using Chrome Remote Debugging to extract cookies," noting that cookie theft using the debugging interface had been discussed since 2018. The company changed Chrome's remote debugging behavior beginning with Chrome 136, configuring the browser to ignore the --remote-debugging-port and --remote-debugging-pipe switches when they target the default Chrome data directory unless accompanied by a non-standard --user-data-dir, which uses a different encryption key that Google said protects Chrome's data from attackers. SpecterOps said defenders can look for signs of process injection targeting chrome.exe and msedge.exe using Sysmon Event IDs 8 and 10, which Microsoft's documentation identifies as CreateRemoteThread and ProcessAccess respectively—the former records when a process creates a thread in another process and can indicate code injection, while the latter records when one process opens another but can generate significant logging and should generally be used with filters that remove expected activity.

The technique's browser takeover capability can create an offscreen or background browser target for interactive screencasting, or proxy HTTP and HTTPS requests through browser targets carrying the victim's authenticated state, with the screencast mode leaving cookies, browser storage, enterprise authentication state, WebAuthn behavior, extensions, and browser-specific JavaScript behavior inside the Chrome or Edge instance running on the compromised system. SpecterOps noted that operating through the authenticated browser context can sidestep protections intended to prevent off-device replay, though the firm doesn't describe extracting the private key used by Google's Device Bound Session Credentials, which became available to Windows users with Chrome 146 and bind session refresh to a hardware-backed key designed to prevent stolen cookies from being refreshed on another device. The repository provides scripts for deriving new signatures when browser updates cause symbol resolution to fail, but it doesn't establish that its bundled signatures work unchanged against later browser releases. Organizations running current browser versions may find their exposure window narrowing as vendors push updates, though the persistence of post-exploitation tools suggests the tension between attacker innovation and defensive controls will continue to shape enterprise browser security postures. The fundamental challenge isn't technical capability alone but the organizational discipline required to maintain detection coverage across environments where credential theft remains a high-value target.