MFA Fatigue and Account Takeover: The Gap Endpoint Tools Miss

The fastest way to close the MFA account-takeover gap is to stop relying on push and text codes and move your high-value accounts to phishing-resistant MFA (FIDO2 security keys or passkeys), then back it with conditional access that checks device and session, not just the login. Multi-factor authentication still matters, but the common forms of it (a code by text, a push you tap to approve) are now routinely defeated by push-bombing, infostealer-stolen session tokens, and adversary-in-the-middle phishing. Your endpoint security tool will not catch most of these, because the attacker never touches your endpoint.

The MFA you turned on is not the MFA attackers are testing

Most of the trucking and logistics companies I sit down with did the right thing a few years back. They turned on MFA in Microsoft 365. They feel covered. The problem is that the threat moved. Criminals stopped trying to guess passwords and started attacking the second factor directly, or skipping it entirely by stealing the session that MFA already approved.

I want to be precise about the gap, because it gets papered over by vendor marketing. "We have MFA" and "we have account-takeover protection" are not the same sentence. The first is a control you enabled. The second is an outcome you have to keep earning against three specific techniques.

Push-bombing (MFA fatigue): wearing the user down

Push-bombing is the crudest of the three and still works. The attacker already has the password (bought from a marketplace, reused from a breach, or phished). They log in over and over, firing a push notification at the employee's phone each time. Twenty prompts during a dispatch shift. Fifty overnight. Eventually someone taps Approve to make it stop, or because they assume it's a glitch.

The 2022 Uber breach is the textbook case: an attacker spammed an Uber contractor with MFA requests, then messaged them pretending to be IT to get the final approval. No malware. No exploit. Just patience and a tired human.

Number matching helps here, and you should turn it on today if you haven't. Instead of a tap-to-approve, the user has to type a number shown on the login screen into their authenticator app. That breaks blind approval. But understand what number matching is and isn't. It defeats fatigue. It does not defeat a phishing page that simply shows the user the real number to relay. CISA is blunt about this in its guidance on implementing phishing-resistant MFA: number matching is a worthwhile improvement, but it is not phishing-resistant.

Token theft via infostealers: skipping the login entirely

Here is the technique that catches even careful, well-trained teams. When you log into Microsoft 365 and clear MFA, your browser holds a session token, basically a signed note that says "this person already authenticated, let them back in." Infostealer malware (RedLine, Lumma, Raccoon and their kin) grabs those tokens, along with saved passwords and cookies, off an infected machine and ships them to the attacker.

With a stolen, still-valid session token, the criminal pastes it into their own browser and is inside the mailbox. They never enter a password. They never trigger an MFA prompt. From your tenant's point of view, the session was already trusted. This is why a company can have MFA on every account and still get its inbox taken over.

Infostealers usually arrive through a poisoned download, a cracked-software lure, or a malicious browser extension on a personal or lightly managed device. That last part is the trap for fleets: a driver or a part-time dispatcher logging into webmail from a home laptop is outside your hardened perimeter. Short token lifetimes and conditional access that re-checks the device are what shrink this window.

Adversary-in-the-middle (AiTM): phishing that eats the code and the cookie

AiTM is the most dangerous of the three because it defeats almost every MFA method built on shared secrets. The attacker stands up a reverse-proxy phishing site (Evilginx-style kits make this cheap) that sits between the victim and the real Microsoft login. The victim types their password into what looks like the genuine page. The proxy relays it to Microsoft. Microsoft sends a real MFA challenge. The victim approves it, or types the real number-matching digits. The proxy captures the resulting session cookie and replays it.

Read that again: the victim completed legitimate MFA, and the attacker walked away with a live session anyway. Text codes, authenticator apps, push with number matching, all of them feed the proxy. The user did nothing obviously wrong.

This is the path behind a large share of business email compromise, which remains one of the costliest crimes the FBI tracks. The IC3's 2023 Internet Crime Report logged 21,489 BEC complaints and roughly $2.9 billion in reported losses for that year alone. In freight, that often means a hijacked email thread used to reroute a payment or alter a rate confirmation, with the takeover invisible until the money is gone.

Why your endpoint tool does not save you here

Good endpoint detection and response (we run SentinelOne) is essential, and it will catch the infostealer on a managed machine, the malware dropper, the obvious lateral movement. I am not arguing against EDR. I'm pointing out where its line of sight ends.

Two of these three attacks happen off your endpoints entirely. The AiTM proxy lives on attacker infrastructure. The push-bombing happens on the user's phone and your identity provider. A stolen token replayed from a personal laptop in another country never executes anything on the corporate fleet you're watching. EDR protects devices. Account takeover is an identity problem, and you need identity-layer controls to see it and stop it.

How we actually close the gap

The fix is layered, and the order matters. First, move high-value accounts to phishing-resistant MFA. CISA calls FIDO2/WebAuthn (security keys and passkeys) and PIV smartcards the only widely available phishing-resistant methods, and the reason is cryptographic, not procedural: a FIDO2 credential is bound to the real domain. Land on an AiTM proxy and the key simply won't authenticate, because the domain doesn't match. The attack dies at the door. We start owners, controllers, dispatch leads, and anyone who can move money or reroute a load. You don't have to boil the ocean on day one.

Second, turn on number matching everywhere you still use the authenticator app, because not every account gets a hardware key immediately, and fatigue protection is cheap. Third, tighten conditional access in Microsoft 365 and Intune: block legacy authentication protocols, require compliant or hybrid-joined devices for mailbox access, restrict sign-ins from geographies you never operate in, and shorten session lifetimes so a stolen token expires fast. Fourth, watch for the takeover signals (impossible-travel sign-ins, new inbox forwarding rules, mass mailbox reads) and have a named incident commander who can pull the session and force a credential reset on a contractual 4-hour clock. We map these controls to NIST CSF 2.0 so a client's board can see exactly what's covered.

None of this is exotic. It's the difference between turning MFA on and actually protecting accounts against the way they're attacked in 2026. For freight operators especially, where a single rerouted payment can dwarf a year of security spend, the identity layer is where I'd put the next dollar. If you want a hand pressure-testing your own setup, that's the core of what we do on the EFROS Chicago cybersecurity services page.

Call us at +1-765-888-8888 if you'd rather just talk it through.