Helpdesk Social Engineering and MFA Resets in Okta

TL;DR. The attacker phones the service desk as the victim and asks for a password or MFA reset. In the System Log that is a user.mfa.factor.reset_all, user.mfa.factor.deactivate or user.account.reset_password whose actor is not the target, followed within hours by a user.mfa.factor.activate for the target, usually from a network that user has never used. Reset plus new factor is worth a look; reset plus new factor from a new ASN, a hosting provider or a proxy is an incident. If the victim is an administrator, assume the next step is privilege abuse and a rogue identity provider.

Why this works so well

Strong MFA protects the sign-in, not the recovery process around it. When a caller convincingly claims to be an employee who lost their phone, a well-meaning agent does what the process allows: resets the factors so the "employee" can enroll a new device. The attacker then enrolls their device and owns the account, MFA included.

This is not hypothetical. In 2023 Okta Security reported attackers calling IT service desks to have all MFA factors of highly privileged users reset, then using those accounts to take over Super Administrator access (Okta Security: cross-tenant impersonation). The CISA/FBI advisory on Scattered Spider describes the group impersonating employees and IT staff in calls to help desks (CISA AA23-320A). MITRE ATT&CK covers the pieces as T1656 Impersonation, T1098.005 Device Registration and T1556.006 Multi-Factor Authentication.

The sequence in the System Log

#	eventType	Actor	Target	What to note
1	`user.session.access_admin_app`	helpdesk agent	Admin Console	the agent's normal session
2	`user.account.reset_password`	helpdesk agent	victim	actor ≠ target
3	`user.mfa.factor.reset_all`	helpdesk agent	victim	all factors gone
4	`user.session.start`	victim	—	new IP, new ASN, new user agent
5	`user.mfa.factor.activate`	victim	victim + factor	the attacker's device
6	`user.authentication.auth_via_mfa`	victim	—	now passing MFA with their own factor
7	`user.session.access_admin_app`	victim	Admin Console	if the victim is an admin

Steps 2 and 3 are indistinguishable from legitimate support in isolation: factor resets are routine. It is steps 4 and 5 that give the attack away, and specifically where they come from.

One more tell: the real user usually finds out later, when their password no longer works. A few user.session.start failures with INVALID_CREDENTIALS from the user's usual network, hours after the reset, are the victim trying to sign in.

How the analyzer detects it

The Okta Forensics analyzer has two rules for this pattern:

Rule	Logic	Severity
`mfa.factor_reset_by_admin`	any password or factor reset where actor ≠ target	low (informational)
`mfa.helpdesk_reset_then_enroll`	such a reset, then a successful `user.mfa.factor.activate` by the target within 24 hours	high
— escalation	the enrollment comes from a network (ASN, or IP when no ASN) the user had not used before the reset, or from a proxy, a hosting provider, or an IP ThreatInsight flagged	critical

The low rule exists so the timeline always shows who reset whom; it does not change the verdict on its own. The sequence rule is what raises it. "Never used before" is computed from the export itself, which is why a longer export (weeks before the reset) makes the escalation more reliable. See limits and tuning.

Separating attack from support work

For each hit, answer these four questions:

Is there a ticket? A real reset has a ticket, a caller ID, and an agent who remembers the call. Ask the agent how identity was verified.
Where did the enrollment come from? Look at client.ipAddress, securityContext.asOrg and client.userAgent.rawUserAgent on the user.mfa.factor.activate. Compare with the user's sign-ins over the previous weeks. A VPS provider, a country the user has never worked from, or a Linux desktop for a user who always uses a managed Windows laptop is decisive.
What did the account do next? SSO targets, Admin Console access, admin actions. A regular user who opens their mail and their HR app is reassuring. An admin who immediately grants roles is not.
Does the user confirm? Call them on a number from the HR system, not the one the caller gave.

If the victim is an administrator

Treat it as a tenant compromise until proven otherwise. Pivot on the victim as actor from the enrollment onwards and look for:

user.account.privilege.grant / group.privilege.grant, especially Super Administrator (Super administrator);
system.api_token.create;
system.idp.lifecycle.create and routing rule changes;
policy, authenticator and network zone changes.

The fictional incident walkthrough is exactly this chain: a helpdesk reset for an IT admin, an enrollment from a VPS, then a Super Administrator grant and a new identity provider.

Containment

Clear the victim's sessions; revoke tokens.
Remove the attacker's factor; reset password and factors; re-enroll the real user in person or through a strongly verified channel.
Review every admin assignment, token and identity provider created after the reset.
Investigate applications opened in the attacker's session.

Hardening the helpdesk

Okta's guidance after the 2023 campaign includes restricting what help desk staff can do and strengthening identity verification before resets (Okta Security). In practice:

Verification that a caller cannot research: call-back on a number from the HR system, manager approval, or an in-person or video check with ID. Personal details from social networks are not verification.
Stricter process for administrators: no phone-only resets for admin accounts, ever.
Alert on the sequence, not on resets alone: reset by someone else plus enrollment from a new network, paged to someone who can call the user.
Phishing-resistant authenticators for admins, bound to managed devices, so a reset alone does not let the attacker enroll just anything.