Qué es Purple Team: colaboración red y blue team con MITRE ATT&CK

Un Purple Team no es un tercer equipo separado: es una metodología de trabajo en la que el equipo ofensivo (red) y el defensivo (blue) ejecutan técnicas juntos, con visibilidad mutua y en tiempo real, para medir qué se detecta y qué se escapa. El red dispara una técnica del catálogo de MITRE ATT&CK; el blue observa su telemetría; ambos comparan lo ocurrido con lo que llegó al analista; se identifica el hueco; se ajusta la regla; se vuelve a ejecutar para validar. Es ingeniería de detección con feedback inmediato y, a diferencia del red team puro, aquí ambos equipos se sientan en la misma sala. El resultado es una mejora medible en cobertura de detección y tiempo medio de respuesta.

Lo esencial sobre Purple Team

• Es una metodología colaborativa, no un equipo separado del red ni del blue.
• Se mide cobertura sobre el framework MITRE ATT&CK, no número de hallazgos.
• Permite desarrollar y validar reglas custom de SIEM y EDR contra técnicas concretas.
• Ideal para SOCs en evolución que quieren saber qué detectan de verdad.
• Frameworks habituales: ATT&CK Navigator, Atomic Red Team, Caldera, VECTR.

Qué es exactamente un Purple Team

Un Purple Team es un ejercicio colaborativo y guiado en el que profesionales ofensivos y defensivos trabajan codo con codo durante un periodo acotado, normalmente entre una y cuatro semanas, para mejorar de forma medible la capacidad de detección y respuesta. La palabra "purple" viene de mezclar rojo y azul y describe la dinámica con literalidad: en lugar de medir con el blue a oscuras, se acuerda un catálogo de técnicas, se ejecutan en orden y se documenta paso a paso qué llegó al SIEM, qué generó alerta, qué pasó desapercibido y qué ajustar.

La pregunta que responde no es "¿podrían comprometernos?" (eso lo responde el red team) sino "¿qué detectamos hoy de cada técnica que un atacante real usaría contra nosotros?". Es un giro de foco: del impacto al mapa de cobertura.

En la práctica:

• Se selecciona un subconjunto del catálogo MITRE ATT&CK relevante, filtrado por sector, plataforma (Windows, Linux, cloud) y amenazas activas.
• El red team ejecuta cada técnica de forma controlada, anunciando comando y momento.
• El blue team observa su pila (SIEM, EDR, XDR, logs de red) y reporta qué llegó, qué se vio y qué se perdió.
• Ambos analizan el porqué de cada hueco: falta de telemetría, regla mal escrita, evento no parseado, ruido que oculta la señal.
• Se desarrolla o ajusta la detección, se vuelve a lanzar la técnica y se valida que ahora sí dispara.

Origen y evolución del modelo Purple Team

El término aparece en la comunidad de ciberseguridad alrededor de 2015, popularizado por charlas de SANS y por la consultora FireEye, cuando los SOC empezaban a ver que sus inversiones en SIEM no se traducían automáticamente en detecciones útiles. La intuición era simple: si solo medimos al blue cuando viene un red team que no quiere ser visto, perdemos la oportunidad de aprender técnica por técnica.

A partir de 2017 y 2018 varios factores aceleraron la adopción. MITRE ATT&CK ofreció un lenguaje común entre ofensiva y defensiva. Atomic Red Team puso al alcance de cualquier organización tests granulares ejecutables por técnica. Y consultoras europeas como Tarlogic publicaron playbooks abiertos que normalizaron el formato. Hoy el modelo Purple es prácticamente estándar en SOCs corporativos maduros y encaja con marcos europeos que exigen probar la eficacia de los controles, como NIS2 y DORA.

Purple Team vs red team vs ejercicio coordinado

Estos tres formatos se confunden en los pliegos. La diferencia importa porque cambia alcance, coste y, sobre todo, lo que aprendes.

Regla rápida: un red team te dice si pueden entrar sin que te enteres; un Purple Team te dice qué detectas de cada técnica y mejora reglas en el momento; un ejercicio coordinado valida un escenario puntual (por ejemplo, ransomware en un servidor de ficheros). Si nunca has hecho ninguno, empieza por Purple; si ya tienes detecciones razonables, ve a red.

Cuándo elegir un ejercicio Purple Team

Tres situaciones en las que Purple es la respuesta correcta:

• SOC en evolución que quiere medir cobertura real. Has invertido en SIEM y EDR pero no sabes qué porcentaje de ATT&CK detectas. Un Purple te da ese mapa y dice qué reglas faltan.
• Necesidad de desarrollar reglas custom. Detection engineering construye casos nuevos y necesita validar que disparan contra técnicas reales, no contra simulacros teóricos.
• Onboarding de tecnología nueva. Acabas de desplegar un EDR distinto, una XDR o una NDR y quieres saber qué detecta de verdad antes de fiarte del marketing.

También funciona como paso previo a un red team. Si tu blue nunca se ha enfrentado a movimiento lateral, Kerberoasting o evasión de EDR, llevarles directos a un red team de seis semanas suele acabar en frustración. No tiene sentido un Purple sin equipo defensivo, interno o externo, capaz de operar las detecciones: sin blue no hay con quién colaborar.

Workflow típico de un ejercicio Purple Team

La estructura habitual de un Purple Team profesional se mueve por cinco fases reconocibles:

1. Scoping y selección de técnicas. Se eligen las técnicas de MITRE ATT&CK más relevantes según sector, plataforma y amenazas activas. Para un cliente financiero europeo, técnicas de grupos como FIN7, Carbanak o Lazarus. Para un industrial, técnicas de ransomware operado por humanos. El catálogo suele tener entre 20 y 60 técnicas.

2. Preparación de telemetría. Antes de ejecutar nada, se verifica que el blue tiene la telemetría mínima activa: Sysmon en endpoints clave, auditoría avanzada de Windows, logs de PowerShell, integración EDR con SIEM, logs de red en puntos relevantes. Sin esto, ejecutar es ciego.

3. Ejecución y observación. El red team lanza cada técnica de forma controlada y notifica al blue, que observa su pila. El blue reporta si llegó el evento al SIEM, si disparó alerta, si llegó al EDR y si el analista la habría visto entre el ruido.

4. Análisis de huecos. Tras cada técnica ambos equipos analizan juntos. Si no hubo detección se identifica la causa: falta el evento en origen, regla mal escrita, ruido excesivo o campo no parseado.

5. Desarrollo de detección y retest. Se ajusta o crea la regla, se vuelve a lanzar la técnica y se valida que ahora sí dispara. Cada ciclo cierra con un entregable: una regla validada lista para producción. El cierre del ejercicio incluye un informe con la matriz ATT&CK marcada (detectado, parcial, no detectado) y la lista de reglas nuevas o ajustadas.

Frameworks fundamentales en Purple Team

Hay cuatro o cinco herramientas que cualquier equipo de Purple Team utiliza casi siempre, y conviene conocerlas para entender propuestas y entregables.

MITRE ATT&CK Navigator. Capa visual sobre el framework ATT&CK. Permite construir mapas (layers) con colores que indican cobertura por técnica. El entregable estándar incluye un layer exportado en JSON que el cliente puede mantener en el tiempo. Ver nuestra guía de MITRE ATT&CK.

Atomic Red Team. Proyecto mantenido por Red Canary que reúne tests atómicos asociados a cada técnica de ATT&CK. Cada test es un comando o script concreto que ejecuta esa técnica en su mínima expresión. La librería supera los miles de tests y está versionada en GitHub.

MITRE Caldera. Plataforma de adversary emulation automatizado mantenida por MITRE. Permite definir adversarios (combinaciones de técnicas) y ejecutar cadenas completas con agentes desplegados en las máquinas objetivo. Útil para escenarios complejos que van más allá del test atómico aislado.

VECTR. Herramienta de tracking diseñada para ejercicios Purple Team. Permite registrar cada técnica probada, el resultado de detección, las reglas creadas, el responsable y el estado de validación. Es la diferencia entre un Excel disperso y un repositorio histórico de cobertura por técnica.

PurpleSharp. Framework en .NET que ejecuta técnicas de adversarios en entornos Windows. Aporta cobertura específica sobre Active Directory, Kerberos, LSASS y movimiento lateral en dominios. Complementa a Atomic Red Team en entornos Windows corporativos. Lo habitual es combinar Atomic Red Team o PurpleSharp para ejecución, ATT&CK Navigator para el mapa y VECTR para el seguimiento.

Métricas medibles en un ejercicio Purple Team

Una razón de la extensión del modelo es que deja métricas duras, no solo sensaciones. Las más frecuentes en informes serios:

• Detection coverage: porcentaje de técnicas probadas que se detectaron, sobre la matriz ATT&CK. Indicador principal, comparable entre ejercicios.
• MTTD (Mean Time To Detect): tiempo medio entre ejecución y primera alerta en SIEM o EDR. Por técnica y agregado.
• MTTR (Mean Time To Respond): tiempo medio desde la alerta hasta la contención (aislamiento de endpoint, deshabilitación de cuenta).
• False positive rate: cuántas alertas legítimas son ruido tras las nuevas reglas. Una regla que detecta el 100 por cien pero dispara 200 falsos positivos al día no es útil.
• Alerts per analyst per shift: carga operativa del SOC. Un Purple bien hecho reduce ruido sin perder cobertura.

Idealmente se comparan entre ejercicios sucesivos. Un Purple semestral o anual permite ver progreso real y justificar inversión ante dirección.

Casos de uso comunes para Purple Team

Los ejercicios Purple que vemos más a menudo se reparten entre cinco escenarios:

• Validar una inversión en EDR o XDR nuevo. Acabas de cambiar de proveedor de EDR y quieres saber, antes de fiarte de la demo, qué detecta de verdad. Un Purple corto sobre técnicas clave responde sin esperar al primer incidente.
• Onboarding y formación de analistas nuevos. Ver al red ejecutar la técnica, observar el evento en el SIEM y entender por qué la regla dispara o no acelera el aprendizaje meses respecto a la formación teórica.
• Pre-audit de compliance. Antes de una auditoría NIS2 o seguimiento DORA, un Purple permite documentar evidencia objetiva de que se prueban controles, requisito explícito en ambas normas.
• Post-incident lessons learned. Tras un incidente, repetir las técnicas del atacante en formato Purple cierra de forma estructurada los huecos identificados.
• SIEM tuning regression. Cuando se cambia de SIEM, se actualiza el motor o se migra a cloud, un Purple sirve como regresión funcional: confirmar que las detecciones que funcionaban siguen funcionando.

Errores comunes en ejercicios Purple Team

Los Purple que salen mal fallan en patrones reconocibles:

• Alcance demasiado grande. Intentar cubrir cien técnicas en una semana garantiza ejecución superficial y cero retest. Mejor veinte técnicas bien que cien mal.
• Ejecutar sin medir. Pasar técnicas como en un guion sin documentar qué detectó cada una convierte el ejercicio en teatro. Sin matriz final no hay aprendizaje agregado.
• No retesting tras el fix. Crear la regla, asumir que funciona y pasar a la siguiente deja huecos invisibles. El retest distingue Purple de ingeniería de detección a ciegas.
• Blue team en modo defensivo. Si el blue siente que está siendo evaluado y oculta carencias, el ejercicio se rompe. El sponsor (CISO) tiene que dejar claro que el objetivo es mejora colectiva, no examen individual.
• Sin telemetría suficiente. Empezar sin verificar Sysmon, auditoría avanzada de Windows o integración con SIEM lleva a conclusiones erróneas: parece que no se detecta cuando en realidad no se está observando.
• No mantener el resultado en el tiempo. Un Purple aislado pierde valor si los entregables no se versionan ni se vuelven a validar tras seis meses, cuando el entorno ya ha cambiado.

Encaje normativo del Purple Team

Varios marcos europeos exigen, explícita o implícitamente, probar la eficacia de los controles y mantener evidencia objetiva. Purple Team encaja bien en ese hueco:

• NIS2, artículo 21. Entre las medidas para entidades esenciales e importantes se incluyen pruebas regulares de la eficacia de las medidas técnicas y organizativas. Un Purple periódico evidencia ese cumplimiento.
• DORA, artículo 24. Las entidades financieras deben realizar pruebas básicas y avanzadas de resiliencia operativa. Sin llegar al TLPT (red team intelligence-led), un Purple sirve para las pruebas básicas y prepara madurez antes del TLPT.
• ISO/IEC 27001:2022, control A.5.35. La revisión independiente de seguridad incluye revisión de la eficacia, no solo de la existencia, de los controles. Un Purple aporta evidencia técnica clara.
• ENS. La verificación periódica de medidas establecida por el ENS encaja con la mecánica Purple cuando se aplica a sistemas dentro del ámbito.

Documentar el ejercicio con matriz ATT&CK exportada, reglas creadas y métricas pre/post lo convierte en evidencia auditable reutilizable en auditorías de ISO 27001 o seguimientos NIS2.

Preguntas frecuentes sobre Purple Team

¿Necesito un SOC propio para hacer un Purple Team?

No es imprescindible. Si tu defensa está externalizada a un MSSP, puede hacerse el ejercicio si el MSSP acepta participar y dedica horas a observar telemetría y ajustar reglas durante las sesiones. Lo que sí es imprescindible es que alguien con acceso al SIEM y al EDR esté en la sala. Sin esa pieza, no hay ejercicio.

¿Cuánto tarda un ejercicio Purple Team típico?

Entre una y cuatro semanas según alcance. Un Purple focalizado en un escenario concreto (por ejemplo, técnicas de un ransomware específico) puede cerrarse en cinco días. Un Purple amplio que cubra varias tácticas de ATT&CK sobre Windows y cloud suele moverse en tres o cuatro semanas, con sesiones de ejecución intercaladas con desarrollo de detecciones.

¿Cuánto cuesta comparado con un red team?

Sustancialmente menos. Como referencia pública del sector, un Purple Team europeo medio se mueve entre 15.000 y 50.000 euros, frente a los 40.000 a 150.000 euros habituales de un red team full-scope. La diferencia se explica por duración menor, ausencia de fase larga de OSINT y por la naturaleza colaborativa que no requiere infraestructura ofensiva dedicada.

¿Es realista cubrir el 100 por cien de la matriz ATT&CK?

No, y nadie serio lo persigue. La matriz contiene cientos de técnicas con múltiples variantes. El objetivo es cubrir las técnicas relevantes para tu sector y entorno. Un buen Purple selecciona técnicas asociadas a los grupos APT activos contra tu vertical y prioriza por probabilidad e impacto.

¿Hay una herramienta favorita en la industria?

Para ejecución, Atomic Red Team es prácticamente estándar. Para tracking, VECTR es la opción más extendida en consultoras. Para visualización de cobertura, ATT&CK Navigator no tiene rival práctico. Lo importante no es la herramienta sino documentar cada paso y mantener el entregable en el tiempo.

¿Cada cuánto retestear las detecciones?

Las detecciones críticas se retestean idealmente cada vez que se actualiza versión de EDR o SIEM o cambia el entorno (migración a cloud, nuevo dominio Active Directory, despliegue de servicios). Como ciclo mínimo, una revisión semestral de las reglas del Purple anterior separa la detección viva de la obsoleta. Los entornos y los atacantes cambian, y una regla que funcionaba hace un año puede haber dejado de hacerlo sin que nadie lo note.

Recursos relacionados

• Qué es un Red Team: guía completa para empresas
• Pentesting vs Red Team: diferencias prácticas
• Qué es MITRE ATT&CK: tácticas y técnicas
• EDR vs XDR vs MDR: comparativa
• Qué es Threat Hunting
• Pentesting de Active Directory y modelo Tier

Purple Team con Secra

Si tu organización tiene SOC propio o externalizado y quieres saber qué porcentaje real de las técnicas relevantes detecta hoy, un Purple Team es la vía más eficiente para obtener esa respuesta y, a la vez, dejar el SOC mejor preparado de lo que estaba. En Secra diseñamos ejercicios Purple alineados con MITRE ATT&CK, integrando Atomic Red Team y VECTR como entregables versionables que puedes mantener en el tiempo. Si encaja con tu pipeline, hablamos y planteamos el alcance; si no encajamos, te decimos a qué proveedor del sector deberías acudir y por qué.