Mots de passe dans les descriptions AD

Les mots de passe dans les descriptions AD paraissent anodins pour les équipes parce qu'ils ressemblent à de simples notes d'exploitation. En pratique, ils deviennent souvent un raccourci pour stocker des mots de passe d'onboarding, des valeurs de réinitialisation pour des prestataires, des secrets de comptes de service, des commentaires de passation ou des rappels qui ne devraient jamais exister en clair. Dès qu'un mot de passe atterrit dans l'attribut description, il cesse d'être une note privée et devient une donnée d'annuaire qui peut être interrogée, exportée, synchronisée et recopiée bien après la fin de la tâche initiale.

C'est précisément ce qui rend PASSWORD_IN_DESCRIPTION si concret. Un attaquant n'a pas besoin de casser un hash, de lancer un password spray ou d'attendre un clic sur un phishing si un secret valide ou facilement devinable est déjà présent dans LDAP. Et même si la valeur exacte n'est plus valide, le texte autour du secret continue souvent à révéler des conventions de réinitialisation, des habitudes d'équipe, des faiblesses de gouvernance ou des indices sur des comptes sensibles.

Le problème apparaît aussi rarement seul. Les environnements qui laissent fuiter des mots de passe dans les attributs AD présentent souvent en parallèle des workflows de reset fragiles, des identités privilégiées obsolètes, des comptes de service mal possédés et une visibilité limitée sur les changements d'attributs. Il faut donc traiter ce finding comme un symptôme d'un mode opératoire trop permissif, pas uniquement comme du nettoyage éditorial.

Mots de passe dans les descriptions AD : ce que le finding recouvre

PASSWORD_IN_DESCRIPTION signifie qu'un ou plusieurs champs Description dans Active Directory contiennent de la matière sensible liée à un mot de passe ou des indices crédibles sur le secret. Cela peut être un mot de passe complet, une valeur temporaire d'onboarding, une partie du mot de passe qui facilite le guessing, une note indiquant que le secret n'a pas été tourné, ou un commentaire opérationnel du type mot de passe temporaire défini pour le nouvel arrivant.

Dans beaucoup d'organisations, tout commence par une exception apparemment raisonnable. Un technicien support réinitialise un compte et garde la valeur quelques heures dans la description. Un administrateur note qu'un compte de service n'a pas été tourné lors d'une passation. Une équipe projet renseigne les détails d'accès d'un prestataire dans l'annuaire parce que c'est plus rapide que de mettre à jour le ticket. L'intention est la commodité, mais le résultat est un secret en clair dans l'un des répertoires les plus répliqués de l'environnement.

L'impact dépend fortement du compte concerné. Un mot de passe temporaire sur un compte de test sans privilège reste un échec de sécurité, mais le risque explose lorsque la description appartient à un compte de service, à un compte admin, à un compte de secours ou à une identité capable d'ouvrir la messagerie, le VPN, l'administration distante ou un outil d'automatisation.

Comment cela fonctionne

Les attaquants exploitent cette faiblesse par de l'énumération standard. Après un premier accès quelconque au domaine, ils interrogent les objets utilisateurs, services et ordinateurs dont la description est renseignée, puis filtrent les chaînes qui ressemblent à des identifiants, à des notes de reset ou à des commentaires techniques. Aucun exploit n'est nécessaire. Des droits de lecture LDAP et un peu de méthode suffisent souvent.

On retrouve fréquemment des traces comme :

temp password: Winter2026!
compte VPN créé, valeur initiale transmise par téléphone
svc_sql repris par l'équipe B, mot de passe inchangé
ne pas désactiver, la sauvegarde dépend de ce compte, pass = ...
compte nouvel arrivant réinitialisé avant arrivée, changement imposé à la première connexion

Même lorsqu'un mot de passe exact a expiré, la note continue d'aider l'attaquant. Elle peut confirmer qu'un compte correspond à une fonction critique, que les mots de passe temporaires suivent un format prévisible, que la propriété d'un compte de service est floue, ou que les équipes manipulent encore des secrets en dehors des outils approuvés.

Les champs Description ne restent d'ailleurs pas confinés à AD. Ils finissent souvent copiés dans des exports d'administration, des connecteurs IAM, des tableaux de bord support, des snapshots d'audit, des CMDB ou des outils tiers d'inventaire. L'exposition dépasse donc largement les personnes qui naviguent directement dans l'annuaire.

Cet aspect est important parce que le premier accès nécessaire pour énumérer LDAP n'a rien d'exotique. Un compte utilisateur récupéré via réutilisation de mot de passe, vol de session ou technique de déplacement latéral similaire à celles discutées dans Attaques NTLM Relay suffit souvent pour commencer la chasse aux notes intéressantes. Une fois un secret de service ou un compte sur-privilégié trouvé, le chemin vers une compromission plus profonde se raccourcit vite.

Où cela apparaît en pratique

Le plus utile est de considérer ce problème non comme un cas rare, mais comme le sous-produit de moments d'exploitation très ordinaires. Les champs Description fuient surtout des mots de passe là où les équipes sont sous pression ou n'ont pas de workflow plus sûr.

Onboarding et comptes prestataires

Les mots de passe temporaires apparaissent souvent dans les processus d'arrivée et de changement de rôle. Un compte est préparé à l'avance, une valeur de reset est générée, puis quelqu'un l'écrit dans la description en attendant que l'utilisateur appelle, se présente sur site ou confirme qu'il a bien reçu l'information. La note peut survivre longtemps après la première connexion si personne n'est clairement responsable du nettoyage.

Les comptes de prestataires sont encore plus risqués, car leur cycle de vie est souvent éclaté entre RH, achats, IT locale et équipe projet. Quand personne ne tient le flux complet, le champ Description devient un pense-bête d'accès.

Réinitialisations helpdesk et urgences support

Quand un utilisateur perd l'accès juste avant une réunion, le support peut réinitialiser le mot de passe, laisser la valeur dans la description et passer au ticket suivant. Dans certaines équipes, ce raccourci finit par devenir une pratique implicite. Le problème n'est pas seulement le mot de passe exposé, mais l'idée sous-jacente qu'AD serait un endroit acceptable pour stocker un secret pendant un traitement support.

Passations de comptes de service

Les comptes de service sont une source classique de notes dangereuses parce qu'ils sont difficiles à tourner proprement. Lorsqu'une responsabilité change d'équipe, la note de passation peut inclure le mot de passe actuel, un indice sur l'application qui l'utilise ou un rappel indiquant qu'il a volontairement été laissé inchangé pour éviter une panne. On combine alors les deux pires paramètres : du stockage en clair et un secret que personne ne veut vraiment tourner.

Le risque est encore plus fort quand le compte concerné apparaît aussi dans des scénarios proches de ceux couverts par Kerberoasting : attaques sur les comptes de service ou lorsqu'il appartient au stock de comptes privilégiés obsolètes dans AD que personne n'ose désactiver parce qu'un traitement pourrait encore en dépendre.

Comptes privilégiés et comptes de secours

Les comptes d'urgence devraient faire l'objet de la discipline la plus stricte de l'environnement. Pourtant, ils accumulent parfois des notes informelles parce que très peu de personnes savent comment ils sont utilisés. Des commentaires comme mot de passe gardé dans le coffre, changé le trimestre dernier ou, pire, le secret lui-même, ouvrent une voie directe vers un accès très sensible.

Objets ordinateur et indices d'admin local

Certaines équipes consignent dans la description des postes des informations de build ou des références à l'administration locale. Même si l'objectif est simplement l'inventaire, tout mot de passe ou indice de réutilisation ouvre une opportunité de mouvement latéral, surtout si le même secret local est partagé largement.

Le motif est toujours le même : le champ Description finit par remplacer un coffre-fort, un ticket ou une procédure. La faiblesse est donc à la fois technique et procédurale.

Chaîne d'attaque

Une chaîne d'attaque réaliste reste très simple :

L'attaquant compromet un poste ou un compte utilisateur à faible privilège.
Il énumère les objets AD dont la description est renseignée.
Il filtre des mots-clés comme password, pwd, pass, temp, reset, service, welcome, des mois, des saisons, ou des notes liées au VPN et à l'onboarding.
Il valide les identifiants récupérés sur la messagerie, le VPN, SMB, RDP, l'administration distante ou des applications métier.
Il pivote ensuite vers des groupes privilégiés, des délégations, des chemins de service ou de la réutilisation de credentials.

La force de cette faiblesse est qu'elle réduit l'incertitude. Une attaque par mot de passe classique commence avec de nombreuses inconnues : quels comptes sont actifs, lesquels sont sensibles, quels systèmes ils atteignent, comment les mots de passe sont choisis, où les workflows sont faibles. Les descriptions répondent souvent à plusieurs de ces questions au même endroit.

Quelques scénarios fréquents :

une note d'onboarding expose un mot de passe temporaire encore valide sur Microsoft 365 et le VPN parce que le changement au premier logon n'a pas été imposé ;
la description d'un compte de service révèle à la fois le secret et le nom de l'application, ce qui facilite ensuite l'ingénierie sociale ;
une note sur un compte de secours confirme que ce compte échappe aux contrôles classiques ;
une identité privilégiée obsolète conserve encore une ancienne référence de mot de passe et n'a jamais été désactivée faute de tests de dépendance.

Le problème devient plus grave lorsqu'il recoupe des faiblesses de gouvernance déjà visibles dans Sécurité des mots de passe Active Directory : resets informels, mauvaise maîtrise du cycle de vie, comptes de service historiques et absence de revue régulière des secrets hors coffre.

Détection

La détection commence par le périmètre. Il ne faut pas se limiter aux utilisateurs activés. Une revue utile couvre :

les utilisateurs activés ;
les utilisateurs désactivés mais encore récemment utilisés ;
les comptes admin et les comptes de secours ;
les comptes de service ;
les comptes prestataires et onboarding ;
les comptes génériques ou partagés ;
les objets ordinateur lorsque les équipes y stockent des notes d'administration.

Un premier balayage PowerShell suffit souvent à révéler les premières expositions :

Get-ADUser -LDAPFilter '(description=*)' -Properties description, Enabled, PasswordLastSet, LastLogonDate |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, Description

Cette première passe doit ensuite être enrichie avec des motifs, sans dépendre uniquement du mot password. Dans un environnement francophone, il est utile de rechercher des variantes anglaises et locales :

$pattern = '(?i)(password|mot de passe|pwd|pass\s*=|temp|temporaire|initial|reset|welcome|ete|hiver|printemps|vpn)'

Get-ADUser -LDAPFilter '(description=*)' -Properties description, Enabled, PasswordLastSet, LastLogonDate |
  Where-Object { $_.Description -match $pattern } |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, Description

Si les équipes annotent aussi les ordinateurs :

Get-ADComputer -LDAPFilter '(description=*)' -Properties description |
  Where-Object { $_.Description -match $pattern } |
  Select-Object Name, Description

L'objectif n'est pas simplement de compter les descriptions non vides, mais de distinguer les notes techniques bénignes des entrées qui révèlent une manipulation de secret en clair. Le triage doit chercher :

un mot de passe exact ou une valeur candidate crédible ;
une référence à un reset potentiellement encore valable ;
un indice sur le format du mot de passe ;
des notes de propriété montrant que le secret n'a pas tourné depuis longtemps ;
des références à des systèmes sensibles comme la sauvegarde, le VPN, la finance ou l'administration d'identité.

Une priorisation simple peut ressembler à ceci :

Type d'objet	Pourquoi c'est important	Priorité
Utilisateur privilégié ou compte de secours	Un seul secret exposé peut donner un accès immédiat à fort impact	Critique
Compte de service lié à des tâches, applications ou infrastructure	La rotation est souvent repoussée et le blast radius est large	Haute
Compte partagé ou obsolète	La mauvaise gouvernance rend l'abus plus discret	Haute
Compte prestataire ou onboarding	Les mots de passe temporaires restent valides trop longtemps	Moyenne à haute
Objet ordinateur avec notes d'admin local	Peut faciliter le mouvement latéral	Moyenne

La détection doit aussi sortir de l'annuaire. Si le champ Description est synchronisé vers d'autres systèmes, l'exposition existe ailleurs que dans AD. Il faut examiner où ces attributs sont consommés :

outils IAM et provisioning ;
exports service desk ;
CMDB ou bases d'inventaire ;
sauvegardes et snapshots d'audit ;
scripts qui exportent les utilisateurs pour l'administration.

Il est également utile de vérifier si des changements d'attribut sont surveillés. Quand l'audit des objets d'annuaire est activé, des événements comme 5136 peuvent aider à repérer les modifications du champ Description. Corrélés aux événements de reset et aux pratiques décrites dans Supervision sécurité AD : événements clés, ils permettent de détecter à la fois l'exposition existante et le workflow qui la recrée.

Enfin, chaque finding doit être accompagné de questions de décision :

le compte est-il toujours activé ;
possède-t-il des privilèges ou en hérite-t-il ;
le mot de passe a-t-il été tourné après l'écriture de la note ;
le compte s'est-il authentifié récemment et depuis quelles machines ;
le secret a-t-il pu être réutilisé dans un autre système ;
la note révèle-t-elle un problème de processus affectant d'autres comptes gérés par la même équipe.

Sans cette couche de triage, on efface du texte sans répondre à la vraie question : le secret exposé a-t-il déjà servi ou s'est-il déjà propagé ailleurs.

Remediation et actions prioritaires

La remédiation doit être menée comme un workflow de compromission, pas comme une simple correction de forme. Si un mot de passe apparaît dans une description, l'hypothèse prudente est qu'il est exposé et qu'il faut le tourner.

La réponse minimale est la suivante :

supprimer le mot de passe ou l'indice du champ Description ;
réinitialiser ou faire tourner le secret ;
vérifier si la même valeur a été réutilisée ailleurs ;
examiner les authentifications récentes du compte ;
corriger le processus qui a amené le secret dans AD.

Pour les comptes utilisateurs, cela signifie en général imposer un reset, vérifier si le compte a accédé récemment à la messagerie, au VPN, au bureau à distance ou à des services SaaS, et examiner si la note révélait aussi une convention de mot de passe temporaire réutilisée ailleurs. Si le compte est privilégié, il faut aussi revoir les groupes, les délégations et les opportunités de mouvement latéral ouvertes pendant la fenêtre d'exposition.

Pour les comptes de service, la remédiation est plus délicate parce que les équipes repoussent souvent la rotation par peur de casser la production. La bonne réponse n'est pas de laisser le secret en place, mais d'inventorier les dépendances et de tourner proprement. Cela implique notamment de passer en revue :

les services Windows ;
les tâches planifiées ;
les pools IIS ;
les scripts et jobs d'automatisation ;
les connecteurs applicatifs et middlewares ;
les credentials stockés dans les pipelines ou fichiers de configuration.

Dès que possible, il vaut mieux migrer ces identités vers des approches managées comme gMSA plutôt que de préserver un modèle reposant sur des secrets statiques connus de plusieurs personnes.

Si l'objet concerné est obsolète ou d'appartenance incertaine, le bon réflexe peut être de le désactiver avant rotation puis de valider les dépendances. C'est souvent plus sûr que de conserver un secret douteux simplement parce que personne n'est certain de ses usages. On retrouve ici les lacunes de maîtrise évoquées dans Comparatif des outils d'audit sécurité Active Directory.

L'autre moitié de la remédiation est procédurale. Les équipes doivent disposer d'une alternative explicite à l'écriture de secrets dans AD. Cela passe en général par :

un coffre ou un workflow approuvé de partage temporaire ;
des références de ticket plutôt que des secrets dans les notes d'annuaire ;
des points de contrôle de nettoyage après onboarding et resets support ;
une revue des propriétaires de comptes de service lors des passations ;
des limitations sur qui peut écrire des notes sur des comptes sensibles ;
une sensibilisation claire indiquant qu'un attribut d'annuaire n'est pas un secret store.

Un contrôle simple et utile consiste à lancer des revues récurrentes des descriptions renseignées et à faire remonter immédiatement toute entrée contenant un motif plausible de mot de passe. Cela rend le problème visible avant le prochain audit formel.

Enfin, supprimer le texte n'efface pas l'exposition. La valeur a peut-être déjà été lue, exportée, répliquée ou sauvegardée. C'est pour cela que la rotation et la validation d'usage sont essentielles. Si la note décrivait un mot de passe réutilisé, l'incident peut déborder d'AD vers le VPN, l'admin locale, les applications métier ou des scripts encore configurés avec cette valeur.

Comment EtcSec détecte ce risque

EtcSec identifie les comptes dont la description contient un mot de passe probable, une note de reset ou un texte opérationnel révélant une manipulation de secret en clair. Le signal devient beaucoup plus utile lorsqu'il est corrélé avec le niveau de privilège, l'âge du mot de passe, l'activité récente, le caractère obsolète du compte et les chemins d'attaque qui transformeraient un seul credential récupéré en progression réelle pour un attaquant.

Cette corrélation est essentielle, car toutes les expositions n'ont pas le même niveau d'urgence. Une note temporaire sur un compte désactivé à faible valeur reste un problème, mais elle n'a pas le même poids opérationnel qu'un compte de service vivant lié à l'infrastructure ou qu'une identité privilégiée avec des droits permanents.

Conclusion

Les mots de passe stockés dans les champs Description représentent une petite commodité pour les équipes, mais un déséquilibre de risque majeur pour la défense. Ils exposent des secrets dans un annuaire que les attaquants savent déjà énumérer et révèlent souvent des faiblesses plus profondes de gouvernance des comptes, de support et de gestion des services.

Il faut donc traiter ce finding à la fois comme une fuite de secret et comme un échec de processus : supprimer la note, tourner le mot de passe, vérifier où le secret a pu circuler et fermer le workflow qui a permis son écriture.

Mots de passe dans les descriptions AD : détection et correction