Stop Scattered Spider helpdesk MFA transfer

According to the CISA/FBI joint advisory AA23-320A published 16 November 2023, Scattered Spider targets large companies and contracted IT help desks with password resets, MFA enrollment moved onto attacker devices, repeated push prompts until Accept, carrier SIM swaps that seize SMS MFA, and live coaching to read out one-time codes. Phishing-proof MFA 2.0 hardens recovery and enrollment so a phone call cannot casually re-bind authenticators, removes fatiguable push and SMS factors a carrier can hijack, and leaves no transferable code for a coached employee to speak aloud. Closing that login and recovery surface is prevention. Malware after a legitimate login is a harder, separate problem.

For the full attack-chain narrative CISA documents, read the companion on legacymfa.sucks. The same recovery failure class later showed up when helpdesk password-reset social engineering hit retail workforce identity.

FAQ

Would phishing-proof MFA 2.0 stop Scattered Spider helpdesk MFA transfers?

Yes at the credential and enrollment phase CISA describes. In AA23-320A, actors posed as employees so IT or a contracted helpdesk would reset the password and transfer MFA onto hardware the attacker controlled. That path works when recovery still issues a transferable secret or lets staff re-bind a second factor from weak identity proofing on a call. Phishing-proof MFA 2.0 keeps enrolment and device onboarding free of codes helpdesk can read out or reassign from a phone conversation alone. Adding a device requires an already-enrolled device, not a phishable enrollment secret. Public reporting does not establish a single named victim organization for every intrusion in the advisory.

How does MFA 2.0 kill push fatigue and SIM swap in this TTP set?

MFA 2.0 removes the factors those techniques abuse. CISA documents repeated MFA notification prompts until employees pressed Accept, classic push fatigue, and separate cases where carriers moved a target number to an attacker SIM so MFA prompts followed the new card. Approve-deny spam needs a prompt to fatigue. SMS and voice OTP bind to a phone number a carrier can transfer. Device-bound, origin-bound cryptography has no push to spam and no SMS channel to seize. The private key never leaves the enrolled hardware, so a SIM swap cannot intercept a signature the user never types. That is prevention, not detection: the ceremony those fatigue and SIM paths complete never becomes available.

Are passkeys alone enough against the recovery gap in AA23-320A?

Not if enrollment and helpdesk recovery still use phishable factors. Passkeys and WebAuthn are phishing-resistant at the login ceremony: origin-bound signatures, no reusable secret to type on a fake page. They harden authentication only. If email OTP, SMS, push, or a helpdesk-issued reset can still register a new authenticator, an attacker who wins that recovery step enrolls their own device and later signs requests that look legitimate. MFA 2.0 is phishing-proof across the identity lifecycle (registration, device onboarding, authorisation, authentication, decommissioning). Against Scattered Spider’s documented MFA-transfer TTP, the enrollment policy matters as much as the login cryptography.

What does MFA 2.0 not undo after Scattered Spider gets a foothold?

MFA 2.0 does not revoke sessions, cookies, or RMM access already taken after sign-in succeeds. The advisory’s later stages describe legitimate remote tools such as AnyDesk, TeamViewer, ScreenConnect, and Ngrok, plus stealers and dumpers including Mimikatz, Raccoon, and VIDAR, then data theft for extortion and, in updates, ransomware activity including DragonForce-linked encryption. Those are token and endpoint problems on machines that already hold access. No login MFA undoes memory harvest or a live remote-tool session. Closing the helpdesk reset, fatigue, SIM, and OTP-coaching paths stops the easy identity win. Containment after foothold still needs session revoke, device trust, EDR, and re-auth on sensitive actions. Public reporting does not establish a quantified org count or specific ransom figures for the campaign as a whole.

Is coached OTP handoff the same failure class as helpdesk MFA transfer?

Yes. Talking helpdesk into a password reset and MFA re-bind is the same social-engineering class as talking an employee into reading an OTP, approving a push, or following fake-IT instructions over phone or SMS. Both coach a human into releasing or rebinding a transferable factor. Org-themed SSO, helpdesk, and Okta lookalike domains in the advisory feed the same weak password-plus-legacy-MFA surface. Phishing-proof device-bound MFA collapses both paths the same way: there is no code to recite, no push to accept under pressure, and no recovery secret IT can reassign from a call. Helpdesk vishing and user coaching are one MFA story, not two.