Unter „Malware Analysis“ versteht man den Analyse-Prozess einer potenziellen oder bestätigten Schadsoftware. Es geht darum, so viele Informationen wie möglich aus dem analysierten File zu extrahieren, damit man die Software bestenfalls komplett versteht und sich effektiv davor schützen kann.

Im Kern der Malware Analysis steht die Beantwortung folgender Fragestellungen:

    • Um welche Art von Malware (Ransomware, Remote Access Trojaner usw.) handelt es sich?
    • Welche Fähigkeiten besitzt die Malware (ergibt sich aus den identifizierten Funktionen innerhalb der Software)?
    • Wie gelangt die Malware auf das eigene System (oder ins Netzwerk) und welche Weiterverbreitungsfähigkeiten besitzt sie?
    • Wie kommuniziert sie mit dem Besitzer?

Aus Sicht des Blue Teams ist das Ziel dann, aus den gewonnenen Informationen IOCs zu generieren und Host-/Netzwerksignaturen daraus zu erstellen. In diesem Blog Artikel beziehe ich mich – falls nicht anderswo erwähnt – ausschliesslich auf Windows spezifische Malware.

Methoden und Techniken

Um eine umfassende Malware Analyse durchführen zu können, müssen verschiedene Techniken und Methoden angewendet werden, damit möglichst informationsreiche Erkenntnisse über die Malware gewonnen werden können. Da die heute verwendeten Malwares immer perfider und komplexer werden, reichen einfache Analyse Techniken alleine nicht mehr aus, um den vollen Funktionsumfang und damit resultierenden IOCs einer Malware bestimmen zu können.

Static Analysis

Bei der Static Analysis wird die Malware nicht ausgeführt oder gestartet. Ziel ist es, alle Metadaten eines Files auszuwerten und öffentlich zugängliche Quellen (OSINT) nach weiteren Daten und Informationen abzufragen.

Es sollten mindestens folgende Metainformationen zusammengetragen werden:

    • Filesignatur (Software Owner)
    • Filesignatur (Magic Bytes)
    • File Hashes (MD5, SHA1, SHA2 …)
    • Entropie der Daten im File
    • ASCII/Unicode Strings
    • Was ist das Zielsystem der Malware? (MacOS, Windows oder eine Linux Distro?)
    • Scan mithilfe von Signatur basierten AV-Engines (bspw. frei verfügbare YARA Rules oder VirusTotal)
    • (Open) Threat Intelligence Plattformen wie Alien Vault, ThreatConnect usw. abfragen
    • Falls es ein Executable ist, DLLs berücksichtigen (Imported und Exported Functions)

Oftmals kann man bereits nach der Static Analysis eine Aussage machen, ob es sich bei der fragwürdigen Datei um einen „True-Positive“ handelt oder nicht.

Behavioral Analysis

Wer nun auf effiziente Art und Weise mehr über eine ausführbare Datei in Kenntnis bringen möchte, kann diese in einer Sandbox detonieren und das Verhalten beobachten oder automatisiert auswerten lassen. Dafür kann man sich sein eigenes Malware Lab konfigurieren, oder zu einer bereitgestellten Malware Analysis Platform greifen. Ziel dieser Methode ist zu beobachten, inwiefern eine ausführbare Datei ein Host System verändert und welchen Netzwerk-Traffic verursacht wird (bspw. Kommunikation mit C2 oder weiteren Payload Downloads).

Als Start für seine DIY „Freemium“ Malware Analysis Platform kann ich den Artikel von SANS-Teacher Lenny Zeltser sehr empfehlen: https://zeltser.com/build-malware-analysis-toolkit/ oder ein etwas anderer Ansatz wäre das Detection Lab, was dem Analyst eine vorkonfigurierte Active Directory Infrastruktur mit Eventlogging-Best-Practices und integriertem SIEM bereitstellt. Das Detection Lab kann dann auch nach Belieben mit Malware Analysis Tools getunt und nach seinen Bedürfnissen erweitert werden: www.detectionlab.network

Wer zur Online Variante greifen möchte – hat wie so oft – die Qual der Wahl aus unzähligen Anbietern. Hier ein Auszug einiger meiner Favoriten:

Nicht zuletzt muss man auch anmerken, dass praktisch jeder Hersteller von IT-Security Lösungen seine eigene Sandbox/Malware Analysis Appliance on-premises oder als Service in der Cloud anbietet. Oftmals bieten diese eine API oder andere Schnittstelle an, um eine on-demand Analyse zu starten, oder diese an Umsysteme anbinden zu können. Die Frage, welcher Hersteller/Anbieter die „beste“ Sandbox anbietet, kann man so nicht beantworten.

Wichtig an der Stelle ist; Man darf sich nie auf einen einzelnen Sandbox Report verlassen und man muss sich bewusst sein, dass Malware Developer bemüht sind, ihre Schadsoftware vor Sandboxes zu verstecken. Es kann sich lohnen, selber Live Forensics auf einem infizierten Host zu betreiben und sich nicht auf Reports automatisierter Systeme zu verlassen. Ein guter Start bietet REMnux (remnux.org) oder die FlareVM von FireEye (github.com/mandiant/flare-vm).

Code Analysis

Code Analysis setzt voraus, dass man sich mit Assembler auskennt oder sich zu helfen versteht. Assembler ist die einzige Sprache, welche Maschinencode in eine für Menschen lesbare Sprache „wahrheitsgetreu“ übersetzen kann. Diese Translation ist notwendig, weil nach dem Kompilieren von High-Level Sprachen wie bspw. C, C++ usw. Maschinencode (ein Binary) generiert wird, welches der CPU Instruktionen gibt, was diese zu tun hat.

Sprachen wie C#, Perl, Python, Java usw. sind sog. Top-Level Sprachen und werden normalerweise nicht in Maschinencode kompiliert, sondern in Bytecode übersetzt. Dieser wird dann nach der Ausführung – innerhalb des Interpreters („on-the-fly“) – in Maschinencode umgewandelt.

Man kommt nicht um diesen Analyse Step herum, wenn man wirklich verstehen möchte wie die zu analysierende Software tatsächlich funktioniert und Einzelheiten darüber in Erfahrung bringen möchte. Zu den bekanntesten Disassembler/Reverse Engineering Tools gehören IDA Pro (hex-rays.com/IDA-pro/) und Ghidra (ghidra-sre.org/).

Dynamic Analysis

Bei der Dynamic Analysis wird die Malware in einem live Debugger gestartet und kontrolliert ausgeführt. Im Gegensatz zum vorher genannten „Disassembling“, wird das Binary nicht in einem „toten“ Zustand vor der Ausführung als Assembler Code gezeigt, sondern kann Funktion für Funktion ausgeführt werden und zeigt dem Analyst jeweils wie sich der Output einer Funktion aufgrund von Gegebenheiten/Abhängigkeiten laufend verändert. Beispielsweise werden aktuelle Memory Adressen, CPU Register usw. angezeigt.

Eine grosse Hilfe ist auch, dass man die Variablen im Code nach Belieben manipulieren kann und dadurch das Verständnis einer Funktion sich selber sichtbar machen kann.

Software Engineers arbeiten meist mit Source-Level Debugger, welche das live Debugging während dem Coden möglich machen. Das macht die Softwareentwicklung effizient. Malware Analysten arbeiten hingegen fast ausschliesslich mit Assembler-level Debugger, weil der Source Code meist nicht zugänglich ist und de-obfuscation von oftmals verschleiertem Source Code auch seine Tücken hat.

Die meisten Malwares, welche von Cyberkriminellen stammen werden im User-Mode ausgeführt und können deshalb auf einem Host in einem Assembler-Level-Debugger debugged werden. Wenn man Kernel-Mode Malware analysieren möchte (bspw. Rootkits) benötigt dafür zwei komplette Betriebssysteme. Meist eine VM (Victim) und den darunterliegenden Host mit dem Debugger (bspw. WinDbg). Bei einem Reboot der VM kann sich dann WinDbg mit dem Kernel der VM connecten.

Oft benutzte Debugger sind:
WinDbg [Kernel-/ User-Mode] (learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools), x64dbg (x64dbg.com), Radare2 (rada.re/n/radare2.html) oder OllyDbg [nur 32-Bit und User-Mode] (www.ollydbg.de)

Fazit

Wer sich nun mit dem Analysieren von Malware beschäftigen möchte benötigt natürlich noch akkurate Malware – denn Learning by Doing ist nach wie vor die effektivste Methode sich selber neue Skills anzueignen und Erfahrung zu sammeln.

virusshare.com

bazaar.abuse.ch

malshare.com

github.com/ytisf/theZoo