New Post-Exploitation Technique Hijacks Chrome, Edge via DevTools Protocol
Cybersecurity researchers have unveiled a sophisticated post-exploitation technique leveraging the **Chrome DevTools Protocol (CDP)** to gain deep access to active **Google Chrome** and **Microsoft Edge** browser sessions on Windows. This method, detailed by **SpecterOps**, allows attackers with prior code execution to extract sensitive data like cookies, saved passwords, and even hijack authenticated browser sessions, bypassing some modern security measures.
Cybersecurity researchers have detailed a post-exploitation technique that enables the **Chrome DevTools Protocol (CDP)** inside a running **Google Chrome** or **Microsoft Edge** process on Windows. This allows an operator to access cookies, saved data, and authenticated browser sessions.
The technique assumes that an operator already has code execution on the Windows host and does not involve exploiting a Chrome or Edge security vulnerability. The requirement for prior code execution and sufficient access to manipulate the target process places the technique in a narrower post-compromise scenario than a remotely exploitable browser flaw.
**SpecterOps** advises defenders to look for signs of process injection targeting `chrome.exe` and `msedge.exe` using **Sysmon Event IDs 8** and **10**.
"Since **App-Bound Encryption** was enabled, we've seen an increase in attackers using Chrome Remote Debugging to extract cookies," **Google** noted in a March 2025 post. Google changed Chrome's remote debugging behavior beginning with **Chrome 136** after observing this trend, a practice that has been discussed since 2018.
Chrome 136 ignores 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`. This non-standard directory uses a different encryption key, which Google states protects Chrome's data from attackers.
According to SpecterOps, the **CDP-Enable-BOF** takes a different approach by activating the debugging server from inside an existing `chrome.exe` or `msedge.exe` process. The x64 **Beacon Object File (BOF)** then exposes the browser's existing context over a requested CDP port.
### CDP Inside the Running Browser
The BOF builds on earlier work by **DeathFlamingo**, who documented injecting CDP into a running Edge browser in December 2025, and on **Cedric Van Bockhaven's** "Modern Session Hijacking by Living off the DevTools Protocol."
At a high level, **CDP-Enable-BOF** performs the following steps:
* Finds the requested live Chrome or Edge process and its top-level window.
* Locates 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.
* Executes the final call on the browser user interface thread.
* Calls Chromium's internal `StartRemoteDebuggingServer` function on the requested port.
The repository states that executing the final call on the browser's user interface thread makes the technique reliable in the presence of **CFG**, **TLS**, and **CET**-sensitive execution. The BOF requires a running browser process and is limited to x64 systems.
The public repository does not specify whether administrator rights are required in every case.
### Browser Takeover Through CDP
Once the endpoint is available, **SpecterOps' CDP-Toolkit** can interact with the browser directly or automate its internal WebUI surfaces. The main post-exploitation workflows are:
* **Cookie collection** uses `Storage.getCookies` to request the browser's cookie state without reading the cookie database from disk.
* **Browser data collection** can retrieve history, bookmarks, installed extensions, screenshots, and saved-password metadata through CDP and browser-rendered pages.
* **Saved-password recovery** can exercise Chromium's autofill workflow against a matching origin and read resulting username and password field values through CDP.
* **Browser takeover** 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.
The screencast mode leaves 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.
The proxy mode makes upstream requests through browser targets carrying the victim's authenticated state on the compromised endpoint, preserving cookies and the browser's user agent where CDP exposes them.
Google's **Device Bound Session Credentials (DBSC)**, which became available to Windows users with **Chrome 146**, bind session refresh to a hardware-backed key and are designed to prevent stolen cookies from being refreshed on another device.
SpecterOps does not describe extracting that private key. The firm stated that operating through the authenticated browser context can sidestep protections intended to prevent off-device replay.
### Detection and Version Limits
**Microsoft's Sysmon** documentation identifies **Event ID 8** as `CreateRemoteThread`, which records when a process creates a thread in another process, and **Event ID 10** as `ProcessAccess`, which records when one process opens another.
Microsoft notes that Event ID 8 can indicate code injection, while ProcessAccess can generate significant logging and should generally be used with filters that remove expected activity.
The Hacker News confirmed via **GitHub** on August 14 that the public BOF still lists **Chrome 147.0.7727.102** and **Edge 147.0.3912.98** as its tested versions and describes the signatures as version-specific.
Later browser releases documented by Google and Microsoft include:
* **Chrome:** The repository lists 147.0.7727.102 as tested. Google moved **Chrome 151.0.7922.47/.48** into Early Stable for a small percentage of Windows and macOS users on July 22.
* **Edge:** The repository lists 147.0.3912.98 as tested. Microsoft's Stable release notes list **151.0.4129.78**, released August 10, as the latest Stable build as of August 14.
The repository provides scripts for deriving new signatures when browser updates cause symbol resolution to fail, but it does not establish that its bundled signatures work unchanged against later browser releases.
This development comes a day after **AmnesiaStealer** was disclosed, targeting macOS users with a `stream_module` that grants an operator hidden, interactive control over a Chromium browser. **Jamf Threat Labs** said the component supports keyboard, mouse, scrolling, navigation, and tab management through CDP, and that it exported cookies in plaintext during its analysis, while SpecterOps' Windows research activates CDP inside the victim's already-running Chrome or Edge process.