Attackers don’t always “hack in.” Increasingly, they talk their way in—and they do it by targeting the one team that is designed to help people: the help desk. If your password reset, MFA reset, or device enrollment process is weak, your strongest technical controls can be bypassed in minutes.
That’s why groups tracked as Scattered Spider (and a handful of related aliases used by security vendors) keep showing up in U.S. cybersecurity advisories. Their playbook is brutally practical: don’t fight the firewall—convince a person (or a workflow) to grant access. Tactics often include help desk impersonation, push-notification fatigue (“MFA bombing” or “push bombing”), SIM swaps, and other social engineering techniques aimed at getting an MFA reset or account recovery approved. Once inside, attackers can move laterally, steal data, abuse cloud identity, and in many cases hand off access to ransomware or extortion crews.
Why this matters to CISOs right now
Most security programs have invested heavily in perimeter controls, endpoint protection, and multi-factor authentication. That’s good—but it can create a false sense of confidence: “We have MFA, so account takeover is unlikely.” Scattered Spider-style operations break that assumption. When attackers can socially engineer a reset, MFA becomes a speed bump instead of a barrier.
This risk is amplified in organizations with:
- Large user populations and high ticket volumes (more noise makes malicious requests harder to spot).
- Outsourced or distributed IT support (variable training and inconsistent verification).
- Fast-moving business units (pressure to “just get it done” during travel, mergers, or outages).
- Hybrid and cloud-heavy environments where identity is the control plane (Okta, Entra ID, Google Workspace, VPN, SaaS).
In other words: the help desk is now part of your “identity security” surface area. If you treat it like a customer service function instead of a security-critical control point, attackers will treat it like an open door.
How the attack usually unfolds (a realistic sequence)
Here’s a common pattern that shows why traditional defenses don’t catch this early enough:
1) Recon and pretext: the attacker gathers names, titles, travel schedules, and org details from LinkedIn, conference posts, breach dumps, or vendor portals.
2) Help desk engagement: they call, chat, or open a ticket posing as a real employee (often an executive or someone with broad access).
3) Verification pressure: they manufacture urgency—“I’m about to present to the board,” “I’m locked out overseas,” “my phone was replaced,”—and attempt to steer the agent away from standard verification.
4) Recovery action: the agent resets MFA, changes a recovery email, enrolls a new device, or issues a temporary password.
5) Access and escalation: the attacker logs in from a new device or geography, pivots into email or collaboration tools, and hunts for high-value targets (finance workflows, password vaults, cloud consoles).
6) Extortion stage: data exfiltration, mailbox rule abuse, and handoff to ransomware affiliates (depending on the crew).
The key lesson: by the time malware shows up (if it ever does), the attacker may already have valid credentials and legitimate sessions.
Four places to harden (fast)
If you only have time for a few improvements, start with the workflows that attackers abuse most often and that create the highest blast radius:
1) MFA resets and device enrollment (treat as a high-risk security event)
Password resets matter, but MFA resets and new device enrollments are often the real prize. Treat these actions like privileged changes:
- Require strong verification (see the standard below) before any MFA reset, new authenticator enrollment, or recovery-email change.
- Log every request with ticket ID, agent ID, method of verification used, and approval path.
- Route exceptions to a small, trained group (a “high-risk queue”) instead of letting any tier-1 agent approve.
- Add a “cooling-off” delay (15–30 minutes or longer for privileged users) so security monitoring and managers have a chance to intervene.
Keywords to align internally: identity proofing, account recovery, MFA reset, device enrollment, step-up authentication, identity governance.
2) Help desk identity proofing (move beyond ‘what you know’)
Knowledge-based checks—employee ID, last four digits, “security questions,” manager name—are easily obtained or guessed. A better approach is to rely on at least one verification method that’s hard to spoof via voice or email:
- An authenticated portal: the user approves a reset from a corporate portal session that already requires SSO and MFA.
- Known-device verification: the user confirms from a pre-registered device (mobile app prompt, endpoint certificate, device posture check).
- Directory-sourced callback: the agent calls back using the number already stored in HR/identity systems—not the number provided during the ticket.
- Manager confirmation in the ticketing system: approval must come through an authenticated workflow (not a forwarded email).
Keywords: identity proofing, out-of-band verification, known good channel, secure service desk, zero trust identity.
3) Privileged access workflows (phishing-resistant MFA + step-up controls)
Scattered Spider often targets users with access to admin consoles, finance systems, or broad SaaS permissions. For these accounts, tighten controls to reduce the likelihood that any single help desk interaction becomes catastrophic:
- Move administrators and service desk staff to phishing-resistant MFA (FIDO2 security keys/passkeys) where feasible.
- Require step-up approval for sensitive changes (MFA settings, password resets, mailbox delegation, role assignment, conditional access changes).
- Minimize standing privileges with PAM (Privileged Access Management) and just-in-time access. If an attacker gets a user session, JIT reduces what they can immediately do.
- Put explicit detection rules on privileged identity actions: new authenticator enrollment, recovery method changes, and role escalation.
Keywords: PAM, least privilege, just-in-time access, conditional access, phishing-resistant MFA, FIDO2, passkeys, privileged identity management.
4) Third-party support controls (outsourced help desk = expanded supply chain)
If a vendor runs your help desk, you still own the risk. Attackers know vendors are often optimized for speed, not verification. Put security requirements into contracts and monitor them like any other critical supplier:
- Contractual requirements: verification standards, MFA for agents, logging retention, and incident notification SLAs for suspected social engineering.
- Audit rights: ability to review samples of reset tickets, verification evidence, and escalation adherence.
- Segmentation of access: vendor agents should not have broad admin rights; enforce least privilege and role-based access control.
- Shared playbooks: run joint tabletop exercises and ensure escalation contacts are documented.
Keywords: third-party risk management (TPRM), vendor access, supply chain security, contractual controls, audit logging.
A “good enough” help desk verification standard
You don’t need to turn the help desk into a bank vault, but you do need a rule that’s consistent and usable under pressure. A practical standard many organizations adopt is:
“No MFA reset without two independent checks—and at least one must be resistant to voice impersonation.”
Examples of a resistant check (good):
- The user is already logged in to an authenticated corporate portal and approves the request in-session.
- A callback to a pre-registered number pulled from HR/IdP records (not supplied by the caller).
- A device-bound verification step (registered authenticator device or device posture attestation).
Examples of weak checks (avoid relying on these alone):
- Knowledge-based questions, employee IDs, manager names, birthdates, or any details likely found on social media.
- “We recognized your voice” or “the caller sounded right.”
Workflow improvements that reduce pressure-based errors:
- Delay windows for MFA changes unless approved by a manager through the ticketing system (and ideally confirmed via a second channel).
- A separate verification path for executives and privileged users with higher friction but clearer guardrails.
- A standardized script that agents read verbatim. Scripts reduce improvisation, which is where attackers win.
Detection and response: what your SOC should monitor
Social engineering leaves patterns in identity and access logs, even when there’s no malware. Build detections around identity signals and help desk activity:
- High-volume MFA prompts or repeated push rejections for a user within minutes (possible push bombing).
- MFA reset or new device enrollment followed by logins from new geographies, unfamiliar ASN ranges, impossible travel, or new devices.
- Sudden changes to recovery methods (new phone number, recovery email, passkey) shortly before access to sensitive systems (finance apps, admin portals, data repositories).
- Help desk tickets requesting urgent changes outside normal hours or asking to bypass verification (“I can’t do the portal right now”).
- New mailbox rules, OAuth app consents, or unusual session token activity shortly after a reset (common in account takeover).
Operational tip: Make sure your SOC has the ticket context. A reset event without the corresponding ticket ID and verification method is hard to triage. Integrate your ITSM (ServiceNow/Jira/other) with your SIEM so identity events include the associated ticket metadata.
Tabletop scenario to run this quarter (no malware required)
Run a tabletop where the attacker never drops malware and never exploits a vulnerability. The scenario is: an executive’s identity is impersonated to the help desk, MFA is reset, and email access is gained. Add one twist: the attacker uses the executive’s mailbox to request a vendor bank change.
Objectives:
- Validate that the help desk rejects the request or escalates it correctly using the verification standard.
- Confirm security monitoring detects the reset and the unusual login chain (new device + new location + sensitive app access).
- Test your containment steps: session revocation, forced re-authentication, conditional access tightening, mailbox rule review, and token invalidation.
- Test internal communications. People panic when they hear “the CEO’s email was accessed.” Your comms plan should prevent rumor-driven escalation while preserving evidence and speed.
What to measure after the tabletop:
- Verification compliance rate (did the process hold under pressure?).
- Time-to-detect the suspicious reset + login sequence.
- Time-to-revoke sessions and lock down recovery methods.
- Gaps in tooling (missing logs, incomplete ticket metadata, lack of step-up enforcement).
Quick checklist for CISOs
- Treat MFA resets and device enrollments as privileged events: higher verification, better logs, and tighter approvals.
- Deploy phishing-resistant MFA for admins and service desk staff, and reduce standing privileges with PAM/JIT access.
- Standardize help desk scripts and require two independent verification checks—one resistant to voice impersonation.
- Integrate ITSM + SIEM so the SOC can correlate resets with ticket evidence quickly.
- Review vendor-run help desk contracts for verification, logging, auditability, and incident response obligations.
- Run a no-malware tabletop this quarter and turn findings into a tracked remediation plan.
References:
- CISA — Cybersecurity Advisory AA23-320A: Scattered Spider (tactics include social engineering, push bombing, SIM swaps, MFA bypass) — https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
- CISA — #StopRansomware Guide (prevention and response checklist, including identity hardening and recovery planning) — https://www.cisa.gov/resources-tools/resources/stopransomware-guide
- CISA — Known Exploited Vulnerabilities (KEV) Catalog (patch prioritization based on in-the-wild exploitation) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog