Skip to content
Start with Identity
Join free
SWI-T014 · Identity lifecycle

Help desk social engineering

A phone call to IT support, not a login attempt, is the actual attack. The target's strong password and MFA enrollment never come into play, because the attacker gets a human to reset both.

WidespreadModerate
First observed: 2022ATT&CK T1684.001 ↗ATT&CK T1098.005 ↗

How it works

Help desk social engineering is getting an IT support agent to issue a working credential for someone else's account. The attacker calls or messages the service desk posing as an employee, a contractor or a third-party user, asks for a password reset, an MFA reset or a new MFA device, and gets it, because the agent checks facts an attacker can look up. The organization hands the attacker a fresh, compliant credential, which makes this a textbook talk-past attack: authentication is satisfied, not broken.

A typical run:

  1. Reconnaissance. The attacker picks a target, often an administrator, and collects what the help desk will ask for: name, employee ID, manager, start date. LinkedIn, breach dumps and a short phishing exchange supply most of it.
  2. The call. The attacker phones or messages the service desk with an urgent but ordinary story: a new phone, a lost authenticator, a lockout before a deadline.
  3. The reset. The agent verifies with knowledge checks, then resets the password, clears all MFA factors, or issues a bootstrap code such as a Microsoft Entra ID Temporary Access Pass, which lets the holder register new sign-in methods.
  4. Enrollment. The attacker registers their own MFA method. From here every phishing-resistant MFA or conditional access check sees a legitimately enrolled user.
  5. Expansion. With an SSO or admin account, the attacker reaches SaaS apps and the identity provider itself. In the 2023 Okta customer cases, attackers who had super administrator access added a second identity provider through inbound federation so they could sign in as any user.

The reverse version, a caller posing as the help desk to get a code from an employee, is covered in OTP relay via social engineering.

Why it works

The help desk's verification step asks the wrong question. It checks whether the caller knows facts about the employee, when it needs to check whether the caller controls something only the employee has: a registered device, a phone number already on file, a face that matches an ID document. Knowledge is for sale. Once the reset happens, every downstream control is moot, because the attacker is not bypassing them. The help desk issued them a credential directly.

Three conditions make it worse. Outsourced service desks hold the same reset power with weaker oversight, as Caesars, Clorox and M&S show. Help desk roles are often scoped to reset anyone, including administrators. And the passkey migration raises the volume of legitimate "new phone" calls this attack hides in: Microsoft's retirement guide says users whose only method is Microsoft-provided SMS or voice will face a blocking passkey registration prompt after February 1, 2027.

How to detect it

The most useful signal is a pairing: a reset or new MFA method, followed shortly by a sign-in from a device, IP or network the account has never used.

  • Okta System Log. user.mfa.factor.reset_all (all factors reset for a user), user.mfa.factor.deactivate, user.account.reset_password, then user.mfa.factor.activate for the new device. Okta's 2023 guidance for these cases also recommends alerting on user.session.start where securityContext.isProxy is true, and on system.idp.lifecycle.create for any new identity provider.
  • Microsoft Entra audit log. Reset password (by admin), Admin deleted security info, Admin registered security info and Admin updated security info (category UserManagement), followed by User registered security info from a new location. Correlate with the next entry in SigninLogs for that user.
  • Clusters. Several resets in a short window sharing a pretext or caller number, or concentrated on admin accounts.
  • Post-reset behavior. New inbox rules, OAuth grants, remote support tools or role changes within an hour of the reset.

Be honest about the limits: a new device after a reset is usually benign, so a rule on resets alone fires constantly. The detection that works correlates the reset event with what the account does next, through ITDR or your SIEM,, and it fires after the attacker holds the credential.

How to stop it

Ranked by effect:

  1. Verify through something the attacker cannot say or look up. In order of strength: the user completes a challenge with a method already registered; a callback to the number in the HR record, never one the caller gives; identity re-proofing with a document and liveness check, from vendors such as Persona or CLEAR, or in person. Okta's guidance after the 2023 cases was to strengthen help desk verification using visual verification.
  2. Scope help desk roles away from privileged accounts. Okta recommends constraining help desk admin roles with resource sets that exclude highly privileged groups. In Entra, only a Privileged Authentication Administrator can create a Temporary Access Pass for admins; Authentication Administrators can only do so for members. Route admin resets to a separate, slower process with two approvers.
  3. Issue a short, single-use bootstrap credential instead of resetting everything. An Entra Temporary Access Pass can be set to one-time use with a lifetime as short as 10 minutes, and tokens issued during a TAP sign-in are capped at the TAP's expiry.
  4. Require re-authentication for sensitive changes. Okta Protected Actions and step-up authentication on admin consoles mean a freshly reset account cannot change identity providers or policies without another challenge.
  5. Notify the user and manager on every reset through a channel the attacker does not control.
  6. Make the agent's refusal safe, and back agents who end a call and call back through the directory. The account recovery path is part of authentication, and our help desk is the perimeter analysis lays out a verification ladder by request type.

Seen in the wild

The Identity Breach Report 2026 puts the talk-past share of human-account incidents at 38.2% (13 of 34) in 2025-2026.

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.