zurück zur Übersicht

Aller guten Dingen sind drei? Oder drei statische Methoden zur Malware Analyse (Teil 1)

Malware, die böse Hexe der IT-Security, ist ein stets beliebtes Thema. Aus diesem Grund widmen wir dem Thema, bzw. verschiedenen Analyse-Methoden zur Erkennung, eine kleine Blogserie. Stellen Sie sich nun folgendes vor: In einem fernen Land, in einer fernen Zeit wird bei einem Unternehmen eine speziell für dieses angepasste oder entwickelte Malware entdeckt. Nun ist es unabdingbar auch in Zeiten von Next Generation Sandboxlösungen mittels Reverse Engineering mehr Informationen über die Malware herauszufinden. Nur so kann im Rahmen eines Incident Response weitgehend sichergestellt werden, dass die Bedrohung auch korrekt eingeschätzt werden kann. Wir möchten uns am Beispiel von verschiedenen Malware Dateien nun mal drei klassische Techniken der statischen Malware Analyse genauer ansehen.

Statische Analyse

Im Rahmen der statischen Analyse erfolgt keine Ausführung der verdächtigen Datei und es werden lediglich die „statischen“ Eigenschaften der Datei bewertet. Die folgenden drei Beispiel Techniken möchten wir in diesem Beitrag beleuchten:

1. Reputation auf öffentlichen und privaten Plattformen
2. Imports und Exports der Anwendung
3.
Verwendete Strings innerhalb der Datei

1. Reputation

Wird eine verdächtige Datei identifiziert, macht es Sinn den Hash Wert der Datei auf entsprechenden Threat Intelligence Plattformen zu prüfen z.B. VirusTotal, ThreatStream und ähnlichen. Die Datei selbst sollte dabei nicht vorschnell hochgeladen werden, da diese Dienste die Dateien weitergeben an AV Hersteller.

Im Rahmen des Starts der Analyse ist ja in der Regel noch gar nicht klar, ob es sich um Schadsoftware oder eventuell um vertrauliche Anwendungen handelt. Selbst wenn es sich mit hoher Wahrscheinlichkeit um Schadsoftware handelt ist die Funktionsweise i.d.R. noch unklar. Würde man eine Malware für einen gezielten Angriff schreiben, die z.B. eine C&C Kommunikation herstellt, also bereits auf Netzwerkverbindungen angewiesen ist, würde man diese auch mit einem Modul versorgen, welches kontinuierlich den Hashwert der Malware gegen VirusTotal und andere öffentliche Plattformen prüft.

Ist der Hash VirusTotal bekannt, weiß der Angreifer: die Malware ist aufgeflogen, da diese nur für diesen Angriff entwickelt oder angepasst wurde (der Hash muss bis dahin also unbekannt gewesen sein). So kann man entsprechende Maßnahmen einleiten (z.B. Zerstörung von Beweismitteln, herunterfahren meiner Command and Control Infrastruktur und im schlimmsten Fall versuchen Geräte mit noch unbekannter Malware zu verschlüsseln o.ä.). Möglich wäre dies über einen einfachen Webservice Aufruf.

Der Vorteil einer Analyse auf VirusTotal ist das bei sogenannter „Consumer Malware“ – also Malware die einem breiten Publikum zur Anwendung bereitsteht – der Analyst mit hoher Zuverlässigkeit auch den Typ der Malware rausfindet (z.B. PoisonIvy, WannaCry etc.). Ist der Typ der Malware erst einmal Identifiziert und es handelt sich um Consumer Malware kann auf intensiviere Analysen der Malware selbst i.d.R. verzichtet werden und der Analyst kann sich wichtigeren Fragen widmen, wie z.B. „Wie ist die Malware überhaupt rein gekommen?“.

Abbildung 1: Beispielprüfung der WannaCry Ransomware auf VirusTotal.

2. Imports und Exports der Anwendung

Bei „Imports“ handelt es sich um Programmcode, der i.d.R. durch andere Bibliotheken durch die eigentliche Anwendung eingebunden wird. Zum Beispiel ist es möglich, mittels API Funktionen Dateien zu erstellen und zu löschen (CreateFile, WriteFile, DeleteFile), Netzwerkverbindungen aufzubauen (send, recv, listen, socket, InternetOpenUrl..), den Speicher fremder Prozesse zu manipulieren (VirtualAlloc, WriteProcessMemory, CreateRemoteThread, SetWindowsHookEx…) und viele weitere Funktionen für die der Malware Autor nicht mehr viel eigenen Programmcode ergänzen muss. Wichtig hierbei ist, nur weil eine Funktion in einer Import-Table auftaucht, heißt das nicht dass diese tatsächlich von der Anwendung verwendet wird! Ein klassischer Fall wäre z.B. das Next Generation Sandbox Systeme einem unerfahrenen Analysten die Aussage geben „Die Datei enthält Techniken um das Debuggen der Anwendung zu erschweren“ und dieser nun davon ausgeht das die geprüfte Datei entsprechende Techniken auch einsetzt.

Eine sehr gute Referenz zu den einzelnen API Aufrufen ist die MSDN, für den API Call „CreateFile“ beschreibt die MSDN zum Beispiel:
Creates or opens a file or I/O device. The most commonly used I/O devices are as follows: file, file stream, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, and pipe.

Anders als der Name vermuten lässt, kann mit CreateFile also deutlich mehr erreicht werden als lediglich eine Datei auf der Festplatte zu erstellen. Ein gutes Verständnis der Windows API ist daher Pflicht für jeden Malware Analysten. Damit wird klar, dass sich durch die Analyse der Import-Tabelle oftmals erahnen lässt welche Funktionsweise die analysierte Datei besitzen kann. Leider ist die Import Table nur ein Hinweis auf die geladenen DLLs und Funktionen. Es gibt verschiedenste Gründe warum die Import Table nicht vollständig ist: z.B. gepackter / verschlüsselter Programmcode, dynamisch nachgeladener Programmcode z.B. durch den API Call „LoadLibary“, Obfuscation oder auch gezieltes Angreifen von Analyse Tools, um nur ein paar mögliche Manipulationstechniken zu nennen.

Innerhalb der Export-Table werden alle „Exports“ einer Anwendung dargestellt. Bei Exports handelt es sich um Funktionen die von anderen DLLs oder Anwendungen (EXE) eingebunden werden dürfen. Wenn dem so ist, müsste ja zum Beispiel die „kernel32.dll“ von Windows, die eine Vielzahl an API Funktionen bereitstellt, eine extrem hohe Anzahl von Exports aufweisen?

Abbildung 2: Export Table „kernel32.dll“ enthält mehr als 1000 Einträge.

Im zweiten Teil unserer Serie erfahren Sie alles zur dritten Analyse Möglichkeit: „Verwendete Strings innerhalb der Datei“ zudem analysieren wir die WannaCry Killswitch.