Notifications
Clear all
Topic starter
27/08/2026 8:35 am
TL;DR: Adversary in the Middle attacks can bypass MFA by intercepting credentials and session approval in real time, as Unixi’s analysis of Microsoft-reported incidents shows. The lesson is that MFA cannot be treated as a standalone control when phishing pages can proxy the login flow and capture full account access.
NHIMG editorial — based on content published by Unixi: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Unixi's analysis of Adversary in the Middle attacks and MFA bypass →
Adversary in the middle attacks: where MFA still fails in practice?
Explore further
27/08/2026 8:35 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AiTM attacks expose the limits of MFA in real enterprise logins
