Researchers Show How Attackers Can Hijack Live Chrome and Edge Sessions on Windows
A post-exploitation trick flips on Chrome's built-in debugger inside a running browser, handing attackers cookies and logged-in sessions without touching the password vault.
Key points
- Researchers detailed a technique that switches on the Chrome DevTools Protocol inside a running Google Chrome or Microsoft Edge process on Windows.
- The trick lets an attacker read cookies and active logged-in sessions from the live browser.
- It assumes the attacker already has code running on the Windows machine, so it's a post-break-in move, not the initial way in.
- No password prompt is triggered and the operating system's data protection doesn't block it.
- Defenders should watch for unusual debugger activity on browser processes and for signs of remote control of a running Chrome or Edge.
Security researchers have detailed a post-exploitation method for quietly taking over a victim's browser sessions on Windows. It turns on a hidden developer feature inside Google Chrome or Microsoft Edge while the browser is already running, then uses that channel to collect cookies and authenticated sessions. The writeup was first reported by The Hacker News.
What is the Chrome DevTools Protocol, and why does this matter?
The Chrome DevTools Protocol, or CDP, is the built-in remote-control channel that Chrome and Edge use for their developer tools. Turned against a user, it reads cookies, dumps saved site data, and watches live tabs. Accounts protected by multi-factor authentication, the extra code or app prompt you enter after your password, are not safe either: the browser has already passed that check, so the attacker inherits the result.
How does the attack actually work?
The attacker needs code execution on the Windows host first. This isn't a way in from the internet. It's what becomes possible after phishing or a malicious installer has already put someone on the machine.
From that position, the technique enables CDP inside the live Chrome or Edge process. Older approaches spawned a fresh browser with --remote-debugging-port flags, which was noisy and detectable. Working inside the existing process is quieter.
The failure mode is trust. Windows treats the browser as the user, the browser trusts its own debug channel, and that channel hands over every session the user holds. The Windows Data Protection API, which encrypts saved passwords tied to the user account, doesn't intervene because the browser decrypts those credentials itself as normal. We covered a related post-exploitation pattern on 30 July 2026 in "What Hackers Actually Do After They're Inside Your Network", where a Huntress case study made the same point: getting in is only the first problem.
Should you worry?
Home users can't patch this directly. It's a design behaviour, not a single bug with a CVE number. What you can do is treat the initial break-in as the line to hold: avoid running installers from sources you don't recognise, keep Windows and your browser updated, and sign out of banking or sensitive accounts when you're finished rather than leaving sessions open.
For security teams the detections are behavioural. Watch for processes attaching to chrome.exe or msedge.exe with debug interfaces open. Look for unexpected local listeners on browser processes. Endpoint tools should flag anything reading the browser's memory or cookie stores outside of normal operation.
Every post-mortem on an incident that uses this technique will say the same thing: the attacker was already inside. The browser was just the fastest path from one compromised workstation to every SaaS account the user had open.
Plain judgement: the technique itself isn't surprising to anyone who's read a CDP spec, but the operational implication is sharper than most teams act on. A workstation breach should trigger session revocation across every cloud app in that browser profile, not just a malware scan. Most IR playbooks still don't do that automatically, and that gap is what makes this worth paying attention to.
