MFA prompt bombing, or when the attacker just asks nicely

The mental model most people have of multi-factor authentication is that the attacker steals your password and is then stopped by your phone. The mental model is half right. The attacker steals your password, true. What stops them depends entirely on which kind of MFA you happen to have.

For push-based MFA, the kind where your phone buzzes and you tap "approve", the answer is increasingly: nothing stops them. They just press the login button again. And again. And again, until somebody at your end taps approve to make the noise stop. The Hacker News piece from late May is worth reading, but the pattern is now well-established and worth setting out for anyone whose firm has rolled out MFA on the assumption that it solves the problem.

This filing covers what prompt bombing is, why it works, what the fix is, and how to tell whether the MFA you have already is the kind that can be bombed.

How the attack runs

Prompt bombing, also called MFA fatigue, has three steps.

The attacker has the password. This is the precondition. It came from a phishing kit, a breach reuse on a different site, an info-stealer on the user's home laptop, or somebody who copied it from a sticky note. The price for valid credentials on criminal markets is a few pounds per record for ordinary corporate accounts and rather more for admin ones. The defence "we use MFA" assumes the password layer is doing some of the work. For a sizeable fraction of users, it is not.

They send push prompts in volume. The attacker uses the password to log in. The system sends a push notification to the user's phone. The user does not approve it, so the attacker logs in again. Another push. Repeat. The 2022 Uber breach made this famous; the attacker sent prompts for more than an hour, then messaged the target on WhatsApp pretending to be Uber IT and asking them to approve "the next one" to make it stop. They did.

Eventually somebody taps approve. The reasons are mundane. The notification looks identical to the dozen legitimate ones the user gets each day. The phone buzzes during a meeting and the user clears notifications without reading. The prompts arrive at 3am and the user, half awake, taps the button to make their phone quiet. The attacker is not relying on the user being stupid. They are relying on the user being tired.

The attack scales. The attacker can run it across hundreds of accounts in parallel; only one needs to hit approve. The defender side does not even register most of the attempts as anomalous, because each one is a single failed login followed by a single push prompt, which is the same shape as a normal user mis-typing their password.

Why push MFA was meant to fix this

Push notifications were designed to be the user-friendly upgrade to SMS codes. The reasoning made sense at the time. SMS codes were vulnerable to SIM swapping. Push prompts could be cryptographically bound to the phone, did not require the user to type anything, and were impossible for an attacker to intercept on the wire.

What the design did not account for was the human side. The cryptography in a push prompt is fine. The human's decision to tap approve is the thing the attacker is trying to influence, and they have many tries.

The same pattern, with a different shape, has shown up against time-based one-time-passcode apps. The user reads the six-digit code off the app and types it into a real-looking login page that is in fact the attacker's. Phishing kits in 2024 and 2025 added real-time proxying so that the code is forwarded to the genuine site within seconds of the user typing it. The session token comes back to the attacker. Once again, the MFA factor exists; it just does not stop the attack.

What an SME should switch on this week

There are three short answers.

Turn on number matching. Microsoft, Google, and Okta all offer this. Instead of a "tap approve to log in" prompt, the prompt shows a two-digit number which the user has to type back. The number is generated at the moment of login and shown on the page the user is logging in from. Prompt bombing collapses, because the user cannot type back a number they cannot see. For Microsoft 365 it is now the default for new tenants but not necessarily for older ones; for Google Workspace it can be turned on in the security console; for Okta it is one of several "verified push" options. None of them require new hardware.

Move the high-risk accounts to passkeys. Passkeys (the consumer-friendly name for FIDO2 / WebAuthn credentials) bind the authentication to the device and the destination domain. They cannot be phished, because the credential will not release for a domain it was not registered with. They cannot be prompt-bombed, because there is no out-of-band prompt to bomb. Your IT admin accounts, your finance accounts, and your customer-data accounts are the obvious places to start. Our existing filing on NCSC says passkeys first, passwords second covers the rollout path.

Set the rate-limit on push prompts. Microsoft and Google both let the admin cap the number of push prompts that can be sent per account per hour. Five is a defensible default; ten is generous. Past the cap, the user has to use a different factor. The attacker's whole approach depends on volume, and the cap removes it.

A fourth, slightly larger, action is worth flagging. Most prompt-bombing campaigns are followed up with a phone call or message to the target, pretending to be IT and asking them to approve "the next one". The Uber attack worked because the target eventually believed the call. The brief to give staff is short and concrete: nobody from IT will ever phone you to ask you to approve an MFA prompt. If somebody does, hang up and ring IT back on a number you already have. The version of this we covered for the IT-guy-at-reception attack is the same pattern in person.

How to tell what kind of MFA you have

Three questions.

When you log in, does your phone buzz and you tap approve? That is push MFA. It is the kind that can be bombed. The fix is number matching, which converts the prompt into a "type these two digits" challenge. The system supports it; you may need to enable it.

Do you have a Microsoft, Google, or Yubico hardware token, or do you log in by holding your phone to a "passkey" prompt without typing anything? That is FIDO2 / WebAuthn / passkey MFA. It is the strongest of the common options. Prompt bombing does not work against it. The phishing kits do not either.

Do you type a six-digit code from an authenticator app or read it off a text message? That is OTP MFA. It is better than nothing, but it can be relayed in real time by a phishing kit. It is the right starting point for low-risk accounts and not the right ending point for admin or finance accounts.

For most UK SMEs the realistic mix is OTP MFA on everything, push MFA for the larger Microsoft 365 or Google Workspace estates, and passkeys for nothing yet. The change worth making this quarter is to add number matching to the push MFA and move at least the admin accounts to passkeys. Both are no-cost. Both close the prompt-bombing route.

Why this matters now

Two trends raise the volume. First, info-stealer malware is now widespread enough that any individual employee password should be assumed leaked at some point. Cybercriminals scrape these markets and bundle credentials by organisation; an attacker can buy a hundred passwords for staff at a UK firm for the price of a takeaway. Second, AI is making the follow-up impersonation half of the attack cheaper and more convincing. The "IT calling to ask you to approve the prompt" phase is the bit that depended on the attacker being a halfway-competent social engineer; voice cloning is removing that constraint.

The cheap, fast move is to turn off the parts of push MFA that the attacker is using. Then plan the passkey migration over twelve months. Neither requires a new product. Both require a decision and somebody to make the change.

How Steelwise can help

Checking which kind of MFA your firm is using, turning on number matching, and planning the passkey rollout for the accounts that matter is the kind of practical work we do with clients. Get in touch.