Ich möchte ein "Red Teaming"
Michael Schneider
Windows-Angriffe über Network Provider
Es existieren jedoch Techniken um beide Sicherheitsfunktionen zu umgehen. Durch Manipulationen am System kann der Virtual Secure Mode (VSM) und somit Credential Guard deaktiviert werden und durch das Laden von signierten Kernel-Treiber kann LSA Protection zur Laufzeit ausgeschalten werden. Diese Techniken beschädigen die Integrität des Systems und hinterlassen sichtbare Spuren, die detektiert werden können. Gibt es weitere Techniken um an Anmeldedaten zu gelangen, die tiefere Anforderungen und weniger einschneidende Effekte auf die Integrität des Systems haben?
Die Authentisierung von Benutzern ist eine zentrale Funktion des Betriebssystems. Die Windows Architektur zur Authentisierung beinhaltet verschiedene Komponenten, die Zugriff auf Anmeldedaten haben. Wenn Benutzer sich gegenüber dem Betriebssystem authentisieren, können diese Komponenten die Anmeldedaten weiter verarbeiten. Ein oft genutzter Vorgang ist das Zwischenspeichern der Anmeldedaten, um sich gegenüber weiteren Systemen authentisieren zu können, ohne dass Benutzer nochmals ihre Benutzernamen und Passwörter eingeben müssen.
Zu den Security Support Provider (SSP) gehören unter anderem Kerberos, NTLM (MSV1), TLS/SSL (Schannel) und Digest (WDigest). Das Security Support Provider Interface (SSPI) ermöglicht es, dass weitere Sicherheitsmodule einfach geladen werden können. Dazu muss der Registryschlüssel Security Packages
um den Namen der DLL des SSPs erweitert werden. Der Schlüssel befindet sich unter dem Pfad HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages
.
Durch die Funktion LSA Protection kann eingeschränkt werden, dass nur durch Microsoft signierte SSPs geladen werden dürfen – ansonsten kann jede beliebige DLL in den LSASS-Prozess geladen werden. Beispielsweise verfügt Mimikatz mit mimilib.dll über ein SSP, der mit administrativen Rechten geladen werden kann:
mimikatz(commandline)# privilege::debug Privilege '20' OK mimikatz(commandline)# misc::memssp Injected =)
Alternativ kann die Datei mimilib.dll in das Verzeichnis %WINDIR%\system32
kopiert und der Security Packages
Registryschlüssel erweitert werden – falls Mimikatz auf dem Zielsystem nicht ausgeführt werden soll. Nachdem der Mimikatz SSP geladen wurde, werden die Anmeldedaten nach einer erfolgten Anmeldung in die Datei mimilsa.log
geschrieben.
Angriffe gegen LSA und die Verwendung von SSPs werden seit Jahren praktiziert, daher sind die meisten Techniken dazu bekannt, Gegenmassnahmen stehen zur Verfügung und verschiedene Endpoint-Systeme können die Angriffe detektieren.
Ein Network Provider ist eine DLL, die Unterstützung für spezifische Netzwerkprotokolle bieten. Diese verwenden die Network Provider API um mit dem Betriebssystem zu kommunizieren. Ein Network Provider kann zugleich auch ein Credential Manager sein. Diese erhalten eine Notifikation, wenn ein Benutzer sich anmeldet oder ein Passwort geändert wird.
Winlogon stellt das graphische Interface (GUI) und die Funktionalität zur Authentisierung zur Verfügung. Über einen RPC-Kanal kommuniziert Winlogon mit mpnotify und teilt Benutzernamen und Passwörter mit. Das Programm mpnotify verteilt diese Information dann an die registrierten Credential Manager. Diese können analog zu SSPs über die Registry geladen werden. Der Registryschlüssel ProviderOrder
unter dem Pfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
enthält alle Network Provider. Um als Network Provider respektive Credential Manager die Anmeldedaten zu erhalten, wird die Funktion NPLogonNotify eingesetzt.
Der Security Researcher Grzegorz Tworek hatte vor zwei Jahren im Juli 2020 mit NPPSpy eine Implementierung der Funktion NPLogonNotify geschrieben. NPPSpy speichert Benutzername und Passwort eines Logins im Klartext in einer Logdatei.
Die NPPSpy DLL wird mit administrativen Rechten in das Verzeichnis %WINDIR%\system32
kopiert. Danach müssen einige Registryschlüssel gesetzt werden und NPPSpy als Network Provider registriert werden. Dies kann mit den folgenden PowerShell-Befehlen gemacht werden:
$NetworkProviderName = "NPPSpy" New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName" New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName\NetworkProvider" New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName\NetworkProvider" -Name "Class" -Value 2 New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName\NetworkProvider" -Name "Name" -Value $NetworkProviderName New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\$NetworkProviderName\NetworkProvider" -Name "ProviderPath" -PropertyType ExpandString -Value "%SystemRoot%\System32\$NetworkProviderName.dll" $NetworkProviderPath = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order" -Name ProviderOrder $NetworkProviderOrder = $NetworkProviderPath.ProviderOrder + ",$NetworkProviderName" Set-ItemProperty -Path $NetworkProviderPath.PSPath -Name ProviderOrder -Value $NetworkProviderOrder
Danach ist NPPSpy aktiv und speichert bei jedem Login die Anmeldedaten in der Datei C:\NPPSpy.txt
.
Der Angriff erfordert administrative Rechte, da eine DLL-Datei in das Windows-Systemverzeichnis kopiert wird und Registry-Einträge erstellt/angepasst werden. Wenn Angreifer an administrative Rechte gelangen, kann der Angriff nicht direkt verhindert werden. Im Gegensatz zum LSASS-Prozess gibt es keine Härtungsmassnahmen für Network Provider. Gegebenenfalls wird die NPPSpy DLL von einer Endpoint-Lösung erkannt.
Um den Angriff zu erkennen, sollte der Registryschlüssel HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder
auf Änderungen überwacht werden. Zudem können Services überwacht werden, die als Network Provider registriert werden. Für Elasticsearch beispielsweise kann die im Artikel Network Logon Provider Registry Modification vorgeschlagene Abfrage verwendet werden:
registry where registry.data.strings != null and registry.path : "HKL M\\SYSTEM\\*ControlSet*\\Services\\*\\NetworkProvider\\ProviderPath" and /* Excluding default NetworkProviders RDPNP, LanmanWorkstation and webclient. */ not ( user.id : "S-1-5-18" and registry.data.strings in ("%SystemRoot%\\System32\\ntlanman.dll", "%SystemRoot%\\System32\\drprov.dll", "%SystemRoot%\\System32\\davclnt.dll") )
Im Repository von Grzegorz Tworek gibt es zusätzlich das PowerShell-Skript Get-NetworkProviders.ps1, welches alle registrierten Network Provider eines Systems ausliest. Dies dient zur Analyse der Network Provider und listet zusätzliche Informationen zur jeweiligen DLL-Datei, ob und durch wen diese signiert wurde.
PS C:\> .\Get-NetworkProviders.ps1 Name : RDPNP DllPath : C:\Windows\System32\drprov.dll Signer : CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US Version : 10.0.19041.1 (WinBuild.160101.0800) Description : Microsoft Remote Desktop Session Host Server Network Provider Name : LanmanWorkstation DllPath : C:\Windows\System32\ntlanman.dll Signer : CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US Version : 10.0.19041.1 (WinBuild.160101.0800) Description : Microsoft® Lan Manager Name : webclient DllPath : C:\Windows\System32\davclnt.dll Signer : CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US Version : 10.0.19041.546 (WinBuild.160101.0800) Description : Web DAV Client DLL Name : NPPSpy DllPath : C:\Windows\System32\NPPSPY.dll Signer : Version : Description :
Der Network Provider NPPSpy ist in diesem Fall auffällig. Angreifer können natürlich beliebige Namen wählen, aber die fehlende Signatur ist ein verdächtiges Indiz.
Angriffe gegen LSA sind weit verbreitet und dementsprechend existieren einige Härtungsmassnahmen, um solche Angriffe zu erschweren. Die Komplexität und Anforderungen für LSA-Angriffe steigt daher stetig an. Zudem wird das Auslesen des LSA-Speichers durch viele Endpoint-Lösungen erkannt und teilweise blockiert. Im Gegenzug dazu sind Angriffe mittels Network Provider einfach zu implementieren und werden weitaus weniger überwacht. Verteidiger sollten dementsprechend passende Detection Use Cases für Network Provider implementieren. Für Angreifer stellen Network Provider eine Alternative dar, um weiterhin Anmeldedaten auslesen zu können. Im Gegensatz zu einem LSA-Dump erlangen Angreifer jedoch nicht direkt Anmeldedaten, sondern müssen zu einem späteren Zeitpunkt wieder an die Logdatei gelangen und darauf hoffen, dass sich jemand am System angemeldet hat.
Unsere Spezialisten kontaktieren Sie gern!
Michael Schneider
Michael Schneider
Michael Schneider
Michael Schneider
Unsere Spezialisten kontaktieren Sie gern!