Adversary-in-the-Middle (AiTM) phishing has become one of the most effective ways of compromising accounts protected by conventional multi-factor authentication (MFA).
There are several ways to defend against it. Some prevent the attack from succeeding, some reduce the likelihood of a user encountering it, and others identify the compromise once it has happened.
For years, we’ve focused on stopping phishing at the point of delivery — filtering emails and blocking malicious websites. Those controls are valuable, but phishing persists, and delivery is only one part of an AiTM attack. The attack ultimately depends on authentication passing through attacker-controlled infrastructure, giving us another opportunity to stop it without chasing every new phishing page.
How AiTM phishing works
Traditional phishing typically involves tricking someone into handing over their credentials. MFA makes those credentials significantly less useful because the attacker still needs to satisfy an additional authentication requirement.
AiTM phishing gets around this by involving the victim in a live authentication process.
Rather than simply collecting credentials, the attacker uses infrastructure under their control to relay authentication, in real time, to the legitimate identity provider, such as Microsoft Entra ID.
- A user follows a link to a phishing website that appears to be a legitimate sign-in page.
- The attacker-controlled infrastructure relays the authentication process to the real identity provider.
- The user enters their credentials and completes an MFA challenge, believing they are signing in normally.
- If authentication succeeds, the attacker can capture the resulting authenticated session and potentially use it to access the account.
The MFA challenge was genuine. The user expected it, after all they thought they were logging into the impersonated site, so they completed the MFA challenge successfully. The problem is that the attacker was controlling the authentication flow.
This is why conventional MFA methods, including TOTP and push-based authentication, do not reliably prevent AiTM attacks.
Phishing-resistant MFA: the preferred solution
FIDO2/WebAuthn authentication, including passkeys and hardware security keys, addresses this problem at the authentication protocol level.
Unlike conventional MFA, FIDO authentication is cryptographically bound to the legitimate service’s origin. An attacker cannot simply relay an authentication challenge through a phishing domain and obtain a valid authentication result.
For conventional reverse-proxy AiTM phishing, that is exactly the protection we want.
Where phishing-resistant authentication is correctly enforced, without allowing users to fall back to weaker methods, it provides a strong defence against this class of attack.
Organisations should be moving towards phishing-resistant authentication, particularly for privileged accounts and access to sensitive systems.
Why isn’t everyone using it?
The difficulty is rarely whether FIDO2 works. It’s whether an organisation can enforce it consistently across its entire environment.
For example, consider an organisation with several thousand users, a mixture of corporate and personally owned devices, external contractors and applications with different authentication requirements.
There are practical questions to address:
- Can every user register and use an appropriate authenticator across all their devices?
- What happens when a security key is lost or a user replaces their phone?
- Can the organisation support passkeys on unmanaged devices without introducing unacceptable restrictions?
- Are all applications and authentication flows compatible?
- Can users still select a weaker authentication method when their preferred method is unavailable?
- How are onboarding, account recovery and emergency access handled?
There’s also a tendency to assume that everyone works at a desk, with a laptop and a mobile phone readily available. For many organisations, that’s simply not how people work.
Consider an industrial environment where mobile phones may be prohibited for safety or security reasons, USB devices are restricted, and staff move between shared workstations. Or a school, where students aren’t permitted to use their phones during lessons. Issuing every student a hardware security key introduces its own challenges around cost, loss and support. And what about teachers? Is it reasonable to expect them to authenticate using their phones in classrooms where they’re enforcing a no-phones policy for students?
These aren’t particularly unusual circumstances, but they’re easily overlooked when discussing authentication from the perspective of someone sitting at a desk in an office.
None of this means phishing-resistant MFA is impractical in these environments. There are ways to address many of these challenges, but they require thought, investment and sometimes changes to how people work. The difficulty isn’t necessarily deploying FIDO2; it’s enforcing it consistently across an organisation without making everyday activities unnecessarily difficult or introducing exceptions that undermine the protection.
BYOD is not inherently incompatible with FIDO2. Modern passkeys, including cross-device authentication, make phishing-resistant authentication entirely practical in many unmanaged-device scenarios.
But supporting passkeys and enforcing them as the only acceptable authentication method are different things.
An organisation may successfully deploy passkeys to most of its workforce while retaining conventional MFA for particular users, devices, applications or recovery processes.
Those exceptions create an issue because attackers now don’t need to defeat FIDO2 if they can persuade a user to authenticate using a weaker method.
This doesn’t undermine the case for phishing-resistant MFA. It explains why organisations often need additional defences while they work towards universal enforcement.
Preventing authentication through attacker infrastructure
There is, however, another way to interfere with AiTM attacks.
An attacker using an AiTM phishing proxy must communicate with the legitimate identity provider. That connection comes from infrastructure controlled or used by the attacker.
If the identity provider knows that the connection originates from AiTM infrastructure, it can reject the authentication.
Microsoft Entra ID provides a useful mechanism for doing this through Conditional Access and Named Locations.
An organisation can maintain a list of IP addresses associated with AiTM proxy infrastructure and configure Conditional Access to block sign-ins originating from those locations.
The important difference is that the control operates at the identity provider.
The user might still click the phishing link, enter a password and attempt to complete MFA. However, if the proxy’s source IP address is already identified and blocked, Conditional Access can deny access before the attacker obtains a usable authenticated session.
Strictly speaking, Conditional Access is evaluated after first-factor authentication, so this does not mean credentials cannot be disclosed. It means the attacker can be prevented from completing the sign-in.
Finding the infrastructure early enough
Blocking a known malicious IP address or ranges is straightforward in principle. Knowing which IP addresses to block is the more interesting challenge.
Many phishing defences concentrate on the websites users visit. These are the frontend components of an AiTM attack.
However, the infrastructure responsible for communicating with the legitimate identity provider is often separate. This backend infrastructure can persist across multiple phishing domains, campaigns and changes to the attacker’s delivery mechanisms.
At Lab539, we actively hunt both frontend and backend AiTM infrastructure, with particular emphasis on the latter.
We investigate infrastructure as adversaries prepare and position it, rather than relying exclusively on indicators collected from successful attacks.
This allows us to identify some infrastructure before it is used against victims.
Our AiTM Feed makes that intelligence available to organisations through existing security controls, including Microsoft Entra ID Conditional Access and Microsoft Defender.
It doesn’t require an additional endpoint agent to enforce the Entra-based blocking control, it can protect authentication attempts originating from managed and unmanaged devices, and it can be deployed in seconds using controls that already exist in your environment.
A common criticism of IP-based blocking is that attackers can simply change their IP addresses. Of course they can, and they do. But that doesn’t make IP addresses ineffective as a preventative control. Much of that criticism assumes we’re collecting indicators from yesterday’s attacks and hoping they’ll still be useful tomorrow.
Our approach is different. We’re actively hunting infrastructure while attackers are preparing it, often before it’s been used in an attack. If we identify and block an AiTM proxy before someone attempts to authenticate through it, the fact that the attacker could move to another IP address tomorrow doesn’t diminish the value of preventing today’s attack.
This is the distinction we explore in our article on Pre-Attack Indicators. The IP address is simply the actionable output. It’s the ability to continually discover new adversary infrastructure, early enough to act on it, that makes the approach effective.
Does infrastructure blocking stop every AiTM attack?
No, and it’s important to be clear about that.
Infrastructure blocking depends on identifying the systems being used and making appropriate decisions about which indicators to enforce.
Adversaries can change infrastructure, rotate IP addresses, use residential proxy networks, or route traffic through legitimate hosting platforms. Shared infrastructure also creates risks of blocking legitimate activity.
The quality, freshness and context of the intelligence are therefore critical. Doing this well requires active hunting, an ability to adapt rapidly and a lot of creativityy.
This is not equivalent to phishing-resistant authentication, which addresses a weakness in the authentication mechanism itself.
Instead, infrastructure blocking provides an additional defensive layer, especially where conventional MFA remains in use.
Other controls still matter
Email security, protective DNS, secure web gateways and browser security can all prevent users from reaching phishing infrastructure.
Endpoint protection can identify malicious activity and, where suitable browser or web protection is deployed, interrupt phishing attempts.
Identity threat detection can help identify suspicious authentication and session activity, while session controls and token protection can limit what an attacker can do with stolen credentials or tokens.
These controls are valuable. They also have different coverage and different points at which they can intervene.
A phishing email might arrive through an unexpected route. A malicious website might be hosted on an otherwise legitimate service. A user might authenticate from an unmanaged device. An identity risk signal might only appear after the session has been established.
Effective defence requires understanding those limitations rather than assuming that having a product in place means the attack is covered.
We see this regularly in practice. Our AiTM Feed is deployed in environments protected by some of the industry’s most highly regarded email security and phishing protection products. Yet we still see AiTM authentication attempts reaching the identity provider, where our intelligence enables them to be blocked. And it happens with frustrating regularity.
That’s not a criticism of those products. They prevent a great deal of malicious activity, much of which we’ll never see. But it’s a useful reminder that preventing the delivery of an attack and preventing the attack itself are two different things. An attack that gets past one set of controls doesn’t necessarily have to succeed.
Evidence from a real attack
In June 2025, a Lab539 customer encountered an active AiTM phishing campaign.
The attack involved a phishing email, multiple redirects, Cloudflare-hosted frontend infrastructure and separate backend infrastructure used to perform authentication.
The user attempted to authenticate, but Microsoft Entra ID rejected the authentication because the proxy’s IP address was included in a Conditional Access policy populated by Lab539’s AiTM Feed.
The attacker did not obtain an authenticated session through that attempt.
We documented the attack, including the associated infrastructure, authentication logs and investigation, in our AiTM Non-Incident Report.
It’s one example, not a claim that every AiTM attack can be prevented this way. But it demonstrates the practical difference between detecting an attack and having a control already in place to prevent the authentication from succeeding.
What should organisations do?
Our recommendation is to approach AiTM prevention in layers.
First, adopt and enforce phishing-resistant authentication wherever practical. It is the strongest defence against conventional authentication-proxy attacks and should be the long-term objective.
Second, protect the remaining authentication paths. Where conventional MFA is still permitted, consider controls that can prevent authentication through known adversary infrastructure.
Third, retain detection and response capabilities. No preventative control has complete coverage. Organisations still need to recognise suspicious activity, revoke compromised sessions, investigate incidents and recover accounts.
And finally, validate the controls against the attack they’re intended to prevent.
Being able to detect session hijacking is not the same as preventing it. Being able to block a phishing URL is not the same as blocking its backend authentication infrastructure.
It’s worth asking exactly what a security product prevents, rather than assuming it stops the whole attack.
Lab539 AiTM Feed
Lab539 hunts adversary-in-the-middle infrastructure and provides intelligence that organisations can apply through existing security controls to prevent authentication through known malicious proxies.
