GPO SYSVOL cPassword Geheimnisse in Active Directory: Warum ein Patch von 2014 das Problem nicht behoben hat

GPO SYSVOL cPassword Geheimnisse in Active Directory: Was sie sind

GPO SYSVOL cPassword Geheimnisse in Active Directory zählen zu den ältesten Fehlkonfigurationen, die einfach nicht verschwinden wollen — und sind eine der häufigsten Active-Directory-Sicherheitsfehlkonfigurationen, die in Produktionsaudits noch heute gefunden werden. Sie stammen aus Group Policy Preferences (GPP), einer Funktion, die Microsoft in Windows Server 2008 eingeführt hat und mit der Administratoren lokale Benutzerkonten, zugeordnete Laufwerke, geplante Tasks, Dienste und Datenquellen per Group Policy verteilen konnten — für mehrere dieser Preference-Typen inklusive eines Benutzernamens und Passworts, das auf den Zielrechnern angewendet wird.

Diese Credentials wurden im Attribut cpassword der jeweiligen XML-Datei der Preference gespeichert (Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml, DataSources.xml), AES-256-verschlüsselt und in die SYSVOL-Freigabe der Domäne geschrieben — dieselbe Freigabe, die jeder Domain Controller repliziert und die jeder authentifizierte Benutzer (und standardmäßig auch Benutzer aus jeder vertrauenswürdigen Domäne) lesen kann, damit Client-Rechner ihre Group Policy Objects (GPOs) abrufen können.

Das Problem: Microsoft hat den privaten AES-Schlüssel, mit dem jeder cpassword-Wert verschlüsselt wird, in der eigenen Protokolldokumentation veröffentlicht, weil GPP eine Möglichkeit brauchte, den Wert client-seitig während der Policy-Verarbeitung zu entschlüsseln. Jeder authentifizierte Domänenbenutzer, der SYSVOL lesen kann — und das ist konstruktionsbedingt jeder — kann den verschlüsselten String finden und ihn in Sekunden mit frei verfügbaren Tools entschlüsseln. Die Exposition wurde erstmals 2012 öffentlich vom Sicherheitsforscher Chris Campbell (obscuresec) dokumentiert, der einen PowerShell-Proof-of-Concept veröffentlichte, um diese Werte zu finden und zu entschlüsseln — lange bevor Microsoft einen Fix auslieferte.

Warum taucht das Problem ein Jahrzehnt später immer noch auf

Wenn MS14-025 bereits 2014 ausgeliefert wurde, warum finden Audits heute noch aktive cpassword-Einträge? Ein paar wiederkehrende Muster erklären das:

• Domänenmigrationen und Akquisitionen. GPOs werden häufig komplett aus einer Legacy-Domäne migriert — inklusive aller Preferences, die konfiguriert wurden, bevor die übernommene Umgebung überhaupt gepatcht oder geprüft wurde.
• Wiederhergestellte GPO-Backups. GPO-Backups, die vor 2014 erstellt und Jahre später wiederhergestellt werden, führen genau die XML wieder ein, die der Patch für die Zukunft verhindern sollte — der Patch schützt den Editor, nicht eine Restore-Operation.
• MSP- und vendor-verwaltete Umgebungen. Managed Service Provider, die eine Standard-GPO-Vorlage über mehrere Kunden hinweg wiederverwenden, können dasselbe exponierte lokale Admin-Credential in jede Umgebung propagieren, die diese Vorlage berührt.
• Kein periodischer SYSVOL-Review. Anders als ein laufender Dienst läuft SYSVOL-Inhalt nicht ab und wird nicht durch reguläres Patching markiert — nichts erzwingt einen erneuten Scan, wenn nicht jemand aktiv einen durchführt.

Keiner dieser Wege erfordert, dass ein fehlkonfiguriertes System den Patch von 2014 ausgelassen hat. Sie erfordern nur, dass irgendwann in der Geschichte der Domäne ein cpassword-Wert in SYSVOL existierte und nie aktiv gesucht und entfernt wurde — genau deshalb ist proaktives Scannen, nicht Patch-Compliance, die Kontrolle, die diese Lücke tatsächlich schließt.

So funktioniert es

Microsoft hat einen Teil des Problems mit MS14-025 (CVE-2014-1812) adressiert, veröffentlicht am 13. Mai 2014 und ausgeliefert als Update KB2962486. Der Patch entfernte die „Password"-Felder aus dem Group-Policy-Preferences-Editor in der Group Policy Management Console (GPMC) und den Remote Server Administration Tools (RSAT), sodass Administratoren keine neuen GPP-Einträge mit Passwort mehr anlegen können (Microsoft Support: MS14-025).

Was KB2962486 nicht tut: rückwirkend cpassword-Werte entfernen, die bereits vor der Patch-Installation nach SYSVOL geschrieben wurden — und es hindert einen Angreifer nicht daran, zu entschlüsseln, was dort noch liegt. ANSSIs Leitfaden zur sicheren AD-Administration weist genau auf diese Lücke hin: Der Patch ändert, was der Editor einen Administrator künftig eingeben lässt, aber historische GPP-Objekte, die vor der Patch-Installation erstellt wurden, müssen manuell gesucht und bereinigt werden (ANSSI-PA-099).

Der AES-Schlüssel selbst ist kein Geheimnis, das ein Angreifer stehlen müsste — es ist derselbe statische 32-Byte-Schlüssel für jede Active-Directory-Domäne der Welt, von Microsoft dokumentiert und in der Sicherheitsforschung seit der ursprünglichen Offenlegung 2012 vielfach zitiert, später direkt in offensive Tools wie PowerSploit und CrackMapExec eingebaut (adsecurity.org: Finding Passwords in SYSVOL & Exploiting Group Policy Preferences).

Die Angriffskette

Einen übrig gebliebenen cpassword-Wert auszunutzen erfordert weder erhöhte Rechte noch einen Exploit — es ist eine Post-Authentication-Technik, die jedem Domänenbenutzer zur Verfügung steht, und oft auch jedem Benutzer in einem vertrauenswürdigen Forest.

Schritt 1 — SYSVOL nach cpassword durchsuchen

Ein Angreifer mit einem beliebigen gültigen Domänen-Credential (oder einem niedrig privilegierten Foothold) durchsucht die SYSVOL-Freigabe nach XML-Dateien, die das Attribut cpassword enthalten:

# Linux, mit gültigen Domänen-Credentials
crackmapexec smb <dc-ip> -u 'user' -p 'password' -M gpp_password

# Windows, PowerSploit
Import-Module .\Get-GPPPassword.ps1
Get-GPPPassword -Verbose

Schritt 2 — Entschlüsselung mit dem veröffentlichten AES-Schlüssel

Get-GPPPassword und gleichwertige Tools (Get-DecryptedCpassword, gpp-decrypt) wenden den öffentlich bekannten AES-Schlüssel auf den Base64-dekodierten cpassword-Wert an und liefern den Klartext sofort zurück — es gibt keinen Brute-Force- oder Cracking-Schritt, nur eine feste Entschlüsselungsroutine.

Schritt 3 — Das Credential wiederverwenden

Da GPP häufig genutzt wurde, um ein lokales Administratorkonto über viele Rechner hinweg zu standardisieren oder einen geplanten Task bzw. Dienst unter einem Domänen-Servicekonto laufen zu lassen, ist das wiedergewonnene Passwort oft direkt für laterale Bewegung oder Privilegieneskalation nutzbar — ganz ohne zusätzliche Technik. Ein einziger Groups.xml-Eintrag, der ein gemeinsames lokales Admin-Passwort domänenweit setzte, reicht aus, um jede Arbeitsstation zu kompromittieren, auf die diese GPO wirkt.

Erkennung

Um die Exposition direkt zu bestätigen, statt auf Log-Signale zu warten, gibt ANSSIs Leitfaden zur sicheren AD-Administration (ANSSI-PA-099) eine proaktive Ein-Zeilen-Prüfung an, die Auditoren von einem domänengebundenen System ausführen können:

:: <FQDN> durch den vollqualifizierten Namen (FQDN) der AD-Domäne ersetzen.
findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Jeder Treffer bedeutet, dass ein cpassword-Wert — gepatchtes Tooling hin oder her — heute noch in SYSVOL liegt (ANSSI-PA-099, Empfehlung R31, Listing 3). Da diese Prüfung statischen Dateiinhalt statt Live-Telemetrie liest, ist sie für einen Auditor der schnellste Weg zu einer definitiven Antwort, ohne auf Log-Retention warten zu müssen. Dasselbe Prinzip gilt für andere veraltete Credential-Lecks, die sich lohnen, im selben Durchgang zu prüfen, etwa Passwörter in AD-Beschreibungsfeldern. Für einen breiteren Überblick, was bei einem vollständigen Review priorisiert werden sollte, siehe unseren Leitfaden Active Directory Sicherheit auditieren.

Remediation

1. Bestätigen Sie, dass KB2962486 ausgerollt ist auf jedem System, das noch für die Bearbeitung von Group Policy über die native GPMC/MMC-Konsole (vor Windows Server 2016) oder über ältere RSAT-Tools (vor Windows 10) genutzt wird. Das verhindert, dass künftig neue Passwörter in GPP eingetragen werden.
2. Führen Sie den SYSVOL-Scan aus (obiger findstr-Befehl oder eine gleichwertige rekursive Suche) und durchsuchen Sie jede Groups.xml-, Services.xml-, ScheduledTasks.xml-, Printers.xml-, Drives.xml- und DataSources.xml-Datei über alle GPOs hinweg nach dem Attribut cpassword — einschließlich deaktivierter und nicht verlinkter GPOs, die bei manuellen Reviews häufig übersehen werden.
3. Rotieren Sie jedes gefundene Credential sofort. Das Löschen des XML-Eintrags macht ein Passwort, das bereits entschlüsselbar war, nicht ungültig; gehen Sie davon aus, dass es gelesen wurde, und handeln Sie entsprechend.
4. Entfernen Sie die GPP-Einstellung, statt ein leeres Passwortfeld zu hinterlassen — gemäß ANSSI-Empfehlung R32 sollte nie wieder ein Passwort in einer Group Policy Preference hinterlegt werden (ANSSI-PA-099, Empfehlung R32, S. 49). Unser praktischer Leitfaden zu den ANSSI-AD-Empfehlungen zeigt, wie sich eine solche Empfehlung in einen Rollout-Plan übersetzen lässt.
5. Ersetzen Sie GPP-verwaltete lokale Admin-Konten durch Windows LAPS, das pro Rechner ein eindeutiges, zufälliges Passwort rotiert und es als geschütztes AD-Attribut speichert statt als statische XML-Datei.
6. Wenden Sie dieselbe Sorgfalt auf An-/Abmeldeskripte an, die auf SYSVOL oder NETLOGON liegen — ANSSI-Empfehlung R31 wendet dasselbe Prinzip wiederverwendbarer Secrets auf jedes Skript an, das von niedriger privilegierten Konten lesbar ist, nicht nur auf GPP-XML. Ein Skript, das ein Laufwerk mit eingebettetem Servicekonto-Passwort mappt, ist genauso exponiert wie ein cpassword-Feld.
7. Härten Sie den Lesezugriff, wo machbar. SYSVOL und NETLOGON müssen für die Policy-Verarbeitung lesbar bleiben, aber prüfen Sie auf SYSVOL/NETLOGON-Berechtigungsdrift über die Standardeinstellung hinaus, und aktivieren Sie UNC Hardening für diese Freigaben, damit Clients beim Lesen Integrität und gegenseitige Authentifizierung validieren.
8. Wiederholen Sie den Scan nach jeder GPO-Backup-Wiederherstellung oder Domänenmigration — nicht nur einmal. Da dies die zwei häufigsten Wege sind, über die alte cpassword-Einträge wieder auftauchen, behandeln Sie das erneute SYSVOL-Scanning als festen Schritt in jedem Migrations-Runbook statt als einmalige Bereinigung, und weisen Sie dafür einen Owner zu, damit es nicht davon abhängt, dass sich jemand daran erinnert.

Wie EtcSec das erkennt

EtcSecs Active-Directory-Audit markiert diese Exposition als GPO_PASSWORD_IN_SYSVOL, eine Prüfung mit kritischem Schweregrad, die die Preference-XML jeder GPO nach einem befüllten cpassword-Attribut durchsucht — einschließlich deaktivierter oder nicht verlinkter GPOs, die manuelle Reviews häufig übersehen. Sie ist gepaart mit SYSVOL_NETLOGON_PERMISSIONS, das Lese-/Schreibzugriff auf die SYSVOL- und NETLOGON-Freigaben auf Drift über die erwartete Baseline hinaus prüft. Zusammen decken die beiden Checks sowohl die historische GPP-Exposition als auch die laufende Berechtigungshygiene ab, die nötig ist, damit SYSVOL nicht erneut zur Müllhalde für wiederverwendbare Secrets wird.