GPP-Kennwörter (cpassword) finden und entfernen

Über die Gruppenrichtlinieneinstellungen (Group Policy Preferences, GPP) konnten Administratoren einst per GPO Kennwörter lokaler Konten, Dienst-Anmeldeinformationen, Ausführungskonten geplanter Aufgaben, Anmeldeinformationen für Laufwerkszuordnungen und Kennwörter für Datenquellen festlegen. Das Kennwort wurde in SYSVOL als Attribut cpassword gespeichert, AES-256-verschlüsselt mit einem Schlüssel, den Microsoft in seiner Protokolldokumentation veröffentlicht hatte. SYSVOL ist für jeden authentifizierten Benutzer lesbar, und Werkzeuge wie Get-GPPPassword sowie die entsprechenden Module gängiger Angriffsframeworks entschlüsseln den Wert in einer Sekunde. Die übliche Beute ist ein Kennwort des lokalen Administrators, das auf allen Arbeitsstationen und Servern gleich ist — und aus einem einzigen gephishten Benutzer Lateral Movement über die gesamte Umgebung macht.

MS14-025 hat im Mai 2014 den Editor geschlossen, vorhandene Werte aber belassen, und sie werden bei Bewertungen noch heute gefunden. Der Leitfaden zu Gruppenrichtlinien und SYSVOL zeigt die grundlegende SYSVOL-Suche. Dieser Leitfaden behandelt die vollständige Aufgabe: jeden Ort, an dem sich ein cpassword verstecken kann, die Ermittlung des jeweils offengelegten Kontos, den ordnungsgemäßen Kennwortwechsel und die Sicherstellung, dass es nicht zurückkehrt.

Wo cpassword-Werte liegen

Einstellungselemente, die ein Kennwort enthalten konnten, schreiben es in diese Dateien innerhalb der Ordner Machine\Preferences oder User\Preferences einer GPO:

Dieselben XML-Dateien existieren auch außerhalb des aktiven Policies-Ordners:

• GPO-Sicherungen, erstellt mit der GPMC oder Backup-GPO, oft auf Admin-Dateifreigaben oder in Repositories der Änderungskontrolle.
• Clientseitige Caches: Jeder Client bewahrt eine Kopie der angewendeten Einstellungs-XML unter %ProgramData%\Microsoft\Group Policy\History\{GUID}\ (Computereinstellungen) und %LocalAppData%\Microsoft\Group Policy\History\ (Benutzereinstellungen) auf, die auch in VM-Vorlagen und Datenträgerimages landet.
• Veraltete SYSVOL-Kopien, die nach einer Migration von FRS zu DFSR oder durch manuelles Kopieren auf DCs zurückgeblieben sind (SYSVOL.bak, SYSVOL_old).
• Skripte in NETLOGON und in GPO-Skriptordnern, die zwar kein cpassword, aber häufig Klartext-Anmeldeinformationen für dieselben Konten enthalten.

Messen: jedes Vorkommen finden

Parsen Sie die XML-Dateien, statt sie mit grep zu durchsuchen, damit Sie ermitteln können, zu welchem Konto jeder Wert gehört. Das Skript meldet nur das Vorhandensein des Werts, niemals den Wert selbst.

function Find-GppCpassword {
    param([Parameter(Mandatory)] [string[]] $Path)
    Get-ChildItem -Path $Path -Recurse -Include Groups.xml, Services.xml, ScheduledTasks.xml,
        Drives.xml, DataSources.xml, Printers.xml -ErrorAction SilentlyContinue |
    ForEach-Object {
        $file = $_.FullName
        Select-Xml -Path $file -XPath '//*[@cpassword]' | ForEach-Object {
            $n = $_.Node
            if ($n.cpassword) {
                [pscustomobject]@{
                    File    = $file
                    GpoGuid = if ($file -match '\{([0-9A-Fa-f-]{36})\}') { $Matches[1] }
                    Item    = $n.ParentNode.name
                    Account = @($n.userName, $n.accountName, $n.runAs, $n.username, $n.newName) |
                                  Where-Object { $_ } | Select-Object -First 1
                    Changed = $n.ParentNode.changed
                }
            }
        }
    }
}

$dns = (Get-ADDomain).DNSRoot
$hits = Find-GppCpassword -Path "\\$dns\SYSVOL\$dns\Policies", 'D:\GPOBackups'
$hits | ForEach-Object {
    $gpo = if ($_.GpoGuid) { Get-GPO -Guid $_.GpoGuid -ErrorAction SilentlyContinue }
    $_ | Add-Member -NotePropertyName GpoName -NotePropertyValue $gpo.DisplayName -PassThru
} | Format-Table GpoName, Item, Account, Changed, File -AutoSize

Leere Attribute cpassword="" werden ignoriert, da sie kein Geheimnis enthalten. Ein Treffer ohne auflösbaren GpoName verweist meist auf eine Sicherung oder einen verwaisten GPT-Ordner, dessen GPC gelöscht wurde; verwaiste Ordner sind weiterhin für alle lesbar und müssen ebenfalls entfernt werden.

Suchen Sie auf jedem DC nach übrig gebliebenen SYSVOL-Kopien sowie auf einer Stichprobe von Clients und auf Ihren Golden Images nach zwischengespeicherten Kopien:

# Auf jedem DC
Get-ChildItem C:\Windows -Directory -Filter 'SYSVOL*' | Select-Object FullName

# Auf einem Client oder einem eingebundenen Image
Find-GppCpassword -Path "$env:ProgramData\Microsoft\Group Policy\History"

Auditieren: ermitteln, was jeder Wert offenlegt

Beantworten Sie für jeden Treffer drei Fragen, bevor Sie die GPO anfassen:

1. Welches Konto? Ein Groups.xml-Element mit userName="Administrator" (oder einem umbenannten integrierten Konto über newName) legt den lokalen Administrator auf jedem Computer im Geltungsbereich der GPO offen. Ein Element in Services.xml oder ScheduledTasks.xml legt meist ein Domänen-Dienstkonto offen.
2. Wo wurde es angewendet? Prüfen Sie Verknüpfungen und Sicherheitsfilterung der GPO mit Get-GPOReport -Guid <id> -ReportType Html. Ein Kennwort für den lokalen Administrator, das auf Server und Arbeitsstationen gleichermaßen angewendet wurde, bedeutet, dass dieselbe Anmeldeinformation in beiden Tiers funktioniert.
3. Ist es noch gültig? Vergleichen Sie bei Domänenkonten pwdLastSet mit dem Zeitstempel changed des Elements. Wurde das Kennwort zuletzt vor oder an diesem Datum gesetzt, ist der SYSVOL-Wert mit ziemlicher Sicherheit aktuell.

Get-ADUser svc-backup -Properties pwdLastSet, lastLogonTimestamp, memberOf |
    Select-Object Name, @{n='PwdLastSet';e={[datetime]::FromFileTime($_.pwdLastSet)}},
        @{n='LastLogon';e={[datetime]::FromFileTime($_.lastLogonTimestamp)}}, memberOf

Um die Tragweite eines Eintrags für den lokalen Administrator abzuschätzen, zählen Sie die Computer im Geltungsbereich der GPO. Die folgende Abfrage durchläuft jede OU, mit der die GPO verknüpft ist; passen Sie sie an, wenn die GPO zusätzlich per Sicherheitsfilterung auf eine Gruppe beschränkt ist.

$guid = '<GpoGuid from the scan>'   # z. B. 6AC1786C-016F-11D2-945F-00C04FB984F9
Get-ADObject -LDAPFilter "(gPLink=*$guid*)" -SearchBase (Get-ADDomain).DistinguishedName |
    ForEach-Object {
        [pscustomobject]@{
            LinkedTo  = $_.DistinguishedName
            Computers = (Get-ADComputer -SearchBase $_.DistinguishedName -Filter * | Measure-Object).Count
        }
    }

Umfasst die Zählung Server und Arbeitsstationen gemeinsam, hat das Kennwort Tiers überbrückt: Wer es auf einer Arbeitsstation abgegriffen hat, konnte sich mit demselben Konto an Servern anmelden. Halten Sie diese Tatsache im Befund fest, denn sie bestimmt, welchen Teil der Umgebung Sie als potenziell kompromittiert betrachten sollten.

Ist das offengelegte Konto privilegiert (Mitglied einer beliebigen Administratorgruppe oder ein Dienstkonto mit Rechten auf Tier-0-Systemen), behandeln Sie den Fall als möglichen Sicherheitsvorfall: Prüfen Sie seinen Anmeldeverlauf auf den DCs (Ereignisse 4624 und 4768), bevor der Kennwortwechsel die Spuren einer Wiederverwendung vernichtet.

Erzwingen: ersetzen, entfernen, wechseln

Die Reihenfolge ist entscheidend. Ersetzen Sie zuerst den Mechanismus, sonst legt das Entfernen der Einstellung lahm, was sie bisher erledigt hat. Planen Sie die Arbeit als eine Änderung pro offengelegtem Konto statt als eine Änderung pro GPO: Dasselbe Dienstkonto taucht oft in mehreren GPOs auf, und wenn Sie es wechseln, während eine davon noch das alte Kennwort verteilt, legt die nächste Gruppenrichtlinienaktualisierung entweder den Dienst lahm oder setzt — bei lokalen Konten — das Kennwort auf den offengelegten Wert zurück.

• Kennwörter lokaler Administratoren → Stellen Sie Windows LAPS auf denselben OUs bereit, bestätigen Sie, dass Kennwörter gesichert werden, und löschen Sie dann das Element für lokale Benutzer und Gruppen. LAPS wechselt das lokale Kennwort auf jedem Rechner sofort — das ist zugleich Ihr Schritt für den Kennwortwechsel.
• Konten für Dienste und geplante Aufgaben → Stellen Sie auf ein gMSA um, sofern die Anwendung es unterstützt. Geplante Aufgaben können als gMSA (New-ScheduledTaskPrincipal -UserId 'CORP\svc-task$' -LogonType Password) oder als SYSTEM laufen, wenn die Aufgabe nur lokale Rechte benötigt.
• Laufwerkszuordnungen und Drucker mit Anmeldeinformationen → Entfernen Sie die Anmeldeinformation; der Zugriff sollte mit der eigenen Identität des Benutzers erfolgen, wobei die Freigabeberechtigungen das Nötige gewähren.
• Datenquellen → Verwenden Sie integrierte Authentifizierung oder einen von der Anwendung verwalteten Geheimnisspeicher.

Entfernen Sie dann das Element. Verwenden Sie den Gruppenrichtlinienverwaltungs-Editor (Computer- oder Benutzerkonfiguration > Einstellungen > der betreffende Knoten > Element löschen), statt die XML-Datei von Hand zu bearbeiten, damit sich die Versionsnummer der GPO erhöht und die Clients die Änderung verarbeiten. Enthält die GPO sonst nichts, heben Sie die Verknüpfung auf und löschen Sie die GPO, nachdem Sie sie an einem zugriffsgeschützten Ort gesichert haben.

Wechseln Sie zuletzt die Kennwörter. Setzen Sie bei Domänenkonten das Kennwort auf einen neuen Zufallswert zurück und aktualisieren Sie jeden Nutzer; besteht der Verdacht, dass ein Angreifer das Konto verwendet hat, prüfen Sie zusätzlich, worauf es Zugriff hatte, statt die Zurücksetzung als Abschluss zu betrachten. Wechseln Sie bei lokalen Konten, die nicht von LAPS abgedeckt sind, das Kennwort auf jedem Rechner im Geltungsbereich. Das Entfernen einer Einstellung setzt das bereits festgelegte Kennwort niemals zurück und ändert es auch nicht.

Löschen oder bereinigen Sie GPO-Sicherungen, die die Werte enthalten, entfernen Sie übrig gebliebene SYSVOL-Kopien und erstellen Sie Golden Images neu bzw. bereinigen Sie sie, wenn sie den clientseitigen Verlauf erfasst haben.

Überprüfen

Führen Sie Find-GppCpassword erneut gegen SYSVOL, die Sicherungsorte und eine Stichprobe von Clients nach deren nächster Gruppenrichtlinienaktualisierung aus; alle sollten nichts mehr liefern. Bestätigen Sie bei Domänenkonten, dass pwdLastSet nach dem Datum des Kennwortwechsels liegt. Bestätigen Sie bei LAPS-verwalteten Rechnern, dass ein LAPS-Kennwort existiert und kürzlich gesetzt wurde:

Get-LapsADPassword -Identity WS0142 | Select-Object ComputerName, PasswordUpdateTime, ExpirationTimestamp

Nehmen Sie den SYSVOL-Scan in einen geplanten Job auf, damit eine wiederhergestellte Sicherung oder eine importierte Legacy-GPO innerhalb eines Tages erkannt wird. PingCastle prüft ebenfalls auf GPP-Kennwörter und meldet eine Regression daher in Ihrer regelmäßigen Bewertung.

Eine nützliche Erkennungsebene ist ein bewusst platzierter Köder: eine Groups.xml in einer nicht verknüpften GPO mit einem cpassword für ein Honeytoken-Konto, das nie legitim verwendet wird. Jeder Authentifizierungsversuch mit diesem Konto (4625, 4771 oder 4776 auf DCs) bedeutet, dass jemand SYSVOL abgrast.

Was dabei ausfallen kann

• Entfernen eines Elements für lokale Benutzer und Gruppen, bevor LAPS bereitgestellt ist, hinterlässt Rechner mit einem bekannten, nicht verwalteten Kennwort für den lokalen Administrator. Stellen Sie zuerst LAPS bereit.
• Wechsel des Kennworts eines Domänen-Dienstkontos legt jeden Dienst, jede Aufgabe und jede Anwendung lahm, die noch das alte Kennwort verwendet. Inventarisieren Sie die Nutzer vor dem Zurücksetzen anhand der Anmeldedaten aus 4624/4768.
• Löschen von Anmeldeinformationen für Laufwerkszuordnungen führt zu „Zugriff verweigert“ für Benutzer, deren eigene Konten keine Freigabeberechtigungen haben; korrigieren Sie zuerst die Freigabe-ACLs.
• Löschen alter GPO-Sicherungen nimmt Ihnen die Möglichkeit, diese GPOs im damaligen Zustand wiederherzustellen. Bewahren Sie eine bereinigte Sicherung auf, wenn Sie den Verlauf benötigen.
• Die Köder-GPO wird von Ihren eigenen Bewertungswerkzeugen gemeldet; dokumentieren Sie sie, damit sie nicht von einem Kollegen „behoben“ wird.

Weiterführend: der Themenbereich Gruppenrichtlinien & SYSVOL, GPO-Berechtigungen auditieren und eine Kennwortrichtlinie, die funktioniert für die kontoseitigen Maßnahmen, die den Schaden jeder offengelegten Anmeldeinformation begrenzen.