We had MFA and passkeys, and still lost the account

The short version

A stolen session cookie is a valid, already-authenticated session. The attacker does not need the password, does not need the second factor, and does not need the passkey. They import the cookie into their own browser and they are you.

This matters because the standard advice, "turn on MFA", is aimed at the login step, and this attack does not use the login step. We have seen accounts protected by TOTP and passkeys taken over this way. The controls were working exactly as designed. They were simply guarding a door the attacker never walked through.

The chain

The initial access technique currently doing the rounds is ClickFix: a page tells the visitor that something is broken and that the fix is to paste a command into the Windows Run dialog or a terminal. Sometimes it is framed as a CAPTCHA ("verify you are human"), sometimes as a video codec or font that needs installing. The victim runs the command themselves, so there is no exploit, no malicious attachment, and nothing for a mail filter to catch.

flowchart TD
    A["Lure page<br/>fake CAPTCHA / 'fix this error'"] --> B["Victim pastes command<br/>into Run dialog or terminal"]
    B --> C["PowerShell downloads<br/>and runs loader"]
    C --> D["Infostealer executes<br/>in the user's own session"]
    D --> E["Harvests browser cookies,<br/>tokens, saved credentials"]
    E --> F["Cookies exfiltrated<br/>to attacker infrastructure"]
    F --> G["Attacker imports cookies<br/>into their own browser"]
    G --> H["Authenticated as the victim<br/>MFA and passkeys never invoked"]
    H --> I["Adds own device / email,<br/>removes victim's access"]

The critical step is the last one. Once inside, the attacker does not sit quietly. They add their own recovery email or device, change the admin set, and lock the legitimate owner out. From the platform's point of view every one of those actions came from an authenticated session, which is precisely why automated appeals so often fail: there is no anomaly to detect in the data the platform is looking at.

Why the usual advice misses

"Enable MFA." Protects the login. The attacker skips the login.

"Use passkeys or FIDO2." Genuinely excellent, and worth doing. It makes credential phishing largely pointless, because there is no shared secret to steal. It does nothing about a cookie lifted after a successful authentication.

"Use a password manager." Helps against reuse and phishing. Infostealers specifically target password manager artefacts and browser stores.

None of that is an argument against those controls. They stop other, more common attacks and you should have all of them. The point is narrower: do not assume they cover this one.

What actually helps

Roughly in order of effectiveness for this specific threat:

1. Device-bound sessions. Chrome's Device Bound Session Credentials tie a session to a key held by the device's TPM. A cookie copied to another machine is inert. This is the first control that addresses the root cause rather than the symptom. Enable it where the platform supports it.
2. Do not run the payload. The whole chain begins with a human pasting a command. No legitimate site has ever asked you to paste something into the Run dialog to prove you are human. This is worth saying plainly and repeatedly to every staff member with account access, because it is the only step where the defence is free.
3. Short sessions and step-up authentication. Re-authenticate before high-impact actions: changing admin roles, adding recovery methods, moving money. A stolen cookie then buys far less.
4. Separate the admin identity. The account that administers a company page should not be the account used for daily browsing. Compromise of a browsing session should not be compromise of the business asset.
5. Reduce the blast radius. Review who holds admin. A page whose only administrator is one personal account is one stolen cookie away from being unrecoverable.
6. Endpoint detection. The loader stage is noisy: a browser spawning PowerShell which reaches out to fetch and execute code is a strong signal. This is what endpoint tooling is for.
7. Session review. Most platforms list active sessions and login locations. Check them, and turn on login alerts.

If it has already happened

Move fast, and assume the credential material is gone rather than merely exposed:

• Invalidate every session on the affected accounts, not just the one you can see. "Log out of all devices" exists for this.
• Rotate anything the browser held. Saved passwords, API tokens, OAuth grants. Treat the whole browser profile as compromised, because it is.
• Check what else used that identity as a login. Social accounts are often the recovery path or the single sign-on for a long tail of other services. That secondary exposure is usually larger than the account itself.
• Download your data while you still have any access at all. Platform data exports also record the attacker's activity, including devices and locations, which is useful evidence.
• Report it properly. For a business asset, go through the platform's business support channel rather than the automated consumer appeal, which is where these cases tend to die.

The uncomfortable part

Recovery from social platform takeover is genuinely difficult, and the automated appeal process is not built for a case where every hostile action came from a valid session. Plan on the assumption that you may not get the account back. That changes the calculus: the effort belongs on the controls above, before anything happens, rather than on a recovery process you do not control.

If your business runs paid advertising or customer communication through a social platform, that account is production infrastructure. It deserves the same treatment as any other production system: named owners, separate admin identities, reviewed access, and a plan for what happens when it is lost.

Sources

• FortiGuard Labs, From ClickFix to Command: A Full PowerShell Attack Chain — technical breakdown of the loader and the PowerShell stages.
• Google Chrome Security, Device Bound Session Credentials — the session-binding mechanism described above.

Adminor works with attack surface monitoring and security testing. If you want a review of how your organisation's business-critical accounts are protected, get in touch.