Active Directory Klartextpasswort Umkehrbare Verschluesselung: Die userPassword-Falle erklärt

Active Directory Klartextpasswort Umkehrbare Verschluesselung

Active Directory Klartextpasswort Umkehrbare Verschluesselung ist eine der wenigen Fehlkonfigurationen, die den üblichen Angreifer-Workflow komplett überspringt — kein Hash zum Knacken, kein Ticket zum Relayen, sondern ein Passwort im Klartext, das direkt im Verzeichnis liegt, anders als ein gestohlener NT-Hash, der über Pass-the-Hash wiederverwendet wird. Active Directory ist so konzipiert, dass niemals eine nutzbare Kopie eines Passworts gespeichert wird: Jeder unicodePwd-Wert wird als Einweg-Hash (NT-Hash sowie Kerberos-Langzeitschlüssel) gespeichert, bevor er die Datenbank erreicht, und das Attribut selbst kann über LDAP nicht ausgelesen werden. Microsofts MS-SAMR-Protokolldokumentation benennt explizit den einen Fall, der diese Garantie aufhebt: Die Speicherung des Klartextpassworts für ein Objekt wird nur konfiguriert, wenn der Wert Effective-PasswordReversibleEncryptionEnabled des Kontos gesetzt ist, oder wenn dessen Attribut userAccountControl das Bit ENCRYPTED_TEXT_PWD_ALLOWED (0x0080) enthält — danach schreibt der nächste Vorgang zum Setzen oder Ändern des Passworts eine entschlüsselbare Kopie nach supplementalCredentials.

Dieser Artikel behandelt zwei unterschiedliche Fehlermodi auf Attributebene, die beide damit enden, dass ein Angreifer ein nutzbares Klartext-Credential direkt aus dem Verzeichnis erhält:

• Das veraltete LDAP-Attribut userPassword, das in manchen Umgebungen direkt mit einer Klartext-Zeichenkette befüllt wird.
• Das Flag für umkehrbare Verschlüsselung in userAccountControl, das jedem Domain Controller mitteilt, neben den üblichen Hashes zusätzlich eine entschlüsselbare Kopie des Passworts vorzuhalten.

Beide sind im Audit-Katalog von etc-collector als kritisch eingestuft (PASSWORD_CLEARTEXT_STORAGE, REVERSIBLE_ENCRYPTION), weil die Kompromittierung eines der beiden dem Angreifer das Passwort im Klartext liefert — nicht nur einen Hash zum Knacken oder Relayen. Dieser Unterschied ist operativ relevant: Ein geknackter Hash oder eine relayte Session lässt sich eindämmen, indem man ein Credential rotiert und prüft, was damit erreichbar war. Ein wiederhergestelltes Klartextpasswort wird dagegen häufig anderswo wiederverwendet — bei privaten Konten, anderen Systemen, anderen Domänen —, sodass der Blast Radius beider Expositionsarten weit über das AD-Objekt hinausreicht, in dem sie gefunden wurden.

Funktionsweise

Das Attribut userPassword

userPassword ist ein Standard-LDAP-Attribut (definiert außerhalb von Microsofts Schema, in von RFC 4519 abgeleiteten Verzeichnisstandards), das Active Directory unter bestimmten Bedingungen ebenfalls berücksichtigt. Gemäß MS-ADTS §3.1.1.3.1.5.2 erlaubt AD Clients das Schreiben und Verwenden von userPassword zum Setzen eines Kontopassworts nur, wenn:

• der DC als AD LDS läuft, oder
• der DC ein AD DS ist, die Domänenfunktionsebene mindestens Windows Server 2003 entspricht, und
• die Heuristik fUserPwdSupport im Attribut dSHeuristics aktiviert ist.

Ist diese Heuristik ausgeschaltet (Standard bei AD DS), ist userPassword lediglich ein gewöhnliches, nicht indiziertes Attribut ohne besondere Semantik — und genau das ist die Falle: Viele Administratoren und Provisioning-Skripte (LDAP-Migrationstools, HR-Sync-Jobs, veraltete Unix/LDAP-Integrationen) schreiben aus Gewohnheit oder Interoperabilitätsgründen weiterhin ein Klartextpasswort in userPassword. Anders als unicodePwd ist dieses Attribut für jeden mit generischen Leserechten auf das Objekt lesbar — eine simple LDAP-Suche (userPassword=*) kann also jeden dort jemals geschriebenen Klartextwert auslesen, ganz ohne Privilege Escalation, ohne Hash-Cracking, ohne Relay.

ldapsearch -x -H ldap://dc01.corp.local -D "[email protected]" -W \
  -b "DC=corp,DC=local" "(userPassword=*)" sAMAccountName userPassword

Das UAC-Flag für umkehrbare Verschlüsselung

Der zweite Mechanismus ist das Bit ENCRYPTED_TEXT_PWD_ALLOWED (dezimal 128 / hex 0x0080) in userAccountControl, das am Benutzerobjekt als Attribut ms-DS-User-Encrypted-Text-Password-Allowed und im AD-PowerShell-Modul als Kontoeigenschaft AllowReversiblePasswordEncryption sichtbar ist. Das Setzen dieses Flags schreibt nicht selbst ein Klartextpasswort — es ändert, was bei der nächsten Passwortvergabe oder -änderung passiert: AD speichert das neue Passwort zusätzlich zu den üblichen Hashes in supplementalCredentials, und zwar in einer Form, die sich mit dem eigenen Verschlüsselungsschlüssel der Domäne entschlüsseln lässt.

Dieses Flag existiert, um veraltete Authentifizierungsprotokolle zu unterstützen, die das tatsächliche Passwort benötigen, um eine Challenge-Response zu berechnen — am häufigsten CHAP für RADIUS/IAS-Einwahl und VPN sowie ältere IIS-Digest-Authentication-Implementierungen. Microsofts eigene Sicherheitsrichtlinien-Dokumentation macht den Kompromiss unmissverständlich klar: Das Aktivieren "kommt im Wesentlichen dem Speichern von Klartext-Versionen der Passwörter gleich" und sollte niemals domänenweit eingeschaltet werden, außer eine Anwendung benötigt es tatsächlich.

Braucht eine Domäne dies für eine kleine Gruppe veralteter Service-Konten, ist eine enge Eingrenzung wichtig: Ein Fine-Grained-Password-Policy-Objekt (Password Settings Object) kann msDS-PasswordReversibleEncryptionEnabled gezielt für genau die OU oder Gruppe setzen, die es benötigt — statt die Einstellung "Kennwörter mit umkehrbarer Verschlüsselung speichern" in der Default Domain Policy für jedes Konto der Domäne umzulegen.

🚨 Gefahr: MITRE ATT&CK T1556.005 beschreibt dies als aktive Angreifer-Technik, nicht nur als veraltete Fehlkonfiguration: Mit ausreichenden Rechten kann ein Angreifer Set-ADUser -AllowReversiblePasswordEncryption $true gegen ein Zielkonto ausführen, auf einen Passwort-Reset warten (oder ihn erzwingen) und anschließend das Klartextpasswort aus dem nächsten gespeicherten Credential des Kontos wiederherstellen — eine einzige Schreibberechtigung wird so zu einer dauerhaften Backdoor zum Credential-Harvesting, die eine Passwortrotation übersteht.

Warum das in modernen Umgebungen weiterhin vorkommt

Keiner der beiden Mechanismen ist ein Relikt, das nur Windows-2000-Domänen betrifft. userPassword taucht immer dann wieder auf, wenn eine Organisation Identity-Synchronisierungstools betreibt, die ursprünglich für OpenLDAP oder ein anderes RFC-4519-Verzeichnis gebaut wurden und ohne Anpassung gegen Active Directory laufen — der Sync-Job schreibt das Feld, für das er gebaut wurde, und nichts in AD hält ihn davon ab, sofern dSHeuristics dies zulässt. Umkehrbare Verschlüsselung kehrt auf dieselbe Weise zurück: Ein RADIUS-Appliance, ein alter VPN-Concentrator oder eine alte Intranet-Anwendung mit IIS Digest Authentication wird einmal konfiguriert, die domänenweite Richtlinie wird umgelegt, damit es funktioniert, und die Einstellung überlebt die Anwendung, die sie benötigte, klaglos — oft jahrelang, für jedes Konto der Domäne, lange nachdem sich niemand mehr erinnert, warum sie existiert.

Beide Fälle teilen dieselbe Grundursache: Die Einstellung ist ein domänen- oder objektweiter Schalter, der tatsächliche Bedarf jedoch fast immer eng begrenzt — eine Anwendung, eine Integration, ein veraltetes Protokoll. Nichts erzwingt eine Überprüfung, wenn die Abhängigkeit wegfällt, sodass die Exposition als reine technische Schuld bestehen bleibt, bis ein Audit — oder ein Angreifer — sie findet. Sie gehört auf dieselbe Beobachtungsliste wie die häufigsten Active-Directory-Sicherheitsfehlkonfigurationen, die Jahre über ihre ursprüngliche Begründung hinaus überdauern.

Erkennung

# Konten mit aktuell aktivierter umkehrbarer Verschlüsselung
Get-ADUser -Filter {AllowReversiblePasswordEncryption -eq $true} `
  -Properties AllowReversiblePasswordEncryption, PasswordLastSet |
  Select-Object SamAccountName, PasswordLastSet

# Äquivalenter LDAP-Bitwise-AND-Filter (Matching-Rule-OID 1.2.840.113556.1.4.803)
Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=128)" `
  -Properties userAccountControl | Select-Object SamAccountName

Da userPassword ein generisches Attribut ist, das AD standardmäßig weder indiziert noch besonders schützt, ist ein geplanter LDAP-Sweep nach (userPassword=*) domänenweit der einzig verlässliche Weg, es zu erkennen; es gibt kein dediziertes Security-Event für das Schreiben in dieses Attribut, daher ist wiederkehrendes Re-Auditing ebenso wichtig wie der erste Sweep.

Remediation

1. Erst auditieren, dann handeln. Führen Sie beide obigen Abfragen domänenweit aus und dokumentieren Sie jeden Treffer — das Umlegen des Flags oder Leeren von userPassword erzwingt einen Passwortwechsel für dieses Konto, planen Sie die Rotation daher zuerst mit den Konto-Ownern ab.
2. Umkehrbare Verschlüsselung domänenweit deaktivieren über Gruppenrichtlinie (Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Kontorichtlinien > Kennwortrichtlinien > „Kennwörter mit umkehrbarer Verschlüsselung speichern" = Deaktiviert), sofern keine konkrete Abhängigkeit von veraltetem CHAP/RADIUS oder IIS Digest Authentication besteht.
3. Besteht eine legitime Abhängigkeit, grenzen Sie diese mit einer Fine-Grained Password Policy (msDS-PasswordReversibleEncryptionEnabled) ein, angewendet nur auf die OU oder Gruppe, die diese Anwendung betreibt — niemals domänenweit.
4. Alle gefundenen userPassword-Werte leeren und fUserPwdSupport in dSHeuristics wieder deaktivieren, sofern der DC nicht absichtlich als AD LDS läuft oder eine dokumentierte Integration dies benötigt.
5. Für jedes betroffene Konto einen Passwort-Reset erzwingen. Das Deaktivieren des Flags oder Leeren des Attributs entfernt bereits nach supplementalCredentials geschriebenes Credential-Material nicht rückwirkend — nur der nächste Passwortwechsel tut das.
6. Schreibzugriff einschränken auf userAccountControl und userPassword für Standardnutzer; beide sollten nur von Tier-0-Identity-Administration änderbar sein, und jede GenericAll/GenericWrite-Berechtigung, die dorthin reicht, verdient dieselbe Prüfung wie ein Pfad zu Domain Admin.
7. Event ID 4738 an Ihr SIEM anbinden mit einem Alert, sobald Encrypted Text Password Allowed in der Liste der geänderten Attribute erscheint, mindestens für privilegierte und Service-Konten, und die LDAP-Sweeps wiederkehrend statt einmalig ausführen.
8. Jede verbleibende Ausnahme dokumentieren. Braucht eine veraltete Anwendung tatsächlich noch umkehrbare Verschlüsselung, dokumentieren Sie Owner, Review-Datum und Abschaltplan — eine undokumentierte Ausnahme ist im nächsten Audit nicht von einer unbemerkten zu unterscheiden.

Wie EtcSec das erkennt

Der Audit-Katalog von EtcSec führt beide Mechanismen als getrennte, kritische Prüfungen: PASSWORD_CLEARTEXT_STORAGE markiert jedes Objekt, bei dem userPassword einen Wert enthält, und REVERSIBLE_ENCRYPTION markiert jedes Konto mit aktiviertem AllowReversiblePasswordEncryption (dem UAC-Bit ENCRYPTED_TEXT_PWD_ALLOWED). Beide liegen in der Kategorie Password neben verwandten Prüfungen wie Kennwortrichtlinien-Konformität und GPO-SYSVOL-cPassword-Geheimnissen — zusammen decken sie die wenigen Wege ab, auf denen ein Verzeichnis am Ende ein Passwort speichert, das ein Angreifer nicht einmal knacken muss.