← Todos los artículos Referencia

El AWS Privilege Escalation Map

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

Ideas clave

Creamos una referencia de los permisos de AWS que un atacante puede encadenar hacia administrador, datos o persistencia, con una página para cada uno.
Cada entrada incluye las mismas cuatro cosas: cómo se usa el permiso, los eventos de CloudTrail que lo atrapan, la técnica de MITRE ATT&CK y el control que eliminaría la ruta.
Más de la mitad de las entradas de escalada de privilegios pasa por iam:PassRole. Es el único permiso que toca la mayor cantidad de servicios.
Algunos permisos escalan por sí solos. Muchos solo escalan en una combinación, en poder conjunto con otros. Esas combinaciones tóxicas son las que se le escapan a una revisión que mira una política cada vez.
Saber que un permiso es peligroso no es lo mismo que saber que es peligroso en tu cuenta. Eso exige validarlo contra tu autorización real, y una decisión con contexto de negocio sobre si el permiso es imprescindible.

Pregunta a diez ingenieros de AWS qué permisos son peligrosos y obtendrás diez listas cortas. Todos nombran iam:PassRole. La mayoría nombra las ediciones de políticas. A partir de ahí se vuelve impreciso, porque la respuesta real es larga, cambia a medida que AWS lanza nuevos servicios y la mayor parte del peligro está en las combinaciones y no en acciones aisladas.

Así que lo pusimos por escrito. El AWS Privilege Escalation Map es una página por cada permiso que un atacante puede encadenar hacia el acceso de administrador, los datos o una forma de volver a entrar. Puedes buscar por servicio, por técnica o por una combinación de permisos, y cada entrada se lee de la misma manera.

Qué hay en cada página

Cada entrada responde a cuatro preguntas. Cómo se usa el permiso, por sí solo o únicamente junto a otros. Cómo lo ves, como los eventos de CloudTrail que registran la llamada. Dónde encaja en el manual del atacante, como la técnica de MITRE ATT&CK. Y qué eliminaría la ruta, como el control que un defensor podría aplicar. La página dibuja el movimiento como una cadena, desde el principal atacante hasta lo que alcanza el permiso, con la acción real de la API en cada paso.

Una combinación tóxica del mapa. Con lambda:CreateFunction e iam:PassRole en poder conjunto, un principal crea una función, le entrega un rol con privilegios y la función se ejecuta como ese rol. Ninguno de los dos permisos resulta alarmante por separado.

Una ruta, paso a paso

Toma el movimiento de arriba, en el que se apoyan más de la mitad de las entradas de escalada de privilegios. Leídas como dos declaraciones de política separadas, ninguna parece peligrosa. Encadenadas, ejecutan el código del atacante como un rol que al principal nunca se le concedió.

Paso 1. Empieza como un principal corriente. Basta con un rol de desarrollador o de CI que tenga lambda:CreateFunction e iam:PassRole. Aquí todavía nada es administrador.
Paso 2. Crea una función con código del atacante (lambda:CreateFunction). El cuerpo de la función es lo que el atacante quiera ejecutar.
Paso 3. Pásale un rol con privilegios (iam:PassRole). Apunta la función a un rol con más acceso del que tiene el principal, por ejemplo uno que pueda leer todos los buckets o adjuntar políticas.
Paso 4. Invócala y el código se ejecuta como ese rol. El principal ha tomado prestado un acceso que nunca se le concedió, y en eso consiste toda la escalada.
Paso 5. El corte: limita iam:PassRole a ARN de roles concretos y fija iam:PassedToService. Ese único cambio cierra esta ruta y buena parte del resto del mapa, porque cada servicio que ejecuta código por ti acepta un rol entregado de la misma manera.

Eso es una sola entrada. El mapa dibuja la misma cadena para cada permiso que cubre, de modo que puedes ver el movimiento antes de decidir si el permiso es imprescindible en tu propia cuenta.

iam:PassRole es el hilo común

De las entradas de escalada de privilegios del mapa, más de la mitad se apoya en iam:PassRole. Aparece en rutas que alcanzan dos docenas de servicios distintos, porque cada servicio que ejecuta código por ti aceptará un rol que le entregues. Lambda, EC2, ECS, Glue, SageMaker, CodeBuild, Step Functions y los demás toman un rol entregado y se ejecutan como él. Por eso una sola concesión de iam:PassRole sobre un recurso comodín vale más para un atacante que casi cualquier otro permiso. Limítalo a ARN de roles concretos y fija iam:PassedToService, y buena parte del mapa se cierra de golpe.

Permisos aislados y combinaciones tóxicas

Algunos permisos escalan por sí solos. iam:AttachUserPolicy con un recurso lo bastante amplio escala por sí solo. Pero muchas de las rutas más peligrosas necesitan dos o más permisos en poder conjunto, y ninguno parece alarmante por separado. iam:PassRole es inofensivo sin una acción de servicio que lo use. lambda:CreateFunction es inofensivo sin un rol que entregar. Ten ambos y tendrás código arbitrario ejecutándose como un rol con privilegios.

Estas combinaciones tóxicas son las que se cuelan en las revisiones, porque una auditoría de políticas que mira una declaración cada vez nunca ve el par. El mapa etiqueta cada entrada como directamente explotable o como combinación tóxica, y puedes filtrar solo por las combinaciones.

Por qué una lista de permisos no es toda la historia

Una referencia como esta te dice qué permisos pueden ser peligrosos. No puede decirte cuáles son peligrosos en tu cuenta. Eso depende de quién tiene realmente el permiso, de si las políticas de confianza y las condiciones encajan, de si una SCP ya lo bloquea y de si el rol que alcanza tiene privilegios. El mismo permiso puede ser imprescindible en una cuenta y puro riesgo en otra.

Por eso el mapa es deliberadamente prudente con la solución. Cada página muestra el control que eliminaría la ruta, y luego dice con claridad que aplicarlo o no es una decisión de negocio, no un cambio automático. Retirar un permiso del que depende un pipeline es su propia clase de caída.

Cómo usarlo

Empieza por un servicio que uses y lee sus entradas. Busca un permiso que estés a punto de conceder y mira qué abre. Escribe dos permisos para comprobar si juntos forman una ruta. Cada página enlaza los eventos de detección sobre los que puedes alertar hoy y la técnica de MITRE para tu propio mapeo, de modo que el mapa resulta útil tanto si estás reforzando, detectando o modelando amenazas.

Cómo lo usa Pathbreak

El mapa es la versión pública de lo que Pathbreak razona dentro de tu cuenta. Nos conectamos en solo lectura, resolvemos tus políticas de IAM, roles y relaciones de confianza reales, y confirmamos cuáles de estas rutas existen de verdad para tus identidades. Después las clasificamos según cuánto abre cada una y, con tu modelo de amenazas y tu contexto de negocio, mostramos qué pocos cambios cortan más. Las primeras rutas validadas llegan en menos de una hora.

Preguntas frecuentes

¿Cuál es el permiso de AWS IAM más peligroso?

iam:PassRole es el permiso más reutilizado en las rutas de escalada de privilegios. Concedido sobre un recurso comodín, permite que un principal entregue un rol con privilegios a un servicio que puede ejecutar, como Lambda o EC2, y herede ese rol. Es peligroso en combinación con una acción de servicio más que por sí solo, lo que explica en parte por qué tantas veces se deja demasiado amplio. El AWS Privilege Escalation Map de Pathbreak muestra cada combinación que lo convierte en una ruta.

¿Qué es una combinación tóxica de permisos?

Es un conjunto de dos o más permisos que son seguros por separado pero conceden escalada cuando un mismo principal los tiene juntos. iam:PassRole más lambda:CreateFunction es un ejemplo clásico. Las revisiones que comprueban una declaración de política cada vez no los detectan, porque el riesgo está en el emparejamiento, no en ninguno de los permisos por separado. El mapa de Pathbreak las etiqueta como combinaciones tóxicas.

¿Cómo sé cuáles de estos permisos son realmente peligrosos en mi cuenta?

Los validas contra tu autorización real. Un permiso solo forma una ruta si un principal lo tiene de verdad, las políticas de confianza y las condiciones lo permiten, ninguna barrera lo bloquea y el rol que alcanza tiene privilegios. Pathbreak lo resuelve en solo lectura e informa únicamente de las rutas que se resuelven, en lugar de cada permiso que en teoría podría ser arriesgado.

¿Debería eliminar sin más todos los permisos del mapa?

No. Muchos de estos permisos hacen un trabajo legítimo. El mapa muestra el control que eliminaría cada ruta, pero aplicarlo o no es una decisión de negocio. El enfoque correcto es validar qué rutas existen, clasificarlas según cuánto abren y cortar las pocas que más importan sin romper lo que depende de ellas. Pathbreak valida cuáles de ellos forman una ruta real en tus cuentas, para que corrijas esos primero.

¿El mapa cubre algo más que la escalada de privilegios?

Sí. Junto a la escalada de privilegios cubre el acceso a credenciales, la evasión de defensas frente a tu propio registro y tus barreras, la exposición de recursos a principals externos o públicos, el acceso a datos y la persistencia, porque las rutas de ataque reales cruzan esas categorías de camino al impacto. Pathbreak mantiene el mapa y valida las mismas técnicas en su plataforma.