You Turned MFA On. Attackers Already Have Three Ways Around It.
Thought Leadership Credential Risk
In Q3 2025, 32% of organizations hit by ransomware had MFA deployed — and 41% of those were breached anyway via MFA bypass. MFA is necessary. It's no longer sufficient. Here are the three routes attackers are using to get around it, and what actually stops them.
On the night of September 15, 2022, an Uber contractor started receiving push notifications on their phone. A second-factor authentication request — the kind their MFA setup had been sending them for years. They declined it. Another one appeared. They declined again. For over an hour, notifications arrived every few minutes. Exhausted, assuming it was a system glitch, they finally tapped Approve.
Within minutes, the attacker had access to Uber's internal systems, Slack, and source code repositories. The MFA worked exactly as designed. The human didn't.
This is the story most businesses don't know about MFA. It's not a story about MFA failing. It's a story about attackers learning to route around it — using the human being holding the phone, the architecture of the authentication session, or the inconsistency of how MFA gets deployed in real organizations. And in 2026, all three routes are more refined, more automated, and more widely used than ever before.
The three routes attackers use to bypass your MFA
Route 1 — MFA Fatigue (Push Bombing)
Attacks the human, not the technology.The attacker already has your employee's valid username and password — purchased from a breach database, obtained through phishing, or stolen by infostealer malware. They feed those credentials into an automated authentication loop. Every failed login attempt triggers a new push notification on your employee's device. The attacker runs this loop continuously — dozens, sometimes hundreds of times — timed deliberately for midnight to 5am, or weekends, when cognitive resistance is lowest.
The goal isn't to trick the employee. The goal is exhaustion. Decision fatigue. The notification that finally gets approved not because the employee was fooled but because they wanted the phone to stop buzzing.
What stops it: Number matching — requiring employees to enter a specific code from the login screen into the push notification, rather than simply tapping Approve. This breaks the automation loop. Microsoft and most major identity providers support it as a setting. CISA now explicitly recommends it as the minimum standard for push-based MFA.
Route 2 — Adversary-in-the-Middle (AiTM) Proxy Attacks
The employee completes MFA correctly — the attacker wins anyway.The attacker sets up a reverse proxy between your employee and your legitimate login service. The employee is directed to what appears to be the real Microsoft, Google, or Okta login page. They enter their real password. They complete the real MFA challenge. Everything works exactly as expected.
But every interaction is being relayed through attacker-controlled infrastructure. The moment the legitimate service issues a session cookie — proving authentication is complete — the attacker captures it. They can now access the account as if they were the authenticated user, without triggering MFA again. Authentication already happened.
What stops it: Phishing-resistant MFA — specifically FIDO2 security keys or passkeys, where the second factor is cryptographically bound to the specific domain being authenticated. A FIDO2 key won't authenticate to a proxy because the proxy domain doesn't match. CISA explicitly calls FIDO2 the gold standard.
Route 3 — The Deployment Gap
Attacks your implementation, not your technology.This one isn't glamorous. It exploits the gap between the MFA policy that exists on paper and the MFA coverage that actually exists across your systems. Most MFA failures in ransomware incidents stem from misconfiguration — MFA policies applied inconsistently, leaving specific pathways completely unprotected.
You enabled MFA on Office 365. But the legacy email protocol — IMAP or POP3 — doesn't support MFA and was never disabled. The attacker uses the legacy protocol. Your MFA never fires. Or admin accounts were set up before the policy and quietly exempted. Or MFA covers the primary login but not the VPN, remote desktop gateway, or cloud storage tool.
What stops it: A complete MFA coverage audit — every system, every user, every access method. Legacy protocols explicitly blocked. Admin accounts included without exception. Third-party SaaS tools audited. The gap-finding is manual and tedious, but it's the highest-return security action available to most SMBs right now.
The MFA you have vs. the MFA that actually protects you
Not all MFA is equal — and the type you've deployed matters as much as whether you've deployed it.
SMS / Text message codes
Vulnerable to SIM swapping — attacker convinces your carrier to transfer your number to their device. CISA recommends moving away from SMS-based MFA. Still better than nothing. Not resistant to determined attackers.
Push notifications (Approve/Deny)
Vulnerable to MFA fatigue and push bombing. Significantly improved by number matching. Without number matching, push notifications are the weakest common MFA form deployed at scale.
TOTP apps (Authenticator codes)
Resistant to push bombing. Vulnerable to AiTM proxy attacks — the code can be relayed in real time before it expires. Better than SMS or push. Not phishing-resistant.
FIDO2 security keys / Passkeys
The gold standard. Cryptographically bound to the specific domain. AiTM proxies cannot relay FIDO2 authentication because the proxy domain doesn't match. CISA's highest recommendation. Phishing-resistant.
What MFA actually needs to work in 2026
- Enable number matching on all push-based MFA. Single configuration change. Defeats push bombing without new hardware or cost. Most businesses haven't turned it on.
- Audit your legacy protocol exposure. Identify every access method that bypasses your MFA policy — legacy email protocols, older VPN configurations, any application authenticating separately from your main identity provider. Block every path that doesn't enforce MFA.
- Include every account without exception. Admin accounts, service accounts, IT staff, contractors. Attackers specifically look for the highest-privilege accounts exempted from policy during rollout. Those cause catastrophic breaches.
- Move toward FIDO2 for your highest-risk accounts. Your admin accounts, finance team, and anyone with access to sensitive client data should be on phishing-resistant MFA as soon as possible. Hardware security keys are inexpensive. AiTM attacks don't work against them.
- Monitor post-authentication behavior. MFA confirms identity at login. It says nothing about what happens after. An attacker with a valid AiTM-captured session looks like a legitimate authenticated user. Behavioral anomaly detection catches them in the session, not at the login prompt.
MFA is table stakes. It's not the whole game.
Turning on MFA was the right decision. In 2026 it remains one of the most important security controls any small business can deploy. That hasn't changed.
What has changed is the threat. Attackers have spent years studying MFA deployments, identifying the gaps, and building automation specifically designed to route around the human interface, the session architecture, and the implementation inconsistencies that most organizations leave in place after rollout.
The Uber contractor who kept declining push notifications for an hour wasn't careless. They were human. And "human" is now the attack surface. The question isn't whether your MFA is turned on. It's whether it's configured to survive contact with an attacker who has studied exactly how to get around it.
See what attackers see before they target your MFA — exposed credentials, legacy protocols, and coverage gaps. Veriti Spottr's beta is free.
Join the free beta →
Comments
Post a Comment