Journaux de connexion Entra ID : analyse, risques, voyages

En bref. Dans les journaux de connexion, lisez sept choses par ligne : heure, utilisateur, IP + ASN + lieu, application, client / protocole d'authentification, statut + code d'erreur, Session ID. Cherchez ensuite des motifs plutôt que des lignes isolées : une connexion réussie depuis un hébergeur, un même Session ID utilisé depuis deux réseaux, beaucoup d'échecs 50126 depuis une IP (pulvérisation), des échecs MFA répétés puis un succès (fatigue), un protocole deviceCode, un client hérité, un blocage par l'accès conditionnel suivi d'un succès. Le voyage impossible est une piste, pas un verdict : VPN et réseaux mobiles en génèrent énormément.

Les journaux de connexion sont le point de départ d'un BEC. C'est aussi là que naissent la plupart des fausses alertes, parce qu'une équipe commerciale en déplacement sur le Wi-Fi d'un hôtel ou les points de sortie d'un opérateur mobile ressemblent beaucoup à un attaquant. Tout l'art consiste à combiner les signaux.

Les champs à lire

Dans le CSV/JSON du portail ou la ressource signIn de Graph :

Les codes d'erreur que vous rencontrerez

D'après la référence des codes d'erreur AADSTS de Microsoft :

Un 50074 ou un 500121 sur un compte que l'utilisateur n'essayait pas d'ouvrir à ce moment-là signifie que quelqu'un d'autre connaît le mot de passe.

Motif 1 : connexion réussie depuis un hébergeur ou un VPN

Les proxys d'hameçonnage et les machines des attaquants tournent pour la plupart chez des fournisseurs cloud et VPS. Une connexion réussie dont l'ASN appartient à un hébergeur, pour un utilisateur qui se connecte d'habitude depuis un réseau d'entreprise ou un FAI résidentiel, est l'un des signaux isolés les plus utiles. Deux réserves : votre propre VPN ou passerelle web sécurisée peut aussi se trouver sur un ASN cloud (mettez-le en liste blanche), et les attaquants utilisent de plus en plus des proxys résidentiels précisément pour échapper à ce contrôle.

Motif 2 : une session, deux réseaux

Le Session ID est créé lors de la connexion interactive et hérité par tous les jetons qui en dérivent. Si la connexion interactive vient de l'IP A et que des connexions non interactives du même Session ID arrivent de l'IP B, dans un autre pays ou un autre ASN, la session a très probablement été volée et rejouée. C'est le sujet de détection du phishing AiTM et du rejeu de jeton.

Motif 3 : le voyage impossible, et pourquoi il ment

Le voyage impossible compare des connexions réussies consécutives d'un utilisateur : si la distance divisée par le temps écoulé dépasse ce qu'un avion de ligne peut faire, quelque chose cloche. Il détecte le rejeu depuis un autre continent. Il détecte aussi :

La détection Atypical travel (voyage atypique) de Microsoft ignore les faux positifs évidents comme les VPN et les lieux régulièrement utilisés par d'autres membres de l'organisation, et nécessite une période d'apprentissage (le plus court entre 14 jours et 10 connexions). Une analyse fondée uniquement sur les journaux n'a pas cet historique : considérez le voyage impossible brut comme une piste et exigez un second indicateur.

La règle de M365 Forensics affiche ses paramètres : deux connexions réussies consécutives du même compte, distantes d'au moins 500 km, impliquant plus de 900 km/h ; elle utilise les coordonnées de la connexion quand elles existent, sinon le centre géographique du pays. Elle est classée élevée, pas critique, justement à cause des faux positifs ci-dessus.

Motif 4 : pulvérisation de mots de passe et fatigue MFA

• Pulvérisation de mots de passe (password spraying) : une IP, beaucoup de comptes différents, des échecs 50126 en moins d'une heure. L'outil la signale quand une IP échoue sur au moins cinq comptes distincts en 60 minutes. Si l'un de ces comptes réussit ensuite depuis un lieu inhabituel, traitez-le en priorité.
• Fatigue MFA : plusieurs échecs à l'étape MFA (500121, 50074, 50076…) pour un même utilisateur en peu de temps, éventuellement suivis d'un succès. L'outil signale cinq échecs en une heure (moyen) et trois échecs suivis d'une connexion interactive réussie dans l'heure (élevé). La correspondance de nombres dans Microsoft Authenticator réduit le risque mais ne supprime pas l'ingénierie sociale.

Entra ID Protection a sa propre détection Password spray ; selon Microsoft Learn, elle ne se déclenche que lorsqu'une pulvérisation a réellement validé le mot de passe d'un utilisateur.

Motif 5 : code d'appareil et authentification héritée

• Flux par code d'appareil (authenticationProtocol = deviceCode, ou originalTransferMethod = deviceCodeFlow) : l'utilisateur saisit un code sur la page de connexion d'appareil de Microsoft et la session de l'attaquant reçoit les jetons. Microsoft a documenté une vaste campagne d'hameçonnage par code d'appareil en février 2025 et recommande de bloquer ce flux partout où c'est possible. Voir hameçonnage par code d'appareil.
• Authentification héritée (IMAP, POP, SMTP AUTH, Exchange ActiveSync en authentification de base…) : impossible d'y imposer la MFA. Une connexion héritée réussie sur une boîte qui ne devrait pas l'utiliser mérite un examen.

Motif 6 : blocage par l'accès conditionnel, puis succès

Un blocage 53003 suivi dans l'heure d'un succès pour le même utilisateur peut être un utilisateur qui corrige son appareil, ou un attaquant qui change de client ou de réseau jusqu'à ce qu'une stratégie ne s'applique plus. Comparez les deux lignes : même appareil et même IP, ou non ?

Les signaux d'Entra ID Protection

Si le tenant dispose de P2, riskEventTypes_v2 et riskLevelDuringSignIn portent les détections de Microsoft (unfamiliarFeatures, anonymizedIPAddress, unlikelyTravel…). Sans P2, vous voyez hidden ou un « risque supplémentaire détecté » générique. Utilisez-les comme corroboration ; leur absence ne prouve rien.

Tout lire ensemble

Une ligne isolée très parlante est rare. Ce qui convainc, c'est un faisceau : une pulvérisation depuis un VPS à 22 h 10, une connexion réussie depuis un hébergeur pour le même utilisateur à 8 h 12, le même Session ID depuis un autre pays sept minutes plus tard, puis une nouvelle méthode MFA. M365 Forensics évalue chaque motif, puis corrèle : toute action de l'UAL ou de l'audit portant l'IP, le Session ID ou le jeton d'une connexion suspecte devient un constat critique. L'incident fictif commenté montre un tel faisceau, y compris un constat de voyage impossible dont les preuves mêlent les connexions légitimes de l'utilisatrice et celles de l'attaquant.

Questions fréquentes

Une alerte de voyage impossible prouve-t-elle que le compte a été piraté ?

Non. VPN, proxys cloud, réseaux mobiles et erreurs de géolocalisation IP produisent tous des voyages impossibles entre connexions légitimes. Traitez-la comme une piste et cherchez un second indicateur indépendant : réseau d'hébergeur, session rejouée ou nouvelle règle de boîte de réception.

Que signifie l'erreur 50126 dans les journaux de connexion Entra ?

InvalidUserNameOrPassword : les identifiants étaient faux. Quelques-unes sont normales ; de nombreux échecs 50126 depuis une même IP sur de nombreux comptes en peu de temps signent une pulvérisation de mots de passe.

Pourquoi les connexions non interactives sont-elles importantes ?

Elles enregistrent l'utilisation de jetons sans action de l'utilisateur, c'est-à-dire la manière dont un cookie de session ou un jeton d'actualisation volé est rejoué. Le rejeu de jeton et beaucoup d'actions de l'attaquant n'apparaissent que là.

Pour aller plus loin

• Microsoft Learn : Que sont les détections de risque ?, Journaux de connexion non interactives
• MITRE ATT&CK : Password Spraying (T1110.003), MFA Request Generation (T1621)
• Comment exporter les journaux de connexion
• Okta pose les mêmes questions avec d'autres champs : oktaforensics.com.