Use Case: Identity
MFA fatigue and push bombing
An attacker sends 47 Duo push notifications at 2:30 AM. The user wakes up, taps approve to make it stop. ManySignal detects the flood pattern and blocks the session before that tap matters.
When persistence beats security awareness
MFA fatigue — also called push bombing — is the technique that Scattered Spider used to compromise MGM Resorts, Caesars Entertainment, and dozens of other enterprises between 2022 and 2024. The mechanics are simple: the attacker already has valid credentials (bought, phished, or brute-forced). The only obstacle is MFA. So they send notifications until the user approves one.
The most effective variant pairs the push flood with a phone call. The attacker, claiming to be IT helpdesk, calls the user and says "we're migrating systems and need you to approve the MFA request." Awareness-trained users still fall for this because the caller sounds authoritative and the notification is real.
Legacy SOC tools see a surge in failed MFA events and generate a low-severity alert. By the time a human reviews it, the user has approved push number 23 and the attacker is in the VPN.
Trigger detection sketch
rule: mfa_fatigue_push_flood
type: behavioral + threshold
sources:
- okta_system_log
- duo_admin_api
- microsoft_entra_signin
trigger:
- event: mfa.push.sent
- count: >= 5
- within: 10m
- same_user: true
- condition: |
auth_ip NOT IN user_known_ips(90d)
AND auth_ip NOT IN corporate_ip_ranges
enrichments:
- ip_asn: maxmind_asn
- threat_intel: recorded_future, virustotal
- user_timezone: hr_directory
- prior_flood_attempts: same_user, 30d
risk_score: 91
mitre: T1621 (Multi-Factor Authentication Request Generation)
Questions the agent answers before you see the alert
How many MFA push notifications were sent to this user in the last 60 minutes?
IdP push logDid the user approve a push notification at any point during the flood?
Okta / Entra auditWhat is the source IP and ASN of the authentication requests?
IP enrichmentHas this ASN or IP subnet been associated with phishing campaigns in the past 90 days?
Threat intelDid any post-authentication activity occur — mail access, file download, config change?
M365 / GSuite auditIs the user currently reachable via their registered mobile number?
HR directoryDid the user's device report the push receipt locally (MDM telemetry)?
Jamf / IntuneAutomated steps before analyst review
Temporarily disable MFA push for this user and switch to TOTP-only to stop the flood
AutonomousSend the user an in-app security alert with a 'This was me / Not me' button
AutonomousIf user responds 'Not me': immediately lock account and open P1 incident
Approve-gatedBlock originating IP range at the IdP policy layer for 24 hours
Approve-gatedIf push was approved: treat as full account compromise, escalate to IR playbook
RecommendHow this plays out in a legacy SOC
The SIEM generates an "MFA anomaly" alert at severity 3 (medium). It sits in the queue for 4 hours until the morning shift. By then the attacker has already established persistence via a registered MFA device added to the account — a capability the IdP allows without requiring a second factor when done from an authenticated session. The breach investigation takes 3 weeks and costs the organization $2.1M in IR fees and business disruption.
MITRE ATT&CK mapping
MFA fatigue FAQ
What push count threshold triggers the detection?
The default threshold is 5 push notifications within 10 minutes from a new or anomalous IP. The threshold adapts per user — a user who frequently retries MFA has a higher baseline. The key signal is the combination of volume plus IP anomaly, not volume alone.
Does this work for number matching MFA prompts?
Number matching (introduced by Microsoft in 2023) reduces but does not eliminate fatigue attacks. Attackers use social engineering to tell the user which number to match. ManySignal detects the push flood pattern regardless of prompt type.
Can the detection distinguish a forgetful user from an attacker?
Yes. A forgetful user typically retries 2-3 times from a known device and known IP within seconds. An attacker sends rapid-fire pushes from an unknown IP, often at odd hours for the user's timezone. Both behavioral and contextual signals are combined.
What MFA providers are supported?
Okta Verify, Microsoft Authenticator, Duo Security, Google Authenticator (via TOTP log), Ping ID, and RSA SecurID. Push log granularity varies by provider — Okta and Duo provide the richest per-push telemetry.
How does ManySignal handle MFA fatigue that escalates to account compromise?
If a push is approved during the flood window, ManySignal immediately escalates from the MFA-fatigue playbook to the account-compromise playbook — suspending the session, notifying the on-call analyst, and initiating the full triage sequence for the post-auth activity.
Stop the next push bombing attack before approval
ManySignal cuts the window from hours to minutes. Connect your IdP and see push-flood detection in the first session.