Adversarial Exposure Validation para AWS

Por el equipo de Pathbreak · 24 de octubre de 2026 · 7 min de lectura

Adversarial Exposure Validation, normalmente abreviado como AEV, es la práctica de probar las exposiciones como lo haría un atacante, para que el equipo de seguridad sepa qué hallazgos se pueden usar y cuáles no. Gartner usa el término para una categoría de herramientas que surgió de Breach and Attack Simulation y de las pruebas de penetración automatizadas. La idea común es que la validación añade pruebas a lo que reporta un escáner, para que el equipo pueda actuar sobre los hallazgos que se ha demostrado que funcionan.

Este artículo trata de lo que eso significa específicamente en AWS, porque el plano de control de la nube cambia tanto el método como el resultado.

Por qué AWS necesita su propio tipo de validación

En una red, validar una exposición significa enviar tráfico: si la herramienta puede llegar al host, si puede autenticarse, si puede moverse. La evidencia es una conexión conseguida o una credencial capturada. En el plano de control de AWS no hay hosts a los que llegar. Cada movimiento del atacante es una llamada a la API, y que una llamada tenga éxito lo decide un conjunto de documentos de política que AWS evalúa en conjunto: las políticas de identidad de quien llama, cualquier límite de permisos, las políticas de control de servicios de la unidad organizativa de la cuenta, la política de confianza o de recursos del destino y las claves de condición de cada sentencia.

Eso tiene dos consecuencias. Primera, una ruta se puede validar sin ejecutarla, porque resolver esos documentos en modo de solo lectura produce el mismo permiso o denegación que produciría la llamada. Segunda, una herramienta que solo lee políticas de identidad sobrestimará la superficie de ataque, ya que las SCP y los límites de permisos eliminan una buena parte de lo que las políticas de identidad parecen conceder.

Qué validar en AWS

Cuatro tipos de exposición explican la mayoría de las rutas demostradas que vemos en cuentas reales.

Escalada de privilegios en IAM. Un principal con un permiso o una combinación que le permite llegar a un rol más privilegiado: iam:PassRole con una acción de creación de cómputo, adjuntar políticas y escribir políticas en línea, reescribir políticas de confianza, crear claves de acceso. El Mapa de Escalada de Privilegios de AWS los enumera con el evento de CloudTrail y el cambio que rompe cada uno.

Confianza entre cuentas. Roles que confían en otra cuenta, en un proveedor o en un comodín, donde el lado que confía es privilegiado y el lado en el que se confía es más débil de lo que nadie suponía. Una cadena de dos o tres saltos de sts:AssumeRole puede conectar un sandbox con producción.

Credenciales expuestas en la configuración. Claves de acceso y tokens en los datos de usuario de EC2, en variables de entorno de Lambda, en salidas de CloudFormation y en definiciones de contenedores. Una sola clave expuesta se convierte en el punto de entrada a todo lo que alcanza el principal de esa clave.

Puntos de entrada públicos. URL de funciones, buckets públicos con acceso de escritura, instancias expuestas a internet con un perfil de instancia y API gateways que invocan un rol privilegiado. La exposición solo es grave si el rol que hay detrás lleva a alguna parte, que es exactamente lo que la validación establece.

Qué debería hacer una herramienta de AEV para AWS

Construir el grafo desde una conexión de solo lectura, de modo que no haya ningún agente que desplegar ni ningún permiso de escritura que conceder. Razonar sobre el grafo para producir cadenas candidatas, incluidas las de varios saltos y las que cruzan cuentas. Validar cada cadena evaluando cada capa de la autorización en cada paso, con el resultado registrado como evidencia. Ordenar las rutas demostradas por lo que alcanzan, para que el equipo vea primero el radio de impacto. Para cada ruta, nombrar el cambio concreto que la rompe y, cuando el cambio se despliega, volver a evaluar la ruta y confirmar que ha desaparecido. Ejecutarse de forma programada, porque las cuentas derivan.

Hay dos cosas que no necesita ser. No necesita ejecutar nada en la cuenta para producir pruebas, porque en el plano de control la prueba es el resultado de la autorización. Y no necesita ser el sistema de registro de todos los hallazgos; un CSPM o un CNAPP ya cumple esa función, y el trabajo de la herramienta de validación es decirte cuáles de esos hallazgos están en una ruta demostrada.

Cómo abordan AWS los principales proveedores de AEV

Los proveedores asociados a la categoría llegaron a ella desde puntos de partida distintos, y cada uno ha construido a partir de ahí. El resumen siguiente describe a cada uno en los términos que usan sus propios materiales públicos. Comprueba los detalles con el proveedor antes de decidir nada basándote en él.

La distinción útil es entre la prueba por emulación de técnicas y la prueba por resolución de la autorización. La emulación encaja de forma natural donde el exploit es código contra un host. La resolución de la autorización se aplica donde el exploit es un permiso, que en AWS es la mayor parte del plano de control, y como es de solo lectura puede ejecutarse a diario de forma programada.

Dónde se sitúa AEV en un programa de CTEM

La gestión continua de exposiciones a amenazas tiene cinco etapas: alcance, descubrimiento, priorización, validación y movilización. AEV es la etapa de validación. Su entrada es la lista priorizada del descubrimiento, y su salida es el pequeño conjunto de exposiciones demostradas, cada una con un responsable y un cambio. El artículo sobre la validación en CTEM recorre cómo se ve eso en una cuenta de AWS con números reales, y el artículo sobre AEV frente a BAS cubre la diferencia con las pruebas de controles.

Preguntas frecuentes