Schutz vor interner Aufklärung mit NetCease und SAMRi10

Was ist Internal Reconnaissance?

Interne Aufklärung ist einer der ersten Schritte, die ein Angreifer unternimmt, sobald er ein Benutzer- oder Computerkonto in Ihrem Netzwerk kompromittiert hat. Mit verschiedenen Tools oder Skripten enumerieren und sammeln sie Informationen, die ihnen helfen, zu identifizieren, welche Assets sie als Nächstes kompromittieren sollten, um zu bekommen, was sie wollen. Zum Beispiel, BloodHound wird Angriffspfade aufzeigen, die es einem Gegner ermöglichen können, ihre Privilegien von einem gewöhnlichen Benutzer zu einem Admin zu eskalieren.

Fast alle gängigen Aufzählungsmethoden können von einem nicht privilegierten Benutzer ausgeführt werden, was ihre Entdeckung und Blockierung extrem schwierig macht. In diesem Beitrag werde ich erklären, wie man sich gegen zwei Arten der internen Aufklärung verteidigen kann:

• Sitzungsauflistung durch nicht privilegierte Benutzer
• Abfragen an das MS-SAMR-Protokoll

Arten der Aufklärung

Um Informationen über das Netzwerk zu finden, in das sie eingedrungen sind, enumerieren Angreifer oft die folgenden Datentypen:

• Sitzungen — Um herauszufinden, wer wo angemeldet ist
• Benutzer — Um alle Benutzer im Domain zu verstehen, idealerweise mit ihrer Gruppenmitgliedschaft
• Gruppen — Um alle Gruppen in der Domäne zu sehen, idealerweise mit ihrer Mitgliedschaft
• Zugriffskontrolllisten (ACLs) von Active Directory — Um zu verstehen, welche Sicherheitsprinzipien (wie Benutzer und Gruppen) auf welche Ressourcen zugreifen können
• Mitgliedschaft in lokalen Gruppen — Um zu sehen, wer Zugriffsrechte auf die Maschine hat (insbesondere wer administrative Rechte besitzt)

Blockieren der Sitzungsauflistung mit NetCease

Dieser Blogbeitrag konzentriert sich auf die Sitzungsaufzählung, die es einem Angreifer ermöglicht festzustellen, wo Benutzer- und Dienstkonten angemeldet sind. Diese Informationen helfen ihnen zu priorisieren, welche Hosts sie zuerst zu kompromittieren versuchen — wie zum Beispiel Hosts, bei denen ein Administrator angemeldet ist.

Hinweis: Die Standardberechtigungen in Windows 10 wurden geändert, um Angreifern das Durchführen von Sitzungsaufzählungen zu verhindern; dennoch ist es ratsam, dies weiterhin zu überprüfen.

NetCease ist ein kurzes PowerShell-Skript, das hilft, die Sitzungsaufzählung zu verhindern, indem es den Registrierungsschlüssel ändert, der die Berechtigungen für die NetSessionEnum-Methode steuert. (Der Grund, warum dies mit einem Skript und nicht manuell durchgeführt wird, liegt daran, dass der Schlüssel, SrvsvcSessionInfo, nur als reg binärer Wert bearbeitet werden kann.) Hier ist der Pfad zum SrvsvcSessionInfo-Schlüssel:

Pfad: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/DefaultSecurity

Der Standardwert des SrvsvcSessionInfo-Registrierungsschlüssels ist die ACL, die die Verwendung der NetSessionEnum-Methode erlaubt. Dies wird folgendermaßen zugewiesen:

• Mitglied der Administratoren
• Mitglied der Server-Operatoren
• Mitglied der Power Users
• Authentifizierte Benutzer

Die Berechtigung für Authentifizierte Benutzer ermöglicht Angreifern, Sitzungsaufklärung mit jedem kompromittierten Benutzerkonto durchzuführen.

Was das NetCease-Skript macht, ist den aktuellen Registrierungswert zu sichern und dann die Berechtigungen zu ändern, sodass die folgenden ACEs in der ACL sind:

• InteractiveSid
• ServiceSid
• BatchSid
• Administratoren
• Server-Operatoren
• PowerUsers

Überprüfung der ACL

Wenn Sie den Sicherheitsdeskriptor einsehen möchten, können Sie das folgende PowerShell-Snippet verwenden, das Ihnen die ACL anzeigt:

      #Registry Key Information
$key = "HKLM:SYSTEMCurrentControlSetServicesLanmanServerDefaultSecurity"
$name = "SrvsvcSessionInfo"

#Get the Registry Key and Value
$Reg_Key = Get-Item -Path $key
$BtyeValue = $reg_Key.GetValue($name, $null)

#Create a CommonSecurityDescriptor Object using the Byte Value
$Security_Descriptor = New-Object -TypeName System.Security.AccessControl.CommonSecurityDescriptor -ArgumentList $true, $false, $ByteValue, 0

#Output of the ACL to make it simple to see for document. Use only $Security_Descriptor.DiscretionaryAcl if you want to see the full ACL!
$Security_Descriptor.DiscretionaryAcl | Select-Object SecurityIdentifier, ACEType | Format-Table -AutoSize
      

Ausgabe vor der Ausführung von NetCease:

Ausgabe nach der Ausführung von NetCease:

Hinweis: Informationen zu bekannten SIDs finden Sie hier.

Testen der Sitzungsaufzählung

Eine einfache Methode, um zu testen, ob Sie die Sitzungsauflistung durch gewöhnliche Benutzerkonten blockiert haben, ist die Verwendung des NetSess Tools von Joeware.net, aber es gibt viele andere Optionen, einschließlich SharpHound. Stellen Sie beim Durchführen sicher, dass Sie ein Benutzerkonto verwenden, das kein Mitglied der Administratoren, Serveroperatoren oder Power Users ist.

Ausgabe vor der Verwendung von NetCease

      Netsess.exe [Computer]
      

Ausgabe nach der Verwendung von NetCease mit einem nicht privilegierten Konto

      Netsess.exe [Computer]
      

Ausgabe nach der Verwendung von NetCease mit einem Privileged User Account

      Netsess.exe [Computer]
      

Blockieren von Aufklärungsversuchen mittels Remote SAM (SAMR)

Attackers can perform reconnaissance using the SAMR protocol, which can remotely query devices but can also query Active Directory. Using SAMR, an attacker without any administrative privileges can find highly privileged groups and users, as well as local users and groups for every system on the network. Tools such as BloodHound can then automatically map this information into attack paths to compromise Active Directory.

Microsoft führte Schutzmaßnahmen für das Abfragen von SAMR mit Windows 10 ein und ergänzte 2017 Updates für frühere Betriebssysteme bis hinunter zu Windows 7 und Server 2008 R2 mithilfe des RestrictRemoteSAM-Registrierungsschlüssels. Dieser Schlüssel ist eine Zeichenkette (REG_SZ), die die SDDL des Sicherheitsdeskriptors enthalten wird, der Remote-SAM-Aufrufe schützt.

In der Jubiläumsausgabe von Windows 10 (1607) und Windows Server 2016 und später wurde die standardmäßige SDDL geändert, um nur lokalen Administratoren das Abfragen von Remote SAM zu erlauben.

Unten finden Sie eine Tabelle, die die Anforderungen, das Standardverhalten und die Schutzoptionen für alle Betriebssysteme aufschlüsselt:

Es gibt drei Möglichkeiten, den RestrictRemoteSAM-Registrierungsschlüssel zu setzen:

• Registry
• Gruppenrichtlinie
• SAMRi10 (Samaritan)

Lassen Sie uns jeden einzelnen davon überprüfen.

Registry-Option

Der RestrictRemoteSAM-Registrierungsschlüssel steht Administratoren zur Aktualisierung nach Belieben zur Verfügung:

Pfad: HKLM/System/CurrentControlSet/Control/Lsa

Name: RestrictRemoteSAM

Standardwert (SDDL) in Windows 10: O:SYG:SYD:(A;;RC;;;BA)

Komponenten der SDDL

Wie Sie sehen können, ist der Standardwert, den Windows 10 festlegt, SYSTEM für Besitzer und Primärgruppe sowie Leseberechtigung für Eingebaute Administratoren.

Überprüfen des SDDL, bevor es angewendet wird

Um sicherzustellen, dass die SDDL korrekt ist, bevor Sie die Änderung anwenden, können Sie den Befehl ConvertFrom-SDDLString in PowerShell verwenden, um sie in einen Sicherheitsdeskriptor zu konvertieren, der leichter zu lesen ist.

Gruppenrichtlinie oder Lokale Sicherheitsrichtlinie Option

Die Gruppenrichtlinie und die lokalen Security Policy-Einstellungen ermöglichen es Administratoren, diesen Schlüssel einfach zu setzen. Dies kann gut funktionieren für Administratoren, die denselben Wert auf allen Systemen oder mehreren Gruppen von Systemen setzen möchten (z.B. das Zulassen von Remote-SAM-Verbindungen für alle Server in einer bestimmten OU oder einer bestimmten Gruppe von Anwendungsservern).

Die Details zu den Einstellungen sind wie folgt:

SAMRi10 (Samaritan) Option

SAMRi10 ist ein PowerShell-Skript, das einen entscheidenden Vorteil gegenüber den vorherigen Optionen bietet: Es erstellt eine neue lokale Gruppe und delegiert den Zugriff für die Gruppe, um Remote-SAM-Aufrufe durchführen zu können. Dies ermöglicht es Administratoren, diese Funktionalität vollständig in den Gruppenrichtlinieneinstellungen zu steuern oder sie bei Bedarf manuell Konten zu gewähren.

Das SAMRi10-Skript führt Folgendes aus:

1. Erstellt eine lokale Gruppe namens „Remote SAM Users“
2. Passt die SDDL an, um die neu erstellte Gruppe einzuschließen:
   • Wenn es keine Standard-SDDL gibt, dann gewähren Sie Zugriff für die integrierten Administratoren.
   • Wenn eine SDDL existiert, dann ergänzen Sie diese, um den neuen ACE für die Gruppe der Remote SAM Users einzuschließen.

Vorteile der Verwendung von SAMRi10

• Einfache Vergabe granularer Zugriffsrechte für Remote SAM-Zugriff
• Hilft Organisationen, die den Zugriff mit den geringsten Privilegien durchsetzen möchten
• Kann in Verbindung mit einer local group membership Gruppenrichtlinie verwendet werden, um Benutzern zentralen Zugriff mittels elementbasierter Zielzuweisung zu gewähren
• Kann von einem Privileged Access Management (PAM)-System verwendet werden, um dynamischen (Just-in-Time) Zugriff zu gewähren, falls ein Konto oder Prozess diese spezifische Berechtigung benötigt

Abwehr von Aufklärungsversuchen mit Netwrix Solutions

Netwrix StealthAUDIT beinhaltet einen Angriffspfad-Analysator, der Administratoren Einblicke in ihre Active Directory ACLs bietet, damit sie eventuelle Schwachstellen schließen können, bevor Angreifer diese ausnutzen. Netwrix StealthINTERCEPT kann LDAP-Abfragen überwachen und diese dann an Netwrix StealthDEFEND weiterleiten, das mehrere Aufklärungsszenarien und Abfragen direkt erkennen kann, einschließlich BloodHound, Abfragen aller SPNs und Abfragen aller Konten mit password never expires.

FAQ

Was ist interne Aufklärung und warum sollten Sie sich darum kümmern?

Interne Aufklärung tritt auf, wenn Angreifer, die bereits einen ersten Zugang zu Ihrem Netzwerk erlangt haben, beginnen, Ihre Umgebung zu kartieren, um wertvolle Ziele zu finden. Sie brechen nicht mehr ein – sie sind bereits eingeloggt und sehen sich um. Hier versagen die meisten Sicherheitsstrategien, da sie sich auf Perimeter-Verteidigungen konzentrieren, während Angreifer sich mit legitimen Anmeldeinformationen frei im Inneren bewegen.

Die Realität ist eindeutig: Man kann nicht schützen, was man nicht sieht, und man kann nicht kontrollieren, was man nicht versteht. Die interne Aufklärung ist die kritische Phase, in der Angreifer Informationen über Ihre Active Directory-Struktur sammeln, hochwertige Konten identifizieren und Wege zu Ihren sensibelsten Daten kartieren. Data Security beginnt mit Identität, und das bedeutet, Angreifern von vornherein das Aufzählen Ihrer Identitätsinfrastruktur zu verhindern.

Wie implementieren Sie NetCease für den Schutz vor Sitzungsaufzählung?

NetCease blockiert Angriffe durch Sitzungsaufzählung, indem es unbefugten Benutzern verhindert, aktive Sitzungen auf Ihren Domänencontrollern und Servern aufzulisten. Die Implementierung ist unkompliziert, erfordert jedoch Planung. Laden Sie zuerst NetCease aus dem offiziellen Repository herunter und stellen Sie sicher, dass Sie es auf einem System mit PowerShell 5.1 oder höher ausführen.

Voraussetzungen:

• Administrative Privilegien
• PowerShell 5.1 oder höher
• Windows Server oder domänenverbundenes System

Das Tool funktioniert, indem es Registrierungseinstellungen ändert, die steuern, wie der Windows Server-Dienst auf Sitzungsauflistungsanfragen reagiert. Führen Sie NetCease mit administrativen Privilegien auf jedem Server aus, den Sie schützen möchten, beginnend mit nicht-kritischen Systemen zum Testen. Die Änderungen treten sofort in Kraft, ohne dass ein Neustart erforderlich ist, aber Sie sollten überprüfen, ob legitime administrative Tools und Überwachungslösungen weiterhin ordnungsgemäß funktionieren.

Die beste Praxis ist, NetCease schrittweise in Ihrer Umgebung zu implementieren, anstatt es überall auf einmal einzusetzen. Beginnen Sie mit Servern, die keine geschäftskritischen Anwendungen hosten, überwachen Sie auf Störungen und erweitern Sie dann auf Domänencontroller und andere hochwertige Ziele. Denken Sie daran, dass es bei der Verhinderung von Aufklärungsversuchen nicht darum geht, Ihr Netzwerk unsichtbar zu machen – es geht darum, Angreifern die Arbeit zu erschweren und Ihren Erkennungssystemen mehr Zeit zu geben, um bösartige Aktivitäten zu identifizieren.

Was ist der Unterschied zwischen SAMRi10 und Group Policy SAM-Beschränkungen?

SAMRi10 und Group Policy beschränken beide den Zugriff auf die Security Account Manager (SAM)-Datenbank, arbeiten jedoch auf unterschiedlichen Ebenen und dienen verschiedenen Anwendungsfällen. SAMRi10 ist ein PowerShell-Skript, das direkt Registrierungseinstellungen auf einzelnen Maschinen ändert und Ihnen eine granulare Kontrolle über die SAM-Zugriffsbeschränkungen auf spezifischen Systemen ermöglicht.

Gruppenrichtlinien-SAM-Beschränkungen funktionieren auf Domänenebene und ermöglichen es Ihnen, konsistente Richtlinien gleichzeitig auf mehrere Systeme anzuwenden. Der Gruppenrichtlinienansatz ist besser für großangelegte Bereitstellungen geeignet, bei denen Sie einen einheitlichen Schutz über viele Maschinen hinweg benötigen. SAMRi10 ist ideal für spezifische Server, Testumgebungen oder Situationen, in denen Sie benutzerdefinierte Konfigurationen benötigen, die nicht in die standardmäßigen Gruppenrichtlinienvorlagen passen.

Die technische Umsetzung unterscheidet sich ebenfalls. SAMRi10 modifiziert den RestrictRemoteSAM-Registrierungsschlüssel direkt, während die Gruppenrichtlinie das administrative Vorlagensystem verwendet, um dasselbe Ergebnis zu erzielen. Beide Methoden sind wirksam, aber SAMRi10 bietet mehr Flexibilität für die Fehlersuche und individuelle Konfigurationen. Für die meisten Organisationen funktioniert ein hybrider Ansatz am besten: Verwenden Sie Gruppenrichtlinie für grundlegende SAM-Beschränkungen im gesamten Bereich, und setzen Sie SAMRi10 für spezifische Systeme ein, die zusätzliche Absicherung benötigen.

Wie überprüfen Sie, ob die Schutzmaßnahmen gegen Aufklärungsversuche funktionieren?

Das Testen Ihres Aufklärungsschutzes erfordert einen methodischen Ansatz, der echte Angreifertechniken simuliert, ohne den Betrieb zu stören. Beginnen Sie mit grundlegenden Sitzungsaufzählungstests unter Verwendung von Tools wie NetSess oder den Get-WmiObject-Befehlen von PowerShell von einem nicht-administrativen Konto. Wenn NetCease korrekt funktioniert, sollten diese Versuche fehlschlagen oder nur begrenzte Informationen zurückgeben.

Um SAM-Beschränkungen zu testen, prüfen Sie den Fernzugriff auf die Security Account Manager-Datenbank mit Tools wie enum4linux oder rpcclient von einem Linux-System oder net use-Befehlen von Windows. Richtig konfigurierte SAM-Beschränkungen sollten unbefugte Enumerationsversuche blockieren und gleichzeitig legitimen administrativen Zugriff erlauben.

Der Schlüssel liegt darin, aus der Perspektive des Angreifers zu testen. Erstellen Sie Testkonten mit Standardbenutzerrechten und versuchen Sie gängige Aufklärungstechniken wie Domänenauflistung, Freigabeerkennung und Benutzerkontenauflistung. Dokumentieren Sie, was funktioniert und was nicht, und passen Sie dann Ihre Schutzmaßnahmen entsprechend an. Denken Sie daran, dass effektive Sicherheit nicht darin besteht, alles zu blockieren – es geht darum zu kontrollieren, welche Informationen wem zur Verfügung stehen, während gleichzeitig sichergestellt wird, dass legitime Geschäftsfunktionen ordnungsgemäß weiterlaufen.

Wann sollten Sie Änderungen an NetCease und SAMRi10 zurücksetzen?

Rollback-Szenarien beinhalten typischerweise Kompatibilitätsprobleme mit legitimen administrativen Werkzeugen, unerwartete Anwendungsausfälle oder Geschäftsprozessunterbrechungen, die während des Tests nicht identifiziert wurden. NetCease und SAMRi10 bieten beide Rollback-Optionen an, aber der Prozess unterscheidet sich für jedes Werkzeug.

Für NetCease umfasst das Zurücksetzen das Rückgängigmachen der Registrierungsänderungen, die die Sitzungsaufzählung steuern. Das Tool enthält Parameter, um die ursprünglichen Einstellungen wiederherzustellen, aber Sie sollten immer die baseline configuration dokumentieren, bevor Sie Änderungen vornehmen. Testen Sie den Rücksetzungsprozess zuerst in einer Laborumgebung, um sicherzustellen, dass Sie die Schritte und das Timing verstehen.

Das Zurücksetzen von SAMRi10 ist komplexer, da es mehrere Registrierungsschlüssel und möglicherweise Gruppenrichtlinien-Interaktionen umfasst. Wenn Sie SAM-Beschränkungen über Gruppenrichtlinien implementiert haben, verwenden Sie die Richtlinienverwaltungswerkzeuge, um Änderungen rückgängig zu machen. Für direkte Registrierungsänderungen beinhaltet SAMRi10 Wiederherstellungsfunktionen, aber eine manuelle Überprüfung ist unerlässlich, um ein vollständiges Zurücksetzen zu gewährleisten.

Der beste Ansatz ist proaktiv: Änderungen während Wartungsfenstern implementieren, Rücksetzverfahren dokumentieren und testen sowie betroffene Systeme mindestens 24-48 Stunden nach der Implementierung genau überwachen. Die meisten Kompatibilitätsprobleme treten schnell zutage, aber einige werden möglicherweise erst bei bestimmten Geschäftsprozessen oder Systemoperationen erkennbar.