The Human Bypass: Countering MFA Prompt Bombing Attacks
Just caught the latest write-up on MFA Prompt Bombing, and it’s a stark reminder that our strongest technical controls often fail at the human layer. Attackers aren't breaking the encryption; they're spamming the user with push notifications until they accidentally (or intentionally) approve the login.
It’s essentially a distributed denial-of-service attack against a user's patience. We’ve seen this targeting Okta and Azure AD environments heavily recently. Relying solely on the 'default' push notification is becoming a liability.
I’ve been implementing stricter Conditional Access policies to mitigate this. Specifically, I'm requiring number matching (entering the number displayed on the login screen into the app) for risky sign-ins. However, that only helps if the platform supports it.
For detection, I've been tuning our SIEM to look for rapid-fire MFA denial events, which usually precede a successful 'fatigue' approval. Here is a basic KQL query I’m testing for Azure AD to catch these spikes:
kusto
SigninLogs
| where AuthenticationRequirement == "multiFactorAuthentication"
| where Status.errorCode == 500121 // MFA denied by user
| summarize Count = count() by UserPrincipalName, bin(TimeGenerated, 5m)
| where Count > 5
| order by Count desc
Is anyone else seeing a shift away from push-based MFA to FIDO2 hardware keys to bypass this entirely? Or is the cost still too high for a full rollout?
We made the switch to FIDO2 keys for all admin accounts last quarter. It’s the only way to definitively stop prompt bombing. The hardware cost is negligible compared to the risk of a full account takeover. For standard users, we enforce Number Matching combined with location-based Conditional Access. If the login isn't from a known corporate IP or registered country, we block the push entirely and force a password reset + helpdesk ticket.
That KQL query is a good start, but you might want to correlate it with failed IP reputations. We saw attackers using residential proxies to bypass basic geo-blocking, making the requests look somewhat legitimate until the volume spiked. We also added a 'session lockout' in our IdP: if a user denies 3 MFA prompts in 10 minutes, the account gets locked for 15 minutes. It stops the spamming immediately.
From a pentester perspective, prompt bombing is incredibly effective because it exploits helpdesk fatigue too. Users often approve it just to stop the buzzing so they can get back to work, assuming IT will fix it if it's 'bad'. Training users to report the spam before they approve is critical. If you don't have a 'Report Phishing' button that feeds directly to your SOC, you're flying blind.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access