Descripción:

ExecuteAssembly es una alternativa de CS execute-assembly, construida con C/C++ y puede usarse para cargar/inyectar ensamblados .NET mediante; reutilización de los módulos CLR cargados por el proceso anfitrión (spawnto)/AppDomainManager, pisoteo de cabeceras DOS PE del cargador/ensamblado .NET, desvinculación de módulos relacionados con CLR, bypass de ETW+AMSI, evasión de hooks EDR mediante syscalls estáticas NT (x64) y ocultación de importaciones resolviendo APIs dinámicamente mediante el algoritmo de hash superfasthash.

TLDR (Características):

Desvinculación de módulos relacionados con CLR de las estructuras de datos del PEB (usa la utilidad "ListDLLs" de MS en lugar de PH para confirmación).
Pisoteo de cabeceras del ensamblado .NET y DLL reflectiva (bytes MZ, e_lfanew, cabecera DOS, Rich Text, cabecera PE).
Uso de syscalls estáticas hardcodeadas para evadir hooks EDR (solo soporte x64 por ahora, desde WinXP hasta Win10 19042).
Enumeración y reutilización de CLR "AppDomain/AppDomainManager" (ICLRMetaHost->EnumerateLoadedRuntimes), solo hay que configurar el proceso spawnto/anfitrión como un proceso .NET conocido de Windows.
Resolución dinámica de APIs WIN32 (PEB) usando el hash correspondiente de las APIs (SuperFastHash).
Parcheo de AMSI y ETW antes de cargar ensamblados .NET.
Análisis de bytes del ensamblado .NET y escaneo de la versión CLR a cargar/usar.
Sin uso de GetProcAddress/LoadLibrary/GetModuleHandle para el bypass de ETW.
Hosting CLR mediante API COM v4 e inyección de DLL reflectiva.

Uso:

x64(syscalls): esta versión depende principalmente del uso de syscalls estáticas para evadir hooks EDR. Puedes usar esta versión para compilar únicamente la versión x64 de la DLL (solo soporte x64 por ahora).
x86|x64(PEB): recupera las direcciones de API requeridas dinámicamente en tiempo de ejecución recorriendo las tablas EAP de los módulos del PEB y resolviendo las APIs mediante hash superfasthash. Sin embargo, no tiene en cuenta los hooks EDR colocados en kernel32.dll o ntdll.dll. Puedes usar esta versión para compilar tanto las DLLs x86 como x64, o solo la DLL x86 y usar la versión x64(syscalls) para compilar la DLL x64 para cubrir los hooks EDR comunes.
Compila las DLLs requeridas usando VS2017 y/o Windows SDK 10.0.17134.0 (o versiones de SDK compatibles).
Asegúrate de que gzip esté instalado y los siguientes artefactos estén colocados dentro de la misma carpeta, luego solo carga el script aggressor "ExecuteAssembly.cna":
- ExecuteAssembly.cna
- ExecuteAssembly-x64.dll
- ExecuteAssembly-x86.dll
- Opciones de CLI:
  
  --dotnetassembly: Ensamblado .NET a cargar/inyectar.
  
  --assemblyargs: Argumentos del ensamblado .NET.
  
  --unlink-modules: Desvincula módulos relacionados con .NET, como DLLs de CLR/MsCoree, de las estructuras de datos del PEB.
  
  --stomp-headers: Pisotea las cabeceras DOS PE del ensamblado .NET y de la DLL reflectiva.
  
  --etw: Evita el seguimiento de eventos en Windows (ETW).
  
  --amsi: Evita AMSI.
  
  --spawnto: Elige el proceso spawnto, lista de binarios .NET que cargan el CLR por defecto al ejecutarse:
  - PresentationHost.exe
  - stordiag.exe
Revisa spawnto-list.txt para binarios MS adicionales que cargan el CLR por defecto y son buenos candidatos para configurar como spawnto. (se evitarían los conocidos LOLBins a menos que sea una máquina de desarrollo quizás)

Ejemplos:

ExecuteAssembly --dotnetassembly /tmp/Seatbelt.exe --assemblyargs LogonSessions --unlink-modules --stomp-headers --amsi --etw --spawnto PresentationHost.exe
ExecuteAssembly --amsi --etw --unlink-modules --stomp-headers --dotnetassembly /tmp/ghostpack/SharPersist.exe --assemblyargs -t reg -c "C:\Windows\SysWow64\mshta.exe C:\Users\admin\Downloads\Test2.hta" -k logonscript -m add --spawnto FileHistory.exe
ExecuteAssembly --unlink-modules --stomp-headers --dotnetassembly /tmp/ghostpack/SharPersist.exe --assemblyargs -t reg -k "logonscript" -v "C:\Windows\SysWow64\mshta.exe C:\Users\admin\Downloads\Test.hta" -m remove --spawnto FileHistory.exe
ExecuteAssembly --unlink-modules --amsi --dotnetassembly /tmp/ghostpack/SharpWMI.exe --assemblyargs action=query computername=localhost query="select * from win32_service" --spawnto FileHistory.exe
ExecuteAssembly --amsi --etw --dotnetassembly /tmp/ghostpack/SharpWMI.exe --assemblyargs action=query query="select * from win32_process" --spawnto PresentationHost.exe

Soporte de C2:

Fue creado y probado principalmente en Cobalt Strike, sin embargo puede usarse con otros frameworks C2 también (MSF ..etc), solo ten en cuenta que el DLLMAIN de la DLL reflectiva espera el payload de una línea como parámetro (lpReserved) en el siguiente formato (sin ".");

AMSI_FLAG|ETW_FLAG|STOMPHEADERS_FLAG|UNLINKMODULES_FLAG|LL_FLAG.LENGTH_FLAG.B64_ENCODED_COMPRESSED_PAYLOAD [ARGUMENTOS SEPARADOS POR ESPACIOS]
- AMSI_FLAG: 0|1 (0 o 1)
- ETW_FLAG: 0|1
- STOMPHEADERS_FLAG: 0|1
- UNLINKMODULES_FLAG: 0|1
- LENGTH_FLAG: tamaño del ensamblado .NET en bytes
- LL_FLAG: longitud_de(LENGTH_FLAG) (ten paciencia conmigo o finge que no leíste esto)
- B64_ENCODED_COMPRESSED_PAYLOAD: ensamblado .NET comprimido con Gzip y codificado en base64.
- [ARGUMENTOS SEPARADOS POR ESPACIOS]: argumentos del ensamblado .NET

Notas de Prueba:

Probado con Cobalt Strike 4.x sin usar perfiles malleables.
Probado con Cobalt Strike 4.x usando el siguiente perfil malleable (múltiples opciones de evasión de memoria activadas (userwx, startrwx ..etc));
- https://github.com/threatexpress/malleable-c2/blob/master/jquery-c2.4.0.profile

TODO:

Una alternativa de RFLL, BOF + Named Pipes puede ser (no seguro para tareas de larga duración)
Soporte x86 para syscalls estáticas.
Corrección de errores y limpieza de punteros colgantes o fugas de memoria que haya pasado por alto :p

Problemas Conocidos:

Soporte para SharpHound v2 y v3 (v2 solía funcionar bien, necesito averiguar qué cambió).
Limitación de tamaño del ensamblado .NET (< 1MB)

Más Populares

Acerca de

ExecuteAssembly