Hameçonnage AiTM : quand la MFA ne suffit plus à protéger les sessions
Beaucoup d'organisations considèrent qu'une fois la MFA déployée, le hameçonnage des identifiants est réglé. Les kits « adversary-in-the-middle » ont rendu cette idée obsolète : ils laissent l'utilisateur réussir sa MFA, puis récupèrent la session qui en résulte. Nous retrouvons ce scénario à l'origine de nombreuses compromissions de messagerie.
Le principe : un proxy entre l'utilisateur et Microsoft
Un kit AiTM n'imite pas la page de connexion : il la relaie. L'utilisateur arrive sur un domaine contrôlé par l'attaquant, qui transmet chaque requête au vrai service Microsoft et renvoie chaque réponse à la victime. L'utilisateur voit la page habituelle, éventuellement à l'image de son organisation, saisit son mot de passe et valide sa MFA. Tout fonctionne normalement de son point de vue.
Mais le proxy, placé au milieu, capte au passage le mot de passe et surtout le cookie de session émis par Entra ID une fois l'authentification terminée. L'attaquant importe ce cookie dans son propre navigateur et se retrouve connecté, sans avoir à repasser la MFA. Des outils open source de ce type existent depuis des années, et des offres d'hameçonnage « en tant que service » les ont rendus accessibles à des attaquants peu qualifiés.
Pourquoi les MFA classiques échouent
Notification Authenticator, code à usage unique, SMS ou appel : toutes ces méthodes ont un point commun. L'utilisateur prouve qu'il possède un facteur, mais rien ne lie cette preuve au site sur lequel il se trouve réellement. La correspondance de nombres n'y change rien : la victime voit bien le nombre affiché par la page relayée et le saisit de bonne foi.
À retenir. La MFA classique protège contre la réutilisation d'un mot de passe volé, pas contre le vol d'une session authentifiée. Ce sont deux menaces différentes, qui appellent des parades différentes.
Ce qui se passe après la compromission
Les schémas que nous observons en investigation se ressemblent beaucoup :
- création de règles de boîte de réception qui déplacent ou suppriment les courriels contenant certains mots-clés (facture, paiement, virement) ;
- enregistrement d'une nouvelle méthode MFA par l'attaquant, pour se ménager un accès durable ;
- consultation des échanges financiers en vue d'une fraude au virement ;
- envoi de nouvelles campagnes d'hameçonnage depuis la boîte compromise, vers les contacts internes et externes.
Les signaux de détection
Plusieurs indices permettent de repérer une session volée, à condition de les surveiller :
- Détections d'Entra ID Protection : selon votre licence, des détections comme « jeton anormal », « propriétés de connexion inhabituelles » ou la détection dédiée aux attaques de type « attacker in the middle » signalent ce scénario. Vérifiez lesquelles sont disponibles dans votre locataire.
- Incohérences dans les journaux de connexion : une authentification réussie depuis une adresse IP, puis l'utilisation de la session quelques minutes plus tard depuis un hébergeur ou un pays différent.
- Activité post-connexion : nouvelles règles de boîte, nouvelle méthode d'authentification enregistrée, consentement à une application, le tout peu après la connexion suspecte.
- Signaux de messagerie : l'URL d'hameçonnage initiale, souvent visible dans les détections de Defender for Office 365 si vous en disposez.
Réponse à incident : ne pas se contenter du mot de passe
Réinitialiser le mot de passe ne suffit pas. Il faut aussi révoquer les sessions et jetons d'actualisation de l'utilisateur, supprimer les méthodes d'authentification ajoutées par l'attaquant, éliminer les règles de boîte malveillantes, vérifier les consentements d'applications et les redirections de messagerie, puis rechercher les autres destinataires du même courriel d'hameçonnage. L'évaluation continue de l'accès accélère la prise en compte de la révocation par les services compatibles.
La vraie parade : la MFA résistante au hameçonnage
Les clés FIDO2, les passkeys, Windows Hello Entreprise et l'authentification par certificat lient cryptographiquement la preuve d'authentification à l'origine du site. Sur le domaine de l'attaquant, l'authentificateur ne produira rien d'utilisable : l'attaque échoue avant même la création de la session.
En complément, l'accès conditionnel peut exiger un appareil conforme ou joint à Entra ID pour les ressources sensibles : le proxy de l'attaquant ne peut pas présenter la preuve d'appareil attendue. La démarche réaliste consiste à imposer d'abord ces méthodes aux administrateurs et aux populations les plus ciblées (direction, finance, RH), au moyen des forces d'authentification, puis à étendre progressivement.
Ce qu'un audit vérifie
- La part des utilisateurs, et en particulier des administrateurs, disposant d'une méthode résistante au hameçonnage.
- Les stratégies d'accès conditionnel exigeant une force d'authentification ou un appareil conforme pour les accès sensibles.
- L'activation et le traitement des détections de risque d'Entra ID Protection.
- La protection de l'enregistrement des méthodes MFA par une stratégie dédiée.
- Les alertes sur la création de règles de boîte et de transferts externes.
- L'existence d'une procédure de réponse incluant la révocation des sessions.