pwn1sher/frostbyteKombiniert AppDomain Manager Injection mit Shellcode-Einbettung in signierte Binärdateien, um die EDR/AV-Erkennung für Red-Team-Payloads zu umgehen.
In den letzten Tagen habe ich mit der AppDomain-Manager-Injection Technik experimentiert und hatte in meinen früheren Red-Team-Einsätzen gegen bestimmte EDRs einigen Erfolg damit. Obwohl dies ein sehr guter initialer Zugriffsvektor ist, wollte ich einen POC veröffentlichen, der dabei hilft, Ihren Shellcode woanders zu verstecken. Keine Shellcode-eingebetteten DLL-Dateien mehr!
Obwohl es sich um eine hervorragende Technik handelt, wenn sie eigenständig verwendet wird, ist das Problem bei Kombination mit einer Auslieferungstechnik wie dem Senden einer C# ClickOnce in einer ISO/ZIP/VHD/VHDX-Datei, dass 1 von 10 Mal die DLL für die AppDomain von den AI/ML-Heuristiken des AV/EDR erkannt wurde. Dies liegt daran, dass die DLL-Datei vor der Initialisierung der AppDomain auf die Festplatte gelegt werden muss. Abgesehen von den Remote-DLL-Loads (UNC-Pfade in .config) würde die DLL für die AppDomain den Shellcode enthalten, und ich hatte stark das Gefühl, dass dies der Grund für eine wahrscheinliche statische Erkennung ist, da der restliche Code, bei dem es sich um WINAPI-Aufrufe handelt, dynamisch aufgelöst und recht gut verschleiert werden kann.
Ich wollte diese Technik verbessern, um zu minimieren, was die DLL ursprünglich enthält. Ich begann damit, verschlüsselten Shellcode in einer separaten Datei auf der Festplatte zusammen mit der Injector-DLL abzulegen, stieß dann aber auf diesen großartigen Blog von Checkpoint über Zloaders Kampagne
TLDR-Version: Wir können beliebige Daten in einige Felder innerhalb der PE einbetten, ohne die Signatur der Datei zu beschädigen. Unsere Daten werden also eingebettet und die EXE bleibt weiterhin digital signiert.
Weitere Informationen dazu - https://www.blackhat.com/docs/us-16/materials/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf
Die Idee ist also, einen verschlüsselten Shellcode-Stub in eine bekannte signierte ausführbare Datei einzubetten und dennoch dafür zu sorgen, dass sie signiert bleibt, wie es der Zloader-Malware gelang. Dadurch enthält die AppDomain-Manager-DLL den Shellcode nicht mehr selbst, sondern hat nur noch die Logik, den Shellcode aus der PE-Binärdatei zu parsen, die ihn lädt, zu entschlüsseln und als separaten Thread auszuführen. Dies könnte die statische Erkennungsrate für die DLL senken, während Ihr Shellcode schön in einer signierten Binärdatei platziert ist.
Ich versuchte dies, indem ich manuell an den ZLoader-Beispielen manipuliere, die ich von VirusTotal hatte, aber später fand ich ein Projekt, das all diese Techniken bereits recht gut implementiert hatte – Sigflip. In diesem POC nutzte ich Sigflips Lader-Code, um die AppDomain-DLL zu erstellen, und den SigFlip-Injektor, um den verschlüsselten Shellcode in unsere C#-EXE einzubetten.
Große Shellcode-Blobs wie Cobalt Strikes Stageless-Shellcode befinden sich nicht mehr in einer unsignierten DLL auf der Festplatte, unabhängig von den verwendeten Verschleierungs-/Kodierungstechniken. Die DLL ist sauberer, kleiner und unauffälliger mit minimalem Code, wodurch die Erkennungswahrscheinlichkeit verringert wird.
SigFlip.exe -i "Z:\ZLoader\CasPol.exe" "Z:\ZLoader\x64-stageless.bin" "Z:\ZLoader\update.exe" "S3cretK3y"update.exe, die eine digital signierte PE mit eingebettetem verschlüsselten Shellcode ist.csc /target:library /out:test.dll test.csDieser POC ist nur eine Idee, die ich hatte, um zwei völlig unterschiedliche defensiv-umgehende Techniken zusammenzubringen, die mir und anderen Red Teamern helfen, bessere anfängliche Ausführungspayloads für ihre Operationen zu erstellen. Dieses Projekt verwendet AppDomain-Manager-Injection als Beispiel, aber diese Idee ist auch auf andere Injection-Techniken anwendbar, wie DLL-Seitenladung, DLL-Hijacking usw.
Vollständige Credits an med0x2e, dieser POC basiert auf seinem SigFlip-Projekt