Scattered Spider help-desk defense — the social-engineering playbook

This playbook fires for identity-recovery social engineering: an attacker contacting your help desk, service desk, or IT support — by phone, chat, or ticket — to obtain a password reset, an MFA reset, MFA device re-enrollment, or to have a remote-access tool installed. The canonical actor is Scattered Spider (also tracked as UNC3944, Octo Tempest, Scatter Swine, Oktapus, Storm-0875, Muddled Libra), but the protocol applies to any account-recovery abuse.

In scope: the help-desk verification protocol, the recovery-surface hardening, and the detection backstop for when verification fails.

Not in scope: post-compromise incident response once a takeover is confirmed — for that, pivot to the identity provider compromise playbook. This is the *prevention-side* sibling: stop the fraudulent reset before it becomes a takeover.

Understand the chain or the protocol will feel arbitrary. Per AA23-320A and MITRE ATT&CK G1015:

1. Recon. The actor harvests names, roles, employee IDs and personal data from LinkedIn, data-broker sites and breach dumps (MITRE T1589, T1593.001). They learn *exactly* what your help desk asks for before it resets a password.

1. Pretext + SIM swap. They may first SIM-swap the target's mobile number (T1451) so they receive the victim's SMS/voice codes, then call the help desk impersonating the employee (T1656).

1. The ask. Over the phone (spearphishing voice, T1566.004) they ask the agent to reset the password and/or move MFA to a new device. Alternatively they pose as IT and ask the *employee* to read back a one-time code, or to install a remote-access tool (T1219).

1. Persistence. Once in, they register their own MFA token (T1556.006) and — in mature intrusions — add a federated identity provider to the SSO tenant with automatic account linking (T1484.002), so they keep access even after the password is changed (T1078).

1. Impact. Data exfiltration to MEGA.nz, Amazon S3 and Snowflake, followed in recent cases by DragonForce ransomware encrypting VMware ESXi (T1486).

The single decision that breaks this chain is step 3: the agent who refuses to reset without real verification.

Adopt a written, mandatory protocol that an agent cannot waive under social pressure. No reset — password, MFA, or device re-enrollment — proceeds until identity is proven by at least one factor the real employee physically controls, not by knowledge a caller could have stolen.

Banned as sole proof (all obtainable by the attacker): full name, employee ID, date of birth, manager name, last four of a national ID, desk location, security questions.

Accepted verification (require one, two for privileged accounts):

• Live video with corporate photo ID held to camera, with a liveness prompt, matched against the HRIS photo on file.
• Callback to the number stored in the HRIS — never a number the caller supplies. If the caller objects to a callback, that is itself a red flag.
• Out-of-band manager approval: the employee's direct manager confirms the request through a separate, pre-established channel (not the caller's email).
• Push to a pre-enrolled, phishing-resistant authenticator the employee already holds (not the device being enrolled).

Tier the protocol by account risk:

• *Standard user*: one accepted factor.
• *Privileged / admin / finance-approver*: two factors and a mandatory hold (see below).
• *Break-glass / domain admin*: in-person verification only.

Always apply a cooldown. Any new MFA device enrollment notifies the employee's existing verified channel and imposes a short hold window before the new device is trusted — so a real employee can shout "that wasn't me" before the attacker is live.

Give agents an explicit refuse-and-escalate path so the safe choice is the default under pressure:

• Urgency or authority pressure ("the CEO needs this in five minutes", "I'll miss a board deadline") → treat as a red flag, not a reason to skip steps. Real executives tolerate verification; attackers manufacture urgency.
• Caller asks to bypass the protocol or is annoyed by the callback → refuse and escalate to the SOC. Legitimate users do not object to being verified.
• Caller cannot complete video + ID → no remote reset; route to in-person or a verified-manager channel.
• Inbound call claiming to be IT, asking the employee to read a one-time code or install a tool → IT never asks for an OTP or installs tools via an unsolicited call. Hang up and report.
• Multiple failed verifications across different accounts in a short window → this is a campaign indicator, not bad luck. Raise a SOC alert and consider a temporary freeze on all phone-initiated resets.

Make explicit, in writing, that an agent is never penalised for refusing a reset that could not be verified — only for skipping verification. Reverse the incentive that social engineers exploit.

The protocol is the human control; these are the technical controls that shrink what a single mistake can cost. From the AA23-320A mitigations and CISA's phishing-resistant MFA guidance:

• Deploy phishing-resistant MFA (FIDO2/WebAuthn or PKI). It is not susceptible to push bombing or SIM swap — the two techniques the advisory ties to this actor. Retire SMS and voice OTP for any account that matters.
• Alert on every MFA device registration and on new federated identity providers / domain-trust changes (the T1484.002 persistence move). Treat an unexpected SSO federation change as an incident.
• Constrain remote-access tools. Application allowlisting blocks unsanctioned RMM (AnyDesk, ScreenConnect, TeamViewer, Ngrok and similar named in the advisory); block their ports inbound and outbound at the perimeter and require remote access only over the corporate VPN/VDI.
• Apply NIST authentication standards (SP 800-63B): long unique passwords, no recurring forced rotation, and require administrator credentials to install software.
• Segment so a single recovered account cannot reach the ESXi/backup/Snowflake estate the actor monetises.

Assume the protocol will occasionally fail: a convincing caller, a rushed agent, an outsourced desk off-script. After a fraudulent reset the account is genuinely valid — the login is not anomalous, so identity-layer alerting alone will miss it. What remains anomalous is the *behaviour*: an impossible-travel session, a host that historically only ingests suddenly fanning out laterally, RMM execution, and sustained egress to never-seen destinations (MEGA.nz, unfamiliar S3 buckets, bulk Snowflake queries).

Monitor explicitly for: new MFA enrollments, federated-trust changes, CISA-style "risky logins", RMM process execution, and abnormal east-west and outbound traffic. This last layer is exactly where Zero Hunt's AI Traffic Analysis pillar fits: a deep-learning model with four inference heads (suspicious traffic, malware classification, attack-type identification, application fingerprinting), running on the appliance GPU, flags the lateral fan-out and exfiltration of a session the help desk wrongly trusted — *while it is happening*, not in the next morning's SIEM digest. The verification protocol is the front door; wire-speed behavioural detection is the tripwire for the times the front door is talked open.

Keep these so you can prove the control works to an auditor, an insurer, or a board — and so you can spot a campaign early:

• Help-desk reset log: per request — timestamp, agent, account, verification method used, outcome (reset / refused / escalated).
• MFA enrollment and change audit log, with the originating device and IP.
• Federated identity / domain-trust change log (the persistence canary).
• Risky-login and impossible-travel alerts, retained with the session detail.
• RMM install/execution logs from endpoint allowlisting.
• Outbound/lateral traffic anomalies correlated to the account window.

Track these metrics monthly: percentage of resets completed via an approved verification method (target 100%), verification-failure / refusal rate (a healthy non-zero number means the protocol is being enforced), and mean time from suspected fraudulent reset to account revocation.

Patterns that recur across organisations Scattered Spider has hit:

• PII-only verification. Resetting on data the attacker already bought. The single most common root cause.
• The VIP exception lane. A fast path for executives that skips verification — precisely the accounts the actor targets and the pretext ("I'm the CFO, hurry") they use.
• An outsourced help desk on a weaker protocol than the parent. The advisory explicitly flags abuse of *contracted* IT help desks (T1199); your protocol must bind the BPO contractually and be tested against it.
• SMS or voice-call MFA left enabled for sensitive accounts — defeated by the SIM swap that often precedes the call.
• No alert on new MFA device enrollment, so the attacker's device goes live silently.
• Treating this as an IT-help-desk problem. It is a people-and-process control the board owns: training, incentives, the BPO contract, and the decision to fund phishing-resistant MFA all sit above the service desk.