Scattered Spider Simulation | Breacher.ai
Run the Scattered Spider Attack
Before Scattered Spider Runs You.
They do not break your firewall. They call your help desk, impersonate an employee, and talk a human into resetting multi factor authentication. Then they own your identity provider. Breacher.ai reproduces that exact kill chain using OSES, and because the playbook is already built, we deploy it in days, not weeks. This is how you find out whether your people, your process, and your SOC hold before a real operator dials in.
Why Scattered Spider Wins Against Companies That Passed Every Audit
Scattered Spider, tracked across the industry as UNC3944 and Octo Tempest, is not a sophisticated exploit crew. That is exactly what makes them dangerous. They do not need a zero day. They need a phone, a believable story, and a help desk that is measured on how fast it resolves tickets. The organizations they have compromised were not careless. They had endpoint protection, email filtering, and multi factor authentication deployed. The attackers walked straight past all of it by targeting the one control that lives between a human and a keyboard: your identity verification process.
The pattern is consistent. An operator calls the service desk posing as an employee locked out of an account. They have done the reconnaissance, so they can recite the employee ID, the manager name, the recent project. Under time pressure and a convincing story, the help desk resets the password or the MFA enrollment. Minutes later the attacker is authenticated as a real user, inside the identity provider, moving toward data and domain control. No malware tripped a sensor because nothing about the login looked wrong.
Your firewall was never the target. Your help desk was. The question a Scattered Spider simulation answers is simple and uncomfortable: when a convincing stranger calls and asks to reset MFA, does your process stop them, or does it help them?
This is why a standard phishing test tells you nothing useful about your exposure to this group. Counting who clicked a link does not test whether your help desk demands identity proofing under pressure, whether your identity provider alerts on an anomalous reset, or whether your SOC connects a suspicious call to a suspicious login. Those are the controls that decide the outcome, and they are the controls a Scattered Spider simulation is built to exercise.
The Scattered Spider Toolkit We Reproduce
Every technique below is drawn from documented UNC3944 tradecraft and reproduced under strict authorization. We do not improvise. We run the same moves the group runs, in the same order, so what you learn maps directly to how you would actually be attacked.
The signature move. An operator calls IT support impersonating an employee and drives a live MFA or password reset. This single path is responsible for the group's biggest intrusions, and it is the one most service desks are trained to resolve quickly rather than resist. We test whether identity proofing actually happens when a caller pushes back with urgency and a good story.
Repeated authentication prompts fired at a target until a tired or distracted user approves one to make it stop. We measure approval rates across your workforce and the time from first prompt to compromise, then map which teams are most exposed.
Convincing Okta and Microsoft Entra sign in captures delivered through lookalike infrastructure that mirrors the exact patterns seen in real intrusions. We measure who submits credentials and whether the session and token controls behind them hold when they do.
Social engineering aimed at telecom workflows and internal callback procedures to hijack SMS based codes and defeat verification that relies on a phone number. We test the process, not the individual, because the process is what fails.
Synthetic voice of a known internal contact used to defeat callback verification, the escalation Scattered Spider style actors are already field testing. When your verification step is a call back to a familiar voice, we test whether a cloned voice passes it.
Once inside, the group uses legitimate remote access and administration tooling rather than malware, because legitimate tools do not trip antivirus. We stage the same behavior so your endpoint and detection controls are tested against what actually gets used, not against a lab sample.
One Orchestrated Chain, Built on OSES
Individual techniques tested in isolation tell you almost nothing, because Scattered Spider does not attack in isolation. They chain moves together, using each one to make the next more believable. OSES, our Orchestrated Social Engineering Simulations methodology, runs the group's techniques as a single conditional campaign that adapts to how your people respond and reaches the real decision point where process and technology are supposed to intervene. Walk the chain.
We build the persona from real open source intelligence: org chart, active projects, vendor relationships, employee identifiers. A target employee receives a smishing or voice touch that establishes a believable situation. Technology under test: did anything flag the inbound. People under test: did the target treat it as routine.
An operator calls the service desk as the employee, armed with the details gathered in Stage 1, and requests a password or MFA reset. Optional deepfake voice raises the pressure. Process under test: does the help desk demand identity proofing. People under test: does the agent hold the line when the caller pushes.
The agent is asked to perform the reset. This is the layer no click rate test ever reaches. Even if the agent believes the caller completely, the question becomes procedural: is out of band verification required, is a manager callback to a number on file enforced, does policy forbid resetting MFA on a voice request alone. Process under test: does the procedure stop the reset independent of whether the agent was convinced. This single stage decides whether a fooled human becomes a contained incident or a breach.
If the reset proceeds, the chain reaches its objective: a simulated authenticated session and a staged remote access attempt. Technology under test: did the identity provider alert on the anomalous reset and new device, did endpoint controls flag the tooling. And did the SOC correlate Stages 1 through 4 into one incident or log them as unrelated events. Correlation is the difference between catching an attack and catching four things.
A disconnected phishing test stops at Stage 1 and calls it a day. Only an orchestrated chain reaches Stage 3, where your reset policy lives, and Stage 4, where correlation is provable. That is why OSES is what makes a real Scattered Spider test possible.
A Playbook Built for Instant Deployment
Most red teams quote a Scattered Spider engagement as a multi week build. Persona development, infrastructure standup, script writing, tooling, and chain logic all get constructed from zero for every client. That lead time is not caution. It is overhead, and you pay for it. Breacher.ai does not build the attack from scratch. We already built it.
We maintain a productized Scattered Spider playbook: engineered personas, help desk vishing scripts calibrated across real engagements, identity provider capture flows, MFA fatigue sequencing, deepfake voice assets, and the conditional OSES chain logic that ties it all together. The attack architecture is a standing asset, refined every time we run it. When you engage us, we are configuring a proven system to your environment, not inventing one. That collapses the timeline from weeks to days, and the only true gating steps are the ones that should gate it: scoping, authorization, and target mapping.
We define the target population, the objectives in scope, and the hard limits, then lock legal sign off, a trusted control contact, and an abort path. Deepfake voice of named individuals requires explicit consent and a documented authorization chain, settled here first. This is the real gate, and it is the only one.
The pre-built personas and vishing scripts are tuned to your org chart, your help desk workflow, your identity provider, and your live projects. Because the frame already exists, tailoring is a configuration pass measured in hours, not a build measured in days.
For each objective we write down the process control that should stop it and the technology control that should detect it. This list is your scorecard, and it is standardized from prior engagements so it is ready on arrival rather than authored from scratch.
The conditional OSES chain goes live: reconnaissance touch, help desk call, reset request, access and correlation, adapting to target behavior in real time. Because the chain logic is a mature asset, it deploys as a unit, instrumented on both the attacker and defender side from the first minute so nothing that engages goes unmeasured.
Because the measurement framework is standardized, findings do not wait on a lengthy write up cycle. You get the critical results, especially any successful reset or missed correlation, on the day they happen, with the full report and remediation ranking to follow.
After you fix a gap, the playbook redeploys against the same target to prove the fix. A control change you never retest is a control change you cannot claim, and because deployment is fast, retesting is not a second project. It is a rerun.
What the Engagement Measures
Three layers, three sets of signals, one headline number. These are the metrics that tell you where the system actually breaks against this specific adversary, and the resilience metric at the bottom is the one your board should see.
| Layer | What We Test | Key Metrics | A Pass Looks Like |
|---|---|---|---|
| People | Help desk and user decision under pressure | Reset attempt outcome, escalation rate, report rate, time to report | Refused the reset and escalated |
| Process | Whether identity proofing engages and holds | Verification enforced rate, action stopped rate, adherence under pushback | Reset blocked even when the agent was convinced |
| Technology | Detect, prevent, correlate | IdP alerting, endpoint flags, detections per stage, correlation rate, MTTD | Chain correlated into one incident and alerted |
| System (headline) | End to end resilience | Runs where the objective was blocked despite a deceived person | The attacker never reached authenticated access |
Note what the headline metric is not: it is not click rate. It is the share of runs where your system stopped the attack despite a person being fooled. That single number reframes the leadership conversation from how gullible your help desk is to how many independent layers an attacker has to defeat, which is the only question that maps to real world risk.
Two Ways to Test for Scattered Spider, One Tells the Truth
The same threat can be simulated two ways. One produces a number for a slide. The other produces a map of exactly where this adversary would get through.
Fire a lure, count clicks, assign training. The help desk is never called, so your reset policy is never tested. Nothing multi stage happens, so correlation is never validated. You learn a click rate and nothing about whether the group that hit your industry last quarter could hit you, and since detection training barely moves that number, you run the same test again next quarter.
Run the real chain to the reset request and beyond. When a person is fooled, you find out whether identity proofing fired, whether the IdP alerted, and whether the SOC connected the call to the login. You leave with a ranked list of which layer failed and where to invest, process gap, control gap, or correlation gap, deployed in days by a pre-built playbook.
The difference is not delivery polish. It is whether the test reaches the layers where resilience against this specific group is built. A generic test optimizes the one control the research says you cannot meaningfully improve. The full chain finds the controls you can.
What a Complete Engagement Delivers
A Scattered Spider simulation should leave you with a clear, prioritized picture of where this adversary would actually get through, and what to fix first.
The Output Bar
- A documented control map written before launch, so every result ties to a defined pass condition
- A definitive answer on the help desk reset path: did identity proofing hold, or did the reset go through
- People metrics framed as behavior, escalation and reporting, not a click rate scoreboard
- A finding on each process control: did it engage, did it stop the action, did staff adhere under pushback
- Technology validation per stage, including whether the SOC correlated the chain into one incident
- The headline resilience number: how often the system held despite a person being deceived
- A ranked remediation list separating process gaps, control gaps, and correlation gaps
- A retest plan, delivered fast because the playbook redeploys in days, not weeks
Anything short of that is a phishing click rate report wearing an adversary's name. Anything at or above it is an operational assessment of how your people, process, and technology behave when the Scattered Spider chain is moving through all three at once.
The Standard Worth Holding
Scattered Spider did not invent a new class of attack. They industrialized an old one and moved fast enough that most defenders never got to the decision point in time. The deepfake era only sharpens the edge, because a convincing synthetic voice makes the person more likely to comply, which means the layers behind the person, the process and the technology, matter more than they ever have. Testing only whether someone clicks, and ignoring whether your reset policy holds, is exactly backwards.
Run the attack that reaches the reset request. Watch whether the agent resists, whether the process intervenes, and whether the SOC correlates. The breach happens when all three fail. Your job is to find out, in a simulation, which one fails first, and to find out fast.
That is the whole discipline: one orchestrated chain built on OSES, a pre-built playbook that deploys in days, three layers instrumented, and one resilience number that tells leadership the truth. Not whether your help desk can be fooled, because it can, everyone's can, but whether your organization is built to survive being fooled at the worst possible moment.
Frequently Asked Questions
Direct answers to the questions security leaders ask when scoping a Scattered Spider simulation.
It is an authorized adversary emulation that reproduces the tradecraft of the group tracked as Scattered Spider, UNC3944, and Octo Tempest. Rather than firing a single phishing email, it runs the real kill chain: help desk vishing to trigger an MFA or password reset, MFA fatigue, SIM swap pretexts, Okta and Entra phishing, and deepfake voice. Breacher.ai runs it as an OSES orchestrated campaign so one engagement tests people, process, and technology together.
Because they target process, not perimeter. The group does not exploit an unpatched server. It calls the IT help desk, impersonates an employee, and convinces a human to reset multi factor authentication. That path bypasses most technical controls because the request looks legitimate and the help desk is optimized for speed. Defending against it requires testing whether your identity proofing procedure holds under a convincing, high pressure call, which detection focused phishing tests never reach.
In days, not weeks. We maintain a pre-built Scattered Spider playbook: engineered personas, help desk vishing scripts, identity provider capture flows, MFA fatigue sequencing, and a conditional OSES chain refined across engagements. Because the attack architecture already exists, deployment is a configuration pass rather than a build from scratch. Scoping, authorization, and target mapping are the gating steps, not construction of the attack itself.
OSES™ is a trademarked methodology developed by Breacher.ai for running conditional, multi stage adversary emulation campaigns built on a persistent contextual layer. Applied to Scattered Spider, OSES chains the group's techniques into one coherent campaign that reaches the real decision point, where an employee is asked to act, a procedure is asked to intervene, and the technology is asked to detect. That is what lets a single engagement test people, process, and technology at once.
Process: help desk identity proofing before a reset, out of band verification of caller identity, callback procedures, and the escalation path for suspicious requests. Technology: identity provider alerting on anomalous MFA resets, impersonation protection, endpoint blocking of remote access tooling, and whether the SOC correlated the multi stage activity into one incident. People: whether help desk staff and targeted employees escalated or complied under pressure.
Threat actor tradecraft referenced in this article reflects publicly documented reporting on the group tracked as Scattered Spider, UNC3944, and Octo Tempest through 2025. All techniques are reproduced only under written authorization and defined rules of engagement. Control examples are illustrative of common enterprise procedures and are not exhaustive. Methodology framing reflects Breacher.ai's OSES™ approach. Questions are welcome at support@breacher.ai.
Deploy the Scattered Spider Playbook
Book a 30 minute walkthrough. We will show you the orchestrated chain that reaches the help desk reset request, where your process is supposed to intervene and your SOC is supposed to detect, and how fast we can run it against your environment. No marketing slides.
Latest Posts
Table Of Contents
About the Author: Jason Thatcher
support@breacher.ai
