Push-bombing: when the MFA prompt is the attack

What we are seeing

An attacker already has a working password, usually from an old breach or a convincing sign-in page. Multi-factor authentication is doing its job and stopping them. So they simply try again. And again. Forty prompts in ten minutes, often late in the evening, until the person on the other end taps Approve to make it stop.

It works more often than anyone would like. It is not a technical failure. It is a tired person and a badly designed prompt.

How to tell

• Approval prompts arriving when you are not signing in to anything
• Several in a row, a minute or less apart
• A phone call or message shortly afterwards from "IT" asking you to approve it
• In the sign-in log: a run of failures with reason MFA denied; user declined followed by one success

The fix

Turn on number matching. Instead of Approve and Deny, the sign-in screen shows a two-digit number and the phone asks the user to type it. Someone who is not looking at the sign-in screen cannot know the number, so there is nothing to approve by accident.

1. Check it is enforced, not just available. Most platforms now default to it for new tenants. Older tenants frequently have exceptions nobody remembers granting.
2. Remove SMS and voice-call fallbacks for anyone with administrator rights. A fallback is a second front door.
3. Tell people what a real prompt looks like. One short message: we will never call and ask you to approve a sign-in.

What to look for in the logs

If you want to check whether it has already been tried, this is roughly the shape of it. Field names vary by platform.

user            result    reason                    source_country
j.alvarez       failure   MFA denied; user declined  --
j.alvarez       failure   MFA denied; user declined  --
j.alvarez       failure   MFA denied; timeout        --
j.alvarez       success   MFA approved               (unfamiliar)

A success at the end of a run like that is an incident, whatever the user remembers. Treat it as one.