Kits de phishing AiTM (Adversary-in-the-Middle)

Comment fonctionne le phishing AiTM

Le phishing AiTM repose sur un principe ancien appliqué au web moderne : l’attaque par interposition. Au lieu de créer une fausse page de connexion statique qui collecte un mot de passe, l’attaquant met en place un proxy inversé qui relaie le trafic entre la victime et le serveur légitime en temps réel.

Le résultat : la victime interagit véritablement avec le site qu’elle croit consulter. Elle voit les bonnes couleurs, les bons logos, le bon comportement. Parce que c’est le vrai site. Le proxy ne fait que transiter les données — et en copier certaines au passage.

Le flux d’attaque étape par étape

1. L’appât : un email ou un message de phishing ciblé

L’attaque commence comme un phishing classique. La victime reçoit un email imitant une notification Microsoft 365 (“Document partagé”, “Activité suspecte détectée”, “Votre session a expiré”). Le lien pointe vers le serveur proxy de l’attaquant, souvent hébergé sur un domaine visuellement proche du domaine légitime (login-microsft365[.]com, auth-google[.]app).

2. Le proxy transparent

Quand la victime clique sur le lien, elle arrive sur le serveur proxy. Ce serveur contacte immédiatement le vrai serveur Microsoft 365 (ou Google, Okta, etc.) et lui demande la page de connexion. Il renvoie cette page à la victime, pixel pour pixel. L’utilisateur voit la vraie page, avec le vrai design, les vrais champs de formulaire.

3. La saisie des identifiants

La victime entre son adresse email et son mot de passe. Le proxy transmet ces informations au vrai serveur en temps réel. Le serveur les accepte et déclenche la demande de MFA.

4. La validation du MFA

Le serveur légitime envoie une notification push, demande un code TOTP ou un code SMS. La victime valide normalement — elle pense être sur le vrai site. Le proxy transmet la réponse MFA au serveur.

5. L’interception du cookie de session

Le serveur légitime valide l’authentification complète (mot de passe + MFA) et émet un cookie de session. Ce cookie est la clé d’accès au compte — il prouve que l’utilisateur s’est correctement authentifié. Le proxy intercepte ce cookie avant de le transmettre à la victime.

6. L’exploitation

L’attaquant injecte le cookie de session volé dans son propre navigateur. Il accède au compte de la victime sans avoir besoin du mot de passe ni du code MFA — le cookie suffit. Il peut lire les emails, exfiltrer des documents, créer des règles de transfert, et lancer du phishing interne depuis le compte compromis.

Tout se passe en quelques secondes. La victime, elle, est redirigée vers le vrai site et ne remarque rien d’anormal.

EvilProxy vs Evilginx : deux outils, deux modèles

Le phishing AiTM existe sous deux formes principales, avec des logiques très différentes.

Evilginx : l’outil open source

Evilginx est un framework open source créé initialement par le chercheur en sécurité Kuba Gretzky comme outil de test de pénétration. Basé sur le serveur web nginx, il fonctionne comme un proxy inversé configurable. L’opérateur doit disposer de compétences techniques : configurer un serveur, un nom de domaine, un certificat TLS, et écrire les “phishlets” (fichiers de configuration décrivant comment intercepter les sessions d’un service cible).

Profil de l’attaquant : opérateur technique, red team, pentester, ou groupe criminel sophistiqué.

EvilProxy : le Phishing-as-a-Service

EvilProxy est un service commercial vendu sur des forums cybercriminels. Il reprend les principes d’Evilginx mais les empaquette dans une interface graphique accessible. L’acheteur choisit sa cible (Microsoft 365, Google, Facebook, GitHub, Okta), paie un abonnement et reçoit un lien de phishing prêt à l’emploi. Aucune configuration serveur, aucun code, aucune compétence réseau requise.

Selon les observations de Proofpoint publiées en 2023, les tarifs d’EvilProxy tournent autour de 400 dollars par mois pour cibler Microsoft 365, et montent jusqu’à 1 000 dollars pour Google avec contournement du MFA avancé.

Profil de l’attaquant : n’importe qui avec un budget. C’est la démocratisation du phishing AiTM.

L’effet de levier du PhaaS

La différence entre Evilginx et EvilProxy illustre un problème plus large. Historiquement, les attaques AiTM nécessitaient des compétences pointues. Avec le modèle PhaaS, la barrière d’entrée a disparu. Un rapport de Microsoft Threat Intelligence d’août 2023 documente des campagnes massives utilisant EvilProxy pour compromettre plus de 10 000 organisations en quelques mois.

Pourquoi le MFA classique échoue face à l’AiTM

Le MFA fonctionne sur un principe : prouver son identité par au moins deux facteurs. Mais le phishing AiTM ne cherche pas à deviner le mot de passe ou le code MFA. Il laisse l’utilisateur s’authentifier normalement et vole le résultat de cette authentification — le cookie de session.

Ce que le proxy capture

Le proxy ne s’intéresse pas à chaque facteur individuellement. Il attend la fin du processus d’authentification complet. Ce qu’il vole, c’est le jeton de session : le petit fichier qui dit au serveur “cet utilisateur s’est correctement authentifié, il peut accéder à son compte pendant les X prochaines heures”.

C’est comme si quelqu’un passait tous les contrôles de sécurité d’un aéroport (identité, billet, scanner) et qu’un pickpocket lui volait la carte d’embarquement juste après le dernier contrôle. Les contrôles ont fonctionné — mais le bénéfice en a été détourné.

Les facteurs MFA vulnérables à l’AiTM

• Codes SMS : transmis par le proxy au vrai serveur en temps réel
• Applications TOTP (Google Authenticator, Microsoft Authenticator en mode code) : même logique, le code est relayé
• Notifications push : la victime approuve la notification qui confirme la connexion du proxy
• MFA fatigue via push : l’attaquant peut forcer des approbations répétées

Le seul facteur résistant : FIDO2 et les passkeys

Les clés FIDO2 (YubiKey, Google Titan) et les passkeys ont une propriété que les codes et les push n’ont pas : la liaison au domaine. La clé vérifie cryptographiquement que le domaine qui demande l’authentification est bien le domaine légitime (login.microsoftonline.com, par exemple). Si le domaine est celui du proxy (login-microsft365[.]com), la clé refuse de s’authentifier. Le proxy n’a rien à relayer.

C’est la seule méthode d’authentification qu’un proxy AiTM ne peut pas contourner.

Exemples concrets d’attaques AiTM

Campagne massive contre Microsoft 365 (2022-2023)

En juillet 2022, Microsoft a publié une analyse détaillée d’une campagne AiTM ciblant des organisations utilisant Microsoft 365. Les attaquants envoyaient des emails imitant des notifications de pièces jointes partagées. Les victimes atterrissaient sur un proxy qui capturait leurs cookies de session après validation du MFA. En moins de 5 minutes après la compromission, les attaquants créaient des règles de transfert email et lançaient des campagnes de fraude au président (BEC) depuis les comptes volés — ciblant les partenaires et clients de l’entreprise.

Campagne EvilProxy contre des dirigeants (2023)

Proofpoint a documenté en septembre 2023 une campagne ciblant spécifiquement des cadres dirigeants (C-level) dans des entreprises de toutes tailles. Entre mars et juin 2023, plus de 120 000 emails de phishing EvilProxy ont été envoyés à des organisations dans le monde entier. Les cibles privilégiées : directeurs financiers et directeurs généraux — des profils à haut accès dont la compromission donne accès aux données financières et aux processus de paiement.

Impact sur les entreprises françaises

La France n’est pas épargnée. L’ANSSI note dans son Panorama de la cybermenace 2023 une augmentation des compromissions de comptes cloud dans les organisations françaises, avec un recours croissant aux techniques de contournement du MFA. Les entreprises qui utilisent Microsoft 365 ou Google Workspace sans MFA résistant au phishing sont exposées.

Se protéger contre le phishing AiTM

1. Déployer le MFA résistant au phishing (FIDO2 / passkeys)

C’est la contre-mesure technique la plus directe. Les clés FIDO2 et les passkeys vérifient le domaine du site au niveau cryptographique. Un proxy ne peut pas usurper cette vérification.

Déploiement progressif recommandé :

• Phase 1 : équiper les comptes à privilèges (administrateurs, direction, finance)
• Phase 2 : déployer les passkeys pour l’ensemble des utilisateurs via Windows Hello for Business ou les passkeys iOS/Android
• Phase 3 : désactiver les méthodes d’authentification vulnérables (SMS, TOTP) comme facteurs principaux

Microsoft, Google et Okta supportent tous nativement les clés FIDO2 et les passkeys. Le coût d’une clé physique YubiKey est de 25 à 70 euros par utilisateur — un investissement ponctuel.

2. Configurer les politiques d’accès conditionnel

Les politiques d’accès conditionnel (Conditional Access dans Microsoft Entra ID, Context-Aware Access dans Google Workspace) permettent de bloquer les connexions suspectes même si le cookie de session est valide :

• Exiger un appareil géré (intégré à Intune ou au MDM de l’entreprise) pour accéder aux ressources
• Bloquer les connexions depuis des pays inhabituels ou des plages IP inconnues
• Exiger une ré-authentification pour les actions sensibles (accès aux données financières, modification des règles email, téléchargement en masse)
• Détecter les connexions impossibles : un utilisateur qui se connecte depuis Paris puis depuis Lagos 10 minutes plus tard déclenche une alerte

3. Réduire la durée de vie des jetons

Un cookie de session volé n’est exploitable que tant qu’il est valide. Réduire la durée de vie des tokens limite la fenêtre d’exploitation :

• Session tokens : configurer une durée maximale de 1 à 4 heures (au lieu de 24-72 heures par défaut)
• Continuous Access Evaluation (CAE) : activer cette fonctionnalité dans Microsoft Entra ID pour révoquer les sessions en quasi-temps réel quand un risque est détecté
• Sign-in frequency : forcer une réauthentification toutes les X heures, même pour les sessions actives

4. Former et tester les équipes

Le phishing AiTM commence par un email. Si l’utilisateur ne clique pas sur le lien, le proxy n’est jamais contacté.

La sensibilisation doit inclure :

• La vérification systématique de l’URL avant de saisir des identifiants (le domaine du proxy est toujours différent du domaine légitime)
• Des simulations de phishing régulières incluant des scénarios AiTM (notification de document partagé, alerte de sécurité, expiration de session)
• Le réflexe de signalement : un email suspect reporté en 30 secondes vaut mieux qu’un clic en 3 secondes

5. Surveiller les signaux de compromission

Même avec des protections en place, la détection reste nécessaire :

• Alertes sur les nouvelles règles de transfert email (premier geste des attaquants après une compromission)
• Alertes sur les connexions depuis de nouveaux appareils ou de nouvelles localisations
• Analyse des journaux d’authentification : connexions multiples depuis des IP géographiquement impossibles, changements rapides d’User-Agent
• Intégration avec un SIEM ou un XDR pour corréler les signaux

L’avenir du phishing AiTM

Le phishing AiTM n’est pas une mode passagère. C’est une réponse logique à l’adoption croissante du MFA par les entreprises. Plus le MFA se généralise, plus les attaquants investissent dans les techniques pour le contourner.

Le Verizon DBIR 2024 confirme que les identifiants volés restent impliqués dans plus de 40 % des fuites de données. Les kits AiTM accélèrent cette tendance en rendant le vol de session accessible à des attaquants sans compétence technique.

La réponse est claire : le MFA résistant au phishing n’est plus une option, c’est un prérequis. Les passkeys et les clés FIDO2 sont les seules méthodes d’authentification qu’un proxy ne peut pas relayer. Les organisations qui n’ont pas encore planifié leur migration vers FIDO2 accumulent un risque qui ne fera que croître.

Vérifiez la configuration email de votre domaine avec notre vérificateur de sécurité email pour bloquer le spoofing — le point de départ des emails de phishing AiTM qui usurpent l’identité de vos partenaires.