Seguridad de IAM en AWS: errores frecuentes que llevan a escalada de privilegios

En la mayoría de los incidentes que afectan a entornos AWS, el vector no es una vulnerabilidad exótica en un servicio gestionado, sino una política de IAM demasiado permisiva. Para un CISO, esto plantea un problema incómodo: la superficie de ataque no está en el perímetro de red, sino en miles de líneas de JSON repartidas entre roles, usuarios, grupos y políticas que casi nadie revisa después de crearlas. Un permiso concedido «para salir del paso» durante un despliegue puede convertirse, meses después, en la palanca que un atacante usa para pasar de una credencial de bajo privilegio a control total de la cuenta.

La seguridad de IAM en AWS es, en la práctica, el control de acceso que sostiene todo lo demás. Si el modelo de identidades está mal diseñado, el cifrado, la segmentación de red y la monitorización pierden buena parte de su valor. Este artículo repasa los errores de configuración más habituales que habilitan escalada de privilegios y cómo auditarlos de forma sistemática.

Por qué IAM es el punto crítico de la escalada de privilegios

En AWS, escalar privilegios rara vez implica explotar un bug del hipervisor. Consiste en encadenar permisos legítimos hasta obtener capacidades que no deberían estar al alcance de la identidad comprometida. El atacante parte de una credencial (una clave de acceso filtrada en un repositorio, un token de una instancia EC2, una función Lambda comprometida) y busca acciones de IAM que le permitan reescribir las reglas del juego.

El catálogo de acciones peligrosas es conocido y está bien documentado en herramientas como Pacu o en las matrices de escalada de Rhino Security Labs. El problema no es que se desconozcan, sino que se conceden sin darse cuenta a través de políticas amplias.

Errores de configuración más frecuentes

1. Uso de comodines en Action y Resource

Políticas con "Action": "*" o, más sutilmente, "iam:*", "s3:*" combinadas con "Resource": "*" son el error más común. Un caso particularmente peligroso es conceder iam:PutUserPolicy, iam:AttachUserPolicy o iam:CreatePolicyVersion: con cualquiera de ellas, una identidad puede adjuntarse a sí misma la política AdministratorAccess. La escalada es directa y no requiere ninguna vulnerabilidad adicional.

2. Permisos de PassRole sin restricción

iam:PassRole es una de las acciones más infravaloradas. Permite entregar un rol a un servicio (EC2, Lambda, Glue, CloudFormation). Si un usuario tiene iam:PassRole con Resource: * junto a lambda:CreateFunction y lambda:InvokeFunction, puede crear una función que asuma un rol administrativo y ejecutar código con esos privilegios. La regla es clara: PassRole debe limitarse siempre a ARNs de roles concretos y acompañarse de la condición iam:PassedToService.

3. Políticas de confianza (trust policies) mal delimitadas

Los roles se asumen según su política de confianza. Un Principal demasiado abierto —por ejemplo, "AWS": "*" o una cuenta externa sin condición de sts:ExternalId— permite que cualquiera asuma el rol. En escenarios multi-cuenta y con terceros (proveedores SaaS que necesitan acceso), esta es una fuente habitual de acceso no autorizado tipo confused deputy.

4. Credenciales de larga duración y claves sin rotar

Las claves de acceso estáticas asociadas a usuarios IAM siguen siendo omnipresentes. Cuando se filtran en un repositorio, un log o una imagen de contenedor, no caducan. El uso de roles con credenciales temporales vía STS y la adopción de IAM Identity Center o la federación reducen drásticamente esta exposición. Las claves activas con más de 90 días sin rotación son una señal de alarma inmediata.

5. Escalada vía servicios de cómputo y CI/CD

Muchos roles de instancias EC2, tareas ECS o pipelines de CI/CD acumulan permisos «por comodidad». Si un atacante compromete una aplicación web sobre EC2, puede consultar el metadata endpoint (idealmente ya en IMDSv2) y recuperar las credenciales del rol asociado. Cuanto más amplio sea ese rol, mayor el alcance. Lo mismo aplica a roles de despliegue que pueden modificar infraestructura completa.

6. Confianza ciega en políticas gestionadas por AWS

Políticas como IAMFullAccess o incluso ciertas políticas de servicio con capacidades de iam:* se asignan pensando que son «estándar». En realidad, cualquier política gestionada con permisos sobre IAM es un candidato a escalada. Conviene revisarlas con el mismo escrutinio que las políticas propias.

Cómo auditar IAM de forma sistemática

Una auditoría rigurosa no se limita a leer políticas una a una: hay que analizar los permisos efectivos considerando el conjunto de políticas gestionadas, en línea, límites de permiso (permission boundaries) y SCPs de la organización.

Herramientas nativas y de terceros

• IAM Access Analyzer: identifica recursos accesibles desde fuera de la cuenta o la organización y, en su modo de generación de políticas, ayuda a construir permisos de mínimo privilegio a partir del uso real en CloudTrail.
• Access Advisor: muestra los servicios que una identidad ha utilizado realmente, útil para recortar permisos concedidos y nunca usados.
• Herramientas de análisis de rutas de escalada: Prowler, ScoutSuite, Cloudsplaining o PMapper permiten mapear relaciones entre identidades y detectar cadenas de escalada de forma automatizada.
• CloudTrail: imprescindible para correlacionar el uso efectivo de permisos y detectar actividad anómala como enumeración de políticas o intentos de AssumeRole.

Un enfoque de auditoría práctico

1. Inventaría todas las identidades: usuarios, roles, grupos y las políticas asociadas a cada uno.
2. Detecta las acciones peligrosas conocidas (iam:PutUserPolicy, iam:CreatePolicyVersion, iam:PassRole sin restricción, sts:AssumeRole con confianza amplia, etc.).
3. Evalúa los permisos efectivos, no solo los declarados, teniendo en cuenta boundaries y SCPs.
4. Contrasta el uso real (Access Advisor, CloudTrail) frente a los permisos concedidos y recorta lo no utilizado.
5. Revisa políticas de confianza y accesos entre cuentas y con terceros.
6. Repite el proceso de forma continua: IAM es un objetivo móvil que cambia con cada despliegue.

El análisis automatizado detecta lo evidente, pero las cadenas de escalada reales suelen combinar varios permisos individualmente inocuos. Ahí es donde el criterio de un pentester marca la diferencia frente a un simple escaneo.

De la auditoría al cumplimiento y a la validación ofensiva

La mayoría de marcos —CIS AWS Foundations Benchmark, ENS, ISO 27001, PCI DSS— exigen aplicar mínimo privilegio y revisar accesos periódicamente. Cumplir el checklist no equivale a estar seguro: un entorno puede pasar una auditoría de cumplimiento y, aun así, contener rutas de escalada explotables. La forma de cerrar esa brecha es validar la configuración desde la perspectiva del atacante.

En CISEC abordamos estos escenarios con un equipo certificado OSCP y metodologías como MITRE ATT&CK (matriz Cloud), PTES y las guías de CIS. Nuestro servicio de pentesting cloud en AWS no se queda en el listado de configuraciones incorrectas: reproduce las cadenas de escalada de privilegios reales que un adversario ejecutaría, priorizando por impacto explotable. Además, con nuestra plataforma de pentesting continuo AISAC podemos monitorizar la deriva de configuración de IAM entre pruebas puntuales, de modo que un permiso peligroso introducido en un despliegue no pase desapercibido durante meses.

Preguntas frecuentes

¿Cada cuánto debería auditar la configuración de IAM en AWS?

El análisis automatizado (Access Analyzer, Prowler) debería ser continuo o, como mínimo, semanal, dado que IAM cambia con cada despliegue. Una revisión ofensiva en profundidad, que valide cadenas de escalada reales, tiene sentido al menos una vez al año y tras cambios arquitectónicos relevantes como la incorporación de nuevas cuentas o integraciones con terceros.

¿Qué diferencia hay entre un escaneo de configuración y un pentest de IAM?

Un escaneo detecta configuraciones que incumplen buenas prácticas y genera muchos hallazgos, a menudo sin contexto de explotabilidad. Un pentest parte de una credencial realista e intenta escalar privilegios encadenando permisos, confirmando qué riesgos son realmente explotables y cuál es su impacto. Esto permite priorizar la remediación por riesgo real, no por volumen de alertas.

¿Es suficiente con aplicar mínimo privilegio para evitar la escalada?

Es la base, pero no basta por sí sola. El mínimo privilegio debe complementarse con permission boundaries, SCPs a nivel de organización, restricción estricta de iam:PassRole, credenciales temporales en lugar de claves estáticas y monitorización de CloudTrail. La combinación de controles preventivos y validación ofensiva periódica es lo que reduce de forma efectiva la superficie de escalada.