Descrição:

O ExecuteAssembly é uma alternativa ao execute-assembly do CS, construído em C/C++ e pode ser usado para Carregar/Injetar assemblies .NET por meio de; reutilização dos módulos CLR/AppDomainManager carregados pelo processo hospedeiro (spawnto), Stomping dos cabeçalhos DOS PE do Loader/assembly .NET, Desvinculação de módulos relacionados ao .NET, bypass de ETW+AMSI, evasão de hooks EDR via syscalls estáticos NT (x64) e ocultação de imports pela resolução dinâmica de APIs via algoritmo de hashing superfasthash.

TLDR (Características):

Desvinculação de módulos relacionados ao CLR das estruturas de dados do PEB. (use o utilitário "ListDLLs" da MS em vez do PH para confirmação)
Stomping de cabeçalhos do assembly .NET e da DLL reflexiva (bytes MZ, e_lfanew, Cabeçalho DOS, Rich Text, Cabeçalho PE).
Uso de syscalls estáticos codificados para bypassar hooks EDR. (suporte apenas x64 por enquanto, do WinXP ao Win10 19042)
Enumeração e reutilização de CLR "AppDomain/AppDomainManager" (ICLRMetaHost->EnumerateLoadedRuntimes), basta definir o processo spawnto/hospedeiro como um processo .NET conhecido do Windows.
Resolução dinâmica de APIs WIN32 (PEB) usando o hash correspondente da API (SuperFastHash)
Correção (patching) de AMSI e ETW antes de carregar assemblies .NET.
Análise e varredura dos bytes do assembly .NET para determinar a versão do CLR a ser carregada/utilizada.
Nenhum uso de GetProcAddress/LoadLibrary/GetModuleHandle para bypass de ETW.
Hospedagem CLR usando a API COM v4 e injeção de DLL reflexiva.

Uso:

x64(syscalls): esta versão depende principalmente do uso de syscalls estáticos para bypassar hooks EDR. Você pode usar esta versão para compilar apenas a versão x64 da DLL (suporte apenas x64 por enquanto).
x86|x64(PEB): recupera dinamicamente os endereços das APIs necessárias em tempo de execução percorrendo as tabelas EAP dos módulos do PEB e resolvendo APIs via hash superfasthash. No entanto, não considera hooks EDR colocados em kernel32.dll ou ntdll.dll. Você pode usar esta versão para compilar ambas as DLLs x86 e x64, ou apenas a DLL x86 e usar a versão x64(syscalls) para compilar a DLL x64 para lidar com hooks EDR comuns.
Compile as DLLs necessárias usando VS2017 e/ou Windows SDK 10.0.17134.0 (ou versões de SDK compatíveis).
Certifique-se de que o gzip esteja instalado e os seguintes artefatos estejam na mesma pasta, depois carregue o script aggressor "ExecuteAssembly.cna":
- ExecuteAssembly.cna
- ExecuteAssembly-x64.dll
- ExecuteAssembly-x86.dll
- Opções de CLI:
  
  --dotnetassembly: Assembly .NET a ser carregado/injetado.
  
  --assemblyargs: Argumentos do assembly .NET.
  
  --unlink-modules: Desvincular módulos relacionados ao .NET, como DLLs CLR/MsCoree, das estruturas de dados do PEB.
  
  --stomp-headers: Aplicar stomping nos cabeçalhos DOS PE do assembly .NET e da DLL reflexiva.
  
  --etw: Bypass do Event Tracing for Windows (ETW).
  
  --amsi: Bypass do AMSI.
  
  --spawnto: Escolher processo spawnto, lista de binários .NET que carregam o CLR por padrão quando executados:
  - PresentationHost.exe
  - stordiag.exe
Verifique spawnto-list.txt para binários MS adicionais que carregam o CLR por padrão e são bons candidatos para definir como spawnto. (evitaria os conhecidos LOLBins, a menos que seja uma máquina de desenvolvedor, talvez)

Exemplos:

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

Suporte a C2:

Foi criado e testado principalmente no Cobalt Strike, mas também pode ser usado com outros frameworks C2 (MSF ..etc). Apenas lembre-se de que o DLLMAIN da DLL reflexiva espera o payload de uma linha como parâmetro (lpReserved) no seguinte formato (sem "."):

AMSI_FLAG|ETW_FLAG|STOMPHEADERS_FLAG|UNLINKMODULES_FLAG|LL_FLAG.LENGTH_FLAG.B64_ENCODED_COMPRESSED_PAYLOAD [ARGUMENTOS SEPARADOS POR ESPAÇO]
- AMSI_FLAG: 0|1 (0 ou 1)
- ETW_FLAG: 0|1
- STOMPHEADERS_FLAG: 0|1
- UNLINKMODULES_FLAG: 0|1
- LENGTH_FLAG: tamanho do assembly .NET em bytes
- LL_FLAG: comprimento_de(LENGTH_FLAG) (apenas me ature aqui ou finja que não leu isso)
- B64_ENCODED_COMPRESSED_PAYLOAD: assembly .NET comprimido com Gzip e codificado em base64.
- [ARGUMENTOS SEPARADOS POR ESPAÇO]: argumentos do assembly .NET

Notas de Teste:

Testado com Cobalt Strike 4.x sem perfis malleable.
Testado com Cobalt Strike 4.x usando o seguinte perfil malleable (várias opções de evasão de memória configuradas (userwx, startrwx ..etc));
- https://github.com/threatexpress/malleable-c2/blob/master/jquery-c2.4.0.profile

TODO:

Uma alternativa ao RFLL, BOF + Named Pipes pode ser (não tenho certeza sobre tarefas de longa duração)
Suporte x86 para syscalls estáticos.
Correção de bugs e limpeza de ponteiros soltos ou vazamentos de memória que eu possa ter deixado :p

Problemas Conhecidos:

Suporte para SharpHound v2 e v3 (v2 costumava funcionar bem, preciso descobrir o que mudou).
Limitação de tamanho do assembly .NET (< 1MB)

Mais Populares

Sobre

ExecuteAssembly