Tim Beasley Senior Incident Response

Willkommen zurück zu unserer Untersuchung risikobehafteter Active-Directory-Gruppen, die auf den ersten Blick nicht risikobehaftet „erscheinen“. Wie ich bereits in unserem ersten Teil erläutert habe, benötigen Angreifer keine „Domain-Admin“-Rechte, um erheblichen Schaden anzurichten, und sie suchen nicht immer nach Gruppen mit derart offensichtlichen, weitreichenden Berechtigungen.

„Account Operators“ ist eine AD-Gruppe, die von vielen unterschätzt wird, da sie das Wort „Admins“ nicht enthält. Genau aus diesem Grund wird sie so oft übersehen.

Ein weit verbreiteter Irrtum ist, dass „Account Operators“ kein ernstzunehmendes Risiko darstellen, da Mitglieder geschützte Gruppen wie „Domain Admins“ eigentlich nicht ändern dürfen.

Diese Annahme ist bestenfalls unvollständig – und schlimmstenfalls gefährlich.
Unter bestimmten Umständen ist sie zudem falsch.

Das Hauptproblem besteht nicht darin, dass die Gruppe „Account Operators“ eine direkte Verwaltungsgruppe der „obersten Ebene“ ist (obwohl wir sie als solche behandeln). Das eigentliche Problem ist, dass sie weitreichende Kontrolle über Identitäten in der gesamten Domäne gewährt – und in Active Directory sind Identitäten gleichbedeutend mit Berechtigungen.


Was können Kontobetreiber eigentlich tun?

Standardmäßig können Mitglieder der Gruppe „Account Operators“ Benutzer-, Gruppen- und Computerobjekte in weiten Teilen der Domäne erstellen, ändern und löschen. In vielen Umgebungen umfasst dies folgende Befugnisse:

  • Passwörter zurücksetzen
  • Konten aktivieren oder deaktivieren
  • Dienstprinzipalnamen (SPNs) bearbeiten
  • Verwaltung der Mitgliedschaft in nicht geschützten Gruppen
  • Neue Computerkonten anlegen

Kontoverwaltern ist es bewusst untersagt, geschützte Gruppen und Konten, die von „AdminSDHolder“ verwaltet werden – darunter „Domain-Administratoren“, „Unternehmensadministratoren“, „Schema-Administratoren“ und die integrierte Gruppe „Administratoren“ auf Domänencontrollern –, direkt zu ändern.

Diese Einschränkungen beseitigen jedoch nicht die Angriffswege, die ein versierter Angreifer nutzen kann, nachdem er sich Zugang zu einem Mitglied der „Account Operators“ verschafft hat.

Das ist der entscheidende Punkt, den Sicherheitsverantwortliche verinnerlichen müssen: „Account Operators“ ist keine harmlose, delegierte Administratorrolle.
Es handelt sich um einen Privilegienverstärker, der direkt auf der Identitätsebene angesiedelt ist.


Warum wird die Gruppe der „Account Operators“ so schnell zu einer Gefahr?

Sollte ein Angreifer die Anmeldedaten eines Kontoadministrators kompromittieren, muss er sich nicht zur Gruppe „Domänenadministratoren“ hinzufügen, um seine Ziele zu erreichen.

Ich habe beobachtet, wie sie von Angreifern kontrollierte Benutzer angelegt, Passwörter für ungeschützte privilegierte Konten zurückgesetzt, die Gruppenzugehörigkeit indirekt manipuliert, SPNs für die Einrichtung von Kerberoasting hinzugefügt und die Erstellung von Computerobjekten für Delegierungsangriffe wie die ressourcenbasierte eingeschränkte Delegierung missbraucht haben.

Dies ist von Bedeutung, da viele der realistischsten Angriffspfade in Unternehmen es nicht erfordern, zunächst die offensichtlichen „Kronjuwelen“-Gruppen anzusteuern. Die Angreifer benötigen lediglich die richtigen Identitäten, die richtigen delegierten Gruppen und die richtigen Authentifizierungspfade – gerade so lange, bis sie sich weiterbewegen können.

Mit anderen Worten: „Account Operators“ gewähren einem Angreifer verteilten Schreibzugriff auf die gesamte Identitätsinfrastruktur. Das reicht oft schon aus, um von „noch nicht ganz privilegiert“ zu „Ich habe Sie im Griff“ zu gelangen.


Realistische Missbrauchswege nach der Kompromittierung durch Account-Betreiber

Ein naheliegender Weg ist die Erstellung von Backdoor-Konten. Ein Angreifer kann einen neuen Benutzer anlegen und diesen anschließend in privilegierte oder halbprivilegierte Gruppen einbinden, die er kontrollieren kann – darunter auch Gruppen mit versteckten Eskalationspfaden, die oft weitaus weniger streng überwacht werden als „Domain Admins“. Darüber hinaus ermöglicht dieser Ansatz dem Angreifer, die Gruppennestung innerhalb privilegierter Gruppen zu ermitteln, was eine weitere Eskalation und Persistenz ermöglicht.

Ein weiterer häufiger Angriffsweg sind gezielte oder pauschale Maßnahmen zur Passwortzurücksetzung. Kontoadministratoren können die Passwörter der meisten Benutzer in der Domäne zurücksetzen, darunter auch Dienstkonten, Anwendungsidentitäten und nicht geschützte Administratorbenutzer. In den Händen eines Angreifers bedeutet dies sofortigen Zugriff auf die Betriebsabläufe und potenzielle Betriebsstörungen.

Ein dritter Ansatz ist der Missbrauch von SPNs und das sogenannte „Kerberoasting“. Kann ein Angreifer Kontoattribute bearbeiten und SPNs hinzufügen, ist er in der Lage, neue Ziele für Kerberoasting zu schaffen oder bestehende Konten angreifbar zu machen, ohne dass der „Angriff“ offensichtlich erscheint.

Ein vierter Weg besteht darin, ungeschützte, aber dennoch wertvolle Konten zu missbrauchen. In vielen Organisationen gibt es nach wie vor delegierte Administratoren, veraltete Dienstkonten und verschachtelte Gruppen, die nicht durch „AdminSDHolder“ geschützt sind. Das Zurücksetzen von Passwörtern oder das Ändern von Attributen bei diesen Objekten kann bereits ausreichen, um sich höhere Berechtigungen zu verschaffen.

Und dann gibt es noch Missbrauch von Computerkonten. Da Kontoadministratoren häufig Computerobjekte erstellen und die Kontrolle darüber haben, was sie erstellen, können sie Angriffe ermöglichen, bei denen MachineAccountQuota sowie eine durch Ressourcen begrenzte Delegierung. Dies eröffnet einen Weg zur Identitätsfälschung und zur Ausweitung von Berechtigungen, ohne jemals direkt auf die Gruppe „Domain-Administratoren“ zugreifen zu müssen.

Haben wir schon Spaß?


Die Nuance von „AdminSDHolder“, die Befürworter nicht außer Acht lassen sollten

An dieser Stelle wird das Gespräch noch unangenehmer.

Theoretisch sollten Kontoadministratoren keine geschützten Gruppen wie „Domain-Administratoren“ oder „Unternehmensadministratoren“ ändern können.

In der Praxis wird dieser Schutz nicht kontinuierlich durchgesetzt. Er wird durch den Prozess „Security Descriptor Propagator“, allgemein als SDProp bezeichnet, gewährleistet, der die AdminSDHolder-ACL in regelmäßigen Abständen auf geschützte Objekte anwendet. Standardmäßig läuft dieser Zyklus etwa alle 60 Minuten.

Das standardmäßige 60-Minuten-Intervall von SDProp ist von Bedeutung. Zwischen den Verarbeitungsläufen können sich „geschützte Objekte“ vorübergehend vom beabsichtigten Sicherheitsdeskriptor abweichen. Wenn sich Berechtigungen verschoben haben, wenn vererbte oder delegierte Rechte noch nicht vollständig korrigiert wurden oder wenn ein neu erstelltes oder neu geändertes Objekt noch nicht erneut mit dem Sicherheitsdeskriptor versehen wurde, kann ein Angreifer eine kurzzeitige Gelegenheit erhalten, diese Lücke auszunutzen, bevor SDProp die geschützte ACL erneut anwendet.

Das bedeutet, dass ein Angreifer möglicherweise keine dauerhafte Mitgliedschaft in einer geschützten Gruppe benötigt. Es reicht ihm möglicherweise bereits aus, innerhalb dieses standardmäßigen 60-Minuten-Fensters genügend Zeit zu haben, um einen kontrollierten Teilnehmer hinzuzufügen, eine privilegierte Sitzung zu starten, geheime Daten abzugreifen, Hintertür-Konten anzulegen oder an anderer Stelle eine dauerhafte Präsenz zu etablieren, bevor SDProp die offensichtlichen Spuren auf ACL- oder Mitgliedschaftsebene beseitigt. Möglicherweise hat er sogar Zeit, ein neu erstelltes Administratorkonto zurückzusetzen.

60 Minuten sind für einen versierten Angreifer eine lange Zeit.

Dies stellt für die Sicherheitsverantwortlichen ein großes Problem bei der Erkennung dar, da dadurch die Möglichkeit einer nur sehr kurzzeitigen privilegierten Mitgliedschaft entsteht, auf die privilegierte Aktivitäten von einem Konto folgen, das bei einer späteren Überprüfung durch die Ermittler möglicherweise nicht mehr als privilegiert erkennbar ist.

Die wichtigste Erkenntnis ist, dass der AdminSDHolder-Schutz „eventually consistent“ (langfristig konsistent) und nicht in Echtzeit erfolgt, und dass der standardmäßige 60-minütige SDProp-Zeitplan die Lücke darstellt, die ein Angreifer auszunutzen versucht.


Was sollten Sicherheitsverantwortliche überwachen, um den Missbrauch durch Account-Betreiber aufzudecken?

Wenn Sie den Missbrauch von Kontoadministratoren aufdecken möchten, beginnen Sie mit den Aktivitäten im Identitätslebenszyklus. Die Erstellung neuer Konten, die Freischaltung von Konten, das Zurücksetzen von Passwörtern sowie Änderungen an Konten sind allesamt wichtige Indikatoren, wenn sie von einem Mitglied dieser Gruppe durchgeführt werden. Zu den relevanten Ereignissen zählen 4720, 4722, 4723 oder 4724 sowie 4738.

Beobachten Sie als Nächstes Änderungen bei der Gruppenzugehörigkeit genau, insbesondere Neuzugänge zu ungewöhnlichen delegierten Gruppen, verschachtelten Gruppen oder selten genutzten Gruppen mit Berechtigungen. Ereignisse wie 4728, 4732 und 4756 sind hier von Bedeutung, und im Szenario mit kurzem Zeitfenster müssen Sie zudem Muster schneller Hinzufügungen und Entfernungen mit den Ereignissen 4729, 4733 und 4757 in Zusammenhang bringen.

Sie sollten außerdem auf Änderungen an SPNs und andere Änderungen an Verzeichnisattributen achten. Ereignis 5136 ist wichtig für unerwartete servicePrincipalName Bearbeitungen, Änderungen an Attributen im Zusammenhang mit der Delegierung, wie beispielsweise msDS-AllowedToActOnBehalfOfOtherIdentity, sowie weitere verdächtige Änderungen an neu erstellten oder kürzlich geänderten Objekten.

Erstellen Sie abschließend eine Verhaltensbasislinie.

  • Wie viele Benutzer legt ein Mitglied der Gruppe „Account Operators“ normalerweise pro Tag an?
  • Wie viele Passwortzurücksetzungen führen sie normalerweise durch?
  • Wer sind die üblichen Zielgruppen?

Abweichungen von dieser Basislinie sind der Ausgangspunkt für Erkennungen mit hoher Zuverlässigkeit.


Was kann man dagegen tun?

Die empfohlene Vorgehensweise ist einfach: Leeren Sie die Gruppe.

Sofern kein triftiger betrieblicher Grund für die Verwendung von Konto-Operatoren vorliegt (was fast IMMER der Fall ist), entfernen Sie die Mitgliedschaft und lassen Sie das Feld leer. Sollten Sie dennoch eine delegierte Verwaltung benötigen, nutzen Sie eine maßgeschneiderte Delegierung für die spezifischen Organisationseinheiten und Objekte, die tatsächlich verwaltet werden müssen.

Sollte die Gruppenzugehörigkeit nicht sofort beseitigt werden können, behandeln Sie diese als weitaus sensibler, als dies derzeit in den meisten Organisationen der Fall ist.

  • Verwaltungsstufung durchsetzen
  • Verhindern Sie die interaktive Anmeldung an Domänencontrollern und kritischen Servern
  • Verhindern Sie lokale Anmeldungen, soweit dies möglich ist

Sie sollten zudem die Möglichkeiten für den Missbrauch von Computerobjekten einschränken, indem Sie MachineAccountQuota (vorzugsweise auf null), sofern dies angemessen ist, und die Einschränkung, wer neue Computerkonten anlegen darf.

Überwachen Sie darüber hinaus gezielt die Bereiche, die eine Eskalation innerhalb eines kurzen Zeitfensters oder auf indirektem Wege ermöglichen: Änderungen an privilegierten Gruppen, Änderungen an Delegierungen, SPN-Änderungen sowie ACL-Änderungen an „AdminSDHolder“ und geschützten Gruppen.


Überdenken Sie die Risiken von Kontobetreibern

Die Gruppe „Account Operators“ ist gefährlich, da sie weitreichende Kontrollbefugnisse über die Objekte gewährt, die den Zugriff, die Vertrauensbeziehungen und die Authentifizierung im gesamten Active Directory definieren.

Ein kompromittierter Account-Operator kann neue Prinzipale anlegen, Passwörter zurücksetzen, Gruppen manipulieren, Kerberoasting einrichten, Delegierungen missbrauchen, Persistenz herstellen und unter den richtigen Bedingungen die in den AdminSDHolder-Schutzmechanismen integrierte Verzögerung ausnutzen.

Aus diesem Grund sollten erfahrene Sicherheitsbeauftragte aufhören, Account-Operatoren als eine veraltete Support-Rolle zu betrachten, und sie stattdessen als das behandeln, was sie tatsächlich sind: einen Zugang ohne Sonderrechte mit mehreren Eskalationsmöglichkeiten … auch bekannt als Tier 0.

Die Identität ist die Schutzgrenze … schützen Sie sie.

Bis zum nächsten Mal …Verfolgen Sie die Diskussion zum Thema „Account Operators“ auf LinkedIn.

Und wenn Sie fachkundige Unterstützung bei der Ermittlung und Behebung von Sicherheitslücken in Ihrem Active Directory benötigen, wenden Sie sich an uns für eine Active Directory-Sicherheitsbewertung. Wir sind für Sie da.


Weitere Lektüre