Purple teaming con Atomic Red Team y CALDERA:
probar tus detecciones sin un red team
Serie Blue Team | unfantasmaenelsistema.com
Tienes reglas Sigma, un EDR y un SIEM. La pregunta incómoda es: ¿de verdad saltan cuando tienen que saltar? La mayoría de los equipos no lo sabe hasta que ocurre un incidente real. El purple teaming resuelve eso convirtiendo MITRE ATT&CK en algo que se mide: ejecutas una técnica conocida en un entorno controlado y compruebas, paso a paso, si generó telemetría y si tu detección la vio.
Este artículo es una guía de laboratorio. Explica el ciclo de emulación de adversario, cómo usar Atomic Red Team (pruebas pequeñas y acotadas por técnica) y MITRE CALDERA (emulación encadenada con agentes), cómo construir una matriz de cobertura de detección y qué higiene hace falta para no dejarte una prueba a medio limpiar. Todo sobre máquinas propias y desechables.
Qué aprenderás en este artículo
Qué es la emulación de adversario y en qué se diferencia de un pentest · El ciclo purple: ejecutar, observar telemetría, comprobar detección, ajustar, repetir · Cómo se estructura una prueba de Atomic Red Team y cómo se comprueba antes de lanzarla · Qué aporta CALDERA: agentes, abilities y perfiles de adversario · Cómo montar una matriz de cobertura sobre ATT&CK Navigator · Higiene de laboratorio: instantáneas, aislamiento y limpieza
Marco legal y de uso — léelo antes de ejecutar nada
La emulación de adversario ejecuta acciones que, fuera de un entorno autorizado, encajan en los delitos de acceso ilícito a sistemas y daños informáticos (arts. 197 bis, 197 ter y 264 del Código Penal español) · Ejecuta estas pruebas SOLO sobre sistemas de tu propiedad o con autorización escrita explícita del responsable, en un laboratorio aislado (la red 192.168.56.x de la serie) o en VMs desechables · En una organización, un ejercicio purple necesita una ventana acordada por escrito con el SOC y con sistemas, y quedar fuera de producción y de datos reales · Algunas pruebas atómicas descargan binarios de prueba o muestras inertes: trátalas con la misma contención que cualquier muestra de malware y no las dejes en un sistema conectado
1. Emulación de adversario, no pentest
Un pentest busca entrar: encontrar y encadenar vulnerabilidades hasta comprometer un objetivo. La emulación de adversario asume el compromiso y pregunta otra cosa: dado que un atacante ya está dentro y se comporta como el grupo X, ¿lo veríamos?. No busca fallos de configuración, busca huecos de visibilidad y detección.
El purple teaming es la versión colaborativa: el que ejecuta (rol rojo) y el que defiende (rol azul) trabajan juntos y en tiempo real, técnica por técnica, ajustando la detección sobre la marcha en lugar de entregar un informe al final. Para un equipo pequeño, las herramientas de este artículo permiten hacer el rol rojo sin contratar a nadie.
2. El ciclo purple
| Paso | Pregunta que responde | Artefacto que produce |
|---|---|---|
| 1. Elegir técnica | ¿Qué comportamiento de ATT&CK quiero validar? | ID de técnica y sub-técnica |
| 2. Ejecutar en lab | ¿La acción se completa en el sistema de prueba? | Registro de la ejecución y su hora |
| 3. Observar telemetría | ¿Se generó un evento en el log / EDR / Sysmon? | Event ID o registro concreto |
| 4. Comprobar detección | ¿Saltó una alerta en el SIEM / EDR? | Sí / No / Parcial + captura |
| 5. Ajustar | Si no saltó: ¿falta telemetría o falta regla? | Nueva regla, o cambio de auditoría |
| 6. Re-test | ¿Ahora sí se detecta, sin falsos positivos nuevos? | Resultado verde y regla documentada |
La distinción del paso 3 y 4 es la clave del ejercicio. «No se detectó» tiene dos causas muy distintas: no hubo telemetría (el log no estaba activado, Sysmon no cubría ese evento, el EDR no instrumenta esa llamada) o hubo telemetría pero ninguna regla la miró. La solución es diferente en cada caso.
3. Atomic Red Team
Atomic Red Team (de Red Canary) es una biblioteca abierta de pruebas atómicas: acciones pequeñas, acotadas y documentadas, una por técnica de ATT&CK. Cada prueba hace una cosa (por ejemplo, crear una tarea programada, o volcar un proceso), con sus parámetros, sus requisitos previos y su rutina de limpieza.
3.1 Anatomía de una prueba atómica
- Technique: el ID de ATT&CK al que corresponde (por ejemplo T1053.005, tarea programada).
- Input arguments: parámetros con valores por defecto (nombre de la tarea, ruta, etc.).
- Dependencies: ficheros o condiciones que deben existir; el framework puede resolverlas.
- Executor: la shell que la ejecuta (PowerShell, cmd, bash, sh).
- Cleanup command: cómo deshacer el cambio. Esto es lo que hace que la prueba sea segura de repetir.
3.2 Invoke-AtomicRedTeam
El módulo de PowerShell Invoke-AtomicRedTeam orquesta las pruebas. Antes de ejecutar nada conviene inspeccionar la prueba y comprobar sus requisitos. Estos comandos son de inspección y comprobación, no ejecutan la técnica:
# Ver que hace una prueba, sin ejecutarla Invoke-AtomicTest T1053.005 -ShowDetailsBrief Invoke-AtomicTest T1053.005 -ShowDetails # Comprobar si se cumplen los requisitos previos (no lanza la tecnica) Invoke-AtomicTest T1053.005 -CheckPrereqs # (En el laboratorio aislado y con instantanea previa) ejecutar y limpiar: # Invoke-AtomicTest T1053.005 -TestNumbers 1 # Invoke-AtomicTest T1053.005 -TestNumbers 1 -Cleanup
El flujo de trabajo: instantánea de la VM, -CheckPrereqs, ejecutar la prueba concreta, ir al SIEM y al EDR a ver qué quedó registrado, -Cleanup, y revertir la instantánea si algo no quedó limpio. Nunca en bloque: prueba a prueba, anotando el resultado.
4. MITRE CALDERA
Donde Atomic Red Team ejecuta acciones sueltas, CALDERA encadena. Es una plataforma de la propia MITRE para emulación automatizada: un servidor coordina agentes desplegados en las máquinas de laboratorio y ejecuta operaciones que siguen un perfil de adversario.
- Agente: el proceso que corre en la máquina víctima de laboratorio y recibe instrucciones (Sandcat, Manx y otros).
- Ability: una acción individual mapeada a ATT&CK, con su comando, su parser de resultados y su limpieza — el equivalente CALDERA de una prueba atómica.
- Adversary profile: una secuencia ordenada de abilities que imita a un grupo o un escenario (descubrimiento, recolección, movimiento lateral simulado).
- Operation: la ejecución de un perfil contra un grupo de agentes, con su ritmo, su registro y su informe final mapeado a la matriz.
- Plugins: «stockpile» (abilities de la comunidad), «pathfinder», «debrief» (informes) y «atomic» (importa pruebas de Atomic Red Team).
CALDERA es más potente y más ruidoso; conviene empezar con Atomic Red Team para validar detecciones puntuales y pasar a CALDERA cuando quieras probar cadenas completas y la correlación entre eventos.
5. La matriz de cobertura de detección
El resultado del ejercicio no es una lista de «pasó / no pasó», es un mapa. ATT&CK Navigator permite pintar la matriz de técnicas con colores según tu cobertura, y esa capa se versiona y se revisa con el tiempo.
| Técnica probada | ¿Telemetría? | ¿Detección? | Acción |
|---|---|---|---|
| T1059.001 PowerShell | Sí (Event ID 4104) | Sí (regla Sigma) | Verde, documentar |
| T1053.005 Tarea programada | Sí (4698) | No | Escribir regla sobre 4698 |
| T1003.001 Volcado de LSASS | Parcial (Sysmon 10) | No | Afinar Sysmon + regla de acceso a lsass |
| T1070.001 Borrado del log de seguridad | Sí (1102) | Sí | Verde, alerta crítica |
| T1197 BITS jobs | No | No | Activar auditoría de BITS antes de re-test |
Con tres o cuatro sesiones tienes una imagen honesta de por dónde entra un atacante sin que nadie se entere. Priorizar por ahí —y no por la técnica de moda— es lo que mueve la aguja.
6. Higiene de laboratorio
- Solo VMs de test, nunca equipos con acceso a producción, a la LAN de casa o a datos reales.
- Instantánea antes de cada sesión y revertir al terminar; no acumular estado entre pruebas.
- Red aislada (host-only / internal) para que nada de la emulación salga fuera.
- Inventario de lo ejecutado: fecha, técnica, máquina, resultado. Sin bitácora no hay ejercicio repetible.
- Limpieza verificada: ejecutar el cleanup y comprobar a mano que la tarea, el usuario o el servicio de prueba ya no están.
- Coordinación con el SOC: si el ejercicio es sobre infraestructura corporativa de laboratorio, avisar para no disparar una respuesta a incidentes real.
La emulación no sustituye a un red team
Estas herramientas prueban detecciones contra técnicas conocidas y documentadas; no encuentran cadenas de ataque nuevas ni fallos de lógica de negocio · Un resultado «todo verde» significa que detectas lo que probaste, no que estés cubierto: la matriz solo mide lo que ejecutaste · Complementa con un pentest o un red team real cuando el presupuesto lo permita
Referencias y recursos
atomicredteam.io y github.com/redcanaryco/atomic-red-team — biblioteca y módulo Invoke-AtomicRedTeam · caldera.mitre.org y github.com/mitre/caldera — plataforma y plugins · mitre-attack.github.io/attack-navigator — ATT&CK Navigator para las capas de cobertura · MITRE Engenuity — CTID: guías de emulación de adversario por grupo · «Purple Team Exercise Framework» (PTEF) de SCYTHE — metodología del ejercicio
Conclusión
El purple teaming con herramientas abiertas convierte una duda («¿saltarían nuestras alertas?») en un dato medido y repetible. Atomic Red Team valida detecciones concretas técnica a técnica; CALDERA prueba cadenas completas y la correlación entre eventos. El valor no está en ejecutar muchas pruebas, sino en separar con rigor la falta de telemetría de la falta de regla y en llevar el resultado a una matriz de cobertura que se revisa con el tiempo.
Nada de esto sale del laboratorio. Ejecutado sobre VMs propias y desechables, con instantáneas y limpieza verificada, es uno de los ejercicios más rentables para un equipo azul pequeño. Ejecutado en cualquier otro sitio, es un delito.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)