Gruppenrichtlinien sind sehr mächtig: Damit steuern Administratoren Sicherheitseinstellungen, Skripte, Anwendungskonfigurationen und Benutzervorgaben verbindlich und verteilen sogar Softwarepakete. Doch ein einziger Fehler bei der Berechtigungsvergabe genügt, um die Robustheit und Verbindlichkeit der richtlinienbasierten Verwaltung gegen die Administratoren zu richten und zugunsten der Angreifer einzusetzen.

In diesem Artikel konzentrieren wir uns auf die Windows-Bordmittel zur Erstellung und Verwaltung von Gruppenrichtlinien. Auf dem Markt existieren Third-Party-Produkte, die hier unterstützen können: Sie agieren gegenüber dem AD zwar mit sehr hohen Rechten, kanalisieren die Tätigkeiten der Administratoren jedoch mittels Role Based Access Control (RBAC) besser, als es die Bordmittel vermögen. Doch diese Werkzeuge sind teuer und bedürfen vor der Einführung einer eigenen Sicherheitsbetrachtung.

Ein Blick darauf, wie der Richtlinien-Ergebnissatz für die Anwendung von Policys entsteht, zeigt: Jedes Gruppenrichtlinien-Objekt (GPO) setzt sich aus vier Arten von Komponenten zusammen.

Die erste Gruppe bilden Einträge im AD, die grundsätzlich entscheiden, ob das Gruppenrichtlinienobjekt für den jeweiligen Computer und/oder Benutzer überhaupt in Betracht kommt. Es geht dabei um die Verknüpfung des GPOs mit einzelnen OUs oder mit der gesamten Domäne. Technisch bilden die LDAP-Attribute gPLink und gPOptions dies ab: Ersteres listet die am jeweiligen Objekt verknüpften GPOs und ihre Anwendungsreihenfolge auf, die der umgekehrten Priorität entspricht; Letzteres beschreibt die GPO-spezifischen Einstellungen am Objekt selbst.

Ein Wert von 1 bedeutet hier "Vererbung deaktivieren", jeder andere Wert, einschließlich des leeren Attributs, signalisiert eine aktive Vererbung. Selbst erfahrene Administratoren übersehen dabei gern die Möglichkeit, Gruppenrichtlinien an AD-Standorte zu verknüpfen. Sinnvolle Einsatzmöglichkeiten dafür sind eher begrenzt, weshalb die Gruppenrichtlinien-Verwaltungskonsole (GPMC) die Standorte stand- ardmäßig auch nicht anzeigt. Die Mechanik bleibt dabei dieselbe, nur dass das gPOptions-Attribut hier keine Wirkung entfaltet, denn an dieser Stelle existiert keine Vererbung, die sich deaktivieren ließe.

Eine zweite Gruppe von AD-Einträgen entscheidet, ob das Gruppenrichtlinienobjekt konkret für diesen Benutzer und/oder Computer zur Anwendung kommt. Diese Einträge finden sich am GPO selbst, standardmäßig im Container "CN=Policies,CN=System" der jeweiligen Domäne enthalten. Dazu zählt zum einen die Sicherheitsfilterung, also die Kombination der Rechte "Lesen" und "Gruppenrichtlinie übernehmen", zum anderen das Attribut gPCWQLFilter, das die WMI-Filter enthält. Diese Filter führt der Computer aus, bevor das System das jeweilige GPO als Kandidaten in den Richtlinien-Ergebnissatz aufnimmt. Auch die Definitionen der WMI-Filter selbst liegen im AD, als Objekte vom Typ "msWMI-Som".

Eine dritte Kategorie von AD-Einstellungen gibt an, welche Funktionalität das GPO bereitstellt. Dazu gehört zum einen das versionNumber-Attribut des Gruppenrichtlinienobjekts: Sein Wert teilt dem auswertenden Computer mit, ob es seit der letzten Anwendung Änderungen an diesem GPO gab. Zum anderen zählen die Attribute "gPCUserExtensionNames" und "gPCMachineExtensionNames" dazu. Sie listen die clientseitigen Erweiterungen (CSE) auf, für die das jeweilige GPO Einstellungen bereitstellt.

Die vierte Komponente bilden die Dateien in der SYSVOL-Freigabe; sie beherbergen die eigentliche Funktionalität der Gruppenrichtlinien. Je nach Abschnitt der Gruppenrichtlinie weisen diese Dateien unterschiedliche Formate auf: Teilweise handelt es sich um "flache" Textdateien, die sich unmittelbar lesen und, sofern die Dateisystemberechtigungen es zulassen, auch bearbeiten lassen. Komponenten, die Richtlinien lediglich ausliefern, etwa Softwarepakete oder Skripte, liegen in ihrer ursprünglichen Form vor. Doch auch der binäre Teil des GPO, der Registry-basierte Einstellungen enthält, lässt sich mit Windows-Bordmitteln auswerten und bearbeiten. Active Directory verfügt über keinen eingebauten Mechanismus, um die Integrität dieser Dateien oder auch nur die ihrer Zugriffsberechtigungen zu überwachen oder gar zu erzwingen. Erst, wenn ein Administrator die GPO im Editor öffnen möchte, erhält er eine Fehlermeldung, falls die Berechtigungen in SYSVOL von denen im AD unterschiedlich sind.

Aus dieser Betrachtung ergeben sich für Angreifer mehrere Möglichkeiten, Gruppenrichtlinien zu missbrauchen: Die Auswertung vergangener Cyberangriffe bestätigt sämtliche der im Folgenden beschriebenen Taktiken.

Verfügt ein Angreifer, sei es irrtümlich berechtigt oder durch vorherige Privilege Escalation erlangt, über das Recht, die für die GPO-Verknüpfung relevanten Attribute gpLink und gegebenenfalls gpOptions von Domänen, OUs oder Standorten zu bearbeiten, kann er damit beispielsweise ein GPO mit absichtlich abgeschwächten Einstellungen, das eigentlich für einen anderen Einsatzzweck gedacht war, gezielt auf Domain-Controller wirken lassen.

Ebenso brisant ist die Berechtigung, die Sicherheitsfilterung oder die WQL-Filter eines GPO zu bearbeiten: Sie erlaubt es, die Wirkung der Richtlinien auszuweiten oder zu reduzieren. Das Recht, die Sicherheitsbeschreibung eines GPO zu bearbeiten, geht noch weiter – damit verschafft sich der Angreifer jedes weitere Recht an diesem GPO, zumindest für das groupPolicyContainer-Objekt im AD. Die NTFS-Rechte auf die Dateien in SYSVOL betrifft dies zunächst nicht unmittelbar. Allerdings kann hier die Gruppenrichtlinien-Verwaltungskonsole dem Angreifer in die Hände spielen: Beim Auswählen eines Gruppenrichtlinienobjekts prüft die Konsole, ob die NTFS-Berechtigungen mit denen im AD übereinstimmen, und fordert den Operator bei Abweichungen auf, dies per Mausklick zu korrigieren.

Hinzu kommt das Recht, das Attribut versionNumber eines GPO zu bearbeiten: In Kombination mit der Möglichkeit, Dateien im SYSVOL-Ordner des GPO zu verändern, kann der Angreifer damit die Anwendung der präparierten Richtlinien gezielt im nächsten Anwendungszyklus auslösen. Auch das Recht, die ExtensionNames-Attribute zu bearbeiten, birgt Risiken: Der Angreifer kann eine bestimmte Erweiterung für das GPO deaktivieren oder eine neue hinzufügen, die anschließend auf Dateien zugreift, die er zuvor in das Dateisystem eingeschleust hat.

Und schließlich das Recht, Dateien im SYSVOL-Teil des GPO zu bearbeiten, zu löschen oder neu hinzuzufügen: Auf Maschinen, die dieses GPO bereits einmal angewendet haben, wirkt sich das zunächst nicht auf den Ergebnissatz aus. Bei neuen Maschinen und bei der Vordergrund-Verarbeitung, etwa nach einem Neustart oder ausgelöst durch gpupdate /force, werden die angepassten Dateien dagegen aktiv. Kann der Angreifer zusätzlich die Version des GPO erhöhen, kommt es bereits im nächsten Anwendungszyklus zur erneuten Auswertung der geänderten Dateien.

Die meisten Administratoren sehen die oben aufgeführten Berechtigungen nie in dieser Granularität, denn niemand bearbeitet normalerweise Gruppenrichtlinien direkt im AD und SYSVOL. Werkzeuge wie die Gruppenrichtlinien-Verwaltungskonsole setzen die Berechtigungen an den richtigen Stellen automatisch und konsistent. Leider schleppen andere Prozesse häufig zusätzliche Berechtigungen ein: Wer beispielsweise eine OU mit "Vollzugriff" oder "Alle Eigenschaften schreiben" delegiert, delegiert damit auch die Rechte, die GPO-Verknüpfung samt Reihenfolge zu ändern und die Vererbung von GPOs an dieser OU zu unterbrechen.

Eine weitere wichtige Berechtigung blieb bislang unerwähnt: das Recht, neue Gruppenrichtlinienobjekte in einer Domäne zu erstellen. Ein neues Objekt ist an sich erst einmal nicht gefährlich, da es nicht verknüpft ist und somit nicht wirkt. Allerdings eröffnet dieses Recht unschöne Taktiken wie das Anlegen von GPOs mit Anzeigenamen, die mit denen legitimer GPOs übereinstimmen. Die GPMC verhindert dies beim eigenen Anlegen zwar; ist ein solches Objekt jedoch bereits vorhanden, zeigt sie es anstandslos an und erlaubt seine Verknüpfung an Domänen, OUs oder Standorte. Damit könnte ein Operator in der Hitze des Gefechts das falsche, vom Angreifer kontrollierte Objekt an eine wichtige OU oder gar an die Domäne verknüpfen.

Die bisherige Betrachtung ging davon aus, dass der Angreifer das Recht, zu einem GPO gehörende Dateien und Ordner in SYSVOL zu bearbeiten, unmittelbar innerhalb von SYSVOL erhält. Meistens geschieht dies durch unachtsames Kopieren von Dateien im Explorer oder durch unglücklich verlaufende Wiederherstellungsoperationen am SYSVOL-Speicherort.

Allerdings existiert ein anderer Weg, neue Dateien im SYSVOL-Ordner zu platzieren oder bestehende zu ändern – auch diese Taktik trat bereits in der Auswertung von Angriffen auf. Erbt der Angreifer das Recht, im Container "CN=Topology, CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=ita25, DC=metabpa,DC=org" neue Objekte vom Typ msDFSR-Member zu erstellen – meistens einfach durch das Recht "Alle untergeordneten Objekte erstellen" abgedeckt –, kann er einen von ihm kontrollierten Fileserver als Mitglied der Replikationsgruppe "Domain System Volume" hinzufügen und die gewünschten Dateien per DFS-R in den aktiven SYSVOL-Speicher replizieren lassen.

Auch nicht ordnungsgemäß bereinigte Domain-Controller-Leichen können diesen Angriffspfad offenlassen. Die Einrichtung einer neuen DFS-Replikationsbeziehung hinterlässt zwar durchaus Spuren in Ereignisprotokollen, doch in einer Umgebung mit normalerweise problemlos funktionierender DFS-Replikation bleiben diese Protokolle nicht selten unbeachtet.

Nachdem wir die Möglichkeiten eines Angreifers beleuchtet haben, Kontrolle über Anwendung und/oder Inhalt der Gruppenrichtlinien zu übernehmen, betrachten wir nun, welche Möglichkeiten sich ihm aus dieser Kontrolle eröffnen: seine Berechtigungen auszuweiten (Eskalation) oder sich nach eventuellen Gegenmaßnahmen einen Wiedereinstieg zu sichern (Lateral Movement und Persistence). Solche Wege finden sich in nahezu jedem Abschnitt eines Gruppenrichtlinienobjekts.

Bei Softwareinstallationen liegen die eigentlichen Installationspakete meistens nicht innerhalb des GPO-Ordners, sondern an einem anderen freigegebenen Speicherort – dort fällt es dem Angreifer womöglich noch leichter, originale MSI-Dateien gegen manipulierte Pakete auszutauschen. Das System behandelt diese anschließend als "von vertrauenswürdiger Quelle installiert" und öffnet damit Tür und Tor für erheblichen Schaden. Innerhalb des GPO repräsentiert ein "Application Advertisement Script" (AAS-Datei) im Unterordner "Applications" jede bereitgestellte Anwendung. Diese Dateien liegen zwar im binären Format vor, lassen sich jedoch mit bordeigenen Windows-Funktionen generieren. Um eine neue AAS-Datei zu einem GPO hinzuzufügen, muss der Angreifer allerdings zusätzlich ein packageRegistration-Objekt im AD erzeugen – deshalb konzentrieren sich Angriffe in der Praxis meist auf den Austausch der MSI-Pakete selbst.

Schleust der Angreifer Skripte in den Maschinenzweig des GPO ein, führt das System sie beim Start beziehungsweise beim Herunterfahren des Computers in dessen SYSTEM-Kontext aus. Handelt es sich dabei um einen Domain-Controller, agiert das Skript mit "Gott-Rechten" gegenüber dem Active Directory. Enthält das Skript Befehle, die lokale Benutzer anlegen und diese zu hochprivilegierten lokalen Gruppen hinzufügen, entstehen hochprivilegierte Domänenbenutzer, sobald es dem Angreifer gelingt, eine solche Richtlinie auf Domain-Controller anzuwenden. Flache Textdateien bilden die Skripte vollständig ab: scripts.ini und psscripts.ini sowie die Skripte selbst, allesamt innerhalb des GPO-Ordners in SYSVOL.

Es trägt eine gewisse Ironie in sich, dass gerade Sicherheitseinstellungen innerhalb der Gruppenrichtlinie in flachen Textdateien liegen. Kontorichtlinien, Kerberos-Einstellungen, die Zuweisung der Benutzerrechte und die "klassische" Überwachungsrichtlinie residieren in der "GptTmpl.inf" unter "Microsoft\Windows NT\SecEdit". Dort finden sich auch Einstellungen für "Eingeschränkte Gruppen" – damit lässt sich eine harmlose Gruppe zu einer Admin-Gruppe hinzufügen – sowie für "Systemdienste": Setzt der Angreifer "Anwendungsidentität" auf "deaktiviert", hebelt er damit AppLocker aus, und es gibt noch zahlreiche weitere Beispiele dieser Art. Weitere prominente Fundstellen in der GptTmpl.inf sind NTFS- und Registry-Berechtigungen; Angreifer setzten beide bereits erfolgreich zur Berechtigungserweiterung ein.

Die erweiterte Überwachungsrichtlinie, also diejenige, die heutzutage nahezu ausnahmslos zum Einsatz kommt, liegt als CSV-Datei ("audit.csv") vor, die sogar die Sprache jener Konsole übernimmt, mit der zuletzt jemand das GPO bearbeitete. Durch gezielte Beeinflussung der Überwachungsrichtlinien gelingt es dem Angreifer womöglich, Eskalationsaktivitäten im AD unbemerkt durchzuführen, vor allem dann, wenn Ihre Sicherheitsüberwachung ausschließlich auf den Ereignisprotokollen von Windows beruht, die ein zentraler Logspeicher zusammenführt.

AppLocker, PKI-Richtlinien, Ereignisprotokoll-Konfigurationen und die Einstellungen der Windows-Firewall finden sich in der Datei "Registry.pol". Diese hält Daten im Registry-Hive-Format vor, was eine direkte Auswertung und das Durchsuchen erschwert, jedoch nicht unmöglich macht. Sämtliche auf ADMX-Vorlagen basierenden Einstellungen beruhen ebenfalls auf der Windows-Registry und liegen somit auch in der Registry.pol. Die aus Sicherheitssicht prominentesten dieser Richtlinien behandeln wir in einem gesonderten Abschnitt.

Die "Group Policy Preferences" (GPP, auf Deutsch "Einstellungen") liegen als strukturierte Textdateien (XML) vor und enthalten zahlreiche sicherheitsrelevante Konfigurationsmöglichkeiten. Diese Funktionalität beruht auf dem Produkt "Policy Maker" von Desktop Standard, das Microsoft 2006 übernahm, und weist daher bis heute eine vom Rest der Gruppenrichtlinien abweichende Architektur auf. Auch dieser Teil des Gruppenrichtlinien-Konstrukts verdient einen eigenen Abschnitt.

Für jeden neuen Konfigurationstyp braucht es neben den Daten in SYSVOL und eventuellen Unterobjekten im groupPolicyContainer natürlich auch die entsprechende CSE im GPO-Objekt selbst. Einen versierten Angreifer hält das jedoch nicht davon ab, die ihm zugefallenen Zugriffsrechte zu missbrauchen.

Im ersten Teil dieser Workshopserie haben wir einen Blick auf die Angriffsmöglichkeiten geworfen. So können Hacker etwa über DFS-R Daten einschleusen. Im zweiten Teil schauen wir uns an, was Eindringlinge anstellen können, wenn sie den Fuß in der Tür haben, und wie Sie sich davor schützen.

(dr)