Bypassing Multi-Factor Authentication: Reverse-Proxy AiTM Attacks and Session Cookie Theft in Enterprise Okta and Entra ID

The Fallacy of Conventional Multi-Factor Authentication

For years, enterprise security awareness training has advised employees: "Look for the green padlock, check the URL, and enable MFA."

While MFA undeniably stops automated credential stuffing attacks, traditional second factors—including SMS one-time codes, email verifications, and authenticator app TOTP tokens—provide zero defense against modern Adversary-in-the-Middle (AiTM) phishing frameworks.

Tools like Evilginx, Modlishka, and Muraena have transformed credential harvesting into real-time session hijacking.

How Reverse-Proxy AiTM Attacks Work

Unlike legacy phishing pages that present a fake static HTML form, an AiTM proxy operates as an authentic transparent intermediary between the victim and the legitimate enterprise Identity Provider (IdP) like Okta or Microsoft Entra ID.

Victim Browser ───► Phishing Proxy Domain (login.evil-devwalls.com)
                          │
                          ▼ (Proxies requests in real-time)
                    Real Identity Provider (login.microsoftonline.com)

Execution Timeline:

1. The Lure: The employee receives a realistic notification requesting document review, pointing to login.evil-devwalls.com.
2. Real-Time Proxying: The Evilginx server fetches the actual Microsoft login page, including genuine branding, corporate logos, and conditional flow logic.
3. MFA Execution: The user inputs their real username, real password, and solves the real Authenticator app prompt or SMS code. The proxy forwards all responses to Microsoft instantaneously.
4. The Theft: Upon successful authentication, Microsoft issues the final HTTP Set-Cookie response containing the session authentication tokens (e.g. ESTSAUTH, ESTSAUTHPERSISTENT).
5. Session Hijacking: The proxy captures the session cookie and terminates the connection, immediately redirecting the victim to the real document so suspicion is never aroused.

The attacker imports the stolen session cookies into an unmodified browser and gains instant, fully authenticated access to the victim's email, OneDrive, and corporate portal without ever knowing their password or possessing their MFA device.

The Only Permanent Fix: FIDO2 / WebAuthn

To defeat AiTM phishing proxies, organizations must deploy phishing-resistant authentication:

• FIDO2 Hardware Keys (YubiKey)


• Windows Hello for Business


• Passkeys (WebAuthn)

FIDO2 protocols cryptographically bind the authentication assertion to the exact domain name displayed in the browser's address bar. When the browser talks to login.evil-devwalls.com, the cryptographic challenge signature is generated for evil-devwalls.com. When forwarded to Microsoft, Microsoft's servers reject the assertion because the origin domain does not match login.microsoftonline.com.

The attack fails silently and completely.