Warum brauchen wir ein System zur Malware-Analyse? Im Zuge von Incident-Response-Einsätzen und Forensiken kommen uns in unserer Arbeit immer wieder Programme, Skripte und Dokumente zweifelhafter Herkunft unter. Bei diesen ist oft nicht klar, was der Quellcode tut. Erreicht wird das zum Beispiel durch mehrere Stages (das vorliegende Skript lädt Schadcode dynamisch nach). Oft geschieht das Ganze durch stark verschleierten Programmcode.
Um eine Malware-Analyse solcher Artefakte durchzuführen, wird eine sichere Umgebung benötigt, in der diese (möglichst) gefahrlos ausgeführt, beobachtet und analysiert werden können. Ein oft genutztes Tool in diesem Kontext ist Cuckoo Sandbox .
Um die Samples auszuführen, werden Virtuelle Maschinen genutzt, die vom cuckoo Host gesteuert werden. Als Virtualisierungsumgebung gibt es verschiedene Varianten – in diesem Post werden wir Proxmox als Umgebung nutzen.
Proxmox ist jedoch mehr als „nur“ eine bloße Virtualisierungsumgebung. Es bietet auch umfangreiche Management-Features für ein komplettes Datacenter. D.h. bereits der Cuckoo Host ist eine virtuelle Maschine. Durch diesen Unterschied verändert sich die generelle Architektur unserer Sandbox bereits.
Setzen wir auf einen Hardware-Host für unsere Cuckoo-Installation, können wir in diesem Host die Malware VMs ausführen und beobachten. Es wird lediglich ein Host-Only-Netzwerk in den VMs exponiert.
Ist der Host bereits eine Virtuelle Maschine, haben wir diese Möglichkeit nicht. Wir benötigen also ein sicheres Netz, um mit den Malware-Maschinen zu kommunizieren, Samples zu übermitteln und das Verhalten zu beobachten.
Cuckoo Bare Metal
In diesem Diagramm wird das Standard Cuckoo Setup gezeigt. Das Hostsystem ist dabei auch das, auf dem Cuckoo installiert ist und den Virtuellen Maschinen als Host dient.
Cuckoo Host Installation
In dieser Variante, die wir in diesem Post beschreiben, ist auf dem Physikalischen Hostsystem installiert. Deshalb ist unser Cuckoo ebenfalls eine Virtuelle Maschine. Diese VM kontrolliert dann die Malware Analyse VMs.
Cuckoo Installation
Als erstes setzen wir unseren Cuckoo Host auf. Als Betriebssystem wählen wir hier Ubuntu 20.10 – wer sich bei Debian wohler fühlt, kann Cuckoo auch unter Debian installieren und benutzen.
Sobald die Ubuntu-Installation abgeschlossen ist, müssen die Requirements von Cuckoo installiert werden. Cuckoo ist ein Tool auf Python-2.7-Basis. Python 2 ist aktuell bereits End-of-Life, weshalb die Python Community mittlerweile angefangen hat, Tools wie pip für Python 2 aktiv zu entfernen. Um python2-pip auf diesem System noch zu installieren, muss das von der Python Packaging Authority heruntergeladen werden.
Der Link dazu ist hier – alternativ via wget https://bootstrap.pypa.io/get-pip.py
. Anschließend dann mit python2 get-pip.py
installieren – voila, pip2 ist installiert!
Hier noch einmal der Hinweis: Python 2 ist End of Life – Sobald Cuckoo mit Python 3 Support released wird, sollte das ausgetauscht werden.
Proxmox Machinery: Konfiguration
Um Cuckoo in Proxmox betreiben zu können, sind ein paar Anpassungen im Code von Cuckoo nötig. Im Folgenden werden die Anpassungen gezeigt.
machinery = proxmox
Die Machinery in cuckoo.conf
muss auf Proxmox gesetzt werden. Hier wird eingestellt, welche Art von Virtualisierung (oder mittels physical auch welche Rechner) genutzt wird.
Der folgende Abschnitt der Konfigurationsdatei bezieht sich auf konkret angelegte Virtuelle Maschinen. Solltet ihr hier einen anderen Namen wählen wie cuckoo-win10
, muss das natürlich angepasst werden.
Darauf folgt die Konfiguration der einzelnen Maschinen.
Der Snapshot Name ist zwar optional – wird er nicht gesetzt, wird jedoch einfach auf den neuesten Snapshot zurück gerollt. Hiermit könnte man also verschiedene Patch-Stände der Analyse-VM setzen, ohne direkt mehrere spezifische VM-Instanzen anlegen zu müssen.
snapshot = CLEAN
Hier kann dann ein alternatives Netzwerkinterface zum Packet-Capture definiert werden. Das ist in unserem Fall nicht nötig, da wir das in auxiliary.conf
spezifizierte Interface eth0 benutzen.
interface =
Nachdem wir nun den Zugang zur Proxmox API konfiguriert haben und welche VMs Cuckoo zur Verfügung stehen, ist es nun an der Zeit, etwas tiefer in den Maschinenraum von Cuckoo Sandbox abzutauchen. Bevor wir das allerdings tun, testen wir als erstes den Proxmox-Nutzer und API-Zugang, den wir eben konfiguriert haben.
Der Nutzer cuckoo muss natürlich vorher auf der Proxmox-Maschine angelegt und mit den entsprechend notwendigen Berechtigungen ausgestattet worden sein.
Solltet ihr auf Probleme beim Authentifizieren mit der Proxmox-API stossen, ist hier der richtige Zeitpunkt, um seine Login-Daten und die Host-Addresse zu prüfen.
Zum Testen verwenden wir das Kommandozeilen-Tool curl
. Eine erfolgreiche Authentifizierung sieht dann so aus:
Der Curl-Befehl
Und die zugehörige Reply:
Eine fehlerhafte Authentifizierung äußert sich in einer Reply mit {"data":null}%
.
Die in der erfolgreichen Reply aufgezeigten Berechtigungen
- VM.Audit
- VM.PowerMgmt
- VM.Clone
- VM.Snapshot
- VM.Snapshot.Rollback
sind notwendig, um Cuckoo die Arbeit mit den Virtuellen Maschinen, die in ‚cuckoo.conf‘ definiert sind, zu ermöglichen.
Allerdings ist es allein mit Konfigurationsänderungen nicht getan – um Cuckoo erfolgreich mit Proxmox arbeiten zu lassen, sind einige Modifikationen im Quellcode nötig.
Proxmox-Python-Erweiterungen
Glücklicherweise hat hier Scot Nusbaum von Trusted Sec bereits großartige Vorarbeit geleistet und das Ganze auf github veröffentlicht!
In config.py
muss eine Sektion zu Proxmox eingefügt werden – die jeweiligen Values zu den Keys (username, password, host, nodenames, machines etc.) werden durch die config proxmox.conf
gesetzt.
Neben den ganzen Konfigurationen muss es natürlich noch ein Python-Modul geben, das den Umgang mit der Proxmox-API regelt. Das Modul basiert auf dem Virtualbox-Modul (virtualbox.py
) und kann hier angesehen & kopiert werden. Thanks again, Scot!.
Und damit sollten wir es geschafft haben.
Malware VMs
Bevor wir mit der Analyse starten können, müssen wir jedoch noch (mindestens eine) Virtuelle Maschine aufsetzen, in der wir unsere Samples laufen lassen können.
Dabei ist es unabhängig, ob wir Windows oder Linux nutzen – die grundlegenden Schritte sind dabei immer die gleichen.
Wir setzen hier eine Windows 10 VM auf. Dazu besorgen wir uns als erstes ein aktuelle ISO von der Quelle: Microsoft .
Wenn hier die Datei heruntergeladen ist, prüfen wir noch den MD5 Hash um sicher zu gehen, dass alles geklappt hat und wir nicht mit einem korrumpierten Image anfangen zu arbeiten.
Als erstes müssen wir eine neue Virtuelle Maschine in Proxmox installieren. Dabei ist zu beachten, dass die Maschine in das richtige VLAN konfiguriert wird. Wir wollen nicht, dass diese Maschine mit anderen VMs auf unserem Proxmox-Server kommunizieren kann. Deshalb ist extra für Malware-Analysen ein VLAN angelegt worden. Hier befinden sich unsere Cuckoo-Host-Maschine und unsere Malware VMs.
Als nächstes wird Python 2.7 benötigt – das kann (aktuell noch) hier bezogen werden.
Damit sitzt die Maschine jetzt im Malware-VLAN, hat mit der installierten Python Runtime die Möglichkeit, den Agent auszuführen und so die Beobachtungen zum Verhalten an den Cuckoo Host zurückzumelden.
Der besagte Agent muss natürlich noch seinen Weg auf die Maschine finden – hierfür starten wir einen python http.server
auf dem Cuckoo Host und navigieren mit einem Browser von der Malware-Maschine auf die IP-Adresse des Cuckoo Host, laden das passende File herunter und können es jetzt starten.
Nachdem der Agent gestartet ist, ist die perfekte Zeit um, einen Snapshot zu machen. Dieser benötigt jetzt noch einen sprechenden Namen – hier im Beispiel ist es CLEAN. Auf diesen Snapshot setzt Cuckoo die VM mit jeder neuen Ausführung zurück.
Damit ist auch die Einrichtung der ersten Malware Execution VM abgeschlossen und wir können anfangen, Malware-Samples zu analysieren!
Samples analysieren
Zum Analysieren von Samples gibt es mehrere Wege und Möglichkeiten. Eine Option ist, die Dateien vom cuckoo Host aus mit der CLI hochzuladen.
Eine etwas komfortablere Variante ist das Web Interface. Das kann mittels cuckoo web runserver 0.0.0.:PORT
gestartet werden – wobei PORT
durch den zu nutzenden Port ersetzt werden muss.
Laut Cuckoo-Dokumentation ist das (natürlich) nicht der empfohlene Modus – und liefert eine Anleitung mit, wie die Applikation als WSGI-Applikation im Web Server konfiguriert werden kann. Diese Anleitung findet ihr [hier](https://cuckoo.readthedocs.io/en/latest/usage/web/#starting-the-web-interface).
In dem jetzt – Vorsicht: keine Credentials nötig – zugänglichen Web Interface können nun einfach Samples hochgeladen und von Cuckoo analysiert werden. Den Report kann man dann ebenfalls direkt dort lesen.
Damit ist dieser Blogpost auch schon am Ende – unserer Cuckoo-Analyseumgebung ist eingerichtet, konfiguriert und bereit, euch bei der Malware-Analyse hilfreich zur Seite zu stehen.
Blogposts und Code
An dieser Stelle nochmal explizit der Dank und Gruss an 0x4D5A und Scot Nusbaum .
Die in diesem Blogpost aufgeführten Code-Samples sind auf Github zu finden.
Weitere Beiträge
von Martin Riedel
Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Martin Riedel
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.