Ausgangslage: alte Lesepfade sind oft zu offen

Anonyme Enumeration ist kein spektakulaerer Angriffspfad. Genau deshalb bleibt sie in vielen Active-Directory-Umgebungen lange liegen. Ein System erlaubt ohne gueltige Benutzeranmeldung noch Rueckschluesse auf lokale SAM-Accounts, Shares, Named Pipes, SID-zu-Name-Uebersetzungen oder LDAP-Basisinformationen. Fuer den Betrieb wirkt das harmlos, weil niemand aktiv Daten veraendert.

Aus Sicht der Verteidigung ist das trotzdem relevant. Benutzer- und Gruppennamen, Serverrollen, Freigabenamen und Namenskonventionen helfen bei Passwort-Spraying, Kerberoasting-Priorisierung, Social Engineering und lateraler Orientierung. Der einzelne Informationsabfluss ist klein. Zusammen entsteht daraus ein brauchbares Inventar, bevor ueberhaupt ein normaler Account kompromittiert wurde.

Moderne Windows-Baselines sind deutlich restriktiver als alte NT- und fruehe Windows-Server-Welten. Problematisch sind aber gewachsene Domaenen, Alt-GPOs, Appliances, NAS-Systeme, nicht standardisierte Serverrollen und historische Ausnahmen fuer "jeder darf lesen". Besonders kritisch sind Domain Controller, Datei- und Applikationsserver sowie Management-Systeme, die noch Gast- oder Null-Session-Verhalten dulden.

Das Ziel ist nicht, jedes unauthentifizierte Paket zu verhindern. Einige Protokolle liefern technisch noetige Minimalinformationen, etwa LDAP RootDSE. Das Ziel ist, anonyme Zugriffe auf verwertbare Identitaets-, Freigabe- und Verwaltungsinformationen konsequent zu begrenzen.

Zielbild: ohne Anmeldung gibt es kein brauchbares Inventar

Ein belastbares Zielbild ist konkret:

  1. Anonyme SAM- und Share-Auflistung ist blockiert. Weder lokale Konten noch Freigaben lassen sich ohne Authentifizierung sinnvoll inventarisieren.
  2. SID-zu-Name-Uebersetzung ist nicht anonym erlaubt. Alte Kompatibilitaet wird nicht als Standard akzeptiert.
  3. Null Sessions haben keine operativen Freigaben. NullSessionShares und NullSessionPipes sind leer oder streng begruendet.
  4. Everyone bedeutet nicht Anonymous. Anonyme Benutzer erben keine Everyone-Berechtigungen.
  5. Remote-SAM-Abfragen sind eingeschraenkt. Nur definierte Admin- oder Management-Gruppen duerfen lokale SAM-Daten remote lesen.
  6. Gastpfade sind separat kontrolliert. Insecure Guest Logons und anonyme SMB-Nutzung werden nicht als Ersatz fuer saubere Authentifizierung genutzt.
  7. Ausnahmen sind befristet. Jede Legacy-Ausnahme hat Owner, Grund, betroffene Systeme und Ablaufdatum.

Der praktische Zielzustand: Ein nicht authentifizierter Client kann erkennen, dass ein Dienst existiert, bekommt aber keine verwertbare Liste von Benutzern, Gruppen, Shares, Named Pipes oder Rollen.

Umsetzung: Baseline, Pilot, Ausnahmen

1) Aktuellen Zustand ohne Domain-Credentials pruefen

Starte mit einem Testsystem, das keine Domain-Credentials im Cache hat und nicht als privilegierter Admin angemeldet ist. Sonst misst du versehentlich normale Authentifizierung statt anonymes Verhalten.

Minimaler Defensivtest fuer SMB-Null-Session-Verhalten:

$targets = @(
  'dc01.corp.example',
  'filesrv01.corp.example',
  'mgmt01.corp.example'
)

foreach ($target in $targets) {
  cmd.exe /c "net use \\$target\IPC$ """" /user:"""""
  cmd.exe /c "net view \\$target /all"
  cmd.exe /c "net use \\$target\IPC$ /delete"
}

Das Ziel ist kein Tool-Vergleich und keine offensive Enumeration. Du willst schlicht sehen, ob ein anonymer IPC-Zugriff oder eine Share-Auflistung ueberhaupt noch funktioniert. Auf gehaerteten Systemen erwartest du Zugriff verweigert oder eine leere, nicht verwertbare Sicht.

Ergaenze den Test um Log-Sicht: Security-Events mit ANONYMOUS LOGON oder SID S-1-5-7, SMB-Server-Events, Firewall-Logs und Hinweise aus EDR oder SIEM. Wenn anonyme Zugriffe noch erfolgreich sind, brauchst du das Zielsystem, den Zugriffspfad und den Prozesskontext.

2) Security-Options per GPO explizit setzen

Lege eine eigene Computer-GPO fuer die Baseline an, statt alte Einstellungen in einer ueberladenen Default-Domain-Policy zu verstecken. Die relevanten Einstellungen liegen unter:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Setze mindestens diese Kontrollen bewusst:

  • Network access: Do not allow anonymous enumeration of SAM accounts: Enabled.
  • Network access: Do not allow anonymous enumeration of SAM accounts and shares: Enabled.
  • Network access: Let Everyone permissions apply to anonymous users: Disabled.
  • Network access: Restrict anonymous access to Named Pipes and Shares: Enabled.
  • Network access: Allow anonymous SID/Name translation: Disabled.
  • Network access: Named Pipes that can be accessed anonymously: leer oder streng begruendete Einzelwerte.
  • Network access: Shares that can be accessed anonymously: leer oder streng begruendete Einzelwerte.

Wichtig ist die Nachvollziehbarkeit. Wenn eine Einstellung bereits per Default restriktiv ist, dokumentiere sie trotzdem in der Baseline. So wird ein spaeterer Drift sichtbar und nicht als "war schon immer so" wegdiskutiert.

3) Remote-SAM-Zugriffe separat haerten

Die reine Anonymous-Baseline reicht nicht immer. Viele Tools, Helpdesk-Prozesse und Legacy-Skripte lesen lokale Gruppen und Konten remote ueber SAMR. Das ist nicht automatisch anonym, aber oft zu breit erlaubt.

Pruefe deshalb die Einstellung:

Network access: Restrict clients allowed to make remote calls to SAM

Setze sie nicht blind global auf alle Server. Starte mit Workstations und Standard-Memberservern, dann mit kritischen Serverrollen. Ziel ist eine Allowlist fuer berechtigte Administrations- oder Management-Gruppen, nicht fuer normale Domain Users. Domain Controller, Cluster, Spezialappliances und alte Management-Produkte brauchen vorher einen Pilot.

Typischer Ablauf:

  1. Abfragen und beteiligte Management-Systeme erfassen.
  2. Helpdesk-, Inventory- und EDR-Prozesse identifizieren.
  3. Pilot-OU mit wenigen Workstations oder Memberservern waehlen.
  4. Remote-SAM-Policy setzen und Admin-Prozesse testen.
  5. Ausnahmen dokumentieren oder Tooling korrigieren.
  6. Baseline in Wellen erweitern.

Diese Kontrolle reduziert nicht nur anonyme Informationsabfluesse. Sie begrenzt auch authentifizierte Massenabfragen lokaler Konten und Gruppen.

4) Null-Session-Pipes und -Shares aufraeumen

Historisch wurden einzelne Named Pipes oder Shares fuer anonyme Nutzung freigegeben, damit alte Dienste funktionieren. In modernen AD-Umgebungen sollte das selten noetig sein.

Pruefe auf Servern die effektiven Werte fuer:

  • NullSessionPipes
  • NullSessionShares
  • RestrictNullSessAccess

Arbeite dabei nicht nur mit Registry-Werten, sondern auch mit Rollenwissen. Ein leerer Wert ist gut, aber eine Anwendung kann trotzdem Gast- oder Shared-Account-Logik nutzen. Umgekehrt ist ein alter Eintrag nicht automatisch noch benoetigt.

Sauberer Ablauf:

  • Werte zentral inventarisieren.
  • Serverrolle und Owner zuordnen.
  • Anonyme Nutzung in Logs bestaetigen oder widerlegen.
  • Eintraege in Pilotgruppen entfernen.
  • Anwendungstests mit neuen Sessions ausfuehren.
  • Restwerte als Ausnahme mit Ablaufdatum fuehren.

Wenn niemand den Zweck eines anonym erreichbaren Pipes oder Shares erklaeren kann, ist das ein starkes Cleanup-Signal.

5) LDAP und Domain Controller nicht ausklammern

LDAP auf Domain Controllern liefert auch ohne Bind bestimmte Basisinformationen. Das ist normal und fuer Clients teilweise noetig. Kritisch wird es, wenn alte Kompatibilitaetseinstellungen anonyme LDAP-Abfragen ueber das normale Mindestmass hinaus erlauben.

Pruefe, ob in der Umgebung historische Einstellungen existieren, die anonyme LDAP-Operationen erweitern. Dazu gehoeren alte Migrationsanpassungen, Sonderkonfigurationen in Directory Service Settings und Applikationen, die nie auf authentifizierte Binds umgestellt wurden.

Fuer Domain Controller gilt:

  • Keine anonymen LDAP-Abfragen auf Benutzer-, Gruppen- oder Computerinventar.
  • LDAP Signing und Channel Binding als eigenes Hardening-Thema planen.
  • Alte Applikations-Binds identifizieren und auf dedizierte, niedrig privilegierte Servicekonten umstellen.
  • Anonymous-Logons und LDAP-Bind-Fehler im Monitoring sichtbar machen.

Behandle Domain Controller strenger als normale Server. Wenn DCs anonym verwertbare Identitaetsdaten ausliefern, entsteht sofort ein domaenenweiter Informationsvorteil.

6) Gastzugriffe und "Everyone" sauber trennen

Anonymous Enumeration wird oft mit Gastzugriffen vermischt. Technisch sind das unterschiedliche Pfade, operativ fuehren beide zu demselben Problem: Ressourcen sind ohne nachvollziehbare Identitaet lesbar.

Pruefe daher parallel:

  • Insecure Guest Logons fuer SMB.
  • Lokale Guest-Konten und deren Status.
  • Share- und NTFS-Berechtigungen mit Everyone, Guest, ANONYMOUS LOGON oder breit gesetzten lokalen Gruppen.
  • Appliances oder NAS-Systeme, die Windows-Berechtigungen nur teilweise abbilden.
  • Alte Scan-, Druck- oder Drop-Zonen, die "einfach anonym" funktionieren sollen.

Der Zielzustand ist nicht "kein Everyone mehr irgendwo". Der Zielzustand ist: Everyone umfasst nicht Anonymous, Gastzugriffe sind bewusst deaktiviert oder streng isoliert, und produktive Freigaben verlangen nachvollziehbare Identitaeten.

7) Rollout in sinnvollen Wellen

Ein praktikabler Rollout sieht so aus:

  1. Domain Controller und Tier-0-Server read-only pruefen.
  2. Workstations und Standard-Memberserver inventarisieren.
  3. Security-Options-GPO in einer Pilot-OU setzen.
  4. Remote-SAM-Restriktion getrennt pilotieren.
  5. Null-Session-Pipes und -Shares pro Serverrolle bereinigen.
  6. Fileserver, Applikationsserver und Management-Systeme in Wellen aufnehmen.
  7. Exceptions mit Owner und Ablaufdatum dokumentieren.
  8. Monitoring auf ANONYMOUS LOGON, Gastpfade und Policy-Drift einrichten.

Die wichtigste Regel: Nicht alles an einem Freitagabend global setzen. Die Einstellungen sind grundsaetzlich sinnvoll, aber Altanwendungen und Management-Produkte koennen unerwartet auf alte Lesepfade angewiesen sein.

Vorteile

  • Weniger verwertbares Vorwissen: Benutzer-, Gruppen-, Share- und Rolleninformationen sind ohne Anmeldung deutlich schwerer zu gewinnen.
  • Bessere Grundlage gegen Spraying und Roasting: Namenslisten und Service-Hinweise fallen nicht mehr nebenbei aus anonymen Abfragen heraus.
  • Klarere Serverbaselines: DCs, Memberserver, Workstations und Management-Systeme bekommen nachvollziehbare Security-Options.
  • Weniger Legacy-Schulden: Null Sessions, Gastpfade und alte Everyone-Annahmen werden sichtbar.
  • Geringe technische Komplexitaet: Viele Kontrollen sind Bordmittel und lassen sich per GPO ausrollen.
  • Gute Auditierbarkeit: Erfolgreiche anonyme Zugriffe lassen sich ueber Events, Firewall und SIEM gezielt ueberwachen.

Nachteile und Grenzen

  • Legacy kann brechen: Alte Anwendungen, Inventory-Tools, NAS-Systeme oder Druckprozesse nutzen manchmal unauthentifizierte Lesepfade.
  • Nicht jede Basisinformation verschwindet: Protokolle wie LDAP liefern bestimmte RootDSE- oder Dienstinformationen weiterhin.
  • Keine alleinige AD-Haertung: Die Massnahme ersetzt keine Passwort-, Kerberos-, SMB-, LDAP- oder Tiering-Baseline.
  • Remote-SAM-Restriktionen brauchen Tests: Helpdesk- und EDR-Funktionen koennen legitime lokale Gruppenabfragen benoetigen.
  • Gastzugriffe sind ein eigenes Thema: Anonymous-Hardening wirkt nur vollstaendig, wenn Guest Logons und Share-Berechtigungen ebenfalls bereinigt werden.
  • Appliances verhalten sich uneinheitlich: NAS, Scanner, alte Linux/Samba-Systeme und Spezialsoftware folgen nicht immer Windows-GPO-Logik.

Typische Stolperfallen

  • Mit Admin-Credentials testen: Dann misst du nicht Anonymous, sondern deine aktuelle Anmeldung.
  • Nur Domain Controller betrachten: Memberserver und Workstations liefern oft lokale Konten, Gruppen oder Shares.
  • Remote-SAM global blocken: Ohne Pilot koennen Helpdesk, EDR oder Inventory-Prozesse ausfallen.
  • Everyone falsch verstehen: Wenn Anonymous in Everyone einbezogen wird, wirken breite Berechtigungen anders als erwartet.
  • NullSession-Werte uebersehen: Alte Registry-Eintraege ueberleben Servermigrationen und Basisimages.
  • LDAP pauschal bewerten: RootDSE-Sicht ist nicht dasselbe wie anonyme Objektauflistung.
  • Ausnahmen nicht befristen: Einmal eingerichtete Legacy-Ausnahmen bleiben sonst dauerhaft bestehen.
  • Monitoring vergessen: Ohne Event- und Drift-Sicht kommt die alte Fehlkonfiguration spaeter zurueck.

Projekt-Checkliste

  • [ ] Testsystem ohne Domain-Credentials fuer anonyme Pruefungen bereitstellen.
  • [ ] Domain Controller, Fileserver, Management-Systeme, Memberserver und Workstations stichprobenfrei in den Scope nehmen.
  • [ ] Aktuelle Anonymous-, Guest-, Null-Session- und Remote-SAM-Einstellungen inventarisieren.
  • [ ] Security-Options-GPO fuer Anonymous-Enumeration explizit definieren.
  • [ ] EveryoneIncludesAnonymous, SID/Name-Translation, SAM- und Share-Enumeration restriktiv setzen.
  • [ ] NullSessionPipes und NullSessionShares pro Serverrolle pruefen und bereinigen.
  • [ ] Remote-SAM-Restriktion separat mit Helpdesk, EDR und Inventory testen.
  • [ ] Gastzugriffe, SMB-Insecure-Guest-Logons und Share-Berechtigungen parallel bewerten.
  • [ ] DCs auf erweiterte anonyme LDAP-Kompatibilitaet und Anonymous-Logons pruefen.
  • [ ] Pilot-OU, Rollout-Wellen, Rueckfallweg und Change-Fenster festlegen.
  • [ ] Ausnahmen mit Owner, technischem Grund, Ablaufdatum und Review-Zyklus dokumentieren.
  • [ ] Monitoring auf ANONYMOUS LOGON, SID S-1-5-7, Gastpfade und Policy-Drift einrichten.