BokuLoader : Reflective Loader para Cobalt Strike

Uma prova de conceito Reflective Loader Definido pelo Usuário (UDRL) que tem como objetivo recriar, integrar e aprimorar os recursos de evasão do Cobalt Strike!

Contribuidores:

Contribuidor	Twitter	Contribuições Notáveis
Bobby Cooke	@0xBoku	Autor original e mantenedor do projeto
Santiago Pecin	@s4ntiago_p	Principais aprimoramentos do Reflective Loader
Chris Spehn	@ConsciousHacker	Scripts Aggressor
Joshua Magri	@passthehashbrwn	Hooking da IAT
Dylan Tran	@d_tranman	Spoofing reflexivo de pilha de chamadas
James Yeung	@5cript1diot	Syscalls indiretos

Considerações de Uso do UDRL

O reflective loader nativo do Cobalt Strike é robusto e lida com todos os recursos de evasão Malleable PE que o Cobalt Strike oferece. A principal desvantagem de usar um UDRL personalizado é que os recursos de evasão Malleable PE podem ou não ser suportados nativamente.

O objetivo do projeto público BokuLoader é auxiliar red teams na criação de seus próprios UDRLs internos para Cobalt Strike. O projeto visa suportar todos os recursos de evasão Malleable PE do CS que valem a pena. Alguns recursos de evasão aproveitam a integração com o CS, outros foram recriados por completo, e alguns não são suportados.

Antes de usar este projeto, de qualquer forma, você deve testar adequadamente se os recursos de evasão estão funcionando conforme o esperado. Entre o código C e o script Aggressor, a compilação com diferentes versões de sistemas operacionais, compiladores e Java pode retornar resultados diferentes.

Recursos de Evasão

Recursos de Evasão Específicos do BokuLoader

• Spoofing reflexivo de pilha de chamadas via quadros sintéticos.
• Código de reflective loader personalizado em ASM/C
• Syscalls NT indiretos via técnicas HellsGate & HalosGate
  • Todas as alterações de proteção de memória para todas as opções de alocação são feitas via syscall indireto para NtProtectVirtualMemory
• obfuscate "true" com implementação personalizada do script Aggressor para UDRL.
• NOHEADERCOPY
  • O loader não copiará os cabeçalhos da beacon DLL bruta para a beacon DLL virtual. Os primeiros 0x1000 bytes serão nulos.
• XGetProcAddress para resolver símbolos
  • Não usa Kernel32.GetProcAddress
• xLoadLibrary para resolver o endereço base da DLL e o carregamento da DLL
  • Para DLLs carregadas, obtém o endereço base da DLL a partir de TEB->PEB->PEB_LDR_DATA->InMemoryOrderModuleList
  • Não usa Kernel32.LoadLibraryA
• Cifra de César para ofuscação de strings
• Tamanho do UDRL de 100k
• Os nomes das DLLs de importação e as strings dos nomes das entradas de importação são sobrescritos na beacon DLL virtual.

Recursos de Evasão Malleable PE Suportados

Comando	Opção(ões)	Suportado
allocator	HeapAlloc, MapViewOfFile, VirtualAlloc	Todos suportados via implementação do BokuLoader
module_x64	string (DLL Name)	Suportado via implementação do BokuLoader. Os mesmos requisitos de DLL stomping da implementação do CS se aplicam
obfuscate	true/false	Beacons HTTP/S suportados via implementação do BokuLoader. SMB/TCP atualmente não é suportado para obfuscate true. Detalhes na issue. Aceito ajuda se você puder corrigir :)
entry_point	RVA como número decimal	Suportado via implementação do BokuLoader
cleanup	true	Suportado via integração com o CS
userwx	true/false	Suportado via implementação do BokuLoader
sleep_mask	(true/false) ou (Sleepmask Kit+true)	Suportado. Ao usar o padrão "sleepmask true" (sem sleepmask kit), defina "userwx true". Ao usar o sleepmask kit que suporta memória RX beacon.text (src47/Ekko), defina "sleepmask true" && "userwx false".
magic_mz_x64	string de 4 caracteres	Suportado via integração com o CS
magic_pe	string de 2 caracteres	Suportado via integração com o CS
transform-x64 prepend	string hex escapada	Modificação do script Aggressor BokuLoader.cna
transform-x64 strrep	string string	Modificação do script Aggressor BokuLoader.cna
stomppe	true/false	Não suportado. O BokuLoader não copia os cabeçalhos da beacon DLL. Os primeiros 0x1000 bytes da beacon DLL virtual são 0x00
checksum	number	Experimental. Modificação do script Aggressor BokuLoader.cna
compile_time	string de data-hora	Experimental. Modificação do script Aggressor BokuLoader.cna
image_size_x64	valor decimal	Não suportado
name	string	Experimental. Modificação do script Aggressor BokuLoader.cna
rich_header	string hex escapada	Experimental. Modificação do script Aggressor BokuLoader.cna
stringw	string	Não suportado
string	string	Não suportado

Teste

• (2/22/23) Todos os 4 métodos de alocação testados com threatexpress/malleable-c2/master/jquery-c2.4.7.profile

Origens do Projeto

• Baseado no incrível projeto Reflective Loader de Stephen Fewer:
  • https://github.com/stephenfewer/ReflectiveDLLInjection
• Criado inicialmente enquanto eu percorria os vídeos de Reflective DLL do Renz0h do curso Malware Developer Intermediate (MDI) da Sektor7

Uso

1. Compile o arquivo de objeto BokuLoader com make
2. Inicie o seu Team Server do Cobalt Strike
3. No Cobalt Strike, importe o script Aggressor BokuLoader.cna
4. Gere o beacon x64 (Attacks -> Packages -> Windows Executable (S))
5. Use o Script Console para garantir que o BokuLoader foi implementado na compilação do beacon

• Não suporta a opção x86. O binário x86 é o arquivo de objeto original do Reflective Loader.
• Gerar beacons RAW funciona nativamente. Ao usar o Artifact Kit para o loader do beacon, a variável stagesize deve ser maior que o padrão.
  • Consulte a documentação do User-Defined Reflective Loader do Cobalt Strike para obter informações adicionais

Orientação de Detecção

Strings Hardcoded

• O BokuLoader altera algumas strings comumente detectadas para novos valores hardcoded. Essas strings podem ser usadas para criar assinaturas do BokuLoader:

String Original do Cobalt Strike	String do Cobalt Strike com BokuLoader
ReflectiveLoader	BokuLoader
Microsoft Base Cryptographic Provider v1.0	12367321236742382543232341241261363163151d
(admin)	(tomin)
beacon	bacons

Alocadores de Memória

DLL Module Stomping

• O Kernel32.LoadLibraryExA é chamado para mapear a DLL do disco
• O 3º argumento de Kernel32.LoadLibraryExA é DONT_RESOLVE_DLL_REFERENCES (0x00000001)
  • o sistema não chama DllMain
• Não resolve endereços na entrada LDR do PEB, conforme detalhado por MDSec aqui
• Detectável ao escanear a memória do processo com a ferramenta pe-sieve

Alocação em Heap

• Memória executável RX ou RWX existirá no heap se o sleepmask kit não for usado.