Two pieces of research landed on August 13 from teams with no obvious connection to each other. One was offensive tooling from a red-team research shop. The other was a Rust infostealer found in the wild on macOS. They describe the same idea, and it is the idea worth taking away from this week.
Stop trying to steal the credential. Take the session that already exists.
SpecterOps published Return of the Cookie Monster, detailing a technique that switches on the Chrome DevTools Protocol inside a running Chrome or Edge process on Windows. The same day, Jamf Threat Labs disclosed AmnesiaStealer, macOS malware distributed through counterfeit GitHub pages that — after harvesting the usual cookies and login data from 16 Chromium-family browsers — drops a second stage that drives the victim's live browser over that same protocol.
Neither exploits a browser vulnerability. There is no CVE to track, no patch to schedule, and nothing for a vulnerability scanner to flag.
For three years the industry's answer to cookie theft has been to make stolen cookies useless somewhere else. Chrome's App-Bound Encryption ties cookie decryption to the browser process, so lifting the SQLite database off disk yields ciphertext. Device Bound Session Credentials bind a session to a key held in device hardware, so a replayed cookie on the attacker's machine fails. Chrome 136 tightened remote debugging so that --remote-debugging-port requires a separate --user-data-dir, cutting off the easy path to a profile that is already logged in.
Every one of those controls assumes the attack happens outside the browser. The technique SpecterOps documents happens inside it. Once CDP is live in the real browser process, the operator is not decrypting anything or replaying anything — they are asking the authenticated browser to act on their behalf, and it does, because from the browser's perspective nothing unusual is being asked. Storage.getCookies returns cookies already decrypted. History, bookmarks, extensions and saved passwords come back through the browser's own workflows. And browser-takeover opens a live screencast or proxies HTTP requests through the authenticated session.
SpecterOps is careful about the boundary, and so should we be: the technique does not extract the DBSC private key. It sidesteps the need for one. As the researchers put it, protections like ABE and device-bound cookies "do not remove the value of an authenticated browser to adversaries."
Jamf's description of AmnesiaStealer's remote_stream command reaches the same conclusion from the other direction — an infected host becomes a live, operator-driven browser running the victim's authenticated sessions, which they call a materially different level of access from file collection. That is the phrase to sit with. Not stolen files. Stolen presence.
MFA is irrelevant to all of this, because MFA already happened. The user passed it this morning.
This is post-exploitation. The CDP technique needs prior code execution on the host and enough privilege to inject into the browser process; AmnesiaStealer needs a user to paste a Base64 command into Terminal after a ClickFix prompt. That genuinely narrows the scenario compared to a remotely exploitable browser flaw, and anyone reporting this as "Chrome is broken" is reporting it wrong.
But "attacker already has code execution on one endpoint" is not an exotic precondition — it is the assumed starting state of every ransomware playbook and most espionage intrusions. What has changed is what that foothold is now worth. The old answer was: credentials in memory, files on disk, lateral movement to earn. The new answer includes every SaaS application the user is currently signed in to, at their privilege level, through their own session, from their own device — arriving in whatever system logs it as normal activity by a legitimate user.
Detection sits at the injection, not the access. SpecterOps points defenders at Sysmon Event ID 8 (CreateRemoteThread) and Event ID 10 (ProcessAccess) with access mask 0x143a against chrome.exe and msedge.exe. Worth noting that this is exactly the class of host telemetry that most organisations either do not collect or do not correlate — the same gap we wrote about after the vCenter campaign, where the persistence mechanism was visible only to teams actually watching the host.
Google has been saying the quiet part for over a year: since App-Bound Encryption shipped, it has observed an increase in attackers using Chrome Remote Debugging to extract cookies. Harden one path and the traffic moves to the next one.
Now ask which authenticated session on a typical employee's machine is worth the most in August 2026.
It used to be webmail or the SSO portal. Both are still valuable, and both are at least inventoried — someone owns them, someone reviews their logs, someone gets an alert on an anomalous login.
Increasingly the richest tab is a personal AI account. Not because the model is sensitive, but because of what has accumulated underneath it: months of conversation history, uploaded contracts and spreadsheets and source files, saved projects containing an employee's actual working context, and — with growing frequency — connectors wired into Drive, GitHub, Slack or a ticketing system. An operator with live control of that session does not need to exfiltrate anything cleverly. They can scroll.
We covered the scale of this a week ago: IBM's 2026 report put shadow AI in 43% of breaches, with 92% of AI-related breaches occurring where no AI access controls existed. Read that alongside this week's disclosures and the two stories fuse into one. A consumer AI account is an unmanaged, high-value, credential-free-to-the-attacker data store, reachable through a technique that defeats the browser's strongest session protections, sitting on an endpoint your EDR may or may not be watching closely.
And here is the part that should bother a security leader most: if it happened on Tuesday, would anyone know? An organisation cannot log a system it does not have a tenant in. There is no admin console, no access record, no export, no retention setting. The post-incident question — what did the attacker read, and how much of it was ours — has no owner and no data source.
Be clear about what this does and does not solve, because overselling it would be the wrong lesson. Nothing at the AI layer stops browser session hijacking. That is an endpoint problem, and the fixes are endpoint fixes: injection telemetry, EDR tuning, application allow-listing, and user resistance to ClickFix prompts. Any vendor telling you otherwise this week is selling you something.
What you can decide in advance is where your organisation's AI conversations live when an endpoint does fall — and whether the aftermath is answerable.
That is the job Obichat does. It is a managed multi-model chat workspace that runs in your own tenant — SaaS on Obiguard-managed infrastructure or a private deployment inside your AWS, Azure or GCP account — so the AI work that would otherwise accumulate in personal consumer accounts sits somewhere your security team actually has standing.
Three things change as a result.
The session belongs to your identity provider. Obichat authenticates through SAML or OIDC — Okta, Azure AD, or whatever you already run — so AI access inherits your conditional access, session lifetime, and revocation. A compromised endpoint is a bad day either way, but "disable the user in Okta and every AI session dies with it" is a lever that simply does not exist for an employee's personal ChatGPT login. Today, that account survives offboarding, let alone incident response.
The blast radius is bounded before the incident. Every team gets a workspace with its own connected providers and model allow-list, and every message passes through Obiguard's inspection layer under the policy set assigned to that workspace — redaction of sensitive data, block-lists, and jailbreak detection applied before a prompt leaves your network. An operator riding a hijacked session into a governed workspace is constrained by the same rules the legitimate user is, rather than inheriting an unbounded account.
The aftermath is a query. Security and compliance get an exportable activity log of conversations and events for every workspace, with controls mapped to NIST AI RMF and ISO/IEC 42001. That converts "what did they see?" from an unanswerable question into a report with a date range on it — which is what a regulator, a cyber insurer, and your own board will ask for, and what no consumer AI account will ever produce.
For the endpoint half of this — the Sysmon 8 and 10 events that are the only place the injection is visible — Obiguard SOC ingests host telemetry through any Splunk HEC-compatible forwarder and OpenTelemetry, correlates it into incidents with a full evidence timeline, and needs no detection rules authored first.
There is no patch for this week's research, and that is precisely the point. The controls that matter are the ones you put in place before an endpoint falls: where the sensitive work lives, whose identity governs it, and what record it leaves. Explore Obichat or talk to us about moving your organisation's AI conversations somewhere you can actually audit them.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →