Skip to main content
CybersecurityHacking

Researchers Expose Chrome DevTools Protocol Hijacking Technique

Cybersecurity researcher poised to type on keyboard amidst multiple computer screens in a bright lab setting.

"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.

SpecterOps' CDP-Enable-BOF: activating DevTools inside a live browser

Cybersecurity researchers at SpecterOps published a Beacon Object File (BOF) that activates the Chrome DevTools Protocol (CDP) inside a running chrome.exe or msedge.exe process on Windows. The technique assumes an operator already has code execution on the host and does not rely on exploiting a Chrome or Edge security vulnerability. SpecterOps' public repository describes an x64 BOF that exposes the browser's existing execution context over a requested CDP port by calling Chromium's internal StartRemoteDebuggingServer function from the browser's user interface thread.

How the BOF accomplishes in-process debugging (as documented)

  • Finds a live Chrome or Edge process and its top-level window.
  • Locates the loaded chrome.dll or msedge.dll module and 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 UI thread.
  • The repository notes executing on the UI thread helps reliability where Control Flow Guard (CFG), Thread Local Storage (TLS), and CET-sensitive execution are present.

The BOF is limited to x64 systems and requires a running browser process; 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.

What CDP access lets an operator do

Once the debugging server is active inside the live browser, SpecterOps' CDP-Toolkit can interact with and automate internal WebUI surfaces to harvest or operate through an authenticated context. The main post-exploitation workflows documented by SpecterOps include:

  • Cookie collection via Storage.getCookies, which requests the browser's cookie state without reading cookie files from disk.
  • Browser data collection of history, bookmarks, installed extensions, screenshots, and saved-password metadata through CDP and browser-rendered pages.
  • Saved-password recovery by exercising Chromium's autofill workflow against a matching origin and reading username and password field values via CDP.
  • Browser takeover modes that create offscreen or background targets for interactive screencasting, or proxy HTTP/HTTPS requests through targets carrying the victim's authenticated state.

SpecterOps points out that the screencast and proxy modes preserve cookies, enterprise authentication state, WebAuthn behavior, extensions, and browser-specific JavaScript behavior inside the compromised browser instance. Google’s Device Bound Session Credentials (DBSC), introduced to Windows users with Chrome 146, bind session refresh to a hardware-backed key to prevent stolen cookies from being refreshed on another device; SpecterOps does not describe extracting that private key and notes that operating through the authenticated browser context can sidestep protections intended to prevent off-device replay.

Detection signals and version constraints

Defenders are pointed to Windows process-injection indicators. SpecterOps said defenders can look for code-injection activity targeting chrome.exe and msedge.exe using Microsoft Sysmon Event IDs 8 and 10. Microsoft's documentation identifies Event ID 8 as CreateRemoteThread (an indicator of cross-process thread creation) and Event ID 10 as ProcessAccess (when one process opens another); Microsoft cautions that ProcessAccess can produce significant logging and should be filtered to remove expected activity.

The BOF repository lists tested signatures for Chrome 147.0.7727.102 and Edge 147.0.3912.98 and describes those signatures as version-specific. The Hacker News confirmed on August 14 via the BOF's GitHub that those versions remain listed. Google and Microsoft published later releases: Google moved Chrome 151.0.7922.47/.48 into Early Stable on July 22 for a subset of users, and Microsoft's Stable release notes listed Edge 151.0.4129.78 as the latest Stable build on August 10. The repository includes scripts to derive new signatures when browser updates break symbol resolution, but it does not assert that bundled signatures work unchanged against later releases.

What this means for technologists, procurement leaders, and end users

  • Technologists and security teams: look for the specific process-injection behaviors SpecterOps cites and tune Sysmon filters around Event ID 8 (CreateRemoteThread) and Event ID 10 (ProcessAccess) to reduce noise while preserving hunting visibility.
  • Enterprise IT and procurement leaders: note that the BOF's signatures are version-specific; the repository offers scripts to derive new signatures, so tracking browser build deployments and update cadence will matter for both mitigation and incident response planning.
  • End users and administrators: the technique requires prior code execution on the host, which narrows the scenario compared with a remote browser zero-day—but if an endpoint is already compromised, the attacker can access cookies and authenticated sessions without reading disk files directly.

SpecterOps' work and related macOS research released around the same time underline a persistent trade-off: platform and browser defenses can harden data-at-rest, but an authenticated, running browser process remains a high-value target. Two concrete follow-ups remain in public view: whether the BOF reliably works against later 151-series builds and whether administrator privileges are consistently required; SpecterOps and vendors have been asked for clarification.

Original story — The Hacker News