Mécanismes du reverse proxy adversary-in-the-middle (AiTM)

Pendant plus de deux décennies, l’industrie de la cybersécurité a considéré l’authentification multi-facteurs (MFA) comme le rempart absolu contre le vol d’identifiants. Cependant, l’avènement et l’industrialisation des frameworks de reverse proxy Adversary-in-the-Middle (AiTM) — au premier rang desquels Evilginx, Modlishka et Muraena — ont rendu caducs les mécanismes traditionnels de MFA (SMS, appels vocaux, codes TOTP et notifications push mobiles classiques) face à des attaquants déterminés.

Les attaques AiTM ne cherchent pas à casser, deviner ou contourner les algorithmes du MFA. Elles positionnent un proxy inverse HTTP transparent et en temps réel entre la victime ciblée et le véritable fournisseur d’identité Microsoft (login.microsoftonline.com). En relayant fidèlement le trafic d’authentification, l’attaquant laisse la victime s’authentifier légitimement avec son mot de passe et valider son second facteur, puis intercepte et dérobe les cookies de session authentifiée émis en retour.

Ce guide détaille l’architecture des reverse proxys AiTM, analyse leur pipeline d’interception, explique l’échec des règles d’Accès Conditionnel classiques face au rejeu de jetons, et expose les fondements cryptographiques des méthodes de MFA résistantes au phishing.

---

1. La rupture de paradigme : récolte d’identifiants vs vol de session

Le phishing traditionnel clonait des formulaires d’authentification statiques en HTML, capturant le mot de passe en clair de la victime. L’activation du MFA a neutralisé ce modèle : l’attaquant disposait d’un mot de passe mais ne pouvait pas satisfaire le second facteur.

L’approche AiTM bouleverse la topologie d’attaque :

graph TD
    subgraph "Phishing Traditionnel (Neutralisé par le MFA)"
        V1[Victime] -->|1. Mot de passe en clair| FAKE_SITE[Site Cloné Statique]
        FAKE_SITE -->|2. Enregistrement mot de passe| ATT_DB[(Base Attaquant)]
        ATT_DB -.->|3. Tentative de connexion| MS_IDP[Véritable IdP Microsoft]
        MS_IDP -->|4. Défi MFA émis| ATT_DB
        ATT_DB -.->|ÉCHEC : Impossible de valider le MFA| BLOCKED[Accès Rejeté]
    end

    subgraph "Proxy Inverse AiTM Moderne (MFA Contourné)"
        V2[Victime] <-->|1. Session HTTPS sur domaine leurre| PROXY[Proxy Inverse AiTM<br/>Evilginx / Muraena]
        PROXY <-->|2. Session HTTPS relayée vers l'IdP légitime| MS_AUTH[login.microsoftonline.com]
        V2 -->|3. Saisit mot de passe & valide le challenge MFA| MS_AUTH
        MS_AUTH -->|4. Émission des cookies de session authentifiée<br/>ESTSAUTH, ESTSAUTHPERSISTENT| PROXY
        PROXY -->|5. Capture et extraction des cookies| ATT_EXFIL[(Rejeu de Session Attaquant)]
        PROXY -->|6. Redirection vers l'application réelle| REAL_APP[portal.office.com]
    end

Dans le modèle AiTM :

1. La victime interagit avec le véritable service d’authentification Microsoft via un relais invisible.
2. L’interface affiche la charte graphique authentique de l’entreprise, les bannières personnalisées et les invites MFA réelles.
3. Tous les facteurs (mots de passe, SMS, notifications push Authenticator et Number Matching) sont validés par le Security Token Service (STS) de Microsoft.
4. L’attaquant intercepte le cookie de session forgé à l’issue de cette négociation.

---

2. Fonctionnement du reverse proxy : le pipeline des phishlets

Les outils AiTM modernes comme Evilginx fonctionnent à l’aide de modèles de configuration appelés phishlets. Un phishlet définit les noms d’hôtes cibles, les sous-domaines, les expressions régulières de capture et les déclencheurs d’extraction des cookies de session.

sequenceDiagram
    autonumber
    participant Victim as Navigateur Victime
    participant Proxy as Proxy Inverse AiTM (evil-login.net)
    participant Microsoft as Véritable STS Microsoft (login.microsoftonline.com)

    Victim->>Proxy: GET https://login.evil-login.net/login
    Note over Proxy: Handshake TLS (Certificat Let's Encrypt valide)<br/>Inspection de la requête, réécriture de l'entête Host et SNI
    Proxy->>Microsoft: GET https://login.microsoftonline.com/
    Microsoft-->>Proxy: HTTP 200 OK + Page de login réelle (HTML/JS)
    Note over Proxy: Filtre de flux actif :<br/>Remplacement de "login.microsoftonline.com"<br/>par "login.evil-login.net"
    Proxy-->>Victim: Page d'authentification relayée avec charte de l'entreprise
    Victim->>Proxy: POST Identifiants (UPN & Mot de passe)
    Proxy->>Microsoft: POST Recommandé vers le véritable STS
    Microsoft-->>Proxy: HTTP 200 (MFA Requis : Notification Authenticator)
    Proxy-->>Victim: Affichage de l'écran de challenge MFA officiel
    Note over Victim: La victime valide le challenge sur son smartphone
    Microsoft-->>Proxy: HTTP 302 Found<br/>Set-Cookie: ESTSAUTH=... #59; ESTSAUTHPERSISTENT=...
    Note over Proxy: DÉCLENCHEUR ATTEINT !<br/>Cookies interceptés et stockés dans la base d'attaque
    Proxy-->>Victim: Redirection de la victime vers https://portal.office.com légitime

2.1 traduction dynamique de noms de domaine et réécriture de flux

Pour que l’attaque aboutisse, le navigateur de la victime ne doit jamais quitter le domaine du proxy avant la fin de l’authentification. Le proxy applique une réécriture bidirectionnelle en continu :

1. Réécriture des requêtes (entrantes) :
   • 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. Réécriture des réponses (sortantes) :
   • Le proxy inspecte les flux HTML, CSS, JavaScript et JSON renvoyés par Microsoft.
   • Toute occurrence de login.microsoftonline.com, login.live.com et aadcdn.msauth.net est remplacée dynamiquement par les sous-domaines de l’attaquant (login.evil-login.net, aadcdn.evil-login.net).
   • Les entêtes CORS (Access-Control-Allow-Origin) sont modifiés pour empêcher le navigateur de bloquer les requêtes API asynchrones.

---

3. Anatomie des cookies de session Microsoft dérobés

Microsoft Entra ID gère les sessions web authentifiées via des cookies HTTP-only sécurisés émis sous le domaine login.microsoftonline.com :

Nom du Cookie	Portée & Durée de Vie	Fonction Cryptographique et Forensique
ESTSAUTH	Session (En mémoire)	Jeton de session porteur chiffré prouvant l’authentification primaire et la satisfaction du MFA. Présenté pour obtenir des jetons applicatifs.
ESTSAUTHPERSISTENT	Persistant (ex. 90 jours)	Émis lorsque l’utilisateur coche « Rester connecté ». Permet d’acquérir de nouveaux ESTSAUTH sans ressaisie d’identifiants.
ESTSAUTHLIGHT	Session	Cookie léger assurant la continuité de l’état de session au cours des redirections.
SignInStateCookie	Éphémère	Maintient la machine à états lors des handshakes d’authentification en plusieurs étapes.

// Exemple d'export de session capturée sous Evilginx
{
  "id": 14,
  "phishlet": "o365",
  "username": "alice.dupont@target.com",
  "password": "Password123!",
  "tokens": {
    "login.microsoftonline.com": {
      "ESTSAUTH": {
        "Name": "ESTSAUTH",
        "Value": "0.AXEA9b3...[PAYLOAD_JWT_CHIFFRE_TRONQUE]...",
        "Path": "/",
        "Domain": "login.microsoftonline.com",
        "HttpOnly": true,
        "Secure": true
      },
      "ESTSAUTHPERSISTENT": {
        "Name": "ESTSAUTHPERSISTENT",
        "Value": "0.AXEA9b3...[TRONQUE]...",
        "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"
}

Dès que l’attaquant importe ces cookies dans son navigateur ou dans un outil d’automatisation (comme AADInternals), il est immédiatement authentifié sous l’identité de la victime sans aucune sollicitation MFA.

---

4. Pourquoi l’accès conditionnel classique échoue au rejeu

Une incompréhension fréquente chez les administrateurs réside dans la conviction que l’Accès Conditionnel bloquera le pirate lors du rejeu de la session depuis une adresse IP ou un pays différent.

4.1 évaluation à la connexion vs rejeu post-authentification

graph TD
    subgraph "Étape 1 : Évaluation à la Connexion (Validée)"
        V_REQ[La Victime se Connecte via le Proxy] --> CA_EVAL{Évaluation Accès Conditionnel}
        CA_EVAL -->|Exigence MFA| MFA_OK[MFA Validé par la Victime]
        CA_EVAL -->|Contrôle Pays Autorisés| LOC_OK[Proxy situé dans une zone admise]
        MFA_OK & LOC_OK --> STS_ISSUE[Émission du Cookie ESTSAUTH par Microsoft]
    end

    subgraph "Étape 2 : Rejeu de Jeton (La Faille Temporelle)"
        ATT_REQ[L'Attaquant Rejoue ESTSAUTH depuis son IP] --> RESOURCE[Accès à SharePoint / Outlook Web]
        RESOURCE --> COOKIE_VAL{Le Cookie ESTSAUTH est-il Valide ?}
        COOKIE_VAL -->|Oui| GRANT_ACCESS[Accès Accordé sans Réévaluation de l'Accès Conditionnel !]
        COOKIE_VAL -->|Non / Expiré| CA_RE_EVAL[Réévaluation Complète des Règles CA]
    end

1. L’état d’authentification est déjà acquis : le cookie ESTSAUTH encapsule la preuve formelle que le mot de passe et le MFA ont été validés. Les services cibles (outlook.office.com, target.sharepoint.com) acceptent le cookie sans exiger une nouvelle authentification interactive.
2. Absence de liaison matérielle du cookie : les cookies de session web standards ne sont pas liés cryptographiquement au matériel physique (TPM) ou à la négociation TLS initiale. Ils peuvent être rejoués depuis n’importe quel terminal dans le monde.

Limites de continuous access evaluation (CAE)

L’évaluation continue des accès (CAE) révoque en quasi temps réel les jetons en cas de modification de mot de passe ou de désactivation de compte. Toutefois, pour révoquer une session lors d’un changement d’adresse IP d’egress, CAE impose l’activation stricte de la politique Strict IP Location Enforcement.

---

5. L’immunité cryptographique de FIDO2 / passkeys

Alors que les codes SMS, TOTP et notifications push s’avèrent inopérants face aux attaques AiTM, les standards FIDO2 / WebAuthn / Passkeys et l’authentification par certificat (CBA) apportent une immunité mathématique inviolable contre les proxys inverses.

5.1 le mécanisme de liaison d’origine (origin binding)

Le protocole FIDO2 / WebAuthn lie cryptographiquement l’assertion d’authentification au nom de domaine pleinement qualifié (FQDN) affiché dans la barre d’adresse du navigateur :

sequenceDiagram
    autonumber
    participant Browser as Navigateur (API WebAuthn)
    participant Proxy as Proxy Inverse AiTM (evil-login.net)
    participant Key as Clé FIDO2 / Passkey (TPM)
    participant Microsoft as Véritable STS Microsoft (login.microsoftonline.com)

    Proxy->>Browser: Transmet le challenge WebAuthn (provenant de Microsoft)
    Note over Browser: Le navigateur lit l'origine réelle de la fenêtre :<br/>Origin = "https://login.evil-login.net"
    Browser->>Key: navigator.credentials.get({ rpId: "login.microsoftonline.com", ... })
    Note over Key: La clé compare le rpId demandé et l'origine du navigateur.<br/>Calcul de la signature cryptographique sur :<br/>SHA256(ClientDataJSON: { "origin": "https://login.evil-login.net", ... })
    Key-->>Browser: Assertion Signée
    Browser->>Proxy: Envoi de la réponse WebAuthn
    Proxy->>Microsoft: Relais de l'assertion vers login.microsoftonline.com
    Note over Microsoft: Le STS vérifie la signature :<br/>ORIGINE ATTENDUE : "https://login.microsoftonline.com"<br/>ORIGINE REÇUE : "https://login.evil-login.net"
    Microsoft-->>Proxy: HTTP 400 Bad Request : INVALID_ORIGIN_SIGNATURE
    Note over Proxy: L'ATTAQUE ÉCHOUE DÉFINITIVEMENT !

Pourquoi FIDO2 ne peut pas être relayé :

1. Le navigateur construit la structure ClientDataJSON en y inscrivant l’URL réelle affichée dans la barre d’adresse (https://login.evil-login.net).
2. La clé matérielle signe ces données à l’aide de sa clé privée.
3. Lorsque le proxy transmet l’assertion signée à Microsoft, le serveur compare l’origine signée avec son propre domaine (https://login.microsoftonline.com).
4. L’origine signée étant celle du domaine d’attaque, la vérification cryptographique échoue instantanément et Microsoft rejette la connexion.

---

6. Architecture défensive : neutraliser les attaques AiTM

Pour endiguer les attaques AiTM, les organisations doivent mettre en œuvre une stratégie de défense en profondeur :

graph TD
    DEF[Stratégie Défensive Anti-AiTM] --> L1[Niveau 1 : MFA Résistant au Phishing<br/>Clés FIDO2, Windows Hello for Business, Certificats CBA]
    DEF --> L2[Niveau 2 : Forces d'Authentification dans l'Accès Conditionnel<br/>Imposer les clés résistantes pour toutes les applications cloud]
    DEF --> L3[Niveau 3 : Liaison Matérielle du Terminal<br/>Exiger un poste Hybride Entra ID ou conforme Intune]
    DEF --> L4[Niveau 4 : Global Secure Access & Restauration d'IP Source<br/>Filtrage réseau strict via Microsoft Entra Internet Access]

1. Imposer les forces d’authentification (authentication strengths) :
   • Configurer des règles d’Accès Conditionnel imposant l’authentification résistante au phishing (FIDO2, Windows Hello) pour les populations sensibles (administrateurs, finances, exécutifs).
2. Exiger des postes conformes (compliant devices) :
   • Imposer l’appartenance à Intune ou la jonction Hybride Entra ID. Même si un attaquant vole un cookie ESTSAUTH, il ne pourra pas le rejouer depuis sa propre machine sans certificat de conformité machine valide.
3. Global Secure access et contrôle des IP d’egress :
   • L’acheminement du trafic d’entreprise via l’infrastructure SSE Microsoft garantit la continuité d’IP et permet la révocation instantanée par CAE dès qu’une session émerge hors du réseau approuvé.

---

7. Maillage interne & navigation

• Fiche précédente : 20. Vecteurs de Phishing M365 : QR, OAuth & Vol d’Identifiants
• Fiche suivante : 22. Détection Forensique & Investigation des Attaques AiTM
• Fiches complémentaires :
  • 02. Microsoft Entra ID : le plan d’identité
  • 09. Analyse des logs de connexion entra ID
  • 12. Forensique entra ID protection & détection des risques
  • 19. Kill chain de compromission de compte M365
  • 25. Abus du device code flow OAuth & détournement de jetons