MFA Fatigue Attack Detection in Okta System Logs

TL;DR. MFA fatigue (push bombing) shows up in the System Log as a burst of system.push.send_factor_verify_push for one user, with rejections logged as user.mfa.okta_verify.deny_push on Classic Engine or as failed user.authentication.auth_via_mfa on Identity Engine, sometimes ending with one accepted push. Five or more in 15 minutes is a reasonable alert; an accepted push right after the burst is an incident. The attacker already has the password, so reset it, clear sessions, reset factors, and turn on number challenge.

How the attack works

The attacker has a valid password (phished, reused, bought, sprayed). The account requires an Okta Verify push. So they trigger sign-ins again and again until the user, tired, confused or reassured by a fake "IT support" call, taps Approve. MITRE ATT&CK tracks this as T1621, Multi-Factor Authentication Request Generation. The joint CISA/FBI advisory on Scattered Spider lists repeated MFA prompts leading employees to accept them among the group's techniques (CISA AA23-320A).

Nothing is exploited. The logs just show a user who received far more prompts than a human generates.

What it looks like in the System Log

The Classic/OIE split is documented in Okta's event types catalog: the deny_push entry says Identity Engine uses the generic auth_via_mfa failure instead. Okta Security's own push-fatigue Workflows use exactly these two queries, one per engine, with a default of more than five rejections within an hour (Okta Security: responding to anomalous push requests).

A typical burst, simplified:

09:12:03  system.push.send_factor_verify_push   j.doe   203.0.113.50
09:12:31  user.authentication.auth_via_mfa      j.doe   FAILURE  factor=OKTA_VERIFY_PUSH
09:13:10  system.push.send_factor_verify_push   j.doe   203.0.113.50
09:13:40  user.authentication.auth_via_mfa      j.doe   FAILURE
09:15:02  system.push.send_factor_verify_push   j.doe   203.0.113.50
...
09:21:47  user.authentication.auth_via_mfa      j.doe   SUCCESS   ← the one that matters

Note the IP: every push is triggered by the attacker's sign-in, so client.ipAddress on those events is the attacker's, not the user's phone.

A detection you can defend

The rule in the Okta Forensics analyzer (mfa.push_fatigue) is:

Why these numbers: a real sign-in produces one push, maybe two if the phone was slow. Five in a quarter of an hour is well outside normal behaviour, but low enough to catch a patient attacker who spaces the prompts. Okta's Workflow template uses a wider one-hour window; if you tune your own SIEM rule, test both against your own data.

Things that look like push fatigue but are not

• A user signing into many apps with strict per-app MFA, in a short time, on a morning after a password change. The pushes are all accepted and come from the user's usual network. Look at the outcomes and the IP.
• A broken device (notifications delayed, then delivered in a batch). The user retries; you see sends without rejections.
• Shared service accounts with push MFA (a bad idea in itself).

The discriminators are the source network of the triggering sign-ins, the ratio of rejections to approvals, and whether the user can explain it. Call them on a known number.

Investigating a hit

1. Pull every event for the user for the day. Which IP and ASN triggered the pushes? Is it a hosting provider or an anonymizer (securityContext.isProxy, debugData.tunnels)?
2. Was a push accepted? If yes, find the session (authenticationContext.externalSessionId) created by that approval and list everything it did: SSO targets, factor enrollment, Admin Console access.
3. Did the attacker enroll their own factor? A user.mfa.factor.activate from the attacker's IP means they no longer need the user's approval. That is the same foothold as in helpdesk social engineering.
4. Did the user report it? user.account.report_suspicious_activity_by_enduser shows up when users use the reporting link in Okta's security notification emails (Okta Help Center). It is a precious signal: treat it as a high-severity finding.
5. Look for the same source elsewhere. An attacker who has one password often has several. Pivot on the IP in the entity view.

Containment and hardening

In order:

1. Clear the user's sessions and revoke tokens.
2. Reset the password (the attacker has it) and the factors; re-enroll through a verified channel.
3. Remove any factor enrolled from the attacker's network.
4. Investigate the applications opened with the approved session.

Then close the door:

• Number challenge. Okta Verify can require the user to pick the number shown on the sign-in screen, for all push challenges or only for high-risk ones (Okta Help Center: Okta Verify options). CISA recommends number matching as an interim mitigation for push-based MFA (CISA fact sheet).
• Phishing-resistant authenticators (what that means) for administrators first, then everyone: there is no prompt to approve.
• Suspicious activity reporting enabled, and a runbook that acts on it the same day.

FAQ

Which Okta event shows a rejected push?

On Classic Engine, user.mfa.okta_verify.deny_push. On Identity Engine, a user.authentication.auth_via_mfa event with a FAILURE outcome and an Okta Verify push factor in debugData. Watch both.

Does MFA fatigue mean the password is compromised?

Almost always. The push is the second factor: the attacker usually had to pass the password step to trigger it. Reset the password as well as the factors.

What stops push bombing?

Number challenge on Okta Verify pushes reduces blind approvals; phishing-resistant authenticators such as Okta FastPass or FIDO2 keys remove the approve-a-prompt step altogether.

Further reading

• Okta Security: using Workflows to respond to anomalous push requests
• MITRE ATT&CK T1621
• Okta compromise investigation guide
• Detection limits and tuning