An MFA fatigue attack runs in two places at once, and I've caught myself watching only one of them. In the identity provider logs I get a run of push denials against a valid password, then an approval from the same address, and my first instinct is always to read that as routine, a fat-fingered retry, not an attack in progress. What never reaches a log is the other half: an employee's phone buzzing in the middle of the night until they tap approve to make it stop.
That case taught me that an MFA fatigue attack is two attacks running at once. One happens in the identity provider logs, where the security operations center (SOC) can see it. The other happens on an employee’s phone at 1 am local time, where nobody sees it at all.
SOC guidance often centers on the identity-provider log sequence. But nobody’s monitoring a personal phone, and that’s the half detection engineers have to design into.
In brief:
- MFA fatigue starts after the attacker already holds a valid password, so the prompts are real prompts from the real identity provider, which is why email and endpoint telemetry stay quiet.
- Failed pushes that flip to a single approval create the detectable sequence, and that sequence lives only in identity provider logs. Each event in the chain looks routine on its own.
- The make-it-stop approval is a documented human failure mode. Habituation research shows attention to warnings drops after only two to three exposures, and training cannot keep attention from degrading under repeated prompts.
- The working detection ties push-denial velocity to a flip-to-success, then uses a sign-in anomaly to split response by severity.
The textbook definition says an MFA fatigue attack is an adversary with valid credentials generating repeated push notifications until the user approves one, cataloged as MITRE ATT&CK T1621 under Credential Access. That's accurate and mostly useless, because it frames the attack as a user susceptibility problem. Operationally, it's a sequencing problem for the SOC and an attention-depletion problem for the target, and the detection has to account for both.
How an MFA fatigue attack actually starts
Every MFA fatigue attack starts with valid credentials the attacker already owns. In the September 2022 Uber breach, the contractor's corporate password was likely bought on the dark web after malware infected a personal device. Lapsus$ used stolen passwords to trigger simple-approval prompts and waited for the user to consent. The same mechanic appeared in suspected Russian activity: repeated authentication attempts in short succession until the user accepted.
Microsoft's 2023 Digital Defense Report clocked roughly 6,000 MFA fatigue attempts per day, and the Verizon DBIR found prompt bombing showing up at a higher rate than any other MFA bypass technique in its breach dataset., and the Verizon Data Breach Investigations Report (DBIR) found prompt bombing showing up at a higher rate than any other MFA bypass technique in its breach dataset. Scattered Spider and APT29 carry T1621 in MITRE procedure examples. The password comes first, and the barrage is just the last mile.
What the SOC sees in the logs
The logs show a distinct sequence only when the detection reads sequences rather than events. The burst pattern matters first, sequencing comes next, and the evidence stays inside the identity provider. Miss any one of those properties and the rule either goes noisy or blind.
The denial and the approval both leave a distinct signature, but the exact field names shift by platform and engine version:
- Okta Classic Engine: denials land as user.mfa.okta_verify.deny_push.
- Okta Identity Engine: the same denial becomes user.authentication.auth_via_mfa with outcome.result="FAILURE", outcome.reason="INVALID_CREDENTIALS", and debugContext.debugData.factor="OKTA_VERIFY_PUSH".
- Entra ID: the failed challenge code is ResultType = 500121, with authentication step detail distinguishing a declined authentication from one where the user never responded to the notification.
- The approval that ends the barrage, in either platform, looks like any other success: user.authentication.sso or user.session.start with outcome.result == "SUCCESS" in Okta, or ResultType = 0 in Entra.
I learned the hard way that an Okta timed-out push generates no log entry at all. A user who ignores the barrage instead of denying it leaves the SOC with a much thinner trail than one who mashes deny, and those timeout gaps make the sequence harder to prove.
The sequence carries the signal
A failed push is routine, and a successful MFA event is the most common thing in the log. The sequence drives the aggregation and detection logic. Denials-then-approval inside a tight window create the detectable object, ideally with a velocity that no human generates by accident.
There's a false-negative trap inside Entra. When an attacker issues multiple MFA challenges within a single authentication session, the events share the same CorrelationId and the AuthenticationDetails array gets updated in place rather than producing separate records. Single-session prompt bursts mean rules counting distinct sign-in records miss these entirely, so the rule has to parse the array and count distinct prompts per session.
Identity provider logs carry the evidence
The login gives email security no phishing message to catch and no payload to detonate. The attacker authenticates against the real identity provider with real credentials, so email security sees nothing and the endpoint sees a normal login result. Endpoint detection and response (EDR) sees the login outcome, not the authentication anomaly. If identity provider logs aren't flowing into the security information and event management (SIEM) platform with enough granularity to separate push denials from generic auth failures, the attack is invisible until post-compromise activity starts.
What the user experiences before they click
While the SOC sees a tidy event sequence, the target experiences something closer to harassment. Both the timing and the eventual approval are engineered, and the fMRI and warning studies below make the outcome look closer to inevitable than careless. Detection design needs to account for the user-side sequence before the postmortem.
Prompt bombing wears people down, and off-hours is the point
The Uber contractor's barrage arrived in rapid succession during the middle of the night and ran for roughly an hour. Public accounts describe a follow-up WhatsApp message from someone posing as Uber IT, claiming the login system had a bug and that accepting the notification would reset it and stop the prompts. The contractor complied. Cisco's own breach followed the same shape: compromised credentials from a synced personal Google account, then voice phishing plus push spam until an employee accepted.
The attack depends on off-hours timing. By late evening, a person has burned through a full day of decisions, and circadian processes reduce the brain's capacity for deliberate choice. An attacker who fires the barrage at 1 am is betting the target is exhausted, and it's a good bet.
The make-it-stop approval follows a human failure mode
fMRI work on security warnings measured repetition suppression directly: neural response to repeated stimuli drops, and a PMC-indexed warning study found attention decreases after two to three exposures. In a large field study of browser warnings, 47% of click-throughs happened within 1.5 seconds. And first unexpected push approvals happen for about 1% of users, which, against a barrage, is enough to explain why attackers keep trying.
CISA's number matching guidance describes both outcomes, accidental approval and approval out of annoyance. The deeper issue is approval debt: push-based MFA repeatedly spends the user's attention on a security decision until the decision stops being careful. I've called targets the morning after these incidents, and the pattern was always fatigue, tired people trying to get back to sleep. A control that depends on a human staying alert longer than an attacker will wait is broken, and no awareness module repairs it.
The detection I actually write for this
The first version of my rule counted failures only, which is why the 2:40 am case nearly slid past me. The version I run now requires a denial burst that flips to success, plus at least one anomaly that separates an attack from a user having a bad night with their phone. The anomaly is what turns a pattern into an incident.
Correlate push velocity with a failed-then-approved sequence and a sign-in anomaly
For Okta, the Elastic prebuilt rule captures the sequence cleanly and handles both engine variants, which matters because Classic event types miss Okta Identity Engine (OIE) denial events. I keep it close to the vendor rule because the engine split is where homegrown detections usually break. Denial events should terminate only when the same identity later succeeds.
sequence by okta.actor.id with maxspan=10m
[ any where data_stream.dataset == "okta.system"
and (
okta.event_type == "user.mfa.okta_verify.deny_push"
or (
okta.event_type == "user.authentication.auth_via_mfa"
and okta.debug_context.debug_data.factor == "OKTA_VERIFY_PUSH"
and okta.outcome.reason == "INVALID_CREDENTIALS"
)
)
] with runs=5
until
[ any where data_stream.dataset == "okta.system"
and okta.event_type in (
"user.authentication.sso",
"user.authentication.auth_via_mfa",
"user.authentication.verify",
"user.session.start"
)
and okta.outcome.result == "SUCCESS"
]
That Okta sequence rule is a solid base. For Entra ID, I aggregate failed MFA challenges (ResultType == 500121) by user and IP in a 30-minute window, join to a successful MFA event on the same identity and IP, and parse the AuthenticationDetails array to count prompts inside a single CorrelationId instead of counting records. The rule uses a sign-in anomaly, especially new geolocation against the user's baseline or off-hours activity for their timezone, to keep from paging on retries.
What to alert on, what to auto-contain, what to escalate
Response boundaries should be explicit in the playbook before the rule ships. A failed barrage should not get the same treatment as a successful compromise, and the on-call analyst needs permission to move fast when the approval has already happened.
- Alert triage only: three or more push denials from one identity within 30 minutes, no success. A published Red Canary threshold is three or more pushes followed by successful auth in a 30-minute window, tuned for false positive rates rather than as a universal cutoff. A pure denial burst means the barrage failed, so investigate, warn the user, and force a password reset on their schedule.
- Auto-contain: the burst flips to success and the sign-in carries an anomaly. Revoke sessions and refresh tokens immediately and force a credential reset. In Entra that's session revocation with Revoke-MgUserSignInSession; in Okta, Workflows can trigger Clear User Session and Reset Password automatically on the anomalous push pattern. The approval was seconds ago, and containment speed is the whole game.
- Escalate to incident response (IR): any post-approval persistence behavior, including new MFA device enrollment (device.enrollment.create in Okta), new app registrations, mailbox rule or forwarding changes, and consent grants. Microsoft's incident responders single out device enrollment, because it converts a one-time approval into durable access.
What I do in the first ten minutes after it fires
Revoke active sessions and refresh tokens first, then reset credentials and review MFA inventory. The Microsoft Defender extended detection and response (XDR) playbook sequence is the right shape. Review every registered device and method and remove anything unrecognized, because the attacker's first post-approval move is usually enrolling their own factor. Then run the lateral checks: inbox rules, forwarding, consent grants, admin roles. In my last SOC, I ran this from a Slack thread with the Okta admin on one side and the user on the phone, and containment held because the sequence was written down before the incident.
The longer fix is structural, and CISA has already made the call: phishing-resistant MFA such as FIDO2/WebAuthn resists push bombing and SIM swap, with number matching as the interim mitigation. Microsoft enforced number matching in 2023, while Okta's number challenge and Duo's Verified Push stay opt-in, so someone in your org has to turn them on. Until then, the detection above is the control. The person who approved the fifth push at 1 am did exactly what the research predicted, and my job is to make sure the rule fired first.
Frequently asked questions about MFA fatigue attacks
These are the questions that come up when a team turns the pattern into a rule and a playbook. The answers assume the attacker already has the password and the SOC is working from identity-provider telemetry.
How do I recognize an MFA fatigue attack in identity logs?
An MFA fatigue attack, or push bombing, is when an attacker who already holds a valid stolen password repeatedly triggers real MFA push notifications until the target approves one by accident or out of annoyance. It's cataloged as MITRE ATT&CK T1621 under Credential Access. MITRE's T1621 procedure examples list Lapsus$ and Scattered Spider, and the technique also appeared in the 2022 Uber and Cisco breaches.
How is MFA fatigue different from phishing?
In phishing, the attacker deceives the user into entering credentials on a fake page. In MFA fatigue, the attacker already has valid credentials and every prompt comes from the real identity provider, which is why email security and endpoint tools see nothing. It also differs from adversary-in-the-middle (AiTM) token theft, which proxies the whole login and steals the session cookie without needing the user to approve anything.
Which MFA methods actually stop push bombing?
FIDO2/WebAuthn and public key infrastructure (PKI)-based MFA, which CISA classifies as phishing-resistant MFA, resist push bombing. Number matching is CISA's recommended interim mitigation: Microsoft enforces it for all Authenticator push users, while Okta's number challenge and Duo's Verified Push are opt-in by default. Number matching stops blind approvals, but AiTM phishing can still work around it, so treat it as a bridge toward phishing-resistant MFA.
What should the SOC do the moment a fatigue pattern fires?
If the pattern includes a successful approval, revoke all sessions and refresh tokens first. Force a password reset next, then review the account's registered MFA devices and remove anything unrecognized. Hunt for post-approval persistence immediately: new device enrollment, mailbox rules, app registrations, and consent grants. If any of those appear, escalate under your incident response plan, because the attacker has moved past the login and is building durable access.