Gruppenänderungen im Active Directory sind das Ereignis, das üblicherweise überwacht wird. Wer in die Domänen-Admins aufgenommen wird, soll auffallen, und wer eine Gruppe verlässt, ebenfalls. Liest jemand nur die Mitgliederliste einer Gruppe, gilt das in den meisten Umgebungen als Betriebsgeräusch und wird nicht weiterverfolgt.
Dieser Beitrag setzt anders an. Er argumentiert, dass die Active Directory Gruppenaufzählung – das systematische Abfragen von Gruppenmitgliedschaften – das frühere und damit wertvollere Signal ist, und beschreibt, wie man sie mit Bordmitteln von Windows sichtbar macht. Die Technik bleibt überschaubar. Der Unterschied liegt im Zeitpunkt, zu dem ein Alarm entsteht.
Ein Vergleich hilft: ein Schlüsselkasten, dessen Ausgabe penibel protokolliert wird. Jede Herausgabe eines Schlüssels wird vermerkt, jeder Verlust gemeldet. Niemand notiert, wer sich den Grundriss des Gebäudes ansieht. Der Einbruch beginnt nicht mit dem Schlüssel, sondern mit dem Blick auf den Plan: Wo liegen die Räume, die sich lohnen, und welche Türen führen hinein. Wer die Active Directory Gruppenaufzählung überwacht, beobachtet diesen Blick auf den Grundriss.
Warum das Lesen von Gruppenmitgliedschaften das frühere Signal ist
Wer eine Gruppe aufzählt, sammelt keine Rechte, sondern Wissen. Nach dem ersten Fußabdruck – etwa einem phishierten Konto oder einem exponierten Dienst – will ein Angreifer wissen, wer Domain Admin, Enterprise Admin oder eine andere Rolle mit Tier-0-Rechten hält, welche Dienstkonten und Helpdesk-Gruppen einen Pfad dorthin eröffnen und welche Konten sich als Nächstes zum Diebstahl von Anmeldedaten lohnen. Das ist kein exotischer Schritt: MITRE ATT&CK führt ihn als Permission Groups Discovery: Domain Groups (T1069.002), und Sammler wie der SharpHound-Collector aus dem BloodHound-Umfeld, PowerView oder schlicht die ActiveDirectory-Cmdlets von PowerShell erledigen ihn in wenigen Minuten.
Dieser Schritt muss nicht verborgen werden. Standardmäßig darf jedes authentifizierte Konto Gruppenmitgliedschaften lesen; für berechtigte Nutzer ist das Verzeichnis ein offenes Buch. Das macht die Beobachtung brauchbar: Wer die Abfrage braucht, kann sie nicht unterlassen. Man kann sie protokollieren – oder es lassen.
Die zeitliche Reihenfolge macht den Unterschied. Wer ausschließlich Änderungen an der Gruppenmitgliedschaft überwacht, erfährt von einem Vorfall, wenn der Angreifer bereits Rechte besitzt; die Erkundung der Gruppen, die zu diesen Rechten führen, liegt dann Tage oder Wochen zurück. Wer zusätzlich die Lesezugriffe überwacht, bekommt einen Hinweis, solange der Angreifer noch auf niedrigem Recht sitzt. Und in dieser Phase ist Reaktion am günstigsten.
Zwei Voraussetzungen: Auditrichtlinie und SACL auf der Gruppe
Bevor ein Domänencontroller ein Ereignis schreibt, müssen zwei Dinge zusammenkommen. In vielen Umgebungen fehlt eines davon. Die Auditrichtlinie muss auf jedem Domänencontroller aktiv sein, idealerweise per Gruppenrichtlinie, die an der Organisationseinheit der Domain Controller verknüpft ist. Unter Advanced Audit Policy und dort unter DS Access wird Audit Directory Service Access (Erfolg) eingeschaltet.
Ob die Richtlinie greift, lässt sich auf einem Controller mit einer Zeile prüfen. Der Befehl auditpol mit /get und der Subkategorie-GUID zeigt den aktuellen Zustand – lokal auf dem System, auf dem er läuft. So zeigt sich, wie oft eine Richtlinie auf dem Papier existiert und auf dem dritten Controller seit dem letzten Umbau nicht mehr ankommt.
Die zweite Voraussetzung ist eine SACL auf jeder Gruppe, deren Mitgliederliste interessiert. Dazu setzt man einen Audit-Eintrag für Jeder beziehungsweise Authenticated Users, Typ Erfolg, angewendet auf „Dieses Objekt nur“, für das Recht „Mitglied lesen“ (Read member). In PowerShell sind das wenige Zeilen. Wichtig sind die Aufrufe über .psbase: Damit umgeht man den DirectoryEntry-Adapter von PowerShell, und die Änderung landet tatsächlich am Objekt. Wer die SACL für Active Directory Gruppen einrichtet, spart sich damit manche stille Fehlerquelle.
Für eingebaute Gruppen wie Administratoren schlägt die Aufzählung nicht als 4662 nieder, sondern als 4799. Dafür muss zusätzlich unter Account Management die Einstellung Audit Security Group Management (Erfolg) aktiviert sein, die dann auch Lesezugriffe auf diese Gruppen abbildet. Beide Richtlinien gehören in dasselbe GPO, damit sie nicht auseinanderlaufen.
Event 4662 auswerten: die Felder, auf die es ankommt
Sind beide Teile aktiv, erzeugt jeder Lesezugriff auf die Mitgliederliste ein Event 4662 im Sicherheitsprotokoll des Controllers, der die Abfrage beantwortet hat. Der Ereignistext allein hilft wenig. Wichtig sind die Felder, die den Vorgang einordnen: Der Objektname enthält die objectGUID der gelesenen Gruppe, das Feld Properties die GUID des member-Attributs, und die AccessMask steht mit 0x10 für das Lesen einer Eigenschaft.
Wer die Ereignisse auswertet, schaut zusätzlich auf SubjectUserName und SubjectUserSid, um zu wissen, welches Konto gelesen hat. Daneben steht der nützlichste Wert: SubjectLogonId, eine Sitzungskennung wie 0x3A7F21. Sie lässt sich mit dem Feld TargetLogonId eines 4624-Anmeldeereignisses auf demselben Controller verknüpfen. Erst dieser Join liefert Quell-IP-Adresse und Workstation-Namen – die Information, mit der eine Untersuchung weiterkommt.
Wer Event 4662 in Active Directory auswerten will, kommt um diesen zweiten Schritt nicht herum. Das Ereignis selbst sagt nur, dass jemand etwas gelesen hat, aber nicht, von wo aus. Ohne die Korrelation bleibt eine Spur, die ins Leere führt – ein häufiger Grund, warum solche Auswertungen nach der ersten Woche wieder abgeschaltet werden.
Rauschen, Logvolumen und die Blindstellen
Auf produktiven privilegierten Gruppen ist das Signal laut. Verzeichnissynchronisation wie Entra Connect liest Mitgliedschaften, Identitäts-Governance- und PAM-Plattformen tun dasselbe, Exchange und andere Anwendungen prüfen Gruppenzugehörigkeiten per LDAP. Dazu kommen Inventar-, Monitoring- und Schwachstellenscanner, Administratoren, die eine Gruppe in der ADUC öffnen, und jedes Skript, das Get-ADGroupMember aufruft. Jeder dieser Zugriffe erzeugt pro Gruppe ein Ereignis auf dem antwortenden Controller.
Vor dem Setzen einer SACL sollte das Logvolumen geplant werden, nicht danach. Die Auditrichtlinie allein ist verhältnismäßig ruhig. Jede zusätzliche SACL erzeugt neue Ereignisse auf jedem Domänencontroller, und dieses Volumen landet im Sicherheitsprotokoll, in den Log-Forwardern und in der Lizenzierung des SIEM. Die Sicherheitsprotokolle müssen groß genug sein, damit Ereignisse nicht überschrieben werden, bevor sie abgeholt sind. Diese Konfiguration widerspricht gängigen CIS-Empfehlungen. Wer sie umsetzt, sollte das bewusst tun und nicht als Nebenwirkung entdecken.
Filtern im SIEM ist Pflicht. Ohne Filter gehen Analysten in legitimen Lesezugriffen unter, und die Aufklärung verschwindet im Rauschen. Sinnvoll ist eine Basiserhebung über etwa einen Monat: Welche Dienstkonten und Hosts verursachen den Normalverkehr? Daraus entstehen Allowlists. Gefiltert wird im SIEM, nicht durch Entfernen der Auditregel, damit die Rohdaten für eine Untersuchung erhalten bleiben.
Blindstellen muss man kennen. Ereignisse entstehen nur auf dem Controller, der geantwortet hat. Ein Controller ohne Auditrichtlinie ist ein Loch, das ein Angreifer nutzen kann, ohne dass es auffällt. Das Lesen von memberOf auf Benutzerobjekten oder eine Abfrage von tokenGroups zeigt Mitgliedschaften, ohne das member-Attribut der Gruppe zu berühren. SAMR-basierte Werkzeuge wie net group /domain umgehen dieses Signal vollständig, anders als LDAP-Abfragen. Dafür braucht es eigene Erkennungen, etwa auf Endpunkten über Prozess-Erstellung mit Kommandozeilen (Event 4688, Sysmon-Ereignis 1 oder EDR) für net.exe und net1.exe.
Ein letztes Detail betrifft die Vererbung. Gruppen mit adminCount=1 blockieren die Vererbung und werden etwa alle 60 Minuten aus dem AdminSDHolder zurückgesetzt. Wer die Auditregel nur auf die Gruppe setzt, kann sie so wieder verlieren; sie gehört zusätzlich auf AdminSDHolder.
Honeypot-Gruppen: aus Rauschen wird ein Stolperdraht
Honeypot-Gruppen in Active Directory sind Attrappen: Sie sehen wertvoll aus und tun nichts. Keine Anwendung nutzt sie, kein Administrator pflegt sie, kein legitimer Prozess hat einen Grund, ihre Mitgliederliste zu lesen. Jedes 4662-Ereignis gegen sie ist ein echter Treffer, keine Interpretationsfrage. Auf den Domänen-Admins ist ein Lesezugriff einer unter Tausenden; auf einer Attrappe namens Tier0-Server-Admins oder SQL-Prod-Admins ist ein einzelner Zugriff ein Alarm.
Damit die Attrappe glaubwürdig bleibt, sollte sie sich an den eigenen Namenskonventionen orientieren – Angreifer suchen nach Wörtern wie admin, prod, backup oder DBA. Ein bis zwei Köderkonten mit realistischen Namen geben der Gruppe Substanz; Anmeldezeitbeschränkungen oder eine stark eingeschränkte Liste erlaubter Arbeitsstationen verhindern, dass daraus ein echter Zugang wird, und ein gefälschter Service Principal Name lädt zum Kerberoasting ein, was wiederum als 4769 sichtbar wird. Gleichzeitig muss die Gruppe aus dem Bereich von Verzeichnissynchronisation und Inventarisierung herausgehalten werden, sonst liest sie jemand aus Versehen.
Weil das Volumen nahe null liegt, kann auf der Attrappe breit auditiert werden: Erfolg für alle Eigenschaften, nicht nur für member. Der Gewinn entsteht aus der Korrelation. Sammler wie SharpHound lesen jede erreichbare Gruppe. Wenn dieselbe SubjectLogonId innerhalb weniger Minuten die Attrappe und die echten administrativen Gruppen liest, ist das wahrscheinlich Aufklärung. Der Join zum 4624-Ereignis nennt dann die Maschine, die isoliert werden muss. In der Produktion gehört diese Logik als Regel hoher Schwere in das SIEM.
Rollout in Phasen: von der Prüfung zur belastbaren Regel
Ein stufenweises Vorgehen hält das Logvolumen beherrschbar und bringt früh Ergebnisse. Zuerst wird die Auditrichtlinie per GPO auf allen Domänencontrollern aktiviert und auf jedem einzeln mit auditpol verifiziert. Danach kommen ein bis zwei Honeypot-Gruppen mit SACL und einer SIEM-Warnung hinzu. Diese Erkennung ist früh verlässlich, ohne die Umgebung mit Ereignissen zu fluten.
Im dritten Schritt wird einen Monat lang erhoben und gefiltert, wer legitim liest, bevor auf echten Gruppen alarmiert wird. Erst danach folgen SACLs auf den wichtigsten Tier-0-Gruppen und auf eigenen privilegierten Gruppen, idealerweise inklusive AdminSDHolder, weil darüber auch Domain Admins und Enterprise Admins erfasst werden. Abschließend wird mit den Werkzeugen des Angreifers getestet: SharpHound oder PowerView aus einem Testkonto heraus müssen die eigenen Alarme auslösen.
Für den Einstieg gibt es ein PowerShell-Skript namens QuietPhase, veröffentlicht auf GitHub. Es prüft, ob die Domäne für die Erkennung von Gruppenaufzählung konfiguriert ist, bewertet die SACLs bekannter administrativer Gruppen sowie eigener privilegierter Gruppen und schlägt Korrekturen vor. Standardmäßig meldet es nur, ohne etwas zu ändern; auf Anforderung wendet es die Korrekturen an. Benötigt werden PowerShell 7.2 oder neuer, das ActiveDirectory-Modul aus den RSAT-Werkzeugen, eine erhöhte Sitzung sowie WinRM für die Prüfung entfernter Controller. Gruppen werden über ihre SID gefunden, was sprachunabhängig funktioniert. Wer ein solches Werkzeug in einer gewachsenen Domäne einsetzt, sollte es vorher in einer Testumgebung prüfen – die Bewertung von SACLs ist heikel, und ein Skript, das schreibt, schreibt schnell an der falschen Stelle.
Die Active Directory Gruppenaufzählung zu erkennen ersetzt nicht die Überwachung von Mitgliedschaftsänderungen. Sie ergänzt sie und verlängert den Zeitraum, in dem eine Reaktion möglich ist. Wer verdächtige Gruppenlesezugriffe überwacht, gewinnt Tage statt Minuten. Ein einzelner Lesezugriff auf eine Attrappe ist ein Angreifer, der sich verrät, bevor er etwas erreicht. Der Aufwand liegt weniger im Verstehen als im Aushalten des Rauschens. Diese Entscheidung lässt sich planen, solange noch niemand im Gebäude steht und den Grundriss studiert.
Quelle: trustedsec.com
