Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!
BokuLoader — Uma prova de conceito de Reflective Loader do Cobalt Strike que visa recriar, integrar e aprimorar os recursos de evasão do Cobalt Strike! | Kitploit
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.
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
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.
Alocador Mapeado
O Kernel32.CreateFileMappingA e o Kernel32.MapViewOfFile são chamados para alocar memória para a beacon DLL virtual.
Detecção do Sleepmask
Se o sleepmask kit for usado, existem métodos de detecção para essa alocação de memória independente, conforme detalhado por MDSec aqui
Syscalls Indiretos
O BokuLoader chama os seguintes syscalls do NT para configurar a memória executável do beacon carregado: NtAllocateVirtualMemory, NtProtectVirtualMemory
Eles são chamados indiretamente a partir da memória executável do BokuLoader.
Definir hooks no userland em ntdll.dll não detectará esses syscalls.
Pode ser possível registrar kernelcallbacks usando um driver de kernel para monitorar as chamadas de sistema acima e detectar seu uso.
O próprio BokuLoader conterá as instruções de assembly mov eax, r11d; mov r11, r10; mov r10, rcx; jmp r11 dentro de sua memória executável.
Cabeçalho da Beacon DLL Virtual
Os primeiros 0x1000 bytes da beacon DLL virtual são zeros.
Código-Fonte Disponível
O código-fonte do BokuLoader é fornecido no repositório e pode ser usado para criar assinaturas de memória.
Se você tiver orientações adicionais de detecção, sinta-se à vontade para contribuir enviando um pull request.
xforcered/bokuloader
