Scattered Spider helpdesk MFA reset Okta SaaS attack

According to [Mandiant](https://cloud.google.com/blog/topics/threat-intelligence/unc3944-targets-saas-applications) on 13 June 2024, UNC3944 (Scattered Spider, 0ktapus, Octo Tempest, Scatter Swine) called corporate service desks with victim PII, claimed a new phone, and obtained privileged password resets plus MFA re-enrollment. Operators then authenticated through Okta, self-assigned broad app access, and moved through SaaS for data theft. Public reporting does not name the Mandiant IR customers or publish record counts.

Mandiant’s write-up is a campaign TTP, not a single named filing. Callers already held details such as SSN last four, date of birth, and manager names or titles, which was enough to pass many helpdesk identity checks. SMS phishing ran alongside the calls; public reporting does not quantify the split. The same industrial class shows up when a helpdesk is talked into a password reset alone, as in the later M&S helpdesk password-reset case: live coaching of a transferable recovery path, not a clever OTP math problem.

If you want the prevention angle, read the related article on mfa2point0.com.

FAQ

How did UNC3944 get past workforce MFA?

UNC3944 got past workforce MFA by socially engineering the helpdesk recovery path, not by beating a live login ceremony in Mandiant’s primary write-up. According to Mandiant on 13 June 2024, operators called service desks, already possessed victim PII to clear identity verification, claimed they were receiving 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. That is the same attack class as coaching a user through a fake login: both hand the attacker a usable factor. Legacy MFA then treated the post-reset sign-in as a normal user.

What did Scattered Spider do after the helpdesk MFA reset?

After the helpdesk MFA reset, Scattered Spider (UNC3944) authenticated through Okta and SSO, then expanded reach across SaaS. Mandiant reported Okta permissions abuse in which a compromised account self-assigned itself to every application in the Okta instance, which widened SSO app-tile access. Authenticated sessions were used toward environments such as vCenter, CyberArk, Salesforce, Azure, AWS, GCP, and security consoles, including paths that created API keys or used Real Time Response-style access 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 or ransom figures.

Was the Mandiant UNC3944 SaaS pattern an AiTM phishing kit?

No. Public reporting in Mandiant’s 13 June 2024 UNC3944 SaaS write-up does not name an adversary-in-the-middle reverse-proxy kit or a device-code flow as the engine of this pattern. The documented initial access is helpdesk social engineering with pre-held PII, password reset, and MFA re-enrollment, followed by Okta/SSO abuse. SMS phishing campaigns were also observed beside the call-center work. If your incident notes only “social engineering” with no TAP, spoofed page, or proxy detail, keep the mechanism unnamed for that victim and treat the two industrial vishing paths as architecture risk, not as a confirmed fact about a named company.

Once UNC3944 held Okta SSO sessions, could login MFA still stop the theft?

No. Once UNC3944 completed attacker-controlled password and MFA recovery and Okta issued SSO sessions, login-time MFA had nothing left to evaluate. Session use, API keys, console commands, vault enumeration, and sync-tool exfiltration are post-authentication abuse. Mandiant also described later infrastructure moves such as new VMs via vSphere or Azure admin paths, PCUnlocker-style local admin resets, and tooling that opened routes around normal VPN gates. Those steps sit after identity compromise. Closing the phishable recovery path stops this path. Malware or admin abuse after a session already exists is a harder, separate problem. A fix that hardens enrollment and recovery exists; the companion prevention post covers it without turning revoke-and-detect into the main story.

Why did one helpdesk call unlock so many SaaS apps?

One helpdesk call unlocked many SaaS apps because Okta/SSO turned a single reset identity into a multi-app ticket. After UNC3944 held a working password and attacker-bound MFA, federation did not re-prove the human at each app boundary. Self-assignment of the compromised account to every application in the tenant made the blast radius intentional and wide. That design fails a never-trust, always-verify reading of access: one stolen or fraudulently issued cloud session becomes a skeleton key across mail, files, CRM, vault, and admin consoles until someone revokes it. Public reporting does not establish per-customer app inventories.