Scattered Spider's SIM-swap to cloud takeover: why SMS MFA is not a second factor
Scattered Spider SIM-swaps a privileged user's phone number, intercepts the SMS one-time code, signs into the identity provider, and federates into the cloud console to mass-exfiltrate. The MFA-satisfied login is the compromise, and a password reset with a new SMS code just hands the attacker the new code. Here is how it works and how to contain it.
The privileged account signed in with MFA satisfied, and it was the attacker. Nothing was cracked and no prompt was bombed. The phone number itself was moved to a SIM the attacker controls, so the SMS one-time code went to them. This is Scattered Spider’s SIM-swap play, and it turns a second factor that most teams still trust into a factor the attacker holds.
How it works
The actor targets a high-value identity and defeats its second factor at the carrier, not at the login page. They social-engineer the mobile carrier (or the help desk) into porting the user’s number to a SIM they control. The user’s own device silently loses service, and every SMS and voice code for that account now arrives on the attacker’s phone. With the intercepted one-time code, the actor signs into the corporate identity provider from their own device. Because the SMS challenge is satisfied, the IdP treats the login as legitimate. From that session the actor federates into the AWS console, assumes a privileged role, and enumerates and pulls large volumes from cloud object storage and databases before staging an extortion demand. This is T1621 (Multi-Factor Authentication Request Generation) defeating the SMS factor, T1078 (Valid Accounts) into T1550 (Use Alternate Authentication Material) for the federated session, and T1530 (Data from Cloud Storage) exfiltrated as T1567 (Exfiltration Over Web Service).
Why it matters
SMS and voice MFA authenticate whoever holds the phone number, not the person the number belongs to. For a high-value identity, that makes them not a real second factor: a SIM-swap or a carrier port-out silently defeats them, and the result is a normal-looking, MFA-satisfied login. The non-obvious failure comes next. The reflex response to a compromised account is to reset the password and re-send a one-time code so the user can confirm it was them. Here that reflex actively helps the attacker, because the new SMS code goes to the swapped SIM. The password was never the control that failed, and rotating it changes nothing while the phone number is still in the attacker’s hands and the console session is still live.
How to detect it
The sign-in looks clean, because the SMS challenge really was satisfied. The tell is corroboration around it. Watch for a privileged sign-in from a new device and ASN with SMS MFA satisfied, arriving minutes after the user reports losing cellular service, followed immediately by federation into the cloud console and a privileged role assumption. In the cloud logs, the signature is an AssumeRoleWithSAML from that IdP session, then a privileged AssumeRole, then bulk ListBuckets and GetObject or snapshot sharing in a tight window. A lost-service report from the real user next to a new-device SMS login is the strongest single indicator that the factor was defeated rather than passed.
How to contain and shut it down
Contain in order, and treat SMS as defeated the moment you suspect a swap. Revoke the account’s active IdP sessions and cloud console and federation tokens first, a sign-out-everywhere, so the live session stops working. That, not a password reset, is what evicts the attacker. Rotate the federated and console credentials the identity used so a replay or a fresh code cannot re-enter, then re-enroll the account on phishing-resistant MFA (FIDO2) so the swapped SIM authenticates nothing. Do not reset the password and send a new SMS code, because that code goes to the attacker. Scope the damage from the authoritative logs: pivot on the IdP session, enumerate every API the federated role made in CloudTrail, and use VPC flow and proxy logs to prove the exact objects and volume that left. The durable fix is to remove SMS and voice MFA for privileged users and require phishing-resistant MFA, then add carrier-level SIM-swap and port-out protections and tighten help-desk identity proofing so the swap is harder to pull off in the first place. Scope cloud federation with short-lived, just-in-time roles so a single stolen session reaches less.
Practice it
GraphLattice Range runs exactly this incident: a SIM-swap that defeats SMS MFA, an MFA-satisfied IdP login that federates into the cloud console, mass exfiltration from cloud stores, and the session and token revocation that actually contains it. Teams learn why SMS is not a second factor for a privileged identity, why a password reset and a new code help the attacker, and how to lead with session and token revocation and a move to FIDO2.