When MFA passes and the attacker still gets in

We regularly investigate compromised accounts where everything looks correct. Strong password, MFA enabled, the user approved the prompt. And yet an attacker was reading their mailbox from another country an hour later.

The explanation is usually an adversary-in-the-middle phishing kit. Instead of a fake login page that simply records a password, the attacker runs a proxy between the user and the real login service. The user sees the genuine sign-in flow, completes MFA, and is logged in. The proxy quietly keeps a copy of the session cookie that the real service issued.

With that cookie, the attacker does not need the password or the second factor. They are already signed in.

Why traditional MFA does not stop it

Codes sent by SMS, one-time codes from an authenticator app and push notifications all prove that the user is present. None of them prove that the user is talking to the real website. If the user types the code into a convincing proxy, the proxy passes it on.

That is not a reason to drop MFA. It still blocks the large majority of password-only attacks. It is a reason to understand what it does and does not protect.

Use phishing-resistant authentication

Passkeys and hardware security keys based on FIDO2 are bound to the domain they were registered on. A key registered for your real sign-in page will simply not respond to a lookalike domain, however convincing it looks to a human.

• Start with the accounts that matter most: administrators, finance, executives and anyone who can approve payments or change other people's access.
• Then make passkeys the default for everyone, with weaker methods kept only as a fallback that triggers extra checks.

Make stolen sessions less useful

Even with stronger authentication, assume some sessions will be stolen through malware or a missed device. Reduce what a stolen cookie is worth.

1. Bind access to managed devices. Conditional access policies that require a compliant, company-managed device mean a cookie replayed from an attacker's laptop fails.
2. Shorten session lifetimes for sensitive applications, and require re-authentication for high-risk actions such as changing MFA methods or creating forwarding rules.
3. Use token protection where your identity provider supports it, which ties a session to the device it was issued to.

Detect the replay

Stolen sessions leave a trail if you know what to look for:

• The same session used from two very different locations or networks within a short time.
• Sign-ins from hosting providers and anonymising networks for users who normally work from an office or home.
• A new inbox rule, OAuth app consent or MFA method shortly after a sign-in from an unfamiliar location.

Adversary-in-the-middle kits are cheap, sold as a service and constantly updated. The good news is that the strongest defence is now built into every major platform. The work is in rolling it out, starting with the people attackers want most.