Social Engineering Identity Breaches Lessons Guide: Help Desk Resets, MFA Fatigue and Vishing Patterns

The most expensive identity breaches of the last few years did not start with an exploit; they started with a person being persuaded to reset, approve or connect something. A help desk agent reset a password, a contractor tapped "approve" on the twentieth push, a support worker typed a connection code, a finance employee joined a video call with colleagues who were not there. This guide reads across those incidents to pull out the repeating patterns, what the attackers did in the hour after the human step, and which controls would have broken each chain. It is written for identity, security operations and service desk leaders who already know the basics in the Social Engineering Guide and want lessons drawn from real cases. Incident details are as reported on each linked breach page, and several are attacker claims or press reports rather than confirmed findings.

Key takeaways

• The reset is the breach. In MGM, Co-op, Marks and Spencer and Caesars the decisive moment was a credential or MFA reset obtained by phone, often through an outsourced or third-party desk.
• Attackers move to the identity plane within hours. After the human step they register their own MFA, seek identity provider admin rights, or target the directory database, so the first hour of monitoring after a reset matters most.
• Vishing now creates machine identities. In the ShinyHunters CRM campaign, a phone call persuaded staff to authorise an attacker's connected app, which kept API access without the employee's password or MFA.
• Push approval is the weak factor. MFA fatigue in the Uber breach and an SSPR approval in Storm-2949 both turned one tap into account takeover; phishing-resistant methods remove that decision from the user.
• Recovery must include non-human credentials. Once an attacker holds a privileged human account, vault secrets, storage keys and service accounts it could reach must be rotated too.

The incidents at a glance

Pattern 1: the help desk reset

CISA's Scattered Spider advisory (AA23-320A) describes actors posing as employees to get help desk staff to reset passwords and MFA tokens, and posing as IT staff to get employees to share one-time passcodes or install remote access tools. The breach pages show the same shape each time:

• Verification used public facts: the MGM caller reportedly used details available on LinkedIn. Names, managers, employee IDs and recent starters are all discoverable or guessable.
• The reset covered MFA, not only the password: a password reset alone would not have helped; resetting or re-enrolling the second factor is what handed over a working account.
• Privileged and IT staff were targeted: attackers want accounts that can change other accounts. Storm-2949 compromised IT staff and senior leaders; MGM's attackers claimed identity provider admin rights.

The control set for this pattern is in the Account Recovery and Help Desk Security Guide and the Help Desk Identity Verification Policy Template. NIST SP 800-63B-4 section 4.2 is a useful baseline: it defines recovery methods (saved or issued recovery codes, recovery contacts, repeated identity proofing), requires two recovery codes or a code plus a bound authenticator for AAL2 accounts, and requires a notification to the subscriber after every recovery.

Pattern 2: outsourced and third-party desks

Caesars and Marks and Spencer both point to a third party: an outsourced IT support vendor, or a third-party user's identity. Organisations often hold their own staff to a verification script, then accept whatever the provider does.

• Contract the verification standard: write the same verification steps into the provider's contract and test them with unannounced calls.
• Limit what the provider can reset: keep identity provider administrators, break-glass accounts and executives out of the provider's reset scope, as the Caesars lessons suggest.
• Treat third-party users as privileged: time-bound, least-privilege access with regular review, per the Marks and Spencer lessons. See the Third-Party Access Guide.

Pattern 3: MFA fatigue and approval abuse

Uber's attacker held a contractor password, likely bought after malware infected a personal device, and sent repeated prompts until one was approved. Storm-2949 triggered self-service password reset and talked the victim into approving the MFA step, then removed the victim's methods and enrolled its own Authenticator. Both map to ATT&CK T1621 (Multi-Factor Authentication Request Generation); the second also involves attacker registration of a new authentication method.

CISA's advisory recommends FIDO/WebAuthn or PKI-based MFA as resistant to phishing, push bombing and SIM swap. The last column is the lesson: phishing-resistant MFA moves the attack to enrolment and recovery, so those flows need the same rigour. See the MFA Fatigue and Bypass Guide and the Phishing-Resistant MFA Guide.

Pattern 4: vishing that creates a machine identity

The ShinyHunters campaign is the clearest case where social engineering produced a non-human identity. Callers posing as IT support walked staff through authorising a connected app, often a renamed data loading tool, and the app then ran bulk API queries. The breach page notes that the platform itself was not breached; the gap was that a person could approve a new machine identity with broad data access, and that one call created persistent API access that never needed the password or MFA again.

• Restrict who can authorise apps: allowlist approved connected apps and limit approval rights to administrators.
• Inventory OAuth grants: owner, scopes and business purpose for each integration; remove unknown apps.
• Alert on bulk export by new apps: a newly connected app reading whole tables is a detectable, high-risk event.

See the Consent Phishing and Illicit OAuth Grants Guide.

Pattern 5: synthetic authority

At Arup no system was breached and no password stolen. A finance worker who first suspected phishing was reassured by a video call with deepfaked colleagues and made 15 transfers using his legitimate authority. The control is procedural: verify high-value or unusual requests through a separate, pre-registered channel, require a second approver for new beneficiaries, and treat secrecy and urgency as warning signs. See the Deepfake and Payment Fraud Executive Briefing.

What happens in the hour after the human step

The breach pages show attackers converting a single account into durable, wider access quickly. These are the moves to watch for, with ATT&CK references where they apply.

Turning the lessons into controls

1. Close the reset path first: require strong verification for any password or MFA reset (manager approval, call-back to a number on file, or in-person or video proofing against stored evidence) and block resets of privileged accounts by the general desk. Pilot with IT and executive accounts.
2. Notify on every recovery: send a notice to all registered addresses after each reset, as NIST SP 800-63B-4 section 4.6 sets out, so the real user can raise the alarm.
3. Deploy phishing-resistant MFA to privileged users: identity administrators, IT staff and executives first, then everyone with access to customer data.
4. Remove standing privilege: just-in-time elevation for identity provider, cloud owner and vault roles.
5. Lock down app consent: admin-only approval for connected apps and OAuth grants in SaaS tenants.
6. Write the response playbook: the Help Desk Social Engineering Incident Playbook covers containment once a fraudulent reset is suspected.
7. Test and roll back safely: run unannounced vishing tests against your own and your provider's desk; keep an emergency bypass with senior approval for genuine lockouts, and log every use.

Small and large organisations: a small firm with no dedicated desk can require manager confirmation in person or by video for any reset and use passkeys from the start. A large organisation with an outsourced desk needs contractual verification standards, tiered reset scope and a security operations alert on every privileged reset.

Where identity fits

Every pattern here ends in identity: a human account reset, a new authenticator, an admin role, or a machine identity created by a person. The Storm-2949 lessons make the non-human point directly: resetting the user's password does not revoke storage keys, SAS tokens or secrets the account read. After any confirmed social engineering compromise, list the vaults, keys, service accounts and OAuth grants that account could reach and rotate them. See the Identity Incident Response Playbook.

Detection and measurement

• Privileged resets with secondary verification: target 100 percent.
• Time from reset to analyst review: for privileged and third-party accounts, measured in minutes.
• MFA method changes followed by sign-in from a new device: count and time to triage.
• Phishing-resistant MFA coverage: share of administrators, IT staff and executives enrolled.
• Unknown or unowned OAuth apps: number in each SaaS tenant, trending to zero.
• Vishing test pass rate: for internal and outsourced desks.

Framework mapping

Practitioner checklist

• Require verification that public information cannot answer before any password or MFA reset.
• Keep privileged, identity admin and executive accounts out of the general and outsourced desk's reset scope.
• Write the verification standard into outsourced desk contracts and test it.
• Notify all registered addresses after every recovery or method change.
• Roll out phishing-resistant MFA to administrators, IT staff and executives first.
• Restrict connected app and OAuth approval to administrators and keep an owned inventory.
• Alert on method removal plus new registration, new admin roles and bulk export by new apps.
• Rotate secrets, keys and service accounts reachable by any account confirmed as socially engineered.
• Require out-of-band verification and a second approver for unusual high-value payments.

Standards and references

• CISA and FBI: Scattered Spider advisory AA23-320A
• NIST: SP 800-63B-4 Authentication and Authenticator Management, account recovery
• MITRE ATT&CK: T1621 Multi-Factor Authentication Request Generation
• MITRE ATT&CK: T1566.004 Spearphishing Voice
• MITRE ATT&CK: T1098.005 Device Registration
• MITRE ATT&CK: T1528 Steal Application Access Token

Related NHI Mgmt Group resources: Scattered Spider threat actor profile · Vishing and Help Desk Social Engineering Awareness Guide · Help Desk Social Engineering Incident Playbook · Vishing and Smishing Guide