What is an Adversary-in-the-Middle (AiTM) Attack?

Adversary-in-the-Middle (AiTM) attacks have become the primary method used to compromise organisations. Unlike traditional phishing - where an attacker builds a fake login page to harvest a password - AiTM attacks use a live reverse proxy sitting between the user and the real identity provider. The user authenticates normally, MFA and all, while the attacker captures the authenticated session token in real time.

The result: MFA is bypassed, the session is hijacked, and the attacker is in. Often within seconds.

The term “Adversary-in-the-Middle” is the designation used in the MITRE ATT&CK framework (T1557). While it shares conceptual roots with classic Man-in-the-Middle (MitM) attacks, AiTM specifically refers to the active interception and manipulation of authentication flows - not passive network eavesdropping.

This represents an evolution in credential theft. Traditional phishing captured passwords for later re-use - an approach that MFA was designed to defeat. AiTM emerged as the direct response: rather than storing credentials for later, adversaries proxy them to the identity provider as the user types, riding the authentication flow in real time. MFA doesn't fail here - it works exactly as designed. The problem is that it's authenticating the attacker's session.

How AiTM Attacks Work

An AiTM attack has two layers of infrastructure: the frontend and the backend.

The frontend is what the victim sees - a phishing page that mimics a legitimate login screen. These are cheap and disposable. Attackers generate thousands of frontend URLs daily, often using recently registered domains on inexpensive TLDs (.space, .live, .solutions) hosted behind Cloudflare or, in more sophisticated campaigns, behind services like Azure Front Door to add legitimacy.

The backend is the reverse proxy engine - the component that actually performs the attack. When a user enters their credentials on the frontend, the backend proxies those credentials to the real identity provider (Microsoft Entra, Okta, Google Workspace, or whatever is being targeted). The IdP responds normally, including issuing an MFA challenge. That challenge is passed back through the proxy to the user, who approves it - because from their perspective, everything looks exactly as expected.

The moment the user completes authentication, the backend captures the session token. The password is almost secondary; the session cookie is the prize. With that token, the attacker can access the victim’s account from their own infrastructure without needing to authenticate again.

This is why AiTM attacks are so effective against standard MFA. Push notifications, SMS codes, and authenticator app codes all work exactly as designed - the user approves a legitimate MFA challenge. The problem is that the session being authenticated belongs to the attacker’s proxy, not the user’s browser.

The Toolkit Landscape

AiTM attacks are powered by a small number of widely-used toolkits and phishing-as-a-service platforms. Understanding these matters because each leaves distinct fingerprints in the infrastructure they deploy.

Evilginx is the most established open-source AiTM framework. Originally released as a proof of concept, it has become the backbone of countless real-world campaigns. It operates as a standalone reverse proxy and is highly configurable, supporting custom “phishlets” that define how to intercept authentication for specific targets.

Tycoon2FA operated as a phishing-as-a-service (PhaaS) platform until its takedown by Europol in March 2026. At its peak, Tycoon2FA was responsible for campaigns targeting over 500,000 organisations per month, with tens of millions of phishing messages sent. Its infrastructure was characterised by short-lived domains (often active for only 24–72 hours) rotating across cheap TLDs. The platform lowered the barrier for less technically skilled attackers to run AiTM campaigns at scale.

Starkiller is a newer toolkit that we track actively. Like other AiTM frameworks, it deploys backend proxy infrastructure that can be identified during the preparation phase - before attacks are launched.

Other frameworks including Muraena and Modlishka also see active use, though the ecosystem continues to evolve as platforms are disrupted and new ones emerge.  

Frontend vs Backend: Why the Distinction Matters

The security industry has historically focused on detecting and blocking frontend infrastructure - the phishing URLs that appear in emails. This is a reactive game of whack-a-mole. Attackers can stand up a new frontend domain in minutes for near-zero cost. By the time a URL is reported, analysed, and added to a blocklist, the campaign has often already moved on.

Backend infrastructure is a different story. Setting up and maintaining a reverse proxy engine is more expensive and technically complex than registering a throwaway domain. We routinely see the same backend infrastructure supporting thousands of frontend URLs over periods of weeks or months, and being reused across entirely separate campaigns. It is the persistent, high-value component.

This is why disrupting backend infrastructure has a disproportionate impact. Identify one backend proxy engine and block it from authenticating to your identity provider, and you neutralise every campaign running through it - including ones that haven’t started yet.

At Lab539, we focus specifically on identifying backend AiTM infrastructure during the preparation phase. When Microsoft identified the threat actor Void Blizzard in 2025, the infrastructure behind that campaign had already been in our feed and actively blocked in the environments we protect - weeks before the first phishing emails were sent. The same was true for infrastructure used in ConsentFix campaigns, which we were blocking before the technique had even been publicly disclosed.

What Happens After Compromise

The damage from an AiTM attack doesn’t stop at session hijack. Modern identity providers expose APIs that attackers weaponise within seconds of gaining access. The most common automated post-compromise actions we observe are:

MFA device registration - the attacker registers their own MFA device (a phone number, an authenticator app) on the compromised account. Even if the victim’s password is reset and sessions are terminated, the attacker can re-authenticate using their own MFA device.

Email rule creation - silent forwarding rules are created to monitor sensitive communications. These are often configured to forward to an external address and delete the forwarded copy from the victim’s mailbox, making them difficult to spot without deliberate hunting.

Data exfiltration - automated harvesting of files from OneDrive, SharePoint, or other cloud storage connected to the compromised identity.

Business Email Compromise (BEC) - the compromised mailbox is used to send convincing emails to colleagues, customers, or suppliers, often targeting financial processes. Because the emails genuinely come from the victim’s account, they bypass most email security controls.

This automation means that by the time an organisation detects the compromise, the attacker has often already established persistence and begun lateral movement. Resetting the password alone is insufficient - active sessions must be terminated, MFA devices audited, and email rules inspected.

The Scale of the Problem

AiTM attacks have grown rapidly. Microsoft reported a 146% rise in AiTM attacks over 2024, and at Lab539 we observed a 400% increase in AiTM infrastructure between 2024 and 2025. We routinely see in excess of 10,000 new AiTM frontend domains per day, with up to 16,000 new records added to our feed daily.

The migration of organisational authentication to cloud identity providers like Microsoft Entra and Okta has concentrated the attack surface. When businesses ran on-premise Active Directory, there was no single location where authentication for millions of organisations could be targeted. Now there is — and the APIs available to authenticated sessions mean that compromise can be automated at a speed that manual incident response cannot match.

The takedown of Tycoon2FA in March 2026 - a platform responsible for over 64,000 large-scale phishing campaigns - demonstrates both the scale of the problem and the fact that enforcement alone cannot solve it. Other platforms will fill the gap, as they always do.

How to Defend Against AiTM Attacks

There is no single control that eliminates AiTM risk. Effective defence requires layers, each addressing a different stage of the attack chain.

Phishing-resistant MFA (FIDO2 / Passkeys) is the strongest single control. Hardware-bound credentials like FIDO2 security keys are cryptographically tied to the legitimate domain - they simply will not authenticate through a proxy. The challenge is deployment at scale: not every organisation can move every user to FIDO2, and fallback methods (SMS, push) often remain enabled, creating a gap.

Proactive infrastructure intelligence targets the attack before the user ever sees a phishing email. By identifying and blocking AiTM backend infrastructure during the preparation phase - before campaigns launch - organisations can prevent the proxy from authenticating to their identity provider even if a user clicks through. This is the approach Lab539 takes with AiTM Feed, integrating directly with Microsoft Defender and Conditional Access policies to block infrastructure in real time.

Conditional Access policies provide a critical enforcement layer. Restricting authentication to compliant devices, trusted locations, and known network ranges reduces the attack surface. However, default Microsoft conditional access policies can inadvertently weaken defences against AiTM - a topic we have written about in detail.

Token protection is an emerging capability. Microsoft’s token binding features aim to tie session tokens to the device that created them, making stolen tokens unusable on the attacker’s infrastructure. This is promising but still maturing.

Continuous Access Evaluation (CAE) allows identity providers to revoke sessions in near real-time based on policy changes or risk signals, reducing the window an attacker has to operate with a stolen token.

Protective DNS can block user access to known malicious frontend domains, breaking the attack chain at the first step. Feeding AiTM infrastructure data into DNS filtering adds another defensive layer.

Proactive vs Reactive: A Different Approach

Most threat intelligence is reactive. An attack occurs, infrastructure is identified after the fact, indicators are published, and blocklists are updated. This means there has to be a victim before defences are put in place.

We don’t believe that has to be the case. At Lab539, we actively hunt down AiTM infrastructure - both frontend and backend - and identify it during the preparation phase. Our feed typically contains infrastructure days to weeks before major security vendors have visibility of it, and in many cases we detect infrastructure that never appears on their radar at all.

This is not a phishing URL feed. Phishing URL feeds are reactive by nature - they catalogue URLs after they have been used in attacks. AiTM Feed targets the backend proxy infrastructure behind account takeover attacks, identified proactively before campaigns launch.

The practical result: when a new AiTM campaign spins up targeting your organisation, the infrastructure behind it is already blocked in your environment. Your users can click the link, and the attack still fails - because the proxy cannot authenticate to your identity provider.

Ready to see it in action? Start a free 30-day trial or find us in the Azure Marketplace.