EvilGinx et le phishing adversary-in-the-middle, expliqué
L'authentification multifacteur devait rendre les mots de passe volés inutiles. Le phishing adversary-in-the-middle (AiTM) — popularisé par des frameworks open source comme EvilGinx — a discrètement brisé cette hypothèse en volant la session, et non le mot de passe. Comprendre son fonctionnement est la première étape pour s'en défendre.
Ce qu'est le phishing adversary-in-the-middle
Le phishing classique présente à la victime un clone statique d'une page de connexion et enregistre simplement ce qu'elle saisit. Il ne sait pas gérer un code à usage unique en temps réel, ni franchir un vrai défi MFA.
Le phishing AiTM lève cette limite en insérant un reverse proxy entre la victime et le site authentique. Le serveur de l'attaquant n'héberge pas une fausse page : il relaie la vraie.
Victime → login.micros0ft-verify.example (proxy attaquant) → login.microsoftonline.com
Chaque requête de la victime est transmise au service légitime, et chaque réponse renvoyée. La victime voit le vrai parcours de connexion — vraie identité visuelle, vrais messages d'erreur, vraies invites MFA — parce qu'elle dialogue effectivement avec le vrai service, mais à travers un relais qui lit tout au passage.
Pourquoi il déjoue OTP et push
L'idée clé : l'attaquant ne cherche pas à connaître votre mot de passe ni votre code. Il cherche à capturer ce que produit une connexion réussie : le cookie de session authentifié.
- La victime saisit identifiant et mot de passe → relayés au vrai site.
- Le vrai site émet un défi MFA → relayé à la victime.
- La victime valide le push ou saisit l'OTP → relayé au vrai site.
- Le vrai site valide tout et renvoie un jeton de session → le proxy le capture.
À cet instant, l'OTP a déjà rempli son rôle et n'a aucune valeur en rejeu. L'attaquant importe le cookie volé dans son propre navigateur et se retrouve connecté en tant que l'utilisateur — sans mot de passe, sans code, sans seconde invite. Voilà pourquoi les codes SMS, les applications TOTP et les validations push tombent tous face à un montage AiTM compétent : chacun est un secret partagé que l'humain peut être piégé à relayer en temps réel.
L'invite MFA validée par la victime était authentique. C'est précisément ce qui rend l'AiTM si efficace — rien ne semble anormal pour l'utilisateur, ni pour le fournisseur d'identité.
Pourquoi les défenses existantes peinent
- Le domaine est souvent tout neuf. Les domaines sosies fraîchement enregistrés n'ont aucun historique de réputation à signaler.
- Le TLS paraît légitime. Le proxy sert un certificat valide ; le cadenas est présent.
- Le contenu est réel. Le scan par signature ne trouve rien de falsifié, car la page est la vraie, relayée.
- Les fenêtres de détection sont courtes. Les kits emploient filtrage anti-analyse, liens à usage unique et géofiltrage : une URL active pour la victime renvoie une page inoffensive au SOC qui enquête.
Le vrai correctif : une MFA résistante au phishing
L'AiTM fonctionne parce que le second facteur transite par l'attaquant. Supprimez cette possibilité et l'attaque s'effondre. FIDO2 / WebAuthn et les passkeys lient cryptographiquement l'identifiant à l'origine web exacte pour laquelle il a été enregistré.
Identifiant enregistré pour : https://login.microsoftonline.com
Origine vue par le navigateur : https://login.micros0ft-verify.example
→ origine différente → l'authentificateur refuse de signer → échec de connexion
Il n'y a aucun code à relayer et aucun cookie à récolter, car l'authentification ne réussit jamais contre la mauvaise origine. C'est le navigateur qui l'impose — pas l'utilisateur. Des contrôles complémentaires renforcent le reste :
- Accès conditionnel liant les sessions à la conformité de l'appareil et aux réseaux gérés.
- Protection des jetons / évaluation continue de l'accès pour réduire la valeur d'un cookie volé.
- Détection rapide des domaines sosies récents via la surveillance des logs de transparence des certificats.
L'objectif : une MFA résistante au phishing exigée, et non simplement disponible — tout repli hameçonnable est un chemin vers lequel les attaquants dirigeront les utilisateurs.
Comment GottaPhish aide
Les attaques AiTM déjouent la MFA par OTP et par push en relayant la session en temps réel, et aucun proxy ni filtre à lui seul ne comble cette faille de façon fiable. GottaPhish et son équipe d'experts reproduisent les scénarios adversary-in-the-middle automatiquement et en toute sécurité au sein de simulations autorisées — aucune infrastructure d'attaque à monter, héberger ou démanteler pour vos équipes. Nous démontrons, avec un audit complet, comment les MFA par OTP et push tombent face à un vrai proxy tandis que les identifiants résistants au phishing tiennent, vous fournissant des données d'exposition mesurables par utilisateur, service et rôle ; nos experts vous aident à concevoir les scénarios, configurer les campagnes et interpréter les résultats. Cette preuve rend concret l'argumentaire pour FIDO2/passkeys, et notre reporting suit l'adoption aux côtés de vos taux de clic et de signalement, afin de prouver que l'écart hameçonnable se referme réellement — pas seulement qu'une politique existe sur le papier.