Multi-factor authentication stops the majority of automated credential attacks against Microsoft 365 accounts. It does not stop adversary-in-the-middle phishing, known as AiTM. The attack is designed to work after the MFA prompt clears — and the defenses against it are already included in the license most small offices use.
How does an AiTM attack work?
A conventional phishing attack lures someone into typing a password on a fake login page. AiTM goes further. The attacker operates a proxy server positioned between your employee and the real Microsoft sign-in page. The phishing email links to this proxy. Your employee sees what looks like a normal Microsoft login — because the proxy is forwarding the actual Microsoft sign-in page in real time, not a static copy of it.
Here is the sequence:
- Your employee enters her username and password at the proxy page.
- The proxy forwards those credentials to the real Microsoft server.
- Microsoft sends an MFA prompt. The proxy relays it to her screen.
- She approves the push notification or types her code.
- Microsoft accepts the response and issues a session token — the credential that tells Microsoft this browser session is already authenticated.
- The proxy captures that token before it ever reaches her browser.
The attacker now holds a valid, authenticated session. They can read email, access files in OneDrive, and send messages without ever knowing the password or the MFA code, because the session token is what Microsoft accepts as proof of identity for the rest of that session.
Why doesn't the MFA code stop this?
SMS codes, authenticator app codes, and push notifications verify that a real person completed the login. They do not verify that the browser receiving the session token belongs to that person. The MFA step succeeds — your employee did exactly what she was supposed to do — and the attacker enters on the strength of a credential she never knew was taken.
This is why the advice to "just turn on MFA" is incomplete. Standard MFA methods raise the bar substantially against credential stuffing and basic phishing. They were not designed to bind authentication to a specific trusted device or verified domain, which is precisely what AiTM exploits.
What defenses does Microsoft 365 Business Premium include?
Business Premium includes two controls that, when properly configured, break this attack at the source.
Phishing-resistant MFA
FIDO2 hardware security keys and Windows Hello for Business use cryptographic authentication bound to a specific, verified domain. A FIDO2 credential registered for Microsoft's sign-in domain can only be used on that domain. A proxy site operating on a different domain cannot complete the exchange — the cryptographic assertion will not match, and authentication fails at the proxy rather than passing through it.
This is the most direct technical counter to AiTM available in Business Premium. An employee authenticating with a FIDO2 key cannot have that authentication silently proxied. Both methods are available in Business Premium through Entra ID (formerly Azure Active Directory). Employees with access to email, financial records, or client files should be migrated to phishing-resistant MFA first.
Conditional Access policies
Entra ID P1, included in Business Premium, enables Conditional Access policies. A policy requiring sign-ins to come from devices enrolled in Microsoft Intune — also included in Business Premium — means authentication cannot complete from an unmanaged machine. An attacker working from a laptop not enrolled in your organization's device management hits a policy block.
Conditional Access also controls session lifetime and persistent browser sessions. Shorter session lifetimes reduce how long any compromised token remains usable. These settings impose minimal friction on employees logging in from their normal work devices while meaningfully narrowing an attacker's window to act.
A note on Security Defaults
Microsoft's Security Defaults are a starting point for organizations that have not yet configured Conditional Access. They enforce a baseline MFA requirement. They do not enforce phishing-resistant authentication methods and do not provide the granular device compliance controls described above. If your organization still relies on Security Defaults, it is time to move to a properly configured Conditional Access policy.