Defending Against AitM Phishing - Practical Steps

Right, we need to talk about adversary-in-the-middle phishing. AitM has become one of the most significant threats facing organisations, and if you haven’t been hit yet, it’s probably only a matter of time before someone in your environment runs into one of these attacks. I’ve dealt with the aftermath of several over the past year, and the pattern is depressingly consistent: MFA was in place, the user authenticated “correctly,” and the attacker still got in.

So what can you actually do about it?

How AitM Phishing Works

For those who haven’t come across this in detail, here’s the short version. Traditional phishing steals your password. AitM phishing steals your session.

The attacker sets up a proxy server between the victim and the legitimate sign-in page (usually Microsoft’s Entra ID login). When the user hits the phishing page, they see what looks like a real Microsoft sign-in. And because the attacker’s server is proxying the real login page in real time, it IS the real login page — just served through the attacker’s infrastructure.

The user enters their credentials. The proxy forwards them to Microsoft. Microsoft prompts for MFA. The user completes MFA. Microsoft issues a session token. The proxy grabs that token before passing the response back to the user. As far as the user’s concerned, they’ve signed in normally. But the attacker now has a valid session token and can access the account without needing to re-authenticate.

This is why traditional MFA — push notifications, SMS, authenticator codes — doesn’t save you here. The user IS completing real MFA. The attacker just intercepts the resulting token. Toolkits like Evilginx have made this trivially easy to set up, and I’m seeing these attacks increase month on month.

The Defence: Phishing-Resistant Authentication

The single most impactful thing you can do is deploy phishing-resistant authentication methods. These are methods that are bound to the legitimate domain and can’t be proxied. Full stop.

FIDO2 Security Keys and Passkeys

FIDO2 authentication works because the cryptographic challenge is bound to the origin (the actual URL). If a user is on a phishing site at login.m1crosoft.com, the FIDO2 key won’t respond because the origin doesn’t match login.microsoftonline.com. The attack just fails. The user can’t accidentally authenticate to the wrong site, even if they wanted to.

Passkeys (device-bound or synced) work on the same principle. They’re FIDO2 under the hood, just with a friendlier deployment model. For most organisations, I’d recommend starting with device-bound passkeys in Microsoft Authenticator or FIDO2 security keys — depends on your environment and user base.

Windows Hello for Business

WHfB is also considered phishing-resistant when used with Entra ID. It uses a TPM-bound key tied to the device and the identity provider. Solid option for managed Windows devices.

Certificate-Based Authentication

CBA is another phishing-resistant option, though deployment complexity is higher. If you’ve already got a PKI infrastructure, it might make sense. For most organisations starting from scratch, I’d point you towards FIDO2/passkeys first.

Conditional Access - Enforcing It

Having phishing-resistant methods available is only half the battle. You need to actually enforce them. This is where Conditional Access comes in.

Step 1: Require Phishing-Resistant Authentication for High-Value Targets

Start with your most sensitive accounts and scenarios:

• All administrator accounts — create a policy targeting directory roles (Global Admin, Security Admin, etc.) that requires authentication strength of “Phishing-resistant MFA”
• Sensitive applications — anything containing sensitive data should require phishing-resistant auth
• High-risk sign-ins — use risk-based policies to step up to phishing-resistant auth when risk is detected

The authentication strength feature in Conditional Access is what makes this possible. You can use the built-in “Phishing-resistant MFA” strength or create a custom one. Head to Entra ID > Protection > Conditional Access > Authentication strengths to set this up.

Step 2: Token Protection (Token Binding)

Token protection in Conditional Access binds the session token to the device that requested it. Even if an attacker intercepts a token, they can’t replay it from a different device. This is currently supported for Windows devices accessing Exchange Online and SharePoint Online.

To enable it, create a Conditional Access policy with the session control “Require token protection for sign-in sessions.” Fair warning — this is still evolving in terms of which platforms and applications are supported, so check the current documentation before deploying widely.

Step 3: Require Compliant or Hybrid Joined Devices

Another layer that significantly reduces AitM risk. If you require that devices are Intune-compliant or Hybrid Azure AD joined, an attacker who steals a session token still can’t use it from their own unmanaged machine.

Set this up in Conditional Access by requiring “Require device to be marked as compliant” or “Require Microsoft Entra hybrid joined device” as a grant control.

Step 4: Continuous Access Evaluation

Make sure Continuous Access Evaluation (CAE) is switched on. CAE allows Entra ID to revoke access tokens in near real-time when certain events occur — user disabled, password changed, location change. It won’t prevent the initial AitM attack, but it limits the window an attacker has to use a stolen token. Every minute counts.

The Deployment Plan

Here’s the order I’d recommend, based on what’s worked well in practice:

1. Audit your current state. Use the authentication methods activity report in Entra ID to understand what methods people are actually using today. What caught me off guard the first time I did this was how many accounts were still using SMS as their only MFA method.
2. Register phishing-resistant methods. Start with IT and security teams, then expand outward. Use Temporary Access Pass to bootstrap FIDO2 registration if needed.
3. Create authentication strength policies. Start in report-only mode targeting admin accounts. Let it run for a few weeks so you can spot issues before they become outages.
4. Enforce for admins first. Switch the policy out of report-only. Fix any access issues that come up.
5. Expand to all users over time. Phased rollout, department by department. Be clear with users about what’s changing and why.
6. Layer on device compliance requirements. Defence in depth.
7. Enable token protection where supported.

Don’t Forget the Basics

While you’re working on phishing-resistant auth, don’t neglect the fundamentals:

• Make sure your risky sign-in and risky user policies are active in Entra ID Protection
• Review your break-glass account procedures — these accounts should use FIDO2 keys stored securely offline
• Keep an eye out for suspicious inbox rules and consent grants — both are common post-compromise moves
• Think about restricting user consent to applications to prevent OAuth phishing

Wrapping Up

AitM phishing isn’t going away. If anything, it’s going to get worse as the tooling becomes more sophisticated and more widely available. The good news is that the defences exist and they work. Phishing-resistant authentication stops these attacks dead — it’s not a “reduces risk” situation, it’s a “the attack fails completely” situation.

Deploying at scale isn’t trivial, and I won’t pretend otherwise. But every admin account you protect with FIDO2 is one less account an attacker can compromise through AitM. Start there and expand.

For the full technical detail, Microsoft’s documentation on phishing-resistant authentication and Conditional Access authentication strength are excellent places to start.

If you’re working through this and want to talk it through, you know where to find me.