Adversary-in-the-Middle (AiTM) Reverse Proxy Mechanics

For over two decades, the security industry treated Multi-Factor Authentication (MFA) as the ultimate silver bullet against credential theft. However, the widespread adoption of Adversary-in-the-Middle (AiTM) reverse proxy frameworks—most notably Evilginx, Modlishka, and Muraena—has rendered traditional MFA protocols (SMS, voice calls, TOTP codes, and standard mobile push notifications) obsolete against motivated threat actors.

AiTM attacks do not attempt to crack, guess, or bypass the mathematical algorithms of MFA. Instead, they position a transparent, real-time HTTP reverse proxy between the target victim and the genuine Microsoft identity provider (login.microsoftonline.com). By proxying authentic authentication requests, the adversary allows the victim to legitimately satisfy all password and MFA challenges, and subsequently steals the resulting authenticated session cookies.

This guide details the architectural mechanics of AiTM reverse proxies, analyzes the interception pipeline, explains why conventional Conditional Access policies fail upon token replay, and establishes the cryptographic foundation of phishing-resistant authentication.

---

1. The Paradigm Shift: Credential Harvesting vs Session Hijacking

Traditional phishing cloned static HTML login pages, capturing the user’s plaintext password. When organizations enabled MFA, this model collapsed: the attacker captured a password but could not provide the second factor.

AiTM fundamentally alters the attack topology:

graph TD
    subgraph "Legacy Phishing (Defeated by MFA)"
        V1[Victim] -->|1. Plaintext Password| FAKE_SITE[Cloned Login Site]
        FAKE_SITE -->|2. Store Password| ATT_DB[(Attacker DB)]
        ATT_DB -.->|3. Attempt Login| MS_IDP[Genuine Microsoft IdP]
        MS_IDP -->|4. Prompt MFA Challenge| ATT_DB
        ATT_DB -.->|FAIL: Cannot satisfy MFA| BLOCKED[Access Denied]
    end

    subgraph "Modern AiTM Reverse Proxy (MFA Bypassed)"
        V2[Victim] <-->|1. HTTPS Session with Proxy Domain| PROXY[AiTM Reverse Proxy<br/>Evilginx / Muraena]
        PROXY <-->|2. Proxied HTTPS Session with Genuine IdP| MS_AUTH[login.microsoftonline.com]
        V2 -->|3. Submits Password & Satisfies MFA Push| MS_AUTH
        MS_AUTH -->|4. Issues Authenticated Session Cookies<br/>ESTSAUTH, ESTSAUTHPERSISTENT| PROXY
        PROXY -->|5. Session Cookies Hijacked| ATT_EXFIL[(Adversary Session Replay)]
        PROXY -->|6. Redirect to Genuine App| REAL_APP[portal.office.com]
    end

In the AiTM paradigm:

1. The victim interacts with the genuine Microsoft authentication service through an intermediary.
2. The user sees their authentic company branding, custom login banners, and real-time MFA prompts.
3. Every factor (passwords, SMS codes, Authenticator push notifications, and Number Matching) is evaluated and accepted by Microsoft’s genuine Security Token Service (STS).
4. The adversary extracts the session cookie minted at the end of the handshake.

---

2. Reverse Proxy Mechanics: Inside the Phishlet Pipeline

Modern AiTM frameworks operate via specialized configuration templates known as phishlets (in Evilginx). A phishlet defines the target hostnames, subdomains, credential regex patterns, and session cookie extraction triggers.

sequenceDiagram
    autonumber
    participant Victim as Victim Browser
    participant Proxy as AiTM Reverse Proxy (evil-login.net)
    participant Microsoft as Genuine Microsoft STS (login.microsoftonline.com)

    Victim->>Proxy: GET https://login.evil-login.net/login
    Note over Proxy: TLS Handshake (Valid Let's Encrypt Cert)<br/>Inspects Request, Replaces Host & SNI
    Proxy->>Microsoft: GET https://login.microsoftonline.com/
    Microsoft-->>Proxy: HTTP 200 OK + Real Login Page HTML/JS
    Note over Proxy: Stream Filter Active:<br/>Substitutes "login.microsoftonline.com"<br/>with "login.evil-login.net"
    Proxy-->>Victim: Proxied Login Page with Corporate Branding
    Victim->>Proxy: POST Credentials (Username & Password)
    Proxy->>Microsoft: POST Forwarded to Genuine STS
    Microsoft-->>Proxy: HTTP 200 (MFA Required: Authenticator Push)
    Proxy-->>Victim: Proxied MFA Push Challenge Screen
    Note over Victim: Victim approves MFA prompt on physical mobile phone
    Microsoft-->>Proxy: HTTP 302 Found<br/>Set-Cookie: ESTSAUTH=... #59; ESTSAUTHPERSISTENT=...
    Note over Proxy: TRIGGER MATCHED!<br/>Cookies intercepted and written to session store
    Proxy-->>Victim: Redirects victim to legitimate https://portal.office.com

2.1 Dynamic Domain Translation & Stream Rewriting

For the attack to succeed, the victim’s browser must never navigate away from the attacker’s proxy domain until authentication is complete. The proxy performs bidirectional real-time packet rewriting:

1. Request Rewriting (Inbound):
   • Host: login.evil-login.net $\rightarrow$ Host: login.microsoftonline.com
   • Referer: https://login.evil-login.net/... $\rightarrow$ Referer: https://login.microsoftonline.com/...
   • Origin: https://login.evil-login.net $\rightarrow$ Origin: https://login.microsoftonline.com
2. Response Rewriting (Outbound):
   • The proxy parses the HTML, CSS, JavaScript, and JSON bodies returned by Microsoft.
   • Every occurrence of login.microsoftonline.com, login.live.com, and aadcdn.msauth.net is dynamically substituted with the corresponding attacker-controlled subdomains (login.evil-login.net, aadcdn.evil-login.net).
   • CORS headers (Access-Control-Allow-Origin) are rewritten to prevent the browser from blocking cross-origin API calls.

---

3. Anatomy of Hijacked Microsoft Session Cookies

Microsoft Entra ID establishes and maintains authenticated web sessions using a specific set of HTTP-only, secure cookies issued by the domain login.microsoftonline.com:

Cookie Name	Scope & Lifespan	Forensic & Cryptographic Function
ESTSAUTH	Session (In-Memory)	Encrypted bearer session token proving primary authentication and MFA satisfaction. Sent with subsequent requests to acquire workload tokens.
ESTSAUTHPERSISTENT	Persistent (e.g., 90 days)	Issued when the user selects “Stay signed in?”. Allows the browser to acquire new ESTSAUTH tokens without re-prompting.
ESTSAUTHLIGHT	Session	Lightweight telemetry cookie tracking authentication progress across redirects.
SignInStateCookie	Ephemeral	Manages state machine transitions during multi-step authentication handshakes.

// Example: Intercepted Evilginx Session Export
{
  "id": 14,
  "phishlet": "o365",
  "username": "alice.dupont@target.com",
  "password": "Password123!",
  "tokens": {
    "login.microsoftonline.com": {
      "ESTSAUTH": {
        "Name": "ESTSAUTH",
        "Value": "0.AXEA9b3...[TRUNCATED_ENCRYPTED_JWT_PAYLOAD]...",
        "Path": "/",
        "Domain": "login.microsoftonline.com",
        "HttpOnly": true,
        "Secure": true
      },
      "ESTSAUTHPERSISTENT": {
        "Name": "ESTSAUTHPERSISTENT",
        "Value": "0.AXEA9b3...[TRUNCATED]...",
        "Path": "/",
        "Domain": "login.microsoftonline.com",
        "HttpOnly": true,
        "Secure": true
      }
    }
  },
  "session_id": "8f3b6a9c-2d1e-4b5a-9f8e-7c6b5a4d3e2f",
  "useragent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
  "remote_ip": "198.51.100.22",
  "landing_url": "https://login.evil-login.net/auth"
}

Once the adversary imports these cookies into a clean browser profile or an automated API tool (such as AADInternals or custom Python scripts), they are immediately authenticated as the victim.

---

4. Why Traditional Conditional Access Fails on Replay

A common misconception among security architects is that standard Conditional Access (CA) policies will block the adversary when the stolen session is replayed from a different IP address or country.

4.1 Evaluation at Sign-In vs Replay

graph TD
    subgraph "Step 1: Sign-In Evaluation (Passed)"
        V_REQ[Victim Requests Access via Proxy] --> CA_EVAL{Conditional Access Evaluation}
        CA_EVAL -->|Check: Require MFA| MFA_OK[MFA Satisfied by Victim]
        CA_EVAL -->|Check: Block Untrusted Countries| LOC_OK[Proxy located in allowed region]
        MFA_OK & LOC_OK --> STS_ISSUE[Microsoft STS Issues ESTSAUTH Cookie]
    end

    subgraph "Step 2: Token Replay (The Blind Spot)"
        ATT_REQ[Attacker Replays ESTSAUTH from Malicious IP] --> RESOURCE[Access SharePoint / Outlook Online]
        RESOURCE --> COOKIE_VAL{Is ESTSAUTH Valid & Unexpired?}
        COOKIE_VAL -->|Yes| GRANT_ACCESS[Access Granted without re-evaluating CA!]
        COOKIE_VAL -->|No / Expired| CA_RE_EVAL[Conditional Access Re-evaluated]
    end

1. Authentication State is Already Satisfied: The ESTSAUTH cookie encapsulates proof that MFA has already been satisfied. Workload endpoints (such as outlook.office.com or target.sharepoint.com) trust the cookie without forcing a new interactive sign-in challenge.
2. Absence of Device Binding: Standard web session cookies are not cryptographically bound to the underlying hardware (TPM) or TLS connection. The cookie can be moved to any machine on earth and presented via any browser.

Continuous Access Evaluation (CAE) Limitations

Continuous Access Evaluation (CAE) provides real-time revocation when a user’s password changes, account is disabled, or IP location shifts significantly. However, CAE is only supported on specific modern workloads (Exchange, SharePoint, Teams) and requires Strict IP Location Enforcement to terminate sessions when the egress IP changes.

---

5. Cryptographic Immunity: Why FIDO2 / Passkeys Neutralize AiTM

While SMS, TOTP, and mobile push notifications are completely vulnerable to AiTM, FIDO2 / WebAuthn / Passkeys and Certificate-Based Authentication (CBA) provide mathematical, unbypassable immunity against reverse proxies.

5.1 The WebAuthn Origin Binding Mechanism

The FIDO2 / WebAuthn protocol cryptographically binds the authentication assertion to the Fully Qualified Domain Name (FQDN) of the website currently loaded in the browser:

sequenceDiagram
    autonumber
    participant Browser as Client Browser (WebAuthn API)
    participant Proxy as AiTM Reverse Proxy (evil-login.net)
    participant Key as FIDO2 Security Key / Passkey (TPM)
    participant Microsoft as Genuine Microsoft STS (login.microsoftonline.com)

    Proxy->>Browser: Transmits WebAuthn Challenge (originally from Microsoft)
    Note over Browser: Browser inspects window.location.origin:<br/>Origin = "https://login.evil-login.net"
    Browser->>Key: navigator.credentials.get({ rpId: "login.microsoftonline.com", ... })
    Note over Key: Security Key compares requested rpId with Browser Origin.<br/>Key enforces origin match!
    Note over Key: Cryptographic Signature computed over:<br/>SHA256(ClientDataJSON: { "origin": "https://login.evil-login.net", "challenge": "..." })
    Key-->>Browser: Signed Assertion
    Browser->>Proxy: Returns WebAuthn Response
    Proxy->>Microsoft: Forwards Assertion to login.microsoftonline.com
    Note over Microsoft: Microsoft STS verifies signature:<br/>EXPECTED ORIGIN: "https://login.microsoftonline.com"<br/>RECEIVED ORIGIN: "https://login.evil-login.net"
    Microsoft-->>Proxy: HTTP 400 Bad Request: INVALID_ORIGIN_SIGNATURE
    Note over Proxy: ATTACK PERMANENTLY FAILS!

Why FIDO2 Cannot Be Proxied:

1. The browser’s native WebAuthn implementation constructs the ClientDataJSON structure, embedding the actual origin URL currently visible in the address bar (https://login.evil-login.net).
2. The user’s hardware authenticator signs this data structure using its private key.
3. When the proxy forwards the signed data to Microsoft’s STS, Microsoft checks if the signed origin matches https://login.microsoftonline.com.
4. Because the signature covers the attacker’s domain, Microsoft’s verification math fails, and the authentication request is rejected immediately.

---

6. Defensive Architecture: Defeating AiTM in Enterprise Environments

To eliminate or severely restrict the impact of AiTM attacks, organizations must deploy layered identity defenses:

graph TD
    DEF[AiTM Defensive Strategy] --> L1[Layer 1: Phishing-Resistant MFA<br/>FIDO2 Security Keys, Windows Hello for Business, Certificate-Based Auth]
    DEF --> L2[Layer 2: Conditional Access Authentication Strengths<br/>Enforce Phishing-Resistant credentials for all corporate cloud apps]
    DEF --> L3[Layer 3: Device Binding<br/>Require Hybrid Entra Joined or Intune Compliant Devices]
    DEF --> L4[Layer 4: Global Secure Access & Source IP Restoration<br/>Enforce Strict Enclave Egress via Microsoft Entra Internet Access]

1. Enforce Phishing-Resistant Authentication Strengths:
   • In Conditional Access, configure Authentication Strengths to mandate FIDO2 / Passkeys or Windows Hello for Business, blocking SMS and standard push notifications for sensitive roles (Administrators, Finance, C-Suite).
2. Require Compliant Devices:
   • Mandating Intune device compliance or Hybrid Entra ID join ensures that even if an attacker acquires an ESTSAUTH cookie, replay attempts from unmanaged attacker infrastructure will be blocked at the device boundary.
3. Global Secure Access (SSE) & Strict Location Enforcement:
   • Routing corporate traffic through Microsoft’s Security Service Edge (SSE) ensures IP continuity and enables instant CAE session termination upon unauthorized network egress.

---

7. Cross-Reference & Investigation Navigation

• Previous Fiche: 20. Microsoft 365 Phishing Vectors: QR, OAuth & Credential Theft
• Next Fiche: 22. Forensic Detection & Investigation of AiTM Attacks
• Related Guides:
  • 02. Microsoft Entra ID: The Identity Plane
  • 09. Entra ID Sign-in Logs Analysis
  • 12. Entra ID Protection & Risk Detection Forensics
  • 19. Microsoft 365 Account Compromise Kill Chain
  • 25. OAuth Device Code Flow Abuse & Token Hijacking