MFA Fatigue

What MFA Fatigue Is and Why Push Bombing Works

MFA fatigue (or push bombing) is an attack where an adversary with valid credentials bombards the target user with multi-factor authentication push requests — typically via phone notification, SMS, or voice call — until the user approves one, either by accident, to stop the notifications, or because they mistakenly believe it is legitimate.

The attack requires only two things: the user’s valid password (obtained via credential stuffing, phishing, or a prior breach) and the user’s phone number or authenticator registration. The MFA app does the rest — the attacker just keeps clicking “send push” until the user breaks.

MITRE ATT&CK maps this to T1110.004 (Credential Stuffing) and T1621 (Multi-Factor Authentication Request Generation).

Why It Works

The technique rose to global prominence in the September 2022 Uber breach, where the Lapsus$ group compromised an external contractor by flooding them with MFA push requests for over an hour until the contractor accepted one, accompanied by a WhatsApp message claiming to be from Uber IT.

Detection — Finding MFA Fatigue in Azure AD / Microsoft Entra ID Logs

MFA fatigue attacks leave clear forensic traces. The challenge is that a single successful MFA approval looks identical to a legitimate login. The detection lies in the pattern — not the individual event.

Key Azure AD Sign-In Log Fields

The SignInLogs table in Azure Log Analytics is the primary detection source. Key fields:

Detection Queries

KQL — Detect MFA Fatigue (Multiple Failed + One Success)

// Find users who had many MFA-denied sign-ins followed by a successful one
SigninLogs
| where TimeGenerated > ago(1h)
| where AuthenticationRequirement == "multiFactorAuthentication"
| summarize
    FailedAttempts = countif(Status != "Success"),
    SuccessfulAttempts = countif(Status == "Success"),
    IPAddresses = make_set(IPAddress),
    Locations = make_set(Location)
    by UserPrincipalName, bin(TimeGenerated, 1m)
| where FailedAttempts >= 5 and SuccessfulAttempts >= 1
| project UserPrincipalName, FailedAttempts, SuccessfulAttempts, IPAddresses, Locations

This query finds users who received 5+ MFA push denials within a 1-minute window followed by at least one success — the classic MFA fatigue pattern.

KQL — Detect MFA from Unfamiliar Location

SigninLogs
| where TimeGenerated > ago(6h)
| where AuthenticationRequirement == "multiFactorAuthentication"
| where Status == "Success"
| where IPAddress !in (
    SigninLogs
    | where TimeGenerated > ago(14d)
    | where UserPrincipalName == "targetuser@domain.com"
    | project IPAddress
    | distinct IPAddress
)
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, DeviceDetail

KQL — Identify SSPR-Based MFA Fatigue

AuditLogs
| where TimeGenerated > ago(1h)
| where OperationName == "Self-service password reset"
| where Result == "Success"
| summarize ResetCount = count() by UserPrincipalName, bin(TimeGenerated, 5m)
| where ResetCount >= 3

Windows Security Event IDs for MFA-Related Detection

MFA events themselves are logged by the identity provider (Azure AD, Duo, Okta). However, once the attacker gains access, Windows Event Logs on the target endpoint catch the aftermath:

Duo / Okta Detection Patterns

Duo — Logs every push notification, including device platform, location, and whether the push was approved or denied. Key signal: multiple denied pushes followed by an approval from an unfamiliar device or location.

Okta — System Log events policy.evaluate_sign_on and user.authentication.authenticate with factorResult=CHALLENGE (MFA required). High count of DENY results followed by ALLOW from a new IP is the pattern.

Prevention — Stopping MFA Fatigue Before It Starts

Response — When MFA Fatigue Succeeds

If a user confirms they approved an unexpected MFA push (or the detection query above fires), execute the following steps immediately:

1. Force password reset for the affected user. Do not allow the same password.
2. Invalidate all current sessions — revoke refresh tokens and session cookies in Entra ID.
3. Review sign-in logs for the past 24–72 hours. The attacker may have accessed multiple applications.
4. Check mailbox rules — attackers often create forwarding rules or inbox rules to hide activity (look for New-InboxRule in Exchange admin audit logs).
5. Audit Azure AD / Okta / Duo logs for privileged role changes, application registrations, or service principal modifications.
6. Review EDR telemetry on the user’s endpoint for processes spawned after the login session — the attacker may have deployed persistence.
7. Report to CISA if the organization is in a critical infrastructure sector (see CISA Alert AA22-074A).

Walkthrough — A Realistic MFA Fatigue Incident

Scenario: A mid-sized law firm uses Microsoft Authenticator push notifications for MFA. An attacker obtains the CFO’s password from a credential stuffing site.

Related

• MITRE ATT&CK for Triage — covers the mitre att&ck for triage concepts
• Credential Stuffing — detection and response for T1110 techniques
• Azure Sentinel — detection and response for T1654 techniques
• Sigma Rules — detection and response for T1059, T1110 techniques
• Active Directory Basics — covers the active directory basics concepts

Sources

• MITRE ATT&CK T1110.004
• MITRE ATT&CK T1621
• CISA — MFA Fatigue Alert AA22-074A
• Microsoft — MFA Number Matching
• Mandiant — Russian Targeting of Government and Business