Ein Einblick in Ransomware – Statische Analyse – Teil 2

Get set!

Willkommen zurück zur Malware-Analyse durch Data-Sec GmbH. Im letzten Teil haben wir beschrieben wie wir unsere Analyse-Umgebung aufbauen und welche Punkte dabei berücksichtigt werden müssen.

In diesem Teil widmen wir uns endlich der eigentlichen Malware und starten mit der Analyse. Es ist hierbei nochmal zu erwähnen, dass wir uns hier bekannter Malware widmen. Das Ziel ist es hier nicht neue Erkenntnisse zu gewinnen, sondern dem Leser die Malware-Analyse näher zu bringen. Das folgende Malware-Sample wurde willkürlich ausgewählt, in Hinblick auf diesen Blog.

Genug der Theorie, für diesen Blog widmen wir uns folgender Malware:

Malware
SHA256: 59ec54fb9b1d3415b54558977e3640b81bb3ebebdb61af3fc772e308c6b8eb3a

Als Analyse-VM stehen verschiedene Windows 7- als auch Windows 10-VMs als 64Bit-Variante bereit. Jede Windows-VM ist hier auf dem aktuellen Patch-Stand.

• – Windows 10 x64 Pro 2009: Analyse-VM
  Hier sind alle benötigten Tools und jegliche Software installiert, die der Analyst benötigt, um die Malware in Ihre Grundbausteine zu zerlegen und zu analysieren.
• – Windows 10 x64 Pro 2009: Dies ist eine „Vanilla“-VM, die nur installiert und aktualisiert wurde. Diese wird für die Ausführung der Ransomware genutzt.
• – Windows 7 x64 Pro SP1: Sollte es Probleme geben bei der Analyse mit Windows 10, wird die Windows 7-VM genutzt.

Let’s get encrypted!

Der erste Schritt ist es die Malware in einer abgesicherten Umgebung zu beobachten. Dies bedeutet letztendlich die Malware zu starten und zu beobachten was genau passiert. Sollte die Malware Anti-Debug-Techniken, also die Ausführung in einer VM oder nebst Analyse-Tools verhindern, gilt es diese in den nächsten Schritten zu umgehen.

Als „Victim-VM“ wird hier eine „Vanilla“-Windows 10-VM genutzt. Der Hypervisor ist Oracle VirtualBox. Jegliche Netzwerkverbindungen, als auch shared Folder werden deaktiviert bzw. Entfernt. Windows Defender und Firewall sind beide deaktiviert. Des Weiteren wurde Windows 10 DEP

als auch Windows 10 SEH deaktiviert. Bei der Windows 7-VM wurde die Windows Firewall deaktiviert.

Bild

Kurze Zeit nach Ausführung der Malware sehen wir hier Schreib- und Lesevorgänge auf der Festplatte. Die Vermutung liegt hier nahe, dass wir es mit Ransomware zu tun haben.

Bild

Nach wenigen Minuten haben wir die Bestätigung in Form einer Ransom-Note und einem Browser-Fenster. Vermutlich haben wir es hier mit der Locky Ransomwarezu tun.

Bild

Bild

Analyse der Malware

Die Malware-Analyse ist generell in 2 Schritte aufgeteilt. Statische und Dynamische Analyse. Die Statische Analyse beschreibt die Analyse der Malware, ohne diese auszuführen. Es wird also versucht so viel wie möglich an Informationen anhand der entsprechenden Files und Indikatoren zu gewinnen. Die Dynamische Analyse beschreibt die Analyse der Malware im ausgeführten Zustand. D.h. was macht die Malware, sobald Sie tatsächlich ausgeführt wird. Beide Bereiche werden dann zusätzlich noch in die Erweiterte statische und dynamische Analyse unterteilt.

Statische Analyse

Bei der statischen Analyse wird die Malware auf interessante Informationen untersucht. Diese sind unter anderem Strings, also bestimmte Wörter im Programmcode, der auf bestimmte Funktionen hinweisen kann. Bspw. Kann der String „http“ auf Internetaktivität hinweisen. Ob damit ein Download, Upload, Kontrollserver oder lediglich Windows-Update gemeint ist, lässt sich an dieser Stelle meist schwer feststellen. Interessant sind aber auch Imports, Exports, Timestamps, File-Header und viele andere Indikatoren, mit denen der Analyst versucht den Sinn und Aufbau der Malware zu verstehen.

• 1. File-Info

Die Malware ist 639kb groß und wurde August 2018 modifiziert. Dies kann unter anderem auf ältere Malware hinweisen wobei Timestamps auch oft gefälscht werden, um den Analysten zu verwirren.

Bild6

• 2. Packer?

Malware nutzt oftmals sogenannte Packer, um den Programmcode vor Antivirus und Analyst zu verstecken. Ein Packer entpackt dann zur Laufzeit den tatsächlichen Schadcode und führt diesen im Arbeitsspeicher aus. Ein sehr einfacher Packer ist bspw.UPX.

Moderne Malware nutzt hier normalerweise selbst geschriebene oder modifizierte Packer, um dem Analysten die Arbeit zu erschweren. Es gibt mehrere Tools, die eine Executable auf bekannte Packer untersuchen. Ist dies nicht möglich hat der Analyst mehrere Indikatoren um potenziellen „packed code“ zu erkennen.

• a) DiE (Detect it Easy)

Detect it Easy ist ein sehr hilfreiches Tool für jeden Malware-Analyst, bzgl. Statischer Analyse. DiE gibt unter anderem Aufschluss über die Programmiersprache, packed code, Imports, Entropy und weitere Details.

In diesem Fall erkennt DiE keinen Packer und auch keine Programmiersprache, was auf modifizierten Code hindeutet.

Bild 7

• b) Entropy

Die Entropy beschreibt in Kurzform die „Randomness“ von Programmcode. D.h. finden wir an einer bestimmten Stelle bzw. bestimmten Abschnitt einer Datei „random code“ können wir hier von obfuscated bzw. verschleiertem Code ausgehen, was wiederum auf einen Packer hindeutet. In Kurzform, hohe Entropy deutet auf Packer hin.

Mithilfe von DiE können wir die Entropy untersuchen und stellen fest, dass die Sections .data und .rsrc vermutlich gepackt sind.

Bild8

Die Namen der Sektionen sind hier definiert, können vom Autor aber auch geändert werden. Oftmals nutzen die Malware-Autoren hier Sektionen, die nicht für eigentlichen Programmcode vorgesehen sind oder ändern die Namen der Sektionen ab, um für Verwirrung zu sorgen.

• b) Entropy

Die Entropy beschreibt in Kurzform die „Randomness“ von Programmcode. D.h. finden wir an einer bestimmten Stelle bzw. bestimmten Abschnitt einer Datei „random code“ können wir hier von obfuscated bzw. verschleiertem Code ausgehen, was wiederum auf einen Packer hindeutet. In Kurzform, hohe Entropy deutet auf Packer hin.

Mithilfe von DiE können wir die Entropy untersuchen und stellen fest, dass die Sections .data und .rsrc vermutlich gepackt sind.

Bild 9

Die Namen der Sektionen sind hier definiert, können vom Autor aber auch geändert werden. Oftmals nutzen die Malware-Autoren hier Sektionen, die nicht für eigentlichen Programmcode vorgesehen sind oder ändern die Namen der Sektionen ab, um für Verwirrung zu sorgen.

• c) Strings

Ein weiterer Indikator sind Wörter im Programmcode. Dabei handelt es sich um alle möglichen lesbaren Wörter, die aus dem Programmcode erkennbar sind. Z.b. würde ein „http“ auf Netzwerkaktivität hindeuten und ein „CreateToolhelp32Snapshot“ auf eine mögliche Anti-Debug-Technik, um Prozesse auszulesen.

In diesem Fall haben wir hier einen weiteren Hinweis auf gepackten Code, da fast alle lesbaren Strings auf obfuscated (verschleierten) Code hindeuten.

Bild 10

Die wenigen lesbaren Strings sind allerdings relativ eindeutig und sehr verdächtig. Wichtig,
nur weil diese Strings im Programmcode auftauchen, heißt dies nicht, dass diese auch tatsächlich genutzt werden.

Service:

Mit „ControlService“ können Dienste manipuliert werden. Bspw. Können hier ungewünschte Dienste abgeschaltet werden. Weitere Strings dieser Kategorie, die gefunden wurden sind „LogonUser“ und „InitiliazeAcl“

Bild 11

Ressources:

Mit „LoadString“, „LoadIcon“ und „ExtractIcon” können Dateien oder Code aus der Ressource-Section der Datei extrahiert und genutzt werden. Dies wird im weiteren Lauf noch ersichtlich.

Bild 12

Registry:

Mit Befehlen wie „RegReplaceKey“ und anderen Befehlen kann die Registry ausgelesen oder beschrieben werden. Die Möglichkeiten sind hier vielfältig. Oftmals nutzt Malware dies für Persistence oder aber um Keys, Checks o.ä. anzulegen.

Bild 13

File-Operation:

Logischerweise benötigt Malware die Möglichkeit Dateien zu bearbeiten. Die Befehle sind hier vielfältig.

Bild 14

Executable:

Um Dateien auszuführen oder aber die Malware selbst auszuführen werden unter anderem folgende Befehle genutzt.

Bild15

Imports:

Um weitere Funktionen nachzuladen werden Programm-Bibliotheken nachgeladen. Dies passiert zur Laufzeit. Eine sehr bekannte Funktion ist „GetProcAddress“

Bild 16

Evasion:

Ein interessanter Fund ist „ClearEventLog“ und „OpenEventLog“. Damit wäre es möglich die Analyse zu erschweren, indem das EventLog komplett gelöscht wird.

Bild 17

Spreading:

Interessant ist auch der Eintrag „CreateMailSlot“. Dies bezeichnet eine SMB-Funktion „Mailslot“ in die mehrere Computer schreiben dürfen. Damit könnte die Malware sich u.U. verbreiten.

Bild18

Crypto:

Natürlich benötigt Ransomware auch die Möglichkeit Dateien zu verschlüsseln. Da wir bereits wissen, dass wir es mit Ransomware zu tun haben, verwundert der String „CryptSignHash“ nicht sonderlich und wird vermutlich tatsächlich auch genutzt.

Bild19

• d) Imports

Imports sind Dateien bzw. Bibliotheken, die während der Laufzeit von der entsprechenden Executable geladen werden. Bekannte Bibliotheken sind bspw. Kernel32.dll oder user32.dll.
Die Imports können ein weiterer Indikator für gepackten Code sein. Selbst kleinste Programme nutzen oft mehrere Imports für kleinste Operationen. Nutzt also Malware nur 1-2 oder gar keine Imports ist dies sehr verdächtig.

Ein Hintergrund dabei ist, dass nahezu jeder Antivirus sich im System verankert und eben das Aufrufen bzw. Laden dieser Imports kontrolliert. Sowohl zur Laufzeit als auch beim Scannen der Datei selbst. Sind hier keiner der „gefährlichen“ Imports zu sehen, sinkt das Risiko, dass die Datei vom AV abgefangen wird.

Imports können über mehrere Möglichkeiten geladen werden. Werden Bibliotheken importiert, nutzen Malware-Autoren hier oft die Möglichkeit „Ordinals“ zu nutzen. Dabei werden keine Namen benötigt, sondern nur eine Art ID. Dies erschwert es dem Analysten umso mehr die Malware zu verstehen.

In diesem Fall haben wir es mit wenigen Imports zu tun:

Bild20

Interessant ist hier die „nddeapi.dll“ die auf Netzwerkaktivität hindeutet, sowie die „shell32.dll“

• e) Ressources

Die Ressources-Section einer Datei wird normalerweise genutzt, um bestimmten Code, Dateien oder sonstiges mit der Datei mitzuliefern. Dabei kann es sich hier um Programm-Icons, ein paar Codezeilen oder um ganze Programme handeln.

In diesem Fall haben wir es mit 3 Sektionen („SERT“) zu tun, die nicht dem Standard folgen und mit über 80% der File-Ratio den Großteil des Programmcodes enthalten. Mitunter ein weiterer Indikator für gepackten Code.

Bild21

• f) Header

File Header, NT-Header usw. Geben ein Überblick über die Datei selbst. Hier werden normalerweise die Prozessor-Achitektur, Timestamp, Ressource-Tables und weitere Informationen festgehalten. Auch diese sind leider nicht immer eindeutig und viele dieser Informationen können entweder manipuliert oder gelöscht werden.

In diesem Fall sehen wir hier keine weiteren interessanten Informationen. Die Checksum wurde auf 0 gesetzt und Debug-Strings entfernt. Beides typisch für Malware. Außerdem gibt es „invalid“ Einträge, Timestamps von 2009 und andere auffällige Einträge.

Bild22

• g) Sonstiges

Je nach Malware gibt es noch weitere Indikatoren die Informationen preisgeben könnten. Bsp. Ist die „Virtual Size“ und „Raw Size“ oftmals ein Indikator für gepackten Code. Ist der Code auf der Festplatte wesentlich größer oder kleiner als während der Ausführung, bedeutet dies, dass der Code entpackt wurde oder zumindest vor Ausführung angepasst wird. Kleine Abweichungen sind hier normal, größere sind ein Indiz.

Des Weiteren verstecken Autoren gerne Strings, Keys oder sonstiges in ungewöhnlichen Positionen bspw. Dem Attribut „Author“ der File-Properties, die dann während der Ausführung ausgelesen werden. Eine weitere bekannte Möglichkeit ist EXIF-Info, Info im PE-Header oder bspw. Die Ressource-Section der Datei selbst. Die Möglichkeiten sind hier vielfältig und müssen alle in Betracht gezogen werden, um ein möglichst vollständiges Bild zu erhalten.

Bild23

Vorläufiges Fazit:

Auch wenn es weitere Indikatoren gibt, ist es oftmals nicht allzu sinnvoll, zu viel Zeit in die statische Analyse zu investieren. Wir können zusammenfassen, dass wir es definitiv mit Ransomware zu tun haben, die Registry und Dateien bearbeiten kann, logischerweise Verschlüsselungsfunktionen nutzt, eventuell versucht die EventLogs zu löschen und vermutlich gepackt ist.

Im nächsten Teil dieses Blogs widmen wir uns dann der dynamischen Analyse. D.h. wir führen die Malware aus und behalten dabei das System im Auge und untersuchen es auf API-Calls, Registry-Operations usw.