Entra ID : Détection AiTM, Déplacements Impossibles, MFA

Entra ID AiTM Token Replay, Détection des Déplacements Impossibles : Pourquoi C'est Important Maintenant

L'authentification multifacteur bloque les attaques par mot de passe seul. Elle n'arrête pas un attaquant qui proxifie l'intégralité du flux de connexion et repart avec un cookie de session valide une fois que l'utilisateur a terminé la MFA. C'est exactement ce que font les kits de phishing adversary-in-the-middle (AiTM), et c'est précisément la brèche que Entra ID AiTM Token Replay, Détection des Déplacements Impossibles, et les signaux de fatigue liée aux notifications MFA sont conçus pour combler. Microsoft a été explicite sur le fait que cette classe d'attaque représente une part croissante des compromissions d'identité : le blog sécurité de Microsoft sur l'évolution des techniques d'attaque d'identité, ainsi que plusieurs analyses d'incidents, décrivent des kits AiTM comme Evilginx déployant un reverse proxy entre la victime et la véritable page de connexion Microsoft 365, servant le contenu légitime tout en capturant nom d'utilisateur, mot de passe et — surtout — le token de session/refresh émis après la réussite de la MFA. Deepwatch documente l'utilisation du même kit par des acteurs malveillants allant de l'opérateur de phishing prolifique Storm-0485 à l'acteur d'espionnage russe Star Blizzard, pour intercepter silencieusement des sessions Microsoft 365.

Microsoft Entra ID Protection transforme ce type d'activité en signaux de risque, mais ces signaux sont dispersés entre plusieurs détections distinctes, tables de logs et niveaux de licence. Cet article est un guide de terrain pour lire cinq d'entre eux ensemble :

Rejeu de token AiTM — un token de session ou de refresh volé est réutilisé depuis une infrastructure que l'utilisateur légitime n'a jamais touchée
Déplacement impossible / atypique — deux connexions pour la même identité, trop éloignées géographiquement pour être toutes deux légitimes
Abus d'approbation MFA push — un attaquant disposant d'un mot de passe valide tente de convaincre ou d'amener un utilisateur à approuver une notification push qu'il n'a pas demandée
Pics de connexion des service principals — une identité de workload s'authentifie soudainement bien plus, ou de manière bien plus large, que sa ligne de base
Géographie inhabituelle pour les comptes admin — une identité privilégiée se connecte depuis un lieu ou un appareil qu'elle n'a jamais utilisé

ℹ️

ℹ️ Note : Cet article couvre en profondeur les signaux AiTM/rejeu de token, anomalie de déplacement, service principal et géographie admin. L'abus d'approbation MFA fait l'objet d'un résumé ciblé ici — pour la chaîne d'attaque complète, la séquence de détection et la checklist de durcissement, voir MFA Fatigue : détection et prévention dans Microsoft Entra ID. La configuration des politiques de risque de connexion et d'utilisateur se trouve dans Azure Identity Protection : bloquer les identifiants divulgués.

Comment Chaque Signal Apparaît Dans La Télémétrie d'Entra ID

Proxys AiTM et rejeu de token

MITRE suit le vol de cookie de session sous T1539 (Steal Web Session Cookie). Un kit AiTM se place entre l'utilisateur et le véritable point de connexion Microsoft, relaie chaque étape de l'authentification — y compris le challenge MFA — puis capture l'artefact de session résultant. Comme la victime a réellement complété la MFA, le token volé porte cette revendication. L'attaquant le rejoue depuis sa propre infrastructure, pas depuis l'appareil ou le réseau de la victime.

Microsoft Entra ID Protection dispose de plusieurs détections qui captent des fragments de ce scénario :

Token anormal (riskEventType: anomalousToken) — se déclenche sur des caractéristiques de token anormales : une durée de vie inhabituelle, ou un token utilisé depuis un lieu, une application, une adresse IP ou un user agent qui ne correspond pas à l'historique de l'utilisateur. La documentation de Microsoft cite explicitement ce signal comme un indicateur direct de rejeu de token potentiel. Il est temps réel ou hors ligne, et nécessite Entra ID P2.
Attacker in the Middle (attackerinTheMiddle, une détection de risque utilisateur) — une détection à haute précision déclenchée lorsqu'une session de connexion est liée à un reverse proxy malveillant connu, sourcée depuis la télémétrie Microsoft Defender for Cloud Apps. Elle fait passer directement l'utilisateur en risque élevé et nécessite Microsoft 365 E5 avec Enterprise Mobility + Security E5 — contrairement à la plupart des autres détections sourcées par Defender for Cloud Apps, Microsoft ne mentionne pas de chemin de licence autonome Entra ID P2 + Defender for Cloud Apps pour celle-ci.
Propriétés de connexion inhabituelles (unfamiliarFeatures) — compare une connexion à l'historique appris de l'utilisateur (IP, ASN, localisation, appareil, navigateur, sous-réseau du tenant). Les recommandations de Microsoft signalent spécifiquement ceci : quand ce signal se déclenche sur une connexion non interactive, il mérite une attention supplémentaire, car ce schéma correspond à un token de refresh rejoué silencieusement en arrière-plan plutôt qu'à une connexion interactive.
Anomalie d'émetteur de token (tokenIssuerAnomaly) — pour les tokens SAML, signale des revendications d'émetteur inhabituelles ou correspondant à des schémas d'attaquants connus.

Le playbook de vol de token de Microsoft liste les déclencheurs concrets qu'un SOC doit surveiller pour les investigations de vol de token : token anormal, propriétés de connexion inhabituelles, connexions non interactives depuis des sources inhabituelles, tentative d'accès au Primary Refresh Token (PRT) (via Defender for Endpoint), et URL suspectes correspondant à une page d'atterrissage AiTM.

⚠️

⚠️ Avertissement : Aucune de ces détections ne garantit de capturer un proxy AiTM bien mené dès la première connexion. La documentation de Microsoft sur la détection de risque note que la détection de token anormal peut rester bruyante, avec un taux de faux positifs plus élevé que la normale aux niveaux de risque faible et moyen — traitez un seul signal de risque faible comme une piste à investiguer, pas comme une compromission confirmée.

Déplacement impossible et déplacement atypique

Entra ID Protection propose en réalité deux détections liées mais distinctes ici, et les confondre mène à de mauvaises hypothèses de licence et d'outillage :

Déplacement impossible (mcasImpossibleTravel) — identifie une activité depuis des lieux géographiquement distants dans une fenêtre de temps plus courte que ce qui est physiquement possible entre eux. Sourcé depuis Microsoft Defender for Cloud Apps, calculé hors ligne, et nécessite Entra ID P2 plus une licence Defender for Cloud Apps autonome (ou Microsoft 365 E5).
Déplacement atypique (unlikelyTravel) — une détection native d'Entra ID Protection (sans dépendance à Defender for Cloud Apps) qui signale deux connexions depuis des lieux distants où au moins l'une est également atypique pour l'historique de cet utilisateur spécifique. Elle tient compte du temps de trajet entre les lieux et supprime volontairement les faux positifs courants comme les points de sortie VPN et les IP partagées au sein de l'organisation. Les nouveaux utilisateurs traversent une période d'apprentissage de 14 jours ou 10 connexions (selon la première échéance atteinte) avant que la détection ne s'active.

Les deux nécessitent Entra ID P2. Si votre tenant n'a que P1 ou Free, elles se déclenchent comme la détection générique Additional risk detected, sans détail.

Abus d'approbation MFA push, en bref

Deux signaux natifs Entra comptent ici : Suspicious MFA authentication approval (authenticatorPhishing) est une détection temps réel, réservée à P2, qui corrèle les incohérences d'ASN, de navigateur, d'appareil et de GPS entre l'appareil demandant la connexion et l'appareil approuvant via Microsoft Authenticator, et signale directement l'appariement comme risque élevé. User reported suspicious activity (userReportedSuspiciousActivity) se déclenche lorsqu'un utilisateur refuse une invite MFA qu'il n'a pas initiée et la signale explicitement — Microsoft traite cela comme une preuve à haute confiance, confirmée par l'utilisateur, et fait immédiatement passer le compte en risque utilisateur élevé. Seul ce dernier dépend de l'activation de la fonctionnalité Report suspicious activity ; authenticatorPhishing se déclenche automatiquement depuis la télémétrie de connexion et ne nécessite aucune activation séparée. Pour la chaîne d'attaque complète et la séquence de durcissement (number matching, MFA résistante au phishing pour les admins, workflow de réponse), voir l'article dédié à la MFA fatigue lié ci-dessus.

Pics de connexion des service principals

Les identités de workload n'apparaissent pas dans la même table SigninLogs que les utilisateurs — elles se loguent dans AADServicePrincipalSignInLogs (aussi appelée ServicePrincipalSignInLogs selon le nommage du workspace/de la table). Les recommandations d'audit de Thomas Naunheim pour les identités managées et les service principals préconisent de grouper par ServicePrincipalName et IPAddress, puis d'agréger le nombre d'échecs (ResultType != "0") et la diversité des ressources accédées (dcount(ResourceDisplayName)) — un pic dans l'une ou l'autre dimension, surtout depuis une IP ou un ASN que le service principal n'a jamais utilisé, est le signal à investiguer. Microsoft Entra ID Protection dispose aussi d'une surface de détection dédiée au risque des identités de workload pour exactement ce scénario, distincte du risque utilisateur.

Géographie inhabituelle pour les comptes admin

Le guide des opérations de sécurité de Microsoft pour les comptes privilégiés est explicite : les connexions admin méritent une surveillance plus stricte et distincte de celle des utilisateurs standards — nouvel appareil ou lieu, connexions en dehors des heures de travail attendues, et toute détection de risque Entra ID Protection (quel que soit le niveau de risque) sur une identité privilégiée devraient toutes générer une alerte prioritaire. Le même guide recommande de traiter toute activité Unfamiliar sign-in ou sourcée depuis TOR contre un rôle privilégié comme méritant une revue immédiate, plutôt que d'attendre qu'elle escalade vers un risque élevé.

Détection : Que Récupérer Dans Les Logs

Le playbook de vol de token Entra de Microsoft fournit des requêtes de départ concrètes pour SigninLogs, AADUserRiskEvents et AuditLogs. Adaptées ici pour l'ensemble de signaux AiTM/déplacement/géo-admin :

Trouver les détections de risque marquées inhabituelles ou anormales depuis une IP spécifique (point de départ une fois qu'on dispose d'une IP suspecte issue d'un signalement de phishing ou d'une alerte EDR) :

AADUserRiskEvents
| where RiskEventType contains "unfamiliar" or RiskEventType contains "anomalous"
| where IpAddress == "<suspect-ip>"

Extraire toutes les connexions depuis la même IP source pour délimiter le rayon d'impact :

SigninLogs
| where IPAddress == "<suspect-ip>"

Établir la ligne de base de géographie et d'appareils de connexion d'une identité spécifique — c'est la requête que le playbook recommande avant de décider si une connexion signalée est réellement anormale pour cet utilisateur :

SigninLogs
| where UserId == "<user-object-id>"
| extend deviceId_ = tostring(DeviceDetail.deviceId)
| extend city_ = tostring(LocationDetails.city)
| extend countryOrRegion_ = tostring(LocationDetails.countryOrRegion)
| summarize min(TimeGenerated), max(TimeGenerated)
  by IPAddress, ResultDescription, deviceId_, city_, countryOrRegion_, AppDisplayName

Le playbook note explicitement que toute alerte de risque Entra n'a pas nécessairement de ligne correspondante dans SigninLogs — les détections de token anormal en particulier ne sont parfois visibles que via AADUserRiskEvents ou l'API de détections de risque ID Protection, pas le flux de connexion brut.

Pic de service principal, adapté du guide d'audit de cloud-architekt.net :

AADServicePrincipalSignInLogs
| where TimeGenerated >= ago(1d)
| where ResultType != "0"
| summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated),
    count(), applicationCount = dcount(ResourceDisplayName),
    applicationSet = make_set(ResourceDisplayName)
  by ServicePrincipalName, IPAddress, ResultType

Pour la géographie des comptes privilégiés et la surveillance des refus MFA, Microsoft fournit du contenu Sentinel prêt à l'emploi plutôt qu'une requête unique à recopier — le guide des opérations de sécurité pour comptes privilégiés pointe vers des modèles nommés incluant SuspiciousSignintoPrivilegedAccount.yaml, MFARejectedbyUser.yaml et AADPrivilegedAccountsFailedMFA.yaml dans le dépôt GitHub Azure-Sentinel, une meilleure source de vérité que de reconstruire ici la logique exacte des filtres.

💡

💡 Astuce : Si une connexion signalée est non interactive (aucun utilisateur présent), traitez-la comme prioritaire par rapport à un signal interactif équivalent. Les recommandations de Microsoft isolent spécifiquement ce schéma car il correspond à un rejeu de token en arrière-plan plutôt qu'à une connexion utilisateur active (et potentiellement légitime).

Remediation / Remédiation

Pour le rejeu de token / AiTM :

Faites migrer les comptes privilégiés et à haute valeur vers une MFA résistante au phishing (clés de sécurité FIDO2 ou authentification par certificat) — un cookie de session proxifié devient bien moins utile pour un attaquant si la cérémonie d'authentification d'origine ne peut pas simplement être rejouée. Voir Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas pour comprendre pourquoi la MFA push standard ne suffit pas seule.
Activez Continuous Access Evaluation et la protection de token du Conditional Access là où c'est pris en charge, pour qu'un token lié à un appareil ne puisse pas simplement être rejoué depuis l'infrastructure de l'attaquant. Le catalogue d'EtcSec suit cette brèche directement sous CA_TOKEN_PROTECTION_DISABLED — voir Failles d'Accès Conditionnel Azure : Contournement du MFA pour la revue de politique plus large.
Activez les détections Attacker in the Middle et Anomalous token (nécessite P2, et Defender for Cloud Apps pour la première) et routez-les vers une politique de Conditional Access basée sur le risque de connexion plutôt que de les laisser en simple visibilité tableau de bord.
Traitez tout hit AiTM confirmé comme un incident de vol de token, pas comme une réinitialisation de mot de passe : suivez les étapes de containment du playbook de vol de token de Microsoft — révoquer les sessions, bloquer l'IP de l'attaquant, et vérifier les méthodes MFA nouvellement enregistrées ou les règles de boîte mail laissées après l'utilisation de la session.

Pour le déplacement impossible / atypique :

Confirmez le licensing — le déplacement atypique est natif à ID Protection P2, mais le déplacement impossible nécessite en plus Defender for Cloud Apps connecté. L'absence de cette connexion fait silencieusement disparaître le signal mcasImpossibleTravel.
Laissez la fenêtre d'apprentissage de 14 jours/10 connexions se terminer pour les comptes nouveaux ou récemment migrés avant d'ajuster les seuils sur des données bruyantes en début de période.
Injectez le risque de connexion dans une politique de Conditional Access qui exige la MFA ou bloque à risque moyen/élevé, plutôt que de vous contenter de consulter réactivement le rapport des connexions à risque.

Pour l'abus d'approbation MFA : activez le number matching et la fonctionnalité Report suspicious activity, et exigez une MFA résistante au phishing pour les administrateurs — voir l'article dédié à la MFA fatigue pour la séquence complète.

Pour les pics de service principal :

Passez en revue AADServicePrincipalSignInLogs pour comparer comportement de base et pics sur une cadence récurrente, pas seulement en réponse à incident.
Évitez les rôles à haut privilège permanents sur les service principals ; faites tourner les secrets/certificats client selon un calendrier défini et privilégiez les identités managées quand c'est possible.
Activez les détections de risque d'identité de workload d'Entra ID Protection si votre licence le permet — les politiques de risque utilisateur ne couvrent pas les service principals.

Pour la géographie admin inhabituelle :

Enrôlez tous les rôles privilégiés dans Privileged Identity Management (PIM) avec activation limitée dans le temps, et exigez une nouvelle authentification à l'activation.
Alertez sur toute détection de risque ID Protection contre une identité privilégiée, quel que soit le niveau de risque attribué par Microsoft — les recommandations de Microsoft pour les comptes privilégiés préconisent cette barre plus stricte pour les admins par rapport aux utilisateurs standards.
Restreignez l'élévation admin aux appareils approuvés (PAW/SAW) quand c'est possible, et alertez quand l'élévation se produit en dehors de cette population.

Comment EtcSec Détecte Cela

Les catégories Risk Protection et Conditional Access d'EtcSec vérifient si un tenant dispose de l'échafaudage de politique et de licence dont dépendent ces détections, pas seulement si Entra ID Protection est activé. Les vérifications de catalogue pertinentes incluent MFA_SUSPICIOUS_ACTIVITY (activité MFA / schéma de connexion suspect) et MFA_UNUSUAL_LOCATION (connexion MFA depuis une géolocalisation inhabituelle) au niveau du signal, plus RISK_NO_SIGNIN_RISK_POLICY (aucune politique de risque de connexion en place) et RISK_SIGNINS_NOT_INVESTIGATED (connexions à risque s'accumulant sans revue), et CA_TOKEN_PROTECTION_DISABLED (aucune liaison de token pour freiner le rejeu) au niveau de la réponse.

Un tenant qui affiche des connexions à risque dans le portail mais n'a aucune politique agissant dessus, et aucune protection de token devant les cookies de session, est exactement la brèche que ces vérifications sont conçues pour révéler.

Contrôles Liés

Lisez ceci en parallèle de Azure Identity Protection : bloquer les identifiants divulgués pour la configuration des politiques de risque de connexion et d'utilisateur, MFA Fatigue : détection et prévention dans Microsoft Entra ID pour la chaîne d'attaque d'abus d'approbation, Acces Privilegie Azure : Trop d'Admins Globaux et Comment auditer la sécurité Microsoft Entra ID pour le volet PIM et durcissement admin, et OAuth Consent Phishing et Applications Malveillantes et Device Code Phishing dans Entra ID pour les techniques de phishing d'identité adjacentes qui alimentent les mêmes signaux de risque.

Entra ID AiTM Token Replay : Détection des Déplacements Impossibles et Fatigue MFA