Détection du phishing AiTM : le rejeu de jeton dans Entra ID
Comment le phishing AiTM vole des sessions Microsoft 365 malgré la MFA, et comment repérer le rejeu de jeton dans les connexions Entra ID et l'UAL.
En bref. Dans l'hameçonnage adversary-in-the-middle (AiTM, attaquant intercalé), la victime se connecte à travers le proxy inverse de l'attaquant, qui relaie mot de passe et MFA à Microsoft et conserve le cookie de session. L'attaquant rejoue ensuite cette session depuis sa propre machine. Dans les journaux : une connexion interactive depuis le réseau du proxy (souvent un hébergeur), puis des connexions non interactives avec le même Session ID depuis une autre IP ou un autre pays, puis des enregistrements du journal d'audit unifié dont l'AADSessionId correspond. On confine par la révocation des sessions, pas seulement par une réinitialisation du mot de passe ; on prévient par une MFA résistante à l'hameçonnage.
Microsoft a décrit une campagne AiTM qui a tenté de cibler plus de 10 000 organisations à partir de septembre 2021, les attaquants lançant la fraude au paiement dès cinq minutes après le vol des identifiants et de la session. Depuis, ces kits se sont banalisés. La bonne nouvelle pour l'enquêteur, c'est que l'AiTM laisse une trace très caractéristique, parce que la session volée est utilisée depuis deux endroits.
Comment fonctionne l'attaque
- La victime clique sur un lien vers une page qui sert de proxy à la vraie page de connexion Microsoft.
- Elle saisit son mot de passe et approuve la MFA. Le proxy transmet les deux à Entra ID, qui émet un cookie de session au proxy, lequel en renvoie une copie à la victime. Du point de vue de la victime, la connexion a fonctionné.
- Le kit conserve le cookie (et souvent le mot de passe).
- L'attaquant importe le cookie dans son navigateur, ou utilise des jetons dérivés, et accède à Outlook sur le web, à Exchange, à SharePoint, sans nouvelle demande de MFA.
MITRE ATT&CK couvre ces étapes sous Adversary-in-the-Middle (T1557) et Use Alternate Authentication Material: Web Session Cookie (T1550.004).
Ce qu'on voit dans les journaux
| Moment | Journal | Ce qu'il faut voir |
|---|---|---|
| Connexion d'hameçonnage | Connexions Entra interactives | Connexion réussie, MFA satisfaite, depuis l'IP du proxy. Souvent un ASN d'hébergeur / VPS ; application souvent OfficeHome |
| Rejeu | Connexions Entra non interactives | Même Session ID, autre IP / ASN / pays, quelques minutes à quelques heures plus tard ; l'agent utilisateur peut changer |
| Persistance | Audit Entra / UAL | User registered security info (nouvel Authenticator ou téléphone), consentements |
| Actions | UAL | New-InboxRule, Set-Mailbox, MailItemsAccessed, Send avec AppAccessContext.AADSessionId = le Session ID volé et ClientIP = l'IP de rejeu |
Le fait clé, c'est que l'identifiant de session est hérité par tous les jetons dérivés de la connexion d'origine (Microsoft Learn, identifiants liables). Une session légitime change aussi de réseau (ordinateur portable du bureau à la maison), mais un saut vers un autre pays ou vers un hébergeur quelques minutes après une connexion depuis un hébergeur s'explique difficilement de façon innocente.
L'analyse par Microsoft d'une campagne en plusieurs étapes, publiée en juin 2023, décrit exactement cette séquence : le cookie volé rejoué quelques heures plus tard depuis une IP d'un autre pays, puis l'ajout d'une nouvelle méthode MFA (en notant qu'ajouter une méthode ne demandait pas de réauthentification par défaut), puis des règles déplaçant tout le courrier entrant vers Archive en le marquant comme lu (blog sécurité de Microsoft).
Une chasse manuelle, pas à pas
- Exportez les deux fichiers de connexion (interactives et non interactives) de tout le tenant, aussi loin que la rétention le permet (guide d'export).
- Regroupez par Session ID. Pour chaque session, notez son point de départ : les IP de ses connexions interactives (ou de son premier événement).
- Signalez les sessions utilisées ailleurs : toute connexion réussie de la session depuis une IP dont le pays ou l'ASN diffère de l'origine. Sans pays ni ASN, un /16 différent (IPv4) est une approximation grossière mais utile.
- Classez en tête les sessions dont l'origine est un hébergeur et dont le rejeu vient de l'étranger.
- Pivotez vers l'UAL sur les IP de rejeu et le Session ID, et listez les actions (enquête sur l'UAL).
- Vérifiez les autres utilisateurs : des connexions depuis les mêmes IP de proxy ou de rejeu ? Les campagnes s'arrêtent rarement à une seule boîte.
Si le tenant dispose d'Entra ID P2, les champs de risque aident : anomalousToken, unfamiliarFeatures, et la détection Attacker in the Middle au niveau de l'utilisateur, décrite sur Microsoft Learn. Microsoft précise que Anomalous token produit plus de faux positifs que la normale aux niveaux faible et moyen : vérifiez toujours dans les journaux bruts.
Faux positifs
| Situation | Pourquoi ça ressemble à un rejeu | Ce qui l'écarte |
|---|---|---|
| Ordinateur portable qui change de réseau | Même session, nouvelle IP | Même pays et ASN résidentiel/entreprise ; même ID d'appareil et même agent utilisateur |
| VPN en split tunneling | Une partie du trafic via le VPN, l'autre en direct | ASN du VPN connu ; alternance, pas un saut à sens unique |
| Bascule mobile (Wi-Fi vers 4G) | Nouvelle IP, ASN d'opérateur | ASN mobile dans le pays de l'utilisateur |
| Adresses IPv6 temporaires | L'adresse change en permanence | Même préfixe /48 |
Comment M365 Forensics le détecte
L'analyseur dans le navigateur implémente cette chasse dans le constat « Une même session utilisée depuis plusieurs lieux (rejeu de jeton) » (élevé) : pour chaque Session ID, l'origine est constituée de ses connexions interactives (ou du premier événement), et tout événement réussi de la même session depuis une autre IP compte comme rejeu si son pays diffère, si son ASN diffère quand les pays sont identiques ou inconnus, ou s'il tombe dans un autre /16 (/48 en IPv6) quand on ne sait rien d'autre. Le constat liste Session ouverte depuis et Session utilisée depuis.
Vient ensuite la corrélation : toute action de l'UAL ou de l'audit portant la session rejouée, l'IP de rejeu ou un jeton d'une connexion suspecte est regroupée sous « Actions effectuées depuis la session ou l'IP de l'attaquant » (critique). Seuls les constats de connexion qui reflètent la connexion de l'attaquant lui-même servent de marqueurs (réseau d'hébergeur, session rejouée, code d'appareil, connexion à risque, fatigue MFA suivie d'un succès) ; le voyage impossible n'en fait pas partie, car l'une de ses deux connexions est celle de l'utilisateur. L'incident fictif commenté montre le résultat sur un cas AiTM d'exemple.
Confinement et prévention
- Révoquer les sessions (centre d'administration Entra → utilisateur → Revoke sessions, ou
Revoke-MgUserSignInSession). Cela invalide les jetons d'actualisation ; les jetons d'accès peuvent rester valides jusqu'à leur expiration (une heure par défaut), sauf si l'application prend en charge l'évaluation continue de l'accès. - Supprimer ce que l'attaquant a ajouté : méthodes MFA, règles de boîte de réception et transferts, consentements d'applications.
- Réinitialiser le mot de passe depuis un appareil sain.
- Prévenir : MFA résistante à l'hameçonnage (clés d'accès / FIDO2, Windows Hello Entreprise, authentification par certificat), accès conditionnel exigeant des appareils conformes ou joints en mode hybride, et protection des jetons là où elle est prise en charge. Le guide de Microsoft sur le vol de jetons détaille l'investigation et la réponse.
L'ordre complet des opérations se trouve dans la première heure après un BEC.
Questions fréquentes
La MFA arrête-t-elle le phishing AiTM ?
Pas la MFA classique (notification, SMS, codes). Le proxy relaie l'étape MFA et vole le cookie de session qui prouve qu'elle a été réalisée. Les méthodes résistantes à l'hameçonnage comme les clés d'accès (passkeys), les clés de sécurité FIDO2 ou Windows Hello Entreprise sont liées au vrai site et ne peuvent pas être relayées ainsi.
Où le rejeu de jeton apparaît-il dans les journaux ?
Dans les connexions non interactives d'Entra ID : des connexions avec le même Session ID que la connexion interactive d'origine, mais depuis une autre IP, un autre réseau ou un autre pays. Les actions réalisées avec la session volée portent le même identifiant dans le journal d'audit unifié.
Une réinitialisation du mot de passe suffit-elle après un phishing AiTM ?
Non. Révoquez les sessions et jetons d'actualisation de l'utilisateur, supprimez toute méthode MFA, règle de boîte de réception, transfert ou consentement d'application ajouté par l'attaquant, puis réinitialisez le mot de passe.
Pour aller plus loin
- Microsoft Learn : Guide de réponse au vol de jetons
- Glossaire : rejeu de jeton, connexion non interactive, identifiants liables
- Analyse des journaux de connexion Entra ID pour les autres motifs de connexion.