Descubriendo Tradecraft Garden

Table of Contents

Aprovechando las ofertas del reciente Black Friday, decidí adquirir el curso CRTL (Certified Red Team Lead) de ZeroPointSecurity. Si bien el material del curso es denso y técnico (como era de esperar de Rasta Mouse ), una de las primeras joyas con las que me he topado no está oculta detrás de un paywall, sino que es un proyecto público que merece mucha más atención: Tradecraft Garden .

Este repositorio es, en esencia, un entorno de desarrollo o “patio de recreo” diseñado para simplificar la creación de Shellcode y Position Independent Code (PIC) utilizando C y Makefiles.

En este post, vamos a configurar el entorno y crear un ejemplo básico para entender el flujo de trabajo.

🛠️ ¿Qué es Tradecraft Garden?

Tradecraft Garden es un proyecto desarrollado por Raphael Mudge (El mismo creador de CobaltStrike) que resuelve uno de los dolores de cabeza más comunes al desarrollar implantes o loaders personalizados: la compilación cruzada y la extracción de shellcode.

Normalmente, escribir un payload en C que pueda inyectarse directamente en memoria requiere lidiar con alineación de pila, resolución dinámica de APIs (buscando en el PEB) y evitar direcciones absolutas. Tradecraft Garden abstrae la complejidad del proceso de compilación utilizando Mingw-w64 y scripts de Make bien estructurados, permitiéndonos centrarnos en la técnica.

⚙️ Instalación del Entorno

Para este ejemplo, utilizaremos un entorno Linux (o WSL en Windows como en mi caso), que es donde estas herramientas brillan por su facilidad de automatización.

Para instalar WSL abrir una consola de Powershell con permisos de Administrador.

wsl --install

Nota: Deberemos de reiniciar la computadora una vez. La instalación se reanudará automáticamente al reiniciar (si no, volver a ejecutar el comando).

Si te encuentras en una máquina virtual, asegurate de tener habilitada la Virtualización Anidada, en VMWare se encuentra dentro de Settings > Processors > Virtualize Intel VT-x/EPT or AMD-V/RVI:

Necesitamos instalar las siguientes dependencias:

sudo apt update
sudo apt install git mingw-w64 nasm make openjdk-11-jdk zip -y

git: Para clonar repositorios.
mingw-w64: Suite de compiladores cruzados (Cross-compilation).
nasm: Ensamblador x86/x64. Esencial para escribir o modificar shellcode.
make: Automatización de tareas de compilación.
openjdk-11-jdk: Kit de desarrollo de Java (versión 11).
zip: Utilidad de compresión.

⚠️ IMPORTANTE CONFIGURACIÓN DEFENDER ⚠️

En nuestro entorno de pruebas, nos aseguramemos de que en Windows Defender:

Tener desactivada la protección en la nube.
Deshabilitar el envío de muestras.
Agregar una exclusión a nuestra carpeta de archivos TradeCraft (C:\tcg)
Agregar una exclusión para los procesos run.x86.exe y run.x64.exe.

🧪 Ejemplo Práctico: Generando un cargador simple con Crystal Palace

Cuando programamos en C, el sistema operativo resuelve las librerías por nosotros. En el mundo del PIC (Position Independent Code), esto no ocurre. Sin embargo, aquí es donde Crystal Palace brilla, en lugar de obligarnos a calcular hashes ROR13 manualmente o crear stack strings letra por letra, nos permite usar una sintaxis especial.

El framework utiliza el formato MODULE$Function. Cuando el compilador ve esto, y lo procesamos con el archivo de especificación (.spec), automáticamente generará los hashes necesarios.

📦 Preparación y Compilación

Primero, clonamos el repositorio o descargamos las fuentes de Tradecraft Garden. En mi caso, he organizado los archivos en C:\tcg (que en WSL se ve como /mnt/c/tcg). Tenemos dos componentes principales: dist (donde se encuentra el linker Crystal Palace) y tcg (el código fuente de los ejemplos).

Ambos podeis descargarlos desde la web de Tradecraft Garden.

Antes de poder usar los ejemplos, debemos compilarlos. Gracias a los Makefiles incluidos, esto es trivial:

cd /mnt/c/tcg/tcg
make clean; make

Esto compilará todos los ejemplos de loaders, generando los archivos objeto necesarios y las DLLs de prueba.

🔨 Creando nuestro primer PIC

Vamos a utilizar el ejemplo más básico: simple_rdll. Este loader simplemente carga una DLL y ejecuta su punto de entrada. Necesitaremos tres cosas para el comando de enlace:

El archivo de especificación (.spec): Define cómo se construye el loader.
La DLL del payload: En este caso, usaremos una DLL de prueba que simplemente lanza un mensaje “Hello from Hackpuntes”.
El archivo de salida: Nuestro shellcode final (hackpuntes.bin).

Ejecutamos el linker desde la carpeta dist:

# Sintaxis: ./link [spec] [payload_dll] [output_bin]
./link ../tcg/simple_rdll/loader.spec ./demo/test.x64.dll hackpuntes.bin

Si todo ha ido bien, tendremos un archivo hackpuntes.bin que contiene nuestro código independiente de la posición listo para ser inyectado.

🐚 Probando el Shellcode

Para verificar que nuestro shellcode funciona sin necesidad de inyectarlo en un proceso real complejo, Tradecraft Garden incluye una utilidad llamada run.x64.exe. Esta herramienta carga el archivo .bin en memoria y salta a su ejecución.

# Ejecutar desde WSL invocando el ejecutable de Windows
./demo/run.x64.exe hackpuntes.bin

Al ejecutarlo, la ejecución se pausa permitiéndonos adjuntar un depurador si quisiéramos. Al presionar Enter, nuestro shellcode se ejecuta y vemos el MessageBox. ¡Éxito!

🛡️ Execution Guardrails: Evasión Avanzada

Aquí es donde las cosas se ponen interesantes. Un usuario malintencionado podría querer que su payload solo se ejecute en la máquina objetivo específica, evitando así que analistas de malware o sandboxes automáticas puedan ejecutarlo y analizarlo.

El ejemplo simple_rdll_guardrail demuestra cómo implementar “Execution Guardrails”. Este loader descifra el payload utilizando una clave derivada del entorno. Si la clave no coincide, el payload permanece cifrado y el programa termina silenciosamente.

En este ejemplo, la clave se deriva del Número de Serie del Volumen C:.

🗝️ Obteniendo la clave del entorno

Curiosamente, la herramienta run.x64.exe nos ayuda a obtener este valor si la ejecutamos sin argumentos:

./demo/run.x64.exe

El output nos mostrará algo como ENVKEY=d90c3060d90c3060. Copiamos este valor.

🔗 Enlazando con Variables

Ahora, debemos decirle al linker Crystal Palace que utilice esa clave para cifrar nuestro payload durante la generación. Pasamos la variable ENVKEY antes de los argumentos del linker:

# Pasamos la clave específica de mi entorno
./link ../tcg/simple_rdll_guardrail/stage1.spec ./demo/test.x64.dll hackpuntes_guard.bin ENVKEY=d90c3060d90c3060

./demo/run.x64.exe hackpuntes_guard.bin

Cuando ejecutamos este nuevo hackpuntes_guard.bin en mi máquina, funciona perfectamente porque la clave derivada en tiempo de ejecución coincide con la clave usada para cifrar.

🚫 ¿Qué pasa si el entorno no es el correcto?

Para simular que un analista está intentando ejecutar esto en un laboratorio diferente (o si cambiamos la clave manualmente al compilar), podemos ver el comportamiento defensivo.

Si intento generar el payload con una clave falsa (cambiando los últimos 4 valores por 1337):

./link ../tcg/simple_rdll_guardrail/stage1.spec ./demo/test.x64.dll hackpuntes_guard.bin ENVKEY=d90c3060d90c1337

Y lo ejecuto:

./demo/run.x64.exe hackpuntes_guard.bin

El programa lee los bytes, pero al no poder descifrar correctamente el siguiente paso del loader, sale sin mostrar el mensaje ni crashear de forma sospechosa.

Conclusión

Tradecraft Garden y Crystal Palace nos muestran técnicas que antes requerían un conocimiento profundo de la estructura PE y ensamblador. La capacidad de modularizar loaders, aplicar técnicas de evasión (como los guardrails) y generar PIC de manera automatizada es un recurso indispensable para cualquier equipo de Red Team.

Os animo a explorar el código fuente en tcg, especialmente guardrail, para entender cómo se implementa la lógica de descifrado en C puro sin depender de librerías externas.

¡Happy Hacking!