Angreifer kompilieren Open-Source-Software wie den 7zip-SFX-Stub neu, um darin einen Reflective Loader einzuschleusen. Eine solche Modifikation von Open-Source-Code kann von Analysten leicht übersehen werden. Um zu verstehen, warum das so ist, müssen wir uns zunächst ansehen, wie 7zip SFX grundsätzlich funktioniert und wie der Loader darin versteckt wird.
Über OpenSUpdater hat Google bereits 2021 berichtet, weil die Malware "die Zerttifikats-Berarbeitung manipulierte, um einer Erkennung zu entgehen". Aktuelle Samples, die von ESET als OpenSUpdater oder von Microsoft als Snackarcin erkannt werden, nutzen noch raffiniertere Methoden zur Umgehung von Erkennung.
7zip SFX verstehen
SFX steht für „self-extracting archive“, also selbstextrahierendes Archiv. Mit 7zip SFX können Entwickler einfache Installer erstellen.
7zip verfügt über sogenannte „SFX-Module“, wobei dieser Begriff im Kontext des Reverse Engineerings etwas missverständlich sein kann. Eine treffendere Bezeichnung wäre „Dekompressions-Stub“.
In einem 7zip-SFX befinden sich die eingebetteten Dateien in einem Archivformat im Overlay. Aufgabe des Moduls ist es, dieses Archiv zu dekomprimieren, die Dateien daraus zu extrahieren, auf die Festplatte zu schreiben und eine davon auszuführen.
7zip stellt verschiedene Dekompressions-Stubs beziehungsweise Module für unterschiedliche Funktionen bereit. Möchte ein Entwickler während der Extraktion beispielsweise eine grafische Benutzeroberfläche anzeigen, benötigt 7zip ein anderes SFX-Modul als bei einer Kommandozeilenoberfläche. Darüber hinaus existieren auch Module von Drittanbietern, etwa das SFX-Modul von Oleg Scherbakov, die zusätzliche Möglichkeiten zur Anpassung bieten.
Doch woher weiß der SFX-Stub, welcher Text während der Installation angezeigt werden soll und welche Datei beziehungsweise Dateien ausgeführt werden sollen? Diese Informationen werden in einer Klartext-Konfiguration gespeichert, die an den SFX-Stub angehängt ist. Der Stub sucht nach einer Start- und einer Endmarkierung, um diese Konfiguration auszulesen. Bei einer einfachen grafischen Oberfläche lassen sich dort unter anderem der Fenstertitel, eine Nachricht sowie über den Schlüssel „RunProgram“ ein auszuführender Befehl festlegen. Normalerweise wird damit die Entry-Point-Datei gestartet, es kann jedoch auch jedes andere Programm auf dem System ausgeführt werden. Abbildung 1 zeigt beispielsweise eine Konfiguration mit „setup.exe“ als Entry-Point-Datei.
Für Malware-Analysten ist diese Entry-Point-Datei besonders interessant, da sie zu den ersten Stellen gehört, an denen nach potenziell schädlichem Code gesucht wird.
OpenSUpdater’s installer
Bei den OpenSUpdater-Samples [1] und [2] handelt es sich um selbstextrahierende 7zip-Archive, die einen foobar2000-Installer mit dem Namen setup.exe enthalten. Sie sind gültig von Animated Productions, LLC signiert. Laut der Website des Unternehmens, die den Eindruck erweckt, mit einem LLM erstellt worden zu sein, entwickelt es Spiele-Apps.
Der foobar2000-Installer ist echt, allerdings ergibt es wenig Sinn, dass ein Spieleentwickler diesen veröffentlicht. Das sollte bereits ein Hinweis darauf sein, dass etwas nicht stimmt. Hinzu kommt, dass die Versionsinformationen offenbar aus zufälligen Wörtern bestehen, die aus einem Wörterbuch ausgewählt wurden (siehe Abbildung 2).
Das Zertifikat selbst wurde mit zwei Bytes aufgebläht: 0xB8 und 0x84, die zufällig wiederholt werden. Dennoch macht das Zertifikat lediglich 2,6 Prozent der gesamten Datei aus. Viele Angreifer blähen Dateien künstlich auf, um Uploads auf Plattformen wie Virustotal.com oder in Analyse-Sandboxes wie Any.Run zu verhindern. In diesem Fall erklärt das jedoch nicht, warum überhaupt ein solches Padding vorhanden ist. Möglicherweise handelt es sich um eine Form von binärem Padding, durch die sich der Hash jedes Builds verändert, ohne die Gültigkeit der Signatur zu beeinträchtigen.
Zusammengefasst zeigt bereits die Triage deutliche Hinweise darauf, dass etwas nicht stimmt. Den eigentlichen Loader-Code zu finden, um diesen Verdacht zu bestätigen, kann jedoch schwierig sein.
Versteckter Loader
Wenn ein Malware-Analyst einen verdächtigen 7zip-SFX-Installer untersucht, liegen die wichtigsten Schwerpunkte normalerweise auf der Konfiguration und den eingebetteten Dateien. Gibt es viele eingebettete Dateien, wird in der Regel zuerst die Entry-Point-Datei untersucht, die über die Konfiguration ausgeführt wird. Der Dekompressions-Stub enthält üblicherweise lediglich eines der standardmäßigen SFX-Module und wird bei der Suche nach potenziell schädlichem Code daher häufig übersprungen. Dadurch kann ein modifiziertes SFX-Modul leicht unentdeckt bleiben.
Selbst wenn ein Analyst das SFX-Modul untersucht, wird er wahrscheinlich zunächst den Entry Point, den Hauptcode und alles prüfen, was bei der Triage auffällt, beispielsweise Strings oder Imports, die dort nicht hingehören sollten. Auf den ersten Blick sieht jedoch auch all das wie der originale SFX-Stub aus.
Die Stelle im 7zip-SFX-Code, an der der Loader ausgeführt wird, ist mitten in der Software versteckt, unmittelbar bevor der Fortschrittsbalken in ExtractArchive (0x421400 in Sample [1]) initialisiert wird. Diese Funktion befindet sich in der Quelldatei CPP/7zip/Bundles/SFXSetup/ExtractEngine.cpp. Dort einen Aufruf des Loaders einzufügen, ist eindeutig untypisch und stellt klar einen Versuch dar, die Analyse zu erschweren.
Funktionalität des OpenSUpdater-Loaders
Der Loader besteht grob aus einem Beacon-Handler, einem Downloader und einem Payload-Loader.
Der Beacon-Handler ermittelt die C2-URL über eine obfuskierte Funktion. Anschließend registriert er sich mit einer speziellen Byte-Sequenz beim C2-Server, die möglicherweise als Identifikationsmechanismus dient.
Der Downloader nutzt statisch einkompilierte Funktionen der curl-Bibliothek, um zwei DLLs und einen verschlüsselten Blob vom C2-Server herunterzuladen.
Der Reflective Loader ruft zunächst den Export cx1 von DLL1 und anschließend cx2 von DLL2 auf, um den verschlüsselten Blob zu entschlüsseln. Bei dem entschlüsselten Blob handelt es sich wiederum um eine DLL, die der Reflective Loader in den Arbeitsspeicher abbildet. Abschließend ruft er deren Export cx3 auf. Dabei handelt es sich höchstwahrscheinlich um die Payload. Zum Zeitpunkt der Analyse konnte ich keine DLLs vom Server beziehen.
OpenSUpdater-Varianten missbrauchen Open-Source-Bibliotheken
Das Neukompilieren des 7zip-SFX-Stubs ist nur eine der Varianten, auf die wir gestoßen sind. Andere Installer, etwa Sample [3], missbrauchen Open-Source-Softwarebibliotheken wie das NSIS-Plugin EmbedHtml. Dort dient die Funktion EmbedHtml::GetUrl() als Einfügepunkt für den Loader, wobei der schädliche Code nur dann ausgelöst wird, wenn die Funktion mit einem leeren String aufgerufen wird.
Der Loader-Code liest anschließend die URL des C2-Servers aus einem komprimierten Blob im NSIS-Skript aus und kontaktiert danach den C2-Server, um die Payload anzufordern.
All diese Varianten haben eines gemeinsam: Ein Reflective Loader versteckt sich in neu kompilierter Open-Source-Software, sie verfügen über ein aufgeblähtes, aber gültig signiertes Zertifikat und betten einen echten Installer einer kostenlosen Anwendung in einen weiteren Installer wie NSIS oder 7zip SFX ein.
Malware-Analyse war schon immer eine Disziplin, bei der es darum geht, die Nadel im Heuhaufen zu finden, insbesondere bei Software, die auf den ersten Blick sauber erscheint. Der einzige Rat, den ich Analysten geben kann, lautet daher: Bleiben Sie hartnäckig und versuchen Sie herauszufinden, was nicht stimmt, wenn verdächtige Hinweise wie ein Installer in einem Installer oder ein aufgeblähtes Zertifikat auftauchen. Ziehen Sie außerdem in Betracht, auch an ungewöhnlichen Stellen nach Malware-Code zu suchen.
Sample hashes
[1] a7666e5aa3c6ecae0295caa7c3f49714eb561d6e1be6807cf1020b79f1902cd0
[2] e99a053b9d6a414256177e1529417f85867d6ed355f6009300d626f63429753c
[3] ba38916e82c47cff6de71791f179ce762e640e2975e40d6a1803d16ff591b752
C2 URLs
[4] hxxps://codeonicinc(dot)com (sample [1] and [2])
[5] hxxps://setupsoftwarecenter(dot)com (sample [3])
