Mythic C2, Xenon y Crystal Palace

Introducción

Los frameworks de mando y control, los agentes, los perfiles de comunicación y los loaders resuelven problemas diferentes. Cuando todas esas responsabilidades se concentran en un único proyecto, cualquier cambio en la forma de construir, transportar o cargar una capacidad puede obligar a modificar el conjunto completo. Mythic, Xenon y Crystal Palace resultan interesantes precisamente porque permiten estudiar una separación más clara entre esas capas.

Mythic proporciona la plataforma de operación y los contratos de integración. Xenon proporciona un agente de Windows compatible con esa plataforma. Crystal Palace proporciona un enlazador y un lenguaje de especificación para construir y combinar componentes compatibles, incluidos loaders de DLL expresados como código independiente de posición.

Esta combinación no debe presentarse como “la mejor” arquitectura ni como una garantía de evasión. Xenon se encuentra en una fase temprana de desarrollo y su propio repositorio advierte que la configuración predeterminada no se considera segura desde el punto de vista OPSEC y que pueden existir problemas de memoria. Crystal Palace tampoco es un bypass de EDR: es un enlazador especializado que facilita la composición, transformación e instrumentación de código compatible.

El objetivo de este artículo es explicar:

cómo organiza Mythic sus componentes;
qué papel ocupa Xenon dentro de esa arquitectura;
cómo funciona la integración UDRL de Xenon;
qué aporta Crystal Palace durante la construcción;
qué diferencias existen entre el loader principal, las capacidades de postexplotación y los kits de inyección;
qué partes dependen de una versión o implementación concreta;
qué límites deben reconocerse al evaluar esta cadena.

No es una guía de despliegue ni un tutorial de evasión. Los ejemplos deben estudiarse únicamente en laboratorios propios o entornos con autorización expresa.

1. Separación de responsabilidades

Una cadena de este tipo puede dividirse conceptualmente en cinco capas:

Plataforma de operación: administra usuarios, payloads, callbacks, tareas, archivos, trazabilidad y datos operativos.
Agente: implementa la lógica que se ejecuta en el sistema Windows y los comandos que admite.
Perfil C2: define el canal y el formato de comunicación entre el agente y la infraestructura.
Cadena de construcción: compila el agente y, si corresponde, combina la capacidad con un loader compatible.
Entrega o ejecución: coloca el artefacto en el contexto donde se ejecutará.

Mythic desempeña principalmente el primer papel y proporciona los contratos para conectar los siguientes. Xenon ocupa el segundo. Los perfiles HTTPX, SMB y TCP cubren parte del tercero. Crystal Palace participa en el cuarto cuando Xenon genera una salida de tipo shellcode mediante un reflective DLL loader basado en PIC.

La quinta capa queda fuera del alcance de este artículo. El hecho de que Crystal Palace produzca un blob PIC no determina cómo se ejecutará, en qué proceso, con qué permisos de memoria o mediante qué mecanismo. Esas decisiones pueden introducir indicadores propios y deben evaluarse por separado.

Esta separación no elimina todas las dependencias. Un agente y un perfil C2 siguen necesitando un contrato común. Un loader debe entender la capacidad que va a cargar. Una DLL puede imponer requisitos sobre su punto de entrada, hilos, TLS, runtime o ciclo de vida. “Modular” no significa “intercambiable sin adaptación”.

2.1 Arquitectura general

Mythic se define como una plataforma C2 multijugador y multiplataforma para operaciones de red team. Su documentación enfatiza una arquitectura conectable en la que agentes, canales de comunicación y extensiones pueden incorporarse como componentes separados.

A grandes rasgos, la plataforma incluye:

una interfaz web basada en React;
un servidor principal escrito en Go;
APIs GraphQL y WebSockets;
PostgreSQL para persistencia;
RabbitMQ para la comunicación entre servicios;
contenedores separados para agentes y perfiles C2;
gRPC para determinadas operaciones directas entre componentes y el servidor;
un proxy inverso Nginx;
documentación Hugo por agente y perfil;
herramientas adicionales como Jupyter y la consola GraphQL.

Es importante no describir gRPC como si funcionara “a través de RabbitMQ”. Son mecanismos distintos. RabbitMQ actúa como bus de mensajería entre servicios, mientras que gRPC se utiliza para determinadas comunicaciones directas y transferencia de datos.

Los componentes pueden ejecutarse en el host principal, en otros sistemas o en máquinas virtuales, siempre que puedan satisfacer los contratos de conexión de Mythic. Esta flexibilidad resulta útil cuando una cadena de compilación necesita dependencias o un sistema operativo específico.

2.2 Agentes y perfiles C2

Mythic no incorpora de forma predeterminada todos los agentes y perfiles. Estos se instalan como servicios separados, normalmente dentro de Mythic/InstalledServices. Un contenedor de agente define sus comandos, parámetros y proceso de construcción. Un contenedor de perfil C2 implementa un canal de comunicación compatible.

La separación permite sustituir o actualizar un perfil sin reescribir toda la plataforma. Sin embargo, el agente debe incorporar la lógica y la configuración necesarias para usar el perfil seleccionado. Por tanto, la relación es menos acoplada que en un diseño monolítico, pero no inexistente.

2.3 Seguimiento y contexto operativo

Mythic no se limita a recibir los bytes finales de un payload. La plataforma también registra información como:

parámetros de los perfiles C2;
comandos incluidos y sus versiones;
identidad del creador;
fecha y contexto de construcción;
tareas emitidas;
callbacks asociados;
comentarios y datos de operación;
artefactos declarados por agentes y comandos.

Por ello, reducir la integración a “unos bytes y un código de estado” sería incompleto. La respuesta del constructor es importante, pero forma parte de un contrato mayor entre el payload type y la plataforma.

3.1 Responsabilidad del constructor

Cada payload type de Mythic implementa una lógica de construcción. Esa lógica recibe la configuración seleccionada, prepara los archivos necesarios, invoca las herramientas del proyecto y devuelve el resultado a Mythic.

El constructor puede, según la implementación:

generar cabeceras de configuración;
seleccionar módulos o comandos;
compilar código;
invocar Makefiles;
procesar archivos proporcionados por el operador;
llamar a enlazadores externos;
recoger mensajes de progreso y errores;
devolver el artefacto final y sus metadatos.

Esto proporciona la superficie de integración con Crystal Palace. No porque Mythic conozca internamente el lenguaje .spec, sino porque el constructor de Xenon puede invocar la cadena correspondiente y devolver su resultado.

3.2 Parámetros dinámicos

Mythic permite que un payload type defina parámetros de construcción con distintos tipos, condiciones y dependencias. Una interfaz puede mostrar opciones adicionales únicamente cuando el operador selecciona un formato compatible.

En el caso de Xenon, la documentación confirma que el formato shellcode puede utilizar un UDRL personalizado basado en Crystal Palace y que el código fuente del loader se proporciona como un archivo ZIP. Los nombres internos exactos de los parámetros y sus condiciones deben comprobarse en la versión concreta del repositorio. No conviene convertir un ejemplo conceptual de ChooseOne, Boolean o File en una reproducción literal del código sin citar el commit correspondiente.

3.3 Archivos subidos

Cuando una construcción acepta un archivo, Mythic puede almacenarlo y ponerlo a disposición del constructor mediante sus APIs y contratos internos. El constructor decide cómo validarlo y procesarlo.

En un UDRL esto plantea obligaciones de seguridad para el propio servidor de construcción. Un ZIP puede incluir código fuente y un Makefile que se ejecutará dentro del entorno de build. Por tanto, el sistema debe tratarlo como código no confiable y aplicar controles como:

aislamiento del contenedor;
límites de recursos;
validación de rutas al descomprimir;
limpieza de directorios temporales;
registro de versiones y hashes;
control de quién puede iniciar una construcción;
revisión del contenido antes de usarlo en entornos sensibles.

La flexibilidad del pipeline también aumenta la superficie de la cadena de suministro.

4.1 Estado y propósito

Xenon es un agente de Windows para Mythic escrito en C y descrito por sus autores como similar a Cobalt Strike desde el punto de vista de la experiencia operativa. Soporta inclusión modular de comandos, perfiles C2 maleables, UDRL basados en Crystal Palace y kits de inyección compatibles con el formato de Cobalt Strike.

El repositorio oficial incluye una advertencia explícita: Xenon se encuentra en una fase temprana, no realiza afirmaciones de evasión, su configuración predeterminada no se considera OPSEC-safe y pueden existir problemas de memoria. Cualquier análisis responsable debe conservar esta advertencia.

4.2 Formatos de salida

Xenon admite salidas exe, dll y shellcode para Windows x86-64. Cada formato cambia el contrato de ejecución, pero no existe una jerarquía universal en la que shellcode sea siempre “más evasivo”.

EXE

Un EXE es una imagen PE que el cargador de Windows puede procesar de forma convencional. Expone estructuras estáticas y puede generar un artefacto en disco, pero también ofrece un contexto de carga normal y metadatos coherentes con el sistema operativo.

DLL

Una DLL también es una imagen PE. Necesita un componente o proceso que la cargue y un contrato de punto de entrada. Su comportamiento depende de cómo se invoque y de lo que haga durante la inicialización.

No debe afirmarse que una DLL sea automáticamente más discreta que un EXE. Una carga anómala, un abuso de un binario del sistema o un punto de entrada incorrecto pueden resultar muy visibles.

Shellcode

En Xenon, la salida shellcode actual puede construirse combinando la DLL del agente con un reflective DLL loader basado en Crystal Palace. El contenedor exterior puede ser un blob PIC sin cabecera PE propia. La DLL incorporada sigue teniendo las estructuras que el loader necesita interpretar, aunque pueda almacenarse como recurso o encontrarse enmascarada durante una fase de la construcción.

Este formato traslada responsabilidades al loader:

analizar la DLL;
preparar sus secciones;
resolver dependencias;
aplicar permisos;
respetar el contrato de entrada;
gestionar el ciclo de vida.

Un blob ejecutado desde memoria privada con permisos inadecuados puede ser más sospechoso que una imagen PE cargada normalmente. El formato por sí solo no determina el resultado defensivo.

5. Comandos y modelos de ejecución

5.1 Comandos en proceso

Xenon incluye operaciones como navegación de archivos, consulta de identidad, enumeración de procesos, transferencia de archivos, administración del intervalo de comunicación y enlace con otros agentes.

Algunas operaciones se ejecutan dentro del proceso del agente. Esto evita crear un proceso adicional, pero cualquier fallo puede afectar directamente a la estabilidad del agente.

5.2 BOF y ensamblados .NET

inline_execute y inline_execute_assembly no son equivalentes:

inline_execute carga y ejecuta un Beacon Object File o COFF compatible.
inline_execute_assembly utiliza una capacidad BOF para alojar un ensamblado .NET dentro del proceso.

Por tanto, no es correcto afirmar que inline_execute ejecuta directamente archivos como SharpUp.exe o Seatbelt.exe. Esos ensamblados corresponden al segundo modelo.

5.3 Fork and run

La documentación de Xenon identifica algunas capacidades de postexplotación que siguen un patrón fork and run: se crea un proceso sacrificial, se entrega una capacidad y se recupera su resultado.

La implementación no es uniforme para todos los comandos. La documentación actual indica, según la sección consultada, que determinadas capacidades utilizan DLL convertidas a PIC con Crystal Palace, mientras otras incluyen advertencias relacionadas con shellcode de Donut. Esto obliga a documentar la versión exacta y el comando analizado en vez de afirmar que toda la postexplotación pasa por Crystal Palace.

5.4 Process Injection Kit

Xenon ofrece register_process_inject_kit para registrar un BOF de inyección compatible con el contrato de los Process Injection Kits de Cobalt Strike.

Este mecanismo es distinto del UDRL principal:

el UDRL define cómo se combina y carga la DLL principal en la salida shellcode;
el Process Injection Kit define cómo determinadas capacidades se entregan a otro proceso durante la operación;
los comandos inline pueden no usar ninguno de esos flujos.

Separarlos evita atribuir al loader primario decisiones que pertenecen a la postexplotación.

6. Perfiles C2 admitidos por Xenon

6.1 HTTPX

Xenon admite el perfil HTTPX y documenta opciones como:

dominios de callback;
rotación de dominios;
umbrales de fallback;
intervalo y jitter;
configuración JSON o TOML;
localización del mensaje en cabeceras, cookies, parámetros o cuerpo;
transformaciones como Base64, Base64URL, XOR y NetBIOS;
cabeceras y parámetros personalizados.

Estas opciones permiten adaptar el formato de la comunicación. No garantizan que el tráfico parezca legítimo ni que supere controles de red. La temporización, reputación de infraestructura, certificados, destinos y comportamiento global siguen siendo observables.

6.2 SMB y TCP

Xenon también admite perfiles SMB y TCP para agentes enlazados. Esto permite construir topologías en las que un agente se comunica con la infraestructura a través de otro.

La disponibilidad de un perfil no implica que todas sus funciones sean idénticas a HTTPX. Cada transporte tiene sus propios requisitos, límites y señales defensivas.

7.1 Qué es el UDRL en este contexto

En Xenon, un User-Defined Reflective Loader es un proyecto de loader basado en Crystal Palace que el operador puede proporcionar durante la construcción de una salida shellcode.

La documentación actual resume el flujo así:

Xenon compila la DLL del agente.
Mythic descomprime el proyecto UDRL.
El proyecto se compila mediante su Makefile.
Crystal Palace combina el UDRL y la DLL en un blob PIC.

Este es el contrato esencial. Detalles como rutas temporales, nombres exactos de artefactos y órdenes internas pueden variar entre versiones.

7.2 Estructura mínima documentada

El ZIP debe contener, como mínimo:

loader.zip
├── Makefile
├── loader.spec
└── archivos necesarios para construir el loader

El ejemplo básico enlazado por Xenon incluye:

.
├── Makefile
├── libtcg.x64.zip
├── loader.spec
└── src
    ├── loaddll.c
    ├── loader.c
    ├── loaderdefs.h
    └── tcg.h

Archivos como hooks.c, spoof.c, cleanup.c o un stub de ensamblador pueden formar parte de una implementación avanzada, pero no son requisitos universales del formato UDRL.

7.3 Responsabilidad del Makefile

El Makefile debe proporcionar un objetivo predeterminado ejecutable mediante make. Su función es producir los objetos compatibles que la especificación utilizará.

La documentación de Crystal Palace indica que sus casos soportados esperan principalmente C compilado con MinGW-w64. No debe asumirse compatibilidad automática con objetos de MSVC, Clang, Rust, Go u otros lenguajes.

7.4 Responsabilidad de `loader.spec`

loader.spec define cómo se combinan los objetos y recursos. Puede, según el proyecto:

cargar y fusionar módulos;
solicitar la generación de PIC;
configurar DFR;
incorporar LibTCG;
enlazar la DLL como recurso;
aplicar transformaciones compatibles;
registrar hooks;
exportar el blob resultante.

La presencia de Crystal Palace no implica que todas estas funciones estén activas. Un loader básico puede limitarse a cargar la DLL. Otro proyecto puede añadir servicios e instrumentación. El resultado debe describirse según su especificación real.

8.1 Enlazado y composición

Crystal Palace es un enlazador y un lenguaje de script especializado para código independiente de posición, capacidades de postexplotación y componentes de instrumentación. Su objetivo declarado es separar capacidad y tradecraft mediante convenciones compatibles.

Puede combinar objetos y bibliotecas, enlazar recursos, apoyar la resolución dinámica de funciones y producir salidas PIC o PICO. También incluye transformaciones de enlace, generación de información de desenrollado y herramientas para estudiar partes invariantes.

8.2 No convierte cualquier COFF

La documentación oficial especifica que Crystal Palace espera principalmente objetos COFF compilados desde C con MinGW-w64, con restricciones sobre características del lenguaje y optimizaciones. Por tanto, no es correcto afirmar que cualquier archivo COFF pueda transformarse automáticamente.

8.3 Hooks

Crystal Palace incluye mecanismos como attach, redirect, addhook y preserve. Su efecto depende de la arquitectura de la especificación.

En particular, addhook registra hooks que un resolver compatible puede consultar mediante el mecanismo correspondiente. Registrar un hook no reescribe por sí solo todas las importaciones de una DLL. El loader debe integrar la consulta durante su proceso de resolución.

Por eso es impreciso decir que “la IAT del agente se reasigna completamente” en todos los UDRL. Puede ocurrir en una implementación que intercepte y controle la resolución de las importaciones relevantes, pero no es una propiedad automática de Xenon ni de Crystal Palace.

8.4 Transformaciones

Opciones como +mutate, +regdance, +blockparty, +shatter y +disco, junto con magic e ised, pueden modificar partes de la representación binaria.

Estas transformaciones no garantizan que:

todos los bytes cambien entre construcciones;
no existan partes invariantes;
ninguna regla YARA pueda detectar varias muestras;
el comportamiento deje de ser observable;
el artefacto sea único en sentido absoluto.

La formulación correcta es que pueden aumentar la variabilidad y dificultar determinadas firmas rígidas, dependiendo del código y de las opciones utilizadas.

8.5 Generación YARA

Crystal Palace puede generar reglas YARA para partes invariantes del programa. Esta función sirve como instrumento de análisis. No debe presentarse como un “self-test” universal ni como una prueba de que la construcción no será detectada.

8.6 Punto de entrada

Algunos proyectos emplean +gofirst para situar go() al comienzo del blob. Esto crea un contrato sencillo con el componente que transferirá la ejecución.

No todos los artefactos de Crystal Palace tienen necesariamente ese contrato. Debe comprobarse en la especificación utilizada.

9. Pipeline de construcción de Xenon

9.1 Flujo general documentado

Sin fijar rutas internas que puedan cambiar, el flujo puede resumirse así:

Mythic UI
   │
   ├── parámetros del payload
   ├── comandos seleccionados
   ├── configuración C2
   └── UDRL opcional en ZIP
           │
           ▼
Constructor de Xenon
   │
   ├── prepara la configuración
   ├── compila la DLL del agente
   ├── descomprime el UDRL
   ├── ejecuta su Makefile
   └── invoca Crystal Palace
           │
           ▼
Blob PIC que combina loader y DLL
           │
           ▼
Respuesta de construcción a Mythic

Este esquema refleja la documentación pública de Xenon sin asumir nombres concretos de directorios, artefactos o wrappers.

9.2 Cambios de versión

Crystal Palace consolidó en junio de 2026 sus comandos bajo la interfaz cpl. Los scripts antiguos pueden seguir utilizando wrappers propios, integraciones Java o nombres anteriores. Por eso, un artículo que quiera reproducir comandos exactos debe fijar:

versión o fecha de Crystal Palace;
commit de Xenon;
contenido del Makefile;
especificación utilizada;
comando real ejecutado por el constructor.

No es suficiente copiar ./link loader.spec de un proyecto antiguo y presentarlo como la interfaz universal actual.

9.3 Resultado

El resultado exterior puede ser un blob PIC. Sus propiedades dependen del UDRL:

punto de entrada;
recursos incorporados;
transformaciones;
estrategia de carga;
resolución de importaciones;
permisos de memoria;
gestión de errores;
limpieza y ciclo de vida.

Crystal Palace no garantiza automáticamente sleep masking, call stack spoofing, module stomping ni otras técnicas. Esas características deben existir en el código y la especificación del loader seleccionado.

10. Crystal-Kit-Xenon

Crystal-Kit-Xenon es un fork de Crystal Kit adaptado para trabajar con Xenon. El repositorio contiene componentes diferenciados para el loader y la postexplotación y ha recibido cambios para ajustarse al comportamiento actual de Xenon, incluido el uso de SleepEx en versiones recientes.

Esto demuestra dos cosas:

La arquitectura permite adaptar componentes de Crystal Palace a Xenon.
La compatibilidad no es permanente ni automática. Si el agente cambia la API utilizada para su ciclo de espera, un hook diseñado para una función anterior puede dejar de activarse.

Por ello, las afirmaciones sobre el punto de entrada, el ciclo de suspensión o los hooks deben vincularse al commit probado. No debe asumirse que una explicación escrita para Cobalt Strike se aplica sin cambios a Xenon.

Tampoco debe mezclarse Xenon, escrito en C, con requisitos del runtime de Go observados en otros agentes. Cualquier discusión sobre TLS de Go pertenece a una integración diferente y necesita evidencia específica. No forma parte del contrato general de Crystal-Kit-Xenon.

11. Postexplotación y loaders personalizados

11.1 No existe un único flujo

La documentación de Xenon describe varias rutas:

BOF ejecutados inline;
ensamblados .NET alojados inline mediante una capacidad BOF;
comandos fork and run;
DLL convertidas o envueltas para ejecución;
capacidades que pueden utilizar shellcode de Donut;
kits de inyección registrados por el operador.

Por tanto, un diagrama único que afirme que todas las acciones pasan por una función, un loader y un formato específico quedará incompleto o desactualizado.

11.2 Loader principal frente a postexplotación

El UDRL utilizado para construir la salida shellcode principal resuelve la carga inicial del agente. Un loader de postexplotación, si la implementación lo admite, resuelve un contrato distinto:

capacidad diferente;
argumentos diferentes;
ciclo de vida más corto;
posible recuperación de salida;
potencial ejecución en otro proceso.

Aunque ambos puedan utilizar Crystal Palace, no son intercambiables automáticamente.

11.3 Necesidad de fijar una versión

Si se documenta un pipeline interno, deben indicarse:

commit de Xenon;
ruta del módulo;
nombre y firma de la función;
formato de sus argumentos;
loader utilizado;
tipo de capacidad;
resultado esperado.

Sin esos datos, nombres como crystal_utilities.py, %ARGFILE o una función de conversión concreta solo deberían presentarse como detalles de una versión examinada, no como arquitectura estable.

12. La capa de entrega queda fuera del pipeline

Un blob PIC necesita un componente que le transfiera la ejecución. Esa capa puede ser un ejecutor local, un mecanismo de carga autorizado para laboratorio o una infraestructura de pruebas.

No debe confundirse con Crystal Palace:

Crystal Palace construye y transforma el artefacto.
El componente de entrega decide dónde y cómo ejecutarlo.
El loader interno decide cómo preparar la DLL incorporada.
Xenon decide cómo funciona el agente una vez iniciado.

Una mala decisión en cualquiera de estas capas puede anular las ventajas de las demás. Por ejemplo, una asignación de memoria inadecuada, un hilo iniciado en una región anómala o una cadena de llamadas incoherente son propiedades de la ejecución, no del formato de salida por sí solo.

Este artículo omite deliberadamente técnicas para neutralizar controles defensivos, ocultar procesos o inyectar código. Esos detalles no son necesarios para comprender la arquitectura y deben tratarse, si procede, en investigación autorizada y con una metodología defensiva independiente.

13. Evaluación de seguridad y reproducibilidad

13.1 Ausencia de alerta no equivale a ausencia de telemetría

Un producto de seguridad puede registrar eventos sin generar una alerta visible. Una prueba seria debe revisar:

alertas;
telemetría del endpoint;
eventos de memoria;
creación de procesos e hilos;
cargas de imágenes;
actividad de red;
registros del servidor;
correlaciones posteriores.

13.2 Metodología mínima

Para documentar una prueba deberían conservarse:

versión de Mythic;
commit de Xenon;
versión de Crystal Palace;
hash y contenido del UDRL;
compilador y opciones;
versión de Windows;
producto de seguridad y política;
perfil C2;
comandos incluidos;
duración de la observación;
hashes de los artefactos;
eventos y alertas resultantes.

13.3 Variabilidad entre builds

Si se quiere estudiar la variabilidad producida por Crystal Palace, deben construirse varias muestras y medir:

hashes completos;
similitud por función;
regiones compartidas;
cadenas;
reglas YARA generadas;
tamaño;
efecto de cada opción por separado.

La conclusión correcta debe limitarse al conjunto analizado. “Las muestras difieren” no significa “ninguna firma puede relacionarlas”.

13.4 Riesgo de cadena de suministro

Permitir que un usuario suba un ZIP cuyo Makefile será ejecutado supone un riesgo para el constructor. La evaluación del sistema debe incluir no solo el artefacto final, sino también:

integridad de dependencias;
procedencia de LibTCG;
permisos del contenedor;
acceso a secretos;
acceso a la red;
persistencia de archivos temporales;
aislamiento entre construcciones;
registros de auditoría.

La personalización del loader es una característica potente, pero también una forma de ejecutar código durante la construcción.

14. Ventajas y límites de la arquitectura

14.1 Ventajas

La combinación ofrece varias ventajas de ingeniería:

separación entre plataforma, agente, transporte y loader;
construcción configurable desde Mythic;
posibilidad de sustituir el UDRL sin modificar la lógica principal del agente;
soporte para distintos perfiles C2;
reutilización de componentes compatibles con Crystal Palace;
registro contextual de payloads y tareas;
posibilidad de probar loaders básicos y avanzados bajo un contrato común.

14.2 Límites

También presenta límites claros:

Xenon continúa en una fase temprana;
la compatibilidad cambia entre commits;
Crystal Palace tiene restricciones de compilador y lenguaje;
un UDRL debe respetar el contrato real de la DLL;
la postexplotación no utiliza un único formato;
la entrega es una capa independiente;
las transformaciones no garantizan unicidad o indetectabilidad;
los hooks dependen del resolver y de las APIs realmente utilizadas;
una cadena de build personalizable aumenta el riesgo de suministro.

15. Conclusiones

Mythic, Xenon y Crystal Palace forman una combinación interesante para estudiar cadenas de construcción modulares.

Mythic proporciona la plataforma, la interfaz y los contratos de integración. Xenon proporciona un agente de Windows con formatos EXE, DLL y shellcode, perfiles C2 conectables, comandos modulares, BOF, postexplotación y soporte para UDRL. Crystal Palace permite construir un reflective DLL loader compatible y combinarlo con la DLL del agente en una salida PIC.

La idea más valiosa no es que el resultado sea automáticamente evasivo. Es que las responsabilidades pueden mantenerse separadas:

el equipo de Mythic mantiene la plataforma;
Xenon mantiene la capacidad del agente;
los perfiles C2 mantienen los transportes;
el UDRL define el contrato de carga;
Crystal Palace compone y transforma los objetos compatibles;
la capa de entrega se evalúa por separado.

Esta separación reduce el acoplamiento, pero no elimina la necesidad de validación. El loader debe adaptarse al agente. Los hooks deben coincidir con las funciones usadas. Los scripts deben corresponder a la versión instalada. La postexplotación debe analizarse comando por comando. Las pruebas deben observar telemetría, no solo alertas.

La conclusión más precisa es:

Mythic y Xenon ofrecen una superficie de construcción extensible en la que puede integrarse un UDRL basado en Crystal Palace. Las características finales dependen de la versión de Xenon, del proyecto UDRL, de la especificación de Crystal Palace y de la forma de ejecución. La modularidad es real; la evasión automática y la unicidad total no lo son.

Referencias

Mythic, Documentación general y arquitectura.\ https://docs.mythic-c2.net/home
Mythic, Payload Type Development Overview.\ https://docs.mythic-c2.net/customizing/payload-type-development
MythicAgents, Xenon, repositorio oficial. Consultado en agosto de 2026.\ https://github.com/MythicAgents/Xenon
MythicAgents, Xenon OPSEC and UDRL documentation, versión 0.0.6.\ https://github.com/MythicAgents/Xenon/blob/main/documentation-payload/xenon/opsec/\_index.md
MythicAgents, Xenon Commands, versión 0.0.6.\ https://github.com/MythicAgents/Xenon/blob/main/documentation-payload/xenon/commands/\_index.md
Raphael Mudge, Crystal Palace Documentation.\ https://tradecraftgarden.org/docs.html
Raphael Mudge, Crystal Palace: A linker and bin2bin code manipulation tool.\ https://tradecraftgarden.org/crystalpalace.html
nickswink, Crystal-Kit-Xenon. Consultado en agosto de 2026.\ https://github.com/nickswink/Crystal-Kit-Xenon
nickswink, Crystal Simple Loader, ejemplo enlazado desde la documentación de Xenon.\ https://github.com/nickswink/crystal-simple-loader
Raphael Mudge, Cruising Forward with the Tradecraft Garden, 29 de junio de 2026.\ https://aff-wg.org/2026/06/29/cruising-forward-with-the-tradecraft-garden/
Raphael Mudge, LSH delish, 16 de julio de 2026.\ https://aff-wg.org/2026/07/16/lsh-delish/

Nota sobre la redacción

Para apoyar la revisión lingüística y estructural de este documento pueden utilizarse herramientas de inteligencia artificial. La responsabilidad de comprobar las afirmaciones técnicas, fijar las versiones analizadas y distinguir entre documentación, observación e hipótesis corresponde al autor que publica el texto.