Attaque AiTM et vol de jeton MFA

L'attaquant n'a pas à fabriquer un faux site : il installe un serveur web qui fait passer les paquets HTTP entre la victime et le service visé, dans les deux sens¹. La page contient deux sessions TLS distinctes, l'une avec la victime, l'autre avec le vrai site, ce qui lui permet d'extraire des requêtes les mots de passe et, plus important, les cookies de session¹.

Ce travail est automatisable avec des kits open source. Microsoft cite Evilginx2, Modlishka et Muraena¹. MITRE précise qu'Evilginx2 peut servir de relais AiTM entre un site légitime et une personne hameçonnée pour capturer les identifiants, les jetons d'authentification et les cookies de session⁵. Une fois le cookie obtenu, l'attaquant l'injecte dans son propre navigateur pour sauter l'authentification, même si la MFA de la cible est activée¹.

Au départ, un message. MITRE décrit le courriel avec lien piégé, qui sert notamment à éviter les défenses qui inspectent les pièces jointes⁶. Dans la campagne étudiée par Microsoft, le courriel portait une pièce jointe HTML et annonçait un message vocal¹. La page affichait une barre de téléchargement du message, mais la barre était écrite en dur dans le fichier : aucun fichier audio n'était téléchargé¹. La victime était ensuite redirigée vers une page qui préremplissait son adresse de courriel, ce qui renforçait la crédibilité du piège¹.

Puis vient la page de connexion, copie du portail Microsoft. Une fois les identifiants saisis et l'authentification réussie, la victime arrivait sur la vraie page office.com¹. Rien ne signale l'interception : en arrière-plan, l'attaquant avait déjà intercepté les identifiants et ouvert une session à son tour¹.

Voici une illustration neutralisée de la forme d'une telle adresse, pour montrer que seule l'adresse trahit le piège :

Illustration (adresse neutralisée, inventée pour l'exemple) :
hxxps://login[.]exemple-portail[.]invalid/[identifiant de la victime]
Page affichée : [copie du formulaire de connexion Microsoft]
Adresse attendue : [l'adresse officielle du service, saisie ou enregistrée par vous]

Un service web ouvre une session après l'authentification, pour ne pas redemander l'identité à chaque page. Cette session repose sur un cookie fourni par le service d'authentification, qui prouve au serveur que l'utilisateur est connecté¹. MITRE note que ces cookies restent souvent valides longtemps, même quand l'application n'est pas utilisée activement⁷. Un attaquant qui en possède un peut l'importer dans un navigateur qu'il contrôle et se connecter à l'application².

Dans la campagne de 2022, les cookies portaient une déclaration MFA : l'attaquant s'en servait donc pour accéder au compte malgré la politique MFA de l'organisation¹. MITRE cite aussi un cas où APT29 a utilisé des cookies volés pour accéder à des ressources cloud, et un cookie duo-sid forgé pour contourner la MFA d'un compte de messagerie, lors de la compromission SolarWinds².

Côté défense, la CISA classe les formes de MFA de la plus forte à la plus faible. Les codes à usage unique d'une application sont vulnérables à l'hameçonnage, tout comme les SMS et les appels vocaux³. Les notifications push avec saisie d'un nombre résistent au « push bombing » mais pas à l'hameçonnage³. Seule la FIDO/WebAuthn est, selon la CISA, l'authentification résistante à l'hameçonnage largement disponible³. Le NCSC britannique consacre un guide aux méthodes de MFA les plus solides⁸. Microsoft recommande aussi des politiques d'accès conditionnel, évaluées à chaque tentative d'utilisation d'un cookie volé (appareil conforme, adresse IP de confiance)¹.

Juillet 2022 : une campagne visant plus de 10 000 organisations

Le 12 juillet 2022, Microsoft publie l'analyse d'une campagne d'hameçonnage AiTM à grande échelle. Elle a volé des mots de passe, détourné des sessions et ignoré l'authentification même quand la MFA était activée. Selon les données de Microsoft, elle a tenté de cibler plus de 10 000 organisations depuis septembre 2021¹. Les attaquants imitaient la page d'authentification en ligne d'Office, avec le kit Evilginx2¹.

Après le vol : la fraude aux virements

Les attaquants se servaient ensuite des identifiants et des cookies volés pour accéder aux boîtes mail et lancer des fraudes aux virements (BEC) contre d'autres cibles¹. Microsoft a observé que cinq minutes pouvaient suffire entre le vol et le début de la fraude¹. Les jours suivants, l'attaquant consultait toutes les quelques heures les courriels et pièces jointes financiers, cherchait des échanges en cours, puis effaçait le courriel d'hameçonnage initial¹.

Il créait ensuite une règle de boîte de réception qui déplaçait vers « Archive », marqués comme lus, les messages venant du domaine de la cible de la fraude, pour que le titulaire ne voie rien¹. Il répondait enfin aux fils de discussion sur les paiements et les factures, puis supprimait ses réponses des éléments envoyés¹. Une fois, il a mené plusieurs tentatives en parallèle depuis la même boîte¹.