Purple team: emulación coordinada ATT&CK con detección simultánea

Purple team no es un tercer equipo que se sienta entre el red team y el blue team. Es una metodología de trabajo donde ambos equipos colaboran en tiempo real: el lado ofensivo emula técnicas de adversarios reales mientras el lado defensivo monitoriza, detecta (o no detecta) y mejora sus reglas sobre la marcha. El objetivo no es "ganar" sino medir la capacidad de detección real del entorno y cerrar los gaps que aparezcan.

En la práctica tradicional, un red team opera en sigilo durante semanas y al final entrega un informe. El blue team no sabe qué pasó hasta que lee ese documento, y las lecciones aprendidas llegan tarde. Purple team cambia esa dinámica: la emulación es abierta, técnica por técnica, y el feedback es inmediato. Es la octava lección de la Tanda 8.

Purple team se practica en entornos autorizados y controlados. Las técnicas ofensivas que se describen aquí son para emulación coordinada con el SOC, nunca para uso no autorizado. En whoami-labs puedes practicar la parte ofensiva en laboratorios como orthrus y titancorp, que incluyen Active Directory con detección activa.

Qué es purple team#

Purple team es una metodología iterativa que combina la emulación de adversarios (red) con la validación de detecciones (blue) en ciclos cortos. La idea central es simple: no puedes saber si detectas algo hasta que alguien lo ejecuta de verdad en tu entorno.

Un ejercicio purple team típico tiene tres fases:

• Planificación conjunta: ambos equipos eligen las técnicas ATT&CK a emular, definen el alcance (qué sistemas, qué horario, qué queda fuera) y establecen las reglas de engagement.
• Ejecución coordinada: el red team ejecuta una técnica, avisa al blue team, y ambos observan si las detecciones existentes la capturan. Se documenta todo: qué telemetría se generó, qué regla disparó (o no), y por qué.
• Debrief y mejora: ambos equipos revisan los resultados, identifican gaps, y el blue team escribe o tunea las reglas necesarias. Esas reglas se prueban inmediatamente contra la misma técnica.

El resultado medible es un mapa de cobertura ATT&CK que muestra, con evidencia, qué técnicas detectas y cuáles no.

Por qué no basta con red team o blue team por separado#

El modelo tradicional tiene problemas estructurales que purple team resuelve:

Purple team no reemplaza al red team ni al blue team. Los tres modelos coexisten. Un red team assessment sigue siendo útil para medir la postura de seguridad global. Pero purple team es la forma más eficiente de mejorar la capacidad de detección del SOC de forma medible y continua.

ATT&CK como lenguaje común#

MITRE ATT&CK es el framework que hace posible purple team. Proporciona:

• Taxonomía compartida: ambos equipos hablan de T1059.001 (PowerShell), no de "el script raro que lanzamos ayer".
• Cobertura medible: ATT&CK Navigator permite colorear cada técnica según el estado de detección (detectada, parcial, sin cobertura).
• Priorización basada en threat intel: los grupos adversarios relevantes a tu industria usan técnicas específicas. ATT&CK las documenta con referencias reales.

Para elegir qué técnicas emular en un ejercicio, el proceso es:

• Identificar los threat actors relevantes a tu sector y geografía (por ejemplo, APT29 para gobierno europeo, FIN7 para retail).
• Extraer sus TTPs documentados en ATT&CK.
• Cruzar con tu mapa de cobertura actual: las técnicas usadas por adversarios relevantes que no tienes detectadas son la prioridad.

Planificación de un ejercicio#

Un ejercicio bien planificado necesita documentación antes de ejecutar nada:

Scope y reglas de engagement#

• Sistemas en alcance: qué endpoints, servidores, segmentos de red se incluyen.
• Horario: ejecución en horario laboral para que el SOC esté staffed.
• Exclusiones: sistemas de producción críticos que no se tocan, técnicas destructivas que no se ejecutan (wiper, ransomware real).
• Comunicación: canal dedicado (Slack, Teams) para coordinación en tiempo real.
• Kill switch: procedimiento para parar inmediatamente si algo sale mal.

Selección de técnicas#

Cada ejercicio cubre un subconjunto de técnicas. Un buen criterio es elegir entre 5 y 15 técnicas por sesión, agrupadas por táctica (Initial Access, Execution, Persistence, etc.). Intentar cubrir 50 técnicas en una sesión produce datos de baja calidad porque no hay tiempo para analizar cada resultado.

Ejercicio Purple Team #4 — Credential Access
Fecha: 2026-11-15
Scope: Dominio AD CORP.LOCAL

Técnicas a emular:
  T1003.001 — OS Credential Dumping: LSASS Memory
  T1003.003 — OS Credential Dumping: NTDS
  T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting
  T1110.003 — Brute Force: Password Spraying
  T1552.006 — Unsecured Credentials: Group Policy Preferences

Ejecución: emulación con detección simultánea#

Durante la ejecución, el red team avisa al blue team antes de cada técnica (o inmediatamente después, según el nivel de madurez). El flujo técnica por técnica es:

• Red team ejecuta: lanza la técnica usando herramientas reales o simulaciones.
• Blue team observa: revisa el SIEM, EDR, y herramientas de red en tiempo real.
• Registro de resultado: se documenta en una tabla compartida.

| Técnica       | Herramienta usada    | Detectada | Regla que disparó    | Notas                    |
| T1558.003     | Rubeus kerberoast    | Sí        | Sigma-kerb-rc4-001   | Detectó en 12 seg        |
| T1003.001     | Mimikatz sekurlsa    | Parcial   | EDR alert genérica   | Sin contexto de técnica  |
| T1110.003     | Spray.py             | No        | —                    | Gap: sin regla de spray  |

Herramientas de emulación#

Atomic Red Team es el punto de entrada recomendado. Un solo comando ejecuta y documenta una técnica ATT&CK:

# Emular T1059.001 — PowerShell execution
Invoke-AtomicTest T1059.001 -TestNumbers 1

# Limpiar artefactos después del test
Invoke-AtomicTest T1059.001 -TestNumbers 1 -Cleanup

Para emulaciones más realistas, MITRE Caldera permite definir un adversary profile completo que encadena técnicas en orden lógico (reconocimiento → acceso → persistencia → exfiltración) y ejecuta el plan automáticamente contra agentes desplegados en los sistemas en alcance.

Debrief y gap analysis#

El debrief es la fase más valiosa. Ambos equipos revisan juntos, técnica por técnica:

• ¿Se detectó? Si sí, ¿en qué paso? ¿Con qué latencia? ¿La alerta tenía contexto suficiente para que un analista L1 actúe?
• ¿No se detectó? ¿Por qué? ¿Falta la telemetría (no hay logs)? ¿Hay telemetría pero falta la regla? ¿Hay regla pero está mal escrita?
• ¿Falso positivo? ¿La regla dispara con actividad legítima? ¿Cuántas veces al día?

El resultado se plasma en ATT&CK Navigator, que permite exportar e importar capas JSON de cobertura. Cada celda tiene un color:

• Verde: técnica detectada con regla probada y FP rate controlado.
• Amarillo: detección parcial (regla existe pero sin test, o con FP alto).
• Rojo: gap, sin detección. Priorizar según threat intel.

De gap a detección#

Cuando el ejercicio descubre un gap, el flujo para cerrarlo es:

• Analizar qué telemetría genera la técnica (logs, eventos de red, artefactos en disco).
• Verificar que esa telemetría llega al SIEM (problemas de parsing, ingesta o retención son frecuentes).
• Escribir la regla Sigma, YARA o Suricata correspondiente.
• Probar la regla contra la técnica que el red team acaba de ejecutar (los logs ya están ahí).
• Integrar en el pipeline CI/CD de detection-as-code.

# Regla escrita durante el debrief del ejercicio
title: Password Spray Against Domain Controller
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
        LogonType: 3
    timeframe: 10m
    condition: selection | count(TargetUserName) by IpAddress > 15
level: high
tags:
    - attack.credential_access
    - attack.t1110.003
falsepositives:
    - Vulnerability scanners authenticated
    - Service account rotation scripts

Esta regla detecta más de 15 intentos de login fallidos desde la misma IP en 10 minutos contra usuarios distintos, patrón característico de password spraying. El red team vuelve a ejecutar la técnica para confirmar que ahora sí se detecta.

Métricas de un programa purple team#

Un programa maduro mide su progreso con métricas cuantitativas:

Un SOC que empieza con 20% de cobertura ATT&CK sobre sus técnicas prioritarias y ejecuta ejercicios purple team mensuales puede llegar a 60-70% en un año, siempre que mantenga el pipeline de detection-as-code y revise las reglas existentes.

Ejemplo práctico: T1059.001 PowerShell#

Un ejercicio purple team para una sola técnica, paso a paso.

Paso 1: preparación#

El red team elige T1059.001 (Command and Scripting Interpreter: PowerShell). El blue team confirma que tiene Sysmon configurado con logging de process creation (Event ID 1) y PowerShell ScriptBlock logging habilitado (Event ID 4104).

Paso 2: ejecución#

El red team ejecuta en el endpoint objetivo con Atomic Red Team:

# Descarga y ejecución in-memory
Invoke-AtomicTest T1059.001 -TestNumbers 1

El test lanza un comando PowerShell que descarga y ejecuta un payload en memoria (inofensivo, de Atomic Red Team).

Paso 3: observación#

El blue team revisa en el SIEM:

Sysmon Event ID 1 — Process Create
  ParentImage: powershell.exe
  CommandLine: powershell -exec bypass -nop -c "IEX (New-Object Net.WebClient).DownloadString(...)"

PowerShell Event ID 4104 — ScriptBlock
  ScriptBlockText: [contenido decodificado del script]

Paso 4: evaluación#

• ¿La regla Sigma existente para PowerShell download cradles disparó? Si sí, ¿con qué latencia? ¿El contexto de la alerta es accionable?
• ¿ScriptBlock logging capturó el contenido decodificado? Esto es clave para analistas.
• ¿Hay variantes que la regla no cubre? Por ejemplo, Invoke-WebRequest en lugar de Net.WebClient.

Paso 5: mejora#

Si la regla no cubría todas las variantes, se amplía y se prueba contra cada variante en la misma sesión. Si el ScriptBlock logging no estaba habilitado, se configura y se documenta como requisito.

Errores comunes#

Patrones que reducen el valor de un ejercicio purple team:

• Ejecutar sin documentar: si no se registra el resultado técnica por técnica, el ejercicio pierde su valor de medición y no se pueden comparar iteraciones.
• Elegir demasiadas técnicas: intentar cubrir 50 técnicas en una sesión produce análisis superficial. Es mejor 8 técnicas bien analizadas que 50 marcadas con un "sí/no" genérico.
• No involucrar al SOC real: si los analistas L1/L2 no participan, no se valida si las alertas son accionables para ellos (no solo para el detection engineer).
• Olvidar la telemetría: muchos gaps no son de reglas sino de logs que no llegan. Antes de escribir una regla, hay que confirmar que la fuente de datos existe y se ingesta correctamente.
• No repetir: un solo ejercicio da una foto. El valor está en la repetición mensual o trimestral que muestra tendencia de mejora.
• Purple team sin threat intel: emular técnicas al azar no prioriza. Las técnicas a emular deben venir de threat intelligence relevante a la organización.

Preguntas frecuentes#

¿Se necesita un red team dedicado?#

No necesariamente. Un detection engineer con conocimiento ofensivo puede ejecutar Atomic Red Team o Caldera mientras el SOC observa. El purple team es una actividad, no un rol permanente. En organizaciones grandes sí conviene tener operadores ofensivos dedicados para emulaciones más realistas.

¿Con qué frecuencia se hacen ejercicios?#

Mensual es ideal para SOCs maduros. Trimestral es un buen punto de partida. Lo importante es la regularidad: un ejercicio trimestral consistente durante un año supera a un ejercicio anual intensivo porque permite medir tendencia.

¿Qué diferencia hay con un pentest?#

Un pentest busca vulnerabilidades explotables y entrega un informe de hallazgos. Purple team no busca vulnerabilidades sino que valida detecciones. El pentest pregunta "¿puedo entrar?" y purple team pregunta "¿detectas que entré?". Son complementarios.

¿Cómo empiezo si mi SOC es pequeño?#

Instala Atomic Red Team en una VM de prueba, elige 5 técnicas prioritarias de ATT&CK, ejecútalas una por una y revisa si tu SIEM genera alertas. Documenta los resultados en una hoja de cálculo. Eso ya es purple team. No necesitas herramientas caras ni un equipo grande.

¿Se puede hacer purple team en cloud?#

Sí, y es cada vez más importante. Los cloud providers tienen sus propias fuentes de telemetría (CloudTrail, Azure Activity Log, GCP Audit Log) y sus propias técnicas ATT&CK (existe la matriz ATT&CK for Cloud). Herramientas como Stratus Red Team de DataDog permiten emular técnicas cloud específicas.

Resumen#

• Purple team es una metodología de colaboración, no un equipo separado: red emula, blue detecta, ambos mejoran juntos.
• ATT&CK es el lenguaje común que hace medible la cobertura de detección.
• Atomic Red Team y MITRE Caldera permiten emular técnicas de forma reproducible y documentada.
• Gap analysis con ATT&CK Navigator produce un mapa visual de qué detectas y qué no.
• Detection-as-code convierte los hallazgos del ejercicio en reglas versionadas, testeadas y desplegadas por CI/CD.
• Métricas (cobertura, MTTD, FP rate, gaps cerrados) demuestran el valor del programa y guían la priorización.
• Repetición regular (mensual o trimestral) es lo que transforma ejercicios puntuales en mejora continua.

Fuentes y lecturas recomendadas#

• MITRE ATT&CK
• ATT&CK Navigator
• Atomic Red Team
• MITRE Caldera
• Purple Team Exercise Framework (PTEF) de SCYTHE
• MITRE ATT&CK T1059.001 PowerShell
• MITRE ATT&CK T1110.003 Password Spraying
• Stratus Red Team — DataDog