PingCastle-Bewertung: vom AD-Bericht zum Maßnahmenplan

Ein PingCastle-Bericht ist der schnellste Weg zu einem ehrlichen Bild einer Active-Directory-Domäne. Er lässt sich aber auch leicht falsch verwenden. Manche Teams führen ihn einmal aus, sehen einen roten Wert, beheben die drei einfachsten Befunde und öffnen ihn nie wieder. Andere jagen den Wert auf null und verbringen Wochen mit Hygienearbeit geringer Wirkung, während ein Server mit uneingeschränkter Delegierung oder eine beschreibbare GPO auf der OU Domain Controllers offen bleibt. Dieser Leitfaden zeigt, wie Sie PingCastle sicher ausführen, die Ergebnisse so lesen, wie es das Bewertungsmodell vorsieht, und die Befunde in einen Behebungsplan mit Verantwortlichen, Reihenfolge und Überprüfung überführen.

Die übergreifende Bewertungsstrategie, einschließlich des Baseline-Abgleichs mit SCT und CIS und der Einordnung von PingCastle neben Purple Knight, finden Sie im Grundlagenleitfaden zu Bewertung, Sicherung und Wiederherstellung. In diesem Leitfaden geht es darum, von einem Bericht zu einem umgesetzten Plan zu gelangen.

Messen: den Health Check ausführen

Laden Sie PingCastle von der offiziellen Website auf eine Verwaltungsarbeitsstation oder eine Privileged Access Workstation herunter. Prüfen Sie die Dateisignatur und führen Sie das Werkzeug nicht auf einem DC aus. Starten Sie es als Standard-Domänenbenutzer. Der Health Check benötigt keine administrativen Rechte, und die Ausführung als Domain Admin exponiert lediglich eine Tier-0-Anmeldeinformation auf einem weiteren Computer.

# Die Binärdatei vor der ersten Verwendung prüfen
Get-AuthenticodeSignature .\PingCastle.exe | Select-Object Status, SignerCertificate

# Health Check gegen eine bestimmte Domäne
.\PingCastle.exe --healthcheck --server corp.example.com

PingCastle.exe ohne Argumente öffnet ein interaktives Menü; Option 1 ist derselbe Health Check. Jeder Lauf erzeugt zwei nach der Domäne benannte Dateien:

• ad_hc_<domain>.html, der Bericht für Menschen.
• ad_hc_<domain>.xml, die Daten für Trendanalysen und Skripte. Sie enthält detaillierte Daten über Ihre Domäne; bewahren Sie sie daher mit derselben Sorgfalt auf wie die HTML-Datei.

Führen Sie den Check einmal pro Domäne aus, einschließlich jeder untergeordneten Domäne und jeder Domäne, der Sie vertrauen. Der Abschnitt zu Vertrauensstellungen zeigt, was die gescannte Domäne exponiert; Risiken innerhalb einer vertrauenswürdigen Domäne erscheinen jedoch nur, wenn Sie diese Domäne scannen.

Auditieren: den Bericht richtig lesen

Die vier Werte

PingCastle gruppiert die Regeln in vier Kategorien, die jeweils von 0 (am besten) bis 100 bewertet werden:

Der Risikowert der Domäne ist der höchste der vier, nicht die Summe. Eine Domäne mit 15, 10, 0 und 85 erhält 85, denn eine einzige schlechte Kategorie genügt einem Angreifer. Das bedeutet auch: Solange Anomalies die schlechteste Kategorie ist, ändert die Behebung von Stale Objects nichts an der Kennzahl.

Reifegrade und Regel-IDs

Jede Regel hat eine ID mit einem Kategoriepräfix (S-, P-, T-, A-), einen Punktwert und einen Reifegrad von 1 bis 5. Befunde der Stufe 1 sind die kritischsten. Der Abschnitt zum Reifegrad im Bericht nennt die niedrigste Stufe, an der Ihre Domäne scheitert – eine bessere Fortschrittskennzahl für das Management als der rohe Wert. Der Sprung von Stufe 1 auf Stufe 3 ist eine echte Verbesserung, selbst wenn sich der Wert kaum bewegt.

Klappen Sie im HTML-Bericht jede Regel auf. Die Details listen die genauen betroffenen Objekte auf und verlinken auf die Dokumentation hinter der Regel. Arbeiten Sie immer mit der Objektliste, nicht mit dem Regeltitel.

Einstufen: aus Befunden einen Plan machen

Exportieren Sie die Regeln aus der XML-Datei, damit sie in einen Tracker übernommen werden können:

[xml]$hc = Get-Content .\ad_hc_corp.example.com.xml
$hc.SelectNodes('//HealthcheckRiskRule') |
  Select-Object RiskId, Category, Points, Rationale |
  Sort-Object Points -Descending |
  Export-Csv .\pingcastle-findings.csv -NoTypeInformation

Ordnen Sie jeden Befund einer von vier Gruppen zu:

1. Diese Woche beheben (Angriffspfad zu Tier 0). Alles, was einem Nicht-Admin einen Weg zur vollständigen Domänenkontrolle eröffnet. Beispiele sind uneingeschränkte Delegierung auf Servern, die keine DCs sind, gefährliche ACEs auf privilegierten Objekten, nicht standardmäßige Prinzipale mit DCSync-Rechten, GPP-Kennwörter, für ESC1 anfällige AD-CS-Vorlagen und der auf DCs laufende Druckwarteschlangendienst. Diese entsprechen direkt den Themen DCSync-Rechte, Entfernen uneingeschränkter Delegierung und Prüfung von Zertifikatvorlagen.
2. Projekte (erfordern Change-Management). Einstellungen, die Anwendungen beeinträchtigen können: LDAP-Signierung, NTLM-Einschränkungen, SMB-Signierung, Entfernen von RC4, Bereitstellung von LAPS. Versehen Sie jede mit einem Verantwortlichen, einer Pilotgruppe und einer Audit-Phase vor der Durchsetzung.
3. Hygiene (Sammelarbeit). Inaktive Konten, alte Computerobjekte, nie ablaufende Kennwörter bei Konten, die keine Dienstkonten sind. Automatisieren Sie diese, statt sie von Hand zu beheben.
4. Akzeptiertes Risiko. Eine dokumentierte Ausnahme mit einem fachlichen Verantwortlichen, einer kompensierenden Maßnahme und einem Überprüfungsdatum. PingCastle kennt Ihre Ausnahmen nicht; das Register gehört daher in Ihren Tracker.

Zwei Regeln sorgen für Ehrlichkeit. Erstens erhält jeder Punkt aus Gruppe 1 innerhalb weniger Tage einen Verantwortlichen und ein Datum. Zweitens werden die Kategorien Privileged Accounts und Trusts bei jedem Lauf erneut geprüft, weil sie sich am schnellsten ändern und am meisten zählen.

Ordnen Sie jeden Befund der Methode dieser Website zu: Messen (die Objektliste aus dem Bericht), Auditieren (Protokollierung für die Einstellung aktivieren, bevor Sie sie ändern), Durchsetzen, Überprüfen (der nächste PingCastle-Lauf). Die Härtungs-Checkliste liefert eine Standardreihenfolge, falls Sie eine brauchen.

Die Ergebnisse präsentieren

Die Leitung braucht nicht den HTML-Bericht. Sie braucht drei Dinge auf einer Seite: den aktuellen Reifegrad und seinen Trend, die Anzahl offener Befunde aus Gruppe 1 mit ihrem Alter und die Liste akzeptierter Risiken mit namentlich genannten Verantwortlichen. Führen Sie den rohen Wert im Anhang, denn er schwankt mit Regeländerungen und lädt zur falschen Diskussion ein.

Zeigen Sie für jede Domäne die Kategoriewerte nebeneinander. Eine Gesamtstruktur, deren Stammdomäne auf Reifegrad 3 steht, während eine übernommene untergeordnete Domäne auf Stufe 1 liegt, ist eine Gesamtstruktur auf Stufe 1, denn Vertrauensstellungen innerhalb einer Gesamtstruktur halten keinen Angreifer auf. Sagen Sie das ausdrücklich, damit die schwächste Domäne die Mittel erhält und nicht die sichtbarste.

Durchsetzen: planen und Trends verfolgen

Ein einzelner Bericht ist eine Momentaufnahme. Planen Sie den Health Check so ein, dass Abweichungen innerhalb einer Woche sichtbar werden:

$action  = New-ScheduledTaskAction -Execute 'C:\Tools\PingCastle\PingCastle.exe' `
  -Argument '--healthcheck --server corp.example.com' -WorkingDirectory 'D:\PingCastle\Reports'
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 6am
Register-ScheduledTask -TaskName 'PingCastle weekly' -Action $action -Trigger $trigger `
  -User 'CORP\svc-pingcastle' -Password (Read-Host 'Password')

Noch besser: Verwenden Sie ein gMSA als Identität der Aufgabe, damit kein Kennwort gespeichert wird. Bewahren Sie die XML-Dateien, mit Datum umbenannt, in einem Ordner auf, den nur das Sicherheitsteam lesen kann. Aktualisieren Sie PingCastle bewusst, nicht automatisch, und vermerken Sie die Version im Dateinamen jedes Berichts. Eine Regeländerung darf nie mit einer Änderung in Ihrer Domäne verwechselt werden.

Überprüfen

Führen Sie nach jedem Behebungssprint einen neuen Lauf durch und vergleichen Sie die Regelmengen statt der Werte:

[xml]$old = Get-Content .\2026-08-31_ad_hc_corp.example.com.xml
[xml]$new = Get-Content .\2026-09-28_ad_hc_corp.example.com.xml
$o = $old.SelectNodes('//HealthcheckRiskRule').RiskId
$n = $new.SelectNodes('//HealthcheckRiskRule').RiskId
Compare-Object $o $n | ForEach-Object {
  [pscustomobject]@{ RiskId = $_.InputObject; Change = if ($_.SideIndicator -eq '=>') {'NEW'} else {'FIXED'} }
}

Behandeln Sie jede NEW-Regel in Privileged Accounts oder Trusts als Sicherheitsvorfall, bis sie erklärt ist. Prüfen Sie mithilfe der Gruppen- und Vertrauensstellungsereignisse aus der Referenz der Ereignis-IDs, wer was geändert hat. Bestätigen Sie bei behobenen Punkten, dass die Objektliste leer ist – nicht nur, dass der Punktwert unter einen Schwellenwert gefallen ist.

Was dadurch nicht mehr funktioniert

Das Ausführen von PingCastle erfolgt rein lesend, doch wer auf Basis des Berichts handelt, ohne den Audit-Schritt einzuhalten, beschädigt etwas:

• Protokollbefunde direkt durchsetzen. LDAP-Signierung zu erzwingen, NTLMv1 zu deaktivieren oder RC4 zu entfernen, nur weil ein Bericht es sagt, ohne Audit-Phase, verursacht Ausfälle. Alte Appliances, Scanner und Java-Anwendungen fallen zuerst aus.
• Inaktive Konten massenhaft deaktivieren. „Inaktiv“ basiert auf lastLogonTimestamp, das bis zu 14 Tage hinterherhinken kann, und manche Dienstkonten authentifizieren sich auf eine Weise, die es nicht aktualisiert. Deaktivieren Sie in Etappen, verschieben Sie Konten in eine Quarantäne-OU und löschen Sie erst nach einer Wartezeit.
• Admins zu Protected Users hinzufügen. Das entzieht diesen Konten NTLM, DES, RC4 und die Delegierung von Anmeldeinformationen. Testen Sie den Arbeitsablauf jedes Admins vor einer Massenänderung.
• Alarme von Sicherheitswerkzeugen. Der Health Check führt breite LDAP-Abfragen durch, die Defender for Identity oder Ihre Honeytokens als Aufklärung melden können. Teilen Sie dem SOC mit, welches Konto und welcher Host ihn ausführen, und nehmen Sie ihn bewusst von Köderregeln aus.

Weiterführende Lektüre: Der Bereich Bewertung, Sicherung & Wiederherstellung umfasst die übrigen Beiträge dieser Serie, Attack Path Management findet Wege zu Tier 0, die regelbasierte Scanner übersehen, und AD-Sicherungen vor Ransomware schützen behandelt die Maßnahme, die PingCastle nicht für Sie prüfen kann.