By Jaspreet Singh,
Identity Security Researcher at f11.ca
Traditional Multi-Factor Authentication (MFA) is increasingly ineffective. In Lab EID-EXP-017 , we advanced beyond basic phishing to demonstrate an Adversary-in-the-Middle (AiTM) attack using a transparent reverse proxy.
The objective was to intercept the authentication handshake between a legitimate user and Microsoft Entra ID to capture the "Golden Ticket," which is the session token.
Lab Setup: Infrastructure Hygiene
For this experiment, we used Evilginx2 hosted on an external VPS. The effectiveness of an AiTM attack depends on the quality of the phishlet and the ability to bypass Microsoft’s detection telemetry.
- Primary Domain: login.f17.ca (Targeting login.microsoftonline.com)
- Lab ID: EID-EXP-017
- Target: Microsoft Entra ID Tenant (f11labs.onmicrosoft.com)
Technical Challenge: Redirect Logic
A common point of failure for security engineers setting up an AiTM lab is the native_client redirect. During EID-EXP-017, we observed that Microsoft often redirects the session to a www subdomain or a specific reprocess path, which disrupts the proxy connection.
Solution: In our YAML configuration, we strictly defined the proxy_hosts to ensure the session remained tied to our lure domain. By removing or commenting out the www hostname from the phishlet configuration, we prevented the browser from leaving our proxy, enabling seamless token capture.
Execution: Capturing the ESTSAUTH Cookie
The attack follows a four-stage execution path:
- Lure: The user visits our proxy domain, which mirrors the Microsoft login page in real time.
- Credential Relay: The user enters their email and password, which the proxy relays to Microsoft.
- MFA Interception: Microsoft sends a push notification to the user’s phone. The user approves it.
- Token Capture: Microsoft issues the session cookies, which pass through our proxy before reaching the user.
Captured Artifacts: In the terminal output for Lab EID-EXP-017, we successfully extracted:
- ESTSAUTH
- ESTSAUTHPERSISTENT
- SignInStateCookie
When these cookies are injected into a new browser instance, the attacker can bypass both the login screen and MFA.
Why "Default" Conditional Access Fails
During the experiment, we confirmed that Conditional Access (CA) was enabled. However, the policy was set to "Any MFA." Since the proxy is transparent, the CA engine registers a "Success" from the MFA provider and grants the token.
Engineering Solution: To mitigate EID-EXP-017, IT engineers should implement the following:
- Phishing-Resistant MFA: Enforce FIDO2 (YubiKeys) or Windows Hello for Business.
- Device-Bound Tokens: Use Token Binding to ensure a stolen cookie cannot be used on another machine.
- Strict Device Compliance: Allow Entra ID ID-joined Hybrid-Joined devices to access sensitive resources.
Conclusion
Lab EID-EXP-017 demonstrates that if your identity strategy relies solely on "something you have" (such as a phone push) without verifying "where you are" (device state) or "how you authenticated" (FIDO2), your environment remains vulnerable.
Download the YAML configuration snippets and full logs at f11.ca.
Watch the full packet capture and terminal walkthrough on my YouTube channel, Identity Identity Digest .
#CyberSecurity #EntraID #Evilginx #IdentitySecurity #ITBlogs #BlueTeam #RedTeam #MFA #SessionHijacking