Triage AD badPwdCount : qualifier les compteurs avant un verdict d'attaque

Ce que le triage AD badPwdCount permet d'établir

Le triage AD badPwdCount commence par une question sur les preuves : quel contrôleur de domaine a fourni le compteur de ce compte, à quel moment, et la collecte a-t-elle réellement réussi ? Un instantané de l'annuaire peut repérer les comptes à examiner. À lui seul, il ne peut ni établir une attaque par dictionnaire, ni identifier la source des échecs, ni montrer qu'un mot de passe est faible.

Le résultat pratique est un dossier d'analyse qui relie l'état de l'annuaire à l'activité d'authentification. Conservez le constat initial, recueillez des vues comparables auprès des contrôleurs de domaine concernés, vérifiez l'état de verrouillage calculé et examinez les journaux du parcours d'authentification impliqué. Consignez ensuite si les preuves étayent une erreur utilisateur, une application qui réessaie avec un secret obsolète, une activité suspecte ou un cas non résolu.

Ce guide utilise des lectures défensives de l'annuaire et un exemple documenté de déverrouillage ciblé. Les commandes sont des adaptations illustratives destinées à un administrateur autorisé disposant du module PowerShell ActiveDirectory et des permissions appropriées. Elles n'ont pas été exécutées sur un domaine. Aucun test de password spraying ni de verrouillage délibéré n'a été effectué.

Ce que mesure réellement le compteur LDAP

La référence Microsoft des attributs de sécurité utilisateur décrit badPwdCount comme un attribut non répliqué, maintenu séparément sur chaque contrôleur de domaine. Il compte les tentatives de connexion avec un mauvais mot de passe dans la vue de ce contrôleur ; la référence indique aussi que zéro peut signifier une valeur inconnue. Elle recommande d'interroger chaque DC pour obtenir une vue à l'échelle du domaine, plutôt que de traiter une lecture unique comme le total du domaine.

La référence de schéma Bad-Pwd-Count précise que l'attribut est remis à zéro sur un DC donné lorsque l'utilisateur se connecte avec succès à ce DC. Un compteur n'est donc pas un historique permanent. Une valeur plus basse dans un instantané ultérieur ne prouve pas que tous les échecs antérieurs ont été examinés.

Pour le triage, conservez les observations distinctes de chaque DC avant de produire une synthèse. Un nombre sans son serveur et son heure de collecte perd le contexte nécessaire à la comparaison avec une autre observation. Une synthèse des compteurs n'identifie pas non plus les tentatives distinctes dans un intervalle choisi ; utilisez les événements pour construire cette chronologie.

Le verrouillage est une question distincte. Microsoft documente UF_LOCKOUT, de valeur 0x0010, dans msDS-User-Account-Control-Computed. Demandez explicitement cet attribut calculé lorsque vous examinez l'état actuel d'AD DS. Ne supposez pas qu'un booléen du collecteur nommé LockedOut en provient nécessairement.

Détection : recueillir des vues comparables sur chaque DC

Identifier le compte et le périmètre de collecte

Partez de l'identifiant du compte associé au constat et du point de connexion initial du collecteur. Consignez le domaine, le DN ou GUID du compte, la version du collecteur, l'heure de collecte, les attributs demandés et les éventuelles erreurs de collecte. Vérifiez la liste des DC par rapport à l'inventaire du domaine ; l'exemple à deux serveurs ci-dessous ne demande pas d'omettre les autres DC.

La documentation de Get-ADUser permet de sélectionner un utilisateur par son DN, de demander des propriétés supplémentaires et de spécifier un serveur d'annuaire. Ces lectures adaptées utilisent un nom d'hôte de DC explicite au lieu de s'appuyer sur la sélection automatique du serveur :

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc02.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Remplacez le DN et les noms d'hôte illustratifs par des valeurs vérifiées. Demander lockoutTime conserve un autre attribut brut pour l'analyse ; n'utilisez pas sa seule valeur non nulle pour conclure à un verrouillage actuel. Interprétez le bit de verrouillage calculé uniquement lorsque sa valeur a été retournée avec succès. Une valeur manquante est inconnue, pas fausse.

Pour un inventaire plus large et autorisé, Get-ADUser accepte aussi un filtre LDAP. Cet exemple récupère les objets utilisateur activés et les attributs pertinents sur un serveur explicitement sélectionné. Il ne limite volontairement pas la population aux comptes déjà au-dessus du seuil du produit :

Get-ADUser -LDAPFilter '(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Répétez la lecture sur les autres DC vérifiés du périmètre approuvé. Évitez de construire un filtre LDAP en concaténant un nom de compte non échappé. Pour un cas individuel, les lectures fondées sur l'identité évitent entièrement cette interpolation.

Conserver la qualité de collecte avec les valeurs

Utilisez un relevé comportant une ligne par compte et par DC. Les champs suivants sont une recommandation opérationnelle, pas des données automatiquement fournies par le détecteur :

Si un DC est indisponible, signalez la lacune et conservez les lectures réussies. Ne remplacez pas la ligne manquante par zéro et ne réduisez pas silencieusement le périmètre déclaré. Si les observations diffèrent, conservez les deux et examinez leur chronologie et leur provenance avant de choisir une synthèse. L'objectif est une comparaison auditable, pas de rendre toutes les cellules identiques.

Détection : rapprocher les événements du parcours d'authentification

L'instantané LDAP désigne une cible d'investigation ; la chronologie des événements fournit le contexte d'activité. Vérifiez la couverture d'audit, la transmission, la rétention et les systèmes interrogés avant d'interpréter un résultat vide. Choisissez l'intervalle d'analyse à partir de la chronologie du cas et des preuves disponibles. Le compteur lui-même ne fournit pas cet intervalle.

Microsoft associe ces événements respectivement à Audit Logon/Account Lockout, Audit Kerberos Authentication Service et Audit Credential Validation. Une recherche limitée aux DC ne couvre pas tous les emplacements de 4625. L'événement 4771 est absent pour les comptes configurés sans exigence de préauthentification Kerberos. L'événement 4776 couvre les validations réussies et échouées, et identifie le poste source plutôt que le serveur de destination ou une adresse IP.

Lisez la nomenclature des codes propre à chaque événement. Pour 4625, conservez les deux champs d'état au lieu de les réduire à une étiquette d'échec générique. Dans 4771, 0x18 signifie des informations de préauthentification invalides, un mauvais mot de passe étant une cause documentée. Dans 4776, 0xC000006A désigne un mot de passe incorrect ou mal saisi, 0xC0000064 un nom d'utilisateur inconnu et 0xC0000234 un compte verrouillé. Un échec provoqué par le verrouillage constitue une preuve différente de l'activité de mauvais mots de passe qui l'a précédé.

Construisez une chronologie regroupée par compte, source, parcours d'authentification et système émetteur. Conservez les références aux enregistrements originaux pour qu'un autre analyste puisse examiner la conclusion. N'additionnez pas toutes les lignes de différents types d'événements pour annoncer un nombre de tentatives indépendantes : déterminez d'abord quels enregistrements décrivent le même flux d'authentification.

Élargissez l'analyse au-delà du compte sélectionné lorsque les sources ou la chronologie le justifient. Le contexte de corrélation multicomptes et à faible cadence de notre guide du password spraying explique cette investigation plus large. Ici, la première tâche reste de qualifier l'observation de l'annuaire à l'origine du cas.

Remédiation : résoudre la cause avant de clore le constat (Remediation)

Préserver les preuves et tester les explications concurrentes

Conservez les valeurs LDAP initiales et les événements pertinents avant de modifier les identifiants ou l'état du compte. Identifiez le propriétaire du compte et les applications qui l'utilisent. Renseignez-vous sur les changements récents de mot de passe, les modifications de configuration des services, les tâches planifiées, les accès distants et l'expérience rapportée par l'utilisateur. Utilisez ces réponses pour choisir les systèmes à inspecter, pas pour remplacer leurs journaux.

La matrice de décision suivante propose une méthode de triage. Aucune de ces explications n'est calculée à partir du seul badPwdCount :

Pour une charge de travail utilisant un identifiant obsolète, coordonnez le changement avec tous les consommateurs connus. Mettre à jour une seule tâche planifiée tout en laissant un autre client réessayer sans résolution ne constitue pas une correction complète. Vérifiez la configuration propre de la charge de travail et ses événements d'authentification ultérieurs avant de lui attribuer définitivement les échecs.

Traitez les noms inhabituels comme un signal distinct. Notre analyse des noms de comptes distingue un indicateur de nommage statique de l'activité de connexion. Un nom de compte générique ne permet pas d'établir quel mot de passe a été tenté, qui l'a soumis ni si ce cas est malveillant.

Déverrouiller uniquement le compte examiné lorsque c'est approprié

Si l'état calculé confirme le verrouillage et que l'administrateur responsable a approuvé le rétablissement de l'accès après examen de la cause, utilisez une opération ciblée. Cet exemple adapte les paramètres d'identité et de serveur documentés pour Unlock-ADAccount :

Unlock-ADAccount -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Il s'agit d'un exemple qui modifie l'état, pas d'une commande exécutée pour cet article. Confirmez l'identité et le serveur avant utilisation. N'envoyez pas l'inventaire complet dans un pipeline de déverrouillage en masse. Un déverrouillage ne corrige pas un secret applicatif obsolète et ne résout pas une activité suspecte ; appuyez-vous sur les preuves pour choisir la réponse adaptée.

Lorsque l'investigation établit une compromission ou une menace persistante, suivez la procédure de réponse à incident de l'organisation pour le confinement, les changements d'identifiants et les systèmes concernés. Un compteur d'annuaire ne suffit pas à choisir automatiquement ces actions. De même, n'assouplissez pas les contrôles de verrouillage uniquement pour réduire les constats sans examiner les conséquences sur la sécurité et la disponibilité.

Vérifier la correction et documenter la conclusion

Après le changement approuvé, répétez les mêmes lectures de l'annuaire avec la même identité de compte et les mêmes DC explicites. Conservez de nouveau les horodatages et la qualité de collecte. Examinez les journaux pertinents sur une période d'observation déclarée et faites confirmer par le responsable que l'application ou le parcours utilisateur concerné fonctionne comme prévu.

Clôturez le cas avec une affirmation étayée : une application identifiée qui réessayait a été corrigée ; un problème d'accès utilisateur a été résolu ; une activité a été escaladée comme suspecte ; ou la couverture reste incomplète. Consignez les références des événements à l'appui, les explications écartées, les preuves manquantes, les actions, le responsable et la date de suivi. Le retour sous le seuil du produit fournit un contexte utile, mais la clôture doit expliquer la cause et les preuves motivant la décision.

Comment EtcSec détecte ce cas

Le contrôle d'etc-collector est PASSWORD_DICT_ATTACK_RISK, de catégorie Password et de sévérité Medium. Le Detect() examiné se trouve dans public/internal/audit/detectors/ad/password/dict-attack-risk.go:24. Il exclut les utilisateurs avec Disabled=true et sélectionne chaque utilisateur restant lorsque BadPasswordCount > 3 ou LockedOut=true.

Count est le nombre d'utilisateurs sélectionnés, pas la somme des tentatives échouées, le nombre de systèmes sources ni le nombre d'attaques. Chaque utilisateur compte une seule fois, même lorsque les deux conditions sont remplies. L'implémentation retourne le constat même à zéro ; les entités affectées sont incluses lorsque les détails sont demandés et qu'au moins un utilisateur est sélectionné.

Le fournisseur de données détermine ce que le contrôle peut réellement voir :

• parser.go:164 lit badPwdCount via getIntAttr ; cette fonction auxiliaire, à la ligne 290, retourne zéro pour une valeur absente et ignore les erreurs de strconv.Atoi.
• client.go:460 récupère les utilisateurs dans le contexte LDAP choisi. Ce parcours n'agrège pas les observations de tous les DC.
• parser.go:189 déduit LockedOut du bit 0x0010 de userAccountControl. La liste par défaut des attributs utilisateur ne demande pas msDS-User-Account-Control-Computed. Bien que lockoutTime soit collecté, il n'est pas utilisé pour calculer ce booléen.

Cette branche de verrouillage ne doit donc pas être présentée comme une évaluation calculée fiable du verrouillage actuel pour AD DS moderne. Demandez indépendamment l'attribut calculé pendant le triage du constat. Conservez tout désaccord entre le booléen du collecteur et cette lecture plutôt que de traiter l'étiquette du collecteur comme une autorité.

Le contrôle n'a ni fenêtre temporelle, ni source d'authentification, ni corrélation d'événements, ni évaluation de la stratégie effective de verrouillage, ni mesure de qualité du mot de passe. Le seuil est un prédicat du produit, pas une valeur de stratégie AD DS. Trois échecs enregistrés ou moins ne prouvent pas l'absence de risque, et un décompte positif ne prouve pas une attaque.

Il existe une raison concrète d'examiner les compteurs sans présumer leur cause. Le dépôt public SafeSpray et son code source main.go utilisent un filtre LDAP contenant badPwdCount=0 pour sélectionner les utilisateurs avant des tentatives d'authentification SMB. Cela montre comment un outil public utilise les compteurs, pas qu'il a été exécuté dans votre environnement ni que sa promesse d'éviter les verrouillages est fiable. Le code a été lu ; l'outil n'a pas été exécuté.