- › Jamf found a module in AmnesiaStealer that clones the victim's Chromium profile, runs it headless on their Mac, and lets an operator drive it live at about three frames per second.
- › The cloned profile carries the existing authentication tokens and keeps the browser, host, and network identifiers, so device trust and impossible-travel rules see a normal session.
- › Multi-factor authentication already ran. The attacker arrived after it, which is why resetting the password accomplishes nothing on its own.
- › The control that ends this is session revocation, and most teams have never tested whether theirs terminates an active session.
- › Write session termination into your credential-compromise runbook as a separate step, because a password reset is not one.
Your help desk gets the call at 9:40 on a Monday. Somebody clicked something over the weekend, there was a terminal window involved, and they are not sure what it did. The technician does what the runbook says: force a password reset, re-enrol multi-factor authentication, run a scan.
By 9:55 the account has a new password and the attacker has not noticed, because they were never using the password.
What Jamf Actually Found
Researchers at Jamf documented a module in the AmnesiaStealer malware that goes well past collecting files. The malware duplicates the victim’s Chromium profile, launches that copy in headless mode on the infected Mac, and opens two WebSocket connections: one to the attacker’s relay server, one to the Chrome DevTools Protocol running locally.
That second connection is the whole trick. DevTools Protocol is the interface a developer uses to drive a browser programmatically, and it is built into the browser. The operator navigates, clicks, types, and watches a live screencast at roughly three frames per second (BleepingComputer).
Jamf’s own description is worth sitting with: it turns an infected host into a live, operator-driven browser running the victim’s authenticated sessions, which is a materially different level of access from file collection.
Why the cloned profile is the point
A browser profile holds more than bookmarks and history. It carries the session cookies and authentication tokens your applications issue after a successful login, which is what keeps a user signed in for the next thirty days without re-entering anything.
Copy that profile and you copy the proof of a login that already happened. The attacker never authenticates. They inherit an authentication.
And because the cloned browser runs on the victim’s own machine, the identifiers your detection stack scores on all match: the same device fingerprint, the same host, the same source address, the same user agent, the same network. Everything a conditional access policy looks at says this is the right person on the right laptop in the right city.
Every Control You Bought Runs Before This Moment
Put yourself in the shoes of your identity provider for a second. It sees a login attempt, checks the password, prompts for the second factor, evaluates the device, evaluates the location, and issues a token. It has done its entire job correctly.
The attack starts after that. There is no login event to inspect, no anomalous location, no failed factor, no new device to challenge. From the identity system’s point of view nothing is happening at all, because the session it issued is being used.
That is the shape of the problem, and it is why the response most organizations run does nothing.
The password reset
Changing the password invalidates the password. On most platforms it does not, on its own, terminate sessions that were already established. The attacker’s cloned profile keeps working with the token it already holds, and it keeps working until that token expires on its own schedule.
Go look up your session lifetime. If your refresh tokens are good for 30 or 90 days, and your malware ran on a Friday, you have handed somebody three months of access that a Monday password reset did not touch.
The multi-factor re-enrolment
Re-enrolling the second factor protects the next login. It has no effect on the current session, for the same reason. You are hardening a door the intruder already walked through.
The impossible-travel rule
Impossible travel fires when the same account signs in from Phoenix and then from Bucharest forty minutes later. Here, both sessions originate from the same laptop in Phoenix, because one of them is that laptop. The rule is working correctly and has nothing to fire on.
What Actually Ends It
The control that ends this is session revocation, and it is a different button than the one your help desk is pressing.
Revoke sessions explicitly, as a named step
Every major identity platform can invalidate active sessions and refresh tokens for a user. It is a separate action from a password reset, it usually lives in a different part of the console, and in a lot of organizations nobody has ever clicked it.
Add it to the runbook as its own line, worded so it cannot be skipped. Something like: reset the credential, then revoke all active sessions and refresh tokens, then confirm the revocation took effect by checking that the user has to sign in again.
Test that revocation works before you need it
This is the part I would push hardest on. Sign into an application, then revoke your own sessions from the admin console, then go back to the still-open browser tab and refresh it.
You want to see a login prompt. What you may see instead is the application continuing to work for minutes or hours, because the access token in hand is still inside its validity window and nothing checks the revocation list until it expires. That gap is a configuration you can change, and you will not know you have it until you look.
Shorten the lifetimes that are longer than your detection time
The economics here are straightforward. Your exposure from a stolen session equals how long that session stays valid, and there is a real cost to shortening it, which is user friction from re-authentication.
The useful question is how that number compares to your mean time to detect. If it takes you nine days on average to notice a compromised endpoint and your refresh tokens last 90, then in the common case the attacker holds the session for 81 days after you had any chance of catching them. Bring one number down or the other.
Bind the token to something the attacker cannot clone
Token binding and device-bound session credentials tie a session to a key held in hardware, so a copied profile on the same machine is a harder problem and a copied profile moved to another machine stops working entirely. Support is uneven and it is worth knowing where your critical applications stand, because this is the direction the defense is going.
Hunt for the browser running that you did not start
On the endpoint side, a headless Chromium launched from an unexpected parent process, with a DevTools Protocol port listening and an outbound WebSocket to somewhere unfamiliar, is a fairly specific thing to look for. Ask your endpoint detection vendor whether they alert on it today.
The Runbook Line That Is Missing
Go read your credential-compromise procedure. Right now, before you need it.
If the steps are reset the password, re-enrol multi-factor, scan the endpoint, and notify the user, then your procedure was written for an attacker who steals credentials and uses them to log in. That attacker still exists. They are no longer the only one, and the passkey research from earlier this month made the same point from a different angle: authentication strength does not help against code already running on the machine.
Every one of these techniques shares a starting condition. Something is executing on the endpoint. That is also where ClickFix convinces a capable person to run the command themselves, which is exactly how AmnesiaStealer gets there.
A key that has been copied does not care that you changed the lock. You have to close the door it already opened.
Does your credential-compromise runbook have a session revocation step, and has anyone tested it? Contact Grab The Axe for an assessment, or start with our free Human Attack Surface Score.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
