Fileless Malware auf den Zahn gefühlt

Heimlicher Schädling

8. April 2021, 7:00 Uhr | Marc Laliberte/wg
© Wolfgang Traub

Im Zuge des konsequent anhaltenden Wettrüstens beim Thema Security setzen Angreifer auf immer ausgefeiltere Verschleierungsmethoden, um in den Netzwerken ihrer Opfer Fuß zu fassen. Da die meisten modernen Lösungen für Endpoint Protection heute in der Lage sind, klassische – also heruntergeladene und auf dem Endpunkt abgelegte – Malware zu identifizieren, kommt immer häufiger sogenannte „Fileless Malware“ zum Einsatz, die keinerlei Spuren im Systemspeicher hinterlässt.

Der Begriff „dateilose Malware“ ist ein wenig irreführend, da am Anfang durchaus Dateien involviert sein können – und meist auch sind. Während herkömmliche Malware jedoch den Schadcode in einer ausführbaren Datei vorhält, die ihren Niederschlag im Systemspeicher findet, agiert dateilose Malware ausschließlich über den Arbeitsspeicher. Bei klassischer Malware ist davon auszugehen, dass das Löschen der ausführbaren Datei auch der Infektion selbst einen Riegel vorschiebt. Somit stellt eine Identifizierung und Entschärfung im Rahmen von Endpoint Protection meist kein Problem dar.

Dateilose Malware verwendet hingegen nur eine initiale Dropper-Datei (etwa ein Office-Dokument), um ein integriertes Framework wie PowerShell zu öffnen und darüber ein Skript auszuführen. Viele Security-Tools können dieses Vorgehen kaum erkennen, da die Angreifer den Code in andere Prozesse einschleusen, ohne dass diese jemals mit einem Speicherlaufwerk in Kontakt kommt. Ein Grund für die steigende Beliebtheit dateiloser Malware ist also die Tatsache, dass sie sich so schwer identifizieren lässt: Es gestaltet sich extrem schwierig, solche Angriffe in ihren Anfangsstadien zu erkennen und zu blockieren, da auch immer die Gefahr besteht, dass es sich um einen Fehlalarm handelt und der Abwehrmechanismus legitime Aktivitäten behindert.

Verschlungene Pfade zum Ziel

Obwohl ein Großteil der dateilosen Malware mit irgendeiner Form von Dropper beginnt, gibt es auch Varianten, die tatsächlich keine Datei benötigen. Angreifern bieten sich in diesem Zusammenhang zwei Möglichkeiten: Entweder sie führen den fremden Code über eine bestehende Schwachstelle in einem Programm aus, oder – was häufiger vorkommt – sie verwenden gestohlene Anmeldeinformationen und missbrauchen auf diesem Weg eine mit dem Netzwerk verbundene Anwendung für Systembefehle in ihrem Sinne.

Das WatchGuard Threat Lab konnte kürzlich einen laufenden Angriff aufdecken, bei dem die zweitgenannte Methode zum Einsatz kam: Nachdem die Web-Konsole der Endpoint-Protection-Software eine Warnmeldung anzeigte, untersuchten Spezialisten deren Ursprung. Durch die Auswertung diverser Indikatoren und Telemetriedaten, die ein zur Umgebung des potenziellen Opfers gehörenden Server-Endpunkt gesammelt hatte, ergab sich ein klareres Bild. Die Bedrohung ließ sich beseitigen, bevor sie ihr Ziel erreichen konnte.

Das Besondere an diesem Angriff war sein ungewöhnlicher Einstiegspunkt: der Microsoft SQL Server des Opfers. Obwohl die Hauptaufgabe der Datenbankanwendung das Speichern von Datensätzen ist, besteht darüber hinaus die Möglichkeit, Systembefehle auf dem zugrunde liegenden Server auszuführen. Zwar rät Microsoft, die Rechte zur Verwendung von Windows-Dienstkonten gezielt zu beschränken; trotzdem setzen viele Administratoren immer noch auf Accounts mit umfassenden Befugnissen. Damit stehen auch dem Missbrauch Tür und Tor offen.

Im vorliegenden Fall hatte sich der Angreifer die Zugangsdaten zum SQL Server im Vorfeld beschafft – wie genau ihm dies gelungen ist, ließ sich nicht abschließend klären. Wahrscheinlich genügten eine Spear-Phishing-E-Mail oder ein Brute-Force-Angriff, bei dem der Angreifer ein zu einfaches Passwort knackte. Nachdem der Hacker Zugriff auf das System hatte und darüber SQL-Befehle ausführen konnte, boten sich ihm gleich mehrere vielversprechende Optionen, um Schaden anzurichten.

Besonders beliebt ist an diesem Punkt die Aktivierung und anschließende Verwendung der xp_cmdshell-Prozedur. Im aktuellen Beispiel setzte der Angreifer vermutlich ebenfalls auf diese Methode. Unter Umständen lud er jedoch auch eigenen Shellcode in die SQL-Server-Engine, um die Windows PowerShell-Anwendung (PowerShell.exe) unter dem neuen Namen sysdo.exe in das Temp-Verzeichnis des Servers zu kopieren. Mithilfe einer solchen Umbenennung von PowerShell vor der Verwendung versuchte der Angreifer sicherheitsrelevante Suchfilter auszutricksen, die sich bei der Erkennung von PowerShell-Befehlen nur vom Namen der Anwendung leiten lassen.

Anbieter zum Thema

zu Matchmaker+
Bild 1. Nachdem die „getarnte“ Version von PowerShell bereitstand, führte die Malware im ersten Schritt einen verschlüsselten Befehl (hier zur Sicherheit unkenntlich gemacht) aus.
Bild 1. Nachdem die „getarnte“ Version von PowerShell bereitstand, führte die Malware im ersten Schritt einen verschlüsselten Befehl (hier zur Sicherheit unkenntlich gemacht) aus.
© WatchGuard Technologies

Nachdem die „getarnte“ Version von PowerShell bereitstand, wurde im ersten Schritt ein verschlüsselter Befehl ausgeführt (Bild 1). Klarheit brachte die Entschlüsselung durch das WatchGuard-Team (Bild 2): Das verwendete PowerShell-Skript stellte sich als sehr simpel heraus. Es sendete zunächst eine Web-Anfrage an eine bösartige Domain und lud dann von dieser die im zweiten Schritt benötigten Nutzdaten herunter, in dem Fall eine Textdatei namens nc.txt. In dieser Textdatei befanden sich wiederum weitere PowerShell-Nutzdaten in einer Base64-Kodierung. Das Skript dekodierte diese nun und führte sie dann mittels des Invoke-Expression-Moduls aus. Da es das Modul nicht direkt, sondern über ein Alias aufrief, konnte der Angreifer eine zusätzliche Tarnung sicherstellen.

Bild 2. Das PowerShell-Skript stellte sich als simpel heraus.
Bild 2. Das PowerShell-Skript stellte sich als simpel heraus.
© WatchGuard Technologies

Bei den Nutzdaten der zweiten Stufe handelte es sich um eine leicht modifizierte Version des beliebten PowerSploit-Moduls Invoke-ReflectivePEInjection. Nach dessen Ausführung wurde nochmals dieselbe bösartige Domain aufgerufen und ein drittes Paket Nutzdaten heruntergeladen, konkret eine DLL-Binärdatei namens duser.dll. Per PowerSploit-Modul war das PowerShell-Skript in der Lage, die DLL-Datei in den Arbeitsspeicher zu laden, um sie von dort auszuführen. In diesem Fall entpuppte sich das Paket als Krypto-Miner, der die umfangreichen Verarbeitungsressourcen des SQL Servers im Fall eines erfolgreichen Angriffs zum Schürfen von Kryptowährungen genutzt hätte.


  1. Heimlicher Schädling
  2. Nachrüsten bei der Abwehr

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu WatchGuard Technologies GmbH IOM Business Center

Weitere Artikel zu Security-Management

Weitere Artikel zu Robert Half Technology

Weitere Artikel zu Siemens Enterprise Communications GmbH & Co. KG Leipzig

Weitere Artikel zu BullGuard Germany GmbH

Matchmaker+