Saltearse al contenido

Abuso de IAM y escalada de privilegios

En la nube, IAM (Identity and Access Management) es el sistema que decide quién puede hacer qué. Es, de facto, el nuevo perímetro: comprometer una identidad con los permisos adecuados equivale a ser administrador. La escalada de privilegios en cloud rara vez explota un bug: encadena permisos legítimos mal asignados para pasar de una identidad limitada a control total de la cuenta. Es el corazón del pentest cloud.

Las políticas IAM son complejas y es fácil conceder de más. Ciertos permisos, aunque parezcan inocuos, permiten otorgarse a sí mismo más privilegios: crear usuarios, adjuntar políticas, asumir roles, modificar funciones que corren con roles privilegiados. El atacante que controla una identidad busca esos “permisos de escalada” y los encadena hasta admin.

# AWS: ¿quién soy y qué permisos tengo?
aws sts get-caller-identity
aws iam get-account-authorization-details # si tienes permiso
enumerate-iam --access-key ... --secret-key ... # fuerza bruta de permisos
# herramientas de mapeo de escalada
pacu # framework de explotación AWS (módulos de privesc)
cloudsplaining / PMapper # analizan políticas y rutas de escalada

Rhino Security catalogó ~20 vías. Las más comunes:

iam:CreateAccessKey -> crear clave para OTRO usuario (admin)
iam:AttachUserPolicy / PutUserPolicy -> adjuntarte AdministratorAccess
iam:CreatePolicyVersion -> reescribir una política a la que estás sujeto
iam:PassRole + ec2:RunInstances -> lanzar EC2 con un rol admin y usar su IMDS
iam:PassRole + lambda:CreateFunction -> función que corre como un rol admin
sts:AssumeRole -> asumir un rol más privilegiado (si la trust lo permite)
iam:UpdateAssumeRolePolicy -> modificar quién puede asumir un rol

Ejemplo directo: con iam:AttachUserPolicy sobre ti mismo, te adjuntas AdministratorAccess → admin.

aws iam attach-user-policy --user-name yo --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

iam:PassRole permite “pasar” un rol a un servicio (EC2, Lambda, etc.). Si puedes pasar un rol admin a una función/instancia que controlas, ejecutas código como ese rol:

# pasar un rol admin a una Lambda que tú creas -> código como admin
# o a una EC2 -> robar sus credenciales por IMDS (ver cloud-metadata)
# Azure
# roles con Microsoft.Authorization/roleAssignments/write -> asignarte Owner
# abuso de Managed Identities, Automation Accounts, consentimiento de apps
# herramientas: AzureHound, ROADtools, MicroBurst
# GCP
# iam.serviceAccounts.getAccessToken / actAs -> impersonar un SA privilegiado
# setIamPolicy -> concederte roles; abuso de Cloud Functions/Compute con SA admin
# herramientas: GCPBucketBrute, gcp_scanner, Hayat
1. Enumerar identidad y permisos (sts/az/gcloud + enumerate-iam)
2. Buscar permisos de escalada (pacu/PMapper/cloudsplaining)
3. Identificar la ruta más corta a admin
4. Ejecutar la escalada (attach policy, pass role, assume role, impersonate)
5. Confirmar privilegios y documentar impacto
  • Mínimo privilegio real: nada de *:*, revisar permisos peligrosos (iam:*, PassRole, AssumeRole amplios).
  • Analizadores de acceso: AWS IAM Access Analyzer, cloudsplaining, PMapper — detectan rutas de escalada antes que el atacante.
  • Separar roles de servicio y acotar las trust policies (quién puede AssumeRole/actAs).
  • Permission boundaries y SCPs (AWS) / condiciones (Azure/GCP) para limitar el alcance máximo.
  • Logging (CloudTrail) y alertas sobre acciones IAM sensibles (AttachPolicy, CreateAccessKey, PassRole).
  • Enumerar identidad y permisos (sts/az/gcloud + enumerate-iam)
  • Buscar permisos de escalada (pacu/PMapper/cloudsplaining)
  • AttachUserPolicy/PutUserPolicy → AdministratorAccess
  • PassRole + RunInstances/CreateFunction → rol admin
  • AssumeRole / UpdateAssumeRolePolicy
  • Azure: roleAssignments/write → Owner; Managed Identities
  • GCP: actAs/getAccessToken → impersonar SA admin
  • Confirmar privilegios y mapear la ruta