ZERLEGUNG VON BLACKENERGY, TEIL 2 – „DAS ZEICHEN“

Ich werde keine Rede darüber halten, was ein BlackEnergy-Framework ist, da darüber bereits viel geschrieben wurde, auch ohne mich. Trotzdem möchte ich auf Informationen aus dieser speziellen Rezension:

Darf ich vorstellen, der Flashplayer!

Bei der Untersuchung des Angriffs auf unsere Infrastruktur haben wir verschiedene Malware-Beispiele entdeckt, darunter Flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)Kurz gesagt, extrahiert flashplayerapp main_light.dll in seinen eigenen Speicherbereich und überträgt die Kontrolle an ihn. Diese Bibliothek ist eine Light-Version von BlackEnergy und wird für die C&C-Kommunikation verwendet, um die Hauptnutzlast herunterzuladen, deren Funktionalität von den Zielen des Angreifers abhängt. Es erstellt eine Datei: C:UsersuserAppdataAdobecache.datWährend verschlüsselt enthält diese Datei verschiedene Informationen, einschließlich der Build-Version (wie 2015lstb), der Adresse des Command-and-Control-Zentrums, von dem aus verschiedene Nutzdaten abgerufen werden können (wie hxxps://188.40.8.72/l7vogLG/BVZ99/rt170v/solocVI/eegL7p.php) usw. Während ich dieses Sample untersuchte, verlegte ich den Fokus vom C&C, da ein bestimmter Teil des Codes meine Aufmerksamkeit erregte, da er offensichtlich ein Zeichen für die Verwendung einer Technik namens Code-Permutation war. Lassen Sie mich ein Zitat aus dieser Quelle übersetzen http://hacks.clan.su/publ/11-1-0-481:

So sah der Codeausschnitt aus (die von der Permutations-Engine hinzugefügten Instruktionen sind in Rot hervorgehoben und beeinflussen die Funktionalität überhaupt nicht, sie machen den Code nur schwerer verständlich):Durch das Entfernen der unnötigen Zeichenfolgen erhalten wir einen Mechanismus, der alle Funktionsnamen in kernel32.dll verarbeitetindem er ihre (Namen) in eine Art Hash verwandelt, den er später mit einem Wert vergleicht:Lassen Sie uns diesen Mechanismus mit C als Beispiel rekonstruieren. Als Ergebnis erhalten wir ein Werkzeug, das für uns ein „Wörterbuch“ erstellen kann, das Namen aller Funktionen in der kernel32.dll-Bibliothek und die Hash-Werte dieser Namen enthält. Lassen Sie uns versuchen, die Hash-Werte, die wir während der Code-Rückanalyse erhalten haben, in unserem neuen „Wörterbuch“ zu suchen. Zuerst suchen wir den Wert aus dem EAX-Register (0x5147F60F) und vergleichen ihn dann mit dem Referenzwert:Unsere Theorie funktioniert: unser Beispiel hat den Namen der ersten Funktion verarbeitet, den Hash erstellt und vergleicht ihn jetzt mit dem Referenzwert, der im Puffer enthalten ist (0xC8AC8026). Wir suchen diesen Wert und siehe da… wir erhalten die Funktion LoadLibraryA!Um ein weiteres Textbeispiel zu überspringen, möchte ich nur erwähnen, dass unser „Beispiel“ die gleiche Vorgehensweise verwendet, um nach einer anderen Funktion namens GetProcAdress zu suchen.Durch die Verwendung dieser beiden Funktionen kann unser „Beispiel“ andere Bibliotheken laden und die Adressen der Funktionen extrahieren, die es benötigt.

Die Spuren, die die Engine hinterließ

Die Technik, die statische Codeanalyse durch einen Funktionsaufruf basierend auf einem Hashwert anstatt auf ihrem Namen zu erschweren, ist nicht neu. Dennoch führte sie mich zu folgendem Gedanken: trotz wie der bösartige Code verarbeitet wird, kennen wir den Algorithmus der Funktionsnamen-Hashings und können daher mit Zuversicht nach diesen beiden Funktionen (LoadLibraryA und GetProcAdress) im Code suchen. Daher begann ich im Internet nach Erwähnungen dieses Hashes (0xC8AC8026) zu suchen, um zu sehen, ob jemand zuvor die gleiche Engine aus unserem Beispiel verwendet hat, und zu meiner Überraschung fand ich etwas:Dieser Hash wird erstmals im Jahr 2006 erwähnt (der Artikel ist nur bei archive.org zu finden): https://web.archive.org/web/20060614030412/http://osix.net/modules/article/?id=789

Später, im Jahr 2008, taucht ein potenzieller Autor des Algorithmus in einem Forum auf:https://exelab.ru/f/index.php?action=vthread&forum=6&topic=11845

Danach wird im Jahr 2009 ein Analyseartikel über Shellcode MS08-067 auf blogs.technet.com veröffentlicht: http://blogs.technet.com/b/srd/archive/2009/06/05/shellcode-analysis-via-msec-debugger-extensions.aspx

Dann im Jahr 2013 veröffentlicht das „XAKEP“-Magazin (eines der größten russischen Medien über IT und Informationssicherheit) einen Artikel https://xakep.ru/2011/06/23/55780/ wo sie denselben Algorithmus erwähnen, der denselben Hash erzeugt (!):Moment mal, die Situation, die wir hier haben, besteht darin, dass derselbe Algorithmus, der dieselben Hash-Werte erzeugt, seit mehr als 10 Jahren in Verwendung ist und noch niemand hat das bemerkt? Sollte es anders sein, dann wäre es für die flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/) unmöglich, so unbemerkt zu bleiben, wie sie jetzt scheint, wären da nicht die Antivirus-Lösungen, die wir im Jahr 2016 bereits haben:Es gibt eine deutliche „Markierung“, die von dieser konkreten Permutations-Engine hinterlassen wurde, die in unserem analysierten Beispiel verwendet wurde und es sieht für mich wie eine gültige Signatur aus. Außerdem lässt sie sich recht einfach direkt im Klartext verfolgen:Nun, wir haben unsere Annahmen und die Theorie ist gefestigt, also lassen Sie uns zur Praxis übergehen und versuchen, unsere Schlussfolgerungen in eine Yara-Signatur / Regel zu übertragen:

rule API_Hash

{meta: description = „Hash of LoadLibrary that is {26 80 ac c8} und GetProcAddres {ee ea c0 1f}“

strings:

$a = {26 80 ac c8}

$b = {ee ea c0 1f}

condition: $a and $b

}

Das Einzige, was jetzt noch zu tun ist, ist, sie gegen mehrere verschiedene Samples (zum Beispiel eines Antivirus-Labors) zu testen, um genau herauszufinden, wie viel bösartiger Code wirklich von dieser Engine gepackt wurde?
An diesem Punkt kann ich nur feststellen, dass es mir möglich war, das Experiment an einer sehr kleinen Anzahl von Samples in einem der Antivirus-Unternehmen durchzuführen, und die Ergebnisse sind es wert! Unter den gefangenen Samples haben wir:Win32/Spy.Bebloh (Banking-Trojaner) — http://www.virusradar.com/en/Win32_Spy.Bebloh/detailWin32/PSW.Fareit (Trojaner zum Stehlen von Passwörtern) — http://www.virusradar.com/en/Win32_PSW.Fareit/detailWin32/Rustock (Backdoor) — http://www.virusradar.com/en/Win32_Rustock/detailWin32/TrojanDownloader.Carberp (Dropper, der den Banking-Trojaner Carberp installiert) — http://www.virusradar.com/en/Win32_TrojanDownloader.Carberp/detailWin32/Kelihos (Spam-Sender) — http://www.virusradar.com/en/Win32_Kelihos/detailDiese Liste enthält nur bekannte Familien. Diese beiden Hash-Werte tauchen auch in anderen Malware-Familien auf, einschließlich Ransomware / Dateiverschlüsslern (Win32/Filecoder.HydraCrypt), einem Bitcoin-Miner (CoinMiner.LC), einem WinLocker (LockScreen.AQT) und anderen.

Bisher kann ich auch hinzufügen, dass diese ziemlich einfach aussehende Yara-Regel bisher zu keinem einzigen Fehlalarm geführt hat, aber der Test wurde nur auf ein paar Dutzend Computern durchgeführt. Daher hoffe ich wirklich stark, dass nach der Veröffentlichung dieser Forschung, Sie (!) und diejenigen, die bis hierher gelesen haben, ihr Feedback geben werden, das groß genug sein wird, um die Präzision dieser Regel zu beweisen oder zu widerlegen! Natürlich ist es mit nur acht Bytes für eine Signatur außerordentlich klein und die Regel wird sehr wahrscheinlich einige „echte“ Dateien fangen. Dennoch kann diese leichte Yara-Regel in einer Sandbox als Teil einer komplexeren Analyselogik bestehen.

Schlussfolgerungen

Ziel dieses Artikels ist nicht das Reverse Engineering der BlackEnergy-Malware, sondern ich möchte vielmehr darauf hinweisen, dass Tools, die beim Zusammenbau eines Malware-Codes verwendet werden, ihre Spuren hinterlassen und nützliche Indikatoren zur Verteidigung erzeugen können. Und diese Indikatoren können für eine ziemlich lange Zeit unbemerkt bleiben…

Übersetzt aus dem Original von Andrii Bezverkhyi | CEO SOC Prime