Viele Detektionsmechanismen sowie Untersuchungstechniken fokussieren stark auf das Analysieren der Kommandozeilen von Prozessen. Wir sehen zunehmend, dass diese Kommandozeilen von Malware verändert werden. Dies ist zum Beispiel bei der Rohrschach-Malware oder auch im Angriffsmuster von BlackCat zu finden. Dieser Blogeintrag beschäftigt sich damit, warum das trotz aller Schutzmassnahmen so einfach möglich ist.
Windows verwaltet Prozesse in sogenannten «_EPROCESS-Strukturen», welche Metadaten zu Prozessen beinhalten. Die genau Struktur dieser Kernel-Objekte kann man einfach im Windows Debugger anzeigen lassen.
In allen 64-bit-Systemen von Windows sind Kernel-Objekte durch PatchGuard gesondert gegen Veränderung geschützt. Wenn also Malware-Strukturen in _EPROCESS-Blöcken verändert würden, würde PatchGuard einen Blue Screen werfen und das System neu starten. Wie ist es also trotzdem möglich, dass Malware Metadaten zu einem Prozess, in diesem Fall die Kommandozeile, verändert?
Die Antwort ist, dass die Kommandozeile eines Prozesses nicht direkt in der _EPROCESS-Struktur verwaltet wird, sondern im sogenannten «Process Environment Block». Dieser befindet sich im Memory-Bereich des Prozesses selbst. Auf diesen Bereich bestehen Schreibrechte; ausserdem werden sie nicht durch PatchGuard überwacht.
Ein praktisches Beispiel zeigt, wo die Kommandozeilen der Prozesse liegen und wie einfach sie verändert werden können. Ich versuche den Ablauf so zu beschreiben, dass Sie als interessierte*r Leser*in das Experiment selbst durchführen können. Alles, was Sie dazu brauchen, ist ein installierter Windows Debugger. Hängen Sie diesen Debugger dann über den «Öffnen»-Dialog an den Windows Kern.
Im ersten Schritt starten wir einen Prozess, dessen Kommandozeile verändert werden soll. Dazu öffnen wir PowerShell. Weshalb? Wir werden ein PowerShell Script verwenden, welches auch von Angreifern, die mit der BlackCat-Ransomware in Verbindung stehen sollen, verwendet wird.
Zudem öffnen wir den Task Manager und machen die Kommandozeilen-Spalte sichtbar.
Nun verwenden wir Windows Debugger, um den _PEB des Powershell-Prozesses zu lokalisieren.
Praktischerweise bietet der Windows Debugger Direktlinks zu wichtigen Strukturen wie dem _PEB an. Ein einfacher Klick genügt, und Sie erhalten eine Zusammenfassung der interessanten Objekte, die im _PEB referenziert sind. Wichtig ist hierbei, dass zum Anzeigen des _PEB in den Kontext des Prozesses eingegangen wird (rote Box), bevor der _PEB aufgerufen wird. Dies zeigt, dass wir uns nun vom durch PatchGuard überwachten Memory-Bereich verabschiedet haben.
Um den _PEB sauber zu dereferenzieren, klicken wir nun auf die blaue Adresse beim Text «PEB at».
Die Kommandozeile ist nicht direkt unter dem _PEB verlinkt, sondern in einer Struktur namens ProcessParameters vom Typ RTL_USER_PROCESS_PARAMETERS verwaltet. Ein einfacher Klick genügt, um diese Struktur näher anzusehen.
Wie angekündigt, finden sich hier die Referenzen auf zwei Unicode Buffer, die den ImagePathName sowie die CommandLine des Prozesses beinhalten. Wenn auf den blauen CommandLine-Link und direkt danach auf den «Raw View»-Link geklickt wird, wird dieser Puffer genauer beschrieben.
Im illustrierten Beispiel liegt der eigentliche Buffer also an der Adresse 0x219022c256c im virtuellen Speicher des PowerShell-Prozesses. Das lässt sich auch noch einmal ausprobieren, indem die Daten an dieser Speicheradresse als Unicode dekodiert werden.
Intuitiv sollte es nun möglich sein, diese Daten zu verändern. Immerhin läuft der Windows Debugger unter System-Rechten und sollte Zugriff auf den gesamten Speicher haben. Wir können das «eu»-Kommando verwenden, um Speicherbereiche mit Unicode zu befüllen.
Leider bekommen wir an dieser Stelle eine Fehlermeldung. Ich habe für diesen Versuch Windows 10 verwendet. Hier gibt es Massnahmen, die ein einfaches Ändern des _PEB verhindern. Der Grund dafür ist allerdings nicht die Sicherheit, sondern das Vermeiden von parallelem Zugriff auf die Datenstruktur durch verschiedene andere Programme und den Windows-Kern. Dies könnte ansonsten zu Deadlocks führen. Immerhin beheimatet der _PEB auch häufig geänderte Variablen wie das aktuelle Arbeitsverzeichnis. Wie schafft es also Malware trotzdem, diese Daten zu verändern?
Die Antwort ist recht einfach: Wann immer der _PEB geschrieben werden soll, muss vorher ein Schreibschutz errichtet werden. Dies wird durch eine sogenannte «Critical Section» namens FastPebLock realisiert. Will also ein Thread den _PEB beschreiben, muss vorher der exklusive Schreibzugriff über die FastPebLock-Struktur hergestellt werden. Die Windows API bietet dazu zum Beispiel die Funktion «RtlEnterCriticalSection»
Wenn also Malware den _PEB verändern will, muss die Sperre vorrangig errichtet werden. Sehen wir uns dazu nun das Masquerade-PEB.ps1 Script an. Dieses erlaubt es, die Kommandozeile des PowerShell-Prozesses, in dem es aufgerufen wird, auf einen beliebigen Wert zu verändern.
Im Code wird deutlich ersichtlich, dass der PEB-Lock bezogen wird, bevor es zu Änderungen kommen kann.
Nun können wir das Script einfach testen, indem wir es vollständig in das PowerShell-Fenster laden. Anschliessend kann die Kommandozeile verändert werden.
Wird der Task Manager nun erneut gestartet, hat sich tatsächlich die Kommandozeile des PowerShell-Prozesses verändert.
In Überwachungen sowie Untersuchungen muss immer klar sein, welche Prozess-Parameter einfach und welche nur schwer veränderbar sind. Für SOC Analysts und Incident Responders lohnt es sich definitiv, hin und wieder den Windows Debugger zu öffnen, um den Arbeitsspeicher und den Windows-Kern besser zu verstehen.
Sie möchten mehr technische Insights sowie Tipps von mir und meinem Team erhalten? Abonnieren Sie ganz einfach unsere Blog-Updates, um keinen Artikel zu verpassen!