AiTM attacks expose the limits of MFA in real enterprise logins

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: Adversary in the middle phishing can let the attacker complete MFA while the victim believes they are logging in normally.

Why it matters: It matters because IAM teams cannot assume MFA alone closes the login risk window when credentials and session approval can be intercepted in one flow.

By the numbers:

• Storm-1167 managed to send more than 16,000 attacks before detection, according to Unixi.

Context

Adversary in the middle attacks sit between the user and the login page, relaying the session in real time while stealing credentials and challenge responses. That breaks the assumption that MFA is a final gate, because the attacker is no longer guessing a password but riding the authenticated exchange.

In identity programmes, this is an authentication and session integrity problem, not just a phishing problem. When the login channel can be proxied, control has to extend beyond the second factor to the integrity of the browser, URL handling, and the credential submission flow.

Unixi’s article uses Microsoft-reported incidents to show how enterprise logins can be taken over even when MFA is present. The attack pattern is now a practical governance issue for workforce identity teams, not a theoretical bypass.

Key questions

Q: What breaks when MFA is protected by an Adversary in the Middle attack?

A: The factor still works, but the trust chain does not. The attacker relays the user through a fake page, captures the credentials and MFA response, and then uses the resulting authenticated session. That means the real failure is not MFA itself. It is the assumption that a successful MFA event proves the whole login journey was trustworthy.

Q: Why do phishing kits with reverse-proxy flows still bypass MFA?

A: Because the attacker is not trying to defeat MFA in theory. They are trying to steal the authenticated session after the user completes a legitimate-looking sign-in. When the session token is captured, MFA has already been satisfied, so the attacker can continue as the user unless session controls intervene.

Q: How can security teams reduce the risk of session theft after MFA approval?

A: Reduce the value of a successful login by validating where credentials are entered, binding sessions to trusted device context, and limiting what the account can do immediately after authentication. MFA should be one layer in a broader login-path and session-integrity control set.

Q: When should organisations treat MFA as necessary but not sufficient?

A: Organisations should treat MFA as necessary but not sufficient whenever users can still recover access through weaker routes, reuse credentials or operate on unmanaged devices. MFA blocks many common attacks, but it does not fix bad exception handling or weak access governance. The right standard is whether every access path is held to the same assurance level.

Technical breakdown

How adversary in the middle phishing proxies MFA

Adversary in the middle, often shortened to AiTM, works by placing a malicious site between the user and the legitimate identity provider. The fake page forwards the login request to the real service, captures the password, then relays the MFA challenge so the victim completes the flow as if nothing is wrong. Because the attacker receives the resulting session token or authenticated state, the login appears valid to downstream systems. This is why reputation-based email filtering and basic password compromise detection miss the core problem: the credential exchange itself has been proxied, not merely guessed.

Practical implication: treat login interception as a session-integrity problem, not only a phishing awareness problem.

Why MFA can still fail after the second factor is approved

MFA proves that the user completed an authentication step, but it does not prove that the step happened in a trusted context. In AiTM attacks, the challenge is relayed in real time, so the attacker benefits from the user’s legitimate approval without needing to defeat the factor directly. Once the session is established, the attacker can operate with the same access as the victim account, including email access and security policy changes. This is the key limitation: MFA reduces risk, but it does not neutralise real-time relay attacks that reuse the user’s own authentication outcome.

Practical implication: supplement MFA with controls that detect or block credential relay and token theft.

Why URL and browser controls matter in login attacks

The article’s example shows a phishing link hosted on a legitimate-looking external service, which can evade simple reputation checks. That matters because users often trust the page more than the domain itself, and the attack succeeds when the browser submits credentials into an untrusted flow. Controls that validate the destination, constrain credential submission, or protect passwords inside the browser reduce the chance that a user hands the attacker an authenticated starting point. In practice, the weakest link is often not the factor prompt but the moment the login form accepts input.

Practical implication: harden the login path itself, not only the identity provider and factor policy.

Threat narrative

Attacker objective: The attacker aims to obtain authenticated access to enterprise accounts and use that access for control, persistence, and follow-on abuse.

1. Entry occurs through a phishing email carrying a URL that looks legitimate enough to reach the target user.
2. Credential access happens when the victim enters username and password into a fake login page that relays the session to the real service.
3. Escalation follows when the attacker completes the MFA prompt in real time and inherits the authenticated session.
4. Impact is full account control, including email sending and security policy changes from the compromised account.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA completion is not the same as trusted authentication: AiTM attacks succeed because the user still performs the expected second-factor action inside an untrusted relay. That means the assurance boundary is the login path, not the factor prompt. The implication is that enterprise identity teams must stop treating factor success as proof of context integrity.

Real-time relay collapses the control assumption behind phishing-resistant posture: Traditional MFA assumes the attacker cannot stand in the middle of the exchange and reuse the user’s response immediately. Once that assumption fails, the control no longer distinguishes a legitimate session from a proxied one. Practitioners need to recognise that the threat is not factor weakness alone, but session theft through authenticated relay.

Credential submission becomes a governance point, not just a user action: The article’s browser-and-URL emphasis shows that the decisive failure can occur before the identity provider ever sees the request. That is why login governance must include where credentials can be entered, not only how they are verified. The practical conclusion is that the login surface has become part of IAM control scope.

Adversary in the middle exposes an identity trust boundary gap: The central issue is that enterprise programmes often trust a completed login more than the path that produced it. That is a weak assumption in an environment where phishing kits can proxy the entire exchange. Teams should interpret AiTM as evidence that trust must be anchored to channel integrity as much as to authentication strength.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Identity trust has moved upstream into the browser session: The control question is no longer only whether MFA exists, but whether the login path itself is trustworthy before credentials are entered. That pushes identity governance toward browser, URL, and session-context controls that can interrupt relay attacks before they become authenticated access.

Phishing-resistant outcomes require more than user training: Users can still be deceived into approving a proxied login even when they understand phishing risk. Security programmes should therefore measure whether authentication controls can survive a real-time relay, not just whether staff recognise suspicious email.

MFA should be treated as a necessary control with bounded scope: It reduces exposure, but it does not eliminate attacks that capture the full authentication exchange. For workforce identity teams, the practical shift is to govern the login path and session as first-class security objects.

For practitioners

• Tighten credential submission controls Block password entry on untrusted destinations and verify whether employees are sending credentials only to approved login paths. Focus on browser-level enforcement that can stop credential submission before the user authenticates into a proxy page.
• Add relay-resistant authentication signals Use controls that make it harder for a proxied session to look legitimate after MFA approval, including device and browser context checks tied to the login flow. Treat session origin and token reuse as part of the authentication decision.
• Review post-login privilege impact Limit what a newly authenticated account can do, especially email sending and security-policy changes, so a stolen session does not immediately become an account takeover event. Separate authentication success from high-risk administrative capability.
• Instrument phishing response around login relay Look for repeated login pages, unexpected redirects, and successful MFA followed by atypical account actions. Tie those signals to incident triage so AiTM attempts are treated as authentication compromise rather than simple spam.

Key takeaways

• AiTM attacks work because the attacker can relay a legitimate login and MFA approval in real time, not because the factor itself is absent.
• The article shows that more than 16,000 attacks were sent before detection, which underlines how scalable this phishing pattern can be once the proxy infrastructure is in place.
• The control gap is the trusted login path, so defenders need browser, URL, and session-integrity controls alongside MFA.

Key terms

• Adversary-in-the-Middle (AiTM): An attack pattern where the adversary sits between the user and the service to capture or replay authentication data and session state. The victim may still log in successfully, which is why the compromise often appears legitimate until privileged actions begin. AiTM is especially dangerous for admin workflows that trust issued sessions too much.
• MFA Relay Attack: An MFA relay attack is a fraud technique that tricks a user into approving a login while the attacker forwards the authentication in real time. The attacker captures credentials or a one-time code, relays it to the target service, and completes sign-in before the code expires, bypassing the intended second factor.
• Session Integrity: Session integrity is the assurance that an authenticated connection remains trustworthy after sign-in. It covers token use, channel validation, and device posture, because attackers often target the session after the login event rather than the login event itself.
• Trusted Login Path: A trusted login path is a legitimate authentication route that users normally use to reach cloud or SaaS resources. Attackers abuse these paths after compromising an identity because the activity often looks ordinary. The security challenge is not the login itself, but the assumption that valid authentication always means safe access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.