Two pieces of research landed within days of each other, on different operating systems, from unrelated sources. They arrive at the same place.

Jamf documented AmnesiaStealer, macOS malware that takes over the victim's browser session and streams it back to the operator.

SpecterOps documented a Windows technique that turns on Chrome's own debugging protocol inside a browser that is already running and already logged in.

Neither steals a password. Neither is defeated by multi-factor authentication, because the authentication already happened.

AmnesiaStealer: drive the Mac's browser remotely

It arrives through a ClickFix campaign — a fake GitHub download page serving a password-protected ZIP, with a shell-script loader fetching the payload. Jamf notes the template was previously used for the Atomic and MacSync infostealers.

The interesting component is stream_module. It:

  1. Duplicates the user's browser profile from any of seven Chromium browsers — Chrome, Edge, Vivaldi, Arc, Opera, Brave, Chromium
  2. Launches that copy headless, with defences weakened
  3. Opens a WebSocket back to the operator

The operator then gets a live screencast at about 3fps, with keyboard, mouse, scroll, navigation and tab control.

That is not data theft. That is remote desktop, scoped to the browser, inside an already-authenticated session.

It also harvests the conventional things: credentials from 16 Chromium-based browsers, cryptocurrency wallets, Apple Notes, documents and keychain data.

The Windows technique: switch on DevTools in a live process

SpecterOps' CDP-Enable-BOF builds on earlier work by DeathFlamingo and Cedric Van Bockhaven. It finds the running Chrome or Edge process, loads the browser's DLL, resolves internal Chromium symbols by byte signature, allocates two small stubs and a context block, installs a temporary remote window procedure, and calls StartRemoteDebuggingServer on the browser's UI thread.

The Chrome DevTools Protocol is then live inside a browser the user is sitting in front of.

What that gives an operator, through the companion CDP-Toolkit:

  • Cookies via Storage.getCookies — read from the browser's state, not from the cookie database on disk
  • History, bookmarks, extensions and saved-password metadata
  • Chromium's own autofill workflow triggered against a matching origin, then the resulting username and password fields read back
  • An offscreen browser target for interactive screencasting, or HTTP and HTTPS proxied through the victim's authenticated browser

Requirements, stated plainly by SpecterOps:

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.

Tested against Chrome 147.0.7727.102 and Edge 147.0.3912.98, x64 Windows only. The byte signatures are version-specific, which is the main friction.

Why this beats the controls you bought

Every defence in the credential chain assumes the attacker needs to authenticate.

  • MFA proves who you are at login. This is after login.
  • Conditional access checks device and location. The device is the corporate device and the location is the office.
  • Impossible-travel detection sees nothing, because the requests come from the victim's own machine.
  • Cookie theft protections are partly sidestepped. Chrome 146 introduced Device Bound Session Credentials, binding refresh tokens to hardware keys to stop off-device replay — SpecterOps says their approach can sidestep protections meant to prevent off-device replay by working through the authenticated browser context itself. They do not claim to extract the private key. They do not need to. The browser holding the key does the work.

Ordinary cookies are fully exposed.

This is the same conclusion the passkey research in August reached from a different direction: phishing-resistant authentication is a statement about phishing. It does not describe what happens on a host the attacker already owns.

What Google has already done, and what it did not fix

In March 2025 Google acknowledged rising abuse and changed remote debugging behaviour from Chrome 136: debugging switches are ignored unless paired with a non-standard user data directory.

That closed the easy path — relaunching Chrome with a debugging flag. It does not close this one, which never restarts the browser and never passes a flag.

Detection

On Windows, Sysmon Event ID 8 (CreateRemoteThread) and Event ID 10 (ProcessAccess) catch injection targeting chrome.exe and msedge.exe. SpecterOps notes Event 10 is extremely noisy and needs filtering before it is usable.

On macOS, look for a Chromium binary launched headless with a profile path that is not the user's, and outbound WebSocket connections from a browser process to somewhere that is not a known service.

More generally, the signal is a browser process behaving like two browsers — one the user sees, one they do not.

What actually helps

  • Assume the session, not just the credential, is the asset. Shorten session lifetimes for privileged applications and require step-up re-authentication for sensitive actions. That is the one control that meaningfully limits a hijacked session.
  • Deploy Device Bound Session Credentials where you can. It does not stop this technique, but it stops the much more common off-device cookie replay.
  • Alert on browser process injection. It is a narrow, high-signal detection once Event 10 is filtered.
  • Tell staff the actual ClickFix rule: never paste a command into a terminal because a web page told you to. Jamf's guidance is exactly that, and it is the entire initial access vector for the macOS half.
  • Stop treating macOS as the safe platform. AmnesiaStealer is the third infostealer family reusing the same delivery template.