AiTM attacks expose the limits of MFA in real enterprise logins

At a glance

What this is: This is an analysis of Adversary in the Middle phishing and how it defeats MFA by capturing credentials and approvals in real time.

Why it matters: It matters because identity teams still have to defend human logins, and MFA alone does not stop session hijack or credential replay when the login flow itself is compromised.

By the numbers:

• Storm-1167 managed to send more than 16,000 Adversary in the Middle attacks before detection, according to Microsoft.
• In June 2023, Microsoft detailed successful attacks on MFA-protected organisations, including financial institutions.
• MFA patent filings date back to 1995, with AT&T, Ericsson, and Nokia all filing early patents.

👉 Read Unixi's analysis of Adversary in the Middle attacks and MFA bypass

Context

Adversary in the Middle attacks target the login journey itself, not just the password. The attacker proxies the user into a convincing fake login page, captures the credentials and MFA response, and then uses the resulting access to enter the real account.

For IAM teams, the issue is not whether MFA remains useful. The issue is that MFA was designed to verify a user during authentication, while AiTM attacks weaponise the gap between credential entry, factor approval, and session establishment. That gap matters wherever human identities still rely on browser-based sign-in flows.

This is a human IAM problem first, but it also has downstream NHI consequences when compromised human accounts are used to create tokens, approve apps, or modify security settings. The starting point described here is typical of modern phishing-driven account takeover attempts.

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 AiTM attacks still matter if organisations already use MFA?

A: AiTM attacks matter because MFA can still be bypassed when an attacker relays the user’s authentication flow and steals the resulting session cookie. In that case, the problem is not password strength but session integrity. Phishing-resistant authentication and tighter token controls reduce the chance that a successful login becomes immediate takeover.

Q: How do organisations know whether their MFA strategy is actually reducing risk?

A: Look beyond factor count and measure phishing resistance, step-up coverage, and recovery abuse. Passkeys and hardware keys are stronger than SMS or basic push because they bind authentication to origin, while number matching and adaptive challenges reduce fatigue attacks. If recovery paths remain weak, MFA may still be bypassed.

Q: Who is accountable when an AiTM attack leads to account compromise?

A: Accountability usually sits with identity, security, and application owners together. Identity teams own the assurance method, security teams own detection and response, and application teams own session controls and access policies. If any of those layers is weak, the attacker can inherit the trusted session.

Technical breakdown

How Adversary in the Middle phishing proxies the login flow

Adversary in the Middle attacks sit between the user and the legitimate identity provider. The victim enters credentials into a lookalike page, but the attacker relays those credentials and the MFA challenge to the real service in real time. That means the attacker does not need to defeat MFA mathematically. They only need to forward the authentication ceremony fast enough to obtain a valid session or token. This is why URL reputation checks and generic phishing filters often miss the attack. The threat is not the page alone, but the interactive relay behind it.

Practical implication: teams need phishing controls that inspect credential submission paths, not just destination reputation.

Why MFA approval is not the same as session trust

MFA validates a login event, but it does not guarantee the browser session that follows is safe. Once the attacker obtains the authenticated session, they can often act as the user, including changing mailbox rules, altering security policies, and sending email from the compromised account. In practical terms, the MFA factor has already done its job from the identity system’s point of view, even though the attacker now controls the session. This is why session binding, device context, and post-authentication monitoring matter so much in modern human IAM.

Practical implication: monitor for abnormal post-login actions, not just successful MFA completions.

Why credential theft protection changes the attack economics

Credential theft protection aims to stop the browser from releasing secrets to untrusted destinations. In an AiTM flow, that changes the economics of the attack because the adversary no longer gets reusable credentials to replay or harvest. The key architectural point is that the protection has to operate at the moment the credential is typed or submitted, not after compromise has already occurred. That makes browser-level enforcement and application-aware policy more relevant than simple blocklists. For identity programmes, the control focus shifts from detecting bad logins to preventing secret disclosure in the first place.

Practical implication: place control at the credential release point, not only at the sign-in or alerting layer.

Threat narrative

Attacker objective: The attacker wants full account control with a valid session that can be used for persistence, email abuse, and policy tampering.

1. Entry occurs when the target receives a phishing email containing a link to a convincing fake login page.
2. Credential access occurs when the user submits credentials and confirms MFA on the attacker-controlled relay page.
3. Impact follows when the attacker uses the resulting access to control the account, send email, and alter security settings.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA is necessary but not sufficient when the login path itself is untrusted. AiTM attacks do not break the second factor directly. They exploit the fact that many IAM programmes still treat successful MFA as the end of the security decision, even though the browser session can already be compromised by then. The implication is that assurance has to extend beyond factor completion to session integrity and post-authentication behaviour.

Credential interception is now a human identity governance issue, not only a phishing issue. When attackers can relay a user through a fake login page and still obtain a valid session, the control boundary has moved from the inbox to the authentication ceremony. That means IAM, security awareness, email security, and session monitoring all share responsibility for the same failure mode. Practitioners should treat credential release as the critical control point.

Session-level abuse is where account takeover becomes operationally damaging. Once the attacker controls the mailbox or SaaS session, they can change security policies, redirect messages, and create durable access paths. This is the part many programmes under-model, because they measure MFA success but not downstream account misuse. The practical conclusion is that identity telemetry has to follow the session, not stop at login.

AiTM demonstrates a classic trust assumption failure in modern IAM. The assumption that the credential entry page, MFA prompt, and authenticated destination belong to the same trusted interaction chain was designed for honest user journeys. That assumption fails when the actor is a relay-controlled phishing page because the attacker can mirror the real login flow without breaking the authentication protocol. The implication is that trust must be established around the transaction, not just the factor.

Unixi's source article reinforces a broader NHI lesson: identities are often compromised at the point of secret disclosure, not at the point of access use. The same pattern shows up in API keys, tokens, and service credentials when controls focus on detection after the secret leaves the user or system. For practitioners, that is a reminder to align human IAM and NHI governance around the moment a secret is released.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap makes phishing-driven identity compromise more dangerous because attackers often pivot from human login abuse into application and token abuse.
• From our research: Use the Ultimate Guide to NHIs , Static vs Dynamic Secrets to connect session abuse to downstream secret exposure and credential lifecycle risk.

What this signals

Credential interception should be treated as a control-plane problem, not only a user-behaviour problem. When MFA can be proxied, the programme signal that matters is whether your controls can distinguish a real login ceremony from a relayed one. That means improving session assurance, device binding, and conditional access signals rather than relying on factor prompts alone.

The broader identity lesson is that human and non-human trust boundaries are converging. Once a compromised human account can mint tokens, approve apps, or change security policy, the incident stops being a pure authentication event and becomes an identity lifecycle problem across users, applications, and downstream credentials. That is where governance teams need joined-up telemetry.

AiTM is one reason the classic perimeter around identity is dissolving. As credentials become the bridge into both SaaS and NHI estates, organisations need to watch for the same pattern of secret abuse across human sign-in flows and machine access paths. The practical next step is to align human IAM controls with NHI secret governance, not run them as separate risk conversations.

For practitioners

• Harden the credential release point Use controls that block credential submission to untrusted or anomalous destinations, especially lookalike login pages and relayed sign-in flows.
• Monitor the full post-login chain Correlate successful MFA events with mailbox rule changes, security policy edits, and unusual session behaviour so takeover is detected after authentication, not after damage spreads.
• Reduce dependence on browser-only trust Pair MFA with device signals, session binding, and step-up checks for sensitive actions so a stolen session does not inherit unrestricted trust.
• Extend identity governance to downstream abuse Review which human accounts can create tokens, approve applications, or modify security controls, because those paths turn a compromised login into longer-lived access.

Key takeaways

• AiTM attacks succeed by relaying the login ceremony, which means MFA can be completed successfully even while the session is compromised.
• The most important evidence is not just successful sign-in, but what happens immediately after authentication, including mailbox changes and policy tampering.
• Identity teams should shift control to the credential release point and session layer, because that is where this attack pattern actually breaks trust.

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.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
• Credential Release Control: A control that governs whether a browser or application is allowed to submit secrets to a destination. It is more precise than generic phishing detection because it focuses on the act of releasing credentials, which is often the decisive moment in relay attacks.
• Post-Authentication Abuse: Post-authentication abuse happens when an attacker uses valid credentials to perform actions after login rather than breaking authentication itself. For NHI environments, this often means abusing tokens, service accounts, or delegated access to query data, move laterally, or establish persistence while appearing legitimate to basic login controls.

What's in the full article

Unixi's full analysis covers the operational detail this post intentionally leaves for the source:

• The phishing and relay mechanics behind Adversary in the Middle attacks, including how the login flow is proxied in practice.
• The specific browser-side credential protection approach Unixi describes for blocking secret disclosure during sign-in.
• The examples the article cites from Microsoft reporting, including the attack pattern and the affected organisation types.
• The way Unixi claims its controls intervene at both the phishing stage and the credential-theft stage.

👉 Unixi's full post covers the attack stages, Microsoft reference case, and the control points it claims stop the flow.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.