Magic Quadrant™ für Privileged Access Management 2025: Netwrix zum vierten Jahr in Folge anerkannt. Laden Sie den Bericht herunter.

Plattform
Ressourcen­zentrumBlog
Vier Herausforderungen bei der Überwachung der Active Directory Security

Vier Herausforderungen bei der Überwachung der Active Directory Security

Jan 20, 2023

Angesichts der ständigen Entwicklung neuer Taktiken von Angreifern, um Anmeldeinformationen und Daten zu kompromittieren, wird es immer wichtiger, kritische Systeme wie Active Directory (AD) auf Anzeichen bösartiger Aktivitäten zu überwachen.

Viele Organisationen wenden sich an security information and event management (SIEM)-Produkte zur Unterstützung. Aber obwohl diese Lösungen sehr leistungsfähig sein können, hängen sie letztendlich von Windows-Ereignisprotokollen ab – die kompliziert zu handhaben sind und nicht die benötigten Informationen liefern, um mehrere wichtige AD-Angriffsvektoren zu überwachen.

Dieser Blog untersucht vier der größten Herausforderungen bei der Sicherung von Active Directory und erklärt die Grenzen der Verwendung von Ereignisprotokollen, um diese zu bewältigen.

Herausforderung 1. Überwachung von Änderungen in der Gruppenmitgliedschaft

Sicherheitsgruppen im Active Directory sind der primäre Weg, über den Benutzern Zugriff auf IT-Ressourcen wie Daten, Maschinen und Anwendungen gewährt wird. Wenn Angreifer sich seitlich durch Ihre Umgebung bewegen, fügen sie häufig die von ihnen kompromittierten Konten neuen Sicherheitsgruppen hinzu, um zusätzliche Privilegien zu erlangen, daher ist es entscheidend, Änderungen in der Mitgliedschaft von Sicherheitsgruppen zu verfolgen.

Das Nachverfolgen von Änderungen an Gruppen, die Privileged Access bieten, ist besonders wichtig. Dies schließt eingebaute Gruppen wie Domain Admins, Enterprise Admins und Schema Admins ein, sowie jegliche Sicherheitsgruppen, die Ihre Organisation erstellt hat, die erweiterte Zugriffsrechte gewähren.

Was das Ereignisprotokoll erfasst – und seine Grenzen

Active Directory protokolliert Änderungen an Sicherheitsgruppen im Ereignisprotokoll. Wenn beispielsweise ein Benutzer zur Gruppe der Domain-Admins hinzugefügt wird, erzeugt AD ein Ereignis wie das unten gezeigte, das folgende wichtige Details enthält:

  • Die ID des Benutzers, der die Änderung durchgeführt hat
  • Der DN und die Klasse des Objekts, das geändert wurde
  • Die Art der Änderung (in diesem Fall, dass ein Mitglied hinzugefügt wurde)
Image

Abbildung 1. Beispielereignis, das zeigt, dass eine Sicherheitsgruppe geändert wurde

Allerdings hat das Ereignisprotokoll mehrere wichtige Einschränkungen:

  • · Keine Aufzeichnung darüber, woher die Änderung kam — Ereignisprotokolle zeichnen nicht auf, von welcher Quelle eine Änderung an der Gruppenmitgliedschaft stammt. Obwohl eine Änderung an der Gruppe der Domain-Admins von einem Jump-Server oder Domain-Controller (DC) normal sein kann, kann eine Änderung von einem nicht-administrativen Arbeitsplatz oder einer anderen internetexponierten Maschine ein deutliches Zeichen für einen Angriff sein. Ohne Details über die Quelle der Änderung ist es unmöglich, auf Änderungen aus ungewöhnlichen Orten zu alarmieren.
  • · Keine Überwachung der effektiven Gruppenmitgliedschaft — Active Directory protokolliert nur Änderungen an der direkten Mitgliedschaft einer Gruppe. Gruppen können jedoch auch andere Gruppen als Mitglieder enthalten. Um also Änderungen an der Mitgliedschaft einer Gruppe wirklich zu überwachen, müssen Sie die Gruppe selbst und jede darin verschachtelte Gruppe überwachen.
  • · Inkonsistenzen zwischen Ereignissen — Die protokollierten Ereignisse werden je nach Art der Gruppenänderung unterschiedlich sein. Zum Beispiel, wenn ein Benutzer mit Active Directory Service Interfaces (ADSI) zu einer Gruppe hinzugefügt wird, zeigt das Ereignisprotokoll ein Entfernungsereignis für jedes bestehende Gruppenmitglied, gefolgt von einem Ereignis, das jedes Gruppenmitglied wieder hinzufügt, gefolgt von einem Ereignis, das den neuen Benutzer hinzufügt; daher wird das Hinzufügen eines Benutzers zu einer Gruppe mit 50 Mitgliedern 101 Ereignisprotokolleinträge generieren. Und wenn die Änderung mit LDAP vorgenommen wurde, kann anstelle des eindeutigen Namens die GUID des Objekts aufgeführt sein. Diese Inkonsistenzen können Verwirrung und Fehlinformationen in SIEM-Produkten verursachen und es extrem schwierig machen, effektive Regeln zu erstellen, die auf die gesammelten Daten reagieren.

Herausforderung 2. Überwachung von Änderungen an der Gruppenrichtlinie

Gruppenrichtlinieneinstellungen wirken sich auf Benutzer und Computer im gesamten Active Directory domain aus, einschließlich, zum Beispiel, wer administrativen Zugriff auf Systeme hat. Eine einzige Änderung an einem Group Policy object (GPO) kann schwerwiegende Sicherheitsauswirkungen haben oder Produktionsausfälle verursachen, daher ist die Überwachung dieser Änderungen von entscheidender Bedeutung.

Was das Ereignisprotokoll erfasst – und seine Grenzen

Wenn eine Gruppenrichtlinie geändert wird, wird ein Ereignis wie das in Abbildung 2 dargestellte protokolliert. Dieses Ereignis liefert nützliche Informationen, wie zum Beispiel, wer die Änderung vorgenommen hat und die Kennung der GPO.

Image

Abbildung 2. Ereignisprotokollierung für eine Änderung der Gruppenrichtlinie

Allerdings fehlen diesen Ereignissen die folgenden kritischen Informationen:

  • · Details darüber, welche Einstellung geändert wurde und ihre Werte vor und nach der Änderung — GPOs unterstützen Hunderte von standardmäßigen und benutzerdefinierten Einstellungen. Eine Änderung könnte die Standard-Startseite des Browsers für Benutzer modifizieren oder allen Benutzern administrative Kontrolle über einen kritischen Rechner gewähren. Das Ereignisprotokoll erfasst jedoch nicht die geänderte Einstellung und worauf sie geändert wurde.
  • · Ursprung der Änderung — Wie bei Änderungen an Sicherheitsgruppen zeigen Ereignisse, die Änderungen an Gruppenrichtlinien aufzeichnen, nicht an, woher die Änderung kam. Die meisten GPO-Änderungen sollten von einer ausgewählten Anzahl von Orten kommen, und die Fähigkeit, Änderungen zu identifizieren, die von abnormalen Orten kommen, ist entscheidend, um Angriffe schnell zu erkennen.

Herausforderung 3. Überwachung von Directory Reads

Eine weitere wichtige Aufgabe bei der Sicherung Ihres Active Directory besteht darin, zu überwachen, wie Benutzerkonten AD-Objekte lesen und auflisten. Angreifer, die einen Zugang zu Ihrem Netzwerk suchen, listen oft kritische Konten, Gruppen und Server auf, um Angriffswege zu entdecken, die zu erhöhten Privilegien und letztendlich zu sensiblen Daten führen. Indem Sie verdächtige Lesevorgänge überwachen, können Sie diese Aufklärungsaktivitäten erkennen und einen Angriff stoppen, bevor es zu spät ist.

Was das Ereignisprotokoll erfasst – und seine Grenzen

Um Ihnen zu helfen zu sehen, wer das Active Directory erkundet, erfasst das Ereignisprotokoll Leseaktivitäten. Das Ereignis zeigt Details über das Benutzerkonto, das gelesene Objekt und die Art der durchgeführten Operation, wie in Abbildung 3 dargestellt:

Image

Abbildung 3. Ein Ereignis, das anzeigt, dass eine Eigenschaft von Domain Admins gelesen wurde

Allerdings hat der Versuch, diese Ereignisse zur Beobachtung verdächtiger Aktivitäten zu nutzen, mehrere Nachteile:

  • Zu viel Lärm — Das Protokollieren von Lesevorgängen führt zu so viel Lärm im Ereignisprotokoll, dass es nahezu unmöglich ist, wertvolle Informationen zu finden. Tatsächlich kann eine einzige Instanz eines Benutzers, der eine Gruppe betrachtet, Dutzende oder sogar Hunderte von Ereignissen im Protokoll erzeugen, was es nahezu unmöglich macht, verdächtige Aktivitäten unter all den legitimen Ereignissen zu finden.
  • Keine Aufzeichnung darüber, woher das Lesen kam — Darüber hinaus gibt es keine Möglichkeit zu wissen, woher das Leseereignis stammt. Wie wir bei Änderungen an Sicherheitsgruppen und GPOs gesehen haben, ist es entscheidend zu wissen, von welchem Computer ein Leseereignis kommt, um zu bestimmen, ob es sich um ein harmloses Lesen oder eine bösartige Handlung der Aufklärung handelt.
  • Zu viele Ereignisse von verweigertem Zugriff — Es ist ebenfalls entscheidend, Benutzer zu erkennen, die versuchen, auf Informationen zuzugreifen, zu denen sie kein Recht haben. Beispielsweise kann Active Directory Klartext-Passwörter für administrative Konten in Computerattributen speichern, sodass ein Benutzerkonto, das versucht, diese Attribute zu lesen, möglicherweise versucht, privilegierte Anmeldeinformationen zu kompromittieren. Leider erzeugt jedes Mal, wenn ein Konto aus irgendeinem Grund ein Objekt betrachtet, die Aktion Zugriffsfehlerereignisse für alle Attribute, zu denen sie keine Leserechte haben, selbst wenn sie nicht beabsichtigten, diese Attribute zu lesen. Es ist einfach keine praktikable Strategie, wirklich verdächtige fehlgeschlagene Zugriffsereignisse unter der Masse unschuldiger Ereignisse zu finden.
  • Keine einfache Möglichkeit, LDAP-Abfragen zu überwachen — LDAP-Abfragen werden häufig verwendet, um Active Directory zu durchsuchen und Benutzer, Gruppen und Computer zu entdecken. Leider bietet Microsoft keine einfache Möglichkeit, LDAP-Abfragen zu überwachen, um die gestellte Abfrage und deren Ursprung zu sehen. Aufgrund dieses Problems liefert selbst das Aktivieren der diagnostischen LDAP-Überwachung wenig Nutzen; tatsächlich wird es von Microsoft nicht empfohlen, da es eine enorme Menge an Rauschen in den Ereignisprotokollen erzeugen würde.

Herausforderung 4. Überwachung von Authentifizierungsereignissen

Angesichts des jüngsten Anstiegs von Angriffen, die auf Zugangsdaten basieren, ist die Überwachung von Authentifizierungsmustern entscheidend, um kompromittierte Konten, Anzeichen von pass-the-hash und pass-the-ticket attacks, forged Kerberos tickets, oder andere Exploits zu identifizieren, die verwendet werden, um Privilegien zu erlangen und Zugang zu sensiblen Daten zu bekommen.

Was das Ereignisprotokoll erfasst – und seine Grenzen

Active Directory erfasst Ereignisse, um die Anmelde- und Authentifizierungsaktivitäten auf Domänencontrollern, Mitgliedsservern und Arbeitsstationen zu überwachen, einschließlich derer, die in der folgenden Tabelle aufgeführt sind:

4768

Ein Kerberos-Authentifizierungsticket (TGT) wurde angefordert.

Domänencontroller

4769

Ein Kerberos-Dienstticket wurde angefordert.

Domänencontroller

4773

Eine Kerberos-Service-Ticketanfrage ist fehlgeschlagen.

Domänencontroller

4776

Der Domänencontroller versuchte, die Anmeldeinformationen für ein Konto zu validieren.

Domänencontroller

4771

Die Kerberos-Pre-Authentifizierung ist fehlgeschlagen.

Domänencontroller

4624

Ein Konto hat sich erfolgreich angemeldet.

Server oder Arbeitsstation

4625

Ein Konto konnte sich nicht anmelden.

Server oder Arbeitsstation

4634

Ein Konto wurde abgemeldet.

Server oder Arbeitsstation

Obwohl diese Ereignisse einige nützliche Informationen erfassen, bieten sie keine effektive Möglichkeit, Angriffe auf Basis von Authentifizierung zu erkennen, aufgrund der folgenden Mängel:

  • Zu viel Lärm — Ereignisse werden jedes Mal erstellt, wenn sich ein Benutzer an einem beliebigen Computer anmeldet, was typischerweise eine enorme Menge an Aktivität darstellt. Viele andere Ereignisse werden im Hintergrund erstellt. Zum Beispiel, wenn sich ein Benutzer an einem Mitgliedsserver anmeldet, der einer AD-Domäne beigetreten ist, initiiert der Server eine Verbindung zu einem DC, der Gruppenrichtlinieninformationen abruft, was dazu führt, dass Anmelde-/Abmeldeereignisse im Ereignisprotokoll des DC erscheinen. Es gibt keine Möglichkeit, die Protokollierung normaler Benutzeranmeldeaktivitäten zu deaktivieren, ohne kritische Anmeldeaktivitäten an Ihren Domänencontrollern zu ignorieren.
  • Keine Aufzeichnung des Anmeldetyps auf DCs — Die Protokolle verfolgen den Anmeldetyp für Anmeldeereignisse auf DCs nicht, ein Kontext, der äußerst wertvoll ist, um zu bestimmen, ob Konten auf angemessene Weise verwendet werden. Beispielsweise gibt es keine einfache Möglichkeit, zwischen einer Anmeldung über Remote Desktop und einer Netzwerkanmeldung über ein zugeordnetes Netzlaufwerk zu unterscheiden; man muss Protokolle von jedem Mitgliedsserver sammeln und versuchen, diese mit den Protokollen von den DCs zu korrelieren.
  • Fehlen von protokollspezifischen Details — Die Ereignisse vermissen auch andere wertvolle Details. Beispielsweise zeichnen Kerberos-Authentifizierungsereignisse nicht die Lebensdauer und Erneuerungszeitstempel der Tickets auf, die wertvolle Indikatoren für gefälschte Tickets beim Golden Ticket exploit sind. Ebenso spezifizieren NTLM-Protokolle nicht die verwendete NTLM-Version, eine Information, die wertvoll ist, um zu bestimmen, ob man ältere NTLM-Versionen zugunsten sichererer Protokolle deaktivieren kann.

Wie Netwrix helfen kann

Wie wir gesehen haben, sind Ereignisprotokolle unzureichend, um Angriffe rechtzeitig zu erkennen und effektiv darauf zu reagieren. Für einen umfassenden Schutz sollten Sie die Netwrix Active Directory security solution in Betracht ziehen. Sie wird Ihnen dabei helfen:

  • Identifizieren Sie proaktiv Sicherheitslücken durch eine umfassende Risikobewertung.
  • Minimieren Sie kostspielige Ausfallzeiten und Geschäftsunterbrechungen.
  • Erkennen Sie selbst fortgeschrittene Bedrohungen rechtzeitig und reagieren Sie schnell.

Teilen auf

Erfahren Sie mehr

Über den Autor

Asset Not Found

Joe Dibley

Sicherheitsforscher

Security Researcher bei Netwrix und Mitglied des Netwrix Security Research Teams. Joe ist ein Experte für Active Directory, Windows und eine Vielzahl von Unternehmenssoftwareplattformen und -technologien. Joe erforscht neue Sicherheitsrisiken, komplexe Angriffstechniken sowie zugehörige Milderungs- und Erkennungsmaßnahmen.