Passwörter in AD-Beschreibungen: Erkennung und Bereinigung

Passwörter in AD-Beschreibungen wirken harmlos, weil sie wie normale Betriebsnotizen aussehen. In vielen Umgebungen werden sie aber zu einer Abkürzung für Onboarding-Passwörter, Reset-Werte für Dienstleister, Geheimnisse von Servicekonten, Übergabekommentare oder Erinnerungen, die nie im Klartext dort landen sollten. Sobald ein Passwort im Attribut description steht, ist es keine private Notiz mehr, sondern Verzeichnisdaten, die abgefragt, exportiert, synchronisiert und lange nach dem ursprünglichen Vorgang weiterkopiert werden können.

Genau deshalb ist PASSWORD_IN_DESCRIPTION ein praktisches Sicherheitsproblem. Ein Angreifer muss keinen Hash knacken, kein Password Spraying fahren und nicht auf einen Phishing-Klick warten, wenn ein gültiges oder gut erratbares Kennwort bereits in LDAP steht. Selbst wenn der exakte Wert nicht mehr gültig ist, verrät der Begleittext oft genug über Passwortmuster, Reset-Gewohnheiten, Zuständigkeiten und operative Schwächen, um Folgeangriffe deutlich zu erleichtern.

Die Schwachstelle tritt zudem selten isoliert auf. Umgebungen, die Passwörter in AD-Attributen dulden, haben häufig gleichzeitig unsaubere Reset-Prozesse, veraltete privilegierte Identitäten, unklare Verantwortlichkeiten für Servicekonten und wenig Transparenz über Attributänderungen. Der Fund ist deshalb nicht nur Bereinigungsarbeit, sondern ein Hinweis darauf, dass die Identitätsprozesse an mehreren Stellen zu informell geworden sind.

Passwörter in AD-Beschreibungen: was der Fund bedeutet

PASSWORD_IN_DESCRIPTION bedeutet, dass ein oder mehrere Beschreibungsfelder in Active Directory Passwortmaterial oder klare Hinweise auf das verwendete Geheimnis enthalten. Dazu gehören vollständige Kennwörter, temporäre Onboarding-Werte, Teilstrings, die das Raten erleichtern, Hinweise darauf, dass ein Secret nicht rotiert wurde, oder Kommentare wie temporäres Passwort für neuen Mitarbeiter gesetzt.

In vielen Organisationen beginnt das mit einer scheinbar kleinen Ausnahme. Der Helpdesk setzt ein Konto zurück und legt den Wert für kurze Zeit in die Beschreibung. Ein Administrator notiert bei einer Übergabe, dass das Kennwort eines Servicekontos unverändert geblieben ist. Ein Projektteam schreibt Zugangsdaten für einen Dienstleister in das Verzeichnis, weil das schneller ist als die Ticketpflege. Die Absicht ist Bequemlichkeit, das Ergebnis ist ein Klartext-Secret in einem der am breitesten replizierten Datenspeicher der Umgebung.

Die Auswirkung hängt stark vom betroffenen Konto ab. Ein temporäres Passwort auf einem unkritischen Testkonto ist bereits ein Sicherheitsfehler. Kritisch wird es aber besonders dann, wenn die Beschreibung zu einem Servicekonto, einem Administrator, einem Break-Glass-Konto oder einer Identität gehört, die E-Mail, VPN, Remote-Administration oder Automatisierung erreichen kann.

Wie es funktioniert

Angreifer nutzen diese Schwäche mit normaler Verzeichnisenumeration aus. Nach einem beliebigen ersten Zugriff im Domänennetz fragen sie Benutzer-, Service- und Computerobjekte mit gefüllter Beschreibung ab und filtern nach Zeichenfolgen, die wie Kennwörter, Reset-Hinweise oder Admin-Notizen aussehen. Ein Exploit ist dafür nicht nötig. LDAP-Leserechte und ein systematisches Vorgehen reichen in vielen Umgebungen aus.

Typische Beispiele sind:

Temp password: Winter2026!
VPN-Konto erstellt, Startwert telefonisch übermittelt
svc_sql an Team B übergeben, Passwort unverändert
nicht deaktivieren, Backup hängt daran, pass = ...
Starterkonto morgens zurückgesetzt, Passwortwechsel bei erster Anmeldung

Selbst wenn das exakte Passwort inzwischen ungültig ist, hilft die Notiz weiter. Sie kann zeigen, dass ein Konto zu einer kritischen Funktion gehört, dass temporäre Kennwörter einem vorhersagbaren Muster folgen, dass die Verantwortung für ein Servicekonto unklar ist oder dass Teams Geheimnisse weiterhin außerhalb freigegebener Werkzeuge behandeln.

Beschreibungsfelder bleiben außerdem selten nur in AD. Sie landen in Admin-Exports, IAM-Konnektoren, Support-Dashboards, Audit-Snapshots, CMDBs oder Drittsystemen für Inventarisierung. Die Exposition betrifft damit weit mehr Personen und Systeme als nur diejenigen, die direkt im Verzeichnis lesen können.

Wichtig ist auch: Der erste Zugriff, der für LDAP-Abfragen nötig ist, muss nicht raffiniert sein. Ein normales Benutzerkonto aus Passwortwiederverwendung, Sitzungsdiebstahl oder einem Weg ähnlich zu den Mustern aus NTLM-Relay-Angriffe kann genügen, um nach wertvollen Notizen zu suchen. Wird dabei ein Service-Secret oder ein überprivilegiertes Konto gefunden, verkürzt sich der Weg zu tieferem Zugriff massiv.

Wo das in der Praxis auftaucht

Sinnvoller als die Sicht auf einen Sonderfall ist die Betrachtung als Nebenprodukt alltäglicher Betriebsprozesse. Beschreibungsfelder leaken Passwörter meist dort, wo Teams unter Zeitdruck arbeiten oder kein sicherer Alternativprozess vorhanden ist.

Onboarding und Dienstleisterkonten

Temporäre Kennwörter tauchen häufig in Joiner- und Mover-Prozessen auf. Ein Konto wird vorab angelegt, ein Reset-Wert generiert und anschließend in die Beschreibung geschrieben, bis der Benutzer anruft, vor Ort erscheint oder den Erhalt bestätigt. Ohne klaren Eigentümer für die Nachbereitung bleibt die Notiz oft lange nach der ersten Anmeldung stehen.

Dienstleister- und Lieferantenkonten sind besonders riskant, weil ihr Lebenszyklus oft auf HR, Einkauf, lokale IT und das Fachteam verteilt ist. Wenn niemand den Gesamtprozess besitzt, wird das Beschreibungsfeld schnell zum improvisierten Zugangsprotokoll.

Helpdesk-Resets und dringende Wiederherstellungen

Verliert ein Benutzer kurz vor einem Termin den Zugang, setzt der Support das Passwort unter Zeitdruck zurück und trägt den Wert vielleicht in die Beschreibung ein, bevor das nächste Ticket wartet. In manchen Teams wird diese Abkürzung zur stillschweigenden Routine. Das Problem ist dann nicht nur das einzelne exponierte Passwort, sondern die Grundannahme, dass AD selbst ein akzeptabler Zwischenablageort für Secrets sei.

Übergaben von Servicekonten

Servicekonten produzieren besonders gefährliche Notizen, weil ihre Rotation schwierig erscheint. Wechselt die Zuständigkeit, enthält die Übergabenotiz unter Umständen das aktuelle Kennwort, einen Hinweis auf die Anwendung oder den Vermerk, dass die Rotation bewusst verschoben wurde, um Ausfälle zu vermeiden. Damit kombiniert man Klartextspeicherung mit einem Secret, das sowieso nur widerwillig verändert wird.

Noch problematischer ist das, wenn dasselbe Konto auch in den Szenarien auftaucht, die bei Kerberoasting: Servicekonten im Fokus relevant sind, oder wenn es zu den veralteten privilegierten Konten in AD gehört, die niemand deaktivieren will, weil vielleicht noch irgendwo eine Abhängigkeit existiert.

Privilegierte und Break-Glass-Identitäten

Notfallkonten sollten die strengste Handhabung der gesamten Umgebung haben. In der Realität sammeln sie aber manchmal informelle Kommentare, weil nur wenige Personen wissen, wie sie genutzt werden. Hinweise wie Passwort im Tresor, letztes Quartal geändert oder im schlimmsten Fall der Wert selbst schaffen einen direkten Weg zu hochkritischem Zugriff.

Computerobjekte und lokale Admin-Hinweise

Manche Teams speichern Build-Notizen oder lokale Administratorhinweise in Computerbeschreibungen. Selbst wenn nur Inventarkontext beabsichtigt ist, ermöglicht jedes Passwort oder jeder Wiederverwendungshinweis laterale Bewegung, besonders dann, wenn dasselbe lokale Admin-Secret breit geteilt wird.

Das Muster ist immer ähnlich: Das Beschreibungsfeld ersetzt Tresor, Ticket oder Runbook. Die Schwachstelle ist deshalb technisch und prozessual zugleich.

Angriffskette

Eine realistische Angriffskette bleibt simpel:

Der Angreifer kompromittiert einen Arbeitsplatz oder ein Benutzerkonto mit wenig Rechten.
Er enumeriert AD-Objekte mit gefülltem Beschreibungsfeld.
Er filtert nach Begriffen wie password, passwort, kennwort, pwd, temp, reset, service, Monatsnamen, Jahreszeiten oder Hinweisen auf VPN und Onboarding.
Er testet gefundene Anmeldedaten gegen E-Mail, VPN, SMB, RDP, Remote-Management oder Fachanwendungen.
Von dort pivotiert er in privilegierte Gruppen, Delegierungen, Servicepfade oder Passwortwiederverwendung.

Die Stärke dieser Schwachstelle liegt darin, dass sie Unsicherheit abbaut. Klassische Credential-Angriffe beginnen mit vielen offenen Fragen: Welche Konten sind aktiv, welche wichtig, welche Systeme erreichen sie, welche Passwortmuster werden genutzt und wo sind operative Lücken? Beschreibungsfelder beantworten davon oft mehrere gleichzeitig.

Häufige Szenarien sind:

Eine Onboarding-Notiz enthält ein temporäres Passwort, das gegen Microsoft 365 und VPN noch funktioniert, weil der Wechsel beim ersten Login nie erzwungen wurde.
Die Beschreibung eines Servicekontos enthält sowohl das Secret als auch den Applikationsbezug und erleichtert damit spätere soziale Angriffe.
Eine Notiz zu einem Break-Glass-Konto bestätigt, dass diese Identität aus normalen Kontrollen herausfällt.
Ein veraltetes privilegiertes Konto trägt noch einen alten Passwortverweis in der Beschreibung und wurde nie deaktiviert, weil niemand Abhängigkeiten testen wollte.

Die Lage verschärft sich zusätzlich, wenn die Organisation bereits die Muster zeigt, die in Active Directory Passwortsicherheit beschrieben sind: informelle Resets, schwache Lifecycle-Kontrolle, historische Servicekonten und fehlende systematische Prüfung, wo Secrets tatsächlich liegen.

Erkennung

Die Erkennung beginnt mit sauberem Scope. Eine gute Suche beschränkt sich nicht auf aktivierte Benutzerkonten. Sie umfasst:

aktivierte Benutzer
deaktivierte, aber zuletzt noch genutzte Konten
Administratoren und Break-Glass-Konten
Servicekonten
Onboarding- und Dienstleisteridentitäten
generische oder gemeinsam genutzte Konten
Computerobjekte mit Betriebsnotizen

Ein erster PowerShell-Lauf liefert oft schon die erste Trefferwelle:

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

Danach sollte die Suche mit Mustern erweitert werden und nicht nur auf das Wort password schauen. In deutschsprachigen Umgebungen lohnt sich die Kombination aus englischen und lokalen Begriffen:

$pattern = '(?i)(password|passwort|kennwort|pwd|pass\s*=|temp|temporaer|initial|reset|fruehling|sommer|herbst|winter|vpn)'

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

Falls auch Computerobjekte genutzt werden:

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

Ziel ist nicht bloß das Zählen gefüllter Beschreibungen, sondern die Trennung zwischen harmloser Betriebsnotiz und echtem Klartext-Umgang mit Geheimnissen. Beim Triage sollten Sie besonders prüfen, ob die Beschreibung enthält:

ein exaktes Passwort oder einen glaubwürdigen Kandidaten;
einen Reset-Hinweis, der noch gültig sein könnte;
einen Hinweis auf Passwortmuster;
Eigentumsnotizen, die auf lange ausbleibende Rotation hindeuten;
Bezüge zu sensiblen Systemen wie Backup, VPN, Finanzen oder Identity-Administration.

Ein pragmatisches Priorisierungsmodell:

Objekttyp	Warum relevant	Priorität
Privilegierter Benutzer oder Break-Glass-Konto	Ein einzelnes Secret kann sofort hohen Impact erzeugen	Kritisch
Servicekonto für Aufgaben, Apps oder Infrastruktur	Rotation wird oft verschoben, Blast Radius ist groß	Hoch
Veraltetes oder generisches Konto	Schlechte Ownership macht Missbrauch schwerer sichtbar	Hoch
Dienstleister- oder Onboarding-Konto	Temporäre Kennwörter bleiben oft zu lange gültig	Mittel bis hoch
Computerobjekt mit lokalen Admin-Hinweisen	Kann laterale Bewegung ermöglichen	Mittel

Die Erkennung muss außerdem über das reine Verzeichnis hinausgehen. Wird das Beschreibungsfeld in andere Systeme synchronisiert, existiert die Exposition dort ebenfalls. Prüfen Sie deshalb auch:

IAM- und Provisioning-Werkzeuge
Service-Desk-Exporte
CMDB oder Inventardatenbanken
Backups und Audit-Snapshots
Skripte, die Benutzerdaten für Adminzwecke exportieren

Sinnvoll ist außerdem die Prüfung, ob Attributänderungen überhaupt überwacht werden. Wenn Objektänderungsauditing aktiv ist, können Events wie 5136 helfen, Änderungen des Beschreibungsfelds zu erkennen. In Kombination mit Passwort-Reset-Events und den Ansätzen aus AD-Sicherheitsüberwachung: relevante Events lässt sich so nicht nur bestehende Exposition, sondern auch der Prozess erkennen, der sie wieder einführt.

Am Ende braucht jede Feststellung Entscheidungsfragen:

Ist das Konto noch aktiviert?
Hat es Privilegien oder erbt es welche?
Wurde das Passwort nach dem Eintrag je rotiert?
Hat sich das Konto kürzlich angemeldet und von welchen Hosts?
Könnte derselbe Wert in anderen Systemen wiederverwendet worden sein?
Zeigt die Notiz ein breiteres Prozessproblem bei derselben verantwortlichen Gruppe?

Ohne diese Ebene löscht man Text, ohne zu klären, ob das exponierte Secret bereits benutzt oder anderweitig verteilt wurde.

Remediation und priorisierte Maßnahmen

Die Behebung muss wie ein Compromise-Workflow behandelt werden, nicht wie eine kosmetische Korrektur. Wenn ein Passwort in einer Beschreibung auftaucht, ist die sichere Annahme, dass es exponiert wurde und rotiert werden muss.

Die Mindestreaktion lautet:

Passwort oder Hinweis aus dem Beschreibungsfeld entfernen.
Betroffenes Secret zurücksetzen oder rotieren.
Prüfen, wo derselbe Wert sonst noch verwendet wurde.
Letzte Authentifizierungsaktivität des Kontos untersuchen.
Den Prozess reparieren, der das Secret überhaupt in AD geschrieben hat.

Bei Benutzerkonten bedeutet das in der Regel ein Passwort-Reset, die Prüfung auf jüngste Zugriffe auf E-Mail, VPN, Remote Desktop oder SaaS sowie die Frage, ob die Notiz zusätzlich ein temporäres Passwortmuster verraten hat. Ist das Konto privilegiert, sollten auch Gruppenmitgliedschaften, Delegierungen und potenzielle laterale Bewegungen betrachtet werden.

Bei Servicekonten ist die Behebung anspruchsvoller, weil Teams Rotation oft aus Angst vor Produktionsstörungen verschieben. Die richtige Antwort ist trotzdem nicht, das Secret stehen zu lassen, sondern Abhängigkeiten aufzunehmen und sicher zu rotieren. Dazu gehören insbesondere:

Windows-Dienste
geplante Tasks
IIS-App-Pools
Skripte und Automatisierungsjobs
Anwendungsconnectoren und Middleware
gespeicherte Zugangsdaten in Pipelines oder Konfigurationsdateien

Wo immer möglich, sollten langlebige Serviceidentitäten auf verwaltete Modelle wie gMSA umgestellt werden, statt ein Betriebsmodell mit bekannten statischen Secrets fortzuschreiben.

Ist das betroffene Objekt veraltet oder ohne klare Ownership, kann die sicherste Eindämmung darin bestehen, es zunächst zu deaktivieren und anschließend Abhängigkeiten zu validieren. Das ist oft besser, als ein fragwürdiges Secret zu erhalten, nur weil niemand die Nutzung genau kennt. Genau diese Ownership-Lücken zeigen sich auch in Vergleich von Active-Directory-Sicherheitsaudit-Tools.

Die zweite Hälfte der Behebung ist Prozessdisziplin. Teams brauchen eine explizite Alternative dazu, Secrets in AD zu schreiben. Praktisch bedeutet das meist:

einen Vault oder einen freigegebenen Workflow für temporäre Übergaben;
Ticket-Referenzen statt Secrets in Verzeichnisnotizen;
Cleanup-Kontrollpunkte nach Onboarding und Helpdesk-Resets;
Reviews der Servicekonto-Verantwortung bei Teamübergaben;
Einschränkungen dafür, wer sensible Kontofelder beschreiben darf;
klare Schulung, dass Verzeichnisattribute kein Secret Store sind.

Ein einfacher, wirkungsvoller Control ist die wiederkehrende Überprüfung gefüllter Beschreibungsfelder mit sofortiger Eskalation bei plausiblen Passwortmustern. So wird das Problem sichtbar, bevor der nächste formale Audit-Termin kommt.

Wichtig bleibt: Das Löschen des Textes macht die Exposition nicht rückgängig. Der Wert kann bereits gelesen, exportiert, repliziert oder gesichert worden sein. Deshalb sind Rotation und Validierung unverzichtbar. Wenn das notierte Passwort wiederverwendet wurde, reicht der Vorfall womöglich in VPN, lokale Admin-Workflows, Fachanwendungen oder Skripte hinein.

Wie EtcSec das erkennt

EtcSec identifiziert Konten, deren Beschreibungen wahrscheinliches Passwortmaterial, Reset-Notizen oder operativen Klartextumgang mit Secrets enthalten. Richtig wertvoll wird der Fund, wenn er mit Privilegien, Passwortalter, jüngster Aktivität, veralteter Ownership und Angriffswegen korreliert wird, die aus einem einzelnen gefundenen Secret einen echten Fortschritt für den Angreifer machen.

Diese Einordnung ist entscheidend, weil nicht jede Exposition die gleiche Dringlichkeit hat. Eine temporäre Notiz auf einem deaktivierten Testkonto ist weiterhin ein Problem, aber operativ nicht so kritisch wie ein aktives Servicekonto in der Infrastruktur oder eine privilegierte Identität mit dauerhaften Rechten.

Fazit

Passwörter in Beschreibungsfeldern sind für Betriebsteams vielleicht eine kleine Bequemlichkeit, für Verteidiger aber ein überproportionaler Risikotreiber. Sie legen Secrets in einem Verzeichnis offen, das Angreifer ohnehin systematisch auslesen, und sie zeigen fast immer tiefere Schwächen in Account-Lifecycle, Support-Prozessen und Service-Credential-Management.

Behandeln Sie den Fund deshalb zugleich als Secret Exposure und als Prozessversagen: Notiz entfernen, Kennwort rotieren, weitere Verbreitung prüfen und den Workflow schließen, der das Passwort überhaupt in die Beschreibung geschrieben hat.