Escalada de privilegios AWS: paths comunes

La escalada de privilegios AWS es el momento en que una identidad limitada (un usuario, un rol o una credencial robada) consigue permisos que nunca debería haber tenido. Casi nunca viene de una política “admin” obvia: se esconde en combinaciones de permisos que, encadenadas, llevan a control total de la cuenta.

Si alguna vez armaste una política IAM y la diste por segura porque “solo tiene permisos de desarrollo”, esto te va a interesar. La escalada de privilegios AWS es la técnica por la cual un principal con permisos acotados modifica políticas, adjunta permisos, pasa roles o crea cómputo que asume un rol más poderoso, hasta alcanzar acceso de administrador en uno o dos pasos. No es un bug de AWS: es el diseño de IAM usado de una forma que nadie revisó con cuidado.

¿Por qué combinaciones de permisos inocentes se vuelven peligrosas en AWS IAM?

Ponele que a un desarrollador junior le das permiso para lanzar instancias EC2 y para pasar roles a esas instancias. Las dos cosas suenan normales: necesita levantar servidores y esos servidores necesitan un rol para acceder a S3. Hasta ahí, todo bien.

El problema aparece cuando junta las dos piezas. Cada acción de IAM que deja cambiar quién puede hacer qué, o que deja ejecutar código como una identidad más privilegiada, es un ladrillo de escalada. iam:PassRole es inofensivo hasta que lo apuntás a un servicio que corre código. iam:CreatePolicyVersion está bien hasta que el principal lo dirige a una política adjunta a sí mismo.

El riesgo es contextual. Vive en la cadena, no en la línea.

¿Y por qué se les escapa a las herramientas automáticas? Porque la mayoría de los escáneres revisan permisos de a uno y los clasifican como “alto” o “bajo” riesgo de forma aislada. Un permiso para lanzar EC2 no dispara ninguna alarma. Uno para pasar un rol, tampoco. La combinación que abre la puerta al desastre pasa entre los dos sin que ningún check la marque, y ahí está justamente la gracia del ataque. Relacionado: en tus pipelines de CI/CD.

¿Cuáles son los paths comunes de escalada de privilegios en AWS?

Estos son los patrones de alta frecuencia documentados en la investigación de privilege escalation de IAM, incluido el catálogo de Rhino Security Labs. La regla práctica: si una identidad no-admin tiene cualquiera de estos, tratala como admin efectivo.

El catálogo de Rhino llegó a 21 métodos cuando lo publicaron. La lista sigue siendo la referencia que usa medio mundo para auditar cuentas, y la mayoría de las herramientas de ataque (como Pacu, el framework de explotación AWS del mismo equipo) automatizan justamente estos chequeos.

PassRole + RunInstances: cómo se escala desde permisos de desarrollador

Este es el path que más aparece en cuentas reales. Es de manual, casi aburrido, y por eso funciona tanto.

El ataque va así: el principal tiene iam:PassRole y ec2:RunInstances. Lanza una instancia EC2 y le pasa un rol con permisos de administrador (uno que ya existía en la cuenta, ponele el rol que usa otro equipo para automatización). Una vez que la instancia está corriendo, el atacante entra (o ejecuta user-data) y consulta el endpoint de metadata en 169.254.169.254. Ahí, servidas en bandeja, están las credenciales temporales del rol admin.

El escenario clásico: un pipeline de CI/CD al que le dieron permiso para crear infraestructura. Subís el código, el pipeline lanza instancias, todo funciona bárbaro, nadie revisa que el rol que el pipeline puede pasar no esté restringido, y de repente cualquiera que comprometa una credencial de ese pipeline puede lanzar una EC2 con el rol más poderoso de la cuenta y leerle las llaves.

La defensa concreta: restringir el Resource del iam:PassRole a ARNs de roles específicos y acotados, nunca a *. Si el desarrollador solo necesita pasar un rol con acceso a un bucket, que solo pueda pasar ese rol. Te puede servir nuestra cobertura de entre Jenkins o GitHub Actions.

CreatePolicyVersion y modificación de políticas: el otro camino

Acá viene lo bueno: ni siquiera necesitás cómputo. Si tenés iam:CreatePolicyVersion sobre una política que está adjunta a tu propio usuario, creás una versión nueva de esa política con "Action": "*" y "Resource": "*", la marcás como default, y listo. Pasaste de tener tres permisos a tener todos.

Conviene diferenciar dos casos. Una cosa es iam:CreatePolicy (crear políticas nuevas desde cero), que por sí solo no escala nada porque todavía necesitás adjuntarla. Otra muy distinta es CreatePolicyVersion sobre una política ya adjunta a vos: ahí la escalada es directa y en un solo paso.

El caso real más típico es el de servicios que se auto-expanden los permisos. Una función Lambda con un rol que puede modificar sus propias políticas, un pipeline de Terraform que actualiza la política que usa para correr. Empezás con un permiso acotado y, sin que nadie lo note, el servicio tiene la capacidad de reescribirse a sí mismo en admin.

¿Cómo detectar intentos de privilege escalation en tus cuentas AWS?

La detección tiene dos frentes: lo que mirás en las políticas (antes de que pase) y lo que mirás en los logs (mientras pasa o después).

• Auditoría de combinaciones peligrosas: revisá si algún principal no-admin tiene los pares de la tabla de arriba. Esto no lo hace un escáner de a una línea, necesitás análisis de cadenas.
• CloudTrail como fuente de verdad: cada acción IAM queda registrada. Las llamadas a observar son CreatePolicyVersion, AttachUserPolicy, PutUserPolicy, CreateAccessKey, UpdateAssumeRolePolicy y PassRole desde identidades que no suelen hacerlo.
• Patrones anómalos de AssumeRole: un rol que de golpe es asumido por un principal nuevo, o a una hora rara, es señal de que alguien modificó una trust policy.
• Picos de RunInstances con PassRole: una EC2 lanzada con un rol de alto privilegio desde una credencial de desarrollo es bandera roja directa.

¿Alguien revisa esto en tiempo real en la práctica? En la mayoría de las cuentas chicas, no. Por eso conviene al menos correr una auditoría periódica y poner alertas de EventBridge sobre esas llamadas concretas. Esto se conecta con lo que analizamos en en infraestructuras multirregión distribuidas.

Herramientas y métodos para auditar permisos en AWS IAM

La revisión manual sirve para entender, pero no escala. Si tenés cincuenta roles, leer cada política a ojo es inviable y además te perdés las combinaciones. Acá es donde las herramientas ayudan, con la salvedad de que ninguna es mágica.

• IAM Access Analyzer: servicio nativo de AWS que identifica recursos compartidos con entidades externas y, en su función de policy generation, ayuda a achicar permisos a lo que realmente se usó.
• IAM Policy Simulator: probás si un principal puede ejecutar una acción puntual antes de que lo intente de verdad. Bueno para validar hipótesis de escalada.
• Pacu: el framework de explotación AWS de Rhino Security Labs. Tiene módulos que enumeran automáticamente los paths de escalada conocidos en una cuenta. Úsalo en tu propio entorno, con autorización.
• Análisis contextual A + B: lo que ninguna lista de reglas plana resuelve. La pregunta que importa no es “¿este permiso es peligroso?” sino “¿este permiso más aquel otro forman una cadena?”.

El punto que se repite: el análisis que importa es el de la combinación. Una herramienta que te marca permisos sueltos como riesgosos te va a llenar de falsos positivos y, peor, te va a dejar pasar la cadena real.

Mejores prácticas para prevenir escalada de privilegios en AWS

El principio de menor privilegio se dice fácil. Aplicado a combinaciones peligrosas, se vuelve concreto:

• Restringí el Resource en PassRole: nunca iam:PassRole sobre *. Limitalo a los ARNs de roles puntuales que ese principal necesita pasar.
• Separá quién puede modificar IAM: los permisos sobre políticas (CreatePolicyVersion, AttachUserPolicy, PutUserPolicy) deberían vivir en un grupo chico y auditado, no repartidos en roles de aplicación.
• Usá Permission Boundaries: ponen un techo a lo que un principal puede llegar a tener, aunque alguien le adjunte una política más amplia.
• Auditá lo heredado: los roles viejos que nadie sabe para qué son suelen tener permisos de más. Revisalos con Access Analyzer y recortá lo que no se usó en 90 días.
• Pipelines de CI/CD con rol acotado: si tu pipeline necesita crear infra, dale un rol específico con boundary, no las llaves del reino.

Si todo esto corre sobre infraestructura propia y estás pensando dónde alojar tus servidores o tu panel de control, en donweb.com tenés hosting y cloud con soporte en español para la región.

Errores comunes al manejar permisos IAM

• Dar iam:PassRole con Resource *: es el error que habilita la mitad de las escaladas. Corrección: especificá siempre los ARNs de los roles permitidos.
• Confiar en que “es solo de desarrollo”: un permiso de desarrollo combinado con otro de desarrollo puede dar admin. Corrección: auditá las combinaciones, no los permisos sueltos.
• Asumir que el escáner cubre todo: los escáneres por reglas no ven cadenas. Corrección: sumá análisis contextual y revisión de los 21 paths conocidos.
• No mirar CloudTrail: tenés el registro de cada llamada IAM y no lo usás. Corrección: alertas sobre CreatePolicyVersion, AttachUserPolicy y PassRole anómalos.

Qué está confirmado y qué no

• Confirmado: el catálogo de Rhino Security Labs documenta 21 métodos de escalada en IAM, públicos y reproducibles. Es la referencia estándar de la industria.
• Confirmado: PassRole + RunInstances y CreatePolicyVersion funcionan exactamente como se describe; AWS los considera configuraciones del cliente, no vulnerabilidades del servicio.
• Pendiente de tu cuenta: cuántos de estos paths existen hoy en tu entorno. Eso solo lo sabés corriendo la auditoría. La lista es genérica; el riesgo es tuyo y específico.

Preguntas Frecuentes

¿Qué es privilege escalation en AWS?

Es cuando una identidad de AWS con permisos limitados consigue permisos mayores a los que debería tener, hasta llegar a control de la cuenta. Casi siempre se logra encadenando permisos que individualmente parecen seguros, como pasar un rol y lanzar una instancia que lo asume.

¿Cómo prevenir escalada de privilegios en AWS IAM?

Restringí el campo Resource en iam:PassRole a roles específicos, aplicá Permission Boundaries y separá los permisos que modifican IAM en un grupo chico y auditado. Auditá periódicamente las combinaciones de permisos, no los permisos de a uno. Complementá con ejecutando auditorías con herramientas locales.

¿Qué permisos combinados son peligrosos en AWS?

Los más peligrosos son iam:PassRole junto con ec2:RunInstances o lambda:CreateFunction, y los que modifican políticas como iam:CreatePolicyVersion, iam:AttachUserPolicy y iam:PutUserPolicy. También iam:UpdateAssumeRolePolicy combinado con sts:AssumeRole.

¿Cómo detectar intentos de escalada de privilegios?

Revisá los logs de CloudTrail buscando llamadas a CreatePolicyVersion, AttachUserPolicy, CreateAccessKey y PassRole desde identidades que no suelen hacerlas. Configurá alertas con EventBridge sobre esas acciones y vigilá patrones anómalos de AssumeRole.

¿Cuáles son los paths más comunes de escalada en AWS?

El más frecuente es PassRole + RunInstances, donde se lanza una EC2 con un rol admin y se le roban las credenciales. Le siguen CreatePolicyVersion sobre una política propia, AttachUserPolicy para auto-adjuntarse AdministratorAccess y UpdateAssumeRolePolicy para asumir un rol privilegiado.

Conclusión

La escalada de privilegios AWS no llega por una política “admin” olvidada. Llega por permisos que aprobaste sin pensar que, combinados, abrían una puerta. La defensa no es revisar cada línea: es revisar las cadenas, acotar el Resource de PassRole, separar quién toca IAM y vigilar CloudTrail.

Si gestionás una cuenta AWS, el próximo paso concreto es correr una auditoría contra los 21 paths conocidos y mirar qué principales no-admin tienen los pares peligrosos. Probablemente encuentres más de uno. Mejor que lo encuentres vos antes que otro.

Fuentes

• AWS IAM Privilege Escalation: Common Paths and How to Catch Them – artículo original (dev.to)
• Rhino Security Labs – AWS IAM Privilege Escalation Methods and Mitigation
• AWS – IAM Access Analyzer policy generation (documentación oficial)
• Pacu – framework de explotación AWS (Rhino Security Labs, GitHub)