What actually happens
Traditional phishing steals a password. AiTM (Attacker-in-the-middle) steals the live session.
The attacker stands up a proxy between your user and the real Microsoft sign-in page. The user clicks a link, sees a genuine Microsoft login (because it is genuine, relayed through the proxy), enters their credentials, and completes the MFA prompt on their phone as normal. Everything looks right to them because everything is real. The proxy sits in the middle and copies the authentication token that Microsoft issues once MFA passes.
That token is the prize. It is proof to Entra that this session already satisfied MFA, so when the attacker replays it, Exchange Online, SharePoint, Teams, and OneDrive all accept it without prompting again. The password is irrelevant now, and so is the second factor. A stolen post-authentication token bypasses MFA because it represents an MFA that already happened.
What comes next is fast and quiet. Microsoft’s own detection guidance describes the typical sequence. The attacker opens the mailbox, searches for anything with payment or banking language, and creates inbox rules that move security alerts and replies straight to a folder the user never checks. Then they register their own device or authenticator, which gives them a way back in even after the password is reset. By the time anyone notices, the account has been used to phish the finance team or the org’s customers.
Why your current setup probably doesn’t stop it
Here is the uncomfortable part. Microsoft has been clear that Entra ID and its surrounding services give no direct protection against the initial token theft itself. The tooling helps you detect and contain what happens next, but the moment of capture is not something standard MFA prevents.
Two things follow from that.
First, ordinary MFA is not the control people think it is against this attack. It stops password replay completely, which is why it remains non-negotiable. It does not stop token replay, because the token exists precisely because MFA already succeeded.
Second, the fix is not one setting. It is a small stack of controls that each close part of the gap. Most of them are within reach on Business Premium, and the ones that aren’t are worth knowing about before you promise your board this is fully handled.
The controls that actually help
Four things move the needle, roughly in order of value for a typical Australian SME.
- Phishing-resistant authentication is the real answer. Passkeys and FIDO2 security keys, along with Windows Hello for Business and certificate-based authentication, bind the sign-in to the physical device and the legitimate domain. There is no code for a user to read out and no token for a proxy to lift in a replayable form. The ACSC lists phishing-resistant MFA as the strongest form of multi-factor authentication in its guidance on the subject, and it is the direction Microsoft points to first. This is the one to plan for even though rolling out keys or passkeys across a workforce takes effort.
- Token Protection binds the token to the device. This is a Conditional Access session control that makes a token usable only on the device it was issued to, so a lifted token replayed from the attacker’s machine is rejected. The good news for SMEs is that Microsoft moved this feature down to Entra ID P1, so it is included in Microsoft 365 Business Premium rather than needing E5. The catch is not the licence, it is the coverage. Token Protection currently applies to native desktop apps reaching Exchange Online, SharePoint Online, and Teams on Windows 10 or later devices that are Entra joined, hybrid joined, or registered. Browser-based sessions are not covered, and iOS and macOS are still in preview. So it protects the managed-Windows-and-native-app path and leaves the browser path open. Verify the current supported scope against Microsoft Learn before you lean on it.
- Attack disruption and session revocation limit the damage. Automatic attack disruption in Microsoft Defender XDR is designed to contain an in-progress token-theft attack by disabling the account or forcing re-authentication once the pattern is detected, and the fuller version of this is an E5-tier Defender capability. Revoking a session invalidates the stolen token so the attacker is locked out, though a revoked session only helps once you know to pull it. Session revocation itself is available to you regardless of tier. These are containment, not prevention.
- Conditional Access narrows where a token is worth anything. Policies that require a compliant or managed device to reach email and files mean a token replayed from an unmanaged attacker machine hits a wall even if it is valid. This is standard Conditional Access available on Business Premium, so it is the one most SMEs can act on today without a licence upgrade.
What this does and doesn’t cover
None of this makes you immune, and pretending otherwise is the mistake. A determined AiTM operator can still capture a token. What this stack does is make the token hard to replay, shrink the window it is useful in, and get you an alert while it still matters.
The honest ranking for a Business Premium SME looks like this. You can act on Conditional Access device controls now, and Token Protection is available to you now on P1, so turn both on for the managed Windows fleet. You should start planning phishing-resistant authentication now, because it is the control that addresses the root of the problem and it covers the browser path that Token Protection does not. The genuine higher-tier items are the fuller automated attack disruption and risk-based Conditional Access, which sit with Entra ID P2 and E5-tier Defender. Those are a cost-versus-risk decision to make with eyes open rather than the thing standing between you and a basic defence.
What to do next
Five steps, ranked by impact with the lowest effort first.
- Turn on the Conditional Access device controls you already own. Require a compliant or Entra-joined device for Exchange Online and SharePoint. This is P1 and available on Business Premium today.
- Confirm you can revoke a session fast. Make sure your admins know how to revoke sign-in sessions and disable an account in Entra and Defender, and that the alert reaches a human who acts. A control you cannot trigger in time is not a control.
- Start the move to phishing-resistant methods. Passkeys or FIDO2 keys for your highest-risk accounts first, finance, executives, and admins, then wider. This is the fix that addresses the cause and covers the browser path.
- Turn on Token Protection for your managed Windows devices. It is included in Business Premium on P1, so enforce it in report-only mode first, then for your native desktop apps on Entra-joined Windows machines. Know that it does not cover browser sessions, which is why step 3 matters.
- Rehearse the response. Run the token-theft scenario once. Find out whether you would actually spot the inbox rule and the new device registration before the money left.
If you want a second set of eyes on whether your current Entra configuration would survive an AiTM attempt, that is exactly the kind of thing a focused identity assessment answers.