Researchers Show How Attackers Can Hijack Live Chrome and Edge Sessions on Windows

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, saved data, and active logged-in sessions from the live browser.
• It assumes the attacker already has code running on the Windows machine, so it is a post-break-in move, not the initial way in.
• No password prompt is triggered and the operating system's data protection does not 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 shown a new way for attackers who are already inside a Windows computer to quietly take over a victim's web browser sessions. The method turns on a hidden developer feature inside Google Chrome or Microsoft Edge while the browser is running, and uses it to walk out with cookies and logged-in sessions.

In plain terms: once a criminal has a foothold on the machine, they can ride the browser that is already open and signed in to email, banking, or work apps. No fresh login. No password box. The browser just does what the attacker tells it.

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 developer tools. It is the same plumbing web developers use to inspect a page. Turned against a user, it becomes a spy sitting inside their own browser.

CDP can read cookies, dump saved site data, and observe live tabs. Attackers who reach it get the keys to any site the victim is currently signed in to. That includes accounts protected by multi-factor authentication, which is the extra code or app prompt you use after your password, because the browser has already passed that check for the day.

How does the attack actually work?

The attacker needs code execution on the Windows host first. That is the important caveat. This is not a way to break in from the internet. It is what happens after phishing, a malicious installer, or a stolen laptop has already given someone a shell on the machine.

From there, the technique enables CDP inside the running Chrome or Edge process rather than launching a new browser with debugging flags. Older tricks that spawned a second Chrome with --remote-debugging-port were noisy and easy for defenders to spot. Flipping the switch inside the live process is quieter.

The failure mode here is trust. Windows treats the browser as the user, the browser trusts its own debug channel, and the debug channel hands over everything the user is logged in to. Data Protection API, the Windows feature that encrypts saved passwords tied to the user account, does not help because the browser is doing the decryption itself as normal.

What should ordinary users and IT teams do?

Home users cannot patch this directly. It is a design behaviour of the browser, not a single bug with a CVE number. What you can do is treat the initial break-in as the thing to prevent: do not run installers from unknown sources, keep Windows and the browser updated, and sign out of sensitive sites like banking when you are done rather than staying logged in.

For IT and security teams, the practical detections are behavioural. Watch for processes attaching to chrome.exe or msedge.exe with debug interfaces. Watch for unexpected local network listeners on browser processes. Endpoint tools can flag when something reads the browser's memory or cookie stores outside of normal patterns.

One thing the post-mortem will say on any incident that uses this: the attacker was already in. The browser was just the fastest way to turn one machine into every SaaS account the user had open.

Operational takeaway: assume any workstation break-in equals a full session hijack of every app in that browser, and plan session revocation accordingly.