Safeguard
Security Guides•

How adversary in the middle phishing steals sessions despite MFA

Adversary in the middle phishing relays your real sign-in and steals the session cookie. Learn how it works and which defenses actually hold up.

Safeguard Security Team
3 min read

Adversary in the middle (AiTM) phishing puts a proxy between the victim and the real sign-in page. The victim completes MFA normally, and the proxy keeps the resulting session cookie. The attacker then replays it, so the account is accessed without a new password or code. Phishing-resistant MFA is the main fix.

The mechanism in plain steps

Microsoft describes the setup this way: attackers deploy a proxy server between a target user and the website the user wants to visit. The page looks and behaves like the original, because it is relaying the original.

  1. The victim opens a link in a phishing email.
  2. The proxy shows the real sign-in page content and forwards what the victim types.
  3. The real service asks for MFA, the proxy passes the prompt along, and the victim approves.
  4. The service issues a session cookie. The proxy captures it.
  5. The attacker loads that cookie in their own browser and is signed in.

Microsoft notes that because the cookie carries the authenticated session, the attacker can get in regardless of the sign-in method, including MFA protected accounts. It also names open-source kits that automate this, which means skill is not a barrier.

What happens next

In the campaign Microsoft documented, the attacker used the stolen cookie in web Outlook, looked for finance threads, deleted the original phishing email, and set an inbox rule to hide replies from the target. Payment fraud began as quickly as five minutes after the theft.

That is why AiTM is a common route into business email compromise. The account is real, the thread is real, and the attacker only has to type convincingly.

Which defenses help

Phishing-resistant MFA. FIDO2 and certificate based methods bind the sign-in to the legitimate site, so a proxy domain cannot complete it. CISA's archived guidance calls FIDO the only widely available phishing-resistant authentication and says the protocol blocks the attempt when a user is tricked into logging in to a fake site.

Conditional access. Requiring compliant devices or trusted network ranges means a replayed cookie from an unknown machine meets another check.

Mail and web filtering. Blocking known bad sites and scanning email reduces how many lures land.

Monitoring. Look for unusual sign-in properties and for new inbox rules, which showed up in the documented attacks.

Microsoft is clear that MFA remains an essential pillar even though AiTM can bypass some forms of it. Do not drop it. Upgrade it.

What does not help much

Training people to inspect the address bar helps, but a good proxy page looks right, and people are rushed. Number matching helps against push bombing, yet it does not stop a relayed approval. Treat these as extra layers. See how passkeys resist phishing for the underlying reason.

Quick check

If a user typed an MFA code into a phishing page, what should be done first?

Revoke the user's active sessions and refresh tokens, then reset the password and review MFA methods, inbox rules and app consents.

Do passkeys stop AiTM?

Passkeys and security keys are bound to the real domain, so they will not complete a sign-in on a proxy domain. That is why they are called phishing-resistant.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.