Im Artikel Local Security Authority Geheimnisse sicher aufbewahren von Michael Schneider werden verschiedene Hardening-Möglichkeiten für LSA vorgestellt. Darunter auch die Option mittels Registry-Key den LSA-Prozess (LSASS.exe) als Protected Process Ligth (PPL) zu konfigurieren. Unteranderen bietet das bekannte Angriffsmultitool Mimikatz die Möglichkeit mittels seinem Treiber mimidrv den LSA Schutz durch PPL wieder zu entfernen und damit praktisch out of-the-box den LSASS-Prozess patchen und anschliessend bekannte Aktionen wie den Dump von LSASS durchzuführen. In diesem Artikel wurde auf Windows 10 Version 1909 und mit Mimikatz Version 2.2.0 20191125 getestet. Dazu kann die Frage gestellt werden, ob die Manipulation des LSASS-Prozess von einem geschützten (PPL) zu eine ungeschützten Prozess einfach und rasch detektiert werden kann.

Auf Anhieb konnte keine befriedigende Detektions-Möglichkeiten mit Windows-Standard und Out-of-the-Box-Tools für diesen Vorgang identifiziert werden. Immerhin kann mit dem Abfragen von Prozess-Informationen mit PowerShell Get-Process einen Unterschied zwischen “normalen” und PPL-Prozessen festgemacht werden. Wie zuverlässig dies ist und ob es noch bessere Methoden gibt, muss in diesem Artikel offenbleiben.

Trotzdem konnte während der Recherche einige Interessante Information zu verschiedene Themen rund um Windows Prozesse und LSASS sowie PowerShell Projekte und UEFI Variablen gesammelt werden.

Protected Process Light

Das Konzept (siehe auch The Evolution of Protected Processes Part 1 und The Evolution of Protected Processes Part 2) von geschützten Prozessen (Protected Process) wurde initial mit Windows Vista eingeführt, um geschützte Inhalte (DRM) nur durch bestimme Prozesse mit einer bestimmten Signatur zu manipulieren. Für den Schutz von anderen Prozessen wie z.B. den LSASS konnte Protected Process jedoch nicht sinnvoll eingesetzt werden.

Mit Windows 8.1 führte Microsoft den Protected Process Light ein, welcher flexibler eingesetzt werden kann. PPL erweitert das bestehende Protection-Flag für Prozesse um weitere Typen für Protection Type und Signer. Der Protection-Typ beschreibt, ob es z.B. ein Protected Process oder Protected Process Light ist. Der Signer bestimmt, welche Art von Code-Signierung notwendig ist. Das Ganze folgt einer Hierarchie: Nur Prozesse mit gleicher oder höherer Stufe sowie korrekter Signatur können nun z.B. Treiber für den geschützten Prozess laden.

In der Kernel-Abbildung von Prozess-Objekten, der EPROCESS Struktur, sind unter anderen ab Windows 8.1 die folgenden Variablen für das Feld Protection verfügbar.

Protection Typen

1. PsProtectedTypeNone
2. PsProtectedTypeProtectedLight
3. PsProtectedTypeProtected
4. PsProtectedTypeMax

Signer

1. PsProtectedSignerNone
2. PsProtectedSignerAuthenticode
3. PsProtectedSignerCodeGen
4. PsProtectedSignerAntimalware
5. PsProtectedSignerLsa
6. PsProtectedSignerWindows
7. PsProtectedSignerWinTcb
8. PsProtectedSignerMax

Die Liste der Typen zeigt den Eintrag für den PPL-Typ PsProtectedTypeProtectedLight, sowie in der Liste der Signer den Eintrag PsProtectedSignerLsa.

Unter den Signern ist auch ein Type für Antimalware PsProtectedSignerAntimalware zu sehen, da auch die Prozesse von Antimalware-Lösungen gerne durch Angreifer manipuliert werden.

LSA Protection

Mittels einem Eintrag in der Registry kann der LSASS als PPL definiert werden, siehe auch unter Microsoft Docs.

Konfiguration von LSA Protection Mode

1. Registry-Key: RunAsPPL = dword: 1 unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa setzen
2. Reboot

Verifikation LSA Protection Mode

Nach dem Setzen des Registry-Keys und einem Reboot kann wie folgt verifiziert werden: Der Event der Quelle Wininit mit der Event-ID 12 lautet: LSASS.exe was started as a protected process with level: 4

Mit Sysinternals Process Explorer als Administrator ausgeführt, kann das auch auf einer graphischen Oberfläche nachvollzogen werden.

Mit dem Registry-Eintrag ist nicht Schluss. Damit durch einfaches Löschen des Registry-Keys der Schutz durch PPL von LSASS entfernt werden kann, wird ein weiterer Eintrag in eine UEFI Variable geschrieben, wenn dann das System aus einer UEFI Umgebung bootet.

Damit überlebt die Konfiguration Neustarts und sogar Neu-Installationen. Da die UEFI Environment Variablen nicht aus dem User-Mode verändert werden können, ist die Konfiguration damit einiges besser geschützt. Mit diesem Setup kann der PPL-Schutz von LSASS jedoch nur durch das Booten von UEFI Applikation/Shells wieder rückgängig gemacht werden.

Geeking out with UEFI ist ein interessanter Artikel zu UEFI und Windows. Der gleiche Blog stellt mit Working with UEFI variables from PowerShell auch ein PowerShell Tool zum Lesen von UEFI Variablen vor.

Mimikatz und mimidrv

Mimikatz bietet nun mit dem Treiber mimidrv die Möglichkeit den PPL-Schutz wieder zu entfernen:

1. Windows Defender wurde disabled
2. Mimikatz als Administrator ausführen
3. Mimidrv laden ⇒ !+
4. Remove Protection ⇒ !processprotect /remove /process:LSASS.EXE

Mittels Process Explorer kann der Vorgang nachvollzogen werden. Ein Neustart von Process Explorer ist dafür notwendig, ein Refresh mit F5 reicht dafür anscheinend nicht aus.

Nach einem Tweet von dem Mimikatz Autor Gentilkiwi (Benjamin Delpy) wird folgendes Kommando für die Manipulation der LSASS Protection angewandt.

Ein kurzer Blick in den Code von Mimikatz ergab einige Hinweise mit welchen Windows-Kernel-Calls Mimikatz die Manipulation vornimmt. Es scheint, dass folgende Calls eine wichtige Rolle dabei spielen (könnten):

• NtSetSystemEnvironmentValueEx in kuhl_m_kernel.c
• ZwSetSystemEnvironmentValueEx in mimidrv.c

Während der Recherche zur Manipulation von PPL-Prozessen ist ausserdem das Projekt PPLKiller aufgefallen, welches ein Tool für Debug-Zwecke bereitstellt.

Zurecht muss noch gefragt werden, warum Mimikatz mit mimidrv den LSASS-Prozess überhaupt patchen kann, da doch eine gültige und von Microsoft akzeptierte Signatur notwendig ist. Effektiv ist Mimikatz und mimidrv mit einer entsprechenden Signatur versehen.

Detektion

Initial war die Idee anhand der oben gewonnenen Information, Detektionsmöglichkeiten von Windows Standard Tools wie Windows Event/Audit-Logs, Sysmon, etc. zu identifizieren. Dazu können als Basis folgende mögliche Indikatoren zusammengefasst werden:

• Loggen der Aktion von Mimikatz, respektive der Kernel Calls
• Loggen der angepassten Variablen (Protection) von LSASS in seiner EPROCESS-Struktur
• Loggen der angepassten UEFI Variablen

Leider konnte in der gegebenen Zeit und mit Windows-Boardmittel keine befriedigende Lösung für eine Detektion dieses Vorgangs gefunden werden. Bisweilen konnte nur eine Methode identifiziert werden, welche durch einen Seiteneffekt, quasi eine Poor-Man’s-Lösung, prüfen kann, ob LSASS noch als PPL läuft.

Durch den Schutz von PPL werden bei Anfragen von Prozess-Attributen gewisse Informationen nicht zurückgegeben. Direktes Auslesen der Protection-Felder aus der EPROCESS Struktur konnte in der gegebenen Zeit, ohne einen eigenen Code zu schreiben (oder wiederzuverwenden), nicht bewerkstelligt werden.

Aber folgendes PowerShell Projekt könnte hier Abhilfe schaffen: NTObjectManager aus der Goolge Project Zero’s Sammlung Sandbox-Attacksurface-Analysis-Tools. Wiederum ein Twitter Screenshot hat dazu den Hinweis gegeben. Get-NTProcess eine Funktion aus NTObjectManager.

Jedoch konnte auch hier das Protection-Feld nicht ausgelesen werden, da wohl noch Permission-Probleme gelöst werden müssen. Doch das Projekt bietet eine grosse Fülle an Funktionen, die für die eine oder andere Fragestellung hilfreich sein könnten.

Poor-Man’s Detection

Vergleicht man das Resultat des PowerShell-Kommandos Get-Process -name LSASS | Select-Object * vor und nach der Manipulation mit Mimikatz, erkennt man, dass einige Attribute des durch PPL geschützten LSASS-Prozess nicht zurückgegeben werden. Dies könnte als schnelle Detektions-Möglichkeit für das Erkennen von ungeschützten Prozessen dienen (wie LSASS nach der Mimikatz Manipulation).

z.B. Zeilen 20, 21, 24, 25, etc. zeigen auf dem linken Resultat(Protected LSASS-Prozess) gewisse Informationen nicht an, welche im Resultat auf der rechten Seite (“normaler” LSASS-Prozess) zu sehen sind.

Wie eingangs erwähnt, ist nicht klar, ob dies eine zuverlässige Methode ist. Natürlich wäre das direkte Abfragen der Protection Variablen aussagekräftiger. Falls hierzu jemand zielführende Informationen besitzt, sind wir für Hinweise dankbar.

Fazit

Die Frage, ob die Manipulation von dem Protection-Typ eines Prozesses mit Windows-Standard-Tools detektiert werden kann, konnte nicht abschliessend beantwortet werden. Da die Thematik bereits relativ tief im Code von Microsoft sowie teilweise im Kernelmode stattfindet, ist der Zugriff auf die entsprechenden Informationen nicht trivial. Der direkte Zugriff durch eigenen Code, wie bei Mimikatz oder PPLKiller, ist möglich – Jedoch nur wenn der Code eine entsprechende Signatur besitzt. Natürlich sind auch andere, nicht in diesem Artikel identifizierte Optionen für eine einfache Detektion absolut denkbar.

Über den Autor

Dominik Altermatt arbeitet seit 2003 in der IT-Branche. Unter anderem hat er sich mehrere Jahre mit Data Leakage Prevention bei einer Grossbank beschäftigt. Heute liegen seine Schwerpunkte neben klassischen Penetration Tests bei der Einführung und der Weiterentwicklung von IT-Security-Management-Prozessen. (ORCID 0000-0003-4575-4597)

Links

• http://www.alex-ionescu.com/?p=116
• http://www.alex-ionescu.com/?p=34
• http://www.alex-ionescu.com/?p=97
• https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
• https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/eprocess
• https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
• https://docs.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-
• https://github.com/Mattiwatti/PPLKiller
• https://github.com/gentilkiwi/mimikatz
• https://github.com/gentilkiwi/mimikatz/blob/master/mimidrv/mimidrv.c
• https://github.com/gentilkiwi/mimikatz/blob/master/mimikatz/modules/kuhl_m_kernel.c
• https://github.com/gentilkiwi/mimikatz/releases/tag/2.2.0-20191125
• https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/tree/master/NtObjectManager
• https://oofhours.com/2019/09/02/geeking-out-with-uefi/
• https://oofhours.com/2019/10/05/working-with-uefi-variables-from-powershell/
• https://twitter.com/gentilkiwi
• https://twitter.com/gentilkiwi/status/704127304105136128/photo/1
• https://twitter.com/tiraniddo/status/950869648760803329
• https://www.geoffchappell.com/studies/windows/km/ntoskrnl/structs/eprocess/index.htm