Emulación automatizada de adversarios (Caldera) contra un laboratorio de AD para validar la cobertura de detección de Sigma y mapear los resultados a MITRE ATT&CK.
Validación automatizada de purple-team de las reglas de detección de Sigma creadas en detection-as-code-repo, usando MITRE Caldera para ejecutar una ruta de ataque encadenada de acceso a credenciales de Active Directory contra un laboratorio de dominio existente, y un mapa de calor de ATT&CK Navigator para visualizar la cobertura.
Se eligió Caldera en lugar de Atomic Red Team para este proyecto porque proporciona un framework C2 completo, con agentes, perfiles de adversario y operaciones encadenadas de varios pasos, en lugar de la ejecución de técnicas únicas y aisladas. Esto se ajusta más al objetivo de este proyecto: no solo "¿se detectó esta única técnica?", sino "¿sobrevive una cadena de ataque realista y ordenada a nuestra pila de detección actual, de principio a fin?"
Purple-Team-Automation/
├── abilities/ Custom Caldera ability YAMLs
├── adversary-profiles/ The chained adversary profile used in the operation
├── validation/ Kibana evidence per technique + the LLMNR known-gap writeup
├── attack-navigator-heatmap.json ATT&CK Navigator layer, load at mitre-attack.github.io/attack-navigator
├── purple-team-automation-report.md Full write-up: scope, methodology, results, gap analysis
└── README.md This file
Desplegué un servidor Caldera dedicado mediante Docker Compose en una VM Ubuntu
separada (caldera-server, 192.168.18.205) en la misma red de laboratorio que
el laboratorio de dominio AD existente, manteniéndolo aislado de la pila ELK/SIEM.
Caldera v5.0.0 arrancó con 2000 abilities de serie y 29 adversarios de serie
listos para usar.
Problemas de compilación que diagnostiqué en el proceso:
plugins/magma/dist/assets/). Lo rastreé hasta un montaje de volumen Docker de directorio completo en docker-compose.yml que sobrescribía el
frontend compilado de la imagen con el código fuente sin compilar del host. Lo arreglé eliminando el
montaje de directorio completo.npm/nodejs después de la
compilación de la imagen para mantener la imagen final ligera.localhost:8888 codificado como su base de API, fijado
en tiempo de compilación de Vue mediante plugins/magma/.env (VITE_CALDERA_URL), que
no está controlado por la configuración en tiempo de ejecución app.frontend.api_base_url de conf/local.yml. Lo arreglé editando .env con la IP real de la VM y recompilando.lvextend -l +100%FREE + resize2fs, además de recuperar las capas de caché de compilación
mediante docker system prune -a --volumes.Stockpile solo incluye una ability nativa para el volcado de credenciales basado en LSASS/Mimikatz (T1003.001). Las cuatro técnicas que necesitaba para este proyecto,
Kerberoasting, AS-REP Roasting, Password Spraying y DCSync, todas
requerían abilities personalizadas que construí en torno a Impacket (GetUserSPNs.py,
GetNPUsers.py, secretsdump.py) y Kerbrute, ya que las abilities de Kerberoasting existentes de Stockpile (Rubeus, WinPwn) son solo para Windows/.NET e
incompatibles con el agente Sandcat basado en Linux de este laboratorio.
Me encontré con dos problemas de compilación mientras las creaba:
plugins.stockpile.app.parsers.katz) con
campos source/edge/target, no un analizador genérico de regex pattern como
había asumido originalmente. Esto provocaba un
TypeError('ParserConfig.__init__()') silencioso al cargar. Como no existe ningún analizador integrado
para la salida sin procesar de Impacket, eliminé por completo el bloque parsers:
de las cuatro abilities. Los resultados se capturan como archivos de salida/hash sin procesar
y se validan manualmente contra Kibana (ver /validation).nano fallara silenciosamente. Lo detecté
verificando cada archivo con cat/wc -l antes de reiniciar el
contenedor.Desplegué un agente Sandcat (Linux, grupo red) en la VM Kali
(192.168.18.70), usando el nombre de proceso splunkd para el enmascaramiento OPSEC,
y confirmé que arrancó vivo y confiable, ejecutándose como root con el
ejecutor proc/sh.
Construí el perfil de adversario AD Credential Access Chain para encadenar las
cuatro abilities personalizadas en el orden en que un atacante interno oportunista
normalmente intentaría ejecutarlas:
→ Password Spray (Kerbrute)
→ Kerberoasting (GetUserSPNs.py)
→ AS-REP Roasting (GetNPUsers.py)
→ DCSync (secretsdump.py)
El envenenamiento LLMNR/NBT-NS (T1557.001) se excluyó deliberadamente del
perfil de Caldera. Ver validation/llmnr-known-gap.md
para saber por qué, y cómo sigue incluido como un control negativo de brecha conocida.
Las cuatro técnicas ejecutadas se confirmaron detectadas contra las reglas Sigma de detection-as-code-repo, verificadas directamente en Kibana. El envenenamiento LLMNR/NBT-NS sigue siendo una brecha abierta y documentada.
| Técnica | Estado |
|---|---|
| T1110.003 – Password Spraying | 🟢 Detectada |
| T1558.003 – Kerberoasting | 🟢 Detectada |
| T1558.004 – AS-REP Roasting | 🟢 Detectada |
| T1003.006 – DCSync | 🟢 Detectada |
| T1557.001 – LLMNR/NBT-NS Poisoning | 🔴 Brecha |
Detalle completo: validation/detection-results.md
Informe completo: purple-team-automation-report.md
Mapa de calor interactivo: attack-navigator-heatmap.json