The most effective intrusions of the last two years did not start with a zero-day. They started with a phone call. An attacker, armed with an employee’s name, title and a few personal details scraped from social media and data leaks, calls the IT help desk, sounds stressed and plausible, and asks for a password reset and a new MFA device. Minutes later they are signed in through single sign-on as a legitimate user, with access to email, collaboration tools, cloud consoles and SaaS data.
This pattern, associated most prominently with the loose collective known as Scattered Spider and successor alliances such as Scattered LAPSUS$ Hunters, has hit retailers, insurers, airlines, hospitality and technology firms. Traditional incident response playbooks, built around malware on endpoints, handle it poorly: there may be no malware at all until the very end, the attacker holds valid credentials, and they may be listening to your incident bridge. This article sets out a dedicated playbook for identity-based intrusions, structured around NIST SP 800-61 Revision 3 and informed by the joint CISA and FBI advisory updated in July 2025.
Why Identity Intrusions Need Their Own Playbook
Google’s M-Trends 2026 report, as reported by The Register, found that voice phishing was the initial infection vector in 11% of intrusions Mandiant investigated in 2025, second only to vulnerability exploitation, while non-interactive email lures fell to 6%. Mandiant’s consulting leadership described attackers calling help desks to register attacker-controlled MFA devices and reset passwords, exploiting the fact that a help desk exists to be helpful.
The July 2025 CISA and FBI advisory on Scattered Spider describes the full chain. Actors impersonate employees to get help-desk staff to reset passwords and move MFA to a device they control, or impersonate IT staff to persuade employees to install commercial remote access tools. They use push bombing and SIM swapping to defeat weaker MFA, register their own MFA methods for persistence, search Snowflake and other data platforms for bulk exfiltration, hunt for vCenter and backups, and in recent cases deployed DragonForce ransomware against VMware ESXi. Crucially, the advisory notes they search Slack, Microsoft Teams and Exchange Online for messages about the response and join incident response calls to watch defenders work.
Three properties make these incidents different:
- Valid credentials, legitimate tools: the attacker uses SSO, approved SaaS apps and commercial remote management tools. Activity looks like an employee working, just from the wrong place.
- Speed: initial access is often handed off quickly to ransomware or extortion operators, so the window between first access and impact can be short.
- Adversary in the room: the attacker may have access to your communication channels, making operational security part of the response.
The NIST SP 800-61r3 Frame
NIST published SP 800-61 Revision 3 in April 2025, superseding the 2012 Computer Security Incident Handling Guide. Instead of a standalone lifecycle, Revision 3 is a Cybersecurity Framework 2.0 community profile: incident response is treated as part of overall cybersecurity risk management. Preparation activities sit under Govern, Identify and Protect; the incident itself is handled through Detect, Respond and Recover; and lessons learned feed continuous improvement back into the whole program. The playbook below follows that structure.
Before the Call: Govern, Identify and Protect
Govern: decide who can authorize what
- Define who has authority to disable executive accounts, revoke all sessions tenant-wide, shut down SSO federation or take the help desk offline. These decisions need to be made in minutes, not after a debate.
- Pre-approve an out-of-band communication plan: a separate messaging tenant or secure app, phone bridges with rotating PINs, and a roster verified in person or by known numbers.
- Agree with legal and communications how reporting obligations will be assessed, since identity intrusions often involve personal data and can become material incidents.
Identify: know your identity attack surface
- Inventory privileged identities, break-glass accounts, identity provider administrators, help-desk staff permissions and service accounts with broad access.
- Map which SaaS and data platforms hold your most sensitive data — CRM, data warehouses, code repositories, file sharing — and whether their audit logs reach your SIEM.
- Document the help desk’s actual reset and MFA enrollment procedures, including the exceptions staff make under pressure.
Protect: harden the help desk and MFA
- Phishing-resistant MFA: CISA recommends FIDO/WebAuthn or PKI-based MFA, which resists push bombing and SIM swapping. Prioritize administrators, help-desk staff and remote access.
- Strong caller verification: replace knowledge-based questions with verification that a scraped profile cannot satisfy — a call back to a number in the HR system, manager approval through a separate channel, video verification with ID, or an identity verification service. Require stronger verification for privileged users and executives.
- Secure MFA re-enrollment: require a waiting period, a temporary access pass delivered through a verified channel, or in-person enrollment for high-risk users; notify the user and their manager on every MFA change.
- Remote access tool control: application allowlisting and blocking of unapproved remote monitoring and management tools, as the advisory recommends, with remote access only through approved VPN or VDI.
- Immutable backups: encrypted, offline or immutable copies separate from the production identity domain, with restoration tested.
In an identity intrusion the attacker is not breaking in; they are logging in. Your playbook must be able to prove who a user really is, revoke trust fast and assume the adversary can hear you.
Detect: Signals That Matter
Detection for identity intrusions lives mainly in identity provider, help-desk and SaaS logs rather than on endpoints. Prioritize detections for:
- An MFA method registered shortly after a help-desk password or MFA reset, especially from a new device, location or anonymizing network.
- Repeated MFA push prompts followed by an approval, or MFA approvals from unusual locations.
- Help-desk tickets for resets that do not match the user’s known location, language or working hours, or several reset requests targeting the same department.
- New sign-ins to cloud consoles, data platforms or code repositories by users who rarely use them, and bulk queries or exports from platforms such as Snowflake.
- Installation or execution of remote access and tunneling tools named in the advisory, such as AnyDesk, ScreenConnect, Teleport or ngrok, outside approved use.
- Searches in email and collaboration tools for terms like “incident,” “security,” “breach” or the names of security staff.
- Changes to identity provider configuration: new federation trusts, conditional access policy changes, new application registrations or consent grants.
Feed help-desk systems into the SOC. A reset request is a security event, and correlating tickets with identity logs is one of the highest-value detections an organization can add.
Respond: The First Hours
Step 1: Move communications out of band
Before discussing the incident in corporate chat or email, assume the attacker can read it. Stand up the pre-approved out-of-band channel, verify every participant’s identity, and keep the bridge closed to unverified attendees. Rotate meeting links and avoid announcing response actions in channels the attacker may watch.
Step 2: Scope the compromised identities
- Identify the initially compromised account and every account touched by the same help-desk agent, caller number or pretext in the recent past.
- Pull identity provider logs for those accounts: sign-ins, MFA changes, tokens issued, applications accessed and administrative actions.
- Check for persistence: additional MFA methods, OAuth consents, application credentials, mail forwarding rules, new devices and newly created accounts.
- Review SaaS and data platform audit logs for data access and bulk export.
Step 3: Contain decisively and in the right order
Containment for identity intrusions must be coordinated, because partial actions tip off the attacker and let them re-enter through remaining persistence. A typical sequence:
- Remove attacker-registered MFA methods and devices, and disable any malicious app registrations, consents and federation changes.
- Reset credentials and revoke all sessions and refresh tokens for compromised accounts, then re-enroll MFA through a strongly verified, in-person or video process.
- Block attacker infrastructure where known and tighten conditional access, for example requiring compliant devices and phishing-resistant MFA for affected groups.
- If administrative identities are compromised, rotate identity provider administrator credentials, review break-glass accounts and consider temporary tenant-wide session revocation.
- Isolate hosts where remote access tools were installed and remove the tools; hunt for the same tools elsewhere.
- Temporarily tighten help-desk procedures: suspend phone-only resets for privileged users and require manager or security approval for any MFA change.
Plan the containment window deliberately. If the team has strong evidence the attacker is active and data is leaving, act immediately. If the intrusion appears to be in early reconnaissance and scoping is incomplete, a short, coordinated pause to map every persistence mechanism can prevent a frustrating cycle of evictions and re-entries. Either way, decide explicitly and record the reasoning.
Step 4: Protect the crown jewels
Given the advisory’s emphasis on vCenter, backups and ESXi encryption, verify the integrity and isolation of backup systems and virtualization management immediately. Restrict administrative access to hypervisors and backup consoles to a small, verified group, and monitor them closely until the intrusion is closed.
Step 5: Start the reporting workstream
Identity intrusions frequently involve personal data and extortion threats. Engage legal early to assess obligations under GDPR, NIS2, DORA, SEC disclosure rules and others, and record the timestamps of awareness, classification and any materiality decision.
Recover: Restoring Trust in Identity
- Re-verify the identity of every affected user before restoring access, using the strongest available method.
- Rebuild or reimage hosts where remote access tools or credential-theft tools ran.
- Review all privileged role assignments and conditional access policies against a known-good baseline.
- Confirm that data exfiltration scope is understood and coordinate any notifications.
- Monitor affected identities and help-desk activity closely for several weeks, as groups often attempt re-entry.
Improve: Lessons Learned That Change Something
SP 800-61r3 emphasizes that improvement should feed back into governance, identification and protection, not just produce a report. After an identity intrusion, the most valuable outcomes tend to be:
- A redesigned help-desk verification process, tested with red-team vishing calls.
- Accelerated rollout of phishing-resistant MFA to all privileged and help-desk users.
- New detections correlating help-desk tickets with MFA changes, added to the detection-as-code pipeline and tested.
- An updated out-of-band communication plan, rehearsed in a tabletop exercise where the scenario assumes the attacker is monitoring corporate chat.
Worked Example: A Friday Afternoon Reset
At 16:40 on a Friday, the help desk of a mid-sized retailer receives a call from someone claiming to be a regional finance manager who has lost their phone while traveling. The caller knows the manager’s employee ID and manager’s name. The agent resets the password and registers a new authenticator. At 17:05 the new device signs in from a residential proxy and opens the finance team’s shared drive, then the cloud data warehouse.
A detection correlating the help-desk ticket with an MFA registration from a new device and anonymizing network fires at 17:08. The AI triage agent attaches the evidence and escalates to the on-call analyst, who calls the real manager on the number in the HR system; the manager is at their desk with their original phone. The analyst declares an incident at 17:20 and moves the team to the out-of-band bridge.
Within the hour the team removes the attacker’s authenticator, revokes all sessions, resets the account, and searches for other recent reset requests from the same caller number, finding one more attempt that the help desk had refused. Warehouse logs show several large queries; the data team confirms which tables were accessed. The help desk suspends phone-only MFA resets for the weekend. On Monday, legal assesses notification obligations for the accessed data, and the lessons-learned review leads to a call-back verification requirement and phishing-resistant MFA for finance and help-desk staff.
Common Pitfalls and a Readiness Checklist
Organizations that struggle with identity intrusions tend to make the same mistakes:
- Blaming the agent: help-desk staff follow the process they are given and are measured on speed and satisfaction. If one call can defeat the process, the process is the problem.
- Resetting the password but not the MFA: leaving attacker-registered authenticators or app consents in place guarantees re-entry.
- Running the response in compromised channels: discussing containment plans in the same chat tenant the attacker is reading.
- Ignoring SaaS logs: many organizations collect endpoint telemetry in depth but have no audit logs from the CRM or data warehouse that held the stolen data.
- Treating it as a one-off: the same groups often return with a new pretext, a different department or an outsourced help-desk provider.
A short readiness checklist to test against before the next call comes in:
- Can the help desk verify a caller without relying on information an attacker could find online?
- Are privileged users and help-desk staff on phishing-resistant MFA today?
- Does every MFA registration or reset generate an alert that the SOC can correlate with a ticket?
- Is there a tested out-of-band channel and a verified responder roster?
- Can the team revoke all sessions for a user, a group or the tenant within minutes, and does it know who authorizes it?
- Do identity provider, SaaS and data platform audit logs reach the SIEM with enough retention to scope an intrusion?
- If your help desk is outsourced, does the contract require the provider to follow your verification standard and notify you promptly of suspicious requests?
Conclusion
Help-desk social engineering turns identity into the perimeter and the help desk into the gate. Responding well requires preparation that most playbooks lack: verified out-of-band communications, clear authority to revoke trust quickly, identity-centric detections that correlate help-desk activity with MFA changes, and a containment sequence that removes every foothold at once. Aligning that playbook with NIST SP 800-61r3 ensures it is part of the wider risk program, and grounding it in the tactics CISA and the FBI have documented ensures it is built for the attacks organizations actually face.
How Hanoi Technology Can Help
Hanoi Technology helps teams build identity-centric detections, incident playbooks and tabletop exercises, through projects, dedicated teams or managed services.
Further Reading
- Scattered Spider joint cybersecurity advisory (updated July 29, 2025) – FBI/CISA via IC3
- CISA and Partners Release Updated Advisory on Scattered Spider Group – CISA
- SP 800-61 Rev. 3: Incident Response Recommendations and Considerations – NIST CSRC
- NIST Revises SP 800-61 – NIST
- Smooth criminals talking their way into cloud environments, Google says – The Register