Détection de Rafale d'Échecs de Connexion Entra ID

Détection de Rafale d'Échecs de Connexion Entra ID : Ce Que C'est

La détection de rafale d'échecs de connexion Entra ID reste une couverture volontairement limitée : Microsoft Entra ID Identity Protection n'expédie aucune détection de risque native conçue pour repérer une rafale d'échecs de connexion visant un même compte, alors même que le signal brut — des dizaines de tentatives de mot de passe invalide contre un même compte en peu de temps — se trouve directement dans vos journaux de connexion. Cet article explique pourquoi les propres détections d'Identity Protection ne se déclenchent pas sur une simple série d'échecs, et comment combler cette lacune avec une requête KQL, un réglage de Smart Lockout, et une alerte qui notifie avant la dixième tentative, pas après la première réussie.

Un mot de passe erroné contre Entra ID atterrit dans SigninLogs avec le code d'erreur AADSTS50126, et la documentation même de Microsoft pour ce code est sans détour sur la raison pour laquelle une occurrence isolée ne signifie rien : InvalidUserNameOrPassword — « Erreur de validation des identifiants due à un nom d'utilisateur ou un mot de passe invalide. L'utilisateur n'a pas saisi les bons identifiants. Attendez-vous à voir un certain nombre de ces erreurs dans vos journaux en raison d'erreurs de saisie des utilisateurs. » Ce n'est pas le seul code d'échec d'identifiants documenté par Microsoft — AADSTS50056 signifie « Mot de passe invalide ou nul : le mot de passe n'existe pas dans l'annuaire pour cet utilisateur » — et une détection qui ne surveille que l'un des deux ne voit qu'une partie de la rafale. Une faute de frappe, c'est du bruit. Vingt occurrences contre le même compte en cinq minutes, ou le même mot de passe deviné sur cinquante comptes en cinq minutes, ça ne l'est pas : c'est du brute force ciblé dans le premier cas et du password spraying dans le second, et les deux schémas se traduisent par le même signal brut : une rafale de 50126.

Cette distinction compte pour ce vers quoi cet article renvoie. Si vous cherchez le mode opératoire de l'attaquant — énumération des cibles, listes de mots de passe courants, pourquoi le spraying évite les verrouillages par compte — c'est Password Spraying : Détection et Prévention pour Active Directory et Entra ID. Cet article est l'autre moitié : l'ingénierie de détection sur télémétrie brute qui doit exister parce que le moteur de risque d'Identity Protection laisse ce signal précis sans le signaler.

Pourquoi Identity Protection Ne le Signale Pas

Microsoft documente chaque détection de risque de connexion et d'utilisateur qu'Identity Protection propose, et aucune n'est « échecs de connexion répétés contre un même compte ». Les candidats les plus proches manquent tous ce signal pour une raison précise et documentée :

Détection	Pourquoi une rafale d'échecs pure ne la déclenche pas
Password spray	« La détection de risque ne se déclenche que lorsqu'un attaquant valide avec succès le mot de passe d'un utilisateur. Les tentatives de spraying infructueuses contre vos utilisateurs ne génèrent aucune détection. » Une campagne qui ne devine jamais juste — le cas courant face à une politique de mot de passe correcte — produit zéro événement de risque.
Adresse IP malveillante	Ce qui se rapproche le plus d'un signal de volume d'échecs, mais c'est un verdict sur l'IP, pas sur le compte visé. Microsoft le calcule hors ligne, « en se basant sur des taux d'échec élevés dus à des identifiants invalides reçus depuis l'adresse IP ou d'autres sources de réputation IP », et note que « dans certains cas, cette détection se déclenche sur une activité malveillante antérieure ». Aucun seuil n'est publié et aucun n'est réglable par vous, donc rien de fiable pour un compte spécifique sous attaque.
Déplacement atypique / Déplacement impossible / Propriétés de connexion non familières	Ces trois détections évaluent les propriétés de l'activité de connexion par rapport à un historique appris. Déplacement atypique et Déplacement impossible ont chacun besoin de « deux connexions provenant de lieux géographiquement distants » ; Propriétés de connexion non familières se déclenche quand une connexion présente des propriétés inconnues de l'utilisateur — « IP, ASN, lieu, appareil, navigateur, et sous-réseau IP du tenant ». Aucune des trois ne compte les échecs, donc un attaquant qui devine des mots de passe depuis une IP et un navigateur déjà vus par le tenant ne leur laisse rien d'anormal à évaluer.
Identifiants divulgués	Ne se déclenche que sur une correspondance confirmée avec le pipeline de scan du corpus de fuites de Microsoft. Cela ne dit rien de la télémétrie d'échecs en direct dans vos propres journaux.

Le résultat pratique : une campagne de brute force ciblée ou une vague de spraying infructueuse peut se dérouler entièrement dans SigninLogs — visible, horodatée, attribuable à une IP et à un ensemble de comptes — sans jamais toucher RiskState, RiskLevelAggregated, ou la moindre ligne dans le rapport des utilisateurs à risque. Si votre surveillance s'arrête au tableau de bord d'Identity Protection, ce schéma est invisible jusqu'à ce qu'il réussisse.

Détection : Construisez la Requête Vous-Même

Puisqu'aucun riskEventType n'existe pour ce schéma, la détection doit être construite directement contre SigninLogs, la table Log Analytics dans laquelle les événements de connexion Entra ID sont diffusés une fois l'export de diagnostic activé. Les colonnes qui comptent :

Colonne	Ce qu'elle contient
`ResultType`	« Fournit le code d'erreur à 5-6 chiffres généré lors d'un événement de connexion. 0 indique un succès ; toute autre valeur est un échec. »
`ResultDescription`	« Fournit le message d'erreur ou la raison de l'échec pour l'activité de connexion correspondante. »
`UserPrincipalName`	L'UPN de l'utilisateur.
`IPAddress`	L'adresse IP du client depuis laquelle la connexion a eu lieu.
`TimeGenerated`	Horodatage de l'événement, UTC.

Avant de choisir un seuil, établissez la ligne de base de votre propre tenant. Les exemples de requêtes SigninLogs publiés par Microsoft incluent un point de départ pour cela — « Failed Signin reasons » — adapté ici pour isoler les codes d'échec d'identifiants qui comptent :

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType in ("50126", "50056", "50053")
| summarize Count = count() by ResultType, ResultDescription
| order by Count desc

Lancez-la d'abord. Si le bruit ordinaire de 50126 dû aux fautes de frappe se compte déjà par centaines par jour, un seuil de rafale à un chiffre déclenchera des alertes pour rien. Une fois la ligne de base en main, deux requêtes couvrent les deux variantes de la même lacune du catalogue — brute force ciblé contre une identité, et spraying lent et discret sur plusieurs :

Rafale contre un compte unique :

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            SourceIPs = dcount(IPAddress),
            LastFailure = max(TimeGenerated)
    by UserPrincipalName, bin(TimeGenerated, 15m)
| where FailureCount >= 10
| order by FailureCount desc

Rafale répartie sur plusieurs comptes depuis une seule source :

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            TargetedAccounts = dcount(UserPrincipalName),
            Accounts = make_set(UserPrincipalName, 20)
    by IPAddress, bin(TimeGenerated, 15m)
| where FailureCount >= 10 or TargetedAccounts >= 5
| order by FailureCount desc

Les deux requêtes n'utilisent que des colonnes SigninLogs documentées ; les seuils 10 et 5 sont des points de départ illustratifs, pas des valeurs par défaut Microsoft — dimensionnez-les selon la ligne de base ci-dessus, puis resserrez à mesure que les faux positifs diminuent. Connectez l'une ou l'autre requête à une règle analytique planifiée Microsoft Sentinel (ou une alerte de log Azure Monitor classique si vous n'utilisez pas Sentinel) pour qu'une rafale déclenche un incident au lieu d'attendre d'être découverte lors d'une revue manuelle des journaux.

Remediation / Remédiation

1. Resserrez Smart Lockout au lieu de supposer que la valeur par défaut suffit

Smart Lockout est activé pour chaque tenant, mais ses valeurs par défaut sont réglées pour l'utilisabilité générale, pas pour la détection :

Le seuil de verrouillage par défaut est de 10 tentatives échouées (tenants Azure Public ; 3 pour Azure US Government), après quoi le compte se verrouille pour 60 secondes initiales, en augmentant à chaque verrouillage répété.
Smart Lockout « utilise l'emplacement familier par rapport à l'emplacement non familier pour distinguer un acteur malveillant de l'utilisateur légitime », et « les emplacements familiers et non familiers ont chacun des compteurs de verrouillage séparés » — donc un attaquant qui se connecte depuis un emplacement que l'utilisateur réel n'a jamais utilisé épuise son propre compteur, suivi indépendamment des propres erreurs de l'utilisateur.
Smart Lockout « garde en mémoire les trois derniers hachages de mot de passe erronés pour éviter d'incrémenter le compteur de verrouillage pour le même mot de passe ». Un spraying qui rejoue un même mot de passe courant contre un compte ne le rapproche donc jamais du verrouillage — ce qui est précisément le cas que votre propre requête doit intercepter. Microsoft note que ce suivi des hachages « n'est pas disponible pour les clients utilisant l'authentification directe (pass-through) ».
Personnaliser le seuil et la durée en dessous de la valeur par défaut nécessite Microsoft Entra ID P1 ou supérieur, à configurer sous Entra ID > Méthodes d'authentification > Protection par mot de passe.

Un seuil plus bas échange un peu de friction utilisateur contre l'arrêt d'une campagne de brute force bien avant la fermeture de votre fenêtre de détection de 15 minutes. Coordonnez ce changement avec toute politique de verrouillage AD DS hybride. Pour l'authentification directe (pass-through authentication), Microsoft est explicite : le seuil de verrouillage Entra « doit être inférieur au seuil de verrouillage de compte AD DS », réglé « de sorte que le seuil de verrouillage de compte AD DS soit au moins deux à trois fois supérieur au seuil de verrouillage Microsoft Entra » — le verrouillage cloud absorbe alors l'attaque avant qu'elle n'atteigne l'infrastructure sur site.

2. Transformez la requête KQL en alerte permanente

Une requête qui ne s'exécute que lorsque quelqu'un se souvient de la coller dans Log Analytics n'est pas une détection. Enregistrez-la comme règle analytique planifiée Microsoft Sentinel (ou une alerte de log Azure Monitor) sur un cycle de 15 minutes correspondant à la fenêtre bin(), et acheminez-la vers qui possède les incidents d'identité. C'est le contrôle qui comble réellement la lacune du catalogue — Identity Protection reste silencieux sur une rafale d'échecs pure, donc rien d'autre ne vous alertera.

3. Superposez une politique d'Accès Conditionnel basée sur le risque de connexion pour les cas qui aboutissent

Rien de tout cela ne remplace l'Accès Conditionnel basé sur le risque — cela le complète. Si une rafale finit par produire une tentative réussie, une politique de risque de connexion est ce qui empêche cette session de faire quoi que ce soit. Le guide complet pour en construire une se trouve dans Azure Identity Protection : Bloquer les Identifiants Divulgués ; si votre base d'Accès Conditionnel a d'autres lacunes au-delà du risque de connexion, vérifiez-la avec Failles d'Accès Conditionnel Azure : Contournement MFA.

4. Activez l'export des journaux de connexion avant d'en avoir besoin

SigninLogs ne se remplit qu'une fois l'export de diagnostic vers Log Analytics activé — comme tout flux Azure Monitor, il capture les événements à venir, pas rétroactivement. Activez cet export sous Entra ID > Surveillance et intégrité > Paramètres de diagnostic dès maintenant, pour que l'historique soit disponible la prochaine fois que vous devrez exécuter ces requêtes contre un incident déjà vieux d'une semaine.

Comment EtcSec Détecte Ceci

Les contrôles Risk Protection d'EtcSec incluent exactement cette corrélation de télémétrie brute — suivie en interne sous RISK_FAILED_SIGNIN_BURST, classée critique et mappée sur MITRE ATT&CK T1110.003 — parce que le propre moteur de risque d'Identity Protection, comme documenté ci-dessus, n'a aucune détection liée au volume d'échecs contre un compte unique. Le contrôle exécute les deux mêmes formes que les requêtes ci-dessus, sur une fenêtre fixe de 10 minutes : plus de 50 échecs d'identifiants contre un utilisateur, ou plus de 50 depuis une IP à travers plus de 10 utilisateurs distincts. Ce sont des seuils d'audit, réglés assez haut pour qu'une découverte soit un incident plutôt qu'un point de départ — ce qui explique précisément pourquoi le KQL ci-dessus commence plus bas et vous demande d'établir une ligne de base d'abord. Il se place aux côtés des contrôles qui auditent ce qui se passe une fois qu'Identity Protection lève effectivement un signal : RISK_SIGNINS_NOT_INVESTIGATED (connexions à risque sans suivi) et RISK_NO_AUTOMATED_RESPONSE (risque visible, aucune réponse automatisée configurée), et il alimente directement la question de savoir si CA_NO_RISK_BASED_SIGNIN (aucune politique d'Accès Conditionnel basée sur le risque de connexion) compte dans votre environnement.

Pour les détecteurs frères de la même famille de télémétrie brute, voir Détection d'Anomalie de Connexion Service Principal Entra , Entra ID AiTM Token Replay, Détection des Déplacements Impossibles et MFA Fatigue : Détection et Prévention dans Microsoft Entra ID. Pour la lacune côté réponse une fois qu'Identity Protection se déclenche effectivement, voir Entra ID Risk Protection : Identifiants Divulgués, Utilisateurs à Risque Non Corrigés.

Détection de Rafale d'Échecs de Connexion Entra ID : Pourquoi Identity Protection Ne la Détecte Pas