Seit Windows 10 Version 1709 bringt der Windows Defender sogenannte „Attack Surface Reduction“ (ASR) Regeln mit. Diese Regeln dienen dazu – wie der Name bereits vermuten lässt – die generelle Angriffsfläche eines Systems zu reduzieren. Basierend auf einem Auszug der offiziellen Dokumentation werden hierzu unter anderem folgende Verhaltensmuster von Anwendungen überwacht:
- Starten von ausführbaren Dateien und Skripten, die versuchen, andere Dateien herunterzuladen und/oder auszuführen
- Ausführen von obfuskierten oder anderweitig verdächtigen Skripten
- Verhaltensweisen, die bei Anwendungen im normalen Arbeitsalltag nicht vorkommen
In der Dokumentation findet sich außerdem eine Tabelle, in welcher alle derzeit verfügbaren ASR-Regeln samt einer zugehörigen ID aufgelistet sind. Eine Vielzahl der Regeln zielt auf die Erstellung von neuen Prozessen und die Makro-Funktionalität von Office-Anwendungen ab. Letzteres hat in der Vergangenheit oft als erstes Einfallstor in Kombination mit Phishing-Angriffen gedient, weshalb Microsoft hier wohl einen besonderen Schwerpunkt gelegt hat.
Im Folgenden soll es aber speziell um die Block credential stealing from the Windows local security authority subsystem (lsass.exe) Regel gehen, da diese den Zugriff auf den lsass.exe Prozess einschränken und somit das unbefugte Auslesen von dort zwischengespeicherten Anmeldeinformationen verhindern soll („Credential Stealing“):
Grundlegende Konfiguration von ASR-Regeln
ASR-Regeln werden in der Regel entweder über Intune oder entsprechende Gruppenrichtlinien ausgerollt. Alternativ können Regeln aber auch direkt über die PowerShell konfiguriert werden, was für die Demonstrationszwecke dieses Beitrags die einfachste Variante ist.
Um eine Regel zu konfigurieren, kann das Add-MpPreference Cmdlet verwendet werden:
Der GUID-Parameter bestimmt hierbei, welche Regel konfiguriert werden soll. Hierzu kann eine der IDs aus der oben aufgeführten Tabelle übergeben werden (bspw. 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2). Der Mode Parameter gibt an, in welchen Zustand die Regel gesetzt werden soll (Disabled, Enabled, Audit oder Warn).
Um nun beispielsweise die Credential Stealing ASR-Regel zu aktivieren, kann folgender PowerShell-Befehl abgesetzt werden:
Um eine Übersicht der konfigurierten ASR-Regeln zu erhalten, kann das Get-MpPreference Cmdlet verwendet werden:
Auf einem System mit aktivierter Block credential stealing from the Windows local security authority subsystem (lsass.exe) Regel sieht die Ausgabe wie folgt aus:
Die 1 repräsentiert hierbei den Wert Enabled (bzw. Block laut Referenz):
Neben Disable und Block existieren zudem noch die Zustände Audit und Warn. Im Warn Zustand wird dem Endnutzer beim Eingreifen der Regel eine Benachrichtigung angezeigt, über welche die Blockierung nach manueller Bestätigung durch den Endnutzer selbst umgangen werden kann.
Im Audit Zustand hingegen werden zwar alle Regelverstöße in den Systemlogs protokolliert, allerdings werden keine Gegenmaßnahmen ergriffen. Dieser Zustand ist nützlich, um die Auswirkung neuer Regeln in Produktivumgebungen zu evaluieren, bevor diese im nächsten Schritt aktiviert werden, und automatisiert Gegenmaßnahmen bei Regelverstößen ergreifen.
Weiterführende Informationen zu den verschiedenen Zuständen können diesem Artikel entnommen werden.
Deep Dive: „Block credential stealing from the Windows local security authority subsystem (lsass.exe)“
Der Name der Regel klingt für einen Angreifer zunächst etwas beunruhigend, da Credential Stealing ein essenzieller (und meist sehr effektiver Angriff) in Windows-Umgebungen ist, um sich weiter im Netzwerk auszubreiten („Lateral Movement“). Doch als neugieriger Angreifer fragt man sich schnell, wie diese Regel auf der technischen Ebene implementiert ist – der Teufel steckt ja schließlich im Detail. Hier liefert ein Auszug aus der offiziellen Dokumentation einen ersten Anhaltspunkt:
Exkurs: OpenProcess, Handles und PROCESS_ALL_ACCESS
Um das Verhalten der Regel genauer zu analysieren, bietet es sich an, die Zugriffsberechtigungen der geöffneten Handles sowohl mit aktivierter als auch mit deaktiviert ASR-Regel zu vergleichen.
Die Zugriffsberechtigungen des jeweiligen Handles zum lsass.exe Prozesses können mithilfe der Windows-API genauer analysiert werden. Der unten aufgeführte Codeauszug aktiviert zunächst das SeDebugPrivilege, welches notwendig ist, um als lokaler Administrator ein Handle zum lsass.exe Prozess zu öffnen. Anschließend wird die entsprechende Prozess-ID gesucht, per OpenProcess ein Handle zum Prozess-Objekt mit allen verfügbaren Zugriffsrechten (PROCESS_ALL_ACCESS) geöffnet und anschließend die tatsächlich verfügbaren Zugriffsberechtigungen des Handles ausgegeben. Der gesamte Code kann in unserem GitHub-Projekt dazu gefunden werden.
Wird das Programm nun mit deaktivierter Credential Stealing Regel ausgeführt, hat das geöffnete Handle eine Zugriffsberechtigung von 2097151. Bei diesem Wert handelt es sich um eine sogenannte „Access Mask“, also eine Bitmaske bei der jedes Bit eine Berechtigung repräsentiert. Die einzelnen Berechtigungen sind in der Ausgabe aufgeschlüsselt:
Ist die Regel allerdings aktiviert, ändert sich der Wert der Zugriffsberechtigung auf 1185793. In der Ausgabe kann gesehen werden, dass dem Handle neben Berechtigungen wie PROCESS_CREATE_PROCESS oder PROCESS_CREATE_THREAD auch die PROCESS_VM_READ-Berechtigung entzogen wurde:
Die Block credential stealing from the Windows local security authority subsystem (lsass.exe) Regel entzieht also jedem Handle (unter anderem) die PROCESS_VM_READ-Berechtigung, wodurch kein anderer Prozess lesenden Zugriff auf den sensiblen Speicher des lsass.exe Prozesses erhalten kann:
Aber es gibt doch sicherlich Prozesse, die einen solchen Zugriff für legitime Zwecke benötigen…
Zutritt nur per Gästeliste
Im ExtractedDefender Github-Repo von @HackingLZ findet sich ein dekompiliertes LUA Artifakt der Credential Stealing ASR-Regel. Im dekompilierten Code gibt es eine GetPathExclusions Funktion, welche verschiedene Windows-Pfade beinhaltet:
In Zeile 54 findet sich zum Beispiel der Pfad %temp%\Ctx-*\Extract\TrolleyExpress.exe, welcher auf das temporäre Verzeichnis des aktuellen Benutzers verweist (%temp%) und eine Wildcard (Ctx-*) enthält. Somit sollte also unter anderem der Pfad C:\Users\[Username]\AppData\Temp\Ctx-1337\Extract\TrolleyExpress.exe von der ASR-Regel ausgenommen sein.
Um das zu testen, kann das zuvor verwendete Programm zum Analysieren der Handle Zugriffsrechte verwendet werden. Hierzu wird das Programm einmal als handles.exe und einmal als TrolleyExpress.exe in das exkludierte Verzeichnis kopiert und ausgeführt:
Während handles.exe wie zuvor nur ein Handle mit geringen Zugriffsrechten (1185793) erhält, hat TrolleyExpress.exe Vollzugriff (2097151) auf den lsass.exe Prozess. Somit ist es TrolleyExpress.exe möglich, den Prozessspeicher von lsass.exe auszulesen und einen Credential Stealing Angriff auszuführen.
Let’s dance!
Um sowohl die Enumeration aktiver ASR-Regeln als auch die Umgehung der Credential Stealing Regel einfacher zu gestalten, haben wir ein kleines Tool namens dAnSR in C# entwickelt. Das Tool kann im entsprechenden GitHub-Repository gefunden werden.
enum
Das enum Modul liest die konfigurierten ASR-Regeln und ggfs. davon ausgeschlossene Pfade über die Windows Management Instrumentation (WMI) aus. Die relevanten Informationen sind im root\Microsoft\Windows\Defender WMI-Namespace zu finden:
dump
Das dump Modul nutzt die MiniDumpWriteDump Windows-API per P/Invoke um ein Speicherabbild des lsass.exe Prozesses zu erstellen und komprimiert das Abbild anschließend in eine GZip-Datei. Dies funktioniert analog zum SharpDump Tool von @harmj0y:
auto
Das auto Modul kopiert das Tool nach %temp%\Ctx-*\Extract\TrolleyExpress.exe, wo die Wildcard durch eine zufällig generierte Zahl ersetzt wird. Anschließend wird die TrolleyExpress.exe automatisch gestartet, wodurch das Tool im „no arg mode“ gestartet wird und automatisch das dump Modul ausführt. Da dieser Pfad von der Credential Stealing ASR-Regel ausgeschlossen ist, kann so trotz aktiver Regel ein Speicherabbild des lsass.exe Prozess erstellt werden:
Erkennungsmöglichkeiten und Schutzmaßnahmen
Erkennung: Event Logs
Wenn eine ASR-Regel im Block Modus ausgelöst wird, wird dies im Microsoft-Windows-Windows Defender/Operational Event Log mit der Event ID 1121 protokolliert (Referenz). Bei der Ausführung der handles.exe mit aktiver Credential Stealing Regel wurde z.B. das folgende Event protokolliert:
In Kombination mit dem Process Name Feld lässt sich aus dem Event schlussfolgern, dass ein unerwarteter Zugriff von der handles.exe auf den lsass.exe Prozess verhindert wurde, was in einer Produktivumgebung auf mögliche Post-Exploitation Aktivität hindeuten kann.
Erkennung: Dateien und Pfade
Da es eine Reihe an exkludierten Pfaden gibt, welche von der Credential Stealing Regel ausgeschlossen sind, sollten diese gezielt überwacht werden. Besonders bietet sich der von dAnSR ausgenutzte Pfad %temp%\Ctx-*\Extract\TrolleyExpress.exe an, da dieser für jeden Benutzer schreibbar ist.
Bei der „echten“ TrolleyExpress.exe handelt es sich um eine Komponente des Citrix Receivers, welche zudem von Citrix selbst signiert ist. Sollte also stattdessen ein unsigniertes Programm von diesem Pfad aus ausgeführt werden, dient dies als starker Indikator für einen potenziellen Umgehungsversuch der ASR-Regel.
Um speziell die Ausführung von dAnSR zu überwachen, kann die Erzeugung der Dateien desktop2.ini und dansr.gz als Indikator genutzt werden. Diese werden beim Versuch den Prozessspeicher der lsass.exe auszulesen im aktuellen Arbeitsverzeichnis abgelegt.
Schutzmaßnahmen: LSA-Schutz und Credential Guard
Um ein System effektiv vor Credential Dumping Angriffen zu schützen, wird empfohlen, den LSA-Schutz und den Credential Guard zu aktivieren. Der LSA-Schutz (RunAsPPL) sorgt dafür, dass die Local Security Authority (LSA) in einem isolierten Container ausgeführt wird, wodurch ein Zugriff auf den Prozessspeicher durch bösartige Software verhindert wird. Darüber hinaus können durch den Credential Guard Anmeldeinformationen mithilfe der virtualisierungsbasierten Sicherheit (VBS) weiter isoliert werden, sodass nur privilegierte Systemsoftware darauf zugreifen kann.