Schwache ACL GPO, Tier 0 OU, Active Directory: Der Pivot, der Ihr gerade aufgebautes Tier-Modell aushebelt

Schwache ACL GPO, Tier 0 OU, Active Directory: Was Diese Fehlkonfiguration Wirklich Bedeutet

Eine schwache ACL auf einer mit der Tier-0-OU verknüpften GPO ist die Kontrolle, die die meisten Teams zu prüfen vergessen, sobald ihr Tier-Modell bereits ausgerollt ist. Eine dedizierte Tier-0-Organisationseinheit anzulegen und die Richtlinienvererbung dort zu blockieren, ist ein bekannter Schritt — es sind R58 und R59 von ANSSI-PA-099, dem Leitfaden der französischen Cybersicherheitsbehörde zur sicheren Administration von Active Directory (siehe auch unsere Zusammenfassung der ANSSI-Empfehlungen für den breiteren Kontext). R58 verlangt eine dedizierte OU, die die Tier-0-Objekte bündelt — mit einer expliziten Ausnahme: Computerkonten von Domänencontrollern sowie die integrierten Benutzer und Gruppen verbleiben in ihren Standard-OUs; R59 verlangt, dass diese OU „die auf die Tier-0-Organisationseinheit anwendbaren Sicherheitsrichtlinien einschränkt", indem die Vererbung blockiert wird und sichergestellt ist, dass jede mit ihr verknüpfte oder auf sie angewendete GPO ausschließlich Tier-0-Ressourcen betrifft und nur von Tier-0-Administratoren bearbeitet werden kann.

Diese zweite Hälfte von R59 — „nur von Tier-0-Administratoren bearbeitet werden kann" — ist der Teil, der leise aus dem Blickfeld gerät, sobald die OU-Struktur einmal steht. Das Blockieren der Vererbung schließt eine Kontrollebene: welche Richtlinien von oben auf die OU einwirken. Über eine zweite, unabhängige Kontrollebene sagt das nichts aus: wer in die bereits dort verknüpften GPO-Objekte schreiben darf. Eine GPO ist ein eigenständiges Active-Directory-Objekt mit eigener Zugriffskontrollliste. Gewährt diese ACL einer Instanz unterhalb von Tier 0 Bearbeitungsrechte — einer Helpdesk-Gruppe, einer nie aufgeräumten Alt-Delegation, einer Sicherheitsgruppe, die eine Ebene tiefer verschachtelt ist als beabsichtigt —, kann dieser wenig vertrauenswürdige Principal den Richtlinieninhalt umschreiben, und Active Directory wendet dessen Änderungen auf jeden von der GPO erreichten Tier-0-Rechner und jedes Tier-0-Konto an, Vererbungsblock hin oder her.

Das ist ein enger gefasstes, spezifischeres Problem als die allgemeine Frage, wie ein Tier-Modell überhaupt aufgebaut wird. Ein Team kann die OU-Hierarchie aus R58 korrekt umsetzen, jede Prüfung der OU-Struktur selbst bestehen — und trotzdem eine Tier-0-OU mit einer einzigen schwach berechtigten, daran verknüpften GPO ausliefern, weil die eigene ACL dieser GPO ein separates Objekt ist, das niemand erneut geprüft hat, nachdem das Tier-Modell für abgeschlossen erklärt wurde.

Funktionsweise

Ein Group Policy Object besteht eigentlich aus zwei synchron gehaltenen Artefakten: dem Group Policy Container (GPC), einem Active-Directory-Objekt unter CN=Policies,CN=System,DC=<domain>, das den eigenen Security Descriptor der GPO trägt, und dem Group Policy Template (GPT), dem passenden Ordner in der SYSVOL-Freigabe, der die eigentlichen Einstellungsdateien enthält. Die Verknüpfung zwischen einer GPO und einer OU ist ein drittes, separates Element: das gPLink-Attribut der OU, das die GPO lediglich per GUID referenziert.

Microsofts eigene Dokumentation zur Verarbeitung von Gruppenrichtlinien bestätigt die Mechanik hinter der „Vererbung blockieren"-Anforderung von R59: Jede OU besitzt ein GPOptions-Attribut, das Richtlinien aus übergeordneten Containern blockieren kann, aber „obwohl eine blockierte Vererbung verhindert, dass die meisten Einstellungen auf eine OU angewendet werden, wirkt sie sich nicht auf Einstellungen aus, die über GPOs mit der Option 'Erzwungen' angewendet werden" — Erzwungen ist eine Eigenschaft der Verknüpfung und hat Vorrang vor der Vererbungsblockierung, einer Eigenschaft des Containers. Genau deshalb verlangt R59 auch zu prüfen, dass keine mit dem Status „Erzwungen" aus einer übergeordneten OU angewendete GPO von jemandem außerhalb von Tier 0 bearbeitet werden kann: Die Vererbungsblockierung allein stoppt nicht das Berechtigungsproblem einer erzwungenen GPO, sondern nur ihr Problem mit normaler Priorität.

Nichts davon berührt die eigene ACL des GPC-Objekts. Standardmäßig besitzen nur Domain Admins, Enterprise Admins und SYSTEM Bearbeitungsrechte auf eine GPO — Microsofts Get-GPPermission-Referenz zeigt genau diese Standardmenge in ihrer eigenen Beispielausgabe und benennt diese Berechtigungsstufe GpoEditDeleteModifySecurity. Schwache ACLs entstehen durch Drift, nicht durch eine einzelne Fehlentscheidung: Eine GPO wird von einem Admin einer niedrigeren Tier-Ebene über GPMC erstellt und später mit der Tier-0-OU verknüpft, ohne dass jemand erneut prüft, wer noch Bearbeitungsrechte darauf besitzt; oder eine für eine bestimmte Aufgabe an eine bestimmte GPO gebundene Helpdesk-Delegation wird nie widerrufen; oder eine für Tier 1 vorgesehene Sicherheitsgruppe erhält bei einer Berechtigungsbereinigung versehentlich „Einstellungen bearbeiten".

Die Angriffskette

Schritt 1 — Die Schwachstelle Finden

Ein Angreifer (oder ein Auditor) durchsucht die ACL jeder GPO nach GenericAll-, GenericWrite-, WriteDacl- oder WriteOwner-Berechtigungen, die ein Principal unterhalb von Tier 0 hält, und gleicht das Ergebnis dann mit dem gPLink jeder GPO auf einer Tier-0-OU ab — direkt oder über eine erzwungene GPO auf einer übergeordneten OU. Get-GPPermission -Guid <GPO-GUID> -All liefert diese Information jeweils für eine GPO — -Guid (oder -Name) ist Pflicht, der Sweep muss also iterieren statt einmalig zu laufen: Jeder Trustee, dessen Permission als GpoEditDeleteModifySecurity zurückkommt — oder eine benutzerdefinierte ACE, die das Cmdlet keiner benannten Stufe zuordnen kann — und kein anerkannter Tier-0-Principal ist, zählt als Treffer.

Schritt 2 — Die Richtlinie Bewaffnen

SpecterOps' BloodHound-Dokumentation zur GenericWrite-Missbrauchskante beschreibt die Standardtechnik: die GPO im Group Policy Management Editor öffnen und „eine bösartige Richtlinie hinzufügen, die item-level targeting erlaubt, etwa eine neue geplante Sofortaufgabe" — eine Group-Policy-Preferences-Funktion, die beim nächsten Anwenden der Richtlinie einen beliebigen Befehl als NT AUTHORITY\SYSTEM ausführt. Die dafür bekannten Tools — SharpGPOAbuse unter Windows, pyGPOAbuse unter Linux — automatisieren das Schreiben dieses geplanten-Aufgabe-XMLs in die GPO. Dieselbe Dokumentation weist auf eine wichtige Grenze hin: GenericWrite, beschränkt auf „nur dieses Objekt" ohne weitere ACE, reicht allein nicht aus — die GPT-Einstellungen liegen in SYSVOL, sodass der Angreifer zusätzlich Schreibzugriff auf den SYSVOL-Ordner dieser GPO benötigt, um das tatsächlich Bereitgestellte zu ändern. In der Praxis werden beide Zugriffspfade oft genug gemeinsam vergeben, dass dies ein echter Angriffspfad ist, kein rein theoretischer — aber genau dieses Detail unterscheidet eine echte schwache-ACL-GPO von einem Fehlalarm.

Schritt 3 — Auf das Aktualisierungsfenster Warten

Nach der Änderung ist kein weiterer Zugriff nötig. Laut der oben genannten Microsoft-Dokumentation prüfen Domänenmitglieder-Computer und -Server alle 90 Minuten mit einem zufälligen Versatz von bis zu 30 Minuten auf GPO-Änderungen, während Domänencontroller alle fünf Minuten prüfen. Der SYSVOL-Inhalt selbst repliziert zwischen Domänencontrollern nach einem DFSR-Zeitplan von bis zu 15 Minuten innerhalb einer Site. Sobald die Änderung angekommen ist, führt jeder von der GPO erreichte Tier-0-Computer — bei einer an der Tier-0-OU verknüpften GPO sind das die Tier-0-Administrator-Workstations, die dort gehaltenen Administrationskonten und Dienstkonten — die Aufgabe des Angreifers als SYSTEM nach eigenem Zeitplan aus, ohne jede Interaktion. Domänencontroller sind ein separater Sprung: R58 hält deren Computerkonten in der Standard-OU OU=Domain Controllers, sodass eine schwache GPO einen DC nur erreicht, wenn sie zusätzlich mit dieser OU verknüpft oder mit dem Status „Erzwungen" auf einen übergeordneten Container angewendet ist.

Erkennung

Ereignis-ID 5136 („Ein Verzeichnisdienstobjekt wurde geändert") wird unter der Unterkategorie Verzeichnisdienständerungen überwachen ausgelöst, sobald ein Objekt mit einem passenden SACL-Eintrag für „Schreiben" geändert wird — es erscheint überhaupt nicht, sofern diese SACL nicht vorab auf den GPO-Containerobjekten konfiguriert ist (oder von CN=Policies,CN=System vererbt wird). Das Feld AttributeLDAPDisplayName des Ereignisses ist das, was einem SIEM erlaubt, eine routinemäßige Richtlinienänderung von einer Security-Descriptor-Änderung zu unterscheiden; die Filterung auf ObjectClass=groupPolicyContainer isoliert GPO-Aktivität von allen anderen Verzeichnisdienständerungen, die dieses Ereignis ebenfalls abdeckt.

# Jede GPO nach Trustees mit Bearbeitungs-/Vollzugriffsrechten durchsuchen und
# anschließend mit den an einer Tier-0-OU verknüpften GPOs abgleichen
Get-GPO -All | ForEach-Object {
    $gpo = $_   # GPO merken: innerhalb der verschachtelten Pipeline ist $_ eine GPPermission
    Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -match 'GpoEdit|GpoCustom' } |
        Select-Object @{N='GPO';E={$gpo.DisplayName}}, Trustee, TrusteeType, Permission
}

Remediation

1. Die Exposition inventarisieren. Listen Sie jede mit der Tier-0-OU verknüpfte GPO auf, plus jede mit dem Status „Erzwungen" aus einer übergeordneten OU angewendete GPO — laut ANSSI-PA-099 R59 zählen beide. (Get-GPInheritance -Target "<Tier0-OU-DN>").GpoLinks liefert die direkt verknüpfte Menge; übergeordnete OUs müssen manuell auf erzwungene Verknüpfungen geprüft werden.
2. Den Reiter Delegierung prüfen. Öffnen Sie jede GPO in der GPMC, prüfen Sie den Reiter Delegierung und klicken Sie dann auf Erweitert, um die rohe ACL statt der zusammengefassten Berechtigungsstufen zu sehen — Microsofts Delegierungsleitfaden dokumentiert dies als den unterstützten Weg, um Berechtigungen für Einstellungen bearbeiten, löschen und Sicherheit ändern auf einer GPO hinzuzufügen, zu entfernen oder zu prüfen.
3. Jeden Trustee außerhalb von Tier 0 entfernen, der Bearbeiten, Bearbeiten/Löschen/Sicherheit ändern oder eine benutzerdefinierte Berechtigungsstufe besitzt. Bestätigen Sie, dass der zugehörige SYSVOL-Ordner dieser GPO demselben Principal nicht separat Schreibzugriff gewährt — die AD-ACL und die SYSVOL-ACL sind zwei unterschiedliche Prüfungen an zwei unterschiedlichen Objekten.
4. Die andere Hälfte von R59 erneut verifizieren. Bestätigen Sie, dass die Vererbung auf der Tier-0-OU weiterhin blockiert ist, dass die Default Domain Policy dort mit der niedrigsten Priorität verknüpft ist, wie es R59 vorschreibt, und dass keine erzwungene GPO aus einer übergeordneten OU noch eine schwache ACL trägt.
5. Den Sweep aus dem Abschnitt Erkennung regelmäßig wiederholen, nicht nur einmal — GPO-Berechtigungen driften genauso wie Gruppenmitgliedschaften, durch punktuelle Delegierungen, die niemand mehr widerruft. Diese Prüfung gehört in dieselbe Routine wie ein umfassenderes Active-Directory-Sicherheitsaudit, nicht als einmalige Bereinigung.

Wie EtcSec Dies Erkennt

EtcSecs Compliance-Katalog erfasst genau diesen Fehlermodus als ANSSI_R59_TIER0_OU_POLICIES: Er listet jede aktivierte GPO-Verknüpfung auf, markiert diejenigen, die auf eine GPO verweisen, deren eigene ACL einem Nicht-Admin-Principal Schreibzugriff gewährt, und meldet einen Befund für jede Verknüpfung, die auf einer Tier-0-OU landet. Er ist gepaart mit GPO_DANGEROUS_PERMISSIONS für den allgemeinen Fall schwacher GPO-ACLs überall in der Domäne, PATH_GPO_TO_DA für die Angriffspfad-Sicht derselben Exposition und ANSSI_R15_TIER_MODEL_VIOLATION für die breitere Frage, ob das Tier-Modell selbst noch intakt ist.