Chrome DevTools Technique Enables Authenticated Session Hijacking in Live Windows Browsers

August 14, 2026 · The Hacker News · Severity: HIGH

Researchers at SpecterOps have detailed a post-exploitation technique that activates Chrome DevTools Protocol (CDP) inside a running Chrome or Edge process on Windows, enabling cookie theft, data exfiltration, and session hijacking. The method assumes the attacker already has code execution on the host and does not exploit a browser vulnerability; instead, it uses a Beacon Object File (CDP-Enable-BOF) to inject a debugging server into the existing process. This approach bypasses mitigations like App-Bound Encryption by operating within the authenticated browser context, allowing tools like the CDP-Toolkit to collect cookies, extract passwords, and proxy traffic through the victim's session. Google has responded by altering Chrome's remote debugging behavior in version 136, requiring a non-standard user data directory to enable CDP via command-line switches. However, the new injection technique activates CDP from inside the process, potentially sidestepping this defense. The technique is limited to x64 systems and relies on version-specific binary signatures, but the repository includes scripts to update signatures for new browser releases. Defenders can detect such activity using Sysmon events for process injection (Event ID 8 and 10), though filtering is needed to avoid noise. Google's Device Bound Session Credentials (DBSC) in Chrome 146 may also limit session theft, but the technique does not extract hardware-backed keys. The research builds on prior work by DeathFlamingo and Cedric Van Bockhaven, highlighting the evolving threat of CDP-based attacks in post-compromise scenarios.

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, allowing 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 said defenders can 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 said in a March 2025 post . Google changed Chrome's remote debugging behavior beginning with Chrome 136 after observing an increase in attackers using Chrome Remote Debugging to extract cookies following the introduction of App-Bound Encryption (ABE) . The company said cookie theft using the debugging interface had 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 they are accompanied by a non-standard --user-data-dir. The non-standard data directory uses a different encryption key, which Google said protects Chrome's data from attackers. According to SpecterOps , the CDP-Enable-BOF takes a different path 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," both of which the repository cites as foundations for the project. 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 said executing the final call on the browser's user interface thread is used to make 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 state whether administrator rights are required in every case. The Hacker News has reached out to SpecterOps for clarification on privilege requirements and current-browser compatibility and will update this story with any response. 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 listed below - 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 said 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 the following - 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. The 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. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Key Takeaways

The technique exploits Chrome DevTools Protocol inside already-running Chrome or Edge on Windows, requiring prior code execution and no browser vulnerability.
Google's Chrome 136 update blocks CDP activation via command-line switches for the default data directory, but the new method injects CDP directly into the browser process using a Beacon Object File.
Defenders can monitor for process injection targeting chrome.exe or msedge.exe using Sysmon Event IDs 8 and 10, though detection may require filtering expected activity.