Ir al contenido

MITRE ATLAS vs. ATT&CK: mapeando ataques a modelos

ATT&CK describe lo que el adversario hace en la infraestructura. ATLAS describe lo que hace en el modelo. Los ataques reales atraviesan ambos — y es en la costura entre ellos donde falla la detección.

Los equipos de seguridad maduros ya hablan ATT&CK. Las detecciones se escriben contra técnicas, los informes de red team se mapean a tácticas y la cobertura se mide en matriz. Cuando la IA entra en producción, la pregunta natural es: ¿dónde encaja esto?

La respuesta corta: en parte encaja, en parte no — y el incidente real ocurre exactamente en la costura.

Dos matrices, dos dominios

MITRE ATT&CK cataloga el comportamiento adversario contra sistemas tradicionales. Las tácticas son conocidas: acceso inicial, ejecución, persistencia, evasión de defensa, movimiento lateral, exfiltración. El supuesto es una frontera entre código y datos, y la explotación ocurre cuando el atacante cruza esa frontera.

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) cataloga el comportamiento adversario contra sistemas de machine learning. Reaprovecha la estructura táctica de ATT&CK, pero agrega lo que no existe en el mundo tradicional: reconocimiento de modelo, acceso al artefacto de ML, envenenamiento de datos de entrenamiento, evasión del modelo, inferencia de pertenencia, extracción de modelo.

La diferencia no es de vocabulario. Es de superficie. ATT&CK describe lo que el adversario hace en la infraestructura. ATLAS describe lo que hace en el modelo.

Dónde se superponen las matrices — y dónde no

Algunas tácticas tienen correspondencia casi directa. Reconocimiento es reconocimiento; exfiltración es exfiltración. El canal cambia, la intención no.

Otras no tienen par:

  • Envenenamiento de datos de entrenamiento no tiene equivalente en ATT&CK. No existe en el modelo mental clásico un ataque que altera el comportamiento futuro de un sistema modificando el material del cual aprende.
  • Evasión del modelo — construir una entrada que el clasificador lee de forma distinta al humano — es una clase propia.
  • Extracción de modelo por consulta es exfiltración sin movimiento de archivo. Ningún DLP basado en contenido la detecta.

Y está la asimetría inversa: ATLAS no cubre bien lo que ocurre después de que el modelo es comprometido. Un agente de IA que ejecuta comandos en la máquina del desarrollador está firmemente en territorio ATT&CK — Ejecución, T1059. La técnica es clásica; solo el punto de entrada es nuevo.

El ataque real atraviesa ambas

Por eso mapear un incidente de IA a una única matriz siempre deja lagunas. Considere el patrón observado en incidentes de 2025–2026 con asistentes de código:

  1. ATLAS — el adversario planta instrucciones en contenido que el asistente va a consumir. Prompt injection indirecto: sin credencial, sin exploit, solo texto en el lugar correcto.
  2. ATLAS — las instrucciones manipulan el comportamiento del modelo, evadiendo las restricciones definidas en el system prompt.
  3. Costura — el modelo emite una llamada de herramienta. Aquí el ataque sale del dominio del ML y entra en el dominio de la infraestructura. Ninguna de las dos matrices describe bien esa transición.
  4. ATT&CK — la herramienta ejecuta. Ejecución de comando, escritura en archivo, petición de red. Técnicas conocidas, detecciones conocidas.
  5. ATT&CK + ATLAS — persistencia. Si el payload queda en un archivo de configuración, es ATT&CK. Si queda en la memoria del agente o en el vector store, es territorio ATLAS, y no hay detección estándar.

CVE-2025-53773 (GitHub Copilot) y CurXecute (Cursor IDE) siguen esa forma: entrada en lenguaje natural, salida en ejecución de comando. GeminiJack mostró la variante zero-click con movimiento lateral por un entorno corporativo entero. En los 21 incidentes de promptware que catalogamos entre 2025 y 2026, 15 presentaron cuatro o más etapas encadenadas — ninguno de ellos cabe entero en una sola matriz.

La costura es donde falla la detección

Junte la cobertura de las dos matrices en un entorno típico y el mapa de detección queda así:

  • Lado ATT&CK — razonablemente instrumentado. EDR en la ejecución, logs de red en la exfiltración, gestión de identidad en el movimiento lateral.
  • Lado ATLAS — casi sin instrumentar. Pocas organizaciones registran lo que entró en la ventana de contexto, lo que se escribió en la memoria del agente o lo que se indexó en el vector store.
  • La costura — invisible. Una llamada de herramienta emitida por el modelo aparece en el log como una petición legítima de la aplicación. El log registra qué se hizo; no registra qué input lo originó.

Esa última línea explica por qué el 57% de los incidentes catalogados mantuvo persistencia activa después de la detección inicial. La organización detectó el efecto en la capa ATT&CK, remedió allí, y el payload continuó en la capa ATLAS — en la memoria, en el índice, en el documento.

Cómo usar ambas en la práctica

1. Mapee los hallazgos a las dos matrices, no a una. Un informe de red team de IA que cita solo ATLAS no dialoga con el SOC. Uno que cita solo ATT&CK pierde el origen del ataque. Cada hallazgo debe decir: técnica ATLAS de entrada, técnica ATT&CK de impacto.

2. Instrumente la costura primero. El control de mayor retorno no es la detección de prompt malicioso — es la correlación. Toda llamada de herramienta iniciada por un modelo debe registrarse con el identificador del input que la originó. Sin eso, ninguna investigación de incidente de IA llega a la causa raíz.

3. Extienda la matriz de cobertura existente. Si el equipo ya mide cobertura ATT&CK, agregue las columnas ATLAS al mismo panel. Dos matrices en dos informes separados garantizan que nadie mire la intersección.

4. Trate la persistencia en ATLAS como persistencia de verdad. La memoria de agente, los embeddings y las reglas de proyecto son mecanismos de persistencia con todas las propiedades relevantes: sobreviven a la sesión, influyen en la ejecución futura, no se inspeccionan. Merecen revisión, expiración y log — los mismos controles que usted aplicaría a una tarea programada.

El papel de cada framework

Ninguna de las dos matrices es un programa de pruebas. Son taxonomías — sirven para nombrar, comunicar y medir cobertura, no para decir qué ejecutar.

Por eso nuestros ejercicios usan la Promptware Kill Chain como secuencia operativa y mapean cada etapa de vuelta a ATLAS y ATT&CK. La kill chain define el camino; las matrices dan el lenguaje común con el SOC.

Combinados, los tres responden a la pregunta que importa al consejo: no "cuántas técnicas cubrimos", sino "si el adversario entra por el modelo, hasta dónde llega — y en qué punto lo vemos".


Para mapear sus sistemas de IA contra ATLAS y ATT&CK, conozca nuestro Red Team para IA o hable con el equipo.

Volver a Insights