About the Author
This article was written by Ahmar Imam with over a decade of combined experience in threat intelligence, identity protection, and incident response. Ahmar is a founder of D3C Consulting, where his team monitors emerging attack campaigns daily and works directly with enterprise security teams and individual consumers to mitigate data breach risks.
Reviewed by: Senior Threat Intelligence Analyst | Certified Information Security Professional (CISSP) | Identity Management expert

Introduction: MFA Isn’t Enough Anymore
Table of Contents
ToggleFor years, security teams told users the same thing: turn on multi-factor authentication (MFA), and you will be safe from phishing attacks. Add a second step, a text message, an authenticator app, a push notification, and even if attackers steal your password, they can not get in.
That advice is no longer fully accurate.
A new class of cyberattack called Adversary-in-the-Middle (AiTM) proxy phishing has quietly bypassed MFA at scale. These attacks do not steal your password before authentication. They wait until after you have already proven your identity, then they take the session cookie that your browser receives as a ‘proof of login.’ With that cookie, the attacker can access your account without ever needing your password or your MFA code.
And a second, longer-horizon threat is making this worse: the rise of quantum computing. Quantum machines are expected to break the encryption that protects session tokens, HTTPS connections, and authentication protocols within the next decade. When that happens, AiTM attacks may become nearly unstoppable with today’s defenses.
This guide explains both threats clearly, how AiTM proxy attacks work, what real-world damage they have caused, and what organizations must do right now to stay protected. We also cover the quantum threat and what ‘post-quantum’ security actually means for your organization.
KEY STAT
In 2022, Microsoft reported a single AiTM phishing campaign that targeted over 10,000 organizations in one month, and successfully bypassed MFA in all cases where victims were using SMS or authenticator app-based MFA.
Can AiTM attacks bypass multi-factor authentication?
Yes. AiTM proxy phishing attacks are specifically designed to bypass MFA. They do not steal credentials before MFA, they intercept the session cookie that is issued after MFA completes. This means that SMS, email, and authenticator-app-based MFA methods do not stop AiTM attacks. Only phishing-resistant MFA methods like FIDO2 hardware security keys or passkeys are effective against AiTM attacks.
What Is an Adversary-in-the-Middle (AiTM) Proxy Attack?
An Adversary-in-the-Middle (AiTM) attack is a type of phishing attack where the attacker sets up a fake website that acts as a transparent relay, called a proxy, between the victim and a real, legitimate website.
Here is the key difference from older attacks: the AiTM proxy does not just copy a login page. It actively forwards traffic in real time. When you visit the fake site, you are actually logging into the real website through the attacker’s server, you just do not know it.
This is important because it means the attacker captures everything, including your credentials AND the session cookie that the real website sends after you complete MFA.

What tools do attackers use to carry out AiTM proxy phishing attacks?
The most commonly used tool is Evilginx2, an open-source reverse proxy framework that uses 'phishlets' to proxy specific websites in real time. Other tools include Modlishka and Muraena. Pre-configured AiTM phishing kits targeting platforms like Microsoft 365, Okta, and Google Workspace are also sold on dark web markets
Step-by-Step: How AiTM Proxy Phishing Works
- Victim receives a phishing email with a convincing link (fake Microsoft 365 or Google login page).
- Victim clicks the link and lands on the attacker’s reverse proxy server.
- The proxy silently forwards the victim’s requests to the real login page, the victim sees the real site’s design, SSL certificate indicator, and everything looks normal.
- Victim enters their username and password, which the proxy captures.
- The real website sends an MFA challenge. The proxy relays it to the victim. Victim completes MFA normally.
- The real website confirms authentication and sends a session cookie to the browser, but the attacker intercepts it first.
- Attacker loads the stolen session cookie into their own browser. They are now logged in as the victim, no password or MFA needed.
SIMPLE ANALOGY
Imagine you are talking to someone who pretends to be your bank teller, but they are actually whispering everything to the real teller behind a wall and passing responses back to you. You complete your transaction normally, but the impersonator now has a copy of your account access card.

How AiTM Differs from Traditional Phishing
Traditional phishing attacks steal credentials, your username and password. This works well when there is no MFA. But when MFA is in place, stolen credentials alone are useless. The attacker needs to also beat the MFA step, which is why older phishing attacks became less effective once MFA adoption grew.
AiTM proxy attacks solve this problem by changing when they strike. Instead of stealing credentials before authentication, they intercept the session cookie after authentication is complete. At that point, MFA has already done its job, and the attacker reaps the reward.
Feature | Traditional Phishing | AiTM Proxy Phishing |
What is stolen | Username + Password | Session Cookie (post-MFA) |
MFA defeated? | No, MFA blocks it | Yes, MFA is already completed |
Victim notices attack? | Sometimes (fake page looks off) | Rarely (real site content displayed) |
Technique | Fake static login page | Real-time reverse proxy relay |
Tools used | PhishKit, GoPhish | Evilginx2, Modlishka, Muraena |
Defense | MFA stops most attacks | Requires FIDO2, CAE, Conditional Access |

Tools: Evilginx2 and Modern AiTM Kits
Attackers do not build AiTM proxy tools from scratch. Fully featured open-source and commercial kits are widely available. Security professionals use these tools for penetration testing, but attackers use them for real campaigns.
Evilginx2
Evilginx2 is the most well-known open-source AiTM phishing framework. It is built on top of the nginx web server and uses a system of ‘phishlets’, configuration files that define how to proxy specific websites like Microsoft 365, Gmail, GitHub, or Okta. Evilginx2 automatically handles HTTPS certificates, session cookie capture, and credential logging.
A skilled attacker can deploy Evilginx2 in under an hour, register a convincing domain, and begin targeting users. The framework is actively maintained and regularly updated to stay ahead of detection.
Modlishka and Muraena
Modlishka is a Polish-developed reverse proxy tool that similarly intercepts real-time sessions. Muraena is another tool that adds automation and evasion features, making it harder for anti-phishing filters to detect the proxy relay setup.
Commercial AiTM Phishing Kits
Dark web markets now sell pre-configured AiTM kits targeting specific platforms. These kits include ready-made phishlets, email templates, and evasion bypasses, making AiTM attacks accessible to attackers with limited technical skills.

SECURITY NOTE
The existence of these tools is publicly documented by Microsoft, CISA, and major cybersecurity vendors. Their open availability means AiTM attacks are no longer limited to nation-state actors, any organized criminal group can run them.
Real-World AiTM Attacks: Case Studies
Microsoft 365 Mass AiTM Campaign (2022)
In September 2022, Microsoft published research documenting a large-scale AiTM phishing campaign that targeted over 10,000 organizations in a single month. Attackers used a phishing infrastructure that proxied Microsoft’s login page in real time. Victims entered their credentials and completed MFA, but attackers captured session cookies at the moment of authentication. The cookies were then used to access Microsoft 365 email accounts, initiate Business Email Compromise (BEC) fraud, and conduct internal spear-phishing campaigns.
Okta Breach via Session Hijacking (2022)
The Okta breach carried out by the Lapsus$ group demonstrated how session-based attacks can target identity providers, the very companies trusted to secure authentication. While the Okta incident involved insider access at a third-party vendor, the session-based lateral movement used techniques consistent with AiTM-style token theft, highlighting that no identity platform is immune.
Cloudflare Phishing Incident (2022)
Cloudflare disclosed a targeted phishing attack in 2022 where employees received text messages with a link to a convincing fake Cloudflare Okta login page. The attack was designed as an AiTM relay. Cloudflare avoided a breach because employees used FIDO2 hardware security keys, which, as we will explain below, are the most effective defense against AiTM attacks. Employees who tried to comply with the phishing link were blocked because the FIDO2 key validates the actual domain of the website, not just what is displayed.
US Financial Sector Surge (2023–2024)
CISA and the Financial Services Information Sharing and Analysis Center (FS-ISAC) reported a significant increase in AiTM attacks targeting US banks and financial institutions between 2023 and 2024. Attackers targeted wire transfer approval workflows and high-value accounts. Several organizations suffered multi-million-dollar BEC losses as a direct result.

What is a session cookie and why do attackers want to steal it?
A session cookie is a token your browser stores after you log in to a website. It proves to the server that you have already authenticated, allowing you to stay logged in without re-entering your credentials. Attackers want to steal session cookies because they can replay them in their own browser to gain full access to your account, bypassing password and MFA requirements entirely. Stolen session cookies can remain valid for hours or days.
IMPORTANT
Even if the victim changes their password after realizing they were phished, the stolen session cookie may still be valid, until it expires or the session is explicitly revoked. This is why Continuous Access Evaluation (CAE) is a critical defense.
Quantum Threat: Why AiTM Gets Even More Dangerous
The quantum threat to cybersecurity is not science fiction. It is a documented, near-future risk that governments, defense agencies, and the world’s largest technology companies are actively preparing for. Understanding it requires a brief explanation of how current encryption works.
How Today’s Encryption Protects You
Most encryption in use today, including the TLS encryption that secures HTTPS connections, RSA key exchange, and elliptic-curve cryptography (ECC), relies on mathematical problems that are extremely hard for classical computers to solve. A classical computer would take millions of years to factor a large RSA key.
Why Quantum Computers Change Everything
Quantum computers operate using quantum bits (qubits) that can exist in multiple states simultaneously. This property, combined with quantum algorithms like Shor’s Algorithm, allows a sufficiently powerful quantum computer to factor RSA keys and break elliptic-curve cryptography in hours, or potentially minutes.
The National Institute of Standards and Technology (NIST) and the US National Security Agency (NSA) have both issued warnings that a cryptographically relevant quantum computer could emerge within the next decade. Some estimates put it sooner.
How This Amplifies AiTM Attacks
Today’s AiTM attacks work by intercepting session cookies after MFA. A quantum-capable attacker could potentially do far more:
- Decrypt intercepted HTTPS traffic in real time, eliminating TLS as a defense layer
- Forge authentication tokens by breaking the cryptographic signatures that protect them
- Retroactively decrypt stored network captures of past authentication sessions (a ‘harvest now, decrypt later’ strategy)
- Break the cryptographic integrity of FIDO2 and other phishing-resistant MFA schemes that rely on elliptic-curve cryptography
HARVEST NOW, DECRYPT LATER
Nation-state adversaries are believed to be recording encrypted network traffic today, storing it, and planning to decrypt it when quantum computers become available. This means data stolen now, including authentication tokens, could be decrypted in the future, even if it appears secure today.

NIST Post-Quantum Cryptography Standards
In 2024, NIST finalized its first set of post-quantum cryptographic standards. These algorithms are designed to resist attacks from both classical and quantum computers:
Algorithm | Purpose | Status |
CRYSTALS-Kyber (ML-KEM) | Key encapsulation / key exchange | NIST Standard (FIPS 203) |
CRYSTALS-Dilithium (ML-DSA) | Digital signatures | NIST Standard (FIPS 204) |
SPHINCS+ (SLH-DSA) | Hash-based digital signatures | NIST Standard (FIPS 205) |
FALCON (FN-DSA) | Compact digital signatures | NIST Standard (FIPS 206) |
Organizations that handle sensitive data, operate critical infrastructure, or work with government contracts should begin their post-quantum migration planning now. This process typically takes three to seven years for large organizations.
How to Defend Against AiTM Proxy Attacks
The good news is that strong defenses exist, but they require moving beyond simple MFA. Here are the most effective countermeasures, ranked by effectiveness.
1. Deploy FIDO2 / Passkey Authentication (Hardware Security Keys)
FIDO2 hardware security keys (such as YubiKey, Google Titan, or Apple Passkeys on device) are the single most effective defense against AiTM proxy attacks. Here is why: FIDO2 binds authentication to the actual domain of the website, not just what the page looks like. When a victim visits an AiTM proxy page, the fake domain does not match the registered domain for the FIDO2 key, so authentication is automatically blocked.
This is exactly why Cloudflare avoided a breach in 2022. Their mandatory use of hardware FIDO2 keys made the AiTM relay pointless.
2. Enable Continuous Access Evaluation (CAE)
Continuous Access Evaluation (CAE) is available in Microsoft Azure AD and other enterprise identity platforms. It allows the server to revoke or re-challenge a session in near-real time when suspicious signals are detected, such as an impossible geographic login (e.g., a session cookie used from Nigeria five minutes after a US login). CAE significantly reduces the attacker’s window to exploit a stolen session cookie.
3. Implement Conditional Access Policies
Conditional Access policies add context-aware rules to every authentication attempt. Examples include:
- Block logins from countries where you have no employees
- Require device compliance (managed, corporate device) for sensitive app access
- Flag logins from anonymous VPNs or Tor exit nodes
- Require re-authentication for high-risk actions (wire transfers, admin changes)
4. Deploy Anti-Phishing DNS Filtering
DNS-layer security tools (such as Cisco Umbrella, Cloudflare Gateway, or similar) can block known AiTM proxy domains before a victim’s browser ever loads the fake page. Keeping threat intelligence feeds current is critical, as AiTM domains are rotated frequently.
5. Enable HTTPS / TLS Inspection at the Network Layer
While not foolproof, network inspection tools can detect anomalous TLS certificate patterns associated with AiTM proxies, such as newly registered domains with fresh certificates that are proxying well-known services.
6. Run Regular AiTM-Specific Phishing Simulations
Standard phishing simulations do not test AiTM scenarios. Use platforms that support AiTM simulation (such as GoPhish with AiTM support or commercial platforms like Proofpoint and KnowBe4 with proxy phishing modules) to test whether your employees recognize the warning signs.
7. Implement Token Binding
Token binding is a protocol that cryptographically ties a session token to a specific TLS connection. Even if an attacker steals the token, it can only be used from the original network connection, not replayed from a different machine. Token binding is supported in some enterprise environments but requires server-side and browser-side support.
8. Begin Post-Quantum Cryptography Migration Planning
For organizations with long-term sensitive data or critical infrastructure responsibilities, start a post-quantum readiness assessment now. Work with your identity provider to understand their post-quantum roadmap. Monitor NIST guidance and NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requirements for your sector.
What is one thing that can eliminate AiTM proxy attacks completely?
If you can only do one thing today, enforce FIDO2 / passkey authentication for all privileged accounts and internet-exposed applications. This single change eliminates AiTM proxy attacks against those accounts, regardless of how convincing the phishing page is.
AiTM Attack Indicators of Compromise (IoCs)
Security operations teams should monitor for the following signals that may indicate an active AiTM attack against your organization:
- Login from a new IP geolocation immediately after a normal login from a different location
- Unusual user-agent strings associated with automated browser sessions (indicating cookie replay)
- Login activity outside business hours from accounts that have no history of off-hours access
- Multiple failed MFA attempts followed by a successful session with no corresponding MFA approval log
- Email forwarding rules created shortly after login (common attacker persistence technique)
- New OAuth app authorizations or consent grants shortly after authentication events
- Access to sensitive data or financial systems immediately after login from a new device/location
AiTM Attacks and Compliance: What You Need to Know
If your organization operates under regulatory frameworks, AiTM attacks present specific compliance risks:
Regulation | Relevant Requirement | AiTM Risk |
NIST CSF 2.0 | Protect: Identity Management & Access Control (PR.AA) | Session cookie theft defeats identity controls |
SOC 2 Type II | Logical Access Controls | Unauthorized session access violates access control requirements |
PCI DSS v4.0 | Multi-factor authentication for all access (Req. 8.4) | AiTM bypasses MFA, non-compliant if unmitigated |
HIPAA | Access Control (164.312(a)(1)) | Session hijacking allows unauthorized PHI access |
ISO 27001:2022 | A.8.2 Privileged Access Rights | Stolen session gives unauthorized privileged access |
Auditors and assessors are increasingly asking about AiTM-specific controls. Simply documenting that MFA is in place is no longer sufficient, you need to demonstrate phishing-resistant MFA (FIDO2) or equivalent compensating controls.
The Zero-Trust Imperative
AiTM attacks highlight exactly why the Zero Trust security model is no longer optional for organizations with serious security requirements. Zero Trust operates on the principle of ‘never trust, always verify’, meaning authentication is not a one-time event but a continuous process.
In a Zero Trust architecture:
Every access request is evaluated against current context, device health, location, behavior analytics
- Short-lived tokens replace long-lived session cookies wherever possible
- Lateral movement is minimized through micro-segmentation
- Privileged access requires just-in-time approval and step-up authentication
- Session anomalies trigger immediate re-authentication challenges
The combination of Zero Trust architecture, FIDO2 authentication, and post-quantum cryptography planning represents the strongest possible defense against AiTM attacks today and into the quantum era.
Conclusion: The Attack That Broke MFA, And What Comes Next
Adversary-in-the-Middle proxy phishing attacks represent one of the most important shifts in the threat landscape over the past five years. They do not break MFA by brute force, they simply wait for it to complete, then steal the prize on the other side: the session cookie that proves you are you.
Understanding this attack is the first step. Deploying the right defenses, especially FIDO2 phishing-resistant MFA, Continuous Access Evaluation, and Conditional Access policies, is the second. And beginning your organization’s post-quantum cryptography transition is the third, longer-term imperative.
The quantum threat may feel distant, but the attackers harvesting your encrypted traffic today are betting you will not be ready. The best time to start is now.
