MFA Fatigue / Push Bombing Investigation

When You See This

1. 1

   Identity provider logs show 10+ MFA push requests to a single user within a short window

2. 2

   User reports receiving unexpected MFA push notifications they did not initiate

3. 3

   SIEM alert for MFA push notification volume anomaly outside business hours

4. 4

   Failed MFA attempts followed by a single success from a different source IP

Investigation Steps

1. 1

   Quantify the MFA push volume and timing

   Pull all MFA-related events for the targeted user. Count the number of push requests, their frequency, and the time window. Genuine users rarely generate more than 2-3 MFA prompts per login attempt. More than 5 in rapid succession is suspicious. More than 10 is almost certainly an attack.

   SIEM

   Splunk SPLMicrosoft KQLElastic Lucene

   index=auth eventType="mfa_push" user="targeted_user" | timechart span=5m count | where count > 3

   index=okta OR index=azure_ad action="mfa_challenge" user="targeted_user" | stats count, earliest(_time) as started, latest(_time) as ended by user, src_ip | eval duration_minutes=round((ended-started)/60,1)

2. 2

   Check if the user approved any notification

   Search for a successful MFA approval amidst the flood of requests. If the user approved one, determine the timestamp and source IP of the subsequent authenticated session. This is the critical moment; everything after approval is potentially attacker activity.

   SIEM

   Splunk SPLMicrosoft KQLElastic Lucene

   index=auth user="targeted_user" (action="mfa_push_approved" OR action="mfa_push_denied" OR action="mfa_push_timeout") | table _time, action, src_ip, user_agent | sort _time

   Decision Point

   If: User approved an MFA push notification

   Yes → CRITICAL: An attacker likely has authenticated access RIGHT NOW. Immediately revoke all sessions and treat as active compromise.

   No → User held strong. Proceed to contain; reset password, notify user, block source IP.

3. 3

   Identify the source of the authentication attempts

   Determine where the credential-based login attempts are coming from. Check the source IPs against threat intelligence and geolocation data. The attacker already has the password; trace how they obtained it (previous phishing, credential dump, infostealer malware).

   SIEMFirewall

   Splunk SPLMicrosoft KQLElastic Lucene

   index=auth user="targeted_user" action=failure reason="mfa_required" | stats count by src_ip | iplocation src_ip | table src_ip, City, Country, count | sort -count

4. 4

   Assess post-compromise activity (if push was approved)

   If the attacker gained access, immediately investigate their activities. In the Uber breach, the attacker accessed internal Slack, VPN configurations, and source code repositories within hours. Check for data access, privilege escalation, new application consent grants, and internal reconnaissance.

   SIEMXDR

   Splunk SPLMicrosoft KQLElastic Lucene

   index=* user="targeted_user" src_ip="attacker_ip" | stats count by index, sourcetype, action | sort -count

5. 5

   Contain and remediate

   Revoke all active sessions for the targeted user. Force password reset. Review and remove any unauthorized MFA device enrollments. Block the attacking source IPs. Consider migrating the user from push-based MFA to FIDO2/WebAuthn keys, which are immune to fatigue attacks. Notify the user through a verified channel about what happened.

   SIEMXDR

Common Mistakes

1. 1

   Focusing only on whether the push was approved without investigating how the attacker obtained the password

2. 2

   Not checking for new MFA device enrollments; sophisticated attackers enroll their own device immediately after gaining access

3. 3

   Resetting only the password without revoking active sessions; the attacker session may persist

4. 4

   Not recommending MFA method upgrade; push notifications are inherently vulnerable to fatigue attacks

Escalation Criteria

• User approved an MFA push notification during a fatigue attack

• MFA fatigue targeting executives, IT admins, or accounts with privileged access

• Evidence of attacker activity after successful MFA bypass

Frequently Asked Questions

What is MFA fatigue and how did it breach Uber?

MFA fatigue is when an attacker with valid credentials repeatedly sends MFA push notifications hoping the user approves one. In September 2022, Lapsus$ sent over 100 push notifications to an Uber contractor, then contacted them on WhatsApp pretending to be IT support. The contractor approved a notification, giving the attacker full access to Uber internal systems.

How can organizations prevent MFA fatigue attacks?

Migrate from simple push notifications to number-matching or FIDO2/WebAuthn hardware keys. Number matching requires the user to enter a code shown on the login screen, preventing blind approval. FIDO2 keys are completely immune to fatigue attacks because they require physical presence and domain verification.

How do I practice MFA fatigue investigations?

SOCSimulator includes identity-based attack scenarios featuring MFA fatigue patterns based on real Lapsus$ and Scattered Spider techniques. Practice in realistic SIEM environments. Start free forever.