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

At a glance

What this is: This explains how adversary-in-the-middle phishing works and why it can defeat MFA by capturing credentials and session cookies.

Why it matters: It matters because IAM teams need controls that bind sessions to the right user and device, not just stronger login prompts, across human, NHI, and emerging autonomous access patterns.

👉 Read 1Kosmos's analysis of adversary-in-the-middle phishing and MFA bypass

Context

Adversary-in-the-middle attacks are a session hijacking pattern built on phishing, proxying, and token theft. The attacker does not need to defeat authentication in the abstract. Instead, they capture the credentials and session artefacts that make the login look legitimate to the target system, which is why MFA alone can fail to stop the intrusion.

For IAM teams, the issue is not only user deception but the trust model behind the session. If the programme assumes that successful sign-in means the identity is still trustworthy, an AiTM attacker can inherit that trust and move into email, cloud, and other enterprise services with a live authenticated context.

Key questions

Q: How should security teams reduce the risk of adversary-in-the-middle phishing?

A: Security teams should prioritise phishing-resistant authentication, remove weak fallback login methods, and add device-aware conditional access. AiTM attacks are effective because they steal a live session, not just a password, so the response has to limit replay value and invalidate suspicious sessions quickly.

Q: Why do AiTM attacks bypass MFA in practice?

A: They bypass MFA because the attacker completes the MFA challenge inside a proxy flow and then reuses the resulting authenticated session. The application sees a valid session cookie or token, so the compromise looks legitimate unless the programme also verifies device and session context.

Q: What breaks when organisations rely on login success as proof of trust?

A: Trust breaks at the session layer. A successful login only proves that authentication happened once, not that the same user still controls the browser session afterward. AiTM attackers exploit that gap by stealing and replaying the session artefact after the real authentication step ends.

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 AiTM phishing proxies capture credentials and session cookies

An adversary-in-the-middle setup inserts a proxy between the user and the legitimate service. The victim lands on a lookalike page, enters credentials, and the proxy forwards the login to the real site while intercepting the resulting session cookie or token. Because the real session is established, the attacker can replay that artefact against the original service. TLS still protects transport, but it does not protect the user from authenticating into the wrong endpoint. That is why AiTM is more dangerous than simple credential harvesting: it steals both the secret and the session state that follows it.

Practical implication: enforce phishing-resistant authentication and session binding, not password-and-MFA login alone.

Why MFA can be bypassed when the attacker reuses a live session

Many MFA deployments verify the login event, not the continuity of the session after the login succeeds. If the attacker completes the MFA challenge inside a proxy flow, the target application sees a valid authenticated browser session and accepts subsequent requests. The problem is assurance drift. The control validated the person once, but the attacker now controls the session artefact. This is why cookie replay, token theft, and authenticated browser handoff are central AiTM failure modes. The security boundary shifts from identity proofing to session integrity, which many programmes do not monitor closely enough.

Practical implication: add conditional access, device signals, and rapid session revocation to reduce replay value.

Why phishing-resistant authentication changes the trust boundary

FIDO2 and WebAuthn change the trust boundary by binding the authentication ceremony to the legitimate origin. The user’s browser and authenticator confirm they are interacting with the correct site, which makes proxy-based phishing far harder to execute. That does not eliminate all account abuse, but it removes the easiest path for an attacker to turn a phished credential into a durable authenticated session. In practical terms, this is about reducing the chance that the attacker can inherit the same trust the application grants to the real user after login.

Practical implication: prioritise phishing-resistant authentication for privileged users and high-value applications first.

Threat narrative

Attacker objective: The objective is to inherit a trusted authenticated session and use it to move into enterprise systems for data theft, business email compromise, or further intrusion.

1. Entry begins with a phishing email that mimics a legitimate organisation and lures the victim to a proxy page.
2. Escalation occurs when the proxy captures credentials and the resulting session cookie after the victim authenticates through the attacker-controlled relay.
3. Impact follows when the attacker reuses the live session to access email, cloud services, or other enterprise systems as the user.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Session trust, not just credential secrecy, is the real failure mode in AiTM phishing. These attacks succeed because the programme treats a completed login as proof of continued legitimacy. Once the proxy captures the session cookie, the attacker no longer needs to win the authentication ceremony again. The implication is that IAM must evaluate session integrity as a first-class control surface, not only login success.

Phishing-resistant authentication changes the economics of compromise, but it does not remove account risk on its own. FIDO2 and WebAuthn reduce the chance that a lookalike site can harvest reusable credentials, which narrows the attacker’s path. But any environment that still allows fallback methods, weak recovery flows, or unmanaged privileged accounts remains exposed. Practitioners should treat authentication method diversity as part of the attack surface.

Conditional access becomes meaningful only when it is tied to device and session signals that can invalidate stolen context. The article’s logic points to a broader governance gap: identity programmes often verify who signed in, but not whether the session still matches the original device, browser, and location profile. That gap matters across human identity and NHI governance because replayable trust artefacts behave like portable credentials once issued.

AI agent governance will inherit the same session-trust problem if agent sessions are allowed to persist without continuous binding. The assumption that a successful authentication event establishes durable legitimacy was designed for human-paced interactions. That assumption fails when identities operate across automated or delegated workflows that can carry context far beyond the original login moment. Practitioners must rethink how session legitimacy is asserted when access is reused programmatically.

AiTM should be read as a signal that identity assurance and session governance are converging. The practical lesson is not simply to add more prompts at login. It is to align authentication strength, session revocation, and access policy with the actual lifetime of trusted context. Teams that do not make that shift will continue to defend the ceremony while attackers target the session.

From our research:

• 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, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%, according to The State of Non-Human Identity Security.
• For teams building the next control layer, Ultimate Guide to NHIs , Key Challenges and Risks is the natural follow-on for visibility, over-privilege, and lifecycle control.

What this signals

Session-based compromise is becoming a governance problem, not just a phishing problem. AiTM attacks show that identity programmes need controls that can see past the login ceremony and evaluate whether the active session still deserves trust. The next maturity step is not more authentication friction alone, but better binding between identity, device, and session behaviour.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, any inherited session or delegated access model deserves closer scrutiny. Once trust is delegated, the organisation can lose sight of where the authenticated context is actually being used. That is a structural governance gap, not a tooling glitch.

AiTM should push programmes toward continuous assurance thinking. Teams should prepare for a world where access is not a single event but a chain of assumptions that can be broken after sign-in. The programmes that adapt fastest will be the ones that treat session revocation, device posture, and token lifetime as core identity controls.

For practitioners

• Adopt phishing-resistant authentication for high-value users Move privileged users, finance teams, and cloud administrators to FIDO2 or WebAuthn first, then remove weaker fallback methods that can be abused in proxy-based phishing.
• Bind access decisions to device and session signals Use conditional access that checks device posture, browser context, and location, then deny or step up access when the session context changes unexpectedly.
• Shorten the lifespan of trusted sessions Apply tighter session timeouts and rapid token revocation so intercepted cookies lose value quickly after abnormal activity is detected.
• Instrument alerts for authentication proxy patterns Correlate unusual redirect chains, repeated login attempts, and impossible session handoffs in your SIEM so proxy-based phishing is visible before lateral movement begins.

Key takeaways

• AiTM attacks succeed by stealing trusted session state after authentication, which makes them more dangerous than basic credential theft.
• The scale of the problem is amplified by weak identity confidence, with only 1.5 out of 10 organisations highly confident in NHI security.
• Phishing-resistant authentication, conditional access, and rapid session revocation are the controls that most directly limit replayable trust.

Key terms

• Adversary-in-the-Middle Attack: An adversary-in-the-middle attack is a phishing pattern where the attacker places a proxy between the user and the real service. The proxy relays the login while capturing credentials and session artifacts, allowing the attacker to reuse trusted access after the victim authenticates.
• Session Cookie: A session cookie is the browser-side token that keeps a user logged in after authentication succeeds. In compromise scenarios, it becomes a portable trust artifact, because whoever controls the cookie can often continue the session without repeating the original login.
• Phishing-Resistant Authentication: Phishing-resistant authentication uses methods that bind the login ceremony to the legitimate origin, such as FIDO2 and WebAuthn. It reduces the chance that a lookalike site can capture reusable credentials or silently forward the authentication to an attacker-controlled proxy.
• Conditional Access: Conditional access is a policy layer that evaluates context before granting or continuing access. It can use device posture, location, and session risk to decide whether a request should be allowed, challenged, or revoked when the authentication context no longer looks trustworthy.

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.

This post draws on content published by 1Kosmos: adversary-in-the-middle attacks and MFA bypass. Read the original.