Audience: IT Pros

Platform: Microsoft 365

Series: MFA & Conditional Access

Part: 2 of 7

In Part 1 of this series, we looked at how AiTM phishing defeats MFA by stealing session cookies — and I mentioned that a single Conditional Access policy could have stopped the attack that cost a UK legal firm £87,000 in under five minutes.

The most common message I got after that post was some version of:

"OK. But where do I actually start?"

This post is the answer to that question.

I'm going to walk you through the first five Conditional Access policies you should deploy in any Microsoft 365 SMB environment — in the right order, with the right safeguards, and with enough context that you understand why each one matters before you touch anything.

This is written for the Level 1 IT tech who's been handed M365 admin access and told to "tighten things up." No assumed security background. Real configurations. Honest caveats about what can go wrong.

Let's get into it.

Before You Touch Anything: The Break Glass Account

I'm going to say this once, clearly, and then repeat it throughout this post because it matters that much.

Before you create a single Conditional Access policy, you need a Break Glass account.

A Break Glass account is a cloud-only, emergency admin account that is explicitly excluded from all Conditional Access policies. It exists for one reason: to give you a way back into your tenant if a misconfigured policy locks everyone out — including you.

This isn't a theoretical concern. Locking yourself out of a Microsoft 365 tenant with a badly configured CA policy is a rite of passage in this industry. It happens to experienced admins. It will happen to you if you skip this step.

Here's how to set one up properly:

Creating your Break Glass account:

Entra ID Admin Center
→ Users → New User → Create User

Display name:    BreakGlass-Admin (or similar — make it obvious)
Username:        breakglass@yourdomain.onmicrosoft.com
                 (use the .onmicrosoft.com domain, NOT your custom domain)
Password:        Generate a strong random password (20+ characters)
                 Store it in a sealed physical envelope, locked away
                 Also store in your password manager with restricted access

Assign it the right role:

Entra ID → Roles and Administrators
→ Global Administrator → Add Assignment → [your Break Glass account]

Exclude it from everything:

Every single Conditional Access policy you create should have this account in the exclusions list. No exceptions.

Monitor it religiously:

The Break Glass account should never be used in normal operations. Set an alert for any sign-in from this account — that's either you responding to a genuine lockout, or an attacker who has somehow compromised it.

Microsoft Sentinel / Defender → Analytics Rules → New rule
Alert on: SigninLogs where UserPrincipalName == "breakglass@yourdomain.onmicrosoft.com"

If you don't have Sentinel, set a Logic App or use the Entra ID audit log alerts instead. The point is: if that account ever signs in, you need to know immediately.

Understanding Report-Only Mode

Before we get to the policies themselves, there's one more concept you need to understand: Report-Only mode.

Every Conditional Access policy can be set to one of three states:

• Off — Policy is disabled, does nothing

• Report-only — Policy evaluates against all sign-ins and logs what it would have done, but doesn't actually enforce anything

• On — Policy is live and enforcing

Report-only mode is your safety net. For every policy in this guide, I'm going to recommend you run it in report-only first — ideally for at least a week in a live environment — and review the results before turning it on.

You can review report-only results in:

Entra ID → Monitoring → Sign-in logs
→ Filter: "Conditional Access" column → "Report-only: Failure"

Any entry showing as "Report-only: Failure" is a sign-in that would have been blocked or challenged if the policy were live. Review these before enabling. You'll often find service accounts, shared mailboxes, or legacy applications you didn't know existed that would break on day one.

That's exactly the point. Find out in report-only, not in production.

The Five Policies — In Order

Here's the sequence. Order matters because some policies are foundational and others build on top of them. Enabling them out of sequence can create gaps or — worse — lock out the very accounts you need to manage the others.

Policy 1: Block Legacy Authentication

Enable this one first. Always. No exceptions.

Legacy authentication refers to older protocols that don't support modern MFA challenges: SMTP AUTH, POP3, IMAP4, Exchange ActiveSync (basic auth), and older Office client authentication. These protocols are baked into older email clients, some line-of-business applications, and — critically — they completely bypass MFA.

If you have MFA enforced but legacy authentication is allowed, an attacker with stolen credentials can use a legacy protocol to sign in and MFA will never be triggered. All your MFA work is irrelevant for any sign-in using these protocols.

⚠️ Common misconception: "But we disabled Basic Auth in Exchange Online." Disabling Basic Auth in Exchange Online is not the same as blocking legacy authentication at the Entra ID / Conditional Access level. Do both.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA001 - Block Legacy Authentication

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
  Resources: All cloud apps
  Conditions:
    Client apps: ☑ Exchange ActiveSync clients
                 ☑ Other clients
    (Leave Browser and Mobile apps/desktop clients UNCHECKED)

Access Controls → Grant:
  ● Block access

Enable policy: Report-only first

💡 Before you enable: Run in report-only for one week. Check the Sign-in logs for any "Other clients" sign-ins. Common culprits are:

• Old printers or scanners sending email via SMTP AUTH

• Line-of-business applications using basic auth

• Older versions of Outlook (pre-2016)

For printers/scanners: configure them to use a service account with SMTP AUTH explicitly enabled (you can allow legacy auth per-account while blocking it globally). For LOB apps: this is the impetus to get them updated or replaced.

Why first? Because blocking legacy auth is the fastest win with the broadest impact. Until this is on, everything else you do has a hole in it.

Policy 2: Require MFA for All Users

With legacy auth blocked, you can now enforce MFA for all modern authentication sign-ins. This is the foundational policy that everything else builds on.

A word on the right way to do this, because there are a few approaches and they're not all equal:

• Security Defaults — Microsoft's one-click MFA enforcement. Fine as a starting point, but it's a blunt instrument with no customisation. It also conflicts with Conditional Access policies — you must disable Security Defaults before creating CA policies. If you're here reading this guide, you should be using CA, not Security Defaults.

• Per-User MFA — The old way. Avoid it. It doesn't integrate with Conditional Access properly, creates management headaches, and doesn't give you the policy granularity you need.

• Conditional Access — Require MFA for all users — The right way. This is what we're building.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA002 - Require MFA - All Users

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
  Resources: All cloud apps
  Conditions: None

Access Controls → Grant:
  ● Grant access
    ☑ Require multifactor authentication

Session:
  Sign-in frequency: Every time
    (For high-security environments. For normal users, you can
     leave this at default — we'll refine it in a later policy)

Enable policy: Report-only first

💡 Check before enabling: In report-only, look for any service accounts or shared accounts that don't have MFA registered. These will break when the policy goes live. Use this opportunity to do a sweep: Entra ID → Users → Filter by "MFA registration status."

Also check: do all your users have the Microsoft Authenticator app set up? If not, now is the time to run an MFA registration campaign before this policy goes live.

The order matters here: Policy 1 (blocking legacy auth) should be live before this one. If you enable MFA enforcement while legacy auth is still allowed, users on legacy clients will start getting blocked — but not because of your MFA policy. The error messages will be confusing and you'll spend hours troubleshooting the wrong thing.

Policy 3: Block High-Risk Sign-Ins (Entra ID Protection)

With the basics in place, we can start using intelligence. Entra ID Protection — included in Microsoft 365 Business Premium and Entra ID P2 — evaluates every sign-in using Microsoft's threat intelligence and assigns a risk score: Low, Medium, or High.

High-risk sign-ins are those that Microsoft's systems have flagged as almost certainly malicious. This includes:

• Sign-ins from known attacker IP addresses

• Sign-ins accompanied by credential stuffing patterns

• Sign-ins immediately after the same account was seen on a credential dump

• Impossible travel (signed in from London, then Lagos, 10 minutes apart)

• Token replay — which is exactly what happens when an attacker uses a stolen session cookie

🎯 Remember our AiTM adversary from the first blog in this series?: This is how Entra ID Protection helps catch AiTM attacks. When an attacker replays a stolen cookie from a different IP or device, the anomaly often triggers a high-risk sign-in flag — which this policy will automatically block.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA003 - Block High Risk Sign-ins

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
  Resources: All cloud apps
  Conditions:
    Sign-in risk: ☑ High

Access Controls → Grant:
  ● Block access

Enable policy: Report-only first

A note on licensing: This policy requires Entra ID P2 or Microsoft 365 Business Premium for the sign-in risk condition. If you're on a lower tier, you won't see the "Sign-in risk" option. This is one of the strongest arguments for Business Premium — the risk-based CA capability alone is worth the licensing delta for most SMBs.

Optional — Medium risk, require MFA:

You can also create a companion policy that challenges Medium risk sign-ins with MFA rather than blocking them outright. This is more user-friendly and still provides meaningful protection:

Name:        CA003b - Require MFA for Medium Risk Sign-ins

Conditions:
  Sign-in risk: ☑ Medium

Grant:
  ● Grant access
    ☑ Require multifactor authentication

⚠️ Review before enabling: In report-only, any High risk sign-ins you see are worth investigating immediately — even though the policy isn't live yet. These are real flagged events, not simulations.

Policy 4: Require Compliant Device for Microsoft 365

This is the policy I referred to in the AiTM post as the one that stops cookie theft cold.

When a device compliance requirement is in place, Microsoft 365 checks that the device making the request is:

1. Enrolled in Intune — Microsoft's device management platform

2. Compliant with your compliance policy — which you define (encryption enabled, AV running, OS up to date, etc.)

An attacker who has stolen a session cookie and is replaying it from their own machine will fail this check. Their machine isn't enrolled in your Intune. The cookie replay is blocked. Access denied.

This policy requires Intune to be set up and devices to be enrolled before it can do anything useful. If you haven't done that yet, this is the one to pause on — but it's also the one to prioritise getting there.

Prerequisites

Before enabling this policy:

1. Set up an Intune compliance policy — Intune Admin Center → Devices → Compliance Policies → Create Policy. At minimum, require: BitLocker encryption, Windows Defender active, OS minimum version.

2. Enrol your devices — Either via Autopilot, manual enrolment, or Group Policy (hybrid join). All devices that users sign in from must be enrolled before this policy goes live.

3. Check enrolment status — Intune Admin Center → Devices → All Devices. Every device your users work from should appear here and show as "Compliant" before you enable the policy.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA004 - Require Compliant Device - M365

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
  Resources: Office 365
             (Scope to O365 specifically, not "All cloud apps" —
              some apps may not support device compliance checks)
  Conditions: None

Access Controls → Grant:
  ● Grant access
    ☑ Require device to be marked as compliant

Enable policy: Report-only first — run for at LEAST two weeks

⚠️ This one needs extra care in report-only. The failure logs will show you every device that isn't enrolled. Before you enable, every device in your environment that users need to work from must be enrolled and compliant. Personal devices (BYOD) that users work from are a particular challenge — you'll need to decide whether to enforce Intune enrolment on personal devices (requires App Protection Policies as an alternative), or whether to accept that BYOD remains a gap.

For most SMBs: enforce compliant device on company-owned devices, use App Protection Policies for BYOD. That's a separate guide — but don't enable this policy on "All Devices" until you've thought through your BYOD position.

Policy 5: Restrict Azure Portal and Admin Tools to Admins Only

The final foundational policy is one that prevents a compromised standard user account from accessing the Azure portal, Entra ID admin center, or Microsoft Intune admin center.

Standard users have no legitimate reason to access these portals. If a regular employee's account is compromised and an attacker starts poking around the admin portals, that's a major escalation risk. This policy shuts that door.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA005 - Restrict Admin Portals to Admins

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
                         [All admin accounts / admin role members]
  Resources: Microsoft Admin Portals
             (This is a specific option in the resource selector —
              covers Azure portal, Entra ID admin center,
              Microsoft 365 admin center, Intune admin center)
  Conditions: None

Access Controls → Grant:
  ● Block access

Enable policy: Report-only first

💡 Exclusions matter here. Make sure every account that legitimately needs admin portal access is in the exclusions — either individually or via a group. The Break Glass account must also be excluded. After enabling, test by signing in as a standard user and attempting to access portal.azure.com — you should get an access blocked message.

Putting It All Together: The Deployment Sequence

Here's the order to go from report-only to live, with recommended time in report-only before enabling:

The compliant device policy goes last because it has the most prerequisites and the highest potential to impact users if deployed before devices are enrolled. Everything else can layer on while you're working through Intune enrolment.

Naming Conventions: The Thing Nobody Talks About

Before I let you go, a word on naming. It sounds boring. It will save you significant pain at 11pm when something breaks and you're trying to figure out which policy is doing what.

Use a consistent naming convention from day one:

CA[number] - [Action] - [Target/Scope]

Examples:
CA001 - Block - Legacy Authentication
CA002 - Require MFA - All Users
CA003 - Block - High Risk Sign-ins
CA003b - Require MFA - Medium Risk Sign-ins
CA004 - Require Compliant Device - M365
CA005 - Block - Admin Portals Non-Admins

The number prefix means your policies sort in deployment order in the portal. The action prefix (Block / Require / Allow) tells you at a glance what a policy does before you open it. The scope tells you what it applies to.

Future you will thank present you.

What You've Built

After deploying these five policies, your Microsoft 365 environment now:

• Blocks all legacy authentication — closing the MFA bypass hole

• Requires MFA for all modern sign-ins — the foundational layer

• Automatically blocks high-risk and anomalous sign-ins — using Microsoft's threat intelligence

• Stops cookie replay attacks — by requiring device compliance (once Intune is rolled out)

• Limits the blast radius of a compromised standard account — by locking them out of admin portals

That's not a complete security programme. There's more to do — Named Locations, token lifetime controls, app-specific policies, and the more advanced Entra ID Protection configurations we'll cover later in this series. But it's a genuine, meaningful baseline that puts you significantly ahead of most SMB environments.

The attacks that are successfully compromising UK businesses right now are not sophisticated. They're exploiting the absence of exactly these controls.

Get these in place. Then we'll build on them.

Quick Reference Checklist

• [ ] Break Glass account created, password stored securely offline

• [ ] Break Glass account assigned Global Administrator role

• [ ] Security Defaults disabled (required before CA policies work)

• [ ] CA001 — Block Legacy Authentication — report-only, then live

• [ ] CA002 — Require MFA All Users — report-only, then live (after CA001)

• [ ] CA003 — Block High Risk Sign-ins — report-only, then live

• [ ] CA005 — Restrict Admin Portals — report-only, then live

• [ ] Intune set up and devices being enrolled (prerequisite for CA004)

• [ ] CA004 — Require Compliant Device — report-only for 2+ weeks, then live

• [ ] Break Glass account excluded from ALL policies above

• [ ] Sign-in alerts configured for Break Glass account

• [ ] Naming convention documented and followed

Up Next in the Series

Part 3: MFA Fatigue Attacks — How Attackers Weaponise Your Authenticator App Against You

We've built the defensive layer. In Part 3, we zoom back out to the threat side — specifically the technique that has successfully breached Uber, Caesars, and countless SMBs: MFA push fatigue. How it works, why people fall for it, and the free settings that make it dramatically harder to pull off.

CyberSync UK — Practical cybersecurity for UK businesses and the people who defend them. Questions about your M365 setup? Get in touch at cybersync.uk

Tags: ConditionalAccess EntraID Microsoft365 MFA ITsecurity UKcyber Intune EntraIDProtection cybersecurity ITpro

Series Link: MFA & Conditional Access

Audience: IT Pros & End Users

Platform: Microsoft 365

Threat Class: Adversary-in-the-Middle (AiTM) Phishing

Series: MFA & Conditional Access

Part: 1 of 7

Telling your users to enable Multi-Factor Authentication (MFA) has been Level 1 IT advice for years — and rightly so. It's one of the most effective defences we have. So imagine the sinking feeling when you discover that an attacker has walked straight past it.

That's exactly what's happening with Adversary-in-the-Middle (AiTM) phishing — a technique that doesn't crack MFA, doesn't brute-force passwords, and doesn't need malware on the victim's device. Instead, it tricks the victim into handing over everything the attacker needs in a single, polished, completely convincing interaction.

⚠️ Why This Matters for UK SMBs

AiTM kits like Evilginx, Modlishka, and Muraena are freely available and well-documented. You don't need to be a nation-state actor to pull this off. Financially motivated criminals are actively deploying these tools against UK businesses using Microsoft 365 — particularly targeting finance, legal, and professional services firms.

A Quick Refresher: How MFA Actually Works

Before we can understand how AiTM defeats MFA, let's quickly recap how MFA protects you in the first place. When you sign into Microsoft 365 normally:

1. You enter your username and password.

2. Microsoft's server challenges you for a second factor (Authenticator app push, SMS code, etc.).

3. You approve the push or enter the code.

4. Microsoft issues you a session cookie — essentially a digital "you've been verified" sticker that your browser stores.

5. Every subsequent request to Microsoft 365 uses that cookie. You don't re-authenticate on every click.

💡 Key Concept — The Session Cookie

The session cookie is the crown jewel. Once Microsoft has issued it after a successful MFA challenge, it's proof of a complete authentication. If an attacker steals this cookie, they don't need your password or your MFA code ever again. They can import it into their browser and pick up your session as if they were you.

How AiTM Phishing Actually Works

Traditional phishing steals credentials. AiTM phishing is far more sophisticated — it acts as a real-time relay between the victim and the legitimate Microsoft sign-in page. The attacker sits in the middle, letting the real authentication happen while silently siphoning everything off.

The Traffic Flow

Victim's Browser  →→  AiTM Proxy (Evilginx)  →→  Microsoft login.microsoft.com
                                ↑↓
                   [Steals cookie in transit]
                                ↓
                    Attacker's Browser  →  Full M365 Access ✓

The victim successfully signs in and sees nothing unusual. The attacker has a fully authenticated session. MFA was correctly completed — by the victim — but the resulting proof of authentication was stolen in transit.

Step-by-Step: The Kill Chain

Step 1 — Phishing Email Lands in the Inbox

The victim receives a convincing email — often a fake "shared document" notification, invoice, voicemail alert, or IT security warning. The link leads to a lookalike domain (e.g. login.microsoft-secure-portal.com) hosted on the attacker's AiTM proxy, complete with a valid TLS certificate. The padlock is there — it just doesn't mean what most people think it does.

Step 2 — Victim Sees a Perfect Microsoft Login Page

The proxy fetches the real Microsoft sign-in page and serves it to the victim in real time. Every pixel looks authentic because it is the authentic page — just relayed through the attacker's server. The victim enters their credentials, which the proxy captures and forwards silently to the real Microsoft servers.

Step 3 — Microsoft Issues a Real MFA Challenge

Because the credentials were real, Microsoft responds with an actual MFA challenge. The proxy relays this back to the victim's browser. The victim sees their normal Authenticator push notification or SMS code request. Nothing looks wrong.

Step 4 — Victim Approves MFA, Completing Authentication

The victim approves the push or enters their code. This is forwarded to Microsoft through the proxy. Microsoft is satisfied — a real user, real password, real second factor. It issues a session cookie.

Step 5 — Proxy Intercepts and Clones the Session Cookie

As the session cookie passes through the proxy on its way to the victim's browser, the attacker's kit makes a copy. The victim gets their cookie and signs in normally, completely unaware.

Step 6 — Cookie Replay: Full Account Access Without Authentication

The attacker imports the stolen cookie into their own browser. Microsoft sees a valid, recently-issued session cookie and grants full access — email, OneDrive, Teams, SharePoint, the whole tenant. No password needed. No MFA needed. From here, attackers typically pivot to Business Email Compromise (BEC), data exfiltration, or lateral movement.

What Attackers Are Actually Using

Several polished, well-maintained tools exist — and some are freely available.

Evilginx

Evilginx is the most widely observed AiTM framework in the wild. Originally created as a penetration testing tool, it functions as a man-in-the-middle reverse proxy with built-in "phishlets" — configuration files that define how to intercept and relay authentication sessions for specific targets like Microsoft 365 and Google Workspace. It handles TLS termination, cookie extraction, and credential logging automatically.

# Simplified Evilginx phishlet structure for M365
name: microsoft
proxy_hosts:
  - phish_sub: login
    orig_sub: login
    domain: microsoft.com
    session: true
auth_tokens:
  - domain: .microsoft.com
    keys: [ESTSAUTHPERSISTENT, ESTSAUTH]
    # ↑ These are the M365 session cookies it hunts for

Modlishka & Muraena

Alternative open-source AiTM frameworks with similar capabilities. Muraena has been observed combined with NecroBrowser to automate post-compromise actions on stolen sessions at scale.

Phishing-as-a-Service (PhaaS) Kits

Perhaps most concerning: you can now buy AiTM-capable phishing kits as a subscription service on underground forums. Caffeine, W3LL Panel, and similar PhaaS platforms offer point-and-click campaign management, pre-built Microsoft 365 lures, and automatic cookie harvesting — with no technical knowledge required.

⚡ The W3LL Panel

Discovered by Group-IB in 2023, the W3LL Panel PhaaS kit was responsible for compromising at least 8,000+ Microsoft 365 accounts across 56,000+ corporate emails, generating an estimated $500,000 in criminal revenue. It specifically included an AiTM module targeting Microsoft 365 with pre-built lures designed to bypass spam filters.

Real-World Incidents

These aren't theoretical. AiTM campaigns have caused serious, measurable harm to real organisations — including UK businesses.

Microsoft Threat Intelligence — Large-Scale AiTM Campaign (July 2022)

Microsoft's Security Research team published details of a campaign that targeted over 10,000 organisations using AiTM phishing pages specifically designed to harvest Microsoft 365 session cookies. After gaining access, attackers used compromised accounts within minutes to initiate Business Email Compromise (BEC) fraud — targeting financial contacts at partner companies with fake invoice payment requests.

The speed was the defining characteristic: attackers set up auto-forwarding rules and accessed payment thread emails within 2–5 minutes of cookie theft, then immediately deleted the sign-in alert emails so the victim wouldn't notice.

Impact: 10,000+ organisations, BEC fraud at scale, forwarding rules set on compromised accounts.

Scattered Spider — MGM & Caesars (September 2023)

While US-based, the Scattered Spider threat group's techniques are a masterclass in social engineering combined with AiTM. They combined phishing, SIM swapping, and AiTM to bypass MFA at scale against major enterprises. The MGM incident alone caused estimated losses of over $100 million.

Critically, the UK's National Cyber Security Centre (NCSC) issued specific guidance following these incidents warning that the group's tactics were being adapted and replicated by criminal actors targeting European businesses, including UK financial services firms.

Impact: $100M+ losses, NCSC warnings issued for UK organisations.

UK Professional Services Firm — BEC via AiTM (2023, Anonymised)

A UK-based legal firm with around 150 staff had Microsoft 365 MFA enforced across all accounts. A finance manager received a convincing "DocuSign" email — delivering an Evilginx-backed AiTM page. They signed in, approved the Authenticator push, and thought nothing of it.

Within 4 minutes, the attacker accessed the mailbox, located a live client payment email thread, and modified the bank account details in a reply. The client transferred £87,000 to the attacker's mule account before the fraud was discovered. Only £12,000 was recovered through the banking fraud recall process. The firm faced significant reputational damage and a potential ICO investigation for the data breach element.

Impact: £87,000 lost, 4 minutes from compromise to fraud, ICO notification required.

Nobelium / APT29 — Microsoft 365 Targeting (Ongoing, 2021–Present)

Nobelium — the Russian state-linked group behind the SolarWinds attack — has incorporated AiTM techniques as a standard part of their Microsoft 365 intrusion playbook. They've been documented targeting government supply chains, including contractors and suppliers who interact with UK government departments. Their campaigns are notable for patience: after stealing cookies, they often conduct weeks of passive monitoring before taking any action, making detection extremely difficult.

Impact: Nation-state threat, UK government supply chain targeting, long-term undetected persistence.

Why "Standard" MFA Doesn't Stop This

It's important to be precise here: MFA isn't broken. It still stops the vast majority of credential-based attacks — password spray, credential stuffing, brute force. But AiTM exploits a specific gap: the difference between authenticating the user and trusting the session.

These MFA methods are vulnerable to AiTM because they only verify identity at login time, not on an ongoing basis:

🎯 The Fundamental Issue

All of the above methods verify who you are at the moment of login. They do nothing to verify where the resulting session will be used from. AiTM exploits this gap by letting authentication happen legitimately, then using the resulting proof in an entirely different context.

What Actually Stops AiTM: Phishing-Resistant MFA & Conditional Access

Here's the good news: Microsoft has built the tools to address this problem into Entra ID. The bad news: most SMBs aren't using them because configuration takes effort and often requires higher-tier licensing. Here's what actually works.

Tier 1: Phishing-Resistant MFA

These methods are fundamentally immune to AiTM because they cryptographically bind authentication to the legitimate domain. They cannot be relayed.

✅ FIDO2 Security Keys (e.g. YubiKey)

A physical USB/NFC key that uses public key cryptography. When authenticating, it signs a challenge that includes the domain name. An AiTM proxy on a different domain cannot forge this — the cryptographic signature will fail. This is currently the gold standard for phishing resistance.

✅ Windows Hello for Business

Biometric or PIN-based authentication tied to a specific, enrolled, Entra ID-joined device. The private key never leaves the device's TPM chip. Phishing a Windows Hello session is cryptographically infeasible.

✅ Microsoft Authenticator with Number Matching + Context

Alone, push notifications are AiTM-vulnerable. But with number matching enabled (the user must type the number shown on the sign-in page into the app) and additional context (the app shows the sign-in location and application name), MFA fatigue attacks are significantly harder. Note: this doesn't fully prevent AiTM, but adds meaningful friction and is free to enable today.

Tier 2: Conditional Access Policies

Even if you can't immediately roll out phishing-resistant MFA to everyone, Conditional Access policies in Entra ID give you powerful controls to reduce the blast radius of a successful AiTM attack.

1. Require Compliant Device Effectiveness against AiTM: Very High | Licence: Microsoft 365 Business Premium / Entra ID P1 + Intune

Requires device to be Intune-enrolled and compliant before granting M365 access. An attacker's browser with a stolen cookie will fail this check immediately — the cookie replay attack is stopped cold. This is your single highest-value AiTM mitigation if you have Business Premium licensing.

2. Sign-in Frequency / Token Lifetime Controls Effectiveness: Moderate | Licence: Entra ID P1

Forces re-authentication after a short period. Stolen cookies expire quickly, limiting the attacker's window of access. Doesn't prevent initial compromise, but reduces the damage window significantly.

3. Named Locations — Block Non-UK Traffic Effectiveness: Moderate | Licence: Entra ID P1

Define trusted IP ranges and block sign-ins from unusual geographies. Many attackers use residential proxies in the UK to bypass this, but it stops opportunistic overseas actors.

4. Require Phishing-Resistant MFA Strength Effectiveness: Highest | Licence: Entra ID P1

Enforce that only FIDO2 or Windows Hello is accepted as MFA — standard push notifications are rejected for sensitive applications. This completely defeats AiTM as the authentication method cannot be relayed.

5. Entra ID Protection — Risk-Based Conditional Access Effectiveness: High | Licence: Entra ID P2 / Microsoft 365 Business Premium

Microsoft's ML-driven risk engine evaluates each sign-in. Anomalous properties — new country, impossible travel, anonymising proxy — trigger step-up authentication or an automatic block. A stolen cookie used from an unusual IP is flagged as high-risk and blocked automatically.

Recommended Configuration: Compliant Device Policy

If you can only implement one Conditional Access policy today to address AiTM, make it a compliant device requirement.

Entra ID Admin Center → Protection → Conditional Access → New Policy

Policy Name:  "Require Compliant Device - M365 Apps"

Assignments:
  Users:      All Users (EXCLUDE your Break Glass account!)
  Resources:  Office 365
  Conditions: None (apply to all platforms)

Access Controls → Grant:
  ☑ Require device to be marked as compliant

Session:
  Sign-in frequency: 1 hour (for sensitive roles)
  Persistent browser session: Never persistent

Enable Policy: Report-only first → then On

⚠️ Before You Enable

Always create a Break Glass account — a cloud-only, excluded admin account with a very strong password stored securely offline — before enabling any Conditional Access policy. A misconfigured policy can lock everyone out of your tenant, including you.

How to Detect AiTM Attacks in Your Environment

Prevention is essential, but you need to be able to spot when an attack has succeeded.

Entra ID Sign-In Logs

Navigate to Entra ID → Monitoring → Sign-in logs and look for:

• Two sign-ins in quick succession from different IP addresses or countries for the same user

• Sign-in flagged as using a token from an anonymising proxy or VPN

• Impossible travel — user signed in from London, then from Eastern Europe 10 minutes later

• Sign-in Risk Level: High — Microsoft's detection may have already flagged it

Microsoft Unified Audit Log

In Microsoft Purview → Audit (or Microsoft 365 Defender), search for:

• ⚠️ New inbox rules created — especially rules that forward, delete, or hide emails. A classic post-AiTM move.

• ⚠️ MailItemsAccessed events from an unusual IP or user agent — access without a corresponding sign-in event

• ⚠️ New delegated mailbox permissions or external email forwarding rules added

• ⚠️ OAuth app consents — attacker granting a malicious app persistent access

💡 If You Suspect a Compromise

Don't just reset the password — that won't revoke stolen session cookies. You must use Revoke-AzureADUserAllRefreshToken (PowerShell) or the "Revoke sessions" button in Entra ID to invalidate all active sessions. Then reset the password, investigate the audit log, and check for persistence mechanisms like inbox rules and OAuth app grants.

What to Tell Your Users (In Plain English)

Technical controls are essential, but your users are still the first line of detection — and the primary target. Here's a pragmatic, non-fear-mongering message to share with them:

"The padlock doesn't mean the website is genuine." A padlock just means the connection is encrypted — not that the site is legitimate. Microsoft will only ever ask you to sign in at login.microsoftonline.com or login.microsoft.com. Check the full domain carefully.

"If you're asked to approve an MFA push you didn't initiate — decline it immediately and call IT." You should only ever be approving Authenticator requests that you triggered yourself.

"Urgency is a red flag." Phishing lures almost always create false urgency. "Your account will be suspended." "Action required immediately." Pause, question it, and call IT if unsure.

IT Team Action Checklist

Work through these in priority order:

• [ ] Enable Authenticator Number Matching — Entra ID → Authentication Methods → Microsoft Authenticator. Enable number matching and additional context for all users. Free. Do this today.

• [ ] Deploy Conditional Access — Compliant Device Required — Start in report-only mode for two weeks, then enable. Highest-value AiTM mitigation with Business Premium licensing.

• [ ] Enable Entra ID Protection — Configure sign-in risk policies to block High risk sign-ins automatically (requires P2 or Business Premium).

• [ ] Pilot FIDO2 Security Keys — Start with finance, IT admins, and directors. YubiKey 5 series, approximately £45–55 per key. These are your highest-value targets.

• [ ] Enable Unified Audit Logging — Ensure it's on across your tenant. Set log retention to at least 90 days.

• [ ] Configure Safe Links (Defender for Office 365) — Rewrites URLs in emails and can identify AiTM phishing domains at click time.

• [ ] Run Phishing Simulations — Use Microsoft Attack Simulator (included in Business Premium) to test user responses to realistic AiTM-style lures.

• [ ] Create and document a Break Glass account — Before any Conditional Access deployment. Store credentials offline in a secure location.

• [ ] Review OAuth app consents — Entra ID → Enterprise Applications. Remove any unknown or unused third-party app consents that could be attacker persistence.

• [ ] Block legacy authentication protocols — SMTP AUTH, POP, IMAP bypass MFA entirely. Use a Conditional Access policy to block legacy auth if you haven't already.

The Bottom Line

AiTM phishing represents a genuine evolution in the threat landscape — one that directly neutralises a control that most organisations have come to rely on.

MFA is not enough on its own. Push notifications, SMS codes, and TOTP apps are all bypassable by AiTM. This doesn't mean you should remove MFA — it means you need to go further.

Compliant device enforcement is your highest-value Conditional Access control. An attacker with a stolen cookie connecting from their own machine will fail a device compliance check cold. This breaks the AiTM attack chain decisively.

Phishing-resistant MFA is the end state to work towards. FIDO2 keys for your highest-risk users — finance, IT admins, directors — should be a near-term priority. Windows Hello for Business gives you the same protection at scale for managed devices.

Detection matters as much as prevention. Audit logging, Entra ID Protection, and knowing what post-compromise indicators to look for are what give you a fighting chance of catching a breach quickly — before £87,000 leaves your client's bank account.

The adversaries targeting UK SMBs are using commercial-grade tooling and well-rehearsed playbooks. The good news is that Microsoft has built equally capable defences into the M365 stack — they just need to be switched on and configured correctly.

The organisations that take AiTM seriously today are the ones that won't be calling Action Fraud tomorrow.

Published by CyberSync UK — Cyber Security Education for End Users, IT Professionals, and the C-Suite. Have questions about your Microsoft 365 security posture? Get in touch at cybersync.uk

Tags: microsoft365 cybersecurity phishing MFA AiTM EntraID ConditionalAccess infosec UKcyber ITsecurity