What is AiTM?

Adversary in the Middle Defined

Picture yourself signing into a business-critical app. Ordinary phishing would just show you a fake login page and hope you type your password into it. An AiTM attack goes a step further: instead of a static fake, the attacker stands up a transparent relay (a proxy server) that sits directly between your browser and the real application.

Click the link and your browser is really talking to the attacker's server, which is talking to the genuine service on your behalf at the same instant. Everything you send flows through it: username, password, one-time MFA code. The moment the service authenticates you it hands back a session cookie, and the proxy pockets that cookie and replays it immediately to take over your session.

That is what makes a phishing proxy attack so dangerous: it converts plain credential theft into full session hijacking, usually before the victim has any idea their credentials left the building.

How AiTM Differs from a Traditional Man in the Middle (MITM) Attack

The names rhyme, but a modern AiTM attack is really the traditional Man in the Middle (MITM) idea grown up and retooled to walk straight past today's security controls.

Feature	Adversary in the Middle (AiTM)	Traditional Man in the Middle (MITM)
Primary Goal	Steal session cookies for MFA bypass and identity-based attacks.	Eavesdrop, inject malicious code, or modify data in transit.
Key Technique	Reverse Proxy or Phishing Proxy.	ARP spoofing, DNS cache poisoning, or Wi-Fi eavesdropping.
Target Layer	Authentication and Identity layer (HTTPS).	Network and Transport layers (HTTP/TLS).
Success Criteria	Capturing the valid, post-authentication session cookie.	Breaking or intercepting TLS/SSL encryption.

The gap is really one of goal and scope. Classic MITM is after the encryption or the network traffic itself. AiTM does not bother breaking encryption at all: it lives inside the encrypted session, playing the real client to the service and the real service to the user, and reaches for the one thing a successful login produces that is worth stealing: the valid session cookie.

How AiTM Attacks Work in Modern Identity and Authentication Flows

The whole attack rides on how web authentication normally works: specifically, cookies standing in for a persistent session.

1. Lure: The attacker sends a phishing email with a link to their reverse proxy server. The link looks like the real service (for example, login.microsoft.com) but actually routes through a fake site like login.evil-site.com.
2. Proxy Setup: The user clicks the link. The attacker's server establishes two simultaneous, encrypted connections: one with the victim's browser and one with the legitimate service (e.g., Microsoft 365 or Google Workspace).
3. Credential Capture: The user enters their username and password. The proxy captures these credentials and immediately passes them to the legitimate service.
4. MFA Bypass: The service prompts for MFA. The user enters the one-time code or approves the push notification. The proxy captures the MFA response and passes it to the service. This is the critical moment: the MFA code is only valid for a short time, but the proxy captures and uses it instantly.
5. Session Hijacking: Upon successful authentication, the legitimate service issues a new, authorized session cookie. The proxy intercepts this cookie before passing the subsequent web page back to the victim. The attacker saves the session cookie for later use, effectively hijacking the authenticated session.

From the victim's side it looks like a clean, successful login. In reality the attacker is now holding a valid, long-lived session token: quiet, immediate access to cloud resources, no password prompt required.

Real-World Attack Scenarios, Including MFA Bypass Cases

None of this is hypothetical. AiTM is an everyday technique for well-resourced crews running identity-based attacks at scale.

Scenario 1: Cloud Email Compromise

An attacker targets a senior executive in an organization using an AiTM proxy specifically targeting their Microsoft 365 login.

• The executive receives an email about a "document sharing alert."
• They click the link and authenticate with username, password, and push-based MFA.
• The attacker's proxy steals the resulting session cookie.
• Hours later the attacker replays that cookie, walks past the executive's MFA, and is reading their mail. From there it is forwarding rules, internal phishing, and quiet data theft, textbook MFA bypass.

Scenario 2: SaaS Application Access

A security engineer is targeted via a fraudulent alert regarding their internal GitLab repository.

• The engineer logs into the malicious proxy, which authenticates them to GitLab with their credentials and time-based one-time password (TOTP).
• The session cookie is stolen.
• With that session the attacker pulls source code, pushes malicious commits, or helps themselves to intellectual property inside the developer platform.

The through-line in both cases is the uncomfortable one: AiTM beats MFA, the very control most organizations are leaning on to protect their identities.

Why AiTM Attacks Are Increasing

The surge in AiTM attacks is no accident: it is what you get when MFA becomes universal and everything moves to the cloud at the same time.

The Problem with MFA Alone

MFA did its job against simple credential theft. Its weak spot is an assumption: that presenting two factors proves you are the user. AiTM quietly voids that assumption, because the proxy is live during the login, the attacker gets the valid MFA token and spends it before it expires. MFA is satisfied; the wrong person walked through.

Focus on Session Cookies

Modern cloud and SaaS platforms hand out long-lived session cookies so people are not re-authenticating every few minutes, convenient for users, and the entire prize for the attacker. That cookie unlocks everything, so grabbing it is the whole point of an AiTM attack.

Availability of Tooling

The barrier to running one of these has dropped through the floor. Frameworks like Muraena and Evilginx are freely available and ship with ready-made configs for popular cloud services, so a fairly unsophisticated operator can stand up a working reverse proxy in an afternoon.

To watch an Evilginx-based AiTM attack unfold end to end (phishing page setup, MFA bypass, then lateral movement in Azure), work through the Bypass Azure MFA with Evilginx lab on Pwned Labs.

Impact and Potential Consequences for Organizations

One AiTM success rarely stays contained: it tends to open the door to an organization-wide breach.

Data Breach and IP Theft

First and most direct is unauthorized access to cloud resources and the theft of sensitive data, customer records, or intellectual property. Because these campaigns tend to go after administrators and executives, the data exposed is often both voluminous and unusually sensitive.

Financial Fraud and Lateral Movement

Once inside the mailbox, attackers pivot to Business Email Compromise (BEC), frequently steering wire transfers to accounts they control. The stolen session also enables lateral movement: the borrowed identity unlocks other linked systems, and ransomware or additional malware can follow.

Reputational Damage

A clean session hijack or MFA bypass erodes confidence in the organization's security, and that damage extends to customers, partners, and regulators. Incident response and potential fines make the bill steep on top of it.

Detection Methods and Defensive Best Practices

Stopping AiTM attacks means layering defenses and, above all, moving past "password plus MFA" as the finish line.

Phishing Education

Train people to catch the tell of a phishing proxy: read the full URL in the address bar, not the friendly text in the email. The page can look pixel-perfect: what has to be right is the domain, and it has to be the real service's domain.

Move to Phishing-Resistant MFA

The strongest answer is phishing-resistant MFA: FIDO2 security keys (a YubiKey, for instance) or certificate-based authentication. These bind the login to a specific device and origin, so a stolen cookie is useless and the proxy has nothing to relay. Blocking that relay is exactly what the FIDO protocol was designed to do.

Session Monitoring and Conditional Access

Your SOC needs detection that assumes the cookie can be stolen:

• Geographical Impossibility: Alert when a session's first login happens in one location but later activity using that session comes from a faraway location just minutes later.
• Token Replay Detection: Monitor for signs that a valid session cookie is being used from a new, unregistered, or anomalous user agent or IP address.
• Conditional Access Policies: Set rules that allow access only from trusted devices managed by the organization and from trusted network locations.

Advanced Endpoint Protection

Back it with endpoint detection and response (EDR) that can spot and block traffic heading to known-bad or freshly registered AiTM proxy domains.

Who Is Most at Risk from AiTM Attacks

Any organization running cloud services on traditional MFA is fair game, but a few groups carry noticeably more risk from these identity-based attacks.

Cloud-First Organizations

Businesses that live in SaaS (Microsoft 365, Salesforce, ServiceNow) are prime targets. Their operational identity and their data both sit in those clouds, so a single stolen session cookie is an immediate route to compromise.

High-Value Targets

Attackers go where the payoff is largest, financially or strategically. That usually means:

• C-Level Executives: Due to access to strategic information and authorization for financial transactions.
• IT Administrators and Security Engineers: As they possess elevated privileges that can lead to large-scale compromise, such as granting persistent access to the entire cloud environment.
• Finance Department Personnel: Due to their involvement in payment processing and wire transfers.

For security professionals and technical leaders the takeaway is blunt: AiTM is the phishing threat to plan for right now, and defenses have to move quickly to shut down MFA bypass and unauthorized session hijacking.

Related Labs

Run an AiTM attack chain from lure to lateral movement:

• Bypass Azure MFA with Evilginx - Deploy an Evilginx-based AiTM phishing proxy, intercept Azure AD authentication flows to capture session tokens despite MFA, and perform lateral movement within the target Azure environment.

Frequently Asked Questions

Is AiTM the same as a traditional MITM attack?

No. An AiTM attack is an advanced, application-layer phishing proxy attack aimed squarely at identity and authentication flows, mainly to lift the post-authentication session cookie and achieve MFA bypass. Traditional MITM tends to live at the network level, eavesdropping or tampering with traffic.

Why is MFA not effective against an AiTM attack?

Because the AiTM attack happens in real time. The proxy grabs the legitimate, single-use MFA token while it is still valid and spends it immediately, completing the login for the victim and stepping around the protection entirely.

What is the most effective defense against AiTM?

Technically, moving to phishing-resistant MFA such as FIDO2 security keys. These tie authentication to the specific origin site, so the attacker's reverse proxy has no way to relay the material successfully.

Are only large companies targeted by AiTM?

No. Big crews may favor large enterprises, but cheap, off-the-shelf AiTM tooling puts organizations of any size in range of this session hijacking technique, especially those still relying on weaker forms of MFA.

How do AiTM attacks target cloud environments?

Adversary in the Middle attacks thrive in cloud and SaaS because those services lean on long-lived session cookies for convenience. Steal the cookie and you have persistent access to email, storage, and other cloud apps, no re-authentication needed.