Malware-Tarnung: Bedrohung duch manipulierte Kommandozeilen (InfoGuard Cyber Security Blog) Newsletter

Malware-Tarnung: Die wachsende Bedrohung durch manipulierte Kommandozeilen

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.

Kernelobjekt im Windows Debugger (_EPROCESS-Strukturen)

 

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.

Kommandozeilen finden und verändern – so geht’s 

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.

 

Verwendung eines PowerShell Script: Kommandozeilen finden im Task Manager

 

Nun verwenden wir Windows Debugger, um den _PEB des Powershell-Prozesses zu lokalisieren.

 

Verwendung eines PowerShell Script: 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. 

 

Windows Debugger bietet Direktlink zu Strukturen wie dem _PEB

 

Um den _PEB sauber zu dereferenzieren, klicken wir nun auf die blaue Adresse beim Text «PEB at». 

 

_PEB dereferenzieren via blaue Adresse

 

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.

 

Kommandozeile innerhalb des Process-Parameters

 

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.

 

Zwei Unicode Buffer, sie beeinhalten  den PathName sowie die CommandLine

Genaue Beschreibung des Unicode Buffer

 

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.

 

Der Buffer ist im virtuellen PowerShell-Prozess dargestellt

 

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.

 

Verwendung des eu-Kommandos, 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»

 

PEB_modification_rtl_user_process_parameters_fast_peb_lock


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.

 

Kommandozeile vom PowerSehll-Prozess, wird beliebig verändert

 

Im Code wird deutlich ersichtlich, dass der PEB-Lock bezogen wird, bevor es zu Änderungen kommen kann.

 

Der PEB-Lock wird gezogen, verhindert somit Änderungen

 

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.

 

Skript testen indem es ins PowerShell-Fenster geladen wird

 

Wird der Task Manager nun erneut gestartet, hat sich tatsächlich die Kommandozeile des PowerShell-Prozesses verändert.

 

Bei Neustart vom Taskmanager, ist veränderte Kommandozeile ersichtlich

 

Das Fazit – Windows Debugger nicht vergessen

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!Jetzt Blog Updates abonnieren!

<< >>

Cyberrisiken , CSIRT

Mathias Fuchs
Über den Autor / Mathias Fuchs

InfoGuard AG - Mathias Fuchs, Vice President Investigation & Intelligence

Weitere Artikel von Mathias Fuchs


Ähnliche Artikel
Ransomware – immer professioneller, immer gefährlicher
Ransomware – immer professioneller, immer gefährlicher

Dass Ransomware-Attacken stattfinden, ist inzwischen weitbekannt. Dennoch nehmen die Attacken nicht ab – im [...]
Cyber Threat Intelligence Insights: zeitlicher Ablauf von Ransomware-Vorfällen
Cyber Threat Intelligence Insights: zeitlicher Ablauf von Ransomware-Vorfällen

Im letzten Blogbeitrag haben wir uns die 53 grössten CSIRT-Fälle im Jahr 2022 angesehen. Nun werden wir uns [...]
Ransomware – eine latente Bedrohung [Teil 1]
Ransomware – eine latente Bedrohung [Teil 1]

Ransomware ist zwar schon lange ein Thema, jedoch alles andere als nur ein vorübergehendes Phänomen – im [...]

Spannende Artikel, aktuelle News sowie Tipps & Tricks von unseren Experten rund um Cyber Security & Defence.

Blog Updates abonnieren
Social Media
infoguard-cyber-security-know-how-security-awareness-phishing