Motifs de noms de comptes Active Directory

Ce que signalent réellement les noms de comptes courants

L’expression motifs de noms de comptes active directory décrit une heuristique de nommage, pas un test de mot de passe. Un compte activé nommé admin, test ou temp mérite un examen de son propriétaire et de son exposition. Son nom ne révèle pas son mot de passe, ne prouve pas que celui-ci est faible et n’établit pas qu’il a été attaqué. Cette distinction découle directement de l’implémentation de PASSWORD_COMMON_PATTERNS dans public/internal/audit/detectors/ad/password/common-patterns.go:26.

Un nom générique peut faciliter l’inclusion d’une identité dans une liste de cibles supposées. Il s’agit d’une déduction sur la sélection des candidats, pas d’un classement mesuré des premiers choix des attaquants. L’ancienne référence Microsoft sur le renommage d’Administrator décrit un bénéfice modeste à changer ce nom bien connu, tout en rappelant la limite liée à son SID connu. Elle ne valide ni un classement universel de admin, test et temp, ni les quinze motifs du collecteur.

La question utile est donc : que fait cette identité, qui en est responsable et quels contrôles protègent ses chemins d’authentification réels ? Traitez le résultat comme une file de comptes à examiner. Un nom de service descriptif peut soutenir des opérations légitimes ; un nom d’apparence personnelle peut malgré tout masquer une mauvaise gestion des identifiants. Le détecteur ne distingue pas ces cas, car il examine les noms plutôt que les secrets ou l’activité.

Comment fonctionne le password spraying

Le guide Microsoft de classification du password spraying décrit l’essai d’un petit ensemble de mots de passe couramment utilisés sur de nombreux comptes. Cela diffère des essais répétés de nombreux mots de passe contre une seule identité. Le nommage concerne la liste des cibles ; le password spraying concerne les tentatives d’authentification. Un inventaire de noms correspondants établit le premier élément, pas le second.

Le guide opérationnel d’investigation du password spraying distingue également la compromission du mot de passe de celle du compte. Un attaquant peut découvrir un mot de passe correct alors que la MFA empêche l’accès. Les enquêteurs doivent examiner les authentifications réussies et interrompues, les résultats de MFA et l’activité ultérieure, plutôt que de considérer chaque échec de connexion finale comme la preuve que le mot de passe est resté inconnu.

La chaîne d’attaque à examiner

Une investigation défendable suit la progression documentée dans ces guides Microsoft : identifier les comptes candidats et les chemins d’authentification, corréler les tentatives suspectes, déterminer si un mot de passe a été accepté et examiner les accès qui en résultent. Les noms génériques peuvent éclairer la première étape. Ils ne fournissent aucune preuve pour les suivantes. Une activité lente et peu intense peut rester sous les seuils de verrouillage ; l’absence de verrouillage ne permet donc pas d’écarter automatiquement la piste.

Pour le mécanisme global, l’énumération des noms d’utilisateur, la détection et les contrôles dans les deux environnements, consultez notre guide du password spraying dans Active Directory et Entra ID. Cet article se concentre sur le prédicat exact de nommage, les hypothèses erronées qui l’entourent et les preuves nécessaires pour résoudre un résultat de nommage.

Aucune liste de noms ne couvre toutes les cibles de password spraying. Examinez des identités hors de ces motifs lorsque la télémétrie d’authentification le justifie. Inversement, ne qualifiez pas chaque compte correspondant de compromis : le processus de classification Microsoft demande explicitement de distinguer l’activité malveillante des faux positifs.

Mesurer les comptes et leur politique effective

1. Construire un inventaire sans collecter de secrets

Les commandes suivantes sont des exemples documentés ou des adaptations de paramètres destinées à un administrateur autorisé. Elles n’ont pas été exécutées contre un domaine pour cet article. Utilisez le module ActiveDirectory, les autorisations d’annuaire appropriées et le contexte de domaine ou de serveur voulu. contoso.com et les noms de comptes sont illustratifs ; vérifiez la cible avant d’utiliser une commande de modification.

Get-ADUser documente le filtrage, la récupération des comptes activés et la demande de propriétés supplémentaires. Ce filtre défensif adapte ces capacités aux treize noms complets, à la sous-chaîne et au suffixe du collecteur. La liste provient du détecteur, pas d’un exemple Microsoft présentant ces noms comme une preuve de mot de passe faible.

Get-ADUser -Filter 'Enabled -eq $true -and (SamAccountName -eq "admin" -or SamAccountName -eq "administrator" -or SamAccountName -eq "test" -or SamAccountName -eq "user" -or SamAccountName -eq "guest" -or SamAccountName -eq "temp" -or SamAccountName -eq "default" -or SamAccountName -eq "support" -or SamAccountName -eq "service" -or SamAccountName -eq "backup" -or SamAccountName -eq "demo" -or SamAccountName -eq "sa" -or SamAccountName -eq "dba" -or SamAccountName -like "*password*" -or SamAccountName -like "*123")' -Properties DisplayName,Enabled

DisplayName facilite ici l’examen humain. Il ne participe pas au détecteur. Un compte dont le nom d’affichage est Test mais dont le sAMAccountName est alex.smith n’est pas sélectionné par le motif test. À l’inverse, User123 correspond au suffixe, bien qu’il ne corresponde pas à l’expression de nom complet user. Ces exemples découlent des règles de correspondance du code.

Consignez le propriétaire, la fonction du compte, ses dépendances et la décision d’examen avec l’inventaire. Avant de comparer un nombre de résultats locaux à celui du collecteur, rapprochez le périmètre d’annuaire, l’heure de collecte, l’état activé et le comportement de correspondance. Ne supposez pas que la courte liste de noms d’un résultat représente toute sa population.

2. Lire la politique du domaine

Cette commande adapte l’exemple 3 de Get-ADDefaultDomainPasswordPolicy à un domaine illustratif :

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com

Examinez MinPasswordLength, ComplexityEnabled, PasswordHistoryCount, LockoutThreshold, LockoutDuration et LockoutObservationWindow. Ce sont des preuves de politique. Le nom du compte ne fournit aucune valeur pour ces paramètres. Lire la politique du domaine ne permet pas non plus de savoir si un utilisateur sélectionné possède un Password Settings Object résultant différent.

3. Inventorier les politiques affinées

Utilisez le filtrage documenté par Get-ADFineGrainedPasswordPolicy pour récupérer les objets de politique :

Get-ADFineGrainedPasswordPolicy -Filter *

Inspectez AppliesTo et Precedence ainsi que les paramètres réels. Le guide Microsoft des politiques de mot de passe affinées indique que ces politiques s’appliquent aux objets utilisateur et aux groupes de sécurité globaux. Elles ne s’appliquent pas directement à une OU. Placer un compte générique dans une OU administrative ne suffit donc pas, en soi, à établir une politique de mot de passe effective plus forte.

4. Vérifier la politique résultante de l’utilisateur sélectionné

Cette commande adapte l’exemple d’identité de Get-ADUserResultantPasswordPolicy :

Get-ADUserResultantPasswordPolicy -Identity test

Cette cmdlet récupère le PSO résultant de l’utilisateur. Un PSO affecté directement à l’utilisateur est prioritaire sur les PSO hérités par les groupes de sécurité globaux. Si plusieurs PSO s’appliquent directement, celui dont la valeur de priorité est la plus basse l’emporte parmi eux ; les PSO liés aux groupes ne sont comparés que si aucun ne s’applique directement. Si aucun PSO ne s’applique, évaluez la politique par défaut du domaine. Un résultat PSO vide n’est pas une mesure de robustesse du mot de passe.

Notre guide de sécurité des mots de passe Active Directory examine six autres dimensions : les indicateurs d’expiration, la faiblesse des politiques, les indicateurs de mot de passe non requis, les secrets exposés dans les descriptions, WDigest et NTLMv1, ainsi que les FGPP et la gestion des comptes de service. Ces dimensions sont distinctes du prédicat de nommage. Ne remplacez pas l’examen de ces contrôles par la disparition d’un résultat de nommage et ne copiez pas des valeurs de politique de démonstration comme référence de sécurité.

Détection : corréler 4625, 4740 et 4771

Collecter les bons systèmes et champs

Construisez les preuves autour du chemin d’authentification. L’événement 4625 est enregistré sur l’ordinateur où se produit l’échec de connexion ; il peut s’agir d’un contrôleur de domaine, d’un serveur membre ou d’un poste de travail. Collecter un seul DC ne garantit pas la couverture de tous les échecs de connexion. Vérifiez la couverture Audit Logon et Audit Account Lockout selon les sous-catégories documentées de l’événement.

Pour les comptes de domaine, incluez les journaux Security des DC pour l’événement 4740, dans Audit User Account Management, et l’événement 4771, dans Audit Kerberos Authentication Service. Microsoft précise que 4771 apparaît uniquement sur les DC et est absent lorsque le compte ne requiert pas de préauthentification Kerberos.

Interpréter précisément les codes d’échec

La référence de surveillance de 4625 identifie 0xC000006A comme un mot de passe incorrect ou mal saisi, 0xC0000064 comme un nom de compte incorrect ou mal orthographié et 0xC000006D comme un nom d’utilisateur ou des informations d’authentification incorrects. Sa documentation identifie 0xC0000234 comme un compte verrouillé. Conservez Status et SubStatus ; ne réduisez pas l’investigation à une seule étiquette générale d’échec.

Pour 4771, 0x18 correspond à KDC_ERR_PREAUTH_FAILED : des informations de préauthentification invalides, avec un mot de passe incorrect documenté comme cause. 0x6 correspond à KDC_ERR_C_PRINCIPAL_UNKNOWN, signifiant que le client n’a pas été trouvé dans la base Kerberos. 0x12 correspond à KDC_ERR_CLIENT_REVOKED, signifiant que les informations d’identification du client ont été révoquées. N’assimilez pas automatiquement 0x12 au seul verrouillage et ne traitez pas ces codes comme interchangeables avec les champs d’état de 4625.

Ces distinctions aident à séparer les tentatives sur des noms inconnus, celles avec un mot de passe incorrect et les conséquences de verrouillage. Elles ne révèlent toujours pas le mot de passe candidat. Une règle de corrélation fondée sur ces événements ne peut pas prouver qu’un même secret a été soumis à chaque compte.

Corréler le comportement, puis tester l’explication

Une conception éditoriale de détection consiste à regrouper les échecs par fenêtre temporelle et par source, compter les comptes ciblés distincts et rapprocher ces identités de l’inventaire de nommage. Établissez une référence locale avant de choisir une fenêtre ou un seuil d’alerte. Il s’agit d’une conception à implémenter et valider, pas d’une requête Microsoft copiée ni d’un seuil mesuré pour votre parc.

Comparez le motif avec les erreurs utilisateur attendues et les services qui réessaient un ancien identifiant. Élargissez la recherche lorsque les sources varient, puis examinez les connexions réussies ou interrompues et les activités ultérieures inhabituelles. Les guides Microsoft de spraying soutiennent la corrélation de la chronologie, des sources, des comptes et des suites. Une campagne peut rester sous le seuil de verrouillage ; exiger 4740 laisserait donc une lacune de détection.

Dans un environnement hybride, incluez les enregistrements de connexion et de MFA Entra ainsi que les journaux du fournisseur d’identité fédéré, si applicable. Le guide d’investigation explique que l’emplacement des journaux dépend d’une authentification gérée ou fédérée. Un mot de passe accepté suivi d’un échec de MFA mérite une investigation, même sans accès final à l’application. Un rapport de noms de comptes sans anomalie ne résout pas cet incident.

Remédiation : résoudre la fonction, l’exposition et les contrôles (Remediation)

1. Examiner chaque identité avec son responsable

Utilisez une fiche d’examen pour distinguer les identités humaines, partagées, de test, de service, intégrées et de récupération. Cette classification est une recommandation opérationnelle, pas un calcul effectué par les regex. Demandez ce qui nécessite encore le compte, qui peut l’utiliser, quels chemins d’authentification l’acceptent et ce qui dépend de son nom ou de ses identifiants actuels.

Privilégiez les accès humains attribuables et documentez les exceptions, les responsables et les dates d’expiration des besoins temporaires. Examinez les privilèges séparément : support ne détermine pas les autorisations du support technique et backup ne détermine pas les ressources accessibles au compte. Le code de nommage n’a aucun prédicat d’appartenance aux groupes ou de privilèges.

Pour les tests, les consignes Microsoft sur les environnements de test Entra traitent de tenants dédiés ou de ressources et d’inscriptions d’applications correctement isolées. C’est une procédure pour les applications Entra, pas une recette de déploiement AD natif. Appliquer son principe d’isolation aux identités de test AD est une recommandation de gouvernance : définissez un périmètre de test et un cycle de vie adaptés à votre domaine.

2. Retirer les comptes inutiles après examen des dépendances

Pour un compte ordinaire confirmé inutile, vérifiez d’abord les services, tâches planifiées, applications et dispositions de récupération qui en dépendent avec son responsable. Planifiez ensuite une désactivation ciblée. Cette commande adapte l’exemple 1 de Disable-ADAccount à une identité de test illustrative déjà examinée :

Disable-ADAccount -Identity test

N’injectez pas l’inventaire de nommage dans une désactivation en masse. Le filtre ne permet pas de savoir si une identité est essentielle aux opérations. Un renommage planifié est une autre action administrative possible, après vérification des consommateurs du nom actuel. La commande suivante utilise les paramètres d’identité et SamAccountName documentés par Set-ADUser :

Set-ADUser -Identity test -SamAccountName app-validation

Cela change le nom de compte SAM. Cela ne change pas le mot de passe, ne réduit pas les autorisations, n’impose pas la MFA et ne prouve pas que le compte n’est plus découvrable. Choisissez les noms pour la clarté opérationnelle et la responsabilité ; un nombre de correspondances regex plus faible ne suffit pas à justifier un renommage.

3. Préserver le rôle de récupération de l’Administrator intégré

Un Administrator activé correspond au détecteur, car il n’existe aucune exception pour le SID ou les comptes intégrés. Déterminez quel compte vous examinez avant toute décision de retrait. Ne désactivez pas aveuglément l’Administrator intégré du domaine parce qu’il apparaît dans la liste de noms.

Les consignes Microsoft sur l’Administrator intégré réservent son utilisation à la construction initiale et à une éventuelle récupération après sinistre. La page a explicitement retiré son ancienne recommandation de désactivation, car la récupération de forêt utilise ce compte, notamment pour la connexion sans serveur de catalogue global. Elle décrit à la place des restrictions et l’audit de l’utilisation, des réinitialisations de mot de passe et des modifications du compte.

Appliquez les restrictions dans le cadre d’un plan de récupération examiné et du périmètre documenté. La page déconseille de lier sa GPO de restriction au niveau du domaine, car cela peut rendre Administrator inutilisable pendant la récupération. N’étendez pas les affirmations historiques de l’ancienne page de renommage sur le verrouillage à une affirmation non vérifiée concernant toutes les versions et configurations de Windows.

4. Utiliser des gMSA pour les services AD et des identités managées pour Azure

Pour les services Windows utilisant des utilisateurs de domaine ordinaires, évaluez une migration vers un gMSA lorsque c’est pris en charge. La documentation Microsoft sur les comptes de service Windows Server décrit la gestion automatique des mots de passe et une identité de service partagée entre plusieurs serveurs. Examinez la compatibilité du service, les hôtes autorisés à récupérer les identifiants, les autorisations sur les ressources et les SPN avant la migration. Cette recommandation traite de la gestion des identifiants de service, pas de tous les comptes humains dont le nom correspond.

Pour les charges de travail Azure, les consignes Microsoft sur les comptes de service cloud privilégient les identités managées lorsque c’est possible et les principaux de service lorsque c’est nécessaire, plutôt que les comptes de service Entra fondés sur des utilisateurs. Distinguez ce choix d’identité cloud d’un déploiement de gMSA AD.

Lorsqu’une application nécessite réellement des identifiants partagés, les consignes Entra sur le partage de comptes décrivent un SSO fondé sur le mot de passe qui sert d’intermédiaire pour l’accès via des identités individuelles. Les utilisateurs n’ont pas besoin de recevoir le mot de passe partagé ; les administrateurs peuvent révoquer l’accès, exiger la MFA et examiner les enregistrements de connexion. La rotation du mot de passe dépend de la prise en charge par l’application. C’est une option spécifique d’accès applicatif, pas un remède universel aux connexions AD partagées.

5. Vérifier les FGPP, le verrouillage et la MFA sur les chemins réels

Choisissez les paramètres de mot de passe et de verrouillage selon la population de comptes et les risques, puis vérifiez la politique résultante avec les commandes d’inventaire précédentes. Les FGPP peuvent différencier la politique des utilisateurs et des groupes de sécurité globaux. Ne déployez pas l’exemple Microsoft LockoutThreshold=0 simplement parce qu’il apparaît dans une démonstration : la syntaxe de politique et les recommandations de sécurité ont des objectifs différents.

La référence sur le seuil de verrouillage des comptes décrit le compromis entre la résistance aux essais de mots de passe et le déni de service par verrouillages délibérés. Sa discussion de la référence Windows utilise dix tentatives invalides comme point de départ possible, explicitement sans seuil universel. Examinez ensemble le seuil, la durée, la fenêtre de réinitialisation, les opérations de déverrouillage et la surveillance.

Le verrouillage intelligent Entra est distinct du verrouillage AD DS. Il distingue les emplacements familiers et inconnus et suit les empreintes récentes de mots de passe incorrects ; ce suivi n’est pas disponible avec l’authentification directe, ou pass-through authentication. Pour PTA, Microsoft prescrit un seuil Entra plus bas, un seuil AD DS au moins deux ou trois fois supérieur et une durée Entra plus longue. Vérifiez votre mode d’authentification et vos paramètres réels plutôt que de copier un exemple comme règle universelle.

Imposez la MFA sur les chemins exposés compatibles et examinez l’authentification héritée comme le recommande le guide d’investigation du spraying. Une politique MFA Entra ne rend pas automatiquement la MFA obligatoire sur les chemins d’authentification AD traditionnels. Lorsque la télémétrie établit une compromission de mot de passe ou de compte, suivez la réponse à incident, y compris les changements d’identifiants et les révocations de sessions/jetons appropriées, plutôt que de clore le cas après le renommage d’un compte.

Comment EtcSec détecte ce problème

Le contrôle etc-collector est PASSWORD_COMMON_PATTERNS, catégorie Password, sévérité High. Sa méthode Detect() commence à public/internal/audit/detectors/ad/password/common-patterns.go:26 ; les quinze expressions exactes sont déclarées aux lignes 28–44 :

(?i)^admin$
(?i)^administrator$
(?i)^test$
(?i)^user$
(?i)^guest$
(?i)^temp$
(?i)^default$
(?i)^support$
(?i)^service$
(?i)^backup$
(?i)^demo$
(?i)password
123$
(?i)^sa$
(?i)^dba$

L’implémentation parcourt les utilisateurs collectés et exclut uniquement les comptes Disabled. Elle convertit SAMAccountName en minuscules et vérifie ces expressions. Treize correspondent au nom complet ; password correspond n’importe où et 123$ à la terminaison. Ainsi, admin01, test1, temp-user et svc-sql ne sont pas sélectionnés par ces seuls noms ; resetPasswordHelp et User123 le sont.

Elle ajoute un compte à la première expression correspondante et interrompt la boucle interne. Un compte correspondant à plusieurs expressions ne contribue qu’une fois. Cette implémentation ne prévoit aucune exemption fondée sur le SID/RID, l’OU, un groupe privilégié, une fonction de service ou une liste d’autorisation.

Count inclut tous les utilisateurs activés correspondants. Details.affectedAccountNames contient au maximum dix noms, même sans IncludeDetails. Dix noms affichés ne signifient donc pas qu’il n’existe que dix comptes correspondants. AffectedEntities est ajouté lorsque les détails sont demandés et que le nombre est positif ; le résultat lui-même est renvoyé même à zéro.

Le détecteur ne lit ni displayName, ni mot de passe, ni empreinte de mot de passe. Il ne mesure pas l’entropie des mots de passe, n’effectue pas d’authentification, n’évalue ni la politique de verrouillage ni la MFA et n’inspecte pas l’activité pour prouver une tentative ou une réussite de spraying. Son texte descriptif suggère un risque de mot de passe par défaut, mais ces suggestions ne sont pas des prédicats du code.

Valider le résultat

Répétez le même inventaire et les lectures de politique effective après les changements approuvés. Documentez les exceptions conservées et les exigences de récupération, et confirmez avec les responsables que les services et applications fonctionnent toujours. Examinez les enregistrements d’authentification pertinents pour rechercher une activité suspecte persistante, en suivant les consignes d’investigation Microsoft.

Clôturez chaque examen avec le résultat qu’il établit réellement : identité inutile retirée, dépendance migrée, politique effective vérifiée ou exception conservée avec justification. Le nommage, la politique de mot de passe, l’application des accès et les preuves d’attaque répondent à des questions différentes. Un examen de nommage terminé doit clarifier ces réponses sans prétendre qu’une regex a testé un secret.