AD-Bewertung, Sicherung und Gesamtstruktur-Wiederherstellung

Härtungsmaßnahmen verfallen lautlos. Eine Gruppenrichtlinieneinstellung weicht ab, ein Dienstkonto wurde während eines Vorfalls in Domain Admins aufgenommen und nie wieder entfernt, eine neue Vertrauensstellung kam mit einem Migrationsprojekt und wurde nie überprüft. Bewertung, Sicherung und geübte Wiederherstellung bilden die Governance-Ebene, die solche Abweichungen erkennt und garantiert, dass Sie – wenn, nicht falls, etwas schiefgeht – sowohl die Belege haben, um es zu wissen, als auch einen getesteten Weg zurück zu einer sauberen Gesamtstruktur.

Dieser Beitrag behandelt die Durchführung und Auswertung von Sicherheitsbewertungen, den Abgleich der Konfiguration mit dem Security Compliance Toolkit von Microsoft und den CIS Benchmarks, LAPS und Tiering als wiederkehrende Prüfungen statt einmaliger Projekte, den Schutz von Tier-0-Sicherungen und das Üben einer vollständigen Gesamtstruktur-Wiederherstellung.

Werkzeuge zur Sicherheitsbewertung

Drei Werkzeuge decken das meiste ab, was Sie brauchen, und sie ergänzen sich, statt sich zu überschneiden:

Führen Sie PingCastle (oder Purple Knight) als geplante Aufgabe aus, nicht als einmalige Aktion:

# PingCastle im Modus healthcheck, geplant über die Aufgabenplanung
PingCastle.exe --healthcheck --server dc01.domain.com --level Full

Den Wert richtig lesen: Jagen Sie nicht 100/100 hinterher – manche Befunde sind für Ihre Umgebung Fehlalarme oder ein akzeptiertes Risiko (dokumentiert, z. B. eine Legacy-Anwendung, die ein älteres Protokoll benötigt). Entscheidend ist:

1. Kritische Befunde nehmen von Durchlauf zu Durchlauf ab, niemals zu.
2. Jeder neue Befund in Trusts oder Privileged Accounts wird innerhalb von Tagen bewertet, nicht erst im nächsten Quartalszyklus – diese Kategorien ändern sich am schnellsten und sind für Angreifer am häufigsten relevant.
3. Befunde sind mit einem Ticket und einem Verantwortlichen verknüpft, statt nur immer wieder geprüft und erneut akzeptiert zu werden.

Baseline-Abgleich: Microsoft SCT und CIS Benchmarks

Bewertungsscanner informieren über Risiken auf Ebene der AD-Objekte (veraltete Konten, fehlkonfigurierte Vertrauensstellungen, Delegierung). Einen Abgleich der Gruppenrichtlinien mit einer Baseline, der zeigt, ob Ihre tatsächlichen GPOs einer geprüften Sicherheits-Baseline entsprechen, ersetzen sie in der Regel nicht vollständig.

• Microsoft Security Compliance Toolkit (SCT): liefert Baseline-GPO-Sicherungen für jede unterstützte Windows-Server-Version sowie Policy Analyzer, ein GUI-/CLI-Werkzeug, das Ihre Produktions-GPOs mit der Baseline vergleicht und jede abweichende Einstellung markiert.
• CIS Benchmarks für Windows Server / Active Directory: eine unabhängig gepflegte, präskriptivere Baseline; viele regulierte Umgebungen verlangen ausdrücklich CIS-Konformität statt (oder zusätzlich zu) der Microsoft-Baseline.

Vorgehen:

# Aktuelle GPOs für den Vergleich exportieren
Get-GPO -All | ForEach-Object { Backup-GPO -Guid $_.Id -Path "C:\GPOBackups" }

Laden Sie anschließend sowohl die exportierten Sicherungen als auch die GPO-Sicherungen der SCT-/CIS-Baseline in Policy Analyzer und erstellen Sie einen Differenzbericht. Dokumentieren Sie Ausnahmen (Einstellungen, von denen Sie bewusst abweichen) mit Begründung und Verantwortlichem – Auditoren und Ihr zukünftiges Ich werden es Ihnen danken.

Wiederholen Sie diesen Abgleich, sobald Microsoft eine neue SCT-Baseline veröffentlicht (in der Regel passend zu jedem Feature-Update von Windows Server), und unabhängig davon mindestens zweimal im Jahr.

LAPS und Tiering als wiederkehrende Prüfungen, nicht als einmalige Projekte

Sowohl LAPS (Local Administrator Password Solution / Windows LAPS) als auch administratives Tiering (Tier 0 und privilegierter Zugriff) verkommen, wenn sie als Bereitstellungsprojekt statt als fortlaufende Maßnahme behandelt werden:

# Prüfen, ob LAPS Kennwörter tatsächlich rotiert und nicht nur installiert ist
# Windows LAPS (msLAPS-*-Attribute)
Get-ADComputer -Filter * -Properties msLAPS-PasswordExpirationTime |
  Where-Object { $_.'msLAPS-PasswordExpirationTime' -lt (Get-Date).AddDays(-35).ToFileTime() } |
  Select-Object Name
# Legacy Microsoft LAPS, nur wenn dessen Schemaerweiterung (ms-Mcs-AdmPwd*) installiert ist
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwdExpirationTime |
  Where-Object { $_.'ms-Mcs-AdmPwdExpirationTime' -lt (Get-Date).AddDays(-35).ToFileTime() } |
  Select-Object Name

# Prüfen, ob keine unerwarteten Konten in Tier-0-Gruppen gelandet sind
Get-ADGroupMember "Domain Admins" -Recursive | Select-Object Name, SamAccountName
Get-ADGroupMember "Enterprise Admins" -Recursive | Select-Object Name, SamAccountName

Planen Sie beide Prüfungen mindestens wöchentlich ein. Abweichungen bei Gruppenmitgliedschaften – ein Dienstkonto, das während eines Vorfalls zu Domain Admins hinzugefügt und nie entfernt wurde, ein Dienstleister mit befristetem Zugriff, der den Auftrag überdauert hat – gehören zu den häufigsten Arten, wie Tiering lautlos versagt, und sie bleiben unsichtbar, solange Sie nicht aktiv hinsehen. Korrelieren Sie mit den Ereignissen 4728/4732/4756, damit Sie wissen, wann und durch wen die Abweichung entstand, und nicht nur, dass sie existiert.

Tier-0-Sicherungen schützen

Die Systemstatussicherung eines Domänencontrollers ist faktisch eine Kopie jeder Anmeldeinformation der Domäne: die NTDS-Datenbank mit allen Kennworthashes und der krbtgt-Schlüssel, der jedes Kerberos-Ticket signiert. Schützen Sie sie entsprechend:

• Erstellen Sie Systemstatussicherungen, nicht nur Sicherungen auf Dateiebene oder VM-Snapshots, damit sowohl autoritative als auch nicht autoritative Wiederherstellungen korrekt funktionieren:

wbadmin start systemstatebackup -backupTarget:E: -quiet

• Speichern Sie Sicherungen offline, unveränderlich oder per Air Gap von der Produktion getrennt. Wenn eine Domain-Admin-äquivalente Anmeldeinformation (oder Ransomware, die eine erbeutet hat) Ihren Sicherungsspeicher erreichen und löschen kann, ist er keine Sicherung – sondern eine zweite Kopie desselben Guts, das der Angreifer bereits besitzt. Unveränderlicher Objektspeicher (Write-once, mit Aufbewahrungssperre) oder echte Offline- bzw. per Air Gap getrennte Medien sind beide akzeptabel; eine Sicherungsfreigabe in derselben Domäne, erreichbar mit denselben privilegierten Konten, ist es nicht.
• Beschränken Sie die Rechte von Sicherungsoperatoren – Backup Operators können über eine Systemstatussicherung die gesamte NTDS-Datenbank lesen, was diese Gruppe hinsichtlich der Vertraulichkeit faktisch Domain Admins gleichstellt. Prüfen Sie ihre Mitgliedschaft so streng wie die von Domain Admins.
• Testen Sie die Wiederherstellbarkeit, nicht nur den Abschluss der Sicherung. Ein Sicherungsauftrag, der Erfolg meldet, sagt Ihnen, dass er Daten geschrieben hat – nicht, dass sich diese Daten wiederherstellen lassen.

Die Gesamtstruktur-Wiederherstellung üben

Microsoft veröffentlicht einen ausführlichen AD Forest Recovery Guide, der die genaue Reihenfolge der Schritte für die Wiederherstellung in einem Szenario beschreibt, in dem der Gesamtstruktur nicht mehr vertraut werden kann (Ransomware, bösartige Schemaänderung oder der Verlust so vieler DCs, dass Replikation bzw. Quorum zusammenbrechen). Lesen Sie ihn nicht zum ersten Mal während eines echten Vorfalls.

Reihenfolge der Schritte im Überblick (das vollständige Verfahren finden Sie im Leitfaden von Microsoft):

1. Ermitteln Sie die letzte bekanntermaßen gute, schadsoftwarefreie Systemstatussicherung für einen DC pro Domäne, vorzugsweise einen Globalen Katalog in der Gesamtstrukturstammdomäne.
2. Isolieren Sie die Umgebung – vom Netzwerk trennen bzw. Replikation anhalten –, bevor Sie wiederherstellen, damit ein noch aktiver Angreifer oder ein beschädigter Replikationspartner den wiederhergestellten DC nicht erneut infizieren kann.
3. Stellen Sie den ersten DC jeder Domäne (Stammdomäne zuerst) im Verzeichnisdienst-Wiederherstellungsmodus (DSRM) als nicht autoritative Wiederherstellung von AD DS mit autoritativer Wiederherstellung von SYSVOL wieder her (wbadmin start systemstaterecovery ... -authsysvol, oder bei DFSR msDFSR-Options im SYSVOL-Abonnement des DCs auf 1 setzen). Alle anderen DCs werden neu aufgebaut, daher gibt es keinen Replikationspartner, dessen Änderungen überschrieben werden müssten.
4. Setzen Sie das krbtgt-Kennwort in jeder Domäne als Teil der Wiederherstellung zweimal zurück und warten Sie zwischen den beiden Zurücksetzungen die Replikationskonvergenz ab – damit wird jedes vor der Wiederherstellung ausgestellte Kerberos-Ticket ungültig, einschließlich aller von einem Angreifer gefälschten.
5. Bereinigen Sie mit ntdsutil die Metadaten aller DCs, die nicht wiederhergestellt werden, damit veraltete DC-Objekte keine Replikations- oder DNS-Probleme verursachen:

ntdsutil
metadata cleanup
connections
connect to server <survivingDC>
quit
select operation target
list domains
select domain <n>
list sites
select site <n>
list servers in site
select server <n>
quit
remove selected server
quit
quit

6. Bauen Sie die übrigen DCs von sauberen Medien neu auf und stufen Sie sie herauf, sobald der erste DC und die Metadatenbereinigung als einwandfrei bestätigt sind.
7. Aktivieren Sie Netzwerkkonnektivität und Replikation schrittweise wieder und achten Sie auf Anzeichen einer erneuten Infektion, bevor Sie die gesamte Umgebung wieder verbinden.

Üben Sie dies mindestens einmal jährlich in einem isolierten Labor. Wiederherstellungsleitfäden lesen sich anders, als sie sich ausführen lassen – Probleme mit dem DSRM-Kennwort, eine unerwartete Verteilung der FSMO-Rollen oder mangelnde Vertrautheit mit der ntdsutil-Syntax unter Druck sind genau die Art von Reibung, die Sie bei einer Übung entdecken wollen und nicht um 2 Uhr nachts während eines Ransomware-Vorfalls.

Was dadurch nicht mehr funktioniert

Direkt nichts – dies ist Governance- und Notfallwiederherstellungsarbeit, keine Maßnahme mit Auswirkungen auf die Produktion. Die Kosten liegen in Zeit und Prozessdisziplin: geplante Bewertungsläufe, Budget für unveränderlichen bzw. Offline-Sicherungsspeicher und regelmäßige Wiederherstellungsübungen, die Laborinfrastruktur und Personalstunden binden. Nichts davon ändert das alltägliche Authentifizierungs- oder Zugriffsverhalten der Benutzer.

Kombinieren Sie dies mit Kerberos-Härtung für den Rhythmus der krbtgt-Rotation außerhalb von Wiederherstellungsszenarien und mit Auditing, Protokollierung und Erkennung, damit Sie, wenn die Sicherheitsbewertung einen Befund meldet, auch die Protokolle haben, um festzustellen, ob er jemals ausgenutzt wurde.