Entra ID Risk Protection : Identifiants Divulgués, Utilisateurs à Risque Non Corrigés

Entra ID Risk Protection : Identifiants Divulgués, Utilisateurs à Risque Non Corrigés

Entra ID Risk Protection n'a aucun mal à repérer les comptes compromis. Le problème, c'est ce qui se passe ensuite. Dans un grand nombre de tenants, le même schéma se répète — des identifiants divulgués détectés par Entra ID Risk Protection, des utilisateurs à risque non corrigés pendant des semaines, voire des mois — car la détection se déclenche, atterrit dans un rapport, et y reste. Cet article porte sur cet écart : non pas l'ingénierie de détection, que Microsoft assure déjà pour vous, mais le workflow de réponse que presque personne n'opérationnalise.

Chaque utilisateur à risque dans Entra ID porte un état de risque. Microsoft Graph documente les valeurs possibles comme none, confirmedSafe, remediated, dismissed, atRisk, et confirmedCompromised (plus la valeur sentinelle unknownFutureValue). Seules trois d'entre elles permettent de sortir un compte signalé de la file d'attente — remediated, dismissed, et confirmedSafe, ce qui correspond aux actions manuelles exposées par Microsoft : ignorer (dismiss), confirmer sûr (confirm safe), confirmer compromis (confirm compromise). Les états atRisk et confirmedCompromised laissent tous deux l'utilisateur dans le rapport des utilisateurs à risque. atRisk signifie que le compte est toujours signalé et que rien n'a été fait à son sujet. confirmedCompromised est celui qui piège le plus souvent : un administrateur a examiné le compte, a confirmé qu'il était compromis, et cet état seul ne signifie toujours pas que quelqu'un a sécurisé le compte.

Confirmer un compromis est une action d'étiquetage, pas une action de confinement. Il en va de même pour le rejet (dismissal).

L'arriéré (backlog) ne s'efface pas non plus de lui-même. Les détections de risque de faible niveau et les utilisateurs concernés « persistent dans le produit pendant six mois, après quoi ils sont automatiquement retirés » — mais les niveaux de risque moyen et élevé persistent jusqu'à leur correction ou leur rejet. Une détection d'identifiants divulgués à risque élevé soulevée il y a deux ans figure toujours aujourd'hui dans le rapport des utilisateurs à risque, à moins qu'un humain ou une stratégie ne l'ait close.

Comment fonctionne la détection des identifiants divulgués

Les identifiants divulgués (leaked credentials) font partie des rares détections de risque qui ne comportent aucune ambiguïté.

Microsoft décrit le pipeline sous-jacent : un service d'analyse d'identifiants à grande échelle qui surveille en continu les forums du dark web, les dépôts de fuites de données (breach dumps), les sites de paste, les données issues de saisies des forces de l'ordre, et d'autres sources, via le Microsoft Threat Intelligence Center (MSTIC), la Microsoft Digital Crimes Unit (DCU), et des partenaires du secteur. Lorsque des identifiants sont découverts, le service valide le matériel d'identifiants réel par rapport aux hachages de mots de passe actuellement valides du tenant, et une détection n'est émise que lorsqu'une correspondance confirmée est trouvée. Selon les propres termes de Microsoft, la détection « est toujours à risque élevé car elle représente une exposition d'identifiants vérifiée, et non un signal heuristique ».

Deux conséquences opérationnelles en découlent.

Premièrement, il ne s'agit pas d'un score de probabilité. Un déplacement atypique (atypical travel) peut simplement correspondre à un utilisateur en vacances. Une détection d'identifiants divulgués signifie qu'un mot de passe actuellement valide dans votre tenant se trouve entre les mains de quelqu'un d'autre. Cela mérite un incident, pas une file de tri.

Deuxièmement, vous l'apprenez tard. Les identifiants divulgués sont calculés hors ligne, et Microsoft documente que « les détections déclenchées en temps réel prennent 5 à 10 minutes pour faire apparaître les détails dans les rapports. Les détections hors ligne prennent jusqu'à 48 heures pour apparaître dans les rapports ». La fenêtre entre l'exposition et votre première chance d'agir se mesure en jours, ce qui explique précisément pourquoi la réponse doit être rapide dès que le signal arrive.

La synchronisation de hachage de mot de passe compte ici plus que ne le pensent la plupart des équipes. Une réinitialisation de mot de passe basée sur le cloud via Microsoft Entra corrige le risque utilisateur pour cette détection, à la fois pour les mots de passe cloud et on-premises — mais uniquement « tant que la synchronisation de hachage de mot de passe (PHS) est activée pour les mots de passe on-premises ».

Pourquoi l'arriéré d'utilisateurs à risque ne se résorbe jamais

Les tenants avec les pires arriérés sont rarement ceux qui ont ignoré le produit. Ce sont ceux où plusieurs petites failles s'accumulent.

Les alertes n'atteignent personne. L'e-mail « Users at risk detected » utilise par défaut un seuil de risque utilisateur élevé (High). Par défaut, les utilisateurs activement assignés aux rôles Global Administrator, Security Administrator ou Security Reader sont ajoutés à la liste des destinataires, et ils doivent disposer d'un champ Email ou Alternate email configuré. Deux réserves documentées viennent discrètement casser ce mécanisme : un utilisateur qui s'élève vers l'un de ces rôles via Privileged Identity Management « ne reçoit des e-mails que s'il est élevé au moment où l'e-mail est envoyé », et « l'envoi d'e-mails aux utilisateurs dont le rôle est assigné via un groupe n'est pas pris en charge ». Un tenant qui accorde le rôle Security Reader via un groupe et élève ses administrateurs à la demande via PIM peut recevoir exactement zéro notification pendant que son tableau de bord se remplit.

Les seuils de stratégie sont fixés au-dessus de la majorité de la file. La configuration recommandée par Microsoft est une stratégie de risque utilisateur au niveau Élevé (High) et une stratégie de risque de connexion aux niveaux Moyen et Élevé (Medium and High). C'est un conseil pertinent, mais cela signifie que chaque détection à risque moyen et à risque faible est laissée à un humain, et les risques moyens persistent jusqu'à ce que quelqu'un les clôture.

L'auto-correction n'est en réalité pas disponible. Microsoft avertit que « les utilisateurs doivent s'inscrire à l'authentification multifacteur Microsoft Entra avant de se retrouver dans une situation nécessitant une correction. Pour les utilisateurs hybrides synchronisés depuis l'environnement on-premises, l'écriture différée du mot de passe (password writeback) doit être activée. Les utilisateurs non inscrits sont bloqués et nécessitent une intervention de l'administrateur ». Les utilisateurs hybrides ont également besoin de la PHS ainsi que du paramètre optionnel Allow on-premises password change to reset user risk avant qu'un changement de mot de passe on-premises n'efface leur risque. Lorsque ces prérequis font défaut, la stratégie ne résorbe pas la file — elle transforme des utilisateurs à risque en utilisateurs bloqués et reporte la charge de travail sur le support technique.

Certaines détections ont cessé de s'auto-corriger. Microsoft ne corrige plus automatiquement les sessions porteuses de revendications MFA (MFA claims) lorsqu'une détection liée au vol de jeton ou la détection Verified threat actor IP se déclenche. Les détections concernées sont Microsoft Entra threat intelligence, Anomalous token, Attacker in the Middle, Verified threat actor IP, et Token issuer anomaly. Lorsque l'une d'elles touche un utilisateur, effacer le risque nécessite un changement de mot de passe sécurisé et une réauthentification avec MFA. Si votre modèle mental est encore « le MFA efface tout », ces cas s'accumulent.

Les utilisateurs supprimés restent bloqués pour toujours. « Si un utilisateur présentant un risque a été supprimé de l'annuaire, il apparaît toujours dans le rapport de risque même si le compte a été supprimé. Les administrateurs ne peuvent pas rejeter le risque pour des utilisateurs supprimés de l'annuaire. » Les effacer nécessite l'ouverture d'un dossier de support Microsoft. Chaque utilisateur à risque désactivé (offboardé) gonfle définitivement le compteur, ce qui finit par apprendre à l'équipe à ne plus faire confiance au chiffre.

L'automatisation héritée (legacy) a une date d'expiration. Les recommandations de Microsoft sont explicites : « Les stratégies de risque héritées configurées dans Microsoft Entra ID Protection seront retirées le 1er octobre 2026 ». Les tenants dont la seule réponse automatisée repose sur une stratégie de risque héritée d'ID Protection — plutôt que sur une stratégie d'accès conditionnel — la perdront, et un arriéré qui se résorbait automatiquement recommencera à croître.

Détection : mesurer votre propre arriéré de correction

Les rapports du portail vous indiquent qui est à risque. Ils ne vous indiquent pas combien de temps les utilisateurs restent à risque, qui est pourtant le chiffre qui compte. Pour cela, vous avez besoin des données de risque dans Log Analytics.

Configurez les paramètres de diagnostic dans Entra ID > Monitoring & health > Diagnostic settings et exportez les catégories RiskyUsers et UserRiskEvents (Microsoft expose également RiskyServicePrincipals, ServicePrincipalRiskEvents, RiskyAgents, et AgentRiskEvents). Elles atterrissent dans les tables AADRiskyUsers et AADUserRiskEvents.

Ce qu'il faut surveiller

Détections d'identifiants divulgués encore ouvertes

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskEventType == "leakedCredentials"
| where RiskState == "atRisk"
| project DetectedDateTime, UserPrincipalName, RiskLevel, RiskState, RiskDetail, DetectionTimingType
| order by DetectedDateTime asc

Chaque ligne correspond à un compte dont le mot de passe est connu comme exposé et auquel personne n'a touché. Trié du plus ancien au plus récent, le haut de cette liste représente votre pire exposition.

Quelle est l'ancienneté de l'arriéré à risque

AADRiskyUsers
| summarize arg_max(TimeGenerated, RiskState, RiskLevel, RiskDetail, RiskLastUpdatedDateTime)
    by UserPrincipalName
| where RiskState == "atRisk"
| where RiskLevel in ("high", "medium")
| extend DaysAtRisk = datetime_diff('day', now(), RiskLastUpdatedDateTime)
| project UserPrincipalName, RiskLevel, RiskDetail, RiskLastUpdatedDateTime, DaysAtRisk
| order by DaysAtRisk desc

AADRiskyUsers reçoit un enregistrement à chaque changement d'état de risque d'un utilisateur, donc arg_max réduit le flux au dernier état connu par utilisateur avant que l'ancienneté ne soit calculée.

Auditer le bouton de rejet (dismiss)

AADRiskyUsers
| where TimeGenerated > ago(90d)
| where RiskState == "dismissed" and RiskDetail == "adminDismissedAllRiskForUser"
| project TimeGenerated, UserPrincipalName, RiskLevel, RiskDetail
| order by TimeGenerated desc

Le rejet est un résultat légitime après investigation. C'est aussi le moyen le plus rapide de faire paraître un tableau de bord en bonne santé. Recoupez cette liste avec votre système de tickets : un rejet sans enregistrement d'investigation correspondant est une décision que personne ne pourra défendre plus tard.

Délai de clôture, par type de détection

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskLevel == "high"
| where RiskState in ("remediated", "dismissed", "confirmedCompromised")
| extend HoursToClose = datetime_diff('hour', LastUpdatedDateTime, DetectedDateTime)
| summarize Detections = count(),
            MedianHours = percentile(HoursToClose, 50),
            P90Hours = percentile(HoursToClose, 90)
    by RiskEventType
| order by Detections desc

C'est la mesure à présenter à la direction. « Nous avons 40 utilisateurs à risque » n'inspire qu'un haussement d'épaules ; « notre délai médian de clôture pour un identifiant divulgué confirmé est de 26 jours » n'en inspire pas.

Interroger les mêmes données depuis Microsoft Graph

L'API riskyUsers nécessite une licence Microsoft Entra ID P2 (ou Microsoft Entra Suite). Sa lecture requiert la permission IdentityRiskyUser.Read.All, et pour un accès délégué, l'utilisateur connecté doit détenir le rôle Global Reader, Security Operator, Security Reader, ou Security Administrator.

GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?$filter=riskState eq 'atRisk' and riskLevel eq 'high'

Le point de terminaison prend en charge $filter et $select, avec une taille de page maximale de 500 objets via $top. La même requête via le Graph PowerShell SDK :

Import-Module Microsoft.Graph.Identity.SignIns

Get-MgRiskyUser -Filter "riskState eq 'atRisk' and riskLevel eq 'high'" -All |
    Select-Object UserPrincipalName, RiskLevel, RiskState, RiskDetail, RiskLastUpdatedDateTime

Exécutez-la selon une planification et déclenchez une alerte sur le compteur, pas sur les événements individuels. Un arriéré qui croît semaine après semaine, voilà le constat qui compte.

Correction : résorber la file et la maintenir résorbée

1. Savoir ce que chaque action fait réellement

Avant d'automatiser quoi que ce soit, assurez-vous que l'équipe s'accorde sur la signification de chaque bouton. Microsoft documente l'état et le détail résultants pour chaque chemin :

La terminologie est réellement source de confusion, et Microsoft le signale : le détail de risque « L'utilisateur a effectué une réinitialisation de mot de passe sécurisée » est une étiquette générée par le système qui indique que l'utilisateur a effectué un changement de mot de passe sécurisé (MFA suivi d'un changement de mot de passe), et non un flux de réinitialisation de mot de passe en libre-service.

Notez également la répartition des rôles — Security Operator est le rôle le moins privilégié permettant de rejeter un risque utilisateur, tandis que User Administrator est requis pour réinitialiser les mots de passe. Réinitialiser un mot de passe depuis ID Protection nécessite les deux.

2. Traiter une fois l'arriéré d'identifiants divulgués, manuellement

Les étapes d'investigation de Microsoft pour cette détection sont précises, et constituent le bon runbook pour résorber la file existante :

1. Évaluer l'étendue de l'exposition — passez en revue l'historique de risque de l'utilisateur et les journaux de connexion à la recherche d'un risque de connexion corrélé (emplacements inhabituels, adresses IP anonymes, déplacements atypiques).
2. Vérifier si le mot de passe a déjà été changé après la détection de la fuite ; si c'est le cas, le risque a peut-être déjà été auto-corrigé.
3. Bloquer l'accès si un attaquant est actif — bloquez l'utilisateur, réinitialisez le mot de passe, et révoquez tous les refresh tokens lorsque les journaux montrent un accès non autorisé.
4. Rechercher un mouvement latéral — élévation de privilèges, nouvelles inscriptions d'applications, modifications de règles de boîte aux lettres, accès à des ressources sensibles.
5. Vérifier les comptes liés — si l'utilisateur réutilise ses mots de passe, considérez que l'identifiant est compromis au-delà de votre tenant.

3. Faire en sorte que « confirmer compromis » déclenche le confinement

Confirmer une compromission fixe le niveau de risque à élevé et alimente les modèles de Microsoft, mais Microsoft liste les actions de confinement séparément : demander un changement de mot de passe, bloquer l'utilisateur si l'attaquant peut réinitialiser le mot de passe ou effectuer le MFA, révoquer les refresh tokens, désactiver tout appareil considéré comme compromis, et révoquer tous les jetons d'accès (access tokens) si vous utilisez l'évaluation continue de l'accès (continuous access evaluation).

Automatisez l'étiquetage afin que le temps humain soit consacré au confinement :

POST https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/confirmCompromised
Content-Type: application/json

{
  "userIds": [
    "29f270bb-4d23-4f68-8a57-dc73dc0d4caf",
    "20f91ec9-d140-4d90-9cd9-f618587a1471"
  ]
}

Cette action nécessite IdentityRiskyUser.ReadWrite.All, avec Security Administrator comme rôle pris en charge le moins privilégié, et retourne 204 No Content en cas de succès.

4. Automatiser le régime permanent avec l'accès conditionnel

La résorption manuelle ne passe pas à l'échelle. Deux stratégies d'accès conditionnel basées sur le risque permettent de maintenir la file proche de zéro, et Microsoft est explicite sur le fait qu'elles doivent rester séparées — « ne combinez pas les conditions de risque de connexion et de risque utilisateur dans la même stratégie d'accès conditionnel ».

• Stratégie de risque utilisateur : sélectionnez Require risk remediation lorsque le risque utilisateur est High. Ce choix applique automatiquement Require authentication strength comme contrôle d'octroi et Sign-in frequency – Every time comme contrôle de session.
• Stratégie de risque de connexion : exigez l'authentification multifacteur lorsque le risque de connexion est Medium ou High, avec la fréquence de connexion réglée sur every time.

Excluez les comptes d'accès d'urgence et les principaux de service (service principals), démarrez en mode rapport seul (report-only), et confirmez l'impact avant de basculer sur On. Le guide de configuration complet se trouve dans Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués — et le mode rapport seul est une étape de déploiement, pas une destination, un piège traité dans Accès conditionnel mode rapport seul, exclusions obsolètes : ce que « appliqué » veut vraiment dire. Établissez d'abord correctement la liste d'exclusions, en suivant les recommandations de Comptes d'Accès d'Urgence Break Glass Entra ID : Absents, Non Surveillés, Non Exclus, et vérifiez l'ensemble de stratégies dans sa globalité par rapport à Failles acces conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition.

5. Corriger les prérequis qui bloquent l'auto-correction

• Vérifiez que les utilisateurs sont inscrits au MFA avant la mise en production de la stratégie ; les utilisateurs non inscrits sont bloqués plutôt que corrigés. Le taux d'inscription ne raconte que la moitié de l'histoire — voir Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas.
• Pour les identités hybrides, activez la synchronisation de hachage de mot de passe et activez Allow on-premises password change to reset user risk sous Protection > Identity Protection > Settings. Microsoft précise que ce paramètre est optionnel (opt-in) et recommande de sécuriser le processus de changement de mot de passe on-premises — par exemple en exigeant le MFA avant un changement on-premises.

6. Diriger les notifications vers quelqu'un qui les lit

Vérifiez que les destinataires de l'alerte Users at risk detected disposent d'un Email ou Alternate email valide, ne dépendent pas de rôles assignés via des groupes, et tiennent compte du timing d'élévation PIM. Envisagez d'abaisser le seuil d'alerte en dessous du niveau High par défaut si votre équipe en a la capacité, et activez le digest hebdomadaire pour la visibilité des tendances.

7. Migrer hors des stratégies de risque héritées

Si l'application du risque repose encore sur les stratégies héritées d'ID Protection plutôt que sur l'accès conditionnel, migrez avant le 1er octobre 2026 : construisez les stratégies d'accès conditionnel équivalentes en mode rapport seul, validez-les, activez-les, puis désactivez les anciennes stratégies sous ID Protection > Dashboard.

Comment EtcSec détecte cela

EtcSec audite le chemin de réponse, pas seulement la couche de détection.

Les contrôles Risk Protection signalent RISK_LEAKED_CREDENTIALS (Leaked Credentials Not Blocked) lorsque des comptes présentant des identifiants confirmés compromis sont toujours actifs et non bloqués, et RISK_USERS_NOT_REMEDIATED (Risky Users Not Remediated) lorsque des comptes signalés comme à risque n'ont jamais été corrigés ni rejetés. Les deux sont classés Critique, car les deux décrivent un compte qu'un attaquant peut actuellement utiliser.

À leurs côtés, RISK_HIGH_RISK_USERS_ACTIVE fait remonter les utilisateurs à risque élevé dont les comptes restent activés, RISK_SIGNINS_NOT_INVESTIGATED détecte les connexions à risque sans suivi, et RISK_NO_AUTOMATED_RESPONSE identifie les tenants où le risque est visible mais où aucun confinement automatisé n'existe.

Pour la revue de tenant plus large dans laquelle s'inscrivent ces contrôles, voir Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique. Pour les détections côté connexion qui alimentent le risque utilisateur, voir Entra ID AiTM Token Replay : Détection des Déplacements Impossibles et Fatigue MFA et Password Spraying : détection et prévention dans Active Directory et Entra ID.

Références principales

• What are risk detections? — Microsoft Entra ID Protection
• Risk detection types and levels
• Remediate risks and unblock users
• Investigate risk with Microsoft Entra ID Protection
• Risk policies — Microsoft Entra ID Protection
• Configure Microsoft Entra ID Protection notifications
• Export and use Microsoft Entra ID Protection data
• What is Microsoft Entra ID Protection?
• riskyUser resource type — Microsoft Graph v1.0
• riskyUser: confirmCompromised — Microsoft Graph v1.0
• List riskyUsers — Microsoft Graph v1.0
• Azure Monitor Logs reference — AADRiskyUsers
• Azure Monitor Logs reference — AADUserRiskEvents