A Chrome extension marketed as a trading tool, promoted through a social media campaign, collected browser cookies from the machines it was installed on.
Among those cookies were session tokens for logged-in exchange accounts.
A session token is proof that an authentication has already succeeded. Presenting it does not require a password, and it does not trigger a two-factor prompt, because from the service's point of view the login already happened.
So the attackers acted as the victim. Withdrawals were still blocked by two-factor authentication, so they used the same move as the course autopsy: leveraged trades and orders in low-liquidity pairs, moving prices in their own favour.
One trader reported noticing about $70,000 of losses in February, and on 24 May opened the app to check a price and found the account trading on its own. Total reported losses around $1M.
Now the part that should be uncomfortable.
The victim installed the extension deliberately, and granted it exactly the access it asked for, which is the access a browser extension routinely holds.
Nothing was phished. No device was exploited. No credential was guessed.
The compromise happened at a layer below authentication, which is precisely why nothing the victim had configured for authentication made any difference.
F109-02 covered credentials that bypass the login by design. This lesson covers credentials that bypass it by accident, and they are sitting on your machine right now.
What a session is
When you log in, the service does not ask again on every click. It issues a token, stored by your browser or your application, and your device presents it with each request.
That token is portable proof of a past authentication. Copy it to another machine and that machine is you, until it expires or is revoked.
Which produces the property that makes this lesson necessary:
A stolen session bypasses every authentication control, because authentication already succeeded. Your password is not asked for. Your two-factor code is not requested. Your hardware key, which F107-03 correctly ranked first, is never consulted, because it protects the door and the attacker came through a window that opens from the inside.
This is not a flaw peculiar to crypto. It is how the web works, and F104-01's Connect Kit attacker used a stolen session token to take over an npm account that had two-factor authentication enabled.
Three sources
Browser extensions. The autopsy. An extension with permission to read data on the sites you visit can read your session tokens on those sites. This is the source you installed voluntarily and the only one on this list you explicitly approved.
Infostealer malware. A category of software whose entire purpose is to sweep cookies, saved passwords, and wallet files off a machine and send them onward. Frequently delivered through a downloaded file, and F106-01's pattern 7 is the fake job or paid task that gets you to run one.
The service's own systems, occasionally, which you cannot influence.
Extensions are the problem you can fix
Open your browser's extension list now. Most people have between five and twenty, most were installed for one task, and several have not been opened in a year.
Then look at what each one is allowed to do, which is a different screen from what it appears to do.
The permission that matters is usually phrased as reading and changing data on all sites you visit. An extension holding it can read your exchange session, your wallet's interface, your email, and your bank.
A password manager needs broad page access to do its job. So does a translation tool. So did the extension in the autopsy.
You cannot distinguish them by what they claim to be, and the permission screen is the same for all three.
Worse, the population is not static. Extensions are sold, and they update silently. An extension that was safe when you installed it can be acquired and turned hostile in an update you were never asked about, which is the precise shape of F109-01's Connect Kit and Ronin failures appearing on your own machine.
Which gives the only rule that survives: the extensions you audit are the ones installed today, not the ones you approved. Judge each one on whether you would grant that permission to a stranger this morning, because in effect that is the question.
The practical response is boring and effective. Remove everything you do not actively use, which for most people is half the list. Keep the remainder small enough to name from memory. And for anything financial, use a separate browser profile with no extensions at all, which costs one click to switch and removes the entire category.
Wallet connections are sessions too
The same mechanism, on the wallet side, and it usually gets less attention than approvals.
When you connect a wallet to a site, you grant a persisting relationship. The site can request signatures without a fresh connection, and it holds that connection until you disconnect.
That connection is not an approval and is not a delegation. It grants no spending rights on its own, which is why it is genuinely lower risk than F109-02's keys. What it grants is the ability to keep asking, from a site whose domain may change hands, which is F107-01's Curve autopsy.
Open your wallet's connected-sites list. Most people have never seen it and most lists contain sites they visited once.
Terminate as a routine
The reason this belongs in F109 rather than in an incident-response lesson is that session termination is the cheapest control in the entire course and nobody performs it.
On every venue, find the active sessions or devices screen and terminate everything you do not recognise. Then terminate the ones you do, because logging back in costs you thirty seconds.
In your wallet, disconnect every site you are not currently using.
In your browser, sign out of financial accounts rather than leaving them open indefinitely. An open session is a token sitting on disk.
Do it on a schedule, quarterly, alongside the F109-05 review, and immediately after installing anything, after any device is lent or serviced, and after any incident anywhere in your stack.
And note the property that makes this different from the rest of F109: terminating a session costs you nothing but a login. Revoking an approval costs gas. Rotating an API key costs reconfiguration. There is no reason to be conservative here and no downside to being aggressive.
I log out when I am finished, so I do not have stale sessions.
Logging out of the tab you were using is good and it is not what you assumed it was.
Logging out is often per-device and per-browser. The phone, the second laptop, the machine at work, the browser you used once: each holds its own session and each is unaffected by you logging out somewhere else. This is why venues have a terminate-all-sessions button, and why it is a different button from log out.
Closing a tab is not logging out. Neither is closing the browser, on most services, because the token persists precisely so you do not have to log in again tomorrow.
And the window that matters is not the one you are worried about. The autopsy's extension was reading cookies continuously from a machine the victim used every day. The exposure was not a forgotten session on an old device; it was the live one, on the machine they were sitting at, which no amount of logging out later would have helped.
So the honest hierarchy is: terminating all sessions handles the stale ones and is worth doing quarterly, and the live-session problem is only solved further down the stack, by not having anything on the machine that can read them.
A session token is portable proof that an authentication already succeeded, so a stolen one skips your password, your two-factor authentication and your hardware key without triggering any of them. Sessions are stolen from browser extensions, from infostealer malware, and occasionally from the service, and the first is the one you installed voluntarily and granted exactly the access it asked for. Judge an extension by the permission it holds rather than by what it appears to do, and remember that extensions are sold and updated silently, so the population to audit is the one installed today. Then terminate sessions and disconnect sites quarterly, because it is the only control in this course that costs nothing but a login.