Eden

O Eden loader é um UDRL de PoC para Cobalt Strike construído com Crystal Palace que combina a técnica de page streaming de Raphael Mudge com um call gate modular (atualmente uma versão PIC do BOF de callgate Draugr do Sleepmask-VS).

O objetivo do Eden loader é:

Demonstrar o poder de usar o Crystal Palace para combinar (e reutilizar) 'capacidades' para desenvolver rapidamente loaders/ferramentas personalizados
Servir como um recurso de exemplo para outros construírem em cima
Ajudar profissionais de segurança a entender como UDRLs funcionam (é totalmente depurável)
Informar/estimular a conversa de segurança

Para mais informações sobre o Eden loader, veja o blog correspondente para mais informações.

Nota: O propósito do Eden é demonstrar a ideia de usar o Crystal Palace para combinar diferentes 'unidades de execução' (i.e., capacidades) para criar loaders personalizados. Ele não tem a intenção de ser um loader 'evasivo' completo e, portanto, carece de vários recursos básicos de OPSEC por design. Por exemplo, ele usa memória RWX e não rastreia/mascara a memória heap do Beacon (e, portanto, é vulnerável a assinaturas YARA como esta).

Quick Start Guide

Nota: Este guia de início rápido assume que você já baixou/construiu o Crystal Palace e completou os seguintes passos para configurar seu ambiente de desenvolvimento.

Você primeiro precisa definir a seguinte configuração do Malleable C2:

stage {
    set sleep_mask "false";
}

Abra um terminal WSL na raiz do repositório e construa o Eden loader: make clean; make.
Copie crystalpalace.jar para o diretório do seu cliente Cobalt Strike.
Carregue eden.cna no cliente Cobalt Strike.
Quando você exportar um payload pela próxima vez, o Eden será aplicado automaticamente. Você pode verificar isso verificando a saída no console de script:

[14:55:55] [*] Generating Payload: HTTP -- Type: HTTP -- Arch: x64 -- Exit Function: Thread -- System Call: None -- HTTP Library: wininet
[14:55:56] [EDEN] Parsing C:\Users\wb\Desktop\eden\eden.spec...
[14:55:56] [EDEN] Applying eden ldr spec...
[14:55:56] [EDEN] Payload Size: 387060 bytes
[14:55:56] [*] Using user modified reflective DLL! DLLName=resources/beacon.x64.rl0k.dll Arch=x64

Nota: Eden suporta Beacons HTTP(S), DNS e Pivot.

Debug Guide

Uma limitação do Crystal Palace no momento do lançamento é que ele atualmente só suporta arquivos objeto construídos com mingw. Se você tentar usar um COFF construído com MSVC ou Clang, normalmente receberá erros de realocação. Isso pode ser frustrante, pois mingw não suporta diretamente arquivos pdb e, portanto, pode ser difícil depurar ao escrever tradecraft complexo no Windows. No entanto, você pode adicionar a opção -g ao seu Makefile para incorporar informações de depuração em builds executáveis. Isso torna possível percorrer seu código no WinDbg. Para mais informações sobre este processo, é recomendado ler o seguinte blog do Rastamouse.

Este repositório usa a abordagem acima para construir uma build de depuração do Draugr (draugr.x64.exe) e do código de page streaming (guardexec.x64.exe) por padrão. A build de depuração do Draugr não tem dependências e, portanto, será construída imediatamente, mas se você quiser percorrer/depurar o código de page streaming/hook IAT, precisará seguir os passos abaixo:

1. Exportar Beacon sem um loader:

Carregue debug/export_beacon_with_no_ldr.cna no seu cliente CS e exporte um Beacon raw x64 (HTTP) sem stage para o diretório /eden/debug/. Isso exportará uma DLL do Beacon sem um loader reflexivo que podemos usar para simular o ponto de entrada guardexec.
(No WSL) $ xxd -i ./beacon_x64.bin > debug_beacon.h

2. Exportar o stub PIC do Draugr do Crystal Palace:

Para fazer isso, você precisará executar o Crystal Palace a partir do WSL via $ ./piclink /<path>/eden/debug/draugr.spec x64 /<path>/eden/debug/draugr.bin. Isso fará o Crystal Palace gerar apenas o stub PIC do Draugr que podemos usar para simular o ponto de entrada do guardexec.
(No WSL) $ xxd -i ./draugr.bin > debug_druagr.h

3. Iniciar a depuração no WinDbg:

Reconstrua o Eden após realizar os passos acima: make clean;make
Abra o WinDbg e selecione iniciar executável (/eden/bin/draugr.exe ou /eden/bin/guardexec.exe)
Selecione Open source file e selecione o arquivo .c relevante (i.e., guardexec.c se estiver depurando o código de page streaming).
Agora você pode percorrer / definir breakpoints para o binário Draugr de spoofing de call stack autônomo ou para um Beacon ativo com hooks IAT. Como um aviso, o mascaramento não funcionará corretamente no modo de depuração, pois requer que o Crystal Palace aplique um patch com uma chave durante a geração do payload.

Nota: Não há executável de depuração para o loader, pois não há uma maneira óbvia de fazer o Crystal Palace exportar payloads de depuração para coisas como DLLs criptografadas e suas chaves. Portanto, torna-se não trivial passar buffers PIC 'criptografados' simulados.

Design Considerations

O Eden loader é principalmente destinado a demonstrar o poder do Crystal Palace combinando diferentes 'capacidades' para criar um loader inovador. Essa ideia poderia ser levada muito mais longe do que está neste repositório (i.e., um loader PIC 'estático' que é totalmente personalizável através de módulos COFF (guardrails, callgates, ofuscação de sleep etc.)).
O Eden loader usa uma versão PIC do Draugr explicitamente para que possa falsificar todas as chamadas do ciclo de vida do Beacon (i.e., as chamadas VirtualAlloc / LoadLibrary usadas durante o processo de carregamento reflexivo). Em alguns casos, isso pode ser exagero (i.e., um EDR não se importa com chamadas não respaldadas para LoadLibrary etc.), caso em que isso poderia ser modificado para usar um equivalente PICO (=='BOF') do Draugr, que é muito mais simples.
O Eden loader deliberadamente tenta manter o 'Callgate' desacoplado do loader. Isso é por design para modularidade, pois a ideia é que você possa trocar BOFs BeaconGate/callgate. Portanto, o código do callgate Draugr está todo contido em seu próprio arquivo objeto. Ao substituir isso por outra 'capacidade', você poderia mudar drasticamente as TTPs do Eden.
O Eden loader não usa recursos mais recentes do Crystal Palace por escolha. Como exemplo, o mergelib pode ser usado com a biblioteca compartilhada do Crystal Palace, LibTCG. No entanto, observe que isso significa que você perde a capacidade de depurar seu código.

Troubleshooting

A técnica de page streaming pode impactar o desempenho do Beacon para certos comandos (i.e., por padrão, a injeção de processo levará ~1min(!) com 4 páginas visíveis configuradas). Você pode aumentar #define MAXVISIBLE em guardexec.h para resolver a maioria dos problemas (o valor padrão para Eden é 6). Como uma informação geral, o page streaming pode causar problemas com técnicas de injeção de processo (especialmente se elas dependem de temporização).

Why Release This?

https://aff-wg.org/2025/03/13/the-security-conversation/

O Eden loader é construído com Crystal Palace (https://tradecraftgarden.org/crystalpalace.html) e faz uso dos seguintes projetos:

Raphael Mudge's page streaming technique: https://tradecraftgarden.org/pagestream.html.
NtDallas' Draugr call stack spoofing technique: https://github.com/NtDallas/Draugr.
Sleepmask-VS que contém exemplos de BOF callgates. Essas 'capacidades' foram reaproveitadas e modificadas para compilar para PIC para uso com o Crystal Palace.
O Crystal-Kit do Rastamouse é um projeto similar que também utiliza um BOF Draugr BeaconGate, mas com uma implementação diferente.

Por último, agradecimentos a @rastamouse cujo blog sobre o Crystal Palace ajudou durante o desenvolvimento.

eden

Mais Populares