MFA fatigue — also called push-bombing or MFA request generation (MITRE T1621) — is one of the highest-volume identity alerts a modern SOC handles. The attacker already holds a valid password (from password spray, a credential leak, or a prior phish) but is stopped at the MFA prompt, so they hammer the account with authentication requests until the exhausted or confused user finally approves one. Once inside, the attacker's near-universal next move is persistence via MFA method registration: adding their own authenticator app or phone number to the victim's account so a password reset alone no longer locks them out.
Treat a denial burst that is followed by a successful sign-in from an unfamiliar location, or any new MFA method registered from a session the user does not recognise, as a SEV1 account-takeover in progress. The single most common way this class of incident slips through triage is an analyst closing it as "the user just fat-fingered their token" without ever checking whether a new authentication method was quietly added.
Primary data sources: SigninLogs and AADNonInteractiveUserSignInLogs (MFA challenge/denial ResultTypes, location, risk), AuditLogs (Authentication Methods service — security info registered/deleted, device registration), and AADUserRiskEvents for Entra ID Protection correlation.
☰ Table of Contents
01 — BACKGROUND
TECHNIQUE OVERVIEWPush-bombing exploits the human at the end of the MFA prompt, not a technical flaw in MFA itself. Because the attacker already has valid credentials, every failed sign-in is a genuine authentication attempt that Entra ID scores and logs — the account is one careless tap away from compromise. Microsoft's default number matching for Authenticator (enforced since 2023) makes a blind "approve" far harder, so today's operators pair the request flood with a social-engineering call ("IT here, please approve the prompt") or pivot to help-desk manipulation to get MFA reset outright.
The persistence half of this incident class is MFA method registration abuse (T1556.006 / T1098.005): after a successful sign-in, the attacker registers a new phone or authenticator as an approved method. This survives the victim's password reset and lets the attacker re-authenticate at will — which is why eradication is not complete until every unrecognised method is removed.
| Field | Value |
|---|---|
| MITRE Techniques | T1621 — Multi-Factor Authentication Request Generation T1078.004 — Valid Accounts: Cloud Accounts T1556.006 — Modify Authentication Process: MFA T1098.005 — Account Manipulation: Device Registration |
| Kill-chain Phase | Credential Access → Initial Access → Persistence |
| Primary Log Source | SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs (Authentication Methods) |
| Secondary Log Sources | AADUserRiskEvents, AADRiskyUsers, IdentityInfo, OfficeActivity (post-access) |
| Decisive Signals | ResultType 500121 denial burst; success (ResultType 0) after the burst; new security info registered from unfamiliar session |
| Default Severity | SEV1 if approval + unfamiliar location, or any attacker-registered method; SEV2 for denied-only bursts |
| Detection Window | Query last 1 hour for live bursts; extend to 24h–7d for method-registration hunting |
Five concrete scenarios sit behind this alert class. The analyst's job in Identification is to place the current event in one of them:
| # | Attack Path | Severity |
|---|---|---|
| A1 | Valid password (spray/leak) → push flood → fatigued user approves → hostile session established | SEV1 |
| A2 | Valid password → push flood + social-engineering call → help-desk resets/re-registers MFA for attacker | SEV1 |
| A3 | Post-access persistence — attacker registers own authenticator/phone as a new approved method | SEV1 |
| A4 | Attacker deletes the legitimate MFA method to force re-registration or lock the user out | SEV2 |
| A5 | Genuine user — new phone, expired token, repeated mistaps — during working hours from a managed device | FP |
A denied-only burst (A-family without a following success) still means an attacker holds valid credentials for this account. It is never a clean close — it is a confirmed password compromise that has so far been stopped only by the user's finger. Force a password reset regardless.
Severity is driven by three questions answered in Identification: was there a successful sign-in after the burst, was it from an unfamiliar location / ASN / high risk, and was a new MFA method or device registered. Any one of the last two being true escalates to SEV1.
02 — IDENTIFICATION
5 INDICATORSAnswer these before touching a query — they decide whether this queues or pages someone now:
- 1Is there a burst of MFA denials (ResultType 500121) for one user in a short window (e.g. 5+ in 10 min)? → investigate as push-bombing.
- 2Was there a successful sign-in (ResultType 0) shortly after the denial burst? → assume the user capitulated; SEV1 candidate.
- 3Is the source IP/ASN/country unfamiliar for this user, or is RiskLevelDuringSignIn high? → account takeover, not fatigue.
- 4Was a new MFA method or device registered in AuditLogs around the same time? → persistence established, SEV1 regardless of anything else.
- 5Is the account privileged (Global Admin, Security Admin, exec, finance)? → page L2/IR in parallel, do not wait in queue.
Any YES to Q4 short-circuits the whole tree: a freshly registered authentication method from a session the user does not recognise is a confirmed compromise. Jump straight to Containment C2.
A cluster of MFA denials for a single account is the defining fingerprint of push-bombing. Each denial (ResultType 500121) means valid credentials passed but the second factor was declined or timed out — the attacker is knocking and the user keeps rejecting. Counting these per user in a tight window separates a genuine flood from an occasional mistap.
- 1Open Sign-in logs and filter User to the alerted UPN, Status to Failure.
- 2Add the Authentication requirement = multifactorAuthentication filter and inspect the Sign-in error code column for repeating
500121. - 3Open one failure → Authentication Details tab and read
authenticationStepResultDetail— "MFA denied; user declined the authentication" confirms an active push flood. - 4For SIEM-scale counting run the KQL below in security.microsoft.com → Hunting → Advanced Hunting or Sentinel Logs.
| ResultType / Field | Meaning | Analyst Action |
|---|---|---|
| 500121 | Authentication failed during strong-auth request — push denied, timed out, or number-match failed | Count per user; a burst = push-bombing |
| 50074 | Strong authentication required — MFA challenge was issued | Context; volume shows challenge rate |
| 50076 / 50079 | MFA required by policy / user must enroll (proof-up) | 50079 near a burst = forced-enroll attempt |
| 0 | Sign-in succeeded (MFA satisfied) | If it follows the burst = capitulation (I2) |
| authenticationStepResultDetail | "MFA denied; user declined the authentication" / "…in-progress" | Confirms the denial reason |
The moment that turns an attempted attack into a breach is a successful sign-in (ResultType 0) landing right after a denial burst — the fatigued user finally approved a prompt. Correlating the burst window against the next success, and comparing the location/device of that success to the denials, is the single decisive test in this SOP.
- 1Re-filter the same user to Status = Success and find the first success immediately after the last 500121 denial.
- 2Compare its IP address, ASN, and location to the denial events. A success from the same hostile IP that generated the flood is a confirmed takeover.
- 3Note the DeviceDetail (browser, OS, deviceId). An unmanaged / never-before-seen device on the success is corroborating evidence.
- 4Record the exact success timestamp — it anchors the session-revocation cutoff used in Containment C2 and the timeline in Eradication.
If the success comes from the user's normal IP and managed device, it may be the real user finally approving their own legitimate prompt — but do NOT close yet. Always run I4 first: an attacker who won the flood registers a new method within minutes.
Push-bombing is remote by nature — the flood originates from wherever the attacker holds the password. An unfamiliar country/ASN, an anonymising proxy or VPN, or a high Entra ID Protection risk level distinguishes a real takeover from a genuine user re-tapping their own token. This is the FP/TP fork.
- 1Check Risky sign-ins for the user around the burst — look for
unfamiliarFeatures,anonymizedIPAddress,maliciousIPAddress, orimpossibleTraveldetections. - 2Compare the burst / success IP against the user's 30-day baseline locations (SigninLogs history).
- 3Resolve the ASN — hosting/VPN/residential-proxy ASNs behind the flood strengthen the TP verdict.
- 4If a coincident Entra risk detection exists, this is an account-takeover — proceed to containment without waiting for further confirmation.
This is the indicator most often missed, and the one that decides eradication. An attacker who wins access registers their own authenticator or phone as a new approved method (T1556.006), so a password reset alone will not evict them. A new security-info registration or device join around the sign-in time is a confirmed compromise on its own — even if I1/I2/I3 look ambiguous.
- 1Filter Audit logs by Category = UserManagement and the alerted user's UPN as Target.
- 2Look for
User registered security info,User registered all required security info,Admin registered security info, orUser deleted security infonear the sign-in time. - 3Also check Directory activity for
Add registered device/Register device— attacker device join for Conditional Access evasion. - 4Cross-reference the initiating actor's IP with I2/I3. A method registered from the hostile IP is unambiguous.
- 5Verify against the user's Security info blade (entra.microsoft.com → Users → [user] → Authentication methods) to see the actual method now on the account.
| OperationName | Meaning | Severity |
|---|---|---|
| User registered security info | A new MFA method added by the user (or attacker in their session) | CRITICAL if unfamiliar session |
| Admin registered security info | An admin added an MFA method for the user — help-desk abuse path (A2) | CRITICAL |
| User deleted security info | A method removed — lock-out or forced re-registration (A4) | HIGH |
| Add registered device | A new device joined/registered — CA-policy evasion foothold | HIGH |
Keep a scheduled Sentinel rule for "security info registered" that joins to a risky sign-in in the prior hour — it catches A3 persistence even when the push-bombing burst itself was low-volume or missed.
Before escalating, extract and record:
- 1Identity: victim UPN, object ID, roles/group memberships, whether privileged.
- 2Source: attacker IP(s), ASN, country, VPN/proxy status; DeviceId/browser of the successful session.
- 3Timeline anchors: first denial, last denial, capitulation success time, method-registration time.
- 4Persistence artifacts: exact new MFA method (phone number / authenticator display name), any registered device, any OAuth grant or inbox rule created after access.
| True Positive Signals | False Positive Signals |
|---|---|
| Denial burst followed by success from unfamiliar IP/ASN or high risk | All attempts from the user's normal IP + managed device, working hours |
| New MFA method / device registered from a session the user disowns | User confirms they were setting up a new phone / re-enrolling |
| Coincident Entra risk detection (anonymizedIP, impossibleTravel) | Documented help-desk ticket for MFA reset matching this user + time |
| Denials from a hosting/proxy ASN never used by the org | Single isolated denial then a normal success (mistap, no burst) |
| Privileged account targeted; multiple users hit from one ASN (campaign) | Known token-expiry / device-clock-skew causing repeated re-prompts |
"The user probably fat-fingered it" is a hypothesis, not a verdict. Close as FP only after (a) I4 shows no new method/device, AND (b) the user or a change/help-desk record actually confirms benign activity. Unverified fatigue assumptions are the top way real takeovers get closed.
03 — CONTAINMENT
IMMEDIATE ACTIONEven a "UNCERTAIN / attempted" verdict means an attacker holds this user's valid password. A password reset is mandatory before closing — do not treat a denied-only burst as benign.
- 1Revoke sign-in sessions FIRST — on the user blade click Revoke sessions (or
Revoke-MgUserSignInSession -UserId <upn>). A password reset alone does NOT kill an already-issued refresh token or session cookie. - 2Block sign-in: set Block sign in = Yes on the user, or disable the account, to stop re-authentication while you clean up.
- 3Reset the password and require change at next sign-in (the attacker holds the current one).
- 4Remove attacker-registered MFA methods: Users → [victim] → Authentication methods → delete any phone/authenticator the user does not recognise (identified in I4). Leave/verify a known-good method.
- 5Raise user risk to High in Identity Protection and confirm any risk-based Conditional Access now forces re-auth.
Order matters: revoke sessions → block sign-in → reset password → remove rogue method. Resetting the password first, then revoking, leaves a window where the attacker's live token still works.
- 1Add the attacker IP/range to a Named location marked as untrusted and reference it in a block CA policy (prefer specific-IP block — push-bombing proxies are often shared residential/cloud ranges).
- 2Add the IP/domain as a Defender indicator (security.microsoft.com → Settings → Endpoints → Indicators) if the same source appears in endpoint telemetry.
- 3If multiple users were hit from one ASN, scope the campaign (I3 across all users) and consider a temporary CA block on that ASN's range for the targeted group.
- 4Confirm the tenant enforces number matching for Authenticator and, if not, enable it — it blunts blind-approval floods immediately.
If the entry was a password from spray/leak, the credential itself is the vector — a reset here only fixes one account. Pivot to SOP-05 (brute force / spray) to scope how many other accounts share the exposure.
04 — ERADICATION
CLEANUP- 1Confirm every attacker-registered MFA method and device is removed (re-check I4). The account should show only methods the user recognises.
- 2Hunt post-access persistence the attacker may have set while in-session: malicious inbox rules (auto-forward/delete), OAuth app consents (AuditLogs "Consent to application"), and any added role or group membership. Remove them.
- 3Review what the session touched — mailbox access, SharePoint/OneDrive downloads (OfficeActivity), sent mail. If data movement is found, pivot to SOP-07 (DLP) and SOP-10 (BEC).
- 4Reconstruct the timeline: first denial → capitulation success → method registration → any data access → containment. Record all IOCs from I5.
- 5Re-run I1, I2 and I4 for the user over the incident window — expected result after cleanup is 0 new denials, 0 hostile successes, 0 new methods.
- Sessions revoked, password reset, and only user-recognised MFA methods remain on the account
- No attacker-registered device, OAuth grant, inbox rule, or role/group change persists
- Re-run of I1/I2/I4 returns zero hostile activity for the user
- Source IP/ASN blocked via CA named location and/or Defender indicator
- Number matching + phishing-resistant MFA enforcement confirmed for the user/group
- Full timeline and IOC list attached to the incident record
- 1Enforce number matching for Microsoft Authenticator tenant-wide (Protection → Authentication methods → Microsoft Authenticator) if not already default-on.
- 2Roll phishing-resistant MFA (FIDO2 / passkeys / Windows Hello for Business) to privileged and high-value accounts — these cannot be push-bombed.
- 3Tighten help-desk verification procedures so MFA resets require out-of-band identity proofing — this closes attack path A2.
- 4Ensure a Conditional Access policy requires MFA registration only from trusted locations / compliant devices, blocking A3 registration from hostile sessions.
- 5If the password was exposed via spray/leak, drive the broader remediation via SOP-05 and consider tenant-wide forced reset for the exposed cohort.
05 — ESCALATION
ESCALATION PATHS| Tier | Trigger Condition | Who to Notify | Action |
|---|---|---|---|
| L1 → L2 | Denial burst confirmed but TP/FP unclear in 30 min, OR any privileged account targeted, OR >5 users hit from one source | L2 SOC Analyst | Hand off with I1–I4 findings + timeline |
| L2 → IR | Confirmed capitulation success + hostile session, OR attacker-registered MFA method/device (persistence) | Incident Response Team | Full identity containment, scope campaign, hunt post-access |
| IR → CISO | Global Admin / privileged account takeover, exec/finance account, or confirmed data access/exfil from the session | CISO / Security Management | War room, assess business + data impact |
| CISO → External | Regulated data (GDPR/PCI/HIPAA) reachable from the account, or tenant-wide campaign | Legal / DPO / regulator / MSSP | Breach assessment; GDPR 72h clock starts at awareness |
Bring to every escalation: incident ID; victim UPN + roles; attacker IP/ASN/location; timeline (first denial → success → method registration); containment actions taken (sessions revoked, method removed, source blocked); current confidence (TP confirmed / suspected / unverified); and whether data access occurred.
A confirmed takeover of a Global Admin or an account with standing access to regulated data skips L1 queuing entirely — page IR and CISO in parallel and assume tenant-wide exposure until scoping proves otherwise.
Stay Threat-Ready
Follow CyberHawk Threat Intel for daily SOC analyst playbooks, detection engineering guides, and threat intelligence.