According to Mandiant on 13 June 2024, UNC3944 (Scattered Spider) socially engineered corporate helpdesks with pre-held victim PII, claimed a new phone, and obtained privileged password resets plus MFA re-enrollment onto attacker-controlled factors. That credential-phase recovery path is what phishing-proof MFA 2.0 closes: no transferable TAP, OTP, SMS code, push, or recovery secret for IT to read out, and new-device binding that requires an already-enrolled device. Closing the phishable recovery stops this path. Malware or console abuse after an attacker session already exists is a harder, separate problem. For the full attack-chain narrative, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA 2.0 have stopped UNC3944's helpdesk MFA reset?
Yes, for the documented initial access. Mandiant reported that UNC3944 operators called service desks, already held PII such as SSN last four, date of birth, and manager names or titles, claimed a new phone, and obtained password resets plus MFA re-enrollment onto attacker-controlled factors. Mandiant stated that by interacting with service desk administrators, UNC3944 could reset passwords for privileged accounts and bypass associated MFA protections. Phishing-proof MFA 2.0 treats helpdesk recovery and coached fake login as the same social-engineering class: both coach a transferable factor. With device-bound enrollment, there is no phishable factor for the desk to re-issue, and adding a device requires an already-enrolled device rather than a verbal reset. OTP, SMS, push, and helpdesk-rebindable authenticators fail that test. Public reporting does not name a reverse-proxy AiTM kit or device-code flow as the engine of this Mandiant pattern.
How is MFA 2.0 stronger than passkeys alone against Scattered Spider recovery abuse?
Passkeys are phishing-resistant at the login ceremony. They harden origin-bound authentication once a legitimate factor already exists. They do not automatically protect enrollment, device onboarding, or helpdesk recovery if those stages still accept email OTP, SMS, push, or verbal proofing. UNC3944's path was recovery first: re-bind MFA, then sign in as the user. MFA 2.0 is phishing-proof across the identity lifecycle, registration through decommissioning, so the helpdesk cannot silently hand the attacker a new factor. That ladder matters here: password and OTP sit below phishing-resistant login, and phishing-proof coverage closes the re-enrollment gap Scattered Spider used. The same industrial class later showed up when a helpdesk was talked into a password reset alone, as in the M&S helpdesk recovery case.
Once Okta issued SSO sessions to UNC3944, does login MFA still help?
No. After attacker-controlled password and MFA recovery succeeded and Okta issued SSO sessions, login-time MFA had nothing left to evaluate. Mandiant described Okta permissions abuse in which a compromised account self-assigned itself to every application in the tenant, then authenticated sessions were used toward environments such as vCenter, CyberArk, Salesforce, Azure, AWS, GCP, and security consoles, including API key creation and Real Time Response-style paths where available. Data left via sync tooling to attacker cloud storage. Public reporting does not establish that every listed console was hit at every victim, and it does not publish aggregate record counts. Prevention value for this campaign is entirely upstream at recovery and first-factor binding. Revoke and short lifetimes remain hygiene after a session already exists; they are not a substitute for closing the phishable helpdesk path.
How should CISOs redesign helpdesk recovery to block this Okta blast radius?
Require recovery that cannot be completed from a phone call alone. Identity proofing that accepts SSN last four, DOB, and manager titles is attacker-usable once PII leaks. Prefer prevention-focused architecture where re-enrollment demands possession of an already-enrolled device-bound key, with no SMS, email code, push approval, or Temporary Access Pass the desk can read out. Classic SSO issues one replayable multi-app ticket after that fraudulent login. Secure Explicit Sign-On keeps one-tap UX while authenticating each app with a fresh device-bound signature, so a single fraudulently issued cloud session is not a skeleton key across mail, files, CRM, vault, and admin consoles. Device-bound keys do not by themselves fix overly permissive Okta admin roles or hypervisor rights once a session exists; those are residual authorization and infrastructure controls.
Does device-bound MFA stop UNC3944 VM persistence after identity compromise?
No. Mandiant described later moves such as new VMs via vSphere or Azure admin paths, PCUnlocker-style local admin resets, CyberArk enumeration, and tooling that opened routes around normal VPN gates. Those steps sit after the identity compromise. Phishing-proof recovery prevents the helpdesk from minting the attacker-controlled IdP login that unlocked those admin paths. It does not revoke hypervisor, vault, or API sessions already granted under a compromised identity. Closing the phishable recovery is the prevention claim. Endpoint malware, admin console abuse, and infrastructure persistence after a session already exists remain harder, separate problems.
