Escalada de privilegios en AWS IAM: cómo se forman las rutas de ataque y cómo romperlas

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

Casi todos los incidentes graves de AWS se desarrollan de la misma forma. Un atacante aterriza en una identidad con pocos privilegios, una clave de acceso filtrada, un rol de CI comprometido, una credencial de aplicación, y en unos pocos pasos es administrador. En la mayoría de estos casos no hay ningún zero-day. El atacante usa permisos que la cuenta repartió a propósito, en una combinación que nadie pretendía.

Esa combinación es una ruta de escalada de privilegios de IAM. Este artículo recorre cómo se forman esas rutas en AWS, las combinaciones de permisos que las crean, por qué se esconden de la revisión ordinaria y cómo encontrarlas y romperlas.

¿Qué es la escalada de privilegios de IAM?

La escalada de privilegios de IAM es cuando una identidad usa el acceso que ya tiene para concederse, o alcanzar, más acceso del que debía tener. En AWS esto casi siempre ocurre en el plano de control, la superficie de API que gestiona identidades y permisos, y no entrando por la fuerza en una carga de trabajo.

AWS hace exactamente lo que le dijiste. Si una identidad puede editar una política, pasar un rol o crear una clave, AWS se lo permite. La escalada suele venir de un permiso que se concedió a propósito, con un efecto de segundo orden que nadie rastreó.

Cómo se forman las rutas de escalada de privilegios

La mayoría de las rutas de escalada en AWS se agrupan en un puñado de familias. Ninguna de ellas requiere administrador. Cada una toma un permiso de escritura acotado y lo convierte en poder amplio.

Pasar un rol a un servicio que controlas

La más común es iam:PassRole combinada con un servicio de cómputo. Si una identidad puede pasar un rol privilegiado a una instancia EC2, una función Lambda, una tarea ECS o un job de Glue, y además puede lanzar ese servicio, puede ejecutar código como el rol privilegiado y heredar sus permisos. La identidad tomó prestado un rol que tenía los permisos que a ella le faltaban. Por eso iam:PassRole es el permiso que hay que vigilar más de cerca, y por eso siempre debería estar acotado por qué roles se pueden pasar y a qué servicio.

Reescribir una política que tienes permiso de editar

Si una identidad tiene iam:CreatePolicyVersion, puede publicar una nueva versión de una política gestionada por el cliente con los permisos que quiera, y después establecer esa versión como predeterminada. Una política que concedía acceso de lectura a un bucket se convierte en una política que lo concede todo. La misma idea aplica a iam:PutUserPolicy, iam:PutRolePolicy e iam:PutGroupPolicy para políticas inline. El permiso se lee como un mantenimiento rutinario de política, y puede reescribir todo lo que esa política concede.

Adjuntar una política más potente

Permisos como iam:AttachUserPolicy, iam:AttachRolePolicy e iam:AttachGroupPolicy permiten a una identidad adjuntar una política gestionada existente a sí misma o a un principal que controla. Adjunta AdministratorAccess y el ascenso termina en una sola llamada. Esto funciona porque el permiso estaba acotado de forma demasiado amplia.

Crear credenciales nuevas para una identidad más potente

Varios permisos permiten a una identidad crear credenciales nuevas para un principal que ya tiene más privilegio. iam:CreateAccessKey sobre otro usuario emite para ese usuario una clave nueva. iam:CreateLoginProfile establece una contraseña de consola para un usuario que no la tiene. iam:UpdateLoginProfile restablece una. En cada caso el atacante gana una identidad más potente con la que autenticarse, en lugar de añadir permisos a la que ya tiene.

Relajar una política de confianza

La política de confianza de un rol decide quién puede asumirlo. Si una identidad tiene iam:UpdateAssumeRolePolicy sobre un rol privilegiado, puede reescribir esa política de confianza para permitirse a sí misma, luego llamar a sts:AssumeRole y convertirse en el rol. El riesgo relacionado es un rol que ya confía de forma demasiado amplia, un principal comodín o una cuenta entera, de modo que asumirlo nunca requirió editar nada en absoluto.

Por qué los permisos aislados esconden la ruta

Mira cualquiera de esos permisos en una revisión de políticas y se lee como razonable. Una identidad de despliegue necesita iam:PassRole. Un equipo de plataforma necesita gestionar políticas. Un usuario de automatización necesita rotar claves. Cada concesión tiene una buena historia.

La escalada solo aparece cuando conectas la concesión con lo que puede alcanzar. iam:PassRole es inofensivo hasta que preguntas qué roles puede pasar y si la identidad también puede lanzar el servicio que los ejecutaría. La edición de una política gestionada está bien hasta que notas que la política está adjunta a un rol de administrador. La ruta solo se muestra cuando miras todo el grafo, y una revisión que toma una política cada vez nunca lo hace. Por eso una revisión puede devolver cientos de hallazgos y aun así pasar por alto la cadena que llega a administrador.

Herramientas que lo mapean

No tienes que razonar sobre esto a mano. AWS IAM Access Analyzer informa del acceso externo y sin usar y puede validar políticas. Las herramientas open-source modelan las relaciones: PMapper construye un grafo de quién puede alcanzar a quién, Cloudsplaining marca las políticas con permisos propensos a la escalada y los frameworks ofensivos como Pacu enumeran métodos de escalada conocidos. Son valiosas, y mapean candidatos, los movimientos que podrían funcionar.

La mayoría de las herramientas se quedan cortas de la prueba. Saber que una identidad tiene iam:PassRole no es lo mismo que saber que, dadas todas las políticas, los límites y las service control policies en vigor, esa identidad puede llegar hoy a un administrador. Comprobar eso es lo que convierte un candidato en una ruta validada.

Cómo los defensores rompen estas rutas

La buena noticia sobre las cadenas es que solo tienes que cortar un enlace. Unos pocos movimientos duraderos cierran la mayoría de las rutas de escalada:

Acota iam:PassRole para que una identidad solo pueda pasar roles específicos, y añade una condición iam:PassedToService para que un rol pensado para Lambda no pueda pasarse a EC2. Trata las acciones de escritura de iam:, especialmente las ediciones de políticas, las adjuntaciones y la creación de credenciales, como de alto privilegio y concédelas de forma acotada. Pon un permissions boundary en las identidades que deban tener permisos de escritura de IAM para que no puedan superar un techo. Usa service control policies para limitar el privilegio efectivo en toda la organización, de modo que ni siquiera una cuenta mal configurada pueda llegar a administrador. Endurece las políticas de confianza de los roles para que nombren principales exactos, nunca una cuenta sin más ni un comodín. Después monitorea CloudTrail en busca de las llamadas reveladoras: CreatePolicyVersion, AttachRolePolicy, UpdateAssumeRolePolicy, CreateAccessKey en una identidad que normalmente no las hace.

La parte difícil es saber qué rutas quedan después de que interactúen todos tus controles, y mantener esa respuesta al día a medida que las políticas cambian cada día.

Cómo lo aborda Pathbreak

Pathbreak trata IAM como lo hace un atacante, como un grafo de alcanzabilidad y no como una lista de políticas. Razona sobre tus identidades, roles, políticas, límites y relaciones de confianza reales, y después resuelve la autorización para confirmar qué identidades pueden escalar a administrador o alcanzar datos sensibles. Lo hace en modo de solo lectura. Nada se ejecuta contra tu cuenta, y nada se modifica.

Cuando una ruta se resuelve, Pathbreak muestra la cadena completa y te entrega el único cambio que la rompe, la concesión de PassRole a eliminar, la política a endurecer, la relación de confianza a cerrar. Corriges ese enlace en lugar de clasificar mil hallazgos sin priorizar. Puedes ver la mecánica en la página de cómo funciona, las cadenas que cubrimos en la página de rutas de ataque y cómo gestionamos el acceso en la página de Confianza y Seguridad.

Preguntas frecuentes