Most incident responders spend the first hour of a breach looking for the malware. With Scattered Spider, there often isn't any. The attacker logged in — with a real account, through your real identity provider, after a real phone call to your real help desk.
Nation-state groups like the APT31 campaign we dissected earlier get the headlines for their custom loaders and novel C2. But if you run detection engineering for a large enterprise in 2026, the actor most likely to actually ruin your quarter isn't writing bespoke malware. It's a loose, English-speaking, financially motivated collective tracked as Scattered Spider — and its entire tradecraft is built around never needing an implant at all.
Who they are
Scattered Spider is the community name for an eCrime cluster also tracked as UNC3944 (Mandiant/Google), Octo Tempest (Microsoft), Scatter Swine, and Muddled Libra. Unlike a monolithic state APT, it behaves more like a fluid group of affiliates — young, native English speakers with deep familiarity with Western corporate IT and help-desk workflows. That fluency is the weapon: they don't need to defeat your EDR if they can convince your service desk to reset an MFA factor.
They are best known for high-impact intrusions across telecom, business-process outsourcing (BPO), hospitality and casinos, insurance, retail, and aviation, frequently pairing with ransomware-as-a-service operations — historically ALPHV/BlackCat, and later other RaaS brands — to monetise access through data theft, extortion, and ESXi encryption. CISA and the FBI documented the pattern in advisory AA23-320A; Microsoft's Octo Tempest reporting covers the same ground from the identity-provider side.
The intrusion, step by step
What makes Scattered Spider worth studying for a purple team is how ordinary every step looks in isolation. There is no exploit, no dropper, no beacon. There is a sequence of legitimate identity operations performed by an illegitimate operator.
1 · Get in through a human, not a vulnerability
The entry point is almost always the help desk. An operator calls (vishing) or SMS-phishes (smishing) an employee or the IT desk itself, impersonating a locked-out user — often armed with real personal details harvested beforehand. The ask is simple: reset my password, or register a new MFA device. When self-service or a rushed agent complies, the attacker owns a valid identity. Where phone-based MFA is in play, a SIM swap against the carrier achieves the same thing.
2 · Defeat MFA without breaking it
If credentials are valid but MFA blocks the login, they don't crack it — they wear it down. MFA fatigue (push bombing) floods the victim with approval prompts until one is accepted; alternatively they socially engineer the help desk into enrolling an attacker-controlled authenticator. Either way, the second factor becomes theirs, and every subsequent login is clean.
3 · Pivot in the identity plane
With a foothold identity, the objective is the identity provider itself — Okta, Entra ID (Azure AD), or the on-prem AD that federates to them. From there they enumerate the tenant, register devices, grant themselves roles, steal session cookies to bypass MFA entirely on the next hop, and move laterally across SaaS and cloud. Reconnaissance happens through legitimate admin consoles and PowerShell, not tooling that trips a signature.
4 · Persist with your own tools
Rather than a custom implant, they deploy legitimate remote-access software — AnyDesk, TeamViewer, Splashtop, and similar RMM agents — which sails past application allow-lists because it's signed, common, and often already in the environment. This is living-off-the-land in the truest sense.
5 · Steal, extort, and encrypt
The endgame is money. They exfiltrate data from SharePoint/OneDrive, code repos, and cloud storage for extortion, and — when they escalate to ransomware — frequently target VMware ESXi hosts directly, encrypting the hypervisor layer to take down dozens of VMs at once with a single action.
Mapping it to MITRE ATT&CK
Every step maps cleanly to ATT&CK — which is exactly why it's emulatable. Note how little of this touches the endpoint's malware surface:
| Stage | Technique | ATT&CK ID |
|---|---|---|
| Recon on the target user | Phishing for Information (vishing/smishing) | T1598 |
| Help-desk / user phish | Phishing | T1566 |
| SIM swap | SIM Card Swap | T1451 |
| Push bombing | MFA Request Generation | T1621 |
| Enroll attacker MFA / device | Modify Auth Process: MFA · Account Manipulation: Device Registration | T1556.006 · T1098.005 |
| Login as the user | Valid Accounts: Cloud Accounts | T1078.004 |
| Bypass MFA on the next hop | Steal Web Session Cookie | T1539 |
| Persistence / hands-on-keyboard | Remote Access Software | T1219 |
| Collection & exfiltration | Data from Cloud Storage · Exfil to Cloud | T1530 · T1567 |
| Ransomware (ESXi) | Data Encrypted for Impact | T1486 |
Why your EDR stays quiet
Malware-centric detection is built to answer "did something bad run on this host?" Scattered Spider's answer is: nothing did. There's no process injection to catch, no unsigned binary, no C2 beacon on the wire. The malicious signal has moved off the endpoint entirely and into the identity plane — sign-in logs, MFA events, help-desk tickets, device registrations, cookie theft, OAuth grants. A SOC that only watches endpoints is structurally blind to the whole kill chain.
The telemetry that does catch it looks mundane until you correlate it:
- Entra ID / Okta sign-in logs — impossible travel, logins from residential VPNs or new ASNs, a burst of failed MFA prompts followed by a success (push-bombing signature).
- Identity audit logs — a new MFA method registered (
Add registered security info/ Oktauser.mfa.factor.update), a new device joined, a role or group added shortly after login. - Help-desk / ITSM records — password or MFA resets that don't match a corresponding user request; correlate the ticket to the sign-in.
- RMM install / execution — AnyDesk/TeamViewer/Splashtop appearing on a host or account that has no business running it.
- Mass cloud download — abnormal SharePoint/OneDrive/S3 read volume from a freshly-accessed identity, and ESXi shell /
vim-cmdactivity out of nowhere.
This is the layer that Microsoft Defender for Identity, Entra ID Protection, Okta ThreatInsight, and identity-aware EDR live in. The problem is rarely that the events don't exist — it's that nobody wrote the correlation rule, or the identity logs never made it into the SIEM. That gap between "the log fired" and "an alert fired" is precisely what a purple-team exercise is meant to expose.
Emulating Scattered Spider in Cyllex
Scattered Spider ships as one of Cyllex's built-in, campaign-ready threat profiles. Instead of reading about the chain, you run it against your own lab and read the verdict: which steps your detections caught, which came back partial, and which sailed through silently.
The purple-team loop for an identity actor:
1. Launch the Scattered Spider profile as a phased campaign — valid-account abuse, cloud/identity techniques, MFA-related analysis, collection and exfiltration, staged in the order a real intrusion follows.
2. The destructive tail (ESXi/ransomware-style impact) runs as a gated simulation — Cyllex marks dangerous operations safe_to_run: false so you exercise the detection path without the blast radius.
3. Correlate the run against your SIEM/EDR — for this actor, Microsoft Sentinel and Defender for Endpoint carry most of the weight, since the signal is identity, not malware.
4. Read the report: every technique comes back Detected, Partial, or NotDetected, rolled up by tactic. The red band is your identity-detection gap — and now you can prove it's closed after you fix it.
Because Cyllex correlates by MITRE technique, an emulated T1078.004 valid-account login or T1621 MFA-request burst is matched to whatever alert (if any) your identity tooling produced — turning "we think we'd catch Scattered Spider" into an evidenced yes or no.
What actually stops them
The defensive lesson mirrors the offensive one: if the intrusion is identity-first, so is the defense.
- Harden the help desk. Out-of-band identity verification for password/MFA resets is the single highest-leverage control — the entire chain starts there.
- Go phishing-resistant. FIDO2 / hardware security keys neutralise both push bombing and cookie theft in a way that OTP and push MFA cannot.
- Alert on MFA/device registration events, not just failed logins — a new factor enrolled from a new location is the tell.
- Watch the identity plane in the SIEM. Make sure Entra/Okta sign-in and audit logs are ingested and correlated — then validate those detections fire, rather than assuming they do.
- Lock down ESXi and treat the hypervisor as tier-0.
You don't find out whether you'd catch an identity-first actor by reading their CISA advisory. You find out by running the chain in your own environment and watching what your detections say. That's the whole point of purple teaming — and the whole point of Cyllex.
Sources: CISA/FBI advisory AA23-320A (Scattered Spider); Microsoft Security (Octo Tempest); Mandiant/Google (UNC3944); MITRE ATT&CK Groups. Technique IDs verified against the current ATT&CK enterprise and mobile matrices.