Kurzfassung: Eine Gruppenrichtlinie wirkt auf viele Rechner gleichzeitig - und genau das macht sie zum Hebel. Wer eine bestehende GPO verändert, kann sich Benutzerrechte zuweisen, sich in lokale Administratorgruppen eintragen oder domänenweit Code als SYSTEM ausführen lassen. Die Spuren liegen im SYSVOL und in der Befehlszeile. Drei sigma-cli-validierte Sigma-Regeln nehmen die veränderten Richtliniendateien und die passenden PowerShell-Aufrufe. Dazu Härtung und der Test im Lab. Serie "Angriff erkennen".
Gruppenrichtlinien sind das zentrale Steuerpult einer Windows-Domäne: Sie verteilen Einstellungen, Rechte und Aufgaben an ganze Organisationseinheiten. Diese Reichweite ist im Normalbetrieb praktisch und im Angriff gefährlich. Wer eine bestehende GPO verändert, auf die viele Rechner hören, braucht keinen Exploit mehr - die Domäne verteilt die Änderung selbst. Deshalb ist die Manipulation von Gruppenrichtlinien ein beliebter Weg, um Rechte auszuweiten und sich zugleich breit festzusetzen. Dieser Beitrag bleibt auf der Erkennungsseite: Er zeigt, welche Spuren eine veränderte Richtlinie hinterlässt, nicht, wie man eine GPO missbraucht.
Einordnung in ATT&CK: Group Policy Modification (T1484.001), eine Untertechnik von Domain or Tenant Policy Modification (T1484). ATT&CK führt sie unter Privilege Escalation und Defense Evasion; in dieser Serie steht sie in der Spalte Privilege Escalation, weil der Angreifer über die Richtlinie an höhere Rechte kommt. Sie grenzt sich vom reinen Dienst-Hijack und von der Token-Manipulation dadurch ab, dass der Hebel nicht ein einzelner Host ist, sondern eine Richtlinie, die auf viele Rechner wirkt.
Was der Angreifer tut
Hat ein Angreifer Schreibrechte auf eine GPO - etwa über ein übernommenes Konto mit delegierten Rechten -, stehen ihm auf der Ebene des Prinzips mehrere Hebel offen:
- Benutzerrechte zuweisen. Über die Sicherheitseinstellungen einer GPO lassen sich Privilegien wie das Debuggen von Prozessen oder das Anmelden als Dienst an ein kontrolliertes Konto vergeben - domänenweit und in einem Schritt.
- In Administratorgruppen eintragen. Über eingeschränkte Gruppen trägt eine GPO ein Konto in die lokale Administratorgruppe aller betroffenen Rechner ein.
- Code als SYSTEM ausführen. Eine sofort startende geplante Aufgabe, über die Group Policy Preferences verteilt, läuft auf jedem Zielrechner mit höchsten Rechten.
- Unauffällig bleiben. Weil die Änderung über den regulären Richtlinienweg wirkt, sieht sie auf den Zielrechnern aus wie legitime Verwaltung - der eigentliche Eingriff passiert einmal an der Richtlinie selbst.
Für die Erkennung ist entscheidend: Jede dieser Änderungen schlägt sich in den Richtliniendateien im SYSVOL nieder oder entsteht über benannte Verwaltungswerkzeuge. Nicht die Wirkung auf hundert Rechnern ist der erste Ansatzpunkt, sondern der eine Schreibzugriff auf die Richtlinie.
Welche Logquellen die Technik zeigt
- Datei-Telemetrie im SYSVOL. Sysmon Event 11 zeigt, wenn die Richtliniendateien einer GPO geschrieben werden - etwa GptTmpl.inf oder ScheduledTasks.xml unterhalb von SYSVOL.
- Prozess-Telemetrie. Event 4688 erfasst PowerShell und die Cmdlets des GroupPolicy-Moduls samt Befehlszeile, mit der eine GPO aus dem Skript heraus verändert wird.
- Verzeichnisdienst-Änderungen. Auf dem Domänencontroller protokolliert Event 5136 Änderungen an GPO-Objekten im Verzeichnis - eine wertvolle Ergänzung, auch wenn die hier gezeigten Regeln bewusst auf portierbare Datei- und Prozessquellen setzen.
- Wer und von wo. Richtlinien werden von wenigen Administratoren über die Gruppenrichtlinienverwaltung gepflegt; jeder Schreibzugriff von einem anderen Konto oder Host verdient einen Blick. Hintergrund zum Missbrauch mitgelieferter Werkzeuge unter Living off the Land.
Das Muster im Log
Drei Signale tragen. Das erste ist das Schreiben von GptTmpl.inf im SYSVOL - diese Datei steuert Benutzerrechte und eingeschränkte Gruppen und ist damit der direkteste Privileg-Hebel einer GPO. Das zweite ist eine ScheduledTasks.xml im SYSVOL, über die eine sofort startende Aufgabe als SYSTEM verteilt wird. Das dritte sind die PowerShell-Cmdlets des GroupPolicy-Moduls, mit denen sich Richtlinienwerte aus der Befehlszeile setzen lassen. Alle drei stehen auf mittlerer Stufe, weil auch legitime Administration genau diese Dateien und Cmdlets berührt. Entscheidend ist der Kontext: Die Pflege von Gruppenrichtlinien gehört zu einem kleinen Kreis bekannter Administratoren, läuft über definierte Hosts und folgt einem geregelten Ablauf. Stammt ein Schreibzugriff von einem anderen Konto, von einem Arbeitsplatz statt von einem Verwaltungssystem oder außerhalb jedes Änderungsfensters, wird aus dem Routinevorgang ein Alarm. Werkzeug, Konto, Host und Zeit trennen die Verwaltung vom Angriff.
Drei Sigma-Regeln
Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: die veränderte GptTmpl.inf, die über GPP verteilte geplante Aufgabe und die GPO-Cmdlets in PowerShell. Die ersten beiden werten Datei-Telemetrie aus, die dritte die Prozess-Telemetrie.
1. GptTmpl.inf einer Gruppenrichtlinie im SYSVOL verändert (T1484.001). Das Schreiben dieser Datei im SYSVOL. Wegen der legitimen GPO-Pflege auf level: medium.
title: GptTmpl.inf einer Gruppenrichtlinie im SYSVOL veraendert
id: 3f8b2a71-9c64-4e52-b7a3-5d2c9e6f4b18
status: experimental
description: |
Erkennt das Schreiben der Datei GptTmpl.inf im SYSVOL-Ordner. Diese Datei steuert Benutzerrechte und
eingeschraenkte Gruppen einer Gruppenrichtlinie. Angreifer veraendern sie, um sich ueber eine GPO
Rechte wie SeDebugPrivilege oder die lokale Administratorgruppe domaenenweit zuzuweisen
(Group Policy Modification).
references:
- https://attack.mitre.org/techniques/T1484/001/
author: blue-team.net
tags:
- attack.privilege-escalation
- attack.t1484.001
logsource:
product: windows
category: file_event
detection:
sel:
TargetFilename|contains: '\SYSVOL\'
TargetFilename|endswith: '\GptTmpl.inf'
condition: sel
falsepositives:
- Legitime Aenderung einer Gruppenrichtlinie ueber die Gruppenrichtlinienverwaltung - bekannte Admin-Konten und Hosts als Baseline ausnehmen
level: medium
2. Sofort geplante Aufgabe über GPP im SYSVOL angelegt (T1484.001). Eine ScheduledTasks.xml unterhalb von SYSVOL. Ebenfalls level: medium.
title: Sofort geplante Aufgabe ueber GPP im SYSVOL angelegt
id: 7c1e4a93-2d85-4b61-9f52-6a3b8c7d5e24
status: experimental
description: |
Erkennt das Schreiben einer ScheduledTasks.xml im SYSVOL-Ordner. Ueber die Group Policy Preferences
lassen sich sofort startende geplante Aufgaben domaenenweit verteilen und als SYSTEM ausfuehren.
Angreifer missbrauchen das, um ueber eine veraenderte GPO Code auf vielen Hosts auszufuehren
(Group Policy Modification).
references:
- https://attack.mitre.org/techniques/T1484/001/
author: blue-team.net
tags:
- attack.privilege-escalation
- attack.t1484.001
logsource:
product: windows
category: file_event
detection:
sel:
TargetFilename|contains: '\SYSVOL\'
TargetFilename|endswith: '\ScheduledTasks.xml'
condition: sel
falsepositives:
- Regulaer per GPP verteilte geplante Aufgaben - bekannte GPOs und Admin-Workflows als Baseline ausnehmen
level: medium
3. GPO-Preferences über PowerShell-Cmdlets beschrieben (T1484.001). Die Cmdlets Set-GPPrefRegistryValue, Set-GPRegistryValue und New-GPLink. Wegen der Admin-Nutzung auf level: medium.
title: GPO-Preferences ueber PowerShell-Cmdlets beschrieben
id: 9a2d6c48-5e71-4b93-a6f2-3c7b4d8e2f51
status: experimental
description: |
Erkennt das Schreiben von Gruppenrichtlinien-Werten ueber die PowerShell-Cmdlets des GroupPolicy-Moduls.
Diese Cmdlets erlauben es, Registry-Preferences und Richtlinienwerte aus der Befehlszeile zu setzen.
Angreifer nutzen sie, um eine GPO automatisiert zu veraendern und so Rechte auszuweiten
(Group Policy Modification).
references:
- https://attack.mitre.org/techniques/T1484/001/
author: blue-team.net
tags:
- attack.privilege-escalation
- attack.t1484.001
logsource:
product: windows
category: process_creation
detection:
sel:
CommandLine|contains:
- 'Set-GPPrefRegistryValue'
- 'Set-GPRegistryValue'
- 'New-GPLink'
condition: sel
falsepositives:
- Automatisierte GPO-Verwaltung durch Administratoren - bekannte Skripte, Konten und Hosts als Baseline ausnehmen
level: medium
Härtung: der Angriff, der ins Leere läuft
- Schreibrechte auf GPOs begrenzen. Nur wenige, klar benannte Konten dürfen Gruppenrichtlinien bearbeiten oder verknüpfen; delegierte Rechte regelmäßig prüfen und überflüssige entziehen.
- Tier-Modell durchsetzen. Die Verwaltung von Domänenrichtlinien gehört auf dedizierte Verwaltungssysteme, nicht auf normale Arbeitsplätze - so fällt ein fremder Schreibzugriff sofort auf.
- SYSVOL und 5136 überwachen. Dateizugriffe auf GPO-Dateien und die Verzeichnisdienst-Änderungen an GPO-Objekten zuverlässig erfassen, damit jede Änderung einen Urheber hat.
- Kritische Rechte im Blick behalten. Die Zuweisung sensibler Benutzerrechte und eingeschränkter Gruppen über GPOs inventarisieren, damit eine neue Zuweisung als Abweichung erkennbar wird.
Der Test
Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten Domänencontroller mit aktivem Sysmon und Command-Line-Auditing:
- Für Regel 1 in einer Test-GPO die Sicherheitseinstellungen ändern und prüfen, dass das Schreiben von GptTmpl.inf im SYSVOL als Event 11 erscheint und die Regel greift.
- Für Regel 2 über die Group Policy Preferences eine geplante Aufgabe anlegen und kontrollieren, dass die ScheduledTasks.xml im SYSVOL die Regel auslöst.
- Für Regel 3 einen GPO-Wert mit Set-GPRegistryValue setzen und prüfen, dass Event 4688 die Befehlszeile zeigt.
- Breiter wird der Test mit den Fällen zu T1484.001 aus Atomic Red Team.
Fehlalarme und Tuning
- Legitime GPO-Pflege. Administratoren ändern Richtlinien regelmäßig über die Gruppenrichtlinienverwaltung. Die bekannten Admin-Konten und Verwaltungshosts als Baseline aufnehmen, bevor alarmiert wird.
- Automatisierte Verwaltung. Set-GPRegistryValue und verwandte Cmdlets kommen in Admin-Skripten vor; Regel 3 nach Konto, Host und Zeit priorisieren statt pauschal zu alarmieren.
- GPP im Einsatz. Wer geplante Aufgaben regulär per GPP verteilt, nimmt die betroffenen GPOs als bekannte Quelle auf und achtet stattdessen auf neue, unerwartete ScheduledTasks.xml.
- Kette schlägt Einzelzeile. Ein Schreibzugriff auf GptTmpl.inf von einem untypischen Konto, gefolgt von einer neuen Rechtezuweisung, ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.
Fazit
Die Manipulation von Gruppenrichtlinien ist ein stiller, aber mächtiger Weg zur Rechteausweitung: Eine einzige veränderte GPO wirkt auf viele Rechner und kann Benutzerrechte vergeben, Konten zu lokalen Administratoren machen oder Code als SYSTEM verteilen. Weil die Wirkung über den regulären Richtlinienweg läuft, bleibt der eigentliche Eingriff leicht unauffällig - sichtbar wird er am Schreibzugriff auf die Richtliniendateien im SYSVOL und an den GPO-Cmdlets in der Befehlszeile. Die verlässlichen Signale sind eine veränderte GptTmpl.inf, eine neue ScheduledTasks.xml und die PowerShell-Cmdlets des GroupPolicy-Moduls. Weil legitime Verwaltung dieselben Spuren erzeugt, liegt die Stärke in der Abgrenzung: Werkzeug, Konto, Host und Zeit entscheiden. Die wirksamste Härtung ist, Schreibrechte auf GPOs eng zu fassen und ihre Verwaltung auf dedizierte Systeme zu heben. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Privilege Escalation.