THREAT-EntraID-MFAFatigue

Multi-Factor Authentication Request Generation — Multi-Factor Authentication Fatigue (MFA Bombing) Attack

Credential Access Last updated:

MFA fatigue (also called MFA bombing or push flooding) is a social engineering technique where an attacker who has obtained valid credentials uses repeated MFA push notifications to wear down the victim into approving an authentication request out of annoyance or confusion. Scattered Spider pioneered this at scale, compromising MGM Resorts, Caesars Entertainment, and numerous UK-based organisations. The attacker sends dozens of Authenticator app push notifications in rapid succession, sometimes at 3am to catch sleeping victims, until one is approved. Some variants include calling the victim while bombing, claiming to be IT support (vishing), and guiding them to approve the 'legitimate' request. NCSC and CISA issued a joint advisory on this technique in 2023. With valid M365 credentials available from password spray or phishing, MFA fatigue is the primary way Scattered Spider bypasses MFA.

What is THREAT-EntraID-MFAFatigue Multi-Factor Authentication Fatigue (MFA Bombing) Attack?

Multi-Factor Authentication Fatigue (MFA Bombing) Attack (THREAT-EntraID-MFAFatigue) is a sub-technique of Multi-Factor Authentication Request Generation (T1621) in the MITRE ATT&CK framework. It maps to the Credential Access tactic — the adversary is trying to steal account names and passwords.

This page provides production-ready detection logic for Multi-Factor Authentication Fatigue (MFA Bombing) Attack, covering the data sources and telemetry it touches: Azure AD Sign-In Logs (AADSignInLogs), Microsoft Authenticator logs, Entra ID Identity Protection. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Credential Access
Microsoft Sentinel / Defender
kusto
// THREAT: MFA Fatigue / MFA Bombing Detection
// Detects rapid repeated MFA requests for the same user — push flooding pattern
// Primary telemetry: Azure AD Sign-in logs, MFA request events

// Alert 1: High volume of MFA requests for single user in short window
let MFAFatigueThreshold = 5; // Number of MFA prompts within window
let MFAFatigueWindow = 10m;
AADSignInLogs
| where TimeGenerated > ago(24h)
| where AuthenticationDetails has "MFA" or AuthenticationRequirement =~ "multiFactorAuthentication"
| where Status.errorCode in (
    0,      // Success
    50074,  // StrongAuthenticationRequired
    50076,  // MFA required
    500121, // Authentication failed during strong auth
    500133  // User did not complete MFA
  )
| summarize
    MFAAttempts=count(),
    Approvals=countif(Status.errorCode == 0),
    Denials=countif(Status.errorCode == 500121),
    NoResponses=countif(Status.errorCode == 500133),
    IPs=make_set(IPAddress),
    Locations=make_set(Location),
    Apps=make_set(AppDisplayName)
  by UserPrincipalName, bin(TimeGenerated, MFAFatigueWindow)
| where MFAAttempts >= MFAFatigueThreshold
| extend FatiguePattern = (Denials > 3 and Approvals == 1) or (NoResponses > 4 and Approvals == 1)
| where MFAAttempts >= MFAFatigueThreshold
| extend ThreatType = "MFA_Fatigue_PushBombing"
| extend ThreatActors = "Scattered Spider, Lapsus$"
| sort by MFAAttempts desc;
// Alert 2: MFA approval following high failure rate (fatigue success indicator)
AADSignInLogs
| where TimeGenerated > ago(24h)
| where Status.errorCode == 0
| where AuthenticationRequirement =~ "multiFactorAuthentication"
| join kind=inner (
    AADSignInLogs
    | where TimeGenerated > ago(24h)
    | where Status.errorCode == 500133  // MFA not completed (prior denials/timeouts)
    | summarize PriorDenials=count() by UserPrincipalName
    | where PriorDenials >= 3
  ) on UserPrincipalName
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
    AppDisplayName, PriorDenials
| extend ThreatType = "MFA_Fatigue_SuccessAfterDenials"

Dual detection: (1) User receiving 5+ MFA prompts in a 10-minute window — the push bombing pattern used by Scattered Spider and Lapsus$; (2) Successful MFA approval following 3+ prior MFA denials/non-responses — the 'fatigue success' indicator where the victim eventually approved. The second alert is higher severity as it indicates likely compromise.

high severity high confidence

Data Sources

Azure AD Sign-In Logs (AADSignInLogs) Microsoft Authenticator logs Entra ID Identity Protection

Required Tables

AADSignInLogs

False Positives

  • Users with intermittent mobile connectivity who have multiple MFA push notifications queued and delivered in rapid succession
  • Automated system accounts or service principals that trigger MFA in rapid succession during batch processing
  • MFA enrollment flows that trigger multiple notifications during the enrollment wizard
  • Users testing their own MFA setup by repeatedly triggering and denying prompts

Sigma rule & cross-platform mapping

The detection logic for Multi-Factor Authentication Fatigue (MFA Bombing) Attack (THREAT-EntraID-MFAFatigue) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 1 adversary technique from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate MFA Push Bombing via Microsoft Authentication Library

    Expected signal: Azure AD Sign-in logs record 10 MFA prompts for the target user within a 5-minute window, each showing error code 50076 (MFA required) or 500133 (not completed).


Response Playbook

Triage

  1. Contact the affected user directly via phone (NOT via Teams or email — the account may be compromised). Ask if they received unusual MFA push notifications and whether they approved any.
  2. If the user confirms receiving unexpected MFA pushes, treat as active MFA fatigue attack in progress. Disable legacy auth and block the attacker IP immediately.
  3. Check Azure AD sign-in logs for the attacker's source IP: is this a known VPN exit node, Tor, or residential proxy? This helps attribute the attack vector.
  4. Determine if the user's password was obtained via a prior password spray (check for spray activity against this user's account in the preceding 24-48 hours).
  5. If MFA was ultimately approved: treat as compromised account. Check MailItemsAccessed, Teams messages, and SharePoint activity from the attacker's IP.

Containment

  1. Disable the user's account immediately while investigating if MFA approval was detected.
  2. Block the attacker IP in Entra ID Named Locations.
  3. Enable 'Number Matching' in Microsoft Authenticator if not already deployed — this requires the user to enter a number shown on the sign-in screen into the Authenticator app, defeating push bombing.
  4. Enable 'Additional context' in Microsoft Authenticator to show the application name and location on the MFA push — makes fake MFA requests obvious to users.
  5. Consider migrating from push notifications to FIDO2 security keys or certificate-based authentication — these cannot be fatigue-bombed.

Evidence Collection

  1. Azure AD Sign-in logs: all MFA events for the affected user over the incident window
  2. Microsoft Authenticator logs (if Intune-managed device): push notification delivery timestamps
  3. Entra ID Identity Protection risk events for the user
  4. Network logs from corporate proxy showing attacker IP activity

Escalation Criteria

  • ! MFA approval confirmed following 3+ denials — user likely approved out of fatigue
  • ! Simultaneous vishing call to user while push bombing is detected (caller claims to be IT helpdesk)
  • ! User account is a Global Admin, Security Admin, or privileged account
  • ! Post-approval activity: sign-in from attacker IP accessing SharePoint, Exchange, or Teams

Investigation Guide

Forensic Artifacts

  • > Azure AD Sign-in logs for the user: MFA prompt/denial/approval sequence with source IPs
  • > Microsoft Authenticator notification history (from Intune MDM policy if managed)
  • > Entra ID audit logs: any MFA method changes after the fatigue event
  • > Call logs: did user receive phone calls coinciding with push bombing (vishing component)?
  • > O365 audit logs: post-compromise activity if MFA was approved

Tuning Guidance

The 5-prompt threshold in 10 minutes is appropriate for most SMBs. Users who use MFA regularly may occasionally trigger 2-3 prompts due to connectivity, but 5+ in 10 minutes is strongly anomalous. The 'fatigue success' detection (approval following denials) is the highest-fidelity alert and should be treated as critical. Consider enabling Microsoft Authenticator's 'Report Suspicious Activity' feature which automatically marks risky sign-ins and disables the user account — this provides automatic containment.


Hunting Queries

Hunt for users with high rates of unresponded MFA prompts over 30 days — may indicate ongoing low-slow MFA fatigue campaign or users who routinely ignore unexpected prompts (a risk indicator regardless).

Hunting — KQL
kql
AADSignInLogs
| where TimeGenerated > ago(30d)
| where Status.errorCode == 500133  // MFA not completed
| summarize
    MFASkips=count(),
    Days=dcount(bin(TimeGenerated, 1d)),
    IPs=make_set(IPAddress)
  by UserPrincipalName
| where MFASkips > 10
| sort by MFASkips desc
Hunting — SPL
spl
index=azure sourcetype="azure:aad:signin" properties.status.error_code=500133
| stats count AS MFASkips, dc(bin(_time, 86400)) AS Days
  BY properties.user_principal_name
| where MFASkips > 10
| sort - MFASkips

Atomic Red Team Tests

Test 1 Simulate MFA Push Bombing via Microsoft Authentication Library
linux

Simulates MFA fatigue by programmatically triggering multiple MFA push notification requests for an account with known credentials. This tests detection of rapid MFA prompt generation.

Command

bash
python3 -c "
import requests, time
for i in range(10):
    r = requests.post('https://login.microsoftonline.com/<TENANT>/oauth2/v2.0/token',
        data={'client_id':'d3590ed6-52b3-4102-aeff-aad2292ab01c',
              'grant_type':'password','username':'<USER>','password':'<KNOWN_PASSWORD>',
              'scope':'openid'})
    print(f'Attempt {i+1}: {r.status_code}')
    time.sleep(30)
"

Expected Telemetry

Azure AD Sign-in logs record 10 MFA prompts for the target user within a 5-minute window, each showing error code 50076 (MFA required) or 500133 (not completed).

Expected Detection

Alert fires at 5+ MFA prompts within 10 minutes for the same user.

Related Detections