Windows PowerShell als Einfallstor für Malware

Die Windows PowerShell, eine von Microsoft entwickelte Alternative zum Windows-Kommandozeilenprogramm und zum Windows Script Host, wird zunehmend als Einfallstor für Schadsoftware genutzt, warnt Security-Experte ESET. [...]

Die Gründe dafür liegen einerseits im großen Funktionsumfang der PowerShell, andererseits in der engen Verknüpfung zum Windows-Betriebssystem. Dies macht es Security-Programmen schwer, bösartige Software auch als solche zu identifizieren. In einem Artikel auf seinem Security-Blog WeLiveSecurity zeigt ESET anhand einer PowerShell-Malware auf, welche Tücken und Sicherheitsrisiken von der PowerShell ausgehen.

Die seit Windows 7 in allen Windows-Betriebssystemen vorinstallierte PowerShell bietet eine grafische Entwicklungsumgebung und eine eigene Skriptsprache namens „PowerShell Scripting Language“. Mit Hilfe der Konsole lassen sich Dateien auf verschiedenen Wegen herunterladen. Die Befehle dazu lauten:

• DownloadFile – Erlaubt den Download von einer Internetadresse direkt auf den PC
• DownloadString – Erlaubt den Download und die Ausführung eines PowerShell-Skripts
• Invoke-WebRequest – Eine weitere Möglichkeit, eine Datei aus dem Internet herunterzuladen
• Start-BitsTransfer – Erlaubt, mit Hilfe des intelligenten Hintergrundübertragungsdienstes von Windows (BITS) und dem Standard-Cmdlet Start-BitsTransfer einen Auftrag zu erstellen, um eine Datei herunterzuladen. Hier muss zuvor das Modul BitsTransfer mit dem Befehl Import-Module importiert werden

Die genannten Befehle werden von PowerShell-Schädlingen genutzt, um zusätzlichen Schadcode auf den Computer des Opfers zu laden. Die Methode DownloadString bietet darüber hinaus den Vorteil, dass ein PowerShell-Skript direkt nach dem Download im Speicher ausgeführt werden kann – ohne notwendige Kopie auf die Festplatte.

MALWARE, FAST OHNE DATEIEN

Eine Schadsoftware, die sich die genannten Befehle der Windows PowerShell zu Nutze macht, ist Win32/Bedep. Nachdem sich das Opfer damit infiziert hat, erstellt Bedep einen Eintrag in der Windows-Registry, dadurch bleibt die Software auch nach einem System-Neustart aktiv.

Der Registrierungseintrag bewirkt, dass der Windows Explorer bei jedem Systemstart eine Instanz des Kommandozeilenprogrammes cmd.exe ausführt, die wiederum eine unsichtbare, nicht interaktive Instanz der PowerShell startet. Hierbei werden mehrere Befehle übergeben, um den Command & Control-Server (C&C Server) des Botnetzes zu kontaktieren.

Interessant ist, dass es sich bei den Daten um ein PowerShell-Skript handelt, das für den Nutzer unsichtbar einen x86-Shellcode ausführt. Dieser Shellcode ähnelt in seinem Aufbau stark den Shellcodes des quelloffenen Penetrationtesting-Werkzeugs Metasploit. Er besorgt sich zunächst die Adressen der benötigten Windows API-Funktionen, 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, unter anderem auch eine doppelt verkettete Liste mit den Adressen der API-Funktionen der verwendeten Laufzeitbibliotheken (DLLs).

Nachdem sich der Shellcode die Adressen besorgt hat, reserviert er einen Speicherbereich und kontaktiert den C&C-Server. 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. Zunächst entschlüsselt die erste Stufe die verschlüsselte zweite Stufe. Hierbei handelt es sich um eine einfache XOR-Verschlüsselung mit dem Schlüssel 0x21.

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 Betrugs-Modul im Speicher seine schädlichen Routinen aus.
 
Die beschriebene Variante des Bots Win32/Bedep nutzt eine interessante Technik, um mittels Windows 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 unsichtbar im Arbeitsspeicher ausgeführt.

Win32/Bedep lief im ESET-Labor instabil und brachte gelegentlich das Windows-Testsystem zum Absturz. Richtig implementiert könnte diese Methode jedoch eine ernsthafte Bedrohung sein, auch wenn sie durch die Ausführung von cmd.exe und dem damit verbundenen Kommandozeilenfenster nach jedem Systemstart visuell recht auffällig ist – für erfahrene Nutzer eine deutliche, ebenso große Auffälligkeit wie der Aufbau einer Internetverbindung durch die PowerShell. (pi)