> root@auth-lab:~# python3 token_replay.py --cookie session.json --target portal.corp.com && echo 'authenticated — no MFA prompt'<span class="cursor-blink">_</span>_
Multi-factor authentication is the single most frequently recommended security control in our penetration test reports. We have recommended it in articles on password cracking, phishing, lateral movement, cloud identity, and service account compromise. It is the control that transforms a stolen password from a complete compromise into a partial one. It is the control that every framework mandates, every insurer asks about, and every board presentation includes.
It is also the control that organisations most frequently believe they have implemented fully — when they have not.
MFA is not a binary state. It is not 'on' or 'off'. It is a set of policies, configurations, protocol restrictions, and session management decisions that, taken together, determine whether an attacker who obtains a user's credentials can actually use them. The gap between MFA is deployed and MFA cannot be bypassed is where this article lives.
On this engagement, we accessed corporate email, SharePoint, and internal applications — all protected by MFA — without cracking a single password and without compromising a single second factor. We did it by going around MFA, not through it.
The client was a professional services firm — approximately five hundred staff — providing accounting and advisory services to mid-market businesses. They handled commercially sensitive financial data for their clients and were subject to regulatory obligations around data protection and information security.
The firm had invested significantly in identity security over the preceding eighteen months. They had migrated to Microsoft 365 with Entra ID (formerly Azure AD) as their identity provider. MFA was enforced for all users via conditional access policies. The Microsoft Authenticator app was the default second factor. Security defaults were enabled. The CISO described their MFA posture as 'comprehensive'.
We were engaged to conduct an authentication resilience assessment — a focused engagement testing the practical effectiveness of the MFA deployment against known bypass techniques. The client wanted to validate that their investment had achieved the protection they believed it had.
It had not.
MFA in Microsoft 365 is enforced through modern authentication — OAuth 2.0 and OpenID Connect — which supports interactive MFA prompts. However, Microsoft 365 also supports legacy authentication protocols — IMAP, POP3, SMTP AUTH, and Exchange ActiveSync — which do not support interactive MFA. These protocols authenticate with a username and password only. If they are permitted, they bypass MFA entirely.
We tested whether legacy authentication protocols were blocked.
The conditional access policy requiring MFA was configured to apply to modern authentication clients only. Legacy authentication clients — IMAP, POP3, SMTP AUTH — were not included in the policy. This is a common configuration gap: the conditional access policy was created using the Entra ID portal, and the 'legacy authentication clients' checkbox was not selected. The policy enforced MFA for browser and mobile app access but allowed username-and-password-only authentication via IMAP.
With a compromised password (obtained via a separate password spray during the engagement), we authenticated via IMAP and had full read access to the user's mailbox — 1,847 emails — without encountering an MFA prompt. The mailbox contained client financial data, internal communications, and shared document links.
The conditional access policy enforcing MFA did not include legacy authentication protocols. IMAP authentication with username and password only provided full mailbox access without MFA. Microsoft recommends blocking legacy authentication entirely via conditional access — this policy was not in place.
MFA protects the authentication event — the moment a user proves their identity. After successful authentication (including MFA), the identity provider issues a session token — a cookie or a JWT that the user's browser presents with subsequent requests to prove they have already authenticated. The session token is the proof of completed MFA.
If an attacker can steal the session token after MFA has been completed, they can present it to the service and be treated as an already-authenticated user. No password needed. No second factor needed. The MFA was completed by the legitimate user. The attacker simply inherits the session.
We demonstrated this using an adversary-in-the-middle (AitM) phishing simulation — a technique we first explored in our sixth article on phishing the finance director.
The user completed MFA correctly. They entered their password. They approved the Authenticator push notification. They did everything right. And yet, the attacker obtained full access to their account — because the AitM proxy sat between the user and Microsoft, relaying the entire authentication flow in real time and capturing the session tokens that were issued after MFA completion.
The captured session token was valid for ninety days — the default persistent SSO token lifetime in Entra ID. For ninety days, the attacker could access the user's email, SharePoint, OneDrive, and Teams without any further authentication. The user's MFA was not bypassed — it was completed and then inherited.
Several controls would have mitigated this. Token binding (now available via Entra ID token protection in preview) ties session tokens to the device that performed the authentication — a stolen token presented from a different device would be rejected. Conditional access policies requiring compliant devices would have rejected the attacker's browser even with a valid token. Shorter token lifetimes reduce the window of exploitation. Continuous access evaluation (CAE) enables near-real-time token revocation.
When a user first enrols in MFA, they register their authentication method — typically by scanning a QR code with the Authenticator app or providing a phone number for SMS codes. The registration process itself requires authentication but, depending on configuration, may not require an existing MFA method — because the user does not yet have one.
We identified that new accounts — including accounts created for contractors and temporary staff — had a grace period during which they could access resources and register for MFA.
Fourteen user accounts were members of the MFA exclusion group. Six had never completed MFA registration. Five had been added during MFA troubleshooting and never removed. Three were former contractor accounts that had not been deprovisioned. All fourteen could authenticate with a password only — no second factor required.
We compromised one — a former contractor account with an active Microsoft 365 licence — via password spray. The account authenticated without MFA and had access to the firm's email and SharePoint environment. The MFA policy was comprehensive. The exclusion group undermined it.
The conditional access policy requiring MFA excluded a security group containing 14 active user accounts — including former contractors with active licences and users who had never completed MFA registration. These accounts authenticated with passwords only, bypassing MFA entirely.
Push notification MFA — where the Authenticator app displays a prompt and the user taps 'Approve' — is convenient and widely deployed. It is also vulnerable to MFA fatigue: an attacker who has obtained a user's password repeatedly triggers the MFA prompt until the user, overwhelmed by notifications, approves one to make them stop.
Microsoft has mitigated this with number matching — where the login screen displays a two-digit number and the user must enter it in the Authenticator app, proving they can see both screens simultaneously. Number matching was enforced in this deployment. However, we tested a variation.
Number matching defeated simple MFA fatigue — the user could not just tap 'Approve' without seeing the number. But when we combined the MFA prompt with a social engineering pretext delivered via Teams (using the compromised contractor account from Bypass 03), the user had a plausible reason to expect the prompt and a context that made approval seem legitimate. They entered the number. We obtained the session.
This bypass illustrates that phishing-resistant MFA — FIDO2 security keys or Windows Hello for Business — is fundamentally different from push-notification MFA. A FIDO2 key cryptographically binds the authentication to the legitimate website's origin. It cannot be proxied through an AitM attack. It cannot be socially engineered. The user does not make a trust decision — the cryptography makes it for them.
| Bypass | Method | MFA Status |
|---|---|---|
| 01 | Legacy IMAP authentication — password only, no MFA prompt | MFA policy did not cover legacy protocols — authentication succeeded without MFA |
| 02 | AitM phishing — user completed MFA; attacker captured session token | MFA was completed by the user — attacker inherited the authenticated session |
| 03 | MFA exclusion group — 14 accounts exempt from MFA policy | MFA policy excluded the accounts — no second factor required |
| 04 | Social engineering augmented MFA prompt — user entered number match | MFA was completed by the user under false pretext — attacker initiated the flow |
Four distinct bypass techniques. None involved compromising the second factor itself. None required breaking the Authenticator app, intercepting an SMS code, or cloning a hardware token. The MFA system worked correctly in every case — it prompted when configured to prompt, and it did not prompt when configured not to prompt. The vulnerabilities were in the configuration, the policy, the token lifecycle, and the human response — not in the MFA technology.
MFA is not a single control. It is a spectrum of implementation maturity, from basic deployment through to phishing-resistant authentication that eliminates entire classes of bypass.
| Maturity Level | Characteristics | Bypasses Prevented |
|---|---|---|
| Level 1: Basic | MFA enabled for some users. SMS or email OTP. Legacy protocols permitted. Exclusion groups unmonitored. | Stops basic credential stuffing. Vulnerable to SIM swap, legacy protocol bypass, exclusion group abuse, AitM phishing. |
| Level 2: Standard | MFA required for all users via conditional access. Authenticator push with number matching. Legacy authentication blocked. | Stops credential stuffing and legacy protocol bypass. Vulnerable to AitM session theft, social engineering of push prompts, exclusion group drift. |
| Level 3: Hardened | All Level 2 + compliant device requirement. Short token lifetimes. CAE enabled. MFA exclusion group monitored and minimised. Token protection enabled. | Additionally stops AitM session theft (token binding). Reduces window of exploitation. Vulnerable to sophisticated social engineering of push prompts. |
| Level 4: Phishing-Resistant | FIDO2 security keys or Windows Hello for Business as primary MFA. Passwordless authentication. Legacy methods disabled. | Eliminates password-based attacks entirely. Immune to AitM phishing (origin-bound). Immune to push notification social engineering. The authentication is cryptographic, not human. |
This client was operating at Level 1–2 — MFA was deployed for most users via Authenticator push with number matching, but legacy protocols were permitted, the exclusion group was unmonitored, session tokens were long-lived without binding, and no phishing-resistant methods were in use. The policy was labelled 'comprehensive'. The implementation had four exploitable gaps.
Blocking legacy authentication is a zero-cost configuration change that eliminates the most straightforward MFA bypass. The conditional access policy must include 'Exchange ActiveSync clients' and 'Other clients' in the client app filter. Any application that legitimately requires legacy authentication (there should be none in 2026) must be migrated to modern authentication before the block is applied.
Reducing the persistent SSO token lifetime limits the window of exploitation after an AitM session token theft. A ninety-day token gives an attacker three months of access from a single phishing success. A twelve-hour token requires the attacker to maintain active infrastructure and re-authenticate frequently. Combined with CAE — which enables near-real-time revocation when risk is detected — short token lifetimes dramatically reduce the value of stolen sessions.
Compliant device requirements in conditional access ensure that only Intune-managed, policy-compliant devices can access Microsoft 365 resources. An attacker replaying a stolen session token from their own device would be blocked because their device does not meet the compliance requirement — regardless of the token's validity.
FIDO2 security keys are the strategic answer. They are immune to AitM phishing because the cryptographic assertion is bound to the legitimate service's origin URL. A phishing site at login.m1crosoft-auth.com would receive a challenge for that domain, not for login.microsoftonline.com, and the key would not sign it. The user does not need to decide whether a prompt is legitimate — the key decides for them, using cryptography that cannot be social-engineered.
The client in this engagement had done more than most organisations. They had deployed MFA. They had enforced it via conditional access. They had rolled out the Authenticator app with number matching. They had invested budget, staff time, and executive attention in identity security. By any reasonable audit checklist, they had MFA.
And yet, we found four distinct ways around it — none of which required compromising the second factor.
The lesson is not that MFA is ineffective. It is that MFA is a configuration surface with dozens of settings, each of which either closes or leaves open a bypass path. Legacy protocols. Exclusion groups. Token lifetimes. Session binding. Device compliance. Phishing resistance. Each is a configuration choice. Each has a default. And the defaults are rarely the secure option.
Deploy MFA. Then test it. Test it the way an attacker would — not by asking is MFA enabled? but by asking can I get in without it? The answer may be more uncomfortable than the checkbox suggests.
Until next time — stay sharp, stay curious, and check your MFA exclusion group. It has more members than you expect.
This article describes an authentication resilience assessment conducted under formal engagement with full written authorisation from the client. Phishing simulations were conducted against pre-approved test accounts with the knowledge of the account holders. No client data was exfiltrated. All session tokens obtained during testing were revoked immediately after demonstration. All identifying details have been altered or omitted to preserve client confidentiality. Unauthorised access to computer systems is a criminal offence under the Computer Misuse Act 1990. Do not attempt to replicate these techniques without proper authorisation.
Hedgehog Security conducts authentication resilience assessments that go beyond 'is MFA enabled?' We test legacy protocol exceptions, session token theft and replay, exclusion group drift, conditional access policy gaps, and social engineering resistance. We answer the question that matters: can an attacker get in without MFA? If the answer is yes, we show you exactly what to fix.