Active-Directory-Sicherungen vor Ransomware schützen

Moderne Ransomware-Betreiber beginnen nicht damit, Dateiserver zu verschlüsseln. Sie übernehmen Active Directory, erreichen darüber die Backup-Konsole, löschen oder verschlüsseln die Sicherungen und verteilen erst dann die Schadsoftware über Gruppenrichtlinien oder Remoteausführung. Wenn Ihre Sicherungen der Domänencontroller mit einer Domain-Admin-Anmeldeinformation erreichbar sind, sind sie verschwunden, bevor Sie den Angriff bemerken. Ohne eine saubere DC-Sicherung bedeutet Wiederherstellung, die Gesamtstruktur von Grund auf neu aufzubauen.

Dieser Leitfaden entwirft AD-Sicherungen für genau dieses Bedrohungsmodell: was gesichert werden muss, wo das Backup-System im Tier-Modell steht, wie Sie Kopien unveränderlich und offline machen und wie Sie jede Woche nachweisen, dass Sie wiederherstellen könnten. Der Grundlagenleitfaden zu Bewertung, Sicherung und Wiederherstellung behandelt die Grundlagen der Systemstatussicherung. Das Wiederherstellungsverfahren selbst beschreibt der Beitrag zum Erstellen und Üben eines Plans zur Gesamtstruktur-Wiederherstellung.

Messen: was Sie heute tatsächlich wiederherstellen können

Beginnen Sie mit Fakten, nicht mit dem Dashboard des Backup-Produkts. Prüfen Sie in jeder Domäne, wann jeder Namenskontext zuletzt gesichert wurde – so, wie AD selbst es verzeichnet:

# Letzter Sicherungszeitpunkt pro Partition, aus Sicht des DCs
repadmin /showbackup *

# Auf einem DC verfügbare Versionen von Windows Server Backup
wbadmin get versions

AD warnt Sie auch selbst. Ereignis 2089 im Directory-Service-Protokoll erscheint, wenn eine Partition nicht innerhalb des Schwellenwerts für die Backup-Latenz gesichert wurde – standardmäßig die Hälfte der Tombstone-Lebensdauer. Sehen Sie irgendwo 2089, erstellt Ihr Backup-Produkt keine Sicherungen, die AD anerkennt.

Beantworten Sie anschließend pro Domäne schriftlich fünf Fragen:

1. Welche DCs werden gesichert, und in welchem Format (Systemstatus über Windows Server Backup, VSS-fähige VM-Sicherung, AD-Agent eines Herstellers)?
2. Wo werden die Kopien gespeichert, und welche Identitäten können sie löschen?
3. Gibt es eine Kopie, die keine Online-Anmeldeinformation vor Ablauf ihrer Aufbewahrung löschen oder verändern kann?
4. Wo liegen die DSRM-Kennwörter dieser DCs, und kommen Sie an sie heran, wenn AD ausgefallen ist?
5. Wann wurde zuletzt eine Wiederherstellung getestet, und wie lange hat sie gedauert?

Die meisten Organisationen stellen fest, dass die Antwort auf Frage 2 Domain Admins, das Dienstkonto der Sicherung und alle Mitglieder von Backup Operators umfasst.

Was gesichert werden muss

Für jede Domäne der Gesamtstruktur:

• Systemstatus von mindestens zwei beschreibbaren DCs, täglich. Bevorzugen Sie den PDC-Emulator und einen globalen Katalog. Zwei DCs schützen davor, dass eine Sicherung beschädigt ist oder erst nach der Kompromittierung erstellt wurde.
• AD-integriertes DNS liegt in den Verzeichnispartitionen und ist im Systemstatus enthalten. Bedingte Weiterleitungen und Einstellungen auf Serverebene möglicherweise nicht – exportieren Sie diese ebenfalls.
• Gruppenrichtlinienobjekte als separater, schneller Wiederherstellungsweg für GPO-Fehler, die keine DC-Wiederherstellung erfordern.
• AD CS: CA-Datenbank und privater Schlüssel, denn eine Gesamtstruktur-Wiederherstellung ohne PKI lässt Smartcard-Anmeldung, 802.1X und viele Anwendungen funktionsunfähig zurück. Siehe Härtung der AD CS.
• Konfiguration von Entra Connect, exportiert, damit sich die hybride Identität neu aufbauen lässt.

Install-WindowsFeature Windows-Server-Backup

# Systemstatus auf ein dediziertes, nicht kritisches Volume auf dem DC
wbadmin start systemstatebackup -backupTarget:F: -quiet

# GPOs und AD CS
Backup-GPO -All -Path 'F:\GPO' | Out-Null
Backup-CARoleService -Path 'F:\CA' -Password (Read-Host -AsSecureString 'CA key backup password')

Eine Systemstatussicherung enthält ntds.dit und die Struktur SYSTEM, also jeden Kennworthash der Domäne und die krbtgt-Schlüssel. Eine Kopie davon ist so sensibel wie ein DC. Verschlüsseln Sie sie im Ruhezustand und bei der Übertragung, und legen Sie sie niemals auf einer Freigabe ab, die Tier-1- oder Tier-2-Admins lesen können.

Durchsetzen: das Backup-System aus dem Schadensradius holen

Getrennte Identität

Backup-Konsole, Repository-Server und Verwaltungsoberfläche des Speichers sind Tier 0. Wer sie kontrolliert, kann jeden Hash lesen oder Ihre Wiederherstellung zerstören. Nehmen Sie sie in Ihr Tier-0-Inventar auf und wählen Sie eines dieser Muster:

• Separate Verwaltungs-Gesamtstruktur oder Arbeitsgruppe für die Backup-Infrastruktur, mit lokalen oder dedizierten Konten, phishingresistenter MFA an der Konsole und ohne Vertrauensstellung zur Produktion.
• Gehärtete Appliance mit eigenem Identitätsspeicher, zum Beispiel Linux-basierte unveränderliche Repositories, bei denen die Produktionsdomäne keinen administrativen Zugriffspfad hat.

Welche Variante Sie auch wählen: Das Dienstkonto des Backup-Agenten auf den DCs darf nur die Rechte besitzen, die es benötigt, und nirgendwo sonst wiederverwendet werden. Behandeln Sie Backup Operators und jeden Prinzipal mit SeBackupPrivilege auf DCs als Tier 0. Lassen Sie die Gruppe leer, sofern es keinen dokumentierten Bedarf gibt.

Unveränderliche und Offline-Kopien

Folgen Sie dem Muster 3-2-1-1-0: drei Kopien auf zwei Medientypen, eine außer Haus, eine unveränderlich oder offline und null Fehler bei Wiederherstellungstests.

• Unveränderlich: Objektspeicher mit Aufbewahrungssperre im Compliance-Modus (zum Beispiel S3 Object Lock) oder gehärtete Repositories, die Unveränderlichkeit auf Speicherebene erzwingen. Im Compliance-Modus kann nicht einmal der Speicheradministrator die Aufbewahrung verkürzen.
• Offline: Band oder Wechselmedien, physisch getrennt und planmäßig rotiert. Langsam, aber für nichts im Netzwerk erreichbar.
• Aufbewahrung: lang genug, um vor eine wahrscheinliche Verweildauer des Angreifers zurückzureichen. Mindestens Wochen, dazu einige monatliche Kopien – Wiederherstellungen müssen jedoch innerhalb der Tombstone-Lebensdauer der Gesamtstruktur bleiben oder als vollständige Gesamtstruktur-Wiederherstellung erfolgen.

Netzwerkisolation

Der Sicherungsspeicher sollte Verbindungen nur von Backup-Proxys annehmen, nicht aus dem allgemeinen Servernetz oder direkt von DCs. Verwaltungsoberflächen für Speicher und Backup sollten nur von dedizierten Admin-Arbeitsstationen aus erreichbar sein, abgestimmt auf die Firewallregeln Ihrer Domänencontroller.

DSRM-Kennwörter

Jeder DC hat einen lokalen Administrator für den Verzeichnisdienst-Wiederherstellungsmodus (DSRM). Sie benötigen dessen Kennwort für die Wiederherstellung. Legen Sie es pro DC fest, bewahren Sie es in einem Offline-Tresor auf (versiegelter Umschlag oder ein Kennwortmanager, der nicht von AD abhängt), und rotieren Sie es planmäßig. Sie können es auch von einem deaktivierten Domänenkonto synchronisieren:

# Synchronisiert das DSRM-Kennwort auf diesem DC von einem dedizierten (deaktivierten) Domänenkonto
ntdsutil "set dsrm password" "sync from domain account DSRMSync" q q

Ereignis 4794 verzeichnet jeden Versuch, das DSRM-Kennwort zu ändern. Alarmieren Sie darauf außerhalb von Änderungsfenstern.

Angriffe auf die Sicherungen erkennen

Angreifer bereiten das Terrain Tage vor der Verschlüsselung vor. Mehrere Signale erscheinen in Protokollen, die Sie bereits weiterleiten:

• Löschen von Schattenkopien und Katalogen. Prozesserstellungsereignisse (4688 mit Befehlszeile) für vssadmin delete shadows, wbadmin delete catalog oder wbadmin delete systemstatebackup auf beliebigen Servern und vor allem auf DCs.
• Anmeldungen an der Backup-Konsole von ungewöhnlichen Hosts oder Konten sowie Änderungen an Aufbewahrungsrichtlinien, Repositories oder Verschlüsselungsschlüsseln. Leiten Sie das Audit-Protokoll des Backup-Produkts an das SIEM weiter und alarmieren Sie bei Konfigurationsänderungen außerhalb von Wartungsfenstern.
• Änderungen an der Mitgliedschaft von Backup Operators (4732 auf der integrierten Gruppe) und neue Inhaber von SeBackupPrivilege.
• Ausgefallene Sicherungen. Ein Sicherungsauftrag, der stillschweigend nicht mehr läuft, ist so gefährlich wie ein gelöschter. Alarmieren Sie, wenn länger als einen Tag kein erfolgreicher Auftrag vorliegt.

Überprüfen

Ein grüner Sicherungsauftrag beweist, dass Daten geschrieben wurden, nicht dass sie sich wiederherstellen lassen. Überprüfen Sie auf drei Ebenen:

1. Wöchentlich, automatisiert. repadmin /showbackup zeigt jede Partition als innerhalb von 24 bis 48 Stunden gesichert. Es gibt keine 2089-Ereignisse. Die unveränderliche Kopie existiert und ihre Aufbewahrungssperre ist gesetzt. Prüfen Sie dies über die Speicher-API von einem System außerhalb des Produktions-AD.
2. Vierteljährlich, Wiederherstellungstest. Stellen Sie einen DC pro Domäne aus der unveränderlichen Kopie in einem isolierten Netzwerk ohne Route zur Produktion wieder her. Starten Sie in den DSRM und führen Sie mit wbadmin start systemstaterecovery -version:<version> eine nicht autoritative Wiederherstellung durch. Bestätigen Sie, dass AD DS startet und die Objekte vorhanden sind. Verbinden Sie einen wiederhergestellten DC niemals mit der Produktion – er würde alte Daten und Kennwörter wieder einführen.
3. Jährlich, vollständige Übung. Führen Sie den Plan zur Gesamtstruktur-Wiederherstellung von Anfang bis Ende durch und messen Sie die Zeit.

Testen Sie außerdem die Manipulationssicherheit. Versuchen Sie mit einem Domain-Admin-Konto, in der Laborkopie Ihres Designs eine Sicherung zu löschen oder die Aufbewahrung zu verkürzen. Der Versuch sollte scheitern und einen Alarm auslösen.

Was dadurch nicht mehr funktioniert

• Betrieblicher Komfort. Backup-Admins können ihre alltäglichen Domänenkonten nicht mehr verwenden. Getrennte Anmeldeinformationen und MFA erzeugen Reibung, und manche Teams werden sich bis zum ersten Vorfall dagegen sträuben.
• Wiederherstellungsgeschwindigkeit. Offline- und regionsübergreifende unveränderliche Kopien lassen sich langsamer wiederherstellen als lokale Snapshots. Halten Sie eine schnelle, lokale Online-Kopie für die alltägliche Wiederherstellung vor und die unveränderliche Kopie für den Katastrophenfall.
• Speicherkosten. Eine Aufbewahrung im Compliance-Modus lässt sich nicht verkürzen, auch nicht von Ihnen. Dimensionieren Sie sie sorgfältig, denn eine versehentlich auf Jahre konfigurierte Aufbewahrung auf einem großen Bucket ist eine Rechnung, die Sie nicht stornieren können.
• Herstellerintegrationen. Manche Backup-Produkte erwarten Domänen-beigetretene Proxys oder eine in AD integrierte rollenbasierte Zugriffssteuerung. Die Umstellung auf eine separate Identitätsebene kann eine Neuinstallation von Komponenten oder Lizenzänderungen erfordern.
• Bereinigung von Backup Operators. Das Entfernen von Mitgliedern kann Legacy-Skripte beschädigen, die die Gruppe für Sicherungen auf Dateiebene auf DCs nutzten. Finden Sie diese Skripte, bevor Sie die Gruppe leeren.

Weiterführende Lektüre: Einen Plan zur Gesamtstruktur-Wiederherstellung erstellen und üben nutzt diese Sicherungen, krbtgt-Kennwortrotation behandelt das Zurücksetzen des Schlüssels, mit dem jede Wiederherstellung endet, und der Bereich Bewertung, Sicherung & Wiederherstellung listet die gesamte Serie auf.