ACL-Missbrauch bei Computerobjekten: DACL in AD prüfen

Was bedeutet ACL-Missbrauch bei Computerobjekten in Active Directory?

Bei einer Prüfung auf ACL-Missbrauch bei Computerobjekten in Active Directory geht es darum, wer das Verzeichnisobjekt einer Maschinenidentität ändern kann. GenericAll, WriteDACL und WriteOwner können Wege zu ressourcenbasierter eingeschränkter Delegierung (RBCD), nicht autorisierten Schlüsselanmeldeinformationen oder einem Zurücksetzen des Maschinenkennworts eröffnen. Eine gefährliche Berechtigung belegt eine Gefährdung; der Nachweis ihrer Ausnutzung erfordert Änderungs- und Authentifizierungsbelege.

Die Einführung in die Angriffsfläche von Computerobjekten erläutert bereits den RBCD-ACL-Pfad zusammen mit Delegierung, Replikationsrechten und privilegierten Gruppenmitgliedschaften. Dieser Leitfaden überführt diese Grundlage in eine operative Prüfung: DACL und Eigentümer untersuchen, drei Missbrauchspfade unterscheiden, Belege für Verzeichnisänderungen sammeln und sowohl den Berechtigungspfad als auch nicht autorisierte Konfigurationen bereinigen.

Die Prüfung betrifft Rechte auf einem Computerobjekt. Ein Maschinenkonto mit Berechtigungen an anderer Stelle stellt eine andere Beziehung dar. Erfassen Sie DN und GUID des kontrollierten Objekts, den Berechtigungsempfänger, den Geltungsbereich der Berechtigung und den vorgesehenen administrativen Zweck, bevor Sie entscheiden, was entfernt werden soll.

Funktionsweise: DACL und Eigentümer prüfen

Eine Discretionary Access-Control List (DACL) enthält Access-Control Entries (ACEs). Jeder Eintrag benennt einen Berechtigungsempfänger und Rechte; objektspezifische Einträge können die Eigenschaft, das erweiterte Recht oder die erbende Objektklasse einschränken. Wer nur den angezeigten Berechtigungsnamen liest, übersieht diesen Geltungsbereich. Microsofts Aufzählung der AD-Zugriffsrechte definiert diese Felder sowie die Rechte WriteDACL und WriteOwner.

GenericAll ist nicht bloß ein Rohbit, nach dem gesucht werden muss. Die Zugriffsrechtezuordnung in MS-ADTS ordnet generische Rechte beim Speichern eines Sicherheitsdeskriptors spezifischen Rechten zu. Ein Audit, das nur nach 0x10000000 sucht, kann zugeordnete Vollzugriffsrechte übersehen. Interpretieren Sie die resultierenden Rechte zusammen mit ACE-Typ, Eigenschaftsumfang und Vererbung.

Die Eigentümerschaft muss gesondert geprüft werden. Microsoft dokumentiert die Blockierung impliziter Eigentümerrechte auf Computerobjekten mit Bedingungen für das Betriebssystem und BlockOwnerImplicitRights. Gehen Sie nicht davon aus, dass die Übernahme des Eigentums stets einen uneingeschränkten Pfad zum Schreiben der DACL eröffnet. Prüfen Sie die effektiven Rechte anhand der tatsächlichen DC-Konfiguration. Ebenso belegt das Entfernen einer auffälligen Vollzugriffs-ACE kein bereinigtes Ergebnis, wenn ein unerwarteter Eigentümer oder eine andere anwendbare Berechtigung bestehen bleibt.

Warum Computerobjekte eine eigene ACL-Prüfung benötigen

Eine Delegierungsinventur beantwortet, welche Maschinen derzeit delegierte Identitäten akzeptieren. Eine ACL-Prüfung fragt, wer diese Antwort morgen ändern könnte. Ein leeres RBCD-Attribut schließt deshalb einen Befund zu einem Berechtigungsempfänger, der es schreiben kann, nicht ab. Dieselbe Unterscheidung gilt für Schlüsselanmeldeinformationen: Inventarisieren Sie die gespeicherten Werte und die Fähigkeit, weitere hinzuzufügen.

Beginnen Sie mit dem geschäftlichen Kontext statt mit einem pauschalen Administrationsverbot. Ein Bereitstellungsdienst benötigt möglicherweise bestimmte Provisionierungsrechte; daraus folgt kein Bedarf an dauerhaftem Vollzugriff auf jedes Serverobjekt. Lassen Sie den Verantwortlichen den Vorgang, die betroffenen Objekte, den genehmigten Berechtigungsempfänger und ein Ablauf- oder Prüfdatum benennen. Vergleichen Sie diese Anforderung mit der tatsächlichen ACE.

Direkte und geerbte Berechtigungen erfordern unterschiedliche Korrekturen. Stammt eine unerwünschte Berechtigung aus einer übergeordneten OU, bleiben andere Empfänger gefährdet, wenn nur ein Computer geändert wird. Verfolgen Sie die Vererbungsquelle und prüfen Sie vor einer Änderung den Geltungsbereich der Objektklasse. Binden Sie die administrativen Verantwortlichen der OU und ihrer Workloads ein, damit die Ersatzdelegierung die legitime Aufgabe unterstützt.

Die Angriffskette: Drei Pfade ausgehend von Objektkontrolle

1. RBCD-Konfiguration

Ein Angreifer mit effektivem Schreibzugriff auf msDS-AllowedToActOnBehalfOfOtherIdentity kann versuchen, eine kontrollierte Dienstidentität in die Delegierungskonfiguration der Ressource einzufügen. WriteDACL kann eine vorgelagerte Stufe sein, mit der die benötigte Schreibberechtigung erteilt wird. Die Microsoft-Schemareferenz beschreibt dieses Attribut als Zugriffsprüfung für das Handeln im Namen anderer Identitäten bei Diensten, die unter diesem Konto ausgeführt werden.

Microsofts Übersicht zur eingeschränkten Delegierung erläutert die ressourcenseitige Autorisierung und den S4U2Proxy-Austausch von Diensttickets. Die Folge ist Zugriff über geeignete Dienste auf der Zielressource, abhängig von Umgebung und Dienstautorisierung. Dies garantiert nicht automatisch lokale Administrator- oder Domain-Admin-Rechte. Prüfen Sie die Zieldienste und die Berechtigungen der impersonierten Identität, um die Auswirkungen zu bewerten.

2. Shadow Credentials

Ein nicht autorisierter öffentlicher Schlüssel in msDS-KeyCredentialLink kann einen separaten schlüsselbasierten Authentifizierungspfad schaffen, wenn die Umgebung den betreffenden Key-Trust-Ablauf unterstützt und der Angreifer den privaten Schlüssel besitzt. MS-PKCA Key Trust verlangt von AD-gestützten Implementierungen die Bestätigung desselben öffentlichen Schlüssels im Attribut des Kontos.

Unterscheiden Sie umfassenden Attributschreibzugriff von validierten Schreibvorgängen. Letztere unterliegen zusätzlichen Prüfungen über das Attributschema hinaus. Die Spezifikation validierter Schreibvorgänge für Computer verlangt zum Hinzufügen eines Werts SELF, das betreffende Recht für validiertes Schreiben und spezifische Blob-Bedingungen, darunter das Fehlen eines vorhandenen Werts. Diese Bedingungen bedeuten nicht, dass jeder Dritte mit einem validierten Schreibrecht einen Schlüssel installieren kann.

Die Authentifizierung domänengebundener Geräte mit öffentlichen Schlüsseln erläutert auch die legitime Provisionierung von Computerschlüsseln. Ein befülltes Attribut ist eine Grundlage für die Triage, kein Kompromittierungsnachweis. Der Leitfaden zu Shadow Credentials vertieft diese Unterscheidung und erklärt, warum eine ausschließlich kennwortbasierte Bereinigung einen nicht autorisierten Schlüsselpfad bestehen lassen kann.

3. Zurücksetzen des Maschinenkennworts

Vollzugriff kann das erweiterte Recht Reset Password einschließen. Microsofts Schemaeintrag zu Reset Password führt Computer ausdrücklich unter den anwendbaren Klassen auf. Ein nicht autorisiertes Zurücksetzen kann einem Angreifer Kontrolle über die kennwortbasierten Anmeldeinformationen des Kontos geben; die Auswirkungen hängen von dessen Berechtigungen und den verfügbaren Authentifizierungspfaden ab.

Es kann außerdem die Vertrauensbeziehung der Maschine stören. Microsofts Leitfaden zur Fehlerbehebung beim sicheren Kanal beschreibt Kennwortabweichungen zwischen dem Gerät und AD. Behandeln Sie ein unerklärtes Zurücksetzen als Identitätsvorfall und als Verfügbarkeitsproblem. Stimmen Sie die Wiederherstellung mit dem Systemverantwortlichen ab; eine einseitige Kennwortänderung im Verzeichnis ist kein sicheres Diagnoseexperiment.

Ermittlung: Ein Lesebefehl, danach Prüfung effektiver Rechte

Öffnen Sie auf einem administrativen Windows-System mit verfügbarem dsacls eine Eingabeaufforderung oder PowerShell-Sitzung mit erhöhten Rechten und setzen Sie den verifizierten Computer-DN in diesen einzelnen Lesebefehl ein:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /A

Microsofts dsacls-Referenz dokumentiert die ACL-Anzeige und /A für Eigentümer- und Überwachungsinformationen. Verwenden Sie ein Konto, das zum Lesen der DACL, des Eigentümers und der Überwachungsinformationen berechtigt ist; gewöhnlicher READ_CONTROL-Zugriff schließt die SACL aus. Dieses Beispiel wurde nicht in einer AD-Umgebung ausgeführt.

Lösen Sie jeden unerwarteten Berechtigungsempfänger zu einer aktuellen Identität auf. Erfassen Sie geerbte und explizite Berechtigungen, anwendbare Gruppen, den Eigenschaftsumfang und den Eigentümer. Bestätigen Sie die effektiven Berechtigungen mit den Sicherheitswerkzeugen des Verzeichnisses, statt jeden Allow-Eintrag als eigenständigen, unmittelbar nutzbaren Angriff zu behandeln. Untersuchen Sie nicht aufgelöste Identitäten und begründen Sie genehmigte administrative Ausnahmen im Prüfprotokoll.

Priorisieren Sie sensible Server und die OUs, die Kontrolle über sie delegieren, und erweitern Sie die Prüfung anschließend auf alle Computerobjekte. Speichern Sie den Ausgangszustand, damit spätere Änderungen anhand desselben Objekts und Berechtigungsumfangs bewertet werden können.

Erkennung: Event ID 5136 und KQL

Microsofts Referenz zu Event ID 5136 bestätigt die Überwachung von Änderungen an Verzeichnisobjekten. Aktivieren Sie die Erfolgsüberwachung für Audit Directory Service Changes auf DCs und geeignete SACL-Einträge zur Schreibüberwachung auf den überwachten Objekten oder Attributen. Microsoft weist darauf hin, dass Schemaeinstellungen die Überwachung für manche Objekte und Eigenschaften unterdrücken können; validieren Sie daher die tatsächliche Abdeckung. Bewahren Sie die Korrelationsfelder für Akteur, Objekt, Attribut und Vorgang auf. Das Löschen und Hinzufügen eines Werts kann Teil derselben Änderung sein; zählen Sie dies nicht als separate Vorfälle.

Die folgende KQL ist eine nicht ausgeführte Ausgangsabfrage für einen Workspace, der DC-Sicherheitsereignisse in WindowsEvent empfängt. Sie setzt benannte Eigenschaften innerhalb von EventData voraus. Microsofts Tabellenschema für WindowsEvent definiert dieses Feld als dynamisch und erläutert, dass bei Parsingfehlern stattdessen RawEventData befüllt wird. Prüfen Sie repräsentative Datensätze, bevor Sie sich auf diese Zuordnung verlassen.

WindowsEvent
| where TimeGenerated > ago(7d)
| where Channel == "Security" and EventID == 5136
| extend ObjectClass = tostring(EventData.ObjectClass),
         ObjectDN = tostring(EventData.ObjectDN),
         AttributeName = tostring(EventData.AttributeLDAPDisplayName),
         ActorSID = tostring(EventData.SubjectUserSid),
         ActorName = tostring(EventData.SubjectUserName),
         Operation = tostring(EventData.OperationType),
         OperationCorrelation = tostring(EventData.OpCorrelationID)
| where ObjectClass =~ "computer"
| where AttributeName in~ ("msDS-AllowedToActOnBehalfOfOtherIdentity",
                          "msDS-KeyCredentialLink", "nTSecurityDescriptor")
| project TimeGenerated, Computer, ObjectDN, AttributeName,
          ActorSID, ActorName, Operation, OperationCorrelation
| order by TimeGenerated desc

Prüfen Sie gesondert auf 5136-Datensätze mit leerem oder anders aufgebautem EventData; andernfalls werden Parsinglücken unsichtbar. Passen Sie die Abfrage an, wenn der Connector SecurityEvent oder eine andere Tabelle verwendet. Validieren Sie SACL-Abdeckung und Sichtbarkeit von Sicherheitsdeskriptoränderungen mit einer kontrollierten administrativen Änderung, bevor Sie Aussagen zur Abdeckung treffen. Die Abfrage findet mögliche Änderungen, keinen Missbrauchsnachweis.

Ergänzen Sie für den Kennwortzurücksetzungspfad die Prüfung von Verzeichnisänderungen um Event ID 4742 unter Audit Computer Account Management. Das Feld Password Last Set kann ein manuelles Zurücksetzen oder eine normale Maschinenkennwortrotation widerspiegeln. Microsoft dokumentiert außerdem, dass DACL-Änderungen leere Felder für geänderte Attribute erzeugen können. Eine leere Feldliste belegt deshalb nicht, dass keine relevante Änderung erfolgte.

Gleichen Sie die Triage mit genehmigten Änderungen an Bereitstellung, Registrierung und Delegierung ab. Bewahren Sie die vorherige Konfiguration auf, sofern verfügbar, identifizieren Sie das initiierende Konto und prüfen Sie die nachfolgenden Aktivitäten der betroffenen Maschine. Erhöhen Sie die Priorität, wenn ein nicht genehmigter Akteur einen sensiblen Server ändert, der Eigentümer unerwartet wechselt oder eine Berechtigungsänderung einer Delegierungs- oder Schlüsselergänzung vorausgeht. Fehlende Auditdaten erfordern eine Untersuchung der Datenerfassung; sie belegen keine Abwesenheit einer Ausnutzung.

Behebung (Remediation): Berechtigungspfad entfernen und Identität wiederherstellen

Schritt 1: Beweise sichern und Delegierung einschränken

Erfassen Sie DACL, Eigentümer, Vererbungsquelle und relevante Attributwerte vor einer Änderung. Entfernen Sie nicht autorisierte Berechtigungen für Vollzugriff, DACL-Schreiben und Eigentumsübernahme. Ersetzen Sie notwendigen Provisionierungszugriff durch Rechte, die auf den dokumentierten Vorgang und die Objektklasse begrenzt sind. Korrigieren Sie eine geerbte Berechtigung an ihrer Quelle und prüfen Sie weitere betroffene Computer.

Wenn bestätigt ist, dass ein bestimmter Berechtigungsempfänger keine verbleibenden ACEs auf diesem Objekt benötigt, bietet dsacls /R einen dokumentierten Entfernungsvorgang:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /R "EXAMPLE\RetiredProvisioning"

/R entfernt alle ACEs für diesen Berechtigungsempfänger; es ist keine selektive Vollzugriffsbereinigung. Behält ein Berechtigungsempfänger legitime Rechte, bearbeiten Sie stattdessen die konkrete problematische ACE. Bestätigen Sie anschließend den resultierenden Eigentümer und die effektiven Rechte. Dieses dokumentationsbasierte Beispiel wurde nicht ausgeführt.

Schritt 2: Nicht autorisierte Delegierung und Schlüssel entfernen

Gleichen Sie RBCD-Delegaten mit der genehmigten Liste des Ressourcenverantwortlichen ab. Set-ADComputer stellt PrincipalsAllowedToDelegateToAccount bereit; verwenden Sie die verifizierte Sollmenge und bewahren Sie legitime Anwendungsabhängigkeiten. Das Entfernen eines nicht autorisierten Delegaten ohne Korrektur der Schreibberechtigung lässt die Konfiguration für eine erneute Erstellung offen.

Für einen bestätigten nicht autorisierten Schlüssel unterstützt dasselbe Cmdlet das Entfernen eines exakten LDAP-Attributwerts:

Set-ADComputer -Identity "APP01" -Remove @{ 'msDS-KeyCredentialLink' = $ConfirmedUnauthorizedValue }

$ConfirmedUnauthorizedValue muss den exakt gesicherten und geprüften Wert enthalten. Dies ist ein dokumentationsbasiertes Syntaxbeispiel, keine ausgeführte Wiederherstellung. Bewahren Sie genehmigte Geräteschlüssel, dokumentieren Sie die Validierung jedes verbleibenden Werts und testen Sie die legitime Authentifizierung nach der Bereinigung.

Schritt 3: Vertrauen wiederherstellen und Abschluss verifizieren

Wurden Maschinenanmeldeinformationen kompromittiert, stimmen Sie deren Wiederherstellung mit dem Geräteverantwortlichen ab und untersuchen Sie nachgelagerte Zugriffe. Auf einem Domänenmitglied stellt Microsofts Cmdlet für den sicheren Kanal diesen Prüfbefehl bereit:

Test-ComputerSecureChannel -Verbose

Führen Sie ihn lokal auf dem betroffenen Domänenmitglied in einer über „Als Administrator ausführen“ geöffneten PowerShell aus. Dieser dokumentationsbasierte Prüfbefehl wurde nicht ausgeführt. Microsoft warnt, dass er auf Domänencontrollern falsch positive Fehler erzeugt; folgen Sie dort DC-spezifischen Verfahren. Ein funktionierender sicherer Kanal bestätigt diese Beziehung, nicht die Entfernung jedes vom Angreifer kontrollierten Verzeichniswerts.

Schließen Sie den Befund erst ab, nachdem Sie die resultierenden Berechtigungen und den Eigentümer geprüft, Delegierung und Schlüssel abgeglichen, den vorgesehenen Dienstbetrieb kontrolliert und bestätigt haben, dass die Überwachung die erwarteten Änderungen empfängt. Weisen Sie jeder beibehaltenen Ausnahme einen Verantwortlichen und ein Prüfdatum zu.

Wie EtcSec dies erkennt

Die Implementierung von etc-collector bietet zwei Katalogansichten dieser Berechtigungsprüfung für Computerobjekte:

• COMPUTER_ACL_GENERICALL untersucht gewährende ACEs auf Computerobjekten auf rohes GenericAll oder zugeordneten AD-Vollzugriff und schließt integrierte administrative Berechtigungsempfänger aus. Wenn Inventardaten verfügbar sind, verknüpft sie Computer-DNs; fehlen diese, verwendet sie eine weniger präzise Heuristik für den Speicherort.
• COMPUTER_ACL_ABUSE meldet Computer mit dem Flag DangerousACL. Die Audit-Engine leitet dieses Flag aus gewährten GenericAll-, WriteDACL- oder WriteOwner-Berechtigungen auf Computerobjekten ab und schließt SELF sowie erwartete privilegierte Berechtigungsempfänger aus.

Behandeln Sie diese als eine überlappende redaktionelle Kontrolle: eine spezifische Vollzugriffsansicht und eine aggregierte Ansicht gefährlicher Rechte. Ihre Filter für Berechtigungsempfänger unterscheiden sich; versprechen Sie deshalb keine identischen Befundmengen und addieren Sie ihre Zahlen nicht zu einer Gesamtsumme unabhängiger Gefährdungen. Beide melden Konfigurationsrisiken; keine belegt eine erfolgreiche Ausnutzung von RBCD, eines unzulässigen Schlüssels oder einer Kennwortzurücksetzung. Nutzen Sie die betroffenen Objekte als Ausgangspunkt für die DACL-Prüfung und korrelieren Sie sie mit Änderungsbelegen.