Panorama#
El capítulo anterior estableció por qué se valida y cerró con el primer paso del método: decidir qué se prueba y con qué fidelidad, lo que exige convertir un producto de inteligencia en un plan ejecutable. Este capítulo es ese paso. Es también el punto donde la Parte 6 se conecta con la Parte 1: la emulación de adversario (adversary emulation) es el mecanismo por el cual el conocimiento sobre cómo opera un atacante concreto —producido, evaluado y priorizado por el programa de inteligencia— se transforma en una secuencia de acciones reproducibles que se ejecutan contra la propia defensa para observar qué ve y qué no.
Conviene fijar la distinción que ordena todo lo demás, porque es la que más se confunde en la práctica. Un pentest —y en buena medida un red team— tiene por objetivo entrar: encontrar un camino de compromiso y recorrerlo. La emulación tiene por objetivo reproducir un comportamiento: ejecutar un conjunto de técnicas conocidas, se detecten o no, para medir la respuesta del entorno frente a ellas. La diferencia no es de intensidad sino de finalidad, y tiene una consecuencia inmediata sobre el insumo. El pentest parte de una superficie de ataque y busca sus debilidades; la emulación parte de un producto de inteligencia —un actor, una campaña, un conjunto de TTP— y busca comprobar la visibilidad frente a él. Por eso la tesis del capítulo es que la calidad de una emulación está acotada por la calidad del CTI que la alimenta: se emula lo que se conoce, y no se conoce mejor de lo que el programa de inteligencia permite conocer.
Emular no es lo mismo que penetrar, ni que simular#
Vale la pena separar tres actividades que el vocabulario del sector mezcla, porque cada una responde una pregunta distinta y usarlas como sinónimos lleva a comprar la herramienta equivocada.
La emulación reproduce el comportamiento de un adversario específico y conocido. Su unidad de trabajo es el TTP documentado —esta familia de actores usa esta técnica de acceso inicial, esta de persistencia, esta de movimiento lateral— y su fidelidad se mide por cuánto se parece la secuencia ejecutada a la secuencia real observada en incidentes. Es dirigida por inteligencia por definición: sin un actor de referencia no hay nada que emular.
La simulación ejecuta comportamientos maliciosos representativos pero no atribuidos a nadie en particular. No pregunta «¿vería mi defensa a este grupo concreto?» sino «¿sigue funcionando la detección de esta clase de técnica?». Es el terreno natural de las plataformas automatizadas, que ejecutan un catálogo amplio de forma repetible y programada. La distinción con la emulación es sutil pero útil: la emulación prioriza la fidelidad a un adversario; la simulación prioriza la cobertura y la cadencia de un catálogo.
El pentest y el red team, ya tratados en 6.1, comparten con las dos anteriores el uso de técnicas ofensivas reales, pero su objetivo es el compromiso, no la medición de visibilidad. Un red team puede emular a un actor —de hecho, un buen red team parte de un plan de emulación— pero lo subordina a un objetivo de intrusión y a la evasión; la emulación pura invierte esa prioridad y ejecuta las técnicas a la vista, porque lo que quiere medir es exactamente si se las ve.
El insumo es inteligencia: a quién se emula y por qué a ese#
La decisión más importante de una emulación se toma antes de ejecutar nada: a quién se emula. Emular a todos los adversarios posibles no es factible, y emular al azar produce cobertura ilusoria. La selección es un problema de priorización, y es exactamente el que el programa de inteligencia ya resolvió.
La priorización de 1.2 —qué actores son relevantes para el sector, la geografía y el perfil de la organización— decide a quién se emula. No se emula al grupo más sofisticado ni al más mediático, sino al que con más probabilidad va a dirigirse contra este entorno concreto, que es una pregunta que solo el CTI puede responder. Y una vez elegido el actor, el nivel operativo de 1.5 aporta el material del que se construye el plan: cómo opera ese grupo en concreto, con qué herramientas, en qué orden, contra qué objetivos.
El instrumento que hace utilizable ese material es ATT&CK, ya presentado en 1.3 como modelo de análisis. Aquí cambia de rol: de marco para clasificar lo observado pasa a plantilla para construir lo que se va a ejecutar. Un actor documentado en ATT&CK viene con su conjunto de técnicas mapeadas por táctica, y esa lista es el esqueleto del plan de emulación. MITRE publica además planes de emulación de adversario completos —secuencias detalladas que reproducen campañas concretas paso a paso— que ahorran el trabajo de derivar el plan desde cero para los actores más estudiados.
Ese cambio de rol arrastra los límites que 1.3 ya señaló, y conviene tenerlos presentes para no sobreinterpretar el resultado. ATT&CK es un catálogo de lo observado y documentado, no un mapa de lo posible: emular sus técnicas mide la visibilidad frente a lo conocido, no frente a lo que todavía nadie catalogó. Y la matriz invita a un conteo tranquilizador —«cubrimos tantas técnicas de tantas»— que 1.3 ya desarmó como heat map engañoso: la cobertura de una técnica no es binaria, y contar casillas pintadas dice poco sobre la profundidad real de la detección. La emulación existe, precisamente, para reemplazar ese conteo por una medición.
Del TTP al plan: el continuo de fidelidad#
Con el actor elegido y sus técnicas mapeadas, queda decidir cómo se ejecuta. Hay un continuo entre dos extremos, y cada punto compra una cosa a costa de otra: la fidelidad al adversario real y la repetibilidad automatizada tiran en direcciones opuestas.
En un extremo están las pruebas atómicas (atomic tests): la ejecución aislada de una sola técnica, de la forma más simple que la dispare. El proyecto de referencia es Atomic Red Team, una biblioteca abierta de pruebas indexadas por identificador de ATT&CK, donde cada prueba es una acción pequeña y declarada —crear una tarea programada, volcar un proceso, ejecutar un comando codificado— con sus requisitos y su procedimiento de limpieza. La prueba atómica responde una pregunta precisa y barata: ¿esta técnica concreta, ejecutada de este modo, produce la telemetría que espero y dispara la regla que creo tener? Es el equivalente en validación de la prueba unitaria en software, y su virtud es que aísla la variable: si falla, se sabe exactamente qué falló.
En el extremo opuesto están los planes de emulación encadenados: la ejecución de una secuencia completa que reproduce una campaña de principio a fin —acceso inicial, ejecución, persistencia, escalada, descubrimiento, movimiento lateral, recolección, exfiltración— en el orden en que el actor real la ejecuta. La herramienta abierta de referencia es CALDERA, de MITRE, que orquesta agentes en los equipos objetivo y ejecuta adversaries —perfiles compuestos de habilidades encadenadas— de forma semiautónoma. Lo que la prueba atómica no puede medir y la cadena sí es la correlación: si la detección depende de ver varios comportamientos juntos —el patrón que 5.6 desarrolló para el movimiento lateral, donde ninguna acción aislada es concluyente y la señal vive en la secuencia— entonces solo un plan encadenado revela si esa correlación efectivamente ocurre.
En el medio, y con otra economía, está la simulación automatizada de plataformas comerciales de breach and attack simulation (BAS). Ejecutan un catálogo extenso de comportamientos de forma programada y continua, con informes de qué se bloqueó, qué se alertó y qué pasó inadvertido. No sustituyen el criterio de un operador que adapta el plan a lo que va encontrando —por eso no reemplazan al red team— pero responden la pregunta que ningún humano sostiene con esa cadencia: la del drift de 6.1. Una técnica que se validó en marzo y dejó de detectarse en junio, porque una actualización reseteó una configuración, solo se descubre si algo la vuelve a ejecutar en junio sin que nadie lo pida.
flowchart TB
CTI["Programa de inteligencia\n(1.2 prioriza · 1.5 aporta el cómo)"] --> ACT["Actor relevante\npara el sector"]
ACT --> MAP["Mapa ATT&CK del actor\n(técnicas por táctica · 1.3)\n+ planes de emulación MITRE"]
MAP --> DEC{"¿Qué se mide?"}
DEC -->|"una técnica aislada"| ATOM["Prueba ATÓMICA\n(Atomic Red Team)\nfidelidad baja · barata · precisa"]
DEC -->|"la campaña completa\ny su correlación"| CHAIN["Plan ENCADENADO\n(CALDERA / plan MITRE)\nfidelidad alta · cara"]
DEC -->|"¿sigue funcionando hoy?"| BAS["Simulación AUTOMATIZADA\n(BAS)\ncobertura amplia · continua · drift"]
ATOM --> RES["Resultado por técnica:\nprevenido / alertado /\nregistrado no alertado / invisible"]
CHAIN --> RES
BAS --> RES
RES -->|"cerrar el lazo"| PURPLE["Ejercicio purple → 6.3"]Reglas de enfrentamiento y seguridad del ejercicio#
Un ejercicio de emulación ejecuta técnicas ofensivas reales contra infraestructura real, muchas veces de producción. Eso lo distingue de casi todo lo demás de la Parte 6 y obliga a un marco de seguridad que no es burocracia sino condición de que el ejercicio no cause el daño que dice prevenir. Las reglas de enfrentamiento (rules of engagement) se acuerdan y firman antes de tocar nada, y fijan al menos lo siguiente.
Alcance. Qué sistemas, redes, cuentas y datos entran y —más importante— cuáles quedan explícitamente fuera. Sistemas de soporte vital, entornos con datos regulados de terceros, infraestructura cuya caída tiene consecuencias físicas: la lista de exclusiones importa más que la de inclusiones.
Ventana y contactos. Cuándo se ejecuta y quién está localizable durante la ejecución en ambos lados. Un ejercicio sin un contacto técnico disponible en tiempo real es un incidente esperando a que nadie sepa detenerlo.
Criterio de aborto. Las condiciones bajo las cuales el ejercicio se detiene de inmediato: inestabilidad de un sistema de producción, un efecto no previsto, la aparición de un adversario real en medio del ejercicio —que ocurre, y que la instrumentación tiene que poder distinguir de la actividad propia—.
Queda una consideración que es a la vez de seguridad y de honestidad metodológica, y que separa la emulación abierta del red team encubierto. Si el ejercicio no se anuncia al equipo defensor —lo que a veces es deliberado, para medir la respuesta genuina— hay que asumir que puede disparar una respuesta a incidentes real, con su costo: analistas movilizados de madrugada, sistemas aislados, un proveedor externo activado, una decisión de negocio tomada sobre una amenaza que no existía. Ese costo a veces se justifica —es, de hecho, parte de lo que se quería medir— pero se decide de antemano y con quien tiene autoridad para asumirlo, no se descubre a posteriori. El caso simétrico importa igual: un ejercicio anunciado que inyecta actividad en la telemetría de producción sin marcarla contamina las fuentes de las que depende la detección real, y puede envenenar líneas base, cebar modelos de comportamiento y dejar falsos positivos que sobreviven al ejercicio. La instrumentación del ejercicio —el tema del capítulo siguiente— existe en parte para que cada acción quede etiquetada como propia.
El repertorio ya existe: se enlaza, no se reexplica#
Una emulación no inventa técnicas: reproduce las que el adversario usa, y esas ya están descritas en el manual. El plan de emulación es, en buena medida, un índice de la Parte 3 y la Parte 4 ordenado por el TTP del actor elegido. El acceso inicial y la ejecución encadenan las técnicas de explotación de la Parte 3; la persistencia y el movimiento lateral, las de Active Directory; el canal de mando y control, la infraestructura ofensiva de 3.10; y si el actor emulado es conocido por evadir la detección de endpoint, el plan incorpora las técnicas de evasión de AV/EDR —porque un actor que en la realidad evade y una emulación que ejecuta a la vista miden cosas distintas, y a veces se quiere lo primero—.
Mantener el detalle técnico en aquellos capítulos y aquí solo el enlace tiene además una ventaja de encuadre: este capítulo describe cómo se planifica y se gobierna un ejercicio de validación, no cómo se ejecuta una técnica ofensiva. La forma canónica de declarar una prueba lo deja claro —es una unidad pequeña, nombrada por su identificador de ATT&CK, con su procedimiento de limpieza— y ese es el nivel al que la emulación opera:
# Prueba atómica declarada: ejecutar UNA técnica (T1053.005, tarea programada)
# de forma aislada, medir la telemetría, y limpiar el artefacto.
Invoke-AtomicTest T1053.005 -TestNumbers 1 -GetPrereqs # preparar requisitos
Invoke-AtomicTest T1053.005 -TestNumbers 1 # ejecutar la técnica
Invoke-AtomicTest T1053.005 -TestNumbers 1 -Cleanup # revertir el artefacto
Lo que se valida no es que la tarea programada se pueda crear —eso ya se sabe— sino si su creación produce el evento esperado, si ese evento llega al SIEM, si la regla que debería marcarlo dispara, y si la alerta es visible para alguien. Es la cadena de siete eslabones de 6.1, ahora ejercitada técnica por técnica.
Postura#
- Elegir a quién se emula con el programa de inteligencia, no por moda ni por sofisticación. La priorización de relevancia de 1.2 es el insumo, y sin ella la emulación cubre lo que sea que alguien tuvo a mano.
- Construir el plan sobre ATT&CK y los planes de emulación publicados, recordando que miden visibilidad frente a lo conocido, no frente a lo posible, y que la matriz cubierta no es una métrica de profundidad.
- Elegir la fidelidad según la pregunta: atómica para aislar una técnica, encadenada para medir correlación, automatizada para vigilar el drift. No hay una que sirva para todo.
- Firmar las reglas de enfrentamiento antes de ejecutar: alcance con exclusiones explícitas, ventana, contactos, criterio de aborto.
- Nunca cargas destructivas reales ni datos reales de terceros, y limpieza verificada de todo artefacto de ejercicio.
- Decidir de antemano si el ejercicio se anuncia, asumiendo que uno no anunciado puede disparar una respuesta a incidentes real y que uno anunciado sin marcar contamina la telemetría de producción.
Cierre#
La emulación resuelve el «qué se prueba» que 6.1 dejó planteado, y lo resuelve subordinándolo a la inteligencia: se prueba el comportamiento del adversario que con más probabilidad va a aparecer, ejecutado con la fidelidad que la pregunta requiere y bajo reglas que impiden que el ejercicio se vuelva el incidente. Pero ejecutar un plan y observar qué pasa es solo la mitad del trabajo. Lo que convierte una observación en una mejora —la corrección de la regla que faltó, la ingesta de la telemetría que no estaba, la re-ejecución que confirma que ahora sí se ve— ocurre en el ejercicio colaborativo que instrumenta el plan y cierra el lazo dentro de la misma sesión: es el trabajo del capítulo 6.3.
Referencias#
blue-dfir/defenders-advantage/cap-07— Validate: la parte de pruebas dirigidas por inteligencia y del uso de plataformas automatizadas de simulación y ejercicios colaborativos para descubrir brechas de visibilidad de forma estructurada; la integración de simulaciones atómicas en el flujo de certificación de reglas de detección. (El resto del capítulo —drift, micro-caso de PowerShell, taxonomía de ejercicios, cierre del lazo— se desarrolló en 6.1.)- La distinción entre emulación, simulación y pentest; el continuo de fidelidad atómico–encadenado–BAS con sus herramientas de referencia (Atomic Red Team, CALDERA, plataformas comerciales de breach and attack simulation); los planes de emulación de adversario de MITRE; y el marco de reglas de enfrentamiento y seguridad del ejercicio —incluido el aviso sobre la respuesta a incidentes disparada y la contaminación de la telemetría— son enriquecimiento propio.
- El repertorio técnico que un plan de emulación reproduce está descrito en la Parte 3 y la Parte 4 y aquí se referencia: 3.1, 3.10, 3.11 y 4.8. La lectura de resultados por correlación se apoya en 5.6.