Adversary-in-the-middle attacks expose MFA trust gaps

At a glance

What this is: This is an analysis of AiTM phishing, showing how a proxy in the middle can capture credentials and session cookies to bypass MFA and reuse an authenticated session.

Why it matters: IAM teams need to treat session legitimacy, not just login success, as the control boundary because MFA can be sidestepped after the initial authentication event.

Context

Adversary-in-the-middle phishing is a session hijacking problem, not just a login problem. The attacker inserts a proxy between the user and the legitimate service, capturing credentials and the session artefacts that keep the user signed in after MFA has already been satisfied.

For IAM and access teams, the security gap is that many controls still assume authentication is a durable proof of trust. AiTM breaks that assumption by stealing the authenticated session itself, which means post-login controls, revocation speed, and phishing-resistant methods matter as much as initial sign-in checks.

Key questions

Q: What breaks when MFA bypass techniques and adversary in the middle phishing are not accounted for in access controls?

A: Traditional MFA can fail if the attacker intercepts the login session or relays the authentication flow in real time. That leaves the organisation with a valid session but no real assurance of device, user intent, or login origin. Teams need phishing resistant authentication, token binding where possible, and continuous risk checks after sign in.

Q: Why does a successful MFA login still leave organisations exposed to AiTM attacks?

A: Because the risk shifts from proving identity at login to preserving trust throughout the live session. If the attacker can capture the authenticated session, the organisation may have perfect MFA telemetry and still be vulnerable to abuse through that stolen session.

Q: How should security teams reduce the risk of MFA bypass through AiTM phishing?

A: Treat MFA as one control in a broader session-security chain. Add phishing-resistant authenticators where possible, monitor for impossible or unusual session transitions, and require explicit revocation of active sessions after suspected compromise. The key is to inspect what happens after authentication succeeds, not only whether login was challenged.

Q: When should teams prioritise session revocation over additional login prompts?

A: When the attacker may already hold a valid session cookie or token. Extra prompts do little once the session is captured, so teams should prioritise immediate invalidation of the live session and tighter policy enforcement on sensitive access paths.

Technical breakdown

How AiTM proxies steal the session, not just the password

AiTM attacks use a phishing lure to send the victim to a fake site that relays traffic to the real service through an attacker-controlled proxy. That proxy records credentials during the sign-in flow and can also capture session cookies or tokens generated after authentication. Because the victim completes the login against the genuine service through the proxy, the attacker inherits an authenticated session that looks normal to downstream systems.

Practical implication: treat session capture as part of the threat model, not only password theft.

Why MFA can still fail after successful authentication

Multi-factor authentication proves the user completed a login challenge at a point in time, but it does not guarantee the session remains bound to the original user after the exchange. AiTM takes advantage of that gap by reusing the authenticated session from another endpoint. In other words, MFA is satisfied, but the attacker operates inside the trusted session state that MFA no longer continuously verifies.

Practical implication: add phishing-resistant authentication and session controls that survive beyond the login ceremony.

Why conditional access and revocation speed matter

The article points to monitoring, auto-access revocation, FIDO2, and conditional access as countermeasures because the abuse window is operational, not theoretical. Once the attacker has a live session, the real question becomes how quickly the organisation can detect anomalous use and invalidate the session before it is reused for email, cloud access, or business email compromise. This is an identity governance problem as much as an authentication problem.

Practical implication: design access revocation so it can terminate suspicious sessions immediately across critical applications.

Threat narrative

Attacker objective: The attacker wants to obtain a reusable authenticated session that bypasses MFA and grants access to enterprise systems as the victim.

1. Entry begins with phishing that lures the target to a lookalike site and places an attacker-controlled proxy in the communication path.
2. Credential access occurs when the victim enters credentials and the proxy captures the session cookie or other authenticated session data.
3. Escalation follows when the attacker reuses that trusted session to access enterprise systems as the victim without needing to satisfy MFA again.
4. Impact is the ability to reach business email, cloud services, or other high-value systems and use that foothold for further fraud or compromise.

Breaches seen in the wild

• 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.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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

Session legitimacy is the real trust boundary, not MFA completion: AiTM attacks work because authentication is treated as a one-time event even though the attacker can steal the session state that follows it. That means identity assurance ends up being validated at login while abuse happens after login, inside a trusted session. Practitioners should read this as a governance failure in session assurance, not a user-only phishing problem.

Phishing-resistant authentication must be evaluated as a session-binding control, not just a login control: The article's FIDO2 and WebAuthn emphasis points to a deeper issue. The industry has to distinguish between proving who signed in and proving that the same party still controls the session after the exchange. That distinction matters most for cloud consoles, business email, and any workflow where a stolen session can outlive the MFA challenge.

Conditional access only helps when it is enforced against the live session, not the initial request: AiTM shows that policy decisions made at sign-in are not enough if the attacker can proxy the browser interaction and inherit the outcome. The decisive question is whether access controls can detect or invalidate abnormal session use before the attacker completes follow-on actions. Teams should treat rapid session revocation as a core control, not an incident afterthought.

Identity programmes need a named concept for this failure mode: session trust leakage: The stolen asset is not only a password or a token, but the trust state that lets an attacker act as if they were the legitimate user. Once that state is portable, MFA ceases to be a complete answer on its own. The practical conclusion is that session governance must be designed as a first-class identity control.

MFA fatigue narratives miss the more important governance lesson: The article is not mainly about weak users or weak prompts. It shows that a mature organisation can still lose control when the authentication system assumes the browser session remains trustworthy after the initial proof. That assumption no longer holds in AiTM conditions, so practitioners need to rethink how assurance is maintained across the full session lifecycle.

From our research library:

• Tycoon 2FA alone accounted for 62% of phishing detected by Microsoft and over 64,000 confirmed incidents.

What this signals

Session trust leakage: AiTM turns an authenticated browser session into the attacker’s asset, which is why IAM programmes need controls that can see and kill abuse after login. If session state is portable, MFA on its own becomes a partial control rather than a boundary.

Security teams should treat revocation latency as a measurable risk. The shorter the time between anomalous session use and invalidation, the less value an attacker can extract from captured cookies, relayed browser flows, or inherited trust.

The stronger design pattern is to combine phishing-resistant authentication with policy that evaluates the live session context. That shifts the control point from a one-time sign-in check to continuous enforcement over the access session.

For practitioners

• Deploy phishing-resistant authentication for high-value access Require methods such as FIDO2 or WebAuthn where the service can verify origin and bind the user more strongly to the login ceremony. Prioritise business email, admin consoles, and cloud access paths that would be useful after session theft.
• Instrument live session monitoring and revocation Monitor for abnormal session reuse, impossible travel, and unexpected device or browser context shifts, then terminate the session immediately when risk appears. The control objective is to invalidate the trusted session before the attacker uses it for follow-on access.
• Tighten conditional access around domain and device context Restrict access to approved domains and client states so that a relayed browser flow cannot silently inherit trust. Make the policy decision depend on the current session context, not only the initial sign-in result.
• Shorten the attacker’s post-authentication window Reduce the lifetime of sessions and require revalidation for sensitive actions so that captured cookies remain useful for less time. This is especially important where MFA has already been completed and the attacker’s advantage is persistence inside the session.

Key takeaways

• AiTM phishing is dangerous because it steals the authenticated session, not just the password, which lets attackers operate inside MFA-protected environments.
• The core weakness is an assumption gap. Authentication does not automatically guarantee that the current session is still controlled by the original user.
• The most effective response is to pair phishing-resistant login methods with conditional access and fast session revocation.

Key terms

• Adversary-in-the-middle Attack: An adversary-in-the-middle attack intercepts and relays authentication in real time between the user and the legitimate service. It is especially dangerous for OTPs because the attacker can capture the code while it is still valid and immediately use it to complete login.
• Persistent Cookie: A persistent cookie is a session cookie that remains valid after the browser closes until it expires or is explicitly removed. In remote access designs, it can improve usability, but it also increases the chance that a reused session becomes standing access if the organisation does not enforce compensating controls.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Session revocation: The ability to invalidate active sessions so access ends immediately instead of waiting for tokens or browser state to expire. For identity governance, this is the control that determines whether authentication still matters after a compromise is detected.

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.