IntermedioMITRE ATT&CKevaluacionesEDRtelemetriadeteccionTurla

MITRE Engenuity ATT&CK Evaluations: Cómo Leer los Resultados de EDR

Guia para interpretar las evaluaciones MITRE Engenuity ATT&CK de productos EDR. Metodologia, categorias de deteccion (telemetry, general, tactic, technique), como leer los resultados de Round 5 (Turla), errores comunes de interpretacion y uso para decisiones de compra.

MalwareIntel Research··10 min lectura
Serie: EDR/XDR Telemetría por Vendor — Parte 12

Que son las MITRE ATT&CK Evaluations

Las MITRE ATT&CK Evaluations, gestionadas por MITRE Engenuity (la division de I+D aplicada de MITRE), son las evaluaciones mas rigurosas y transparentes de productos de seguridad en el mercado. Desde 2018, MITRE ejecuta simulaciones de adversarios reales contra los principales EDR y publica los resultados completos, paso a paso, de forma publica.

Lo que hace unicas estas evaluaciones:

  • Transparencia total: cada paso del ataque y cada deteccion (o falta de ella) se documenta publicamente
  • Sin puntuacion ni ranking: MITRE no declara ganadores. Los datos estan disponibles para que cada organizacion los interprete
  • Adversario real: cada ronda simula las tacticas, tecnicas y procedimientos (TTPs) de un grupo APT real
  • Participacion voluntaria: los vendors eligen participar y pagan por hacerlo

Rondas completadas

RondaAnoAdversarioFoco
Round 12018APT3 (Gothic Panda)Evaluacion inicial
Round 22020APT29 (Cozy Bear)Espionaje estatal
Round 32021Carbanak + FIN7Cibercrimen financiero
Round 42022Wizard Spider + SandwormRansomware + destructivo
Round 52023Turla (Snake)Espionaje estatal avanzado
Round 62024CL0P + LockBitRansomware moderno

Cada ronda anade complejidad y simula adversarios con TTPs diferentes, lo que permite evaluar la cobertura de los productos en distintos escenarios.

Metodologia de evaluacion

Escenario de ataque

MITRE define un escenario de ataque detallado basado en los TTPs documentados del adversario objetivo. Por ejemplo, en Round 5 (Turla), el escenario incluyo:

  • Spearphishing con documento malicioso
  • Descarga de implant (Carbon, Snake)
  • Descubrimiento del entorno
  • Movimiento lateral via SMB
  • Escalacion de privilegios
  • Exfiltracion de datos via canal C&C cifrado
  • Persistencia mediante tareas programadas y servicios

El ataque se ejecuta paso a paso contra los endpoints protegidos por cada vendor. El equipo MITRE opera el red team y documenta cada accion.

Categorias de deteccion

Las categorias de deteccion son el concepto clave para interpretar los resultados. MITRE clasifica cada deteccion en una jerarquia:

None: el producto no detecto ni registro nada sobre este paso del ataque. Punto ciego total.

Telemetry: el producto registro el evento en sus datos crudos, pero no genero ninguna alerta ni enriquecimiento. Un analista tendria que buscar proactivamente en los logs para encontrarlo.

General: el producto genero una alerta o marco el evento como sospechoso, pero sin especificar que tecnica ATT&CK esta ocurriendo. Ejemplo: "actividad sospechosa detectada en el proceso cmd.exe".

Tactic: el producto identifico el objetivo tactico (la columna ATT&CK) pero no la tecnica especifica. Ejemplo: "actividad de Persistence detectada" sin especificar si es via Scheduled Task, Registry Run Key u otro mecanismo.

Technique: el producto identifico la tecnica especifica ATT&CK. Ejemplo: "T1053.005 Scheduled Task/Job: Scheduled Task detected". Esta es la deteccion mas precisa y util.

Modificadores adicionales

Ademas de la categoria, MITRE registra modificadores:

  • Configuration Change: la deteccion requirio un cambio de configuracion durante la evaluacion (no funciona out-of-the-box)
  • Delayed: la deteccion no fue en tiempo real, llego con retraso
  • Host Interrogation: requirio que el analista ejecutara una consulta activa al endpoint

Estos modificadores son criticos para la interpretacion: una deteccion "Technique" con "Configuration Change" significa que el producto puede detectar esa tecnica, pero no lo hace por defecto. En produccion, si el equipo no activa esa configuracion, la deteccion no existira.

Como leer los resultados

El portal de resultados

Los resultados se publican en attackevals.mitre-engenuity.org. Para cada vendor y cada paso del ataque, se muestra:

  • Descripcion del paso (que hizo el atacante)
  • Categoria de deteccion asignada
  • Evidencia: capturas de pantalla del producto mostrando la deteccion
  • Notas sobre modificadores o condiciones especiales

Metricas que importan

Visibility (Telemetry + General + Tactic + Technique): cuantos pasos del ataque fueron al menos registrados. Un producto con alta visibility tiene buen logging, aunque no necesariamente buena deteccion.

Analytic Coverage (General + Tactic + Technique): cuantos pasos generaron alguna alerta o enriquecimiento. Esto indica la capacidad de deteccion real, porque un analista sera notificado sin tener que buscar.

Technique Coverage: cuantos pasos fueron identificados con la tecnica ATT&CK especifica. Esta es la metrica de mayor calidad: detecciones precisas que dan al analista contexto inmediato.

None count: cuantos pasos pasaron completamente desapercibidos. Cuanto menor, mejor.

Ejemplo: interpretar Round 5 (Turla)

Round 5 simulo dos escenarios de Turla con un total de 143 substeps. Veamos como leer los resultados de un vendor hipotetico:

CategoriaDeteccionesPorcentaje
Technique8962%
Tactic128%
General86%
Telemetry2215%
None128%

Interpretacion:

  • 62% Technique: la mayoria de las detecciones son precisas. El analista recibe contexto ATT&CK directo
  • 15% Telemetry: los datos estan disponibles pero sin alertar. Util para hunting, no para deteccion pasiva
  • 8% None: 12 pasos del ataque pasaron completamente desapercibidos. Hay que investigar cuales son esos gaps y si son relevantes para tu organizacion

Ahora imaginemos otro vendor:

CategoriaDeteccionesPorcentaje
Technique12084%
Tactic53%
General107%
Telemetry53%
None32%

A primera vista parece claramente superior. Pero hay que verificar:

  • Cuantas detecciones Technique requirieron Configuration Change
  • Cuantas fueron Delayed
  • Cual es el nivel de ruido en produccion (las evaluaciones MITRE no miden falsos positivos)

Errores comunes de interpretacion

Error 1: tratar los resultados como ranking

MITRE publica datos, no rankings. Un vendor puede tener 100% de deteccion Technique pero generar tanto ruido en produccion que los analistas ignoran las alertas. Los resultados muestran capacidad, no eficacia operativa.

Error 2: ignorar los Configuration Changes

Si un vendor necesito 30 Configuration Changes para lograr alta deteccion, eso significa que su configuracion por defecto tiene gaps significativos. Pregunta clave: "¿mi equipo sabria activar todas esas configuraciones?"

Error 3: comparar rondas diferentes

Cada ronda simula un adversario diferente con TTPs diferentes. Comparar los resultados de un vendor en Round 3 (Carbanak/FIN7) con otro vendor en Round 5 (Turla) no tiene sentido. Solo se pueden comparar vendors que participaron en la misma ronda.

Error 4: enfocarse solo en deteccion

Las evaluaciones MITRE no miden:

  • Falsos positivos: un producto puede detectar todo y generar un tsunami de alertas irrelevantes
  • Rendimiento: impacto en el endpoint (CPU, RAM, I/O)
  • Usabilidad: facilidad de investigacion y triaje
  • Prevencion: capacidad de bloquear el ataque (solo se mide en rounds recientes)
  • Soporte y operaciones: calidad del soporte tecnico del vendor

Error 5: asumir que Telemetry es malo

Telemetry no es un fallo: significa que el producto registro los datos. Para un threat hunter, tener la telemetria disponible puede ser mas valioso que una alerta generica. La pregunta es: ¿tu equipo tiene hunters que aprovecharan esos datos?

Error 6: confiar en los graficos de los vendors

Despues de cada evaluacion, los vendors publican sus propios analisis con graficos que invariablemente los posicionan como lideres. Estos graficos suelen:

  • Seleccionar metricas favorables
  • Combinar categorias de formas creativas
  • Omitir Configuration Changes
  • Comparar con subconjuntos de competidores

La unica fuente fiable es el portal oficial de MITRE Engenuity. Todo lo demas es marketing.

Proteccion vs Deteccion

A partir de Round 4, MITRE incluyo escenarios de proteccion (prevencion) ademas de deteccion. La diferencia es fundamental:

  • Deteccion: el producto registro o alerto sobre la actividad maliciosa, pero no la detuvo
  • Proteccion: el producto bloqueo la actividad maliciosa antes de que se completara

Los resultados de proteccion muestran en que paso del ataque el producto intervino y como (bloqueo de proceso, cuarentena de archivo, aislamiento de endpoint). Un producto con alta deteccion pero baja proteccion ve todo pero no hace nada al respecto.

Para un SOC con recursos limitados, la proteccion automatica puede ser mas valiosa que la deteccion. Para un equipo maduro con threat hunters, la deteccion (especialmente Telemetry rica) puede ser preferible a la proteccion que interrumpe las investigaciones.

Usar las evaluaciones para decisiones de compra

Paso 1: definir tu threat model

No todas las tecnicas ATT&CK son igualmente relevantes para tu organizacion. Antes de mirar los resultados:

  1. Identifica los threat actors que apuntan a tu sector e industria
  2. Lista las tecnicas ATT&CK que esos actores utilizan
  3. Prioriza las tecnicas por impacto potencial en tu entorno

Paso 2: filtrar por ronda relevante

Elige la ronda cuyo adversario sea mas cercano a tus amenazas reales:

  • Sector financiero: Round 3 (Carbanak/FIN7) y Round 6 (CL0P/LockBit)
  • Gobierno/defensa: Round 2 (APT29) y Round 5 (Turla)
  • Infraestructura critica: Round 4 (Sandworm)

Paso 3: analizar las tecnicas criticas

Para cada tecnica que priorizaste, verifica en los resultados:

  • ¿El vendor la detecto? ¿Con que categoria?
  • ¿Requirio Configuration Change?
  • ¿Fue Delayed o en tiempo real?
  • ¿Bloqueo el ataque (si hay datos de proteccion)?

Paso 4: evaluar los gaps

Los "None" son los gaps criticos. Para cada tecnica que un vendor no detecto:

  • ¿Es una tecnica relevante para tu threat model?
  • ¿Hay mitigaciones compensatorias en tu stack? (firewall, WAF, proxy)
  • ¿Otro vendor que evaluas si la detecta?

Paso 5: cruzar con otros criterios

Las evaluaciones MITRE son una dimension de la decision, no la unica. Cruzar con:

  • Coste total (licencias + personal + infraestructura)
  • Integracion con tu stack existente (SIEM, SOAR, ticketing)
  • Soporte tecnico y SLAs
  • Resultados de PoC en tu propio entorno (ver articulo dedicado)
  • Impacto en rendimiento de los endpoints
  • Retencion de datos y privacidad

Tendencias en las evaluaciones

Mayor enfoque en proteccion

Las rondas recientes incluyen escenarios de proteccion, reflejando la expectativa del mercado de que un EDR no solo detecte sino que prevenga.

Adversarios mas sofisticados

Cada ronda sube el nivel: de APT3 (tecnicas relativamente simples) a Turla (uno de los grupos mas sofisticados, con implants que evaden deteccion activamente). Esto expone diferencias entre productos que en rondas anteriores parecian similares.

Mas vendors participantes

El numero de vendors que participan ha crecido, incluyendo ahora no solo EDR sino tambien soluciones XDR, SIEM y plataformas cloud. Esto amplica la utilidad de las evaluaciones para decisiones de stack completo.

Linux y macOS

Las rondas recientes incluyen escenarios en Linux y macOS, no solo Windows. Esto es critico para organizaciones con entornos mixtos.

Recursos

Para profundizar en las evaluaciones MITRE ATT&CK:

  • Portal oficial de resultados: attackevals.mitre-engenuity.org
  • Metodologia detallada: cada ronda publica su plan de evaluacion completo
  • Blog de MITRE Engenuity: analisis de tendencias y guias de interpretacion
  • MITRE ATT&CK Navigator: herramienta para visualizar cobertura de tecnicas y comparar

Conclusion

Las evaluaciones MITRE Engenuity son la fuente mas objetiva de datos sobre la capacidad de deteccion de productos EDR. Pero requieren interpretacion cuidadosa. No son un ranking, no miden todo lo que importa (falsos positivos, rendimiento, usabilidad), y los vendors publican analisis sesgados de los resultados.

El valor real de las evaluaciones esta en la transparencia: cada paso, cada deteccion, cada gap esta documentado publicamente. Ningun otro benchmark de seguridad ofrece ese nivel de detalle. Usarlas correctamente requiere entender la metodologia, definir tu propio threat model, y cruzar los resultados con evaluaciones practicas en tu entorno real.

Preguntas frecuentes

Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.