If your organisation still believes that having Microsoft Authenticator or SMS-based MFA makes it immune to Account Takeover (ATO), there's a problem. Hard2bit's DFIR teams are responding weekly to critical intrusions in Microsoft 365 tenants where MFA was bypassed in seconds — not because MFA failed, but because attackers walked around it entirely.
The technical reality is uncomfortable: attackers no longer try to guess passwords or break MFA algorithms — they simply sidestep them. This article dissects, at the protocol level, how modern Adversary-in-the-Middle (AiTM) attacks use reverse proxies (Evilginx2, Muraena, Modlishka) to relay sessions and capture authentication cookies. We then look at what happens after compromise, how to detect AiTM in Sentinel with KQL, and the strategic mitigation that actually works: phishing-resistant MFA with FIDO2, channel binding, conditional access and continuous access evaluation.
The evolution of phishing: Adversary-in-the-Middle (AiTM) and reverse proxies
Static phishing (cloning a login HTML and harvesting credentials) is useless against MFA. To bypass it, cybercrime has adopted reverse-proxy architectures built with frameworks like Evilginx2, Muraena and Modlishka.
Reverse-proxy architecture: how the attack actually works
In an AiTM attack the attacker's server interposes itself dynamically between the victim and login.microsoftonline.com. There's no pre-rendered fake page — the proxy is acting as a transparent man-in-the-middle in real time.
- TLS termination and SNI: the attacker's proxy terminates the TLS connection with the victim's browser using a valid SSL certificate (usually Let's Encrypt, on a typo-squatted domain like login.micros0ft-security.com).
- Transparent proxying: simultaneously, the proxy opens a legitimate connection to Microsoft. It acts as a perfect man-in-the-middle, rewriting links on the fly (modifying DOM and HTTP headers) so the victim interacts with the real Microsoft server through the attacker's infrastructure.
Hard2bit tip: if you want to evaluate whether your current infrastructure is vulnerable to reverse-proxy tactics, consider an advanced cybersecurity audit that simulates these vectors in a controlled environment.
Anatomy of token theft (Pass-the-Cookie)
The attacker's real target is not the password — it's the trust artefact Microsoft issues after a successful authentication: the session cookie.
JWT, ESTSAUTH and the difference with PRT
When the user enters their password and approves the MFA prompt on their phone, Entra ID issues a series of tokens based on JSON Web Tokens (JWT).
On managed devices, Windows uses a Primary Refresh Token (PRT), which is strongly hardware-bound to the device's TPM via cryptography. But at the web-browser layer, the session is maintained through standard cookies — primarily ESTSAUTH and ESTSAUTHPERSISTENT.
As these cookies pass through the attacker's reverse proxy in cleartext (inside the TLS terminated by the attacker), they are intercepted before reaching the victim.
# Simplified traffic capture on the attacker's server:
HTTP/1.1 200 OK
Set-Cookie: ESTSAUTH=0.AT8A_...[JWT_Payload_Truncated]...; domain=.login.microsoftonline.com; secure; HttpOnly
Once the attacker exports this cookie and injects it into their own browser, they inherit the user's identity and MFA state. From Entra ID's perspective the session has already been validated, so it grants immediate access to SharePoint, Exchange Online or Teams without prompting again.
Post-exploitation: persistence and evasion in Entra ID
Once inside, the clock is ticking. Attackers know the ESTSAUTH cookie has a limited lifetime, so their first move is to guarantee continuous access.
Abusing the Microsoft Graph API and mailbox manipulation
The attacker typically accesses Outlook on the Web (OWA) or uses scripts that interact directly with the Microsoft Graph API to:
- Data exfiltration: rapid keyword search across the mailbox (password, invoice, IBAN, confidential).
- Hiding rules: creating inbox rules to move any security alert email or customer reply to Deleted Items or RSS Feeds, blinding the victim.
- Registration of a new MFA device: adding an attacker-controlled device at mysignins.microsoft.com, allowing future authentication even if the password is changed or the cookie expires.
Forensic detection: tracking AiTM in Microsoft Entra ID sign-in logs
Detecting an AiTM attack requires sharpening monitoring of Microsoft Entra ID sign-in logs. Don't look for failed logins — the danger is in successful logins with anomalous context.
If you use Microsoft Sentinel or another SIEM, search for these patterns using KQL (Kusto Query Language):
- SessionId analysis: look for the same SessionId that jumps suddenly from one IP address (the victim's) to a different IP or a different ASN (the attacker injecting the cookie) within a short time window.
- User-Agent mismatches: abrupt browser changes within the same authenticated session.
- Account update events: monitor audit events like
Update userorAdd registered security infoimmediately after a sign-in from an unusual IP.
// Basic KQL example to detect IP changes within the same session
SigninLogs
| where ResultType == 0
| summarize IPCount = dcount(IPAddress), make_set(IPAddress) by SessionId, UserPrincipalName
| where IPCount > 1
Strategic mitigation: real defences against AiTM
The traditional approach no longer works. To protect your Microsoft 365 tenant you have to implement a solid Zero Trust architecture. From Hard2bit's Microsoft 365 security practice, we recommend two foundational pillars:
1. Conditional Access policies and Continuous Access Evaluation (CAE)
Context is everything. Configure strict policies in Entra ID to limit from where and with what access is allowed:
- Compliant devices: require that Office 365 access only happens from devices enrolled in Microsoft Intune and meeting corporate health policies. The attacker will have the cookie, but their laptop won't be in your Intune.
- Continuous Access Evaluation (CAE): enable CAE so token revocation happens near real-time if a critical change is detected (abrupt IP change, user disabled).
2. Phishing-resistant MFA (FIDO2 and Passkeys)
The definitive cryptographic solution. Replace SMS codes and app prompts with hardware security keys (FIDO2/YubiKeys) or Windows Hello for Business.
These standards use Channel Binding. The cryptographic signature of the authentication is bound to the real domain name (login.microsoftonline.com). If the victim is on the attacker's proxy (micros0ft-security.com), the cryptographic challenge fails at the protocol level — there is no possible way for the proxy to relay it. For more context on this control class, our passkey glossary entry explains the underlying mechanism.
Your next step in security
False sense of security is the biggest enemy of any organisation. Account takeover in Microsoft 365 via AiTM and token theft is a daily, silent, highly effective threat. Solving it doesn't require magic — it requires a defence-in-depth architecture: phishing-resistant authentication, strict context-aware access, fine-grained monitoring and a clear incident response plan when something does happen.
If you're not sure whether your current Entra ID configuration would resist an Evilginx2 attack, or if you suspect you may have suffered a silent breach, don't wait for the damage to become irreversible.
Talk to a Hard2bit expert today. We'll analyse the security posture of your tenant, tune your Conditional Access policies and harden your corporate identity against next-generation threats.
_Disclaimer: The threats and detections described in this article must be assessed in the context of each organisation's stack and configuration. KQL queries shown are simplified examples for illustration — production detection requires tuning, baselining and correlation across multiple sources. This article is informational and does not replace a formal compliance assessment or a hands-on technical audit._