Help desk social engineering

How it works

An attacker calls or messages an organization's IT help desk while impersonating an employee, using information gathered from public sources, prior breaches, or a preceding phishing message to sound convincing: an employee ID, a manager's name, a recent project. They ask for a password reset, a new MFA device enrollment, or both, framing it as an urgent lockout. If the help desk agent verifies identity using only information an attacker can also obtain, name, employee ID, department, the reset proceeds, and the attacker now holds fully legitimate, freshly issued credentials for the target account.

Scattered Spider built its 2023 intrusions at MGM Resorts and Caesars Entertainment around exactly this pattern. The 2026 McKesson breach ran the same play at larger scale: attackers registered a lookalike domain, called multiple employees while impersonating help desk and IT staff, obtained Okta credentials, and used the resulting single sign-on session to reach Salesforce and Snowflake, moving roughly a terabyte of data over four days before discovery.

Why it works

Help desk identity verification exists to confirm that the person asking for a reset is who they claim to be, but the verification questions in most deployed processes rely on facts about the employee rather than proof the employee controls something an attacker cannot also obtain. The control assumption that fails is that knowledge of internal-sounding details proves identity. It does not, because a target's LinkedIn profile, a prior data breach, or a preparatory phishing message can supply the same details to an attacker. Once the reset happens, every downstream control, MFA, conditional access, strong passwords, is moot, because the attacker is not bypassing them; the help desk issued them a fresh, compliant credential directly.

How to detect it

• A credential reset or MFA re-enrollment followed immediately by a login from a device, location, or IP that has never appeared for that account.
• A cluster of reset requests referencing a common pretext (a specific outage, a named lookalike support domain) across multiple employees in a short window.
• Help desk tickets where the verification method used was a static personal detail rather than a channel the organization controls, such as a callback to a known-good number or an in-person check.

Be honest about the limits: legitimate employees are locked out and call for resets constantly, and a new device after a reset can simply mean someone got a new phone. This needs correlation between the reset event and downstream anomaly, tracked through ITDR, not a rule on the reset alone.

How to stop it

• Verify identity through a channel the attacker cannot spoof, such as a callback to a number already on file, a manager approval step, or a video check for sensitive roles, rather than personal details alone.
• Add friction and secondary approval to privileged account resets specifically, since these are the highest-value targets and can tolerate a slower process.
• Log and alert on every reset and re-enrollment event, with automatic correlation against the next login for that account.
• Rehearse the response, since the industrialized version of this attack, AI voice agents running the same script at a fraction of the cost, means volume will increase rather than decrease. See phishing-resistant MFA for what still holds even after a successful reset call.
• Limit what a single reset can reach. Step-up authentication on sensitive downstream systems means a compromised help desk credential does not automatically open everything behind single sign-on.

Seen in the wild

• Scattered Spider and the help desk: social engineering the identity reset
• McKesson breach started with vishing against Okta SSO, then reached Salesforce and Snowflake

Sources

• MITRE ATT&CK T1656: Impersonation
• CISA: Scattered Spider advisory