Voice phishing attacks surged 442% between the first and second halves of 2024, according to CrowdStrike's 2025 Global Threat Report, and the fastest-growing target was not the inbox. It was the help desk. Attackers now call IT support, impersonate an employee, and work through the account-recovery workflow until a password is reset and multi-factor authentication (MFA) is moved onto a device they control. The joint CISA and FBI advisory on Scattered Spider, AA23-320A, describes this as the group's signature move, and Verizon's 2025 Data Breach Investigations Report found that roughly 60% of breaches still involve a human element.
That raises a direct buyer question: how do I test whether my account-recovery and help-desk workflows can be socially engineered the way Scattered Spider operates? The answer is to commission a scoped social-engineering red team that targets those exact workflows. A credible engagement measures your identity-proofing strength, your controls around MFA resets, your callback and out-of-band verification, and how quickly your team detects and escalates a suspicious recovery request. This guide explains why the help desk is the soft target, what a red team measures, how to scope and buy the engagement safely, and what a resilient account-recovery workflow looks like.
This is written for the security leader buying the test, not the attacker running it. It stays at defender altitude throughout: what gets tested and why, not how to run the con.
TL;DR
Account recovery is the target (2025): Scattered Spider (also tracked as UNC3944 and Octo Tempest) social-engineers help desks into resetting passwords and re-enrolling MFA, per the joint CISA and FBI advisory AA23-320A, updated 29 July 2025.
Vishing is exploding (2024): voice phishing rose 442% between the first and second halves of 2024 (CrowdStrike 2025 Global Threat Report).
Most intrusions skip malware (2024): 79% of initial-access detections were malware-free, driven by hands-on-keyboard identity abuse (CrowdStrike, 2025).
The human element persists (2025): around 60% of breaches involve a human element and 22% start with credential abuse (Verizon 2025 DBIR).
What to buy: a scoped social-engineering red team that tests identity proofing, MFA-reset controls, callback verification, out-of-band checks, and detection plus escalation.
What good looks like: a recovery workflow that proves identity out-of-band, separates the reset requester from the approver, and alerts the security team on every high-risk reset.
Why account recovery and the help desk are the soft target
Every strong authentication program has a back door built into it on purpose: the process that lets a legitimate but locked-out employee get back in. That workflow is designed for speed and empathy under pressure, which is exactly what an attacker exploits.
The economics favor the attacker. Phishing-resistant MFA, endpoint detection, and network controls have all improved, so adversaries moved to the softest link that still grants a valid identity. CrowdStrike reports that 79% of initial-access detections were malware-free, meaning the intruder logged in rather than broke in. When 22% of breaches begin with credential abuse, per the Verizon DBIR, a recovery desk with weak verification becomes a credential vending machine.
Scattered Spider industrialized this. The CISA and FBI advisory describes operators who impersonate employees and contractors, then pressure IT and help-desk staff to reset the target's password and transfer MFA to an attacker-controlled device. MITRE ATT&CK catalogs the group (G1015) using MFA request generation and push bombing (T1621), SIM swapping (T1451), and valid-account abuse (T1078). None of that requires an exploit. It requires a workflow that trusts the wrong signals.
The trust gap sits between "the caller sounds like they know the employee" and "the caller is the employee." Knowable facts such as a name, a date of birth, a manager, or the last four digits of an ID are not secrets in 2026; they are on résumés, in data-broker records, and in prior breach dumps. A recovery workflow that accepts knowable facts as proof of identity is the gap. A red team exists to find how wide it is before a real crew does.
What a red team actually measures when it tests account recovery
A social-engineering red team is not a stunt to see whether one agent can be tricked. It is a measurement exercise against your controls, with the results mapped to named criteria so you can fix the workflow, not just name a scapegoat. A strong engagement scores five things.
Identity-proofing strength
The core measure is whether your recovery process can be satisfied with knowable facts alone. The red team assesses what evidence the workflow demands to prove a caller is who they claim, and whether that evidence is genuinely hard to obtain. A resilient process leans on enrollment-time secrets, verified device signals, or manager and sponsor attestation rather than data that leaks.
MFA-reset and re-enrollment controls
Resetting a password is only half of an identity takeover. The decisive step is moving the second factor to a new device. The red team measures whether an MFA re-enrollment can happen instantly, on demand, and without a second control, or whether it triggers a cool-down, a step-up check, or independent approval. This is the single highest-value control in the whole workflow.
Callback and out-of-band verification
The team measures whether verification travels over a channel the real employee controls, such as a call back to the number on record or a prompt to a pre-enrolled device, rather than a channel the caller supplies. Any process that verifies a caller using a phone number or email the caller just provided is verifying the attacker.
Detection and telemetry
Prevention will sometimes fail, so the team measures whether the attempt is even visible. Does a high-risk reset generate an alert? Does anyone notice a password reset followed within minutes by an MFA change from a new device and a new location? The red team documents what your security team saw, when, and whether the signal reached anyone who could act.
Escalation and human response
Finally, the team measures what happens when an agent feels that something is wrong. Is there a blameless, well-known path to pause a request and escalate? Or does queue pressure and a culture of "just help the customer" push agents to override their own instincts? The quality of the human response is a control, and it is testable.
The deliverable that matters is a per-control scorecard: for each of the five areas, what held, what did not, the timeline of what your defenders detected, and a prioritized list of workflow fixes with a retest to confirm they work. If a vendor offers you a pass or fail headline instead of that, keep looking. For the difference between this kind of goal-based test and a standard vulnerability assessment, see red team vs penetration test vs continuous validation.
How to scope and buy the engagement safely
Social-engineering testing touches real people, so the rules of engagement matter as much as the technical scope. A professional engagement is designed to be safe for your staff and legally clean before it starts.
Define the workflows and roles in scope. Name the targets: the IT help desk, self-service password reset, MFA re-enrollment, carrier or SIM processes, and which employee tiers (privileged administrators and finance approvers deserve their own scope).
Set rules of engagement and a real-time abort channel. Agree blackout windows, an authorized point of contact, and a way to halt the exercise immediately if it risks real harm or business disruption.
Protect the people. Insist on a no-blame model. The point is to fix the workflow, not to punish an agent who followed a broken process. Build a debrief and a training loop into the statement of work.
Choose the starting position. A full-scope test starts cold from open-source reconnaissance. An assumed-breach engagement starts with a modest foothold so the team spends its time on the recovery controls rather than on getting in, which often gives you more signal per dollar.
Demand defensible deliverables. Require the per-control scorecard, a detection timeline, mapped MITRE ATT&CK techniques, prioritized remediation, and a retest.
Vet the vendor. Prefer a firm-level CREST-accredited provider with a methodology mapped to real adversary behavior, a willingness to run the exercise as a purple team so your defenders learn in real time, and disciplined handling of any sensitive data touched during the test.
Get the legal authorization and staff-care terms in writing before any activity begins. A serious provider will insist on this too. The output feeds directly into your compliance program as well: red team and penetration testing evidence supports your SOC 2 and ISO 27001 controls around access management and incident response.
What a resilient account-recovery workflow looks like
The purpose of the test is a stronger workflow. These are the defensive controls that separate a recovery desk that holds from one that hands out sessions. Use them as a checklist when you review your own process.
Prove identity out-of-band. Verify through a channel the real employee controls, such as a callback to the number on record or a prompt to a pre-enrolled, managed device. Never verify with contact details the caller supplies during the call.
Stop trusting knowable facts. Retire name, date of birth, manager, and last-four-of-ID as proof. Use enrollment-time secrets or a verified device signal instead.
Separate the requester from the approver. For privileged and high-risk accounts, the agent who takes the request should not be the person who approves the MFA re-enrollment. A second set of eyes breaks the single-point-of-failure.
Add friction to MFA re-enrollment. Introduce a cool-down window or a manager approval step before a second factor can move to a new device, so an instant swap is not possible.
Prefer phishing-resistant factors. FIDO2 passkeys mean a password reset alone does not produce a replayable second factor, which shrinks the prize an attacker gets from a successful reset.
Alert on the pattern, not just the event. Generate a security alert on every high-risk reset, and specifically on a reset followed quickly by an MFA change from a new device or location.
Give agents a safe stop. Publish a clear, blameless escalation path and a phrase agents can use to pause a suspicious request without fear of a bad performance mark.
Limit the blast radius. Enforce least standing privilege so a single recovered account cannot pivot into your crown jewels.
Re-test on a cadence. Workflows drift as tools, staff, and outsourcers change. A control that passed last year is an assumption until it is tested again.
What this means for defenders
Identity is the perimeter now, and the recovery workflow is the gate most teams never pressure-test. Two complementary tests give you full coverage of the account-takeover surface, and they are honestly different exercises.
The first is a human-led social-engineering red team against the process: your help desk, your identity proofing, and your MFA-reset controls, run the way Scattered Spider runs it and measured against the five controls above. Stingrai's red team does exactly this, as a firm-level CREST-accredited offensive security provider that can run the exercise as a collaborative purple team.
The second is a technical test of the account-recovery feature inside your web application, because the same account takeover can happen with no phone call at all. Broken password-reset flows, guessable or reusable reset tokens, insecure deep links, and broken authorization on the reset and MFA-enrollment endpoints let an attacker take over an account through the software itself. This is where Stingrai's autonomous agent Snipe works: it is built to hunt the complex, high-impact classes, including insecure direct object references and broken access control in exactly these recovery flows, across black-box testing and white-box code review, and it can raise fix pull requests and gate them in your pipeline. Read more about that surface in web application penetration testing and about continuous coverage through PTaaS.
Test the process and test the product. Then re-test both, because the workflow you hardened this quarter is only as good as the last time an operator tried to walk through it.
Frequently Asked Questions
How do I test whether my account-recovery and help-desk workflows can be socially engineered the way Scattered Spider operates?
Commission a scoped social-engineering red team that targets those workflows directly. A credible engagement measures identity-proofing strength, MFA-reset and re-enrollment controls, callback and out-of-band verification, detection, and escalation, then returns a per-control scorecard with prioritized fixes and a retest. Stingrai runs this as a CREST-accredited red team engagement.
What is Scattered Spider and why does it target help desks?
Scattered Spider, tracked as UNC3944 and Octo Tempest, is a social-engineering-driven cybercriminal group. Per the CISA and FBI advisory AA23-320A, it impersonates employees to pressure IT and help-desk staff into resetting passwords and moving MFA to attacker-controlled devices. The help desk is targeted because it is designed to restore access quickly, which conflicts with rigorous identity verification.
What is the difference between account recovery red teaming and a penetration test?
A penetration test finds and proves technical vulnerabilities in a defined system. Account recovery red teaming is goal-based: it tries to achieve an outcome, an account takeover through the recovery workflow, using social engineering against people and process. The two are complementary. See red team vs penetration test vs continuous validation for the full comparison.
Is a social-engineering red team safe for my staff?
Yes, when it is scoped properly. A professional engagement runs under written rules of engagement with an authorized contact, blackout windows, a real-time abort channel, a strict no-blame model, and a debrief that turns findings into training. The goal is to fix the workflow, never to punish an agent who followed a broken process.
What controls should a resilient account-recovery workflow have?
Out-of-band identity verification through a channel the employee controls, an end to trusting knowable facts, separation of the reset requester from the approver, friction on MFA re-enrollment, phishing-resistant factors, alerting on high-risk resets, a blameless escalation path for agents, and least standing privilege to limit blast radius.
How common are these identity-based attacks?
Very common and rising. Voice phishing rose 442% between the first and second halves of 2024, and 79% of initial-access detections were malware-free, per the CrowdStrike 2025 Global Threat Report. Around 60% of breaches involve a human element, per the Verizon 2025 DBIR.
Can attackers take over accounts without ever calling the help desk?
Yes. The same outcome can come from the web application itself: broken password-reset flows, reusable or guessable reset tokens, insecure deep links, and broken authorization on reset and MFA-enrollment endpoints. That is why the product side deserves its own test alongside the process side, covered by web application penetration testing.
Does MFA stop Scattered Spider?
Not on its own. The group's whole method is to move or reset the second factor rather than defeat it head on, using help-desk social engineering, MFA push bombing, and SIM swapping. Phishing-resistant factors such as FIDO2 passkeys raise the bar, but the recovery workflow that can re-enroll those factors still has to be hardened and tested.
How often should I test my account-recovery workflow?
At least annually, and after any material change to your help desk, identity provider, outsourced support, or MFA tooling. Workflows drift, so a control that passed last year is an assumption until it is tested again. Continuous validation through PTaaS keeps the coverage from going stale between point-in-time tests.
References
CISA and FBI. Scattered Spider (Joint Cybersecurity Advisory AA23-320A). Originally published 16 November 2023, updated 29 July 2025. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a. Describes Scattered Spider tradecraft, including help-desk impersonation to reset passwords and re-enroll MFA, MFA fatigue, and SIM swapping, plus recommended mitigations.
MITRE ATT&CK. Scattered Spider (G1015). Accessed July 2026. https://attack.mitre.org/groups/G1015/. Maps the group's techniques, including MFA request generation and push bombing (T1621), SIM swapping (T1451), and valid-account abuse (T1078).
CrowdStrike. 2025 Global Threat Report. 2025. https://www.crowdstrike.com/en-us/blog/crowdstrike-2025-global-threat-report-findings/. Reports a 442% rise in voice phishing between the first and second halves of 2024 and that 79% of initial-access detections were malware-free.
Verizon. 2025 Data Breach Investigations Report. 2025. https://www.verizon.com/business/resources/reports/dbir/. Finds roughly 60% of breaches involve a human element and 22% begin with credential abuse.
