All posts
MFA fatigueNumber matchingPhishing

Number matching stops MFA fatigue. Phishing proxies still get through

U2 Secured Security Team · · 7 min read

Push two-factor authentication was supposed to be the easy upgrade from typing codes. Then attackers worked out that if you send enough prompts, someone eventually taps Approve just to make them stop. That attack — MFA fatigue, or push bombing — now has a well-understood fix. A different attack, the adversary-in-the-middle phishing kit, does not. Both deserve a plain explanation.

What an MFA fatigue attack looks like

The attacker already has the password — from a breach dump, an infostealer log or a reused credential. They sign in, the service sends a push to the victim’s phone, and the victim declines. So the attacker signs in again. And again. Late at night, during a meeting, a hundred times in a row.

In March 2024, Brian Krebs documented exactly this against Apple users: a stream of system-level password-reset prompts, followed by a phone call from someone posing as Apple Support asking the victim to read back a code. KrebsOnSecurity

It is not just opportunists. CISA’s advisory on Scattered Spider, last updated in July 2025, lists repeated MFA prompts alongside help-desk impersonation as the way the group gets an MFA factor moved to a device it controls. CISA AA23-320A

Why number matching fixes it

A plain push asks a yes/no question, and a tired person can answer yes without thinking. Number matching changes the question: the sign-in screen shows a number, and the phone asks the user to pick that number from several. Someone being bombed from somewhere else has no sign-in screen in front of them, so they have nothing to match. CISA recommends number matching as the interim mitigation for exactly this reason. CISA fact sheet

In U2 Secured Authenticator, number matching is not a setting you can forget to turn on:

  • Every push carries a match number for your sign-in screen, and the phone offers three candidates. A wrong pick does not just fail — it ends the request as denied.
  • Approving requires Face ID, Touch ID or a fingerprint. Denying never does.
  • The prompt shows your app’s name and the context you send (“Login from Chrome on macOS”), and can carry a verified location from the phone, so a request from the wrong city looks wrong.
  • Your policy can flag or deny approvals from a new device or a new country, and can require a location fix before an approval counts.

The developer’s side is one call and a webhook — see how push approvals work and sending a push request. The one thing you must do is show the match number in your own UI; without it, your user is guessing.

What number matching does not fix: phishing proxies

Adversary-in-the-middle (AitM) kits do not bomb anyone. They put a pixel-perfect proxy between the victim and the real site. The victim types their password into the proxy, the proxy types it into the real site, and when the real site shows a match number, the proxy shows the victim the same number. The victim matches it correctly, because from where they sit everything is legitimate. The proxy then keeps the session cookie.

This is not theoretical. In March 2026, Microsoft described Tycoon2FA as a phishing platform that defeated “nearly all commonly deployed MFA methods” — SMS, one-time codes and push — and linked it to tens of millions of phishing messages reaching over 500,000 organisations a month, before Microsoft’s Digital Crimes Unit and Europol disrupted its infrastructure. Microsoft Security Kits like Sneaky 2FA were sold as a service for around $200 a month. Sekoia

That is why CISA reserves the term phishing-resistant for FIDO2/WebAuthn — passkeys and security keys that are cryptographically bound to the real site’s origin, so a proxy on another domain gets nothing it can use. Push with number matching is fatigue-resistant. It is not phishing-resistant, and nobody selling it should tell you otherwise.

AttackPlain pushPush + number matching + biometric
Push bombing / MFA fatigueVulnerable — one careless tapBlocked — the victim has no number to match, and a wrong pick denies
Accidental approval in a pocketPossibleStopped — biometric required
Login from an unexpected countrySilentVisible on the prompt; can be auto-denied by policy
AitM phishing proxy (Tycoon2FA)VulnerableVulnerable — the proxy relays the real number
Stolen session cookie (infostealer)VulnerableVulnerable — MFA happened before the theft

What this does not stop

A live AitM relay; a victim who reads the number to someone on the phone; help-desk social engineering that moves the account to an attacker’s phone; and session cookies stolen after sign-in. U2 Secured also does not cap how many pushes one user can receive in an hour — number matching and the biometric prompt are what make a flood harmless, not throttling.

A practical checklist

  1. Turn off plain yes/no push everywhere you can; use number matching.
  2. Send meaningful context with every push — app, browser, approximate location — so a wrong request looks wrong.
  3. Deny, not just flag, approvals from new countries for admin accounts.
  4. Train the help desk to verify identity before resetting or moving an MFA factor; that is how Scattered Spider gets in.
  5. For admin and finance accounts, add passkeys or hardware keys on top. Push protects everyone; FIDO protects the accounts attackers target hardest.
  6. Keep sessions short and re-verify before sensitive actions, so a stolen cookie has a short shelf life.

If you are choosing a factor for your own product, our guide to TOTP versus push lays out the trade-offs.

Sources

  1. CISA — Implementing Number Matching in MFA Applications (Oct 2022)
  2. CISA AA23-320A — Scattered Spider (updated 29 Jul 2025)
  3. KrebsOnSecurity — Recent MFA bombing attacks targeting Apple users (26 Mar 2024)
  4. Microsoft Security — Inside Tycoon2FA (4 Mar 2026)
  5. Sekoia — Sneaky 2FA, a new AiTM phishing-as-a-service (Jan 2025)