Hallo allerseits! In Erwartung des Starts eines neuen Streams im
Reverse Engineering- Kurs teilen
wir Ihnen eine Übersetzung eines sehr interessanten Materials mit. Viel Spaß beim Lesen
Die letzten zwei Jahre können als Jahre der Ransomware-Hacker bezeichnet werden. Ransomware war ohne Zweifel die beliebteste Art von Malware. Ende der letzten Jahre stellten wir jedoch einen Rückgang der Popularität und eine Zunahme zugunsten der Bergleute fest. Es ist möglich, dass dieser Trend 2018 nur noch zunehmen wird.
Aus Sicht des Opfers ist dies eine Erleichterung, da Bergleute nicht so gefährlich sind wie Ransomware. Ja, sie verlangsamen das System, aber sobald Sie sie entfernen, können Sie Ihren Computer wie bisher weiter verwenden. Ihre Daten werden nicht gestohlen oder gehen verloren, wie dies beim Ransomware-Virus der Fall ist.
Aus der Sicht eines Malware-Forschers sind Bergleute enttäuschend. Sie bieten nicht genügend neues Material für eine eingehendere Analyse, hauptsächlich weil sie auf bekannten Open-Source-Komponenten basieren, die wenig oder gar keine Verwirrung oder Verstohlenheit aufweisen.
Von Zeit zu Zeit finden wir jedoch Bergleute, die interessante Tricks anwenden. Wir haben kürzlich eine Technik namens „Heaven's Gate“ gesehen, die Injektionen von 32-Bit-Bootloadern in 64-Bit-Prozesse ermöglicht. Diese Idee ist nicht neu, ihre erste Implementierung stammt aus dem Jahr 2009, aber es ist interessant zu sehen, wie sie in einer neuen Form implementiert wurde, die direkt "aus der Wildnis" erhalten wurde.
Anfänger in der Virenanalyse können eine Anleitung lesen, was Heaven's Gate ist und wie man sich seiner Analyse nähert.
Materialien für die Analyse
Dieses Muster wurde in der Fortsetzung der
Ngay- Kampagne gefunden (mehr dazu
hier ). Das Überprüfen der Biografie solcher Proben führte mich zu dem
Artikel @_qaz_qaz , der eine frühere Kampagne mit einer ähnlichen Probe beschreibt. Seine Analyse umfasste jedoch nicht die Heaven's Gate-Technologie.
Verhaltensanalyse
Um die erwähnte Injektion zu sehen, müssen wir das Beispiel auf einem 64-Bit-System ausführen. Wir sehen, dass es die Essenz des Notebooks mit den für Cryptocurrency Mining spezifischen Parametern startet:
Wenn wir uns die Zeilen im Speicher von ProcessExplorer ansehen, sehen wir, dass dies kein echtes Notizbuch ist, sondern der
XMRig Monero
Miner .
Im Moment sind wir also sicher, dass das Image des Notebooks im Speicher höchstwahrscheinlich durch die RunPE-Methode (Process Hollowing) ersetzt wurde.
Der Haupttropfer ist 32-Bit, verschiebt jedoch die Nutzlast auf ein 64-Bit-Notebook:
Interessanterweise wird diese Art der Injektion von der offiziellen Windows-API nicht unterstützt. Wir können aus einer 64-Bit-Anwendung (unter Verwendung der WoW64-API) in den Speicher von 32-Bit-Prozessen lesen / schreiben, aber nicht umgekehrt.
Es gibt jedoch einige inoffizielle Lösungen, beispielsweise eine Technik namens „Himmelstor“.
Heaven's Gate Review
Die Heaven's Gate-Technik wurde erstmals 2009 von einem Hacker mit dem Spitznamen Roy G. Biv beschrieben. Später wurden viele Implementierungen erstellt, beispielsweise die
Wow64ext- Bibliothek oder basierend darauf
W64oWoW64 . In seinem Blog im Jahr 2015 beschrieb Alex Ionescu
Maßnahmen zur Bekämpfung dieser Technik .
Schauen wir uns an, wie es funktioniert.
Ausführen von 32-Bit-Prozessen unter 64-Bit-Windows
Jeder 32-Bit-Prozess, der unter einer 64-Bit-Version von Windows ausgeführt wird, wird auf einem speziellen
WoW64- Subsystem ausgeführt, das eine 32-Bit-Umgebung emuliert. Sie können eine Analogie mit einer 32-Bit-Sandbox ziehen, die in einem 64-Bit-Prozess erstellt wird. Zunächst wird eine 64-Bit-Prozessumgebung erstellt. Und bereits darin wird eine 32-Bit-Umgebung erstellt. Die Anwendung wird in dieser 32-Bit-Umgebung ausgeführt, hat jedoch keinen Zugriff auf ihren 64-Bit-Teil.
Wenn wir einen 32-Bit-Prozess von außen mit einem 64-Bit-Scanner scannen, werden wir feststellen, dass im Inneren sowohl 32- als auch 64-Bit-DLLs vorhanden sind. Am wichtigsten ist, dass es zwei Versionen von NTDLL gibt: 32-Bit (aus dem SysWow64-Verzeichnis geladen) und 64-Bit (aus dem System32-Verzeichnis geladen):
Der 32-Bit-Prozess selbst sieht den 64-Bit-Teil jedoch nicht und ist auf die Verwendung von 32-Bit-DLLs beschränkt. Um in einen 64-Bit-Prozess zu injizieren, müssen Sie die 64-Bit-Versionen der entsprechenden Funktionen verwenden.
Codesegmente
Um Zugang zu dem eingeschränkten Teil der Umgebung zu erhalten, müssen wir verstehen, wie Isolation durchgeführt wird. Es stellt sich heraus, dass alles ziemlich einfach ist. Die 32-Bit- und 64-Bit-Codeausführung ist über eine andere Codesegmentadresse verfügbar: 32-Bit - 0x23 und 64-Bit - 0x33.
Wenn wir die Adresse wie gewohnt aufrufen, ist standardmäßig der Modus festgelegt, in dem sie interpretiert wird. Wir können jedoch explizit eine Änderung mithilfe des Assemblycodes anfordern.
Im Bergmann: Heaven's Gate-Implementierung
Ich werde keine vollständige Analyse dieses Bergmanns durchführen, wie es hier bereits beschrieben
wurde . Gehen wir direkt zu dem Ort, an dem der Spaß beginnt. Das Schadprogramm überprüft seine Umgebung. Wenn es feststellt, dass es auf einem 64-Bit-System ausgeführt wird, verwendet es eine andere Methode zum Injizieren in den 64-Bit-Prozess:
Nach einigen Anti-Analyse-Überprüfungen wird ein neuer, angehaltener 64-Bit-Prozess erstellt (in diesem Fall ein Notizblock):
Dies ist das Ziel, in dem die böswillige Last implementiert wird.
Wie wir zuvor erfahren haben, müssen wir die entsprechenden 64-Bit-Funktionen verwenden, um die Nutzdaten in einen 64-Bit-Prozess einzubetten.
Zunächst besteht der Bootloader die 64-Bit-NTDLL-Verarbeitung:
Was in der Funktion
get_ntdll passiert, bedarf einer detaillierteren Erläuterung. Zur Erklärung können wir uns auch einen ähnlichen
Code in der ReWolf-Bibliothek ansehen.
Um auf den 64-Bit-Teil der Prozessumgebung zugreifen zu können, müssen wir mit Segmentselektoren arbeiten. Mal sehen, wie die Malware in den 64-Bit-Modus wechselt.
Es scheint, dass dieser Code direkt aus der geöffneten Bibliothek kopiert wurde:
https://github.com/rwfpl/rewolf-wow64ext/blob/master/src/internal.h#L26Der Segmentwähler 0x33 wird auf den Stapel geschoben. Dann ruft die Malware die folgende Zeile auf: (Auf diese Weise wird auch die Adresse der nächsten Zeile auf den Stapel verschoben.)
Die Adresse,
retf Stapel
retf wird durch Hinzufügen von 5 Bytes festgelegt und nach
retf :
Am Ende wird die RETF-Anweisung aufgerufen. RETF ist "Far Return" und ermöglicht es Ihnen, im Gegensatz zu regulärem RET nicht nur die Adresse anzugeben, von der aus Sie die Ausführung fortsetzen möchten, sondern auch ein Segment. Als Argumente werden zwei DWORDs vom Stapel genommen. Wenn also RETF ausgeführt wird, wird die Rücksendeadresse:
0x33: 0x402A50Dank des geänderten Segments wird Code, der an der angegebenen Adresse beginnt, als 64-Bit interpretiert. Der Code, den der Debugger sieht, ist also 32-Bit ...
... eigentlich 64-Bit.
Um schnell die Ansicht zu wechseln, verwende ich die PE-Bärenfunktion:
Und so sieht dieser Code aus, wenn er als 64-Bit interpretiert wird:
Somit ist der hier ausgeführte Code dafür verantwortlich, den Inhalt des Registers R12 in eine Variable auf dem Stapel zu verschieben und dann zurück in den 32-Bit-Modus zu wechseln. Dies geschieht, um den 64-Bit-
Thread-Informationsblock (TEB) zu erhalten , von dem wir hier den 64-Bit-
Prozessumgebungsblock (PEB) erhalten - wir sehen uns einen
ähnlichen Code an .
Ein 64-Bit-PEB wird als Ausgangspunkt für die Suche nach einer 64-Bit-Version von NTDLL verwendet. Dieser Teil ist recht
trivial implementiert (eine Vanille-Implementierung dieser Methode finden Sie
hier ) und verwendet einen Zeiger auf die geladenen Bibliotheken, die eines der Felder in der PEB-Struktur sind. Von PEB erhalten wir also ein Feld namens
Ldr :
Ldr ist eine Struktur vom Typ
_PEB_LDR_DATA . Es enthält einen Eintrag namens
InMemoryOrderModuleList :
Diese Liste enthält alle geladenen Bibliotheken, die im Speicher des untersuchten Prozesses vorhanden sind. Wir durchsuchen die Liste, bis wir die Bibliothek finden, an der wir interessiert sind, in unserem Fall NTDLL. Genau das macht die obige Funktion
get_ntdll . Um einen geeigneten Namen zu finden, ruft es die folgende Funktion auf, die als
is_ntdll_lib und den Bibliotheksnamen anhand des Zeichens mit ntdll.dll vergleicht. Das Äquivalent
dieses Codes stellt sich heraus.
Wenn die Namen übereinstimmen, wird die Bibliotheksadresse an einige Register zurückgegeben:
Sobald wir NTDLL gefunden haben, müssen wir nur noch die Adressen der entsprechenden Funktionen abrufen. Wir können dies tun, indem wir uns die Exporttabelle der Bibliothek ansehen:
Folgende Funktionen werden abgerufen:
- NttUnmapViewOfSection
- NtGetContextThread
- NtAllocateVirtualMemory
- NtReadVirtualMemory
- NtWriteVirtualMemory
- NtSetContextThread.
Wie wir wissen, sind diese Funktionen typisch für die RunPE-Technik. Zunächst wird NtUnmapViewOfSection verwendet, um die Zuordnung der ursprünglichen PE-Datei aufzuheben. Dann wird im Remote-Prozess Speicher zugewiesen und ein neues PE geschrieben. Am Ende wird der Prozesskontext so geändert, dass die Ausführung vom eingebetteten Modul aus beginnt.
Funktionsadressen werden gespeichert und später aufgerufen (ähnlich wie in
diesem Code), um den Remote-Prozess zu steuern.
Fazit
Bisher haben die Autoren von Bergleuten nicht viel Kreativität gezeigt. Sie erreichen ihre Ziele, indem sie sich auf Open Source-Komponenten verlassen. Der beschriebene Fall spiegelt diesen Trend gut wider, da eine vorgefertigte Implementierung verwendet wurde.
Das Himmelstor gibt es schon seit mehreren Jahren. Einige Schadprogramme verwenden es, um die
Tarnung zu erhöhen. Bei diesem Miner wollten die Autoren wahrscheinlich eher die Leistung maximieren, indem sie die Nutzlast verwendeten, die am besten zur Zielarchitektur passt.
Das ist alles. Mehr über unseren Kurs erfahren Sie
hier .