Sensible Begriffe in AD-Beschreibungen: DA und admin prüfen

Sensible Begriffe in AD-Beschreibungen können verraten, welche Identitäten näher betrachtet werden sollten, auch wenn der Text kein Passwort enthält. Dieser Leitfaden trennt eine umfassende manuelle Prüfung von Bezeichnungen wie DA, admin und privileged von den fünf in etc-collector implementierten Mustern und zeigt anschließend, wie einzelne Beschreibungen inventarisiert, bereinigt und erneut geprüft werden.

Was sensible Begriffe in AD-Beschreibungen verraten

Eine Beschreibung wie domain admin — backup operator ist eine Aussage über den Zweck eines Kontos. Die sicherheitsbezogene Schlussfolgerung lautet, dass ein Leser diese Aussage zur Vorauswahl möglicher Ziele nutzen könnte. Sie belegt nicht, dass das Konto tatsächlich administrative Rechte besitzt. Das Beispiel ist fiktiv; es ist weder eine Beobachtung aus einer Produktivumgebung noch ein bestätigter Angriff.

Dieselbe Unterscheidung gilt für DA, Hinweise auf Notfallzugänge und Dienstbezeichnungen. Ein Prüfer könnte sie als Hinweise auf die Rolle einer Identität verstehen, doch die lokale Terminologie ist entscheidend. admin kann sich auf Verwaltungsarbeit außerhalb der IT beziehen. service client kann eine Fachabteilung bezeichnen. Eine alte Beschreibung kann einen Aufgabenwechsel überdauern. Fragen Sie den Verantwortlichen, was der Text bedeutet, bevor Sie ihn als Beleg für aktuelle Privilegien behandeln.

Dieser Artikel behandelt die Identifizierung von Zielen ohne ein Geheimnis. Für konkrete Passwörter, temporäre Werte oder Hinweise auf Zugangsdaten folgen Sie dem Verfahren zur Offenlegung von Passwörtern, Rotation und Untersuchung in AD-Beschreibungen. Das Löschen einer Rollenbezeichnung und die Reaktion auf offengelegte Zugangsdaten sind unterschiedliche Aufgaben; die Entdeckung eines Geheimnisses verändert die erforderliche Reaktion.

Verwenden Sie ein Prüfprotokoll, das den beobachteten Wortlaut, seine Interpretation und die noch benötigten Nachweise unterscheidet. Erfassen Sie beispielsweise „Beschreibung enthält privileged“ getrennt von „Verantwortlicher hat bestätigt, dass dies eine administrative Identität ist“. Lassen Sie einen ungeklärten Fall offen, wenn der Verantwortliche unbekannt ist. Machen Sie aus einem lexikalischen Treffer keine Aussage darüber, dass das Konto kompromittiert ist, MFA umgeht oder zu Domain Admins gehört.

Wie der Lesezugriff auf Beschreibungen funktioniert

Microsofts Leitfaden zu privilegierten Konten und Gruppen erklärt, dass ACLs Authenticated Users üblicherweise Zugriff auf allgemeine Objektinformationen gewähren. Der Abschnitt über Berechtigungen schließt allgemeine Benutzereigenschaften ausdrücklich ein. Dies spricht dafür, die Offenlegung von Beschreibungen mit einer gewöhnlichen authentifizierten Identität zu prüfen, statt anzunehmen, dass nur Administratoren das Feld sehen können. Authentifiziert bedeutet nicht anonym, und eine Leseberechtigung bedeutet keine Änderungsberechtigung.

Die historische Dokumentation zu vertraulichen Attributen beschreibt ebenfalls den standardmäßigen Lesezugriff auf Attribute und die Rolle von READ_PROPERTY. Der tatsächliche Zugriff hängt von den effektiven Berechtigungen des Objekts ab. Eine lokale Berechtigungsänderung kann beeinflussen, was ein Leser erhält. Prüfen Sie daher die konkrete Umgebung, statt für jedes Objekt die Standardeinstellungen vorauszusetzen.

Die Schemareferenz zu description nennt das LDAP-Attribut description mit searchFlags=0x00000000 und systemFlags=0x00000010. Ihre Anmerkungen unterscheiden einwertige Beschreibungen bei SAM-verwalteten Klassen, einschließlich Sicherheitsprinzipalen, von möglicherweise mehreren Werten bei anderen Klassen. Eine erweiterte Objektprüfung sollte diese Werte erhalten, statt jede Beschreibung als eine einzelne Benutzerkonto-Zeichenfolge zu behandeln.

Wählen Sie für einen aussagekräftigen Vergleich der Offenlegung ein bekanntermaßen befülltes Objekt und führen Sie denselben eingegrenzten Lesevorgang mit einem gewöhnlichen Leser und einem autorisierten Prüfer aus. Dokumentieren Sie die verwendete Identität, den Domänencontroller, die Suchbasis, den Zeitpunkt und etwaige Fehler. Dies ist ein empfohlenes Messverfahren, keine Behauptung, dass diese Tests hier durchgeführt wurden. Bewahren Sie die Prüfunterlagen an einem zugriffsgeschützten Ort auf; eine Bereinigung sollte keine neue, breit geteilte Liste sensibler Identitäten erzeugen.

Erkennung

Schritt 1 — Befüllte Benutzerbeschreibungen inventarisieren

Die folgenden Befehle sind aus Microsoft Learn angepasst und verwenden die dokumentierten Parameter von Get-ADUser und Get-ADObject. Sie wurden für diesen Artikel nicht gegen ein Verzeichnis ausgeführt. Ersetzen Sie den Beispiel-DN und den Server, verwenden Sie das Modul ActiveDirectory und wählen Sie den Leser, dessen Zugriff Sie messen möchten. Jeder Block ist eine separate Messung.

Beginnen Sie mit befüllten Benutzerbeschreibungen:

Get-ADUser -LDAPFilter '(description=*)' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Die Angabe -Properties description fordert das Attribut an; sie gewährt keinen Zugriff. Behandeln Sie eine leere Antwort als Untersuchungsanlass. Prüfen Sie den Umfang, die Berechtigungen und ob ein bekanntermaßen befülltes Objekt zurückgegeben wird, bevor Sie das Verzeichnis für frei von sensiblen Beschreibungen erklären.

Schritt 2 — Aktivierte und deaktivierte Konten trennen

Microsofts Beispiel 5 für Get-ADUser verwendet den bitweisen LDAP-Test auf Bit 2 von userAccountControl, um deaktivierte Konten auszuschließen. Das folgende Inventar ergänzt die Bedingung für die Beschreibung und verwendet die geklammerte NOT-Form aus Microsofts Syntax für LDAP-Suchfilter:

Get-ADUser -LDAPFilter '(&(description=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Für die ergänzende Prüfung behalten Sie den Bittest ohne Negation bei:

Get-ADUser -LDAPFilter '(&(description=*)(userAccountControl:1.2.840.113556.1.4.803:=2))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Damit wird der Kontostatus getrennt, nicht die tatsächliche Privilegierung. Behalten Sie deaktivierte Objekte in der Bereinigungswarteschlange und prüfen Sie ihre Beschreibungen vor einer geplanten Reaktivierung. Interpretieren Sie das Deaktivierungsflag nicht als Beweis dafür, dass niemand das Objekt lesen kann oder dass alle früheren Sitzungen ungültig gemacht wurden.

Schritt 3 — Lexikalische Treffer und weitere lokale Bezeichnungen prüfen

Eine Vorauswahl anhand von Teilzeichenfolgen kann den ersten Durchgang überschaubar machen:

Get-ADUser -LDAPFilter '(|(description=*admin*)(description=*privileged*))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Diese LDAP-Vorauswahl ist nicht gleichwertig mit den Regexen des Collectors. Prüfen Sie das ursprüngliche Inventar befüllter Beschreibungen auf DA, break-glass, service, lokale Abkürzungen und Begriffe in anderen Sprachen. Andernfalls kann eine enge Abfrage genau die Bezeichnungen ausblenden, die die manuelle Prüfung bewerten soll.

Die genauen Muster des Collectors sind in accounts/privileged/domain-admin-description.go:35–41 definiert, relativ zu public/internal/audit/detectors/ad/:

(?i)domain\s*admin
(?i)enterprise\s*admin
(?i)administrator
(?i)admin\s*account
(?i)privileged

Alle fünf ignorieren Groß- und Kleinschreibung. Sie haben weder Wortgrenzen noch Anfangs- oder Endanker, und \s* erlaubt auch null Leerraumzeichen. Daher passt domainadmin zum ersten Muster und unprivileged zum letzten. Letzteres kann das Gegenteil dessen beschreiben, was ein Prüfer erwartet; betrachten Sie den vollständigen Wert, statt die passende Teilzeichenfolge als Urteil zu behandeln.

Diese Ergebnisse ergeben sich aus den Quellmustern; sie sind keine gemeldeten Ergebnisse eines Live-Audits. Halten Sie drei Schlussfolgerungen getrennt: passender Wortlaut, vom Verantwortlichen bestätigter Zweck und unabhängig verifizierter Zugriff. Diese Trennung macht einen Fehlalarm erklärbar, ohne vorzutäuschen, dass das umfassendere Inventar vollständig ist.

Schritt 4 — Objekte erweitern und Änderungen überwachen

Wenn Beschreibungen anderer Objektklassen zum Umfang gehören, verwenden Sie ein separates Inventar:

Get-ADObject -LDAPFilter '(description=*)' -Properties description -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Dies umfasst jede zurückgegebene Objektklasse mit einer befüllten Beschreibung. Es ist eine manuelle Erweiterung über die beiden Benutzerdetektoren hinaus, kein Nachweis, dass deren automatische Abdeckung diese Objekte einschließt. Erhalten Sie mehrere Beschreibungswerte, wo das Schema sie erlaubt.

Für die Überwachung einer erneuten Einführung dokumentiert Microsofts Referenz zu Event ID 5136 Verzeichnisänderungen. Konfigurieren Sie Audit Directory Service Changes und eine geeignete Write-SACL für die überwachten Objekte und Attribute. Wählen Sie Ereignisse mit AttributeLDAPDisplayName=description; prüfen Sie den Akteur, das Objekt und den Wert. Wenn sowohl Value Deleted als auch Value Added verfügbar sind, korrelieren Sie sie anhand von OpCorrelationID sowie desselben Objekts und Attributs.

Ein fehlendes 5136-Ereignis beweist nicht, dass niemand den früheren Text gelesen hat. Diese Änderungsereignisse und das Zustandsinventar beantworten unterschiedliche Fragen: Was steht jetzt im Feld, und welche auditierte Änderung fand statt?

Behebung (Remediation)

Schritt 1 — Die Ersatzinformation abstimmen

Für eine Offenlegung allein durch Rollenbezeichnungen empfiehlt sich, sensible Zusammenhänge in ein Inventar oder Betriebshandbuch mit geeigneten Zugriffskontrollen zu verschieben. Lassen Sie den Verantwortlichen freigeben, was in AD verbleiben soll. Eine undurchsichtige Referenz wie Managed record INV-01234 kann einen betrieblichen Verweis erhalten, ohne das Privileg oder das Notfallverfahren zu benennen. Auch das referenzierte System muss den Zugriff kontrollieren; einen Datensatznamen zu verschleiern ist allein keine Autorisierung.

Definieren Sie mit dem Team, das Konten bereitstellt, Beispiele für zulässige und unzulässige Formulierungen. Berücksichtigen Sie lokale Bezeichnungen, die automatisierte Prüfungen übersehen. Prüfen Sie Helpdesk-Vorlagen, Übergabeanweisungen und wer Beschreibungen ändern kann, damit derselbe Hinweis bei der nächsten Wartung nicht wiederhergestellt wird. Entscheiden Sie pro Objekt, statt jede befüllte Beschreibung unterschiedslos zu löschen.

Schritt 2 — Eine Feldänderung voranzeigen und bestätigen

Diese Beispiele passen die dokumentierten Parameter Clear, Description, WhatIf und Confirm von Set-ADUser an. Beispiel 4 löscht ausdrücklich description. Wählen Sie für das ausgewählte Konto entweder das Entfernen oder einen Ersatz.

Entfernung voranzeigen:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -WhatIf

Fordern Sie nach Freigabe durch den Verantwortlichen eine Bestätigung für die tatsächliche Entfernung an:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -Confirm

Alternativ einen neutralen Ersatz voranzeigen:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -WhatIf

Bestätigen Sie diesen Ersatz anschließend separat:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -Confirm

-WhatIf wendet die Änderung nicht an und beweist keine Anwendungskompatibilität. Bewahren Sie die Identität des ausgewählten Objekts und die freigegebene Aktion im Änderungsprotokoll auf und prüfen Sie anschließend den geschriebenen Wert. Diese Befehle sind dokumentierte Beispiele, kein globales Bereinigungsskript und kein Bericht über eine abgeschlossene Bereinigung.

Schritt 3 — Nicht unterstützte Abkürzungen zur Vertraulichkeit vermeiden

Wenn lokale Lesebeschränkungen erwogen werden, beauftragen Sie zunächst eine Prüfung der effektiven Berechtigungen und Abhängigkeiten. Die Microsoft-Seiten zu Berechtigungen und vertraulichen Attributen erklären ACEs, Vererbung und Leseprüfungen; sie bestätigen kein universelles ACL-Rezept für diese Umgebung. Einen dedizierten Leser hinzuzufügen entfernt keine bereits vorhandene weitreichende Freigabe. Entfernen Sie den Lesezugriff von Authenticated Users nicht global, ohne Verbraucher und Delegierung zu prüfen.

Speichern Sie vertrauliche betriebliche Informationen vorzugsweise in einem geschützten Referenzsystem. Eine Schemaerweiterung oder ein neu gestaltetes Berechtigungsmodell erfordert ein eigenes getestetes Projekt. Die Bereinigung von Beschreibungen reduziert einen Hinweis; sie ersetzt weder die Reduzierung von Privilegien noch verbirgt sie alle anderen Verzeichniseigenschaften.

Validierung nach der Bereinigung

Verwenden Sie den dokumentierten Identity-Lesezugriff mit Get-ADObject, um das ausgewählte Objekt nach dem autorisierten Schreibvorgang zu prüfen:

Get-ADObject -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Properties description -Server 'dc01.corp.example'

Das empfohlene Abnahmeprotokoll sollte festhalten, ob der beabsichtigte Wert vorhanden ist, ob der Verantwortliche die geschützte Referenz nutzen kann und ob legitime Werkzeuge weiterhin funktionieren. Prüfen Sie das Inventar erneut mit demselben Leser und Umfang wie zu Beginn. Berücksichtigen Sie beim Vergleich von Verzeichnisservern die Replikation zwischen Domänencontrollern und bewahren Sie die DC-Identität auf, damit abweichende Leseergebnisse untersucht statt verworfen werden können.

Validieren Sie weitere Bezeichnungen ebenso wie Regex-Treffer. Ein sauberes automatisiertes Ergebnis nach dem Ersatz von domain admin durch DA ließe den Hinweis zur Zielauswahl bestehen. Umgekehrt kann eine freigegebene Formulierung mit unprivileged ein lexikalischer Treffer bleiben, dessen Kontext harmlos ist. Dokumentieren Sie diese Entscheidung ausdrücklich; behaupten Sie weder, dass jeder verbleibende Treffer gefährlichen Zugriff bedeutet, noch, dass jedes negative Ergebnis eine sichere Formulierung beweist.

Tatsächliche Rechte benötigen eine separate Prüfung. Die Validierung von Abweichungen beim privilegierten Zugriff untersucht effektive Mitgliedschaften, delegierte ACL-Pfade und Replikationsrechte gegenüber einer Baseline. Nutzen Sie dieses Verfahren, wenn eine Beschreibung auf administrativen Zugriff hinweist. Das Ändern der Beschreibung selbst ist kein Beleg dafür, dass die Rechte des Kontos reduziert wurden.

Prüfen Sie schließlich die Konfiguration der Änderungsüberwachung mit einer freigegebenen Teständerung und kontrollieren Sie, ob die erwarteten 5136-Daten den Prüfprozess erreichen. Besprechen Sie neue sensible Formulierungen mit dem Verantwortlichen. Wird bei der Validierung ein Geheimnis entdeckt, übergeben Sie es an das Verfahren für offengelegte Zugangsdaten, statt den Fall nach der Feldänderung zu schließen. Legen Sie den nächsten Prüfverantwortlichen fest, damit Beschreibungen deaktivierter Identitäten ebenfalls vor einer Reaktivierung geprüft werden.

Wie EtcSec dies erkennt

Die beiden für diesen Artikel geprüften Implementierungen von etc-collector arbeiten auf data.Users und der erfassten Zeichenfolge Description. Beide überspringen leere Beschreibungen und stoppen nach dem ersten erkannten Muster für einen Benutzer. Sie verwenden dieselben fünf Regexe, wählen jedoch entgegengesetzte Populationen nach Kontostatus aus.

Das Prädikat für aktivierte Konten steht in Zeilen 47–61 der ersten Datei; das für deaktivierte Konten in Zeilen 43–57 der zweiten. Ihre Befunde zählen betroffene Benutzer. Detailentitäten werden nur angehängt, wenn IncludeDetails true ist und mindestens ein Benutzer betroffen ist, jeweils in Zeilen 72–74 und 68–70.

Keine der beiden Detect()-Methoden liest memberOf, verifiziert tatsächliche Rechte, sucht nach Passwörtern oder analysiert Verzeichnisereignisse. Der Bezeichner DOMAIN_ADMIN_IN_DESCRIPTION beschreibt daher eine lexikalische Prüfung auf Offenlegung, keinen Beweis, dass ein betroffener Benutzer zu Domain Admins gehört. Die Werte Hoch/Niedrig sind Klassifizierungen nach Collector-Richtlinie, keine gemessenen Angriffsergebnisse oder Microsoft-Schweregrade.

Behandeln Sie diese Befunde als Ausgangspunkt für eine Prüfung: untersuchen Sie den Wortlaut, bestätigen Sie den Zweck mit dem Verantwortlichen, bereinigen Sie das freigegebene Feld und führen Sie die eingegrenzte Prüfung erneut aus. Ein negativer lexikalischer Befund belegt nicht das Fehlen sensibler Bezeichnungen, und das Entfernen einer Bezeichnung belegt nicht den Entzug von Privilegien.