ModuleShifting

Dieses Tool wurde vorgestellt auf dem 2023 x33fcon talk: "Improving the stealthiness of Memory Injection Techniques" [Video] [Blogpost]

Was ist das?

ModuleShifting ist eine heimlichere Variante der Module-Stomping- und Module-Overloading-Injektionstechnik. Es ist in Python ctypes implementiert, sodass es vollständig im Speicher über einen Python-Interpreter und Pyramid ausgeführt werden kann, wodurch die Verwendung kompilierter Loader vermieden wird.

Die Technik kann mit PE- oder Shellcode-Payloads verwendet werden, die heimlichere Variante ist jedoch für Shellcode-Payloads gedacht, die funktional unabhängig vom endgültigen Payload sein müssen, den der Shellcode lädt.

ModuleShifting führt bei Verwendung mit Shellcode-Payload die folgenden Operationen durch:

1. Legitime Hosting-DLL wird via LoadLibrary geladen
2. Ändert die Speicherberechtigungen eines angegebenen Abschnitts auf RW
3. Überschreibt Shellcode über den Zielabschnitt
4. Fügt optionales Padding hinzu, um sich besser in Fehlalarmverhalten einzufügen (weitere Informationen hier)
5. Ändert Berechtigungen auf RX
6. Führt Shellcode über Funktionszeiger aus - zusätzliche Ausführungsmethoden: Funktions-Callback oder CreateThread-API
7. Schreibt ursprünglichen DLL-Inhalt über den ausgeführten Shellcode - dieser Schritt vermeidet das Hinterlassen eines bösartigen Speicherartefakts im Image-Speicherbereich der Hosting-DLL. Der Shellcode muss funktional unabhängig von weiteren Stufen sein, sonst bricht die Ausführung ab.

Bei Verwendung eines PE-Payloads führt ModuleShifting die folgenden Operationen durch:

1. Legitime Hosting-DLL wird via LoadLibrary geladen
2. Ändert die Speicherberechtigungen eines angegebenen Abschnitts auf RW
3. Kopiert das PE abschnittsweise über den angegebenen Zielpunkt
4. Fügt optionales Padding hinzu, um sich besser in Fehlalarmverhalten einzufügen
5. Führt Basisrelokation durch
6. Löst Importe auf
7. Schließt den Abschnitt ab, indem Berechtigungen auf ihre nativen Werte gesetzt werden (vermeidet die Erstellung einer RWX-Speicherregion)
8. Ausführung von TLS-Callbacks
9. Ausführung des PE-Einstiegspunkts

Warum es nützlich ist

ModuleShifting kann verwendet werden, um einen Payload zu injizieren, ohne dynamisch Speicher zuzuweisen (d.h. VirtualAlloc), und ist im Vergleich zu Module Stomping und Module Overloading heimlicher, da es die Anzahl der von der Injektionstechnik selbst erzeugten IoCs verringert.

Es gibt 3 Hauptunterschiede zwischen Module Shifting und einigen öffentlichen Implementierungen von Module Stomping (eine von Bobby Cooke und WithSecure)

1. Padding: Beim Schreiben von Shellcode oder PE kannst du Padding verwenden, um sich besser in häufiges Fehlalarmverhalten einzufügen (z. B. Drittanbieteranwendungen oder .NET-DLLs, die x Bytes über ihren .text-Abschnitt schreiben).
2. Shellcode-Ausführung mittels Funktionszeiger. Dies hilft, die Erstellung eines neuen Threads oder das Aufrufen ungewöhnlicher Funktions-Callbacks zu vermeiden.
3. Wiederherstellung des ursprünglichen DLL-Inhalts über den ausgeführten Shellcode. Dies ist ein wesentlicher Unterschied.

Die Unterschiede zwischen Module Shifting und Module Overloading sind die folgenden:

1. Das PE kann ab einem angegebenen Abschnitt geschrieben werden, anstatt ab dem PE der Hosting-DLL zu beginnen. Wird der Zielabschnitt sorgfältig gewählt, kann dies die Anzahl der erzeugten IoCs reduzieren (d.h. der PE-Header der Hosting-DLL wird nicht überschrieben oder weniger Bytes im .text-Abschnitt überschrieben usw.).
2. Padding, das zum PE-Payload selbst hinzugefügt werden kann, um sich besser in Fehlalarme einzufügen.

Mit einem funktional unabhängigen Shellcode-Payload wie einem AceLdr Beacon Stageless Shellcode-Payload ist ModuleShifting in der Lage, lokal zu injizieren, ohne dynamisch Speicher zuzuweisen, und erzeugt derzeit null IoCs bei einem Moneta- und PE-Sieve-Scan. Mir ist bewusst, dass die AceLdr-Schlaf-Payloads mit anderen großartigen Tools wie Hunt-Sleeping-Beacon erkannt werden können, aber der Fokus liegt hier auf der Injektionstechnik selbst, nicht auf dem Payload. In unserem Fall ermöglicht die funktionale Unabhängigkeit des Shellcodes mehr Heimlichkeit bei der Injektion, sodass die geschriebenen bösartigen Bytes auf ihren ursprünglichen Inhalt zurückgesetzt werden können, wodurch die Spuren der Injektion effektiv gelöscht werden.

Haftungsausschluss

Alle Informationen und Inhalte werden nur zu Bildungszwecken bereitgestellt. Befolgen Sie die Anweisungen auf eigenes Risiko. Weder der Autor noch sein Arbeitgeber haften für direkte oder indirekte Schäden oder Verluste, die durch eine Person oder Organisation entstehen.

Danksagungen

Diese Arbeit wurde ermöglicht durch das Wissen und die Werkzeuge, die von unglaublichen Menschen wie Aleksandra Doniec @hasherezade, Forest Orr und Kyle Avery geteilt wurden. Ich habe Moneta, PeSieve, PE-Bear und AceLdr intensiv während meines gesamten Lernprozesses genutzt und sie waren entscheidend für mein Verständnis dieses Themas.

Verwendung

ModuleShifting kann mit Pyramid und einem Python-Interpreter verwendet werden, um die lokale Prozessinjektion vollständig im Speicher auszuführen und so kompilierte Loader zu vermeiden.

1. Klonen Sie das Pyramid-Repository:

git clone https://github.com/naksyn/Pyramid

2. Generieren Sie einen Shellcode-Payload mit Ihrem bevorzugten C2 und legen Sie ihn im Ordner Delivery_files von Pyramid ab. Siehe Abschnitt Caveats für Payload-Anforderungen.
3. Ändern Sie die Parameter des Skripts moduleshifting.py im Ordner Modules von Pyramid.
4. Starten Sie den Pyramid-Server: python3 pyramid.py -u testuser -pass testpass -p 443 -enc chacha20 -passenc superpass -generate -server 192.168.1.2 -setcradle moduleshifting.py
5. Führen Sie den generierten Cradle-Code auf einem Python-Interpreter aus.

Demo

https://github.com/naksyn/ModuleShifting/assets/59816245/67fcf888-3385-47da-b828-8a2dafeeb1e2

Einschränkungen

Um diese Technik erfolgreich auszuführen, sollten Sie einen Shellcode-Payload verwenden, der in der Lage ist, einen zusätzlichen eigenständigen Payload in einem anderen Speicherbereich zu laden. ModuleShifting wurde mit dem AceLdr-Payload getestet, der eine vollständige Kopie von Beacon auf dem Heap laden kann, wodurch die funktionale Abhängigkeit vom initialen Shellcode aufgehoben wird. Diese Technik würde mit jedem Shellcode-Payload funktionieren, der ähnliche Fähigkeiten hat. Der anfängliche Shellcode wird nach der Ausführung nutzlos, und es gibt keinen Grund, ihn als IoC im Speicher zu behalten.

Es sollte auch eine Hosting-DLL mit ausreichend Platz für den Shellcode im Zielabschnitt gewählt werden, sonst schlägt die Technik fehl.

Erkennungsmöglichkeiten

Module Stomping und Module Shifting müssen Shellcode in den Speicherbereich einer legitimen DLL schreiben. ModuleShifting beseitigt diesen IoC nach der Bereinigungsphase, aber Indikatoren könnten von Scannern mit Echtzeit-Inspektionsfunktionen erkannt werden.