Eden

Eden loader es un PoC UDRL para Cobalt Strike construido con Crystal Palace que combina la técnica de page streaming de Raphael Mudge con una puerta de llamada modular (actualmente una versión PIC del BOF de llamada Draugr de Sleepmask-VS).

El objetivo de Eden loader es:

Demostrar el poder de usar Crystal Palace para combinar (y reutilizar) 'capacidades' para desarrollar rápidamente loaders/herramientas personalizados
Servir como recurso de ejemplo para que otros construyan sobre él
Ayudar a los profesionales de seguridad a entender cómo funcionan los UDRL (es completamente depurable)
Informar/estimular la conversación de seguridad

Para más información sobre Eden loader, consulta el blog adjunto.

Nota: El propósito de Eden es demostrar la idea de usar Crystal Palace para combinar diferentes 'unidades de ejecución' (es decir, capacidades) para crear loaders personalizados. No está diseñado para ser un loader 'evasivo' completo y, por lo tanto, carece de varias características básicas de OPSEC por diseño. Por ejemplo, utiliza memoria RWX y no rastrea/enmascara la memoria heap de Beacon (y por lo tanto es vulnerable a firmas YARA como esta).

Guía de inicio rápido

Nota: Esta guía de inicio rápido asume que has descargado/construido Crystal Palace y completado los siguientes pasos para configurar tu entorno de desarrollo.

Primero deberás configurar el siguiente ajuste de Malleable C2:

stage {
    set sleep_mask "false";
}

Abre una terminal WSL en la raíz del repositorio y construye Eden loader: make clean; make.
Copia crystalpalace.jar a tu directorio del cliente de Cobalt Strike.
Carga eden.cna en el cliente de Cobalt Strike.
La próxima vez que exportes un payload, Eden se aplicará automáticamente. Puedes verificarlo revisando la salida en la consola de scripts:

[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 soporta Beacons HTTP(S), DNS y Pivot.

Guía de depuración

Una limitación de Crystal Palace en el momento del lanzamiento es que actualmente solo soporta archivos objeto construidos con mingw. Si intentas usar un COFF construido con MSVC o Clang, típicamente obtendrás errores de reubicación. Esto puede ser frustrante ya que mingw no soporta directamente archivos pdb y por lo tanto puede ser difícil depurar al escribir tácticas complejas de Windows. Sin embargo, puedes añadir la opción -g a tu Makefile para incrustar información de depuración en las compilaciones ejecutables. Esto permite avanzar paso a paso por tu código en WinDbg. Para más información sobre este proceso, se recomienda leer el siguiente blog de Rastamouse.

Este repositorio utiliza el enfoque anterior para construir una compilación de depuración de Draugr (draugr.x64.exe) y el código de page streaming (guardexec.x64.exe) por defecto. La compilación de depuración de Draugr no tiene dependencias y por lo tanto se construirá de inmediato, sin embargo, si deseas avanzar paso a paso/depurar el código de page streaming/hooks IAT, deberás seguir los pasos a continuación:

1. Exportar Beacon sin loader:

Carga debug/export_beacon_with_no_ldr.cna en tu cliente de CS y exporta un Beacon raw x64 (HTTP) sin etapa en el directorio /eden/debug/. Esto exportará una DLL de Beacon sin un loader reflectivo que podemos usar para simular el punto de entrada guardexec.
(En WSL) $ xxd -i ./beacon_x64.bin > debug_beacon.h

2. Exportar el stub PIC de Draugr desde Crystal Palace:

Para hacer esto, necesitarás ejecutar Crystal Palace desde WSL mediante $ ./piclink /<path>/eden/debug/draugr.spec x64 /<path>/eden/debug/draugr.bin. Esto hará que Crystal Palace genere solo el stub PIC de Draugr que podemos usar para simular el punto de entrada guardexec.
(En WSL) $ xxd -i ./draugr.bin > debug_druagr.h

3. Comenzar la depuración en WinDbg

Reconstruye Eden después de realizar los pasos anteriores: make clean;make
Abre WinDbg y selecciona lanzar ejecutable (/eden/bin/draugr.exe o /eden/bin/guardexec.exe)
Selecciona Open source file y elige el archivo .c relevante (por ejemplo, guardexec.c si estás depurando el código de page streaming).
Ahora puedes avanzar paso a paso / establecer puntos de interrupción para el binario independiente de spoofing de pila de llamadas Draugr o para un Beacon en vivo con hooks IAT. Como advertencia, el enmascaramiento no funcionará correctamente en modo de depuración ya que requiere que Crystal Palace parchee una clave durante la generación del payload.

Nota: No hay ejecutable de depuración para el loader ya que no hay una forma obvia de hacer que Crystal Palace exporte payloads de depuración para cosas como DLLs encriptadas y sus claves. Por lo tanto, se vuelve no trivial pasar búferes PIC 'encriptados' simulados.

Consideraciones de diseño

Eden loader está principalmente diseñado para demostrar el poder de Crystal Palace combinando diferentes 'capacidades' para crear un loader novedoso. Esta idea podría llevarse mucho más allá de lo que se presenta en este repositorio (por ejemplo, un loader PIC 'estático' totalmente personalizable mediante módulos COFF (guardarraíles, puertas de llamada, ofuscación de sleep, etc.)).
Eden loader usa una versión PIC de Draugr explícitamente para poder falsear cada llamada del ciclo de vida de Beacon (es decir, las llamadas VirtualAlloc / LoadLibrary utilizadas durante el proceso de carga reflectiva). En algunos casos, esto puede ser excesivo (por ejemplo, un EDR no se preocupa por llamadas no respaldadas a LoadLibrary, etc.), en cuyo caso esto podría modificarse para usar un equivalente PICO (=='BOF') de Draugr que es mucho más simple.
Eden loader deliberadamente intenta mantener el 'Callgate' desacoplado del loader. Esto es por diseño para modularidad, ya que la idea es que puedas intercambiar BOFs de BeaconGate/callgate. Por lo tanto, el código de callgate de Draugr está completamente autocontenido en su propio archivo objeto. Al reemplazar esto con otra 'capacidad', podrías cambiar drásticamente las TTPs de Eden.
Eden loader no utiliza las características más recientes de Crystal Palace por elección. Como ejemplo, mergelib se puede usar con la biblioteca compartida de Crystal Palace, LibTCG. Sin embargo, ten en cuenta que esto significa que pierdes la capacidad de depurar tu código.

Solución de problemas

La técnica de page streaming puede afectar el rendimiento de Beacon para ciertos comandos (por ejemplo, por defecto, la inyección de procesos tomará ~1min(!) con 4 páginas visibles configuradas). Puedes aumentar #define MAXVISIBLE en guardexec.h para resolver la mayoría de los problemas (el valor por defecto para Eden es 6). Como información general, el page streaming puede causar problemas con las técnicas de inyección de procesos (especialmente si dependen del tiempo).

¿Por qué publicar esto?

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

Trabajo relacionado/Créditos

Eden loader está construido con Crystal Palace (https://tradecraftgarden.org/crystalpalace.html) y hace uso de los siguientes proyectos:

Técnica de page streaming de Raphael Mudge: https://tradecraftgarden.org/pagestream.html.
Técnica de spoofing de pila de llamadas de NtDallas: https://github.com/NtDallas/Draugr.
Sleepmask-VS que contiene ejemplos de BOF callgates. Estas 'capacidades' fueron reutilizadas y modificadas para compilar a PIC para su uso con Crystal Palace.
El Crystal-Kit de Rastamouse es un proyecto similar que también utiliza un BOF Draugr BeaconGate pero con una implementación diferente.

Por último, agradecimientos a @rastamouse cuyo blog sobre Crystal Palace ayudó durante el desarrollo.

eden

Más Populares