Emular un adversario real (replicar sus TTPs, su secuencia de acciones, sus herramientas) es la forma más rigurosa de validar si una organización puede detectar y responder a una amenaza concreta. Un ejercicio de red team que termina con domain admin sin que el SOC haya levantado una alerta dice más que doce informes de cumplimiento.
El problema no está en el método. Está en lo que pasa cuando intentás aplicarlo en el mundo real, donde las amenazas mutan más rápido de lo que un plan de emulación se puede diseñar y ejecutar.
El problema de selección: emulás lo que ya pasó
El punto de partida de cualquier emulación de adversarios es elegir un threat actor: FIN7, APT29, un grupo de ransomware específico. Esa decisión determina qué TTPs se van a replicar, qué herramientas se van a usar y contra qué partes de la infraestructura se va a operar.
El razonamiento es sólido: si tu sector, tu geografía o tu tamaño de empresa están en la mira de cierto grupo, tiene sentido prepararse para ese grupo. El problema es que esa selección produce un snapshot de un momento específico.
Los adversarios reales no se quedan quietos. Cambian de herramientas cuando una se quema. Adoptan nuevas técnicas cuando las defensas se adaptan. Rotan infraestructura. Mezclan TTPs de otros grupos. Un informe de threat intelligence de seis meses atrás puede describir un adversario que ya no opera como operaba.
Hay una brecha entre lo que los adversaries documentados hacen y el universo de técnicas que existen. Si tu plan de emulación se basa exclusivamente en inteligencia de amenazas, estás cubriendo un subconjunto de lo que es posible. No está mal: es lo mejor que se puede hacer con datos reales. Pero conviene saber que es un subconjunto.
El problema de escala: ¿cada cuánto emulás?
El volumen de malware nuevo es difícil de dimensionar porque depende de qué se cuente.
La cifra conservadora (637 variantes genuinamente nuevas por día) ya alcanza para ilustrar el punto. Un ejercicio de adversary emulation bien hecho toma días o semanas entre planificación, ejecución segura, análisis de resultados y remediación. Ni la organización más madura del mundo puede correr una emulación completa por cada nueva variante que aparece.
El resultado práctico es que la emulación de adversarios se hace una o dos veces al año, contra dos o tres threat actors, y cubre quizás una docena de técnicas de las cientos disponibles. Entre ejercicio y ejercicio, la organización opera a ciegas respecto a todo lo nuevo que surgió.
Esto no es un argumento contra la emulación. Es una descripción de sus límites estructurales. La emulación es profunda pero angosta. El panorama de amenazas es ancho y se mueve rápido.
El problema de madurez: ¿y las empresas que recién arrancan?
Hay una conversación que ocurre con frecuencia en la industria: una empresa contrata un red team, el equipo identifica veinte hallazgos, entrega el informe, y la organización no tiene la capacidad de remediar ni la mitad en menos de seis meses. El ejercicio fue técnicamente impecable. El valor práctico fue marginal.
La adversary emulation presupone ciertas condiciones:
- Un SOC que ya está generando alertas y tiene capacidad de investigarlas.
- Controles preventivos configurados y mantenidos (EDR, segmentación, hardening de AD).
- Un equipo de detección que puede convertir hallazgos en reglas nuevas.
- Un ciclo de remediación que cierra hallazgos en semanas, no en trimestres.
Muchas organizaciones no cumplen ninguna de estas condiciones. Para ellas, una emulación completa de un APT produce un informe que dice “están expuestos a esto, a esto y a esto”, y la respuesta es “lo sabemos, pero no tenemos con qué cubrirlo”.
La adversary emulation apunta a un nivel de madurez que una porción grande del mercado no tiene. Para esas organizaciones, lo que sirve es cobertura de superficie inicial: controles básicos, visibilidad mínima, capacidad de detectar las técnicas más comunes. La emulación de adversarios sofisticados llega después, cuando hay algo que validar.
Qué se está intentando
Los problemas descritos arriba no son nuevos. En los últimos dos años aparecieron varias líneas de trabajo que intentan abordarlos desde ángulos distintos. Ninguna es una solución completa. Algunas son prometedoras.
Micro-emulaciones. En lugar de emular un threat actor completo, se emula un comportamiento compuesto que aparece en múltiples adversarios: despliegue de webshells, movimiento lateral vía PSExec, robo de credenciales con LSASS dumping. Son ejercicios más cortos, más focalizados y más repetibles. El Center for Threat-Informed Defense mantiene planes de micro-emulación que cubren TTPs cross-adversary. La ventaja es que se pueden ejecutar con mayor frecuencia y no requieren inteligencia de amenazas actualizada sobre un grupo específico. La limitación es que no prueban la capacidad de responder a una cadena completa de ataque.
Automatización de emulaciones. Plataformas como MITRE Caldera permiten ejecutar TTPs de forma automatizada contra infraestructura real. El plan sigue siendo definido por un humano, pero la ejecución es repetible y programable. La dirección de la industria en 2026 apunta a plataformas de autonomous exposure validation que orquestan agentes de IA especializados en discovery, exploitation, validation y reporting para validación continua. El objetivo es sacar al humano del loop de ejecución para aumentar la frecuencia sin perder supervisión en los puntos de decisión.
Entornos sintéticos para entrenar agentes. Dreadnode publicó en febrero de 2026 Worlds, un motor de simulación que genera trayectorias de ataque realistas sobre redes Active Directory arbitrarias sin desplegar infraestructura real. Corre en CPU, produce trayectorias completas en segundos y cierra el gap entre simulación y emulación usando datos sintéticos. Entrenaron un modelo de 8B parámetros exclusivamente con datos sintéticos y logró comprometer un entorno GOAD completo: AS-REP roasting, pivoteo de credenciales, LSASS dumping, domain admin. La implicación es que se puede generar datos de entrenamiento para agentes de seguridad a escala arbitraria sin tocar infraestructura de clientes.
Validación continua de controles. El modelo emergente en 2026 conecta micro-emulaciones con pipelines de CI/CD: ejecutar TTPs específicos en staging cada vez que se despliega un cambio, medir si los controles los detectaron, generar alertas si algo dejó de funcionar. Es el mismo principio que los tests de regresión en software, aplicado a controles de seguridad. Frameworks open-source como el Enterprise Security Control Validation Framework (febrero 2026) ya soportan este enfoque con mapeo a MITRE ATT&CK.
Lo que queda por resolver
Hay preguntas que ninguna de estas aproximaciones responde todavía:
Cobertura del espacio de técnicas. ATT&CK tiene cientos de técnicas. Las micro-emulaciones cubren algunas. La automatización permite ejecutar más, pero solo de lo que ya está modelado. El espacio de lo que un adversario podría hacer (combinaciones de técnicas no documentadas, abuso de herramientas legítimas de formas no anticipadas) sigue siendo inalcanzable por cualquier enfoque basado en catálogos. Mientras tanto, el 90% del malware en 2026 es polimórfico y el 37% usa samples mejorados con IA para evadir detección. Las defensas se validan contra lo conocido; los atacantes operan en lo desconocido.
El gap entre hallazgo y remediación. Una emulación identifica brechas. Una validación continua las monitorea. Pero si la organización no tiene capacidad de cerrarlas, el resultado neto es un backlog que crece. Solo el 66% de las organizaciones prueba formalmente más del 60% de sus despliegues. Entre las que sí prueban, la velocidad de remediación es el cuello de botella real.
El punto de entrada para organizaciones sin madurez. Para una empresa que no tiene SOC, no tiene EDR bien configurado y no tiene visibilidad de red, las alternativas automatizadas no resuelven el problema de base. La pregunta no es “¿cómo validamos nuestros controles?” sino “¿qué controles ponemos primero?”. Ahí la respuesta sigue siendo consultoría, priorización por riesgo y cobertura de superficie inicial antes de cualquier forma de emulación.
El rol del humano. Los modelos de IA pueden ejecutar TTPs. Pueden generar trayectorias. Pueden medir cobertura. Lo que no pueden hacer (al menos no en 2026) es interpretar el contexto organizacional: saber cuándo un hallazgo es crítico no por su severidad técnica sino por el activo de negocio que expone, o decidir si conviene profundizar en una línea de ataque o pivotar a otra en tiempo real. Las plataformas más avanzadas mantienen supervisión humana en puntos de decisión. Las que no, generan ruido.
Nada de esto invalida la adversary emulation. Sigue siendo lo más cercano que tenemos a medir defensas contra adversarios reales. Pero entender sus límites permite usarla mejor: saber qué preguntas responde, cuáles no y con qué frecuencia conviene hacerla en función de la madurez real de la organización.
Para una empresa que recién empieza, la prioridad es cobertura de superficie. Para una que ya tiene controles, la prioridad es validación continua de lo que ya tiene desplegado. Para una organización madura, la adversary emulation completa contra threat actors relevantes tiene sentido una o dos veces al año, complementada con micro-emulaciones trimestrales y validación automatizada mensual. Son herramientas distintas para momentos distintos. El error es usar la misma para todo.
Fuentes
- AV-TEST — Malware Statistics 2025–2026
- SonicWall — 2025 Annual Cyber Threat Report
- MITRE — Análisis de cobertura ATT&CK sobre STIX CTI
- SentinelOne — Malware Statistics 2026
- Dreadnode — Worlds: A Simulation Engine for Agentic Pentesting (2026)
- COHORT — Collaborative Orchestration for Hardening via Offensive Replay (June 2026)
- Enterprise Security Control Validation Framework (February 2026)
- IBM X-Force — The Adversary Didn’t Wait. Neither Should You
- ScienceDirect — AI-Driven Threat Validation Survey (2026)