Passwörter im Active-Directory-Beschreibungsfeld: Warum das gefährlich ist

„Backup-Dienst, Passwort: Sommer2019!" – ein Satz wie dieser steht in erstaunlich vielen Active-Directory-Umgebungen im Feld Beschreibung eines Benutzerkontos. Gut gemeint: Der Kollege, der das Konto später anfasst, soll das Passwort schnell finden. Aus Sicht eines Angreifers ist es ein Geschenk. Denn dieses Feld ist kein geschützter Tresor, sondern ein Klartextfeld, das in der Regel jeder Domänenbenutzer lesen kann.

In diesem Ratgeber erklären wir, warum das Muster so gefährlich ist, wie ein Angriff damit in der Praxis abläuft, wie Du Deine eigene Umgebung sicher prüfst und was Du stattdessen einsetzt.

Warum das Beschreibungsfeld kein sicherer Ort ist

Das Attribut description gehört zu den allgemeinen Informationen eines AD-Objekts. Bei einer Standardkonfiguration darf jedes authentifizierte Domänenkonto diese Informationen per LDAP abfragen. Dafür braucht es keine Administratorrechte und keinen Zugriff auf einen Server. Ein Benutzerkonto der Auszubildenden, ein Praktikantenkonto oder ein Konto, das Angreifer per Phishing übernommen haben, genügt.

Das gilt nicht nur für die Beschreibung. Auch das Feld Notizen (Attribut info) und andere Freitextfelder sind so abfragbar. Wer ein Passwort dort ablegt, hat es damit praktisch für alle Domänenkonten veröffentlicht.

Dazu kommen drei Eigenschaften, die das Problem verschärfen:

• Kein Schutz im Ruhezustand: Der Text liegt lesbar in der AD-Datenbank (ntds.dit), in Replikaten auf jedem Domänencontroller und in Backups.
• Kaum auffällig: Eine LDAP-Abfrage über alle Benutzer sieht aus wie normale Verwaltungsarbeit. Ohne gezielte Überwachung fällt sie nicht auf.
• Lange Lebensdauer: Niemand pflegt das Feld. Das Passwort steht oft jahrelang dort, auch wenn der Dienst längst anders läuft.

Die Technik ist in der Sicherheitsbranche seit Langem bekannt. MITRE führt das Ablegen und Auffinden von Zugangsdaten an unsicheren Orten als Technik T1552 „Unsecured Credentials". Das Penetrationstest-Framework Metasploit bringt ein Modul mit, das genau diese Felder nach dem Begriff „pass" durchsucht (Rapid7: Active Directory User Comments). Angreifer müssen das Rad also nicht neu erfinden.

Praxisbeispiel: Vom Phishing-Klick zum Ransomware-Angriff

Das folgende Szenario ist konstruiert, nicht der Bericht über einen bestimmten Kunden. Es bildet aber ab, wie öffentlich dokumentierte Vorfälle typischerweise ablaufen, zum Beispiel der Fall, den The Register im Juni 2026 beschreibt.

Ausgangslage: Ein Betrieb mit rund 60 Arbeitsplätzen, eine Windows-Domäne, ein Dienstkonto svc-backup für die Datensicherung. Bei der Einrichtung hat der damalige Administrator das Passwort in die Beschreibung geschrieben, damit die Vertretung es findet. Das Konto ist Mitglied in einer stark privilegierten Gruppe, weil die Sicherungssoftware sonst nicht auf alle Server zugreifen konnte.

Schritt 1 – Einstieg: In der Buchhaltung öffnet jemand eine täuschend echte Rechnungsmail und gibt die Zugangsdaten auf einer gefälschten Anmeldeseite ein. Der Angreifer hat nun ein ganz normales Benutzerkonto ohne Sonderrechte. Wie Ihr solche Mails erkennt, steht in unserem Ratgeber Phishing erkennen im Unternehmen.

Schritt 2 – Erkundung: Mit diesem Konto fragt der Angreifer das Verzeichnis ab, lädt die Benutzerliste samt Beschreibungen herunter und sucht nach Stichworten wie „pass", „pw" oder „kennwort". Das dauert Sekunden.

Schritt 3 – Treffer: Die Suche liefert svc-backup samt Klartextpasswort. Der Angreifer meldet sich damit an und besitzt nun die Rechte eines hoch privilegierten Kontos. Kein Schadcode, kein Exploit, keine Sicherheitslücke in der Software: nur eine Konfiguration, die jeder lesen konnte.

Schritt 4 – Schaden: Mit diesen Rechten löscht der Angreifer die Sicherungen, verteilt Verschlüsselungssoftware auf die Server und fordert Lösegeld. Die Backups, die im Ernstfall hätten helfen sollen, sind weg. Weshalb gerade getrennte, geprüfte Sicherungen entscheidend sind, beschreiben wir in der Backup-Strategie für KMU.

Der Kern des Beispiels: Die Schwachstelle war nicht technisch kompliziert. Sie war eine Gewohnheit. Genau deshalb lässt sie sich mit überschaubarem Aufwand beseitigen.

Warum Passwörter überhaupt dort landen

In der Beratung begegnet uns das Muster aus immer denselben Gründen:

• Dienstkonten ohne Passwortverwaltung: Für Backup, Scanner, Monitoring oder Anwendungen gibt es ein Konto, dessen Passwort „irgendwo stehen muss".
• Startpasswörter für neue Mitarbeitende: Der Helpdesk notiert das Initialpasswort kurz im Konto und vergisst, es zu entfernen.
• Sammel- und Funktionskonten: Terminalserver-, Kiosk- oder Schichtkonten, die mehrere Personen nutzen.
• Zeitdruck und Übergaben: Wer das Konto anlegt, dokumentiert schnell. Wer es später übernimmt, findet die Information dort, wo sie gerade stand.
• Fehlendes Wissen: Vielen ist nicht bewusst, dass Domänenbenutzer dieses Feld lesen können.

Mit Nachlässigkeit hat das selten zu tun. Meist fehlt schlicht eine bessere Ablage, die im Alltag genauso schnell funktioniert.

So prüfst Du Deine Umgebung

Mit einer Leseabfrage lässt sich der eigene Bestand in wenigen Minuten prüfen. Führe sie mit einem Administratorkonto in der Verwaltungs-PowerShell (Modul ActiveDirectory) aus. Die Befehle ändern nichts, sie lesen nur.

# Benutzer mit verdächtigen Begriffen in Beschreibung oder Notizen
Get-ADUser -Filter * -Properties Description, info |
  Where-Object { $_.Description -match 'pass|pw|pwd|kennwort|zugang' -or
                 $_.info        -match 'pass|pw|pwd|kennwort|zugang' } |
  Select-Object SamAccountName, Description, info

# Dasselbe für alle Objekttypen (Computer, Gruppen, Kontakte)
Get-ADObject -LDAPFilter "(|(description=*pass*)(description=*kennwort*)(info=*pass*)(info=*kennwort*))" `
  -Properties description, info |
  Select-Object Name, ObjectClass, description, info

Drei Hinweise dazu:

1. Die Ergebnisliste ist selbst vertraulich. Sie enthält im Zweifel Passwörter. Speichere sie nicht in Tickets, Chats oder E-Mails und lösche sie nach der Auswertung.
2. Stichwortsuche findet nicht alles. Ein Passwort steht nicht immer mit dem Wort „Passwort" daneben. Sieh Dir Dienstkonten und Konten mit langen Beschreibungen zusätzlich von Hand an.
3. Ein leeres Ergebnis ist kein Freispruch. Es schließt Passwörter in Dateien, Skripten oder Wikis nicht aus, die es in vielen Firmen ebenfalls gibt.

Wenn Du etwas gefunden hast: die richtigen Schritte

Der häufigste Fehler: Die Beschreibung wird gelöscht und damit gilt das Thema als erledigt. Das reicht nicht. Das Passwort war für eine unbekannte Zeit für alle Domänenbenutzer lesbar.

1. Passwort ändern, dann Text entfernen. Behandle jedes gefundene Passwort als bekannt. Setze ein neues, langes, zufälliges Passwort und passe die Stellen an, an denen es hinterlegt ist (Dienst, Aufgabenplanung, Skript).
2. Rechte des Kontos prüfen. Braucht svc-backup wirklich Domänenadministrator-Rechte? Vergib nur, was der Dienst benötigt, und sperre die interaktive Anmeldung für Dienstkonten, wo es möglich ist.
3. Anmeldungen der letzten Zeit ansehen. Gibt es ungewöhnliche Anmeldezeiten oder Quellsysteme für das Konto? Bei Verdacht auf Missbrauch gehört der Vorfall in den Notfallprozess, wie in unserem IT-Notfallplan beschrieben.
4. Ursache beheben. Sorge dafür, dass es künftig einen besseren Ablageort gibt, sonst füllt sich das Feld wieder.

Bessere Alternativen für den Alltag

Anwendungsfall	Statt Beschreibungsfeld	Hinweis
Dienstkonten für Serverdienste	Group Managed Service Accounts (gMSA)	Windows verwaltet und rotiert das Passwort selbst. Niemand muss es kennen.
Lokale Administratorkonten auf PCs und Servern	Windows LAPS	Jedes Gerät bekommt ein eigenes, regelmäßig wechselndes Passwort, abrufbar nur für berechtigte Administratoren.
Anwendungen, die kein gMSA unterstützen	Passwort-Manager für Teams, z. B. Managed Password	Lange Zufallspasswörter, rollenbasierter Zugriff, Nachvollziehbarkeit.
Startpasswort für neue Mitarbeitende	Zufälliges Einmalpasswort mit „Kennwort bei der nächsten Anmeldung ändern"	Übergabe getrennt vom Konto, nie im Konto selbst.
Dokumentation, wofür ein Konto da ist	Beschreibungsfeld mit Zweck, Verantwortlichem und Ticketnummer	Das Feld bleibt nützlich, nur ohne Zugangsdaten.

Ein gMSA ist nicht für jede Software geeignet. Ob Deine Anwendung es unterstützt, steht in ihrer Herstellerdokumentation. Wo es nicht geht, ist ein Passwort-Manager mit langen Zufallspasswörtern die sinnvolle Wahl.

Regeln, die das Problem dauerhaft lösen

Die Technik ist die eine Hälfte. Damit das Muster nicht zurückkehrt, braucht es eine klare Regel:

• Eine Zeile reicht: „Zugangsdaten stehen nie in AD-Feldern, Tickets, Mails oder Dokumenten. Sie liegen im Passwort-Manager, im gMSA oder in LAPS."
• Verantwortlichkeit: Für jedes Dienstkonto gibt es einen benannten Verantwortlichen.
• Regelmäßige Prüfung: Das Skript oben läuft mindestens einmal im Quartal und nach jedem Administratorwechsel.
• Berechtigungen im Blick: Der Baustein ORP.4 des BSI IT-Grundschutz-Kompendiums beschreibt Anforderungen an das Identitäts- und Berechtigungsmanagement (ORP.4). Auch für NIS2-nahe Anforderungen ist ein sauberer Umgang mit Zugangsdaten ein Pluspunkt.

Wie Du Passwörter im Unternehmen grundsätzlich handhabst, steht in unserem Ratgeber zur Passwortsicherheit im Unternehmen.

Häufige Fragen

Wer kann die Beschreibung eines AD-Kontos lesen?

In einer Standardkonfiguration jedes authentifizierte Konto der Domäne, unabhängig von seinen Rechten. Dazu zählen auch Konten von Praktikanten, Externen oder Konten, die durch Phishing übernommen wurden. Einen Zugriff auf einen Server braucht es dafür nicht.

Reicht es, den Text im Beschreibungsfeld zu löschen?

Nein. Das Passwort war bis dahin für alle Domänenbenutzer lesbar und kann in Backups oder bei einem Angreifer längst vorliegen. Ändere zuerst das Passwort und entferne danach den Text. Prüfe außerdem die Anmeldungen des Kontos.

Ist das Notizen-Feld sicherer als die Beschreibung?

Nein. Das Feld Notizen (Attribut info) ist auf die gleiche Weise abfragbar. Für Zugangsdaten ist kein AD-Freitextfeld geeignet.

Wie finde ich solche Einträge, ohne selbst ein Risiko einzugehen?

Mit einer reinen Leseabfrage wie im Abschnitt „So prüfst Du Deine Umgebung". Führe sie mit einem Administratorkonto aus, behandle die Ausgabe vertraulich und lösche sie nach der Auswertung. Wenn Du unsicher bist, lass die Prüfung von einem IT-Dienstleister durchführen. Unser IT-Sicherheitscheck zeigt Lücken unter anderem bei Berechtigungen und Passwortrichtlinien auf.

Was nehme ich für Dienstkonten stattdessen?

Wenn die Software es unterstützt, ein gMSA: Windows verwaltet das Passwort selbst. Für alles andere ein Passwort-Manager mit langem Zufallspasswort und Zugriff nur für Berechtigte. Für lokale Administratorkonten auf PCs und Servern ist Windows LAPS der vorgesehene Weg.

Müssen wir so einen Fund melden?

Das lässt sich nicht pauschal beantworten. Ein Passwort im Beschreibungsfeld allein löst nicht automatisch eine Meldepflicht aus. Wenn es aber Hinweise auf einen tatsächlichen Zugriff oder Datenabfluss gibt, ist zu prüfen, ob eine Meldung nach DSGVO oder NIS2 nötig ist. Hole dafür die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten oder rechtlichen Rat hinzu.

Wie oft sollten wir prüfen?

Mindestens einmal im Quartal und zusätzlich bei jedem Wechsel von Administratoren, nach größeren Änderungen an der Domäne und nach Sicherheitsvorfällen.

Fazit

Ein Passwort im Beschreibungsfeld ist eine der einfachsten Schwachstellen, die ein Angreifer mit einem beliebigen Domänenkonto findet, und eine der einfachsten, die Du selbst beseitigen kannst. Prüfe Deine Umgebung, tausche gefundene Passwörter aus und gib Dienstkonten und lokalen Administratoren eine passende Passwortverwaltung. Mit einer einfachen Regel und einer Quartalsprüfung bleibt das Problem gelöst.

Wenn Du Unterstützung bei der Prüfung Deiner Active-Directory-Umgebung möchtest, sprich uns an: Wir schauen uns das gemeinsam mit Dir an, herstellerneutral und mit Augenmaß. Einen Überblick über unsere Leistungen findest Du unter IT-Sicherheit.