NetSessionEnum, Remote SAM Haertung, BloodHound Aufklaerung, Active Directory: Den Angriffsgraphen blenden

Was ist NetSessionEnum, Remote SAM Haertung, BloodHound Aufklaerung, Active Directory Angriffsgraph-Exposition?

NetSessionEnum, Remote SAM Haertung, BloodHound Aufklaerung, Active Directory Angriffsgraphen: Diese vier Themen laufen alle auf dieselben drei Einstellungen hinaus, und keine davon trägt eine CVE-Nummer — genau deshalb härtet sie fast niemand.

Die beiden wertvollsten Edge-Typen von BloodHound, HasSession und AdminTo, entstehen nicht aus einem Exploit. Sie stammen aus zwei gewöhnlichen Windows-RPC-Aufrufen: NetSessionEnum (wer ist hier gerade angemeldet?) und einer SAMR-Abfrage gegen die lokale SAM-Datenbank (wer ist hier lokaler Administrator?). Ob ein niedrig privilegiertes Domänenkonto diese Aufrufe tätigen darf, entscheiden allein zwei Standardeinstellungen, die zu unterschiedlichen Zeitpunkten geändert wurden — und die auch heute noch eine große Lücke offenlassen. NetSessionEnum stand bis Windows 10 1703 und Windows Server 2016 für Authenticated Users offen, und der Remote-SAM-Zugriff war vor Windows 10 1607 und Windows Server 2016 uneingeschränkt; auf aktuellen Builds sind beide auf Mitgliedsservern und Workstations eingeschränkt, aber Remote SAM steht auf jedem Domänencontroller weiterhin für Jeder offen — per dokumentiertem Design. Ein Angreifer mit einem einzigen niedrig privilegierten Fuß in der Tür durchquert die Umgebung und stellt beide Fragen überall dort, wo sie noch beantwortet werden, und SharpHound verwandelt die Antworten in einen Graphen, der direkt zum Domain Admin führt.

Die drei folgenden Einstellungen sind die Hebel, mit denen sich diese beiden Fragen aus dem Graphen entfernen lassen: der SrvsvcSessionInfo-Sicherheitsdeskriptor, der NetSessionEnum absichert, die RestrictRemoteSam-Richtlinie, die die SAM/SAMR-Abfrage absichert, und ob SMBv1 — das Protokoll, dessen Ära beiden Härtungs-Standardwerten vorausgeht — noch irgendwo in der Umgebung installiert ist.

Funktionsweise

Sitzungs- und Lokal-Admin-Enumeration sind zwei von mehreren Schwächen der Maschinenidentität, die den Angriffsgraphen von BloodHound speisen — siehe auch die breitere Angriffsfläche von Computerobjekten in Active Directory für die Delegations- und DCSync-Seite desselben Problems.

NetSessionEnum und die HasSession-Edge

NetSessionEnum ist eine veraltete Server-Service-API (\\host\srvsvc über die administrative Freigabe IPC$), die die aktuell mit einem Rechner verbundenen Netzwerksitzungen auflistet — im Grunde "welche Konten sind gerade angemeldet oder haben ein Netzlaufwerk zu mir". SharpHound ruft sie während der Standard-Sammelmethode Session auf, löst die zurückgegebenen IPs/Hostnamen zu Computerobjekten auf und zeichnet eine HasSession-Edge von diesem Computer zu jedem gefundenen Konto. Eine HasSession-Edge ist ein Versprechen auf Gelegenheit, keine Garantie: Kann der Angreifer diesen Computer mit Admin-Rechten (oder auf einem anderen Weg) erreichen, könnten die Anmeldedaten oder das Token eines echten, aktuell verbundenen Benutzers zum Diebstahl im Speicher liegen.

Wer NetSessionEnum aufrufen darf, wird über einen Sicherheitsdeskriptor gesteuert, der im Registrierungswert SrvsvcSessionInfo unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity gespeichert ist. Compass Security hat diese spezifische ACL Build für Build getestet und die Matrix veröffentlicht: Windows 10 1607 (14393) und 1703 (15063) sowie Windows Server 2016 (14393) gewähren Authenticated Users das Recht, sie aufzurufen, während Windows 10 1709 (16299) und neuer, Windows Server 2019 (17763) und Windows Server 2022 (20348) dies nicht tun. Auf diesen neueren Builds gewährt der Deskriptor Administratoren, Server-Operatoren und Hauptbenutzern remote sowie den interaktiven, Dienst- und Batch-Anmeldesitzungen lokal Zugriff — was fast genau der ACL entspricht, die das NetCease-Härtungsskript anwenden sollte. Compass merkt zudem an, dass kumulative Updates das Verhalten innerhalb eines Releases nicht verändert haben und dass es keine klare öffentliche Microsoft-Dokumentation dieser Änderung gibt — der einzige Weg, das Verhalten eines gegebenen Hosts zu kennen, ist also, den Wert zu lesen, nicht ihn aus der OS-Version in der Asset-Liste abzuleiten.

Remote-SAM-Zugriff und die AdminTo-Edge

Die Sammelmethode LocalAdmin von SharpHound (auch von den Methoden RDP, DCOM und PSRemote verwendet) enumeriert die lokalen Gruppen eines Computers über die SAMR-Named-Pipe (\\host\samr, ebenfalls über IPC$), um herauszufinden, wer Mitglied der lokalen Administratoren ist — die Quelle der AdminTo-Edge. Das SAMRPC-Protokoll erlaubt es einem niedrig privilegierten Aufrufer, Benutzer, Gruppen und Gruppenmitgliedschaften aus der lokalen SAM und aus Active Directory zu enumerieren — genau der Aufklärungsschritt, den Angreifer schon lange vor BloodHound nutzten, um herauszufinden, wo ein privilegiertes Konto über dauerhafte lokale Admin-Rechte verfügt.

Dies wird über die Richtlinie Netzwerkzugriff: Clients einschränken, denen Remoteaufrufe an SAM gestattet sind abgesichert (Registrierungswert RestrictRemoteSam, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RestrictRemoteSam, REG_SZ). Microsofts eigene Dokumentation macht die Standardeinstellung hier explizit, und dieser Standard ist absichtlich uneinheitlich:

Diese mittlere Zeile ist die entscheidende Nuance: Die Geschichte "seit 2016 standardmäßig sicher" gilt nur für Mitgliedsserver und Workstations. Domänencontroller — die Maschinen, deren Lokal-Admin-Daten ein Angreifer am meisten will — liefern SAMR-Lesezugriffe standardmäßig für Jeder offen aus, auf jeder unterstützten Windows-Server-Version, aus Kompatibilitätsgründen, die Microsoft explizit nennt und nicht als Versehen behandelt.

Wo SMBv1 ins Bild passt

SMBv1 ist nicht das Transportprotokoll, über das NetSessionEnum- oder SAMR-Aufrufe laufen — diese RPCs laufen unabhängig vom SMB-Dialekt über Named Pipes auf IPC$. Was SMBv1 verrät, ist Geschichte. Microsoft installiert SMBv1 seit Windows 10 und Windows Server, Version 1709, nicht mehr standardmäßig, und Windows Server 2019 und neuer werden nach einer Neuinstallation ohne SMBv1 ausgeliefert. Ein Host, der weiterhin auf SMBv1 antwortet, fällt daher in eine von drei Kategorien, und die dritte ist diejenige, die die meisten Umgebungen vergessen: Er stammt aus der Zeit vor der Umstellung, jemand hat es absichtlich neu installiert, oder er wurde per In-Place-Upgrade aktualisiert. Microsoft stellt ausdrücklich klar, dass In-Place-Upgrades SMBv1 nicht automatisch entfernen und dass bei Windows 10 Enterprise, Education und Pro for Workstations "ein Administrator entscheiden muss, SMBv1 in diesen verwalteten Umgebungen zu deinstallieren" — dort gilt keine automatische Entfernung nach 15 Tagen. SMBv1 beweist also nicht, dass der Host alt ist; es beweist, dass der Host nie neu baseliniert wurde. Das ist derselbe Zustand, unter dem ein SrvsvcSessionInfo-Deskriptor aus der Zeit vor 1709 überlebt — weshalb SMBv1 eine nützliche Inventar-Abkürzung ist ("lies die Sitzungs- und SAM-ACLs dieses Hosts von Hand nach") und kein eigenständiges Angriffsprimitiv.

Diese Sitzungs- und Lokal-Admin-Aufklärungsfläche steht neben anderen Recon-Pfaden, die bereits in diesem Blog behandelt wurden: deaktivierte SMB-Signierung, die NTLM-Relay ermöglicht, NTLM-Relay-Angriffsketten gegen Active Directory allgemeiner und anonymer LDAP-Zugriff über einen permissiven dsHeuristics-Wert, der die Enumeration auf Verzeichnisseite behandelt. Dieser Artikel wiederholt nichts davon — er befasst sich speziell mit der Sitzungs- und Lokal-Admin-Enumerationsfläche, die HasSession und AdminTo speist.

Die Angriffskette

Schritt 1 — Ein beliebiger Domänen-Fuß in der Tür

Der Angreifer braucht nicht mehr als ein einziges gültiges Domänen-Credential (oder ein unbeaufsichtigtes Sitzungstoken) — keinen Exploit und keine lokalen Admin-Rechte auf den Domänencontrollern, die er gleich enumerieren wird.

Schritt 2 — Standard-SharpHound-Sammlung

# -c All führt jede Sammelmethode aus, einschließlich Session und LocalAdmin
.\SharpHound.exe -c All -d corp.local

Für jeden aktiven Host ruft SharpHound NetSessionEnum über \\host\srvsvc für Sitzungen und eine SAMR-Lokalgruppenabfrage über \\host\samr für lokale Admins auf. Die beiden Aufrufe schlagen nicht gemeinsam fehl oder gelingen gemeinsam. Die SAMR-Abfrage gelingt gegen jeden Domänencontroller, unabhängig von der Windows-Version, wegen des oben genannten leeren Standardwerts; der Sitzungsaufruf gelingt auf jedem Host, dessen SrvsvcSessionInfo-Deskriptor noch der aus der Zeit vor 1709 ist oder danach gelockert wurde. Ein einziges niedrig privilegiertes Konto reicht für beides.

Schritt 3 — BloodHound baut den Pfad

BloodHound Community Edition korreliert die zurückgegebenen HasSession- und AdminTo-Edges mit vorhandenen Gruppenmitgliedschaften, um einen kürzesten Pfad zu berechnen, etwa: kompromittiertes niedrig privilegiertes Konto → hat eine Sitzung auf Host-X → ein Domain-Admin-Konto ist ebenfalls auf Host-X angemeldet → Angreifer übernimmt Host-X → dumpt LSASS oder stiehlt das Token des Domain Admin.

Schritt 4 — Credential-Diebstahl auf dem Zielhost

Hat der Angreifer auch lokale Admin-Rechte auf dem sitzungstragenden Host (oder kann sie erlangen) — häufig der Fall, da die AdminTo-Enumeration aus demselben niedrig privilegierten Sweep bereits verrät, welche Hosts eine permissive lokale Admin-Mitgliedschaft haben —, wird die Sitzung zu einer Credential-Diebstahl-Gelegenheit über LSASS-Zugriff oder Token-Impersonation.

Erkennung

Weder NetSessionEnum noch ein SAMR-Lesevorgang erzeugen standardmäßig ein dediziertes "jemand hat mich enumeriert"-Windows-Ereignis, und beide sind auf dieselbe erweiterte Überwachungsrichtlinienkonfiguration angewiesen, die die meisten Domänen in ihrem unvollständigen Auslieferungszustand belassen. Die folgenden Ereignisse bieten die beste verfügbare Abdeckung:

Baue keine volumenbasierte Erkennung allein auf 16965 auf. Microsoft drosselt es: Standardmäßig wird das Ereignis nur beim ersten verweigerten Zugriff nach einem Neustart geschrieben, und jede spätere Verweigerung innerhalb eines 15-Minuten-Fensters wird lediglich gezählt und gebündelt über Ereignis 16969 gemeldet ("N Remoteaufrufe an die SAM-Datenbank wurden im vergangenen X-Sekunden-Drosselungsfenster verweigert"). Das Fenster wird über RestrictRemoteSamEventThrottlingWindow (REG_DWORD, Sekunden, unter HKLM\System\CurrentControlSet\Control\Lsa) festgelegt; setze ihn auf 0, um die Drosselung zu deaktivieren und jede Verweigerung zu protokollieren. Der Nur-Audit-Modus wird nicht gedrosselt, was ein weiterer Grund ist, ihn zuerst laufen zu lassen.

Eine praktische Jagd: Filtere Ereignis-ID 5145 nach Share Name = \\*\IPC$ und Relative Target Name in srvsvc, samr, lsarpc, und markiere dann jedes Nicht-Domänencontroller-Quellkonto, das in einem kurzen Zeitfenster mehr als eine Handvoll unterschiedlicher Zielhosts berührt — ein einzelnes Workstation-Konto, das innerhalb von Minuten srvsvc/samr gegen Dutzende Hosts aufruft, ist Standardverhalten der SharpHound-Sammlung, keine normale Benutzeraktivität. Ereignis 5145 stammt aus der Unterkategorie Detaillierte Dateifreigabe überwachen, die standardmäßig deaktiviert und volumenintensiv ist — grenze sie also bewusst ein.

Remediation

1. Inventarisiere, bevor du einschränkst. Aktiviere RestrictRemoteSamAuditOnlyMode (REG_DWORD, Wert 1, unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa) und prüfe Ereignis 16968 einige Tage lang, um legitime Remote-SAM-Aufrufer zu identifizieren, bevor du die Richtlinie live konfigurierst.
2. Konfiguriere RestrictRemoteSam auf Domänencontrollern explizit. Der dortige Standardwert ist "Jeder" aus Kompatibilitätsgründen — er wird nicht sicher, nur weil die Maschine den neuesten Windows Server ausführt. Definiere eine SDDL, die nur die Konten und Gruppen zulässt, die tatsächlich Remote-SAM-Lesezugriffe benötigen (SAMRi10, von denselben Microsoft-Forschern wie NetCease, erstellt eine dedizierte Gruppe "Remote SAM Users" und schreibt die SDDL für dich, statt die Zeichenkette von Hand zu bearbeiten). Neustarts sind nicht erforderlich: Microsoft gibt an, dass die Einstellung wirksam wird, sobald sie lokal gespeichert oder per Gruppenrichtlinie angewendet wird.
3. Härte NetSessionEnum mit einer SrvsvcSessionInfo-ACL-Änderung — auf den Builds, die sie noch brauchen. Das NetCease-Skript entfernt Authenticated Users aus dem SrvsvcSessionInfo-Sicherheitsdeskriptor und fügt die SIDs für interaktive, Dienst- und Batch-Anmeldungen hinzu, während Administratoren, Hauptbenutzer und Server-Operatoren erhalten bleiben. Die eigene Dokumentation macht explizit, dass du "den Dienst 'Server' neu starten musst, damit die Änderungen wirksam werden" (Restart-Service -Name LanmanServer -Force). Beachte, was das für eine moderne Umgebung bedeutet: Windows 10 1709+ und Windows Server 2019+ liefern diese ACL bereits standardmäßig aus, NetCease ist dort also nahezu ein No-Op — sein Wert liegt bei Hosts vor 1709 und Server 2016 sowie bei jedem Host, dessen Deskriptor nachträglich gelockert wurde. Teste zuerst in einer Audit-/Staging-Gruppe — dieselben Admin-Tools, die unter RestrictRemoteSam brechen können, können auch hier brechen.
4. Gehe nicht davon aus, dass die OS-Version den aktuellen Zustand verrät. Frage SrvsvcSessionInfo und RestrictRemoteSam direkt ab, statt "wir sind auf Server 2019/2022, also sind wir sicher" zu vertrauen:

   Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RestrictRemoteSam -ErrorAction SilentlyContinue
   

5. Bestätige, dass SMBv1 tatsächlich weg ist, statt es nur anzunehmen.

   # Erfordert erhöhte Rechte; das Deaktivieren löst einen Neustart aus, sofern nicht -NoRestart verwendet wird
   Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
   # Wenn State auf Enabled steht:
   Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
   
   # Microsofts nicht privilegierte Alternative, besser geeignet, um eine ganze Umgebung zu durchsuchen:
   Get-SmbServerConfiguration | Format-List EnableSMB1Protocol
   

   Behandle jeden Host, der weiterhin auf SMBv1 antwortet, als Anlass, seinen SrvsvcSessionInfo- und RestrictRemoteSam-Zustand manuell zu prüfen — nicht weil SMBv1 beweist, dass der Host alt ist, sondern weil es beweist, dass der Host nie neu baseliniert wurde, derselbe Zustand, der einen veralteten Sitzungs- oder SAM-Deskriptor erhält. Das ergänzt die breitere Liste der Active-Directory-Härtungsprioritäten, die zeigt, wo dies im Vergleich zu anderen Fixes einzuordnen ist.
6. Führe SharpHound nach der Härtung erneut aus und vergleiche die Edge-Anzahl. Ein Rückgang der HasSession- und AdminTo-Edges gegen dieselbe Domäne, mit denselben Sammelmethoden, ist der einzige Beweis, dass die Änderung tatsächlich den Angriffsgraphen verkleinert hat und nicht nur die Compliance-Checkliste.

Wie EtcSec das erkennt

Der Active-Directory-Audit von EtcSec deckt alle drei Einstellungen auf der Ebene ab, auf der sie zentral gesteuert werden: Gruppenrichtlinie. NET_SESSION_HARDENING_MISSING feuert, wenn keine Richtlinie überhaupt eine SrvsvcSessionInfo-Sitzungshärtung konfiguriert — die zu NetCease äquivalente Einstellung fehlt im Richtliniensatz der Domäne schlicht. SAM_REMOTE_ACCESS_OPEN feuert, wenn RestrictRemoteSam entweder nicht gesetzt ist oder eine SDDL ohne DACL trägt — der Zustand, der den Domänencontroller-Standard bestehen lässt. SMB_V1_ENABLED feuert, wenn die Richtlinie SMBv1 aktiviert lässt.

Lies diese drei Befunde für das, was sie sind: Sie sagen dir, ob die Domäne eine Richtlinie hat, die diese Lücken schließt — nicht, ob jeder einzelne Rechner sie einhält. Genau das ist der Kern dieses Artikels. Eine saubere GPO-Baseline lässt dir immer noch die oben beschriebene Arbeit pro Host — SrvsvcSessionInfo und RestrictRemoteSam auf den Hosts selbst zu lesen und SharpHound erneut auszuführen, um die Edge-Anzahl zu vergleichen —, weil ein In-Place-Upgrade, eine lokale Richtlinienänderung oder ein Drittanbieter-Härtungsskript von der Richtlinie abweichen kann, ohne sie zu ändern.