Sommaire
- Qu’est-ce que le phishing ?
- Qu’est-ce qu’une attaque de phishing de type « Man-in-the-middle » ?
- Comment contourner l’étape d’authentification forte ?
- Analysons plus en détail ce scénario
- Analyse fonctionnelle
- Assez de théories, exécutons l’attaque et analysons les journaux
- Analysons maintenant l’empreinte de l’attaque !
- Comment détectons-nous ce type d’attaque ?
- Mise en corrélation des événements
- Que pouvons-nous faire pour l’empêcher ?
Dans ce document, le laboratoire de détection des menaces SEKOIA.IO analyse une attaque de phishing de type « Man-in-the-middle » (MITM).
Qu’est-ce que le phishing ?
Le phishing ou hameçonnage est souvent utilisé par les cybercriminels pour s’emparer des identifiants (login, mot de passe) des victimes. Celles-ci ne se rendent parfois pas compte qu’elles ont été hameçonnées [1], [2].
Le but de cette analyse est d’exécuter l’attaque, de rechercher les traces laissées par les attaquants en analysant les logs et comprendre comment elle peut être détectée et atténuée.
Ici, nous nous concentrerons sur un scénario d’hameçonnage autour de l’environnement Microsoft365, partant du clic sur le courriel reçu à la détection de l’événement.
Qu’est-ce qu’une attaque de phishing de type « Man-in-the-middle » ?
Dans le phishing traditionnel, pour attirer les victimes et leur faire remplir le faux formulaire d’authentification, les attaquants avaient pour habitude de développer des modèles HTML ressemblant aux pages de connexion du service qu’ils voulaient imiter. Certains d’entre eux étaient suffisamment convaincants pour briser la vigilance et piéger la victime.
Cependant, cette technique est devenue moins efficace avec l’adoption de la méthode d’authentification à deux facteurs (2FA).
En effet, la méthode 2FA exige deux étapes de vérification pour une authentification réussie. Même si l’attaquant saisit une seule réponse 2FA, cela ne serait pas d’une grande aide. En effet, la deuxième étape de vérification ayant une courte durée de vie sera requise à chaque tentative de connexion.
Peu après que ce nouveau mécanisme d’authentification ait été largement mis en place, de nouvelles techniques permettant de contourner la 2FA sont apparues. Certaines d’entre elles utilisent une attaque de type « Man in the middle » (MITM).
Dans ce scénario, trois acteurs sont impliqués : la victime, le service usurpé et l’agresseur. La victime communique avec le service (par exemple, une boîte aux lettres Google et un compte Microsoft365), sans savoir qu’un tiers – en position Man in the middle – intercepte la communication entre les deux.
Comment contourner l’étape d’authentification forte ?
Une fois qu’un utilisateur est authentifié, un cookie de session contenant un jeton de session est créé. Celui-ci maintient l’état de la session entre le client et le serveur. Ainsi l’utilisateur reste connecté et n’est pas invité à fournir les informations d’identification à chaque fois qu’une nouvelle page est rechargée.
Ainsi, l’élément clé d’une attaque réussie repose sur l’interception du jeton de session de ce navigateur en lançant une attaque MITM. Cette technique est communément appelée « Pass-the-Cookie ».
Analysons plus en détail ce scénario
Pour obtenir plus d’informations sur l’attaque, il n’y a rien de mieux que de l’exécuter et d’analyser ce qui se passe vraiment en arrière-plan.
La campagne de phishing visera une victime d’une organisation utilisant Microsoft365 pour récolter des informations d’identification et accéder à des données confidentielles.
Comme nous ne sommes plus surpris de voir que les attaquants sont friands d’outils de sécurité offensifs (pour plus d’informations, veuillez vous référer à cet article), nous avons choisi de travailler avec l’un d’entre eux.
Certains d’entre eux utilisant le MITM sont plus ou moins efficaces et sont déjà disponibles sur GitHub, comme Modlishka ou Evilginx2.
Après analyse, Evilginx2 semble être bien plus puissant que Modlishka.
Cet outil, entièrement écrit en langage Golang, intègre ses propres serveurs HTTP et DNS et vous permet de mettre en place une page de phishing en travaillant comme un proxy inverse. Il prend ainsi la requête de la victime et l’envoie au service du site web d’origine, puis intercepte la réponse du service du site web et la renvoie à la victime.
Ainsi, Evilginx2 capture les données transmises entre la victime et le service, y compris les jetons d’authentification des cookies de session. Les cookies de session capturés peuvent ensuite être importés dans un navigateur, donnant un accès complet au compte de la victime, quel que soit l’endroit où se trouve l’attaquant.
Analyse fonctionnelle
Puisque nous nous concentrons sur une attaque utilisant Evilginx2, voyons ses principales caractéristiques techniques qui peuvent nous aider à la détecter.
Notez que cette analyse n’est pas un tutoriel pour Evilginx2, puisque beaucoup d’entre eux sont disponibles sur Internet. Nous nous concentrerons uniquement sur les informations qui pourraient être utiles à la détection.
Evilginx2 nécessite d’abord un nom de domaine, ce domaine sera affiché sur l’url du navigateur lorsque la victime cliquera sur le lien.
Par conséquent, les attaquants utilisent des noms de domaine voisins pour attirer efficacement la victime.
Evilginx2 nécessite également un serveur externe où l’installation sera hébergée et où le proxy va s’exécuter. Pour cela, le serveur doit être à l’écoute sur les ports TCP 80 et TCP 443.
Ce qui fait d’Evilginx2 un outil très efficace, ce sont ses fichiers de configuration appelés « phishlets », des jeux de règles en texte clair écrits au format YAML.
Ces fichiers désignent les sous-domaines nécessaires au proxy pour chaque site, les informations d’identification et les cookies à capturer, la page vers laquelle vous souhaitez rediriger la victime, etc.
Chaque utilisateur d’Evilginx2 peut implémenter ses propres phishlets personnalisés. Il existe déjà un large panel de phishlets disponibles sur le dépôt GitHub d’Evilginx2 permettant d’attirer efficacement les victimes pour qu’elles se connectent à Gmail, LinkedIn, Microsoft365, GitHub, Amazon, Outlook, Protonmail, Twitter, etc. et capturent des informations d’identification.
Assez de théories, exécutons l’attaque et analysons les journaux
Nous avons mis en place le phishlet pour Microsoft365 en suivant le tutoriel original, cette étape a généré deux URL comme suit :
- « login.O365.monnomdedomaine.com »
- « www.O365.mydomainname.com »
Nous avons donc dû mettre à jour les enregistrements DNS externes pour que tout le trafic sur ces URL soit dirigé vers notre serveur de phishing, quel que soit le sous-domaine.
Nous avons également configuré le domaine avec les enregistrements A et les serveurs de noms pertinents. Ensuite, nous avons obtenu un certificat SSL pour le domaine de phishing et ses sous-domaines, Evilginx2 pouvant créer des certificats signés en utilisant le client de Let’s Encrypt.
Nous avons généré ici l’URL leurre à envoyer dans le courriel de phishing. La victime s’est connectée à une page ressemblant à la page de connexion de Microsoft365 grâce au proxy inverse.
Du côté des victimes, on peut s’attendre à ce qu’un courriel persuasif les amenant à cliquer sur l’URL de leurre les incite à faire confiance au site web. Ils devraient renseigner leurs identifiants puisque tout est mis en place pour les convaincre qu’il est légitime.
En effet avec la présence d’un certificat SSL et le fait que la victime se retrouve sur une page présentant le vrai contenu de la page de connexion Microsoft365 comme le montre la figure ci-dessous, l’attaquant brise la barrière de vigilance de la victime.
Dans cette étape, la seule façon pour la victime de savoir que quelque chose ne va pas est de remarquer que le nom de domaine affiché dans le navigateur n’est pas le vrai nom de domaine Microsoft365.
Comme vous pouvez le constater, avec ce niveau la réplication de la page d’origine, même des utilisateurs expérimentés pourraient tomber dans le piège. Une fois les informations d’identification et le deuxième facteur remplis, nous pouvons rediriger les victimes vers le vrai site web Microsoft365 afin que quoi que ce soit ne déclenche leurs soupçons.
Maintenant, du point de vue de l’agresseur, le mot de passe et l’e-mail de la victime sont affichés sur le serveur.
Nous avons ensuite recherché les cookies de session. Nous avons pu copier le jeton et le coller dans le navigateur afin de nous connecter avec succès au compte de la victime.
Analysons maintenant l’empreinte de l’attaque !
Pour une protection avancée contre les menaces, il est recommandé d’intégrer les journaux d’activité Microsoft365 et Azure AD dans une solution SIEM.
En fonction des services que votre organisation utilise, vous pouvez choisir d’exporter différents types de journaux tels que Audit.SharePoint, Audit.AzureActiveDirectory, Audit.Exchange, etc.
La liste complète est documentée sur le site internet de Microsoft.
Vous trouverez ci-dessous un exemple de journaux d’événements et de champs que nous avons choisi d’afficher sur notre SIEM SEKOIA.IO pour étudier ce cas précis.
Dans cette analyse, nous avons choisi de ne pas être exhaustifs, mais plutôt d’esquisser deux types de détection qui peuvent être mises en œuvre spécifiquement pour ce scénario.
Comment détectons-nous ce type d’attaque ?
La première approche qui peut être utilisée pour détecter cette menace est de détecter l’outil lui-même : Evilginx2.
Nous avons développé des traqueurs pour tous les outils fréquemment utilisés par les attaquants, qu’il s’agisse de cybercriminels ou d’acteurs de la menace de type APT, tels que Cobalt Strike, Metasploit et Empire.
Cette approche nous permet d’identifier les serveurs de commandement et de contrôle (C2) malveillants à partir de l’observation de caractéristiques spécifiques liées à ces outils.
Une fois que nous savons quels modèles/caractéristiques nous recherchons, nous scannons l’Internet pour collecter les adresses IP des serveurs ou les noms de domaine correspondant aux modèles/parties recherchés.
Durant l’étude de Evilginx2 dans les paragraphes ci-dessus, nous avons remarqué que par défaut pour la configuration des phishlets Evilginx2 génère deux structures URL :
« login.O365.monnomdedomaine.com » et « www.O365.mydomainname.com ».
Une approche de recherche consisterait à cibler ces structures de noms de domaine spécifiques associées aux certificats Let’s Encrypt en utilisant Certificate Transparency.
La recherche de cette structure URL nous a permis de récupérer plus de 50 noms de domaine probablement enregistrés pour des campagnes de phishing O365, y compris notre propre serveur de phishing.
Nous nous concentrons ici sur l’environnement Microsoft365, mais cette stratégie peut être appliquée à tous les phishlets fournis par défaut dans Evilginx2.
Ces résultats alimentent ensuite la base de données Cyber Threat Intelligence de SEKOIA.IO de sorte que toute tentative de connexion effectuée à partir de ces serveurs déclenche une alerte comme indiqué ci-dessous.
Mise en corrélation des événements
La deuxième approche consisterait à analyser les journaux Microsoft365, en comparant le comportement légitime avec le comportement non légitime.
Dans ce scénario, les victimes ont reçu un e-mail contenant le lien de phishing.
Cela signifie que les victimes étaient déjà connectées à leur compte de messagerie, puis ont cliqué sur le lien.
De là, grâce au proxy, elles sont invitées à remplir leurs identifiants alors qu’elles sont déjà connectées.
Et toutes ces étapes se déroulent dans un délai très court.
Ce comportement peut être détecté grâce à une règle de corrélation permettant de suivre les événements comme suit :
([action.name= « MailItemsAccessed »] SUIVI PAR [action.name= « UserLoggedIn »] DANS LES 300 SECONDES)
Une approche plus globale pour détecter ce type de menace est basée sur la détection des « voyages impossibles ».
Une alerte est déclenchée lorsqu’un utilisateur est, dans une courte fenêtre de temps, connecté à partir de deux pays ou villes différents, comme nous pouvons le voir dans la capture d’écran ci-dessus, où notre serveur d’attaque est marqué « US » alors que l’utilisateur légitime a une IP marquée « FR ».
De multiples autres moyens de détecter cette menace sont possibles en fonction de l’IP (par exemple, l’IP attribuée à un service anonyme VPN/Tor), de la valeur UserAgent, de la validité du certificat SSL.
Tous ces types de journaux peuvent être corrélés pour assurer la meilleure détection possible et minimiser le taux de faux positifs.
Notez que nous avons affaire à une attaque de phishing. Dans ce type d’attaque, de nombreux utilisateurs peuvent être visés en même temps.
En fonction de la taille de votre entreprise, il peut être pertinent d’affiner ces règles avec un paramètre indiquant que le comportement recherché peut être vu par plus de n utilisateurs (par exemple >5 utilisateurs).
Ainsi, une détection en temps réel basée sur une détection proactive aux menaces combinée à la corrélation des journaux d’événements permet de détecter ce type d’attaque afin de limiter les dégâts et de réagir rapidement.
Que pouvons-nous faire pour l’empêcher ?
Le phishing est une technique fréquemment utilisée par de multiples acteurs de la menace tels que APT28, APT32, FIN8, Kimsuky, Turla et bien d’autres, car il s’est avéré être un moyen efficace de récolter des informations d’identification ou de télécharger des logiciels malveillants.
Pour les attaques basées sur Evilginx2 ainsi que pour d’autres types d’attaques de phishing, la formation et la sensibilisation de vos utilisateurs est le meilleur moyen d’éviter les dommages. Les utilisateurs peuvent être formés à reconnaître l’ingénierie sociale et à être vigilants en ce qui concerne le lien sur lequel ils cliquent.
Mais comme les utilisateurs peuvent être facilement piégés par des outils comme Evilginx2 et des méthodes d’évasions comme nous l’avons vu ensemble, la meilleure option est de s’appuyer sur une solution efficace de surveillance et de détection en temps réel basée sur une base de connaissance des cyber-menaces.
MITRE ATT&CK MAPPING:
- Phishing: Spearphishing Link (T1566.002)
- Steal Application Access Token (T1528)
- Man-in-the-Middle (T1557)
- Two-Factor Authentication Interception (T1111)
À lire aussi sur le blog :
Échangez avec l’équipe
Vous souhaitez en savoir plus sur nos solutions de protection ? Vous voulez découvrir nos produits de XDR et de CTI ? Vous avez un projet de cybersécurité dans votre organisation ? Prenez rendez-vous et rencontrons-nous !
