Attaque AiTM : Evilginx, Modlishka et bypass MFA complet 2026

Les attaques AiTM (Adversary-in-the-Middle) représentent l'une des évolutions les plus inquiétantes de la menace phishing en 2026. Contrairement au phishing classique qui vole des identifiants, l'AiTM va plus loin : il s'interpose comme un proxy applicatif entre la victime et le service légitime, intercepte la session authentifiée — y compris après validation du MFA — et rejoue le cookie volé pour accéder au compte sans jamais connaître le second facteur. Cette technique a bouleversé la posture de sécurité de milliers d'organisations qui croyaient être protégées par leur déploiement MFA. Microsoft MSTIC a documenté des campagnes AiTM ciblant plus de 10 000 organisations en 2023, principalement contre Microsoft 365. En 2024 et 2025, le groupe Storm-1167 et d'autres acteurs ont industrialisé ces attaques via des services MaaS (Malware-as-a-Service) comme EvilProxy. Ce guide technique couvre l'architecture AiTM de A à Z : les outils offensifs (Evilginx 3.x, Modlishka, Muraena), les cas réels documentés, et surtout les défenses efficaces — spoiler : seul FIDO2/passkeys protège complètement contre l'AiTM, pas la simple activation du MFA.

Architecture AiTM : différence fondamentale avec le MiTM classique

Le MiTM (Man-in-the-Middle) classique opère au niveau réseau ou TLS : l'attaquant intercepte le trafic chiffré en se positionnant entre le client et le serveur, souvent via ARP poisoning, DNS spoofing, ou un faux point d'accès Wi-Fi. Cette approche est de plus en plus difficile à réaliser contre des services modernes utilisant HSTS, certificate pinning, et TLS 1.3.

L'AiTM opère au niveau applicatif. L'attaquant déploie un proxy inverse (reverse proxy) qui relaie les requêtes HTTP/HTTPS entre la victime et le service légitime en temps réel. Du point de vue de la victime, tout semble normal : elle voit un site qui ressemble parfaitement au site légitime (même design, même certificat TLS valide pour le domaine phishing), peut entrer ses identifiants, recevoir et valider son second facteur MFA. Du côté du service légitime, la connexion semble provenir du proxy AiTM, qui collecte tous les cookies de session dès qu'ils sont émis par le service.

Le cookie de session est la clé de l'attaque. Une fois l'utilisateur authentifié (identifiants + MFA), le service émet un cookie de session valide pour une durée déterminée (souvent 14 à 30 jours pour "rester connecté"). Ce cookie permet d'accéder au compte sans re-authentification pendant toute sa durée de validité. L'attaquant AiTM intercepte ce cookie et peut l'importer dans son navigateur pour accéder directement au compte de la victime — sans connaître le mot de passe, sans avoir à déjouer le MFA.

Pourquoi le MFA classique (TOTP, SMS) ne résiste pas à l'AiTM

La confusion est fréquente : "j'ai activé le MFA, je suis protégé contre le phishing." Cette croyance est vraie contre le phishing classique (vol de credentials), mais fausse contre l'AiTM. La raison est simple : l'AiTM ne cherche pas à deviner ou voler le code TOTP — il laisse la victime l'entrer elle-même sur le proxy, qui le transmet en temps réel au service légitime. L'authentification MFA se déroule normalement. Ce qui est volé, c'est le résultat de cette authentification réussie : le cookie de session.

Les mécanismes MFA vulnérables à l'AiTM :

• SMS OTP : l'attaquant proxyfie simplement le code reçu par SMS
• TOTP (Google Authenticator, Authy) : l'attaquant proxyfie le code TOTP avec une fenêtre de 30 secondes — largement suffisant en temps réel
• Microsoft Authenticator push notification : la victime approuve la notification légitime générée par le service via le proxy
• Email OTP : même mécanisme de proxy en temps réel

Les mécanismes MFA résistants à l'AiTM sont ceux qui lient cryptographiquement l'authentification à l'origine (domaine + clé publique) : FIDO2/WebAuthn, passkeys, et Certificate-Based Authentication. Ces mécanismes sont détaillés dans la section Défenses.

Evilginx 3.x : installation, phishlets et configuration

Evilginx est le framework AiTM open source le plus utilisé, développé par Kuba Gretzky. La version 3.x introduit une architecture refactorisée et un système de phishlets en YAML plus flexible. Il est disponible sur GitHub (github.com/kgretzky/evilginx2).

Architecture d'Evilginx : le framework combine un serveur DNS autoritaire (pour pointer les sous-domaines phishing vers le serveur attaquant), un proxy HTTPS (qui relaie les requêtes vers le service cible), et un moteur de phishlets (règles YAML définissant comment intercepter les cookies de session pour chaque service cible).

Installation :

# Prérequis : Go 1.21+, domaine dédié avec NS pointant vers votre serveur
git clone https://github.com/kgretzky/evilginx2.git
cd evilginx2
go build -o evilginx main.go

# Lancement (nécessite root pour les ports 80, 443, 53)
sudo ./evilginx -p ./phishlets -t ./redirectors -developer

Configuration d'un phishlet Microsoft 365 :

# Dans le shell Evilginx
config domain phishing-legitime.com
config ipv4 1.2.3.4

phishlets hostname o365 login.phishing-legitime.com
phishlets enable o365

# Créer un lure (URL personnalisée envoyée à la victime)
lures create o365
lures get-url 0

Les phishlets définissent pour chaque service : les domaines à proxifier, les paramètres de requête à modifier (pour masquer le proxy), et les credsnaps (patterns pour extraire identifiants et cookies). Des centaines de phishlets existent en communauté pour Microsoft 365, Google Workspace, LinkedIn, Facebook, et d'autres services majeurs.

Les credsnaps capturés par Evilginx incluent le nom d'utilisateur, le mot de passe, et surtout les cookies de session (valeur, domaine, expiration). Ces cookies peuvent ensuite être importés dans un navigateur via des extensions comme EditThisCookie.

Note : Evilginx est un outil de test de pénétration légal dans un cadre d'autorisation contractuelle. Son utilisation sans autorisation constitue une infraction pénale.

Modlishka : le proxy générique alternatif

Modlishka est un reverse proxy AiTM open source développé par Piotr Duszyński. Contrairement à Evilginx qui nécessite des phishlets spécifiques à chaque service, Modlishka est un proxy générique capable de travailler avec n'importe quel service sans configuration préalable spécifique.

Avantages de Modlishka :

• Proxy générique sans phishlets à écrire — fonctionne sur tout service HTTP/HTTPS
• Modification des réponses HTTP à la volée via des règles personnalisables
• Interface de monitoring des sessions capturées

Inconvénients :

• Moins de fonctionnalités de gestion des campagnes que Evilginx
• Plus difficile à configurer pour des services avec des mécanismes anti-phishing avancés (CSRF tokens complexes, JavaScript dynamique)
• Maintenance moins active que Evilginx en 2025-2026

EvilProxy : le MaaS AiTM industrialisé

EvilProxy (aussi nommé Moloch) est un service commercial de Phishing-as-a-Service (PhaaS) apparu en 2022 et documenté par Resecurity. Contrairement aux outils open source, EvilProxy est vendu sur des forums cybercriminels sous forme d'abonnement (400$ pour 10 jours, selon les rapports de 2023). Il offre une interface web de gestion de campagnes clé en main, des centaines de templates préconfigurés, et une infrastructure dédiée pour contourner les protections anti-phishing des services email.

Les cas observés de 2024 à 2026 montrent EvilProxy utilisé massivement contre Microsoft 365 dans des campagnes BEC (Business Email Compromise). Une fois le cookie de session d'un directeur financier capturé, les attaquants accèdent à sa messagerie, identifient des virements en cours, et insèrent des instructions de changement de compte bancaire. Pour une analyse complète du BEC, consultez notre article sur la fraude email professionnelle et défense BEC.

Muraena : un autre outil AiTM open source

Muraena est un framework AiTM open source développé en Go, conçu pour la furtivité et la modularité. Son architecture sépare le composant proxy (Muraena) du composant de suivi des sessions (Necrobrowser). Necrobrowser permet d'automatiser des actions post-compromission dans les sessions volées — téléchargement d'emails, navigation dans SharePoint, exfiltration de fichiers — sans interaction manuelle de l'attaquant.

# Installation Muraena
git clone https://github.com/muraenateam/muraena.git
cd muraena
go build -o muraena ./cmd/muraena/

# Configuration dans config.toml
# Proxy target : login.microsoftonline.com
# Phishing domain : login.votre-domaine-phishing.com

Flux d'attaque AiTM complet contre Microsoft 365

Voici le flux d'attaque type documenté par Microsoft MSTIC pour les campagnes Storm-1167 :

1. Préparation : L'attaquant enregistre un domaine typosquat (ex: microsoftonline-auth.com), configure un certificat TLS Let's Encrypt valide, et déploie Evilginx avec le phishlet Microsoft 365. Le domaine et l'infrastructure passent inaperçus aux filtres de réputation DNS car ils sont frais.
2. Email phishing ciblé : La victime reçoit un email imitant une notification Microsoft légitime (partage de document OneDrive, alerte de sécurité) avec un lien vers l'URL Evilginx. L'email utilise des techniques d'usurpation de domaine (cousin domain, HTML brand impersonation).
3. Proxy en temps réel : La victime clique, arrive sur la fausse page de connexion Microsoft (visuellement identique). Elle entre son mot de passe → Evilginx le capture et le transmet au vrai login.microsoftonline.com. Microsoft répond avec le challenge MFA → Evilginx proxyfie la demande MFA vers la victime.
4. Validation MFA transparente : La victime valide son Authenticator push ou entre son code TOTP → Evilginx transmet en temps réel → Microsoft émet un cookie de session valide → Evilginx le capture.
5. Replay de session : L'attaquant importe le cookie de session capturé dans son navigateur via DevTools ou une extension. Il accède directement à la messagerie de la victime, aux fichiers SharePoint, aux équipes Teams — sans mot de passe, sans MFA.
6. Persistance et latéralisation : L'attaquant crée une application OAuth frauduleuse dans l'Azure AD tenant de la victime pour maintenir l'accès même si le cookie expire. Il effectue une reconnaissance dans les emails et accède aux données sensibles. Pour les techniques de persistance avancées, voir notre article sur les méthodologies de pentest interne.

Cas réels : campagnes AiTM documentées 2023-2026

Microsoft MSTIC a publié en juillet 2022 un rapport détaillé sur une campagne AiTM ciblant plus de 10 000 organisations, principalement en Amérique du Nord et en Europe. La campagne utilisait des lures d'authentification Office 365 et permettait, post-compromission, des attaques BEC avec interception de correspondances financières.

Storm-1167 (aussi nommé DEV-1167 dans certains rapports) est un acteur de menace financièrement motivé documenté par Microsoft qui a utilisé EvilProxy et des variantes d'Evilginx dans des campagnes massives contre des cadres dirigeants entre 2023 et 2025. Le groupe a affiné ses techniques pour contourner les systèmes de détection de phishing basés sur le sandboxing.

En France, l'ANSSI a documenté plusieurs incidents en 2024 liés à des compromissions de comptes Microsoft 365 via AiTM dans des secteurs critiques (collectivités locales, opérateurs d'importance vitale). La technique de replay de session post-MFA est désormais intégrée dans les TTPs (Tactics, Techniques, Procedures) des groupes cybercriminels les plus actifs.

Détection des attaques AiTM

Continuous Access Evaluation (CAE) est la technologie Microsoft qui réduit la fenêtre d'exploitation des cookies volés. CAE permet à Microsoft Entra ID d'envoyer des signaux en temps réel aux applications (Exchange Online, SharePoint, Teams) pour invalider des tokens immédiatement en cas d'anomalie — changement d'IP, revocation de token, désactivation de compte — sans attendre l'expiration naturelle du token. Activez CAE dans tous vos tenants Microsoft 365.

Anomalies de token lifetime : les tokens Microsoft 365 ont une durée de vie standard. Un token utilisé depuis une IP géographiquement incohérente avec les habitudes de connexion, ou présentant un User-Agent inhabituel, doit déclencher une alerte. Ces signaux sont disponibles dans les logs Azure AD Sign-in.

Géolocalisation et impossible travel : si un utilisateur s'authentifie depuis Paris à 14h00 et qu'une session active apparaît depuis Lagos à 14h05, c'est le signe classique d'un replay de session AiTM. Microsoft Entra ID Conditional Access et les règles de détection SIEM (Microsoft Sentinel, Splunk) incluent des règles d'impossible travel prêtes à l'emploi.

Détection des applications OAuth non autorisées : post-compromission, les attaquants créent souvent des applications OAuth dans l'Azure AD tenant. Surveillez la création d'applications OAuth avec des permissions élevées (Mail.ReadWrite, User.ReadAll) dans vos logs d'audit Azure AD.

Pour la création de règles de détection SIEM personnalisées sur ces patterns, consultez notre guide Sigma Rules : guide complet d'écriture et de détection.

Défenses efficaces contre l'AiTM

FIDO2 / Passkeys : la seule protection complète. FIDO2 (WebAuthn) lie cryptographiquement l'authentification à l'origine (domaine + clé publique du serveur). Lors de l'enregistrement, la clé est liée au domaine légitime (ex: login.microsoftonline.com). Lors de l'authentification, si le domaine ne correspond pas (car la victime est sur un proxy AiTM qui a un domaine différent), l'authentification FIDO2 échoue silencieusement. L'attaquant ne peut pas proxifier l'authentification FIDO2 car il ne contrôle pas le domaine légitime. Les passkeys (Apple, Google, Microsoft) utilisent FIDO2 et offrent la même protection avec une meilleure ergonomie.

Certificate-Based Authentication (CBA) offre une protection équivalente. L'authentification est basée sur un certificat client lié à l'identité de l'utilisateur, stocké sur une smartcard ou un TPM. Le proxy AiTM ne peut pas intercepter l'authentification par certificat de manière transparente.

Token Binding (plus difficile à déployer) lie cryptographiquement les tokens TLS aux connexions réseau. Un cookie volé ne peut pas être rejoué sur une connexion TLS différente. Cette technologie reste en déploiement limité en 2026.

Pour les organisations qui ne peuvent pas déployer FIDO2 immédiatement : activez CAE, configurez des règles Conditional Access basées sur la conformité des appareils (appareils managés uniquement), et déployez un XDR avec des règles de détection d'impossible travel et d'anomalies OAuth. Pour les techniques de contournement EDR complémentaires à surveiller, voir notre article sur le bypass EDR et techniques d'évasion.

CAASM + XDR pour la détection automatisée des replays de session

La détection des replays de session post-AiTM nécessite une corrélation de signaux qui dépasse ce que les SIEM classiques peuvent faire seuls. Le CAASM (Cyber Asset Attack Surface Management) permet de corréler les données d'identité (Azure AD, Okta) avec les données d'appareils (Intune, CrowdStrike) : si un token de session est utilisé depuis un appareil non répertorié dans l'inventaire CAASM de l'organisation, c'est un indicateur fort de replay.

Les plateformes XDR (Microsoft Defender XDR, CrowdStrike Falcon XDR, Palo Alto Cortex XDR) intègrent des détections AiTM spécifiques : corrélation des logs Entra ID avec les logs endpoints, détection des applications OAuth suspectes, et alertes sur les patterns de comportement post-compromission (bulk email access, SharePoint exfiltration). L'activation de ces règles de détection XDR est fortement recommandée dans les environnements Microsoft 365 exposés.

FAQ — Questions fréquentes sur les attaques AiTM

L'activation de l'authentification multi-facteurs protège-t-elle contre l'AiTM ?

Non, pas complètement. Le MFA classique (TOTP, SMS, push notification) ne protège pas contre l'AiTM car l'attaquant ne cherche pas à bypasser le MFA — il le laisse s'exécuter normalement via son proxy, puis vole le cookie de session résultant. En revanche, FIDO2/passkeys protège complètement car l'authentification est liée cryptographiquement au domaine légitime. La migration vers FIDO2 devrait être une priorité pour toute organisation utilisant Microsoft 365, Google Workspace, ou d'autres services cloud critiques. Microsoft recommande d'activer les politiques FIDO2 dans Entra ID dès 2025 pour les comptes à privilèges.

Comment détecter si notre organisation a déjà été victime d'une attaque AiTM ?

Les indicateurs de compromission incluent : des connexions OAuth depuis des applications inconnues dans les logs Azure AD, des accès massifs à des emails depuis des IP géographiquement incohérentes (vérifiable dans les logs Entra ID Sign-in), des règles de transfert d'emails créées dans Outlook sans action utilisateur, et des téléchargements bulk depuis SharePoint ou OneDrive. Microsoft Entra ID Identity Protection génère des alertes "Atypical travel" et "Anonymous IP address" qui sont des indicateurs forts de replay de session. Une investigation sur les 30 derniers jours de logs OAuth dans votre tenant peut révéler des compromissions passées. Pour une méthodologie complète d'investigation, voir notre article sur les techniques AiTM et réponse à incident.

Evilginx peut-il bypasser l'authentification FIDO2/passkeys ?

Non. C'est la propriété fondamentale et irréfutable de FIDO2 : la clé est liée au domaine origin (RP ID dans le standard WebAuthn). Lors de l'authentification, le browser vérifie que le domaine actuel correspond au domaine enregistré — et le proxy AiTM opère sur un domaine différent (le domaine phishing). La réponse d'authentification signée par la clé FIDO2 ne sera jamais valide sur le domaine légitime car elle contient le hash du domaine phishing. L'attaquant ne peut donc pas proxifier une authentification FIDO2 — il ne reçoit que l'échec d'authentification. C'est pourquoi Microsoft, Google et Apple poussent fortement vers les passkeys comme remplacement du MFA classique en 2025-2026.