octoberfest7/beatrevPOC zur Frustration/Besiegung von Malware-Analysten
Die folgende Arbeit ist ein POC, um Malware in die Lage zu versetzen, sich selbst an ein bestimmtes Opfer zu „binden“, um die Bemühungen von Malware-Analysten zu erschweren.
Ich übernehme keine Verantwortung für die böswillige Nutzung von Ideen oder Code, die in diesem Projekt enthalten sind. Ich stelle diese Forschung zur Verfügung, um Infosec-Experten weiterzubilden und Malware-Analysten, Reverse Engineers und Blue Teamern zusätzliche Schulungen/Denkanstöße zu bieten.
Beim ersten Ausführen der Malware auf einem Opfer verschlüsselt sie die eigentliche Nutzlast (ein RDLL) mit AES unter Verwendung von Umgebungsdaten dieses Opfers. Bei jeder weiteren Ausführung sammelt die Malware dieselben Umgebungsinformationen, entschlüsselt die als Byte-Array in der Malware gespeicherte Nutzlast mit AES und führt sie aus. Wenn die Entschlüsselung fehlschlägt / die Nutzlast nicht ausgeführt werden kann, löscht sich die Malware selbst. Schutz vor Reverse Engineers und Malware-Analysten.
Ich hatte das Gefühl, mit diesem Projekt noch nicht fertig zu sein, also bin ich zurückgegangen und habe eine ziemlich umfangreiche Neufassung vorgenommen. Die ursprüngliche Forschung und Tradecraft finden Sie hier.
Die wesentlichen Änderungen sind wie folgt:
Es gibt einige verschiedene Dinge, die aus dem Quellcode dieses Projekts für die anderweitige Verwendung übernommen werden könnten. Hoffentlich wird es für jemanden nützlich sein.
Es gab einige Mängel in der ursprünglichen Version von BeatRev, die ich zu beheben versuchte.
Stage2 war zuvor ein eigenständiges ausführbares Programm, das als alternativer Datenstrom (ADS) von Stage1 gespeichert wurde. Um die AES-Verschlüsselung durch das Opfer und die anschließende Entschlüsselung und Ausführung zu erreichen, las Stage1 bei jedem Durchlauf den ADS, entschlüsselte ihn, schrieb zurück in den ADS, rief CreateProcess auf und verschlüsselte Stage2 erneut und schrieb es zurück auf die Festplatte im ADS. Dies waren viele I/O-Operationen, und der CreateProcess-Aufruf war natürlich nicht ideal.
Ich stieß zufällig auf Steven Fewers Forschung zu Reflective DLLs und es schien eine gute Lösung zu sein. Stage2 ist nun ein RDLL; unsere Malware/Shellcode-Runner/was auch immer wir schützen wollen, kann in das RDLL-Format portiert werden und als Byte-Array in Stage1 gespeichert werden, das dann zur Laufzeit entschlüsselt und von Stage1 ausgeführt wird. Dadurch werden alle I/O-Operationen und der CreateProcess-Aufruf von Version 1 entfernt, was eine willkommene Änderung ist.
Stage1 hatte keine wirklich programmierten AV-Evasion-Maßnahmen; dies war beabsichtigt, da es zusätzliche Arbeit ist und nicht wirklich der Kern dieser Forschung war. Während der Neufassung habe ich es als zusätzliche Herausforderung gesehen und API-Hashing hinzugefügt, um Funktionen aus der Importadresstabelle von Stage1 zu entfernen. Dies hat bei der Erkennung geholfen, und Stage1 hat eine Erkennungsrate von 4/66 auf VirusTotal. Ich fühlte mich wohl dabei, Stage1 hochzuladen, da es bereits an die ursprüngliche Box gebunden ist, auf der es ausgeführt wurde, und sich die Dateisignatur aufgrund der AES-Verschlüsselung ständig ändert.
Ich habe kürzlich begonnen, auf Entropie als Mittel zur Erkennung von Malware zu achten. Um die ansonsten sehr hohe Entropie zu senken, die ein riesiger AES-verschlüsselter binärer Blob einer ausführbaren Datei verleiht, habe ich mich mit der Integration von Shellcode befasst, der als UUIDs gespeichert ist. Da die Binärdatei in String-Repräsentation gespeichert ist, ist die Gesamtentropie in der ausführbaren Datei geringer. Mit dieser Technik liegt die Entropie von Stage0 jetzt bei etwa 6,8 und die von Stage1 bei etwa 4,5 (auf einer maximalen Skala von 8).
Schließlich ist es eine riesige Aufgabe, ein vollständiges Stage0 zu integrieren und zu produzieren, aufgrund all der Teile, die manipuliert werden müssen. Um dies zu erleichtern, habe ich eine Builder-Anwendung erstellt, die eine Stage0.c-Vorlagendatei, einen Stage1-Stub, einen Stage2-Stub und eine rohe Shellcode-Datei (dies wurde für Stage2 als Shellcode-Runner mit CobaltStrike-Shellcode entwickelt) aufnimmt und eine kompilierte Stage0-Nutzlast für den Einsatz auf dem Ziel erzeugt.
Der Reflective DLL-Code von Stephen Fewer enthält einige Visual Studio-Compilerspezifische Anweisungen; ich bin sicher, dass es möglich ist, die Technik auf MinGW zu portieren, aber ich habe nicht die Fähigkeiten dazu. Das Hauptproblem hier ist, dass der CobaltStrike-Shellcode (stageless ist etwa 265 KB) in das RDLL gehen und kompiliert werden muss. Um dies zu umgehen und es gut in den Rest des Prozesses zu integrieren, habe ich mein Stage2-RDLL so geschrieben, dass es einen globalen Variablenspeicherblock in der Größe des CS-Shellcodes enthält; dieser etwa 265 KB große Speicherblock enthält einen kleinen Platzhalter, der in der kompilierten Binärdatei lokalisiert werden kann. Der Code in src/Stage2 hat dies bereits hinzugefügt.
Sobald dies kompiliert ist, wird dieser Stage2-Stub nach Kali übertragen, wo ein Binary-Patch durchgeführt werden kann, um den echten CS-Shellcode an der Stelle im Speicher zu platzieren, an die er gehört. Dies erzeugt das vollständige Stage2.
Um das zuvor beschriebene I/O- und CreateProcess-Debakel zu vermeiden, muss das vollständige Stage2 auch von Stage0 in das kompilierte Stage1 gepatcht werden; dies ist notwendig, um Stage2 nach dem Einsatz auf dem Ziel zu verschlüsseln und zu verhindern, dass Stage2 separat auf der Festplatte gespeichert wird. Das gleiche Konzept, das zuvor für Stage2 beschrieben wurde, wird von Stage0 auf dem Ziel durchgeführt, um die endgültige Stage1-Nutzlast zusammenzustellen. Es sollte beachtet werden, dass die Funktion memmem verwendet wird, um den Platzhalter in jedem Stub zu lokalisieren; diese Funktion ist unter Windows nicht verfügbar, daher wurde eine benutzerdefinierte Implementierung verwendet. Danke an Foxik384 für seinen Code.
Um einen Binary-Patch durchzuführen, müssen wir den erforderlichen Speicher im Voraus zuweisen; dies hat einen verstärkenden Effekt, da Stage1 nun groß genug sein muss, um auch Stage2 zu enthalten. Mit dem zusätzlichen Schritt der Umwandlung von Stage2 in einen UUID-String bläht Stage2 in der Größe auf, ebenso wie Stage1, um es aufzunehmen. Ein Stage2-RDLL mit einer kompilierten Größe von etwa 290 KB führt zu einer Stage0-Nutzlast von etwa 1,38 MB und einer Stage1-Nutzlast von etwa 700 KB.
Die Builder-Anwendung unterstützt nur die Erstellung von x64-EXE-Dateien. Mit etwas mehr Arbeit könnte man jedoch theoretisch Stage0 und Stage1 zu DLLs machen und den gesamten Lebenszyklus als DLL-Hijack anstelle eines eigenständigen ausführbaren Programms gestalten.
Diese Anleitung bringt Sie auf den Weg zur Nutzung dieses POC.
Vor etwa 6 Monaten wurde mir klar, dass ich zwar viel über Malware in Bezug auf AV/EDR-Evasion gelernt und gemacht hatte, ich aber sehr wenig Zeit damit verbracht hatte, mich mit der Umgehung oder Überwindung von Reverse Engineering/Malware-Analyse zu beschäftigen. Dies hatte einige gute Gründe:
Trotzdem war es ein interessantes Gedankenexperiment, und ich hatte ein paar Kollegen, die sich mit Malware-Analyse auskennen und mit denen ich Ideen austauschen konnte. Es schien eine Herausforderung von ganz anderem Ausmaß im Vergleich zur AV/EDR-Evasion zu sein, und ich beschloss, einen Versuch zu wagen.
Meine anfängliche Prämisse war, dass die Malware beim ersten Ausführen irgendwie an diese Opfermaschine „gebunden“ wird; jeder nachfolgende Versuch, sie auszuführen, würde etwas in der Zielumgebung auswerten und mit einem Wert in der Malware vergleichen. Wenn diese beiden Faktoren übereinstimmen, führt sie wie erwartet aus. Wenn nicht (wie im Fall, dass die Probe in eine Malware-Analysten-Sandbox übertragen wurde), löscht sich die Malware selbst (wobei sie sich wieder stark auf die Arbeit von LloydLabs und seinem delete-self-poc stützt).
Dieser „Schlüssel“ muss etwas „Einzigartiges“ am Opfercomputer sein. Idealerweise ist es eine Kombination aus mehreren Informationen, die dann weiter verschlüsselt werden. Als Beispiel könnten wir den Hostnamen des Computers sowie die installierte RAM-Menge sammeln; diese beiden Werte können dann konkateniert werden (z.B. Client018192MB) und dann mit einer benutzerdefinierten Funktion gehasht werden, um eine Zahl zu erzeugen (z.B. 5343823956).
Es gibt eine Vielzahl von Auswahlmöglichkeiten, welche Informationen gesammelt werden sollen, aber es sollte bedacht werden, welche Werte ein Blue Teamer leicht fälschen kann; eine MAC-Adresse mag zum Beispiel ein attraktiver „einzigartiger“ Identifikator für ein Opfer erscheinen, aber MAC-Adressen können leicht manuell gesetzt werden, damit ein Reverse Engineer seine Sandbox an das ursprüngliche Opfer anpassen kann. Idealerweise sind die ausgewählten und enumerierten Werte solche, die für einen Reverse Engineer schwer in seiner Umgebung zu replizieren sind.
Mit etwas Selbstlöschungsmagie könnte sich die Malware selbst in einen Puffer einlesen, eine Platzhaltervariable lokalisieren und durch diese Zahl ersetzen, sich selbst löschen und dann die modifizierte Malware wieder an denselben Ort auf die Festplatte schreiben. Kombiniert mit einer if/else-Anweisung in Main würde die Malware beim nächsten Ausführen erkennen, dass sie bereits zuvor ausgeführt wurde, und dann erneut den Hostnamen und die RAM-Menge sammeln, um die gehashte Zahl zu erzeugen. Diese würde dann gegen die beim ersten Durchlauf in der Malware gespeicherte Zahl (5343823956) ausgewertet. Wenn sie übereinstimmt (wie im Fall, dass die Malware auf demselben Computer läuft wie ursprünglich), führt sie wie erwartet aus; wenn jedoch ein anderer Wert zurückgegeben wird, ruft sie erneut die Selbstlöschungsfunktion auf, um sich von der Festplatte zu entfernen und den Autor vor dem Malware-Analysten zu schützen.
Dies schien eine gute Idee in der Theorie zu sein, bis ich mit einem Kollegen sprach, der echte Erfahrung in Malware-Analyse und Reverse Engineering hat. Mir wurde gesagt, dass ein Reverse Engineer die bedingte Anweisung in der Malware beobachten könnte (if ValueFromFirstRun != GetHostnameAndRAM()), und da der erwartete Wert auf einer Seite der bedingten Anweisung hartcodiert ist, einfach die Register so modifizieren, dass sie den erwarteten Wert enthalten, wodurch der gesamte Schutzmechanismus vollständig umgangen wird.
Dieses neue Wissen ließ das Gedankenexperiment völlig scheitern, und da ich ohnehin keine Verwendung für eine solche Fähigkeit hatte, stoppte das Projekt für etwa 6 Monate.
Dieses Projekt tauchte in den folgenden 6 Monaten einige Male wieder auf, aber jedes Mal war es nicht mehr als ein flüchtiger Gedanke, da ich keine neuen Kenntnisse über Reverse Engineering/Malware-Analyse erlangt hatte und wieder keine Notwendigkeit für eine solche Fähigkeit bestand. Vor ein paar Tagen kam die Idee wieder auf, und obwohl sich keiner dieser Faktoren wirklich geändert hat, hatte ich wohl etwas mehr Wissen und konnte die Idee diesmal nicht loslassen.
Mit dem zuvor erwähnten Problem der Hartcodierung von Werten entschied ich mich letztendlich für ein mehrstufiges Design. Ich werde sie als Stage0, Stage1 und Stage2 bezeichnen.
Stage0: Einrichtung. Wird bei der Erstinfektion ausgeführt und danach gelöscht.
Stage1: Ausführer. Wird bei jeder nachfolgenden Ausführung der Malware ausgeführt.
Stage2: Nutzlast. Die Malware, die Sie schützen möchten. Startet einen Prozess und injiziert Shellcode, um einen Beacon zurückzuerhalten.
Stage0 ist die frische ausführbare Datei, die vom Angreifer an das Ziel geliefert wird. Sie enthält Stage1 und Stage2 als AES-verschlüsselte Byte-Arrays; dies dient dem Schutz der Malware während des Transports oder falls ein Verteidiger irgendwie eine Kopie von Stage0 in die Hände bekommt (was nicht passieren sollte). Der AES-Key und IV sind in Stage0 enthalten, daher wird dies Stage1 oder Stage2 in der Realität nicht vor einem kompetenten Blue Teamer schützen.
Stage0 führt die folgenden Aktionen aus:
Nach Abschluss dieser Ereignissequenz beendet Stage0 sich selbst. Da es in Schritt 2 von der Festplatte gelöscht wurde und nicht mehr im Speicher läuft, ist Stage0 praktisch verschwunden; Ohne vorherige Kenntnis dieser Technik wird der Rest des Malware-Lebenszyklus um einiges verwirrender sein, als er ohnehin schon ist.
In Schritt 4 werden der Prozessorname und die Microsoft ProductID gesammelt; die ProductID wird aus der Registry abgerufen, und dieser Wert kann manuell geändert werden, was einem Blue Teamer eine einfache Möglichkeit bietet, seine Sandbox an die Zielumgebung anzupassen. Je nachdem, welche Umgebungsinformationen gesammelt werden, kann dies einfacher oder schwieriger werden.
Stage1 wurde von Stage0 abgelegt und existiert an derselben Stelle wie Stage0 (einschließlich des Namens). Stage2 wird als ADS von Stage1 gespeichert. Wenn der Angreifer/Persistenzmechanismus anschließend die Malware ausführt, führt er Stage1 aus.
Stage1 führt die folgenden Aktionen aus:
Beachten Sie, dass Stage2 beendet werden MUSS, damit es überschrieben werden kann; der Selbstlöschungstrick scheint bei Dateien, die bereits ADS sind, nicht zu funktionieren, da die Selbstlöschungstechnik auf dem Umbenennen des primären Datenstroms der ausführbaren Datei beruht. Stage2 sollte idealerweise eine Inject- oder Spawn+Inject-Ausführbare Datei sein.
Es gibt zwei Punkte, an denen Stage1 erkennen könnte, dass es nicht auf demselben Opfer ausgeführt wird, und sich selbst/Stage2 löschen, um den Bedrohungsakteur zu schützen. Der erste ist die Überprüfung des ausführbaren Headers nach der Entschlüsselung von Stage2 unter Verwendung der gesammelten Umgebungsinformationen; theoretisch könnte dieser Schritt von einem Reverse Engineer umgangen werden, aber es ist eine erste gute Prüfung. Der zweite Schutzpunkt ist das Ergebnis des CreateProcess-Aufrufs – wenn er fehlschlägt, weil Stage2 nicht richtig entschlüsselt wurde, wird die Malware ebenfalls gelöscht. Das Ergebnis dieses Aufrufs könnte auch modifiziert werden, um die Löschung durch den Reverse Engineer zu verhindern, dies ändert jedoch nichts an der Tatsache, dass Stage2 verschlüsselt und unzugänglich ist.
Stage2 ist das Herzstück der Malware-Kette; es ist ein vollwertiger Shellcode-Runner/ein Stück Malware selbst. Durch die Verschlüsselung und den Schutz auf diese Weise werden die Aktionen der Endzustands-Malware viel besser verschleiert und vor Reverse Engineers und Malware-Analysten geschützt. Während der Entwicklung verwendete ich einen meiner vorhandenen Shellcode-Runner mit CobaltStrike-Shellcode, aber dies könnte alles sein, was der Angreifer ausführen und schützen möchte.
Was wird also mit einem solchen Malware-Lebenszyklus tatsächlich erreicht? Es gibt einige interessante Besonderheiten, über die man sprechen kann.
Alternate Data Streams sind eine Funktion, die nur NTFS-Dateisystemen eigen ist; dies bedeutet, dass die meisten Methoden zur Übertragung der Malware nach der Erstinfektion Stage2 entfernen und verlieren, da es ein ADS von Stage1 ist. Es müsste besondere Sorgfalt darauf verwendet werden, die Probe so zu übertragen, dass Stage2 erhalten bleibt, da ohne sie viele Reverse Engineers und Malware-Analysten sehr verwirrt wären, was passiert. RAR-Archive können ADS erhalten, und Tools wie 7Z und Peazip können Dateien und ihre ADS extrahieren.
Wie bereits erwähnt, sollte die Malware bei Erreichen eines Blue Teamers Stage1 sein; Stage0 ist gekommen und gegangen, und Stage2 ist bereits mit den von Stage0 gesammelten Umgebungsinformationen verschlüsselt. Nicht zu wissen, dass Stage0 überhaupt existiert hat, wird erhebliche Unsicherheit beim Verständnis des Lebenszyklus und der Entschlüsselung von Stage2 hinzufügen.
Theoretisch (da ich wieder keine Reverse-Engineering-Erfahrung habe) sollte Stage1 umkehrbar sein (nachdem der Blue Teamer einige Kopien davon durchgespielt hat, weil es sich immer wieder selbst löscht), und die Informationen, die Stage1 vom Zielsystem sammelt, sollten identifiziert werden können. Bei einer gut orchestrierten Reaktion sollte Blue Team in der Lage sein, das Opfer zu identifizieren, von dem die Malware stammt, diese Informationen von dort zu sammeln und in das Programm einzuspeisen, damit sie entsprechend in den AES-Key/IV umgewandelt werden kann, der Stage2 entschlüsselt. Es gibt jedoch viele „Wenns“ in Bezug auf die relative Fähigkeit des Reverse Engineers sowie die Verfügbarkeit der Opfermaschine, um diese Informationen wiederherzustellen.
Application Whitelisting würde diesen Lebenszyklus erheblich erschweren. Stage0/Stage1 könnten möglicherweise als DLL seitengeladen werden, aber ich vermute, dass Stage2 als ADS einige Probleme bereiten würde. Ich habe keine Umgebung, um Malware gegen AWL zu testen, und ich habe mich auch nicht darum gekümmert, dies alles in ein DLL-Format zu portieren, daher kann ich nichts dazu sagen. Ich bin sicher, dass es kreative Wege gibt, diese Probleme zu umgehen.
Ich bin auch ziemlich zuversichtlich, dass es intelligentere Wege gibt, Stage2 auszuführen, als es auf die Festplatte zu legen und CreateProcess aufzurufen; entweder das manuelle Zuordnen der ausführbaren Datei oder die Verwendung eines Tools wie Donut, um es in Shellcode umzuwandeln, erscheinen vernünftige Ideen.
Während der Entwicklung habe ich eine Builder-Anwendung erstellt, der Stage1 und Stage2 zugeführt werden können, um ein funktionsfähiges Stage0 zu erzeugen; diese wird jedoch nicht zur Verfügung gestellt, aber ich werde den größten Teil des Quellcodes für Stage1 bereitstellen, da es das Stück ist, das für einen Blue Teamer am sichtbarsten wäre. Stage0 wird als Übung für den Leser ausgeschlossen, und Stage2 ist die eigenständige ausführbare Datei, die Sie ausführen und schützen möchten. Dieser POC kann nach Belieben und Ermessen fähiger Leser weiter erforscht werden.Ich werde eine kompilierte Kopie dieser Malware als Dropper64.exe bereitstellen. Dropper64.exe ist für x64 kompiliert. Dropper64.exe ist Stage0; es enthält Stage1 und Stage2. Bei der Ausführung werden Stage1 und Stage2 auf die Festplatte geschrieben, aber NICHT automatisch ausgeführt, Sie müssen Dropper64.exe(jetzt Stage1) erneut ausführen. Stage2 ist eine x64-Version von calc.exe. Ich füge dies für alle Blue Teamers hinzu, die einen Blick darauf werfen möchten, aber bedenken Sie, dass Sie in einem Incident-Response-Szenario zu 99& der Zeit Stage1/Stage2 erhalten, Stage0 wird verschwunden sein.
Dies war ein interessantes Hobbyprojekt, das ein langes Wochenende in Anspruch genommen hat. Ich bin sicher, es wäre viel fortschrittlicher/vollständiger, wenn ich Erfahrung mit einem Debugger und Disassembler hätte, aber man macht das Beste aus dem, was man hat. Ich bin gespannt, was Blue Teamers und andere Malware-Entwickler dazu denken. Ich bin sicher, ich habe hier überkompliziert das Rad neu erfunden, angesichts dessen, was echte APTs tun, aber ich habe unterwegs einiges gelernt. Vielen Dank fürs Lesen!
