Adversary Emulation con Caldera y MITRE ATT&CK en Laboratorio Corporativo
Cómo Basilisk usa Caldera, Atomic Red Team y MITRE ATT&CK para simular TTPs reales en un lab cerrado y medir la madurez del SOC sin tocar producción.
Cuando un cliente llama diciendo que compró el EDR más caro del mercado y quiere saber si 'está bien', la respuesta honesta nunca es un informe en PowerPoint. Es una operación de adversary emulation con guión escrito, ATT&CK mapeado y métricas frías: cuántos pasos pasaron en silencio, cuántos generaron alerta, cuántos terminaron en respuesta humana en menos de 60 minutos. En Basilisk OffSec estandarizamos esto sobre Caldera 5.x, Atomic Red Team y un lab de dominio Windows con 8 hosts que replica el entorno del cliente sin tocar jamás su producción. Este texto describe la pila, el flujo y los errores que cobramos caro para no repetir.
El lab base es simple y reproducible: un Windows Server 2022 como DC, dos Server 2019 (archivos y SQL), tres Windows 11 Enterprise como estaciones con Defender for Endpoint en modo bloqueo, y dos Ubuntu 24.04 con auditd y Wazuh agent. Todo orquestado en Proxmox vía Terraform, con snapshots nombrados por fase del escenario. Para quien arma el escenario Windows desde cero recomendamos partir de Pentest de Active Directory: Kerberoasting Paso a Paso en Lab GOAD, que ya entrega ACLs propositalmente desordenadas, y luego acoplar el pivoting descrito en [[pivoting-chisel-ligolo-rede-pentest]] para segmentar VLAN reales. Sin segmentación realista, cualquier métrica de detección de lateral movement queda viciada de origen.
Caldera entra como cerebro de la operación. Levantamos el servidor en un Debian aislado, cargamos los plugins 'atomic', 'stockpile' y nuestro fork interno 'basilisk-ttps' con TTPs latinoamericanas, como abuso de AnyDesk en pymes. Cada adversario en Caldera es un YAML que cita técnicas ATT&CK por ID: T1059.001 para PowerShell, T1021.006 para WinRM, T1003.001 para dump de LSASS. Nunca ejecutamos adversarios listos sin revisión; sirven como benchmark, pero el valor real está en escribir escenarios que reproduzcan el modelo de amenazas del cliente. Un retail con TPV expuesto no merece el mismo adversary que una fintech con Azure AD federado y MFA fuerte.
La ejecución sigue un ciclo de cuatro fases que aprendimos a respetar. Primero initial access simulado en endpoint controlado, normalmente siguiendo el playbook de Initial Access Simulado: Macros, LNK e ISO en un Lab Windows 11 Aislado con payload firmado por una CA interna. Segundo, ejecución y descubrimiento apoyados en LOLBins; aquí el material de Hunting de Living-off-the-Land Binaries en Windows con KQL ayuda al blue team a tener KQL listo antes del ejercicio. Tercero, lateral movement por SMB y WinRM aprovechando cuentas de servicio débiles. Cuarto, acciones sobre el objetivo, que pueden ser exfil de una base SQL o cifrado simulado de un share. Cada fase tiene criterio de parada claro: si el EDR mata el proceso en menos de 90 segundos, anotamos detectado y probamos otro camino.
La parte aburrida pero decisiva es la instrumentación del lado azul. Sin telemetría comparable, adversary emulation se vuelve teatro. Activamos Sysmon con la config de Olaf Hartong, enviamos a un Elastic 8.14 y aplicamos reglas Sigma convertidas, proceso que detallamos en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion. Marcamos cada evento generado por Caldera con un header custom x-caldera-op-id, lo que permite consultar en Kibana qué técnica generó qué eventos y en cuánto tiempo respondió el analista. Métricas que siempre reportamos: MTTD por técnica, tasa de detección por táctica ATT&CK y número de reglas Sigma nuevas escritas como consecuencia. Sin esos tres números, el cliente cree que compró pentest y queda frustrado.
Hay trampas éticas y operativas que vale citar. Adversary emulation no es excusa para ejecutar evasión de EDR en producción ajena; todo lo que involucra direct syscalls o patching de AMSI queda restringido al lab, y quien quiera entender por qué insistimos puede leer Evasion de EDR para Investigacion: Direct Syscalls Explicados sin Romantizar y Bypass de AMSI y ETW para Investigacion Defensiva: Lo que los Blue Teams Deben Saber. Tampoco corremos C2 con infraestructura compartida entre clientes; cada operación recibe un teamserver Sliver dedicado conforme Construyendo Infra de C2 con Sliver en Lab Aislado para Estudio Defensivo. Y el informe final amarra siempre cada TTP a una contramedida concreta, alimentando el ciclo descrito en Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue y evitando que el ejercicio termine archivado en un PDF.
Takeaway práctico: empezá pequeño. Levantá un Caldera, escribí un adversario con cinco técnicas ATT&CK alineadas al modelo de amenazas real de tu entorno, corrélo contra tres endpoints monitoreados y medí MTTD por técnica. Repetí mensualmente cambiando una técnica por vez. En seis meses vas a tener una curva de madurez defendible ante el directorio, sin comprar ninguna herramienta cara extra, y el SOC va a dejar de quejarse de que 'nunca pasa nada' en los entrenamientos.