En 2026, el robo de identidades en AWS se ha convertido en el camino preferido para comprometer entornos cloud. La razón es simple desde el punto de vista del atacante: es más barato y más fiable robar o abusar de credenciales, tokens y relaciones de confianza que buscar un exploit “clásico” contra un servicio expuesto.
Los datos recientes de 2026 apuntan a un patrón claro: un 83% de los ataques iniciales a la nube aprovechan problemas de identidad (credenciales filtradas, sesiones STS, trust policies permisivas, OAuth/SAML mal gobernado) en lugar de vulnerabilidades técnicas tradicionales. No es que hayan desaparecido los exploits; es que la identidad se ha convertido en la autopista más directa hacia permisos reales.
Qué salió mal: cuando el acceso “válido” se vuelve el vector de intrusión
La mayoría de incidentes de identidad en AWS no empiezan con un “0-day”. Empiezan con algo que en logs parece legítimo: una sesión de AWS STS emitida, una llamada a AssumeRole, un inicio de sesión por SSO, una clave de acceso usada desde un entorno nuevo. La trampa es que el atacante no necesita romper AWS; necesita convencer a tu control de identidad para que le entregue una sesión válida.
En empresas grandes, esto se agrava por la presión de entrega: equipos que automatizan con IAM users porque “es más rápido”, integraciones con terceros que piden roles con comodines, o cuentas heredadas donde nadie se atreve a tocar trust relationships por miedo a parar producción. Resultado: el intruso entra con apariencia de usuario interno, y el SOC pierde tiempo descartando un falso positivo.
Consecuencia real típica: el atacante no “escanea” ni explota; enumera con permisos. Empieza por sts:GetCallerIdentity, pasa a listar roles/policies, busca caminos de escalada (permisos de IAM o roles con confianza amplia) y se mueve lateralmente entre cuentas si hay una organización mal segmentada.
Por qué el 83% se explica mejor por economía y fricción operativa que por “magia” atacante
En 2026, el mercado de credenciales, tokens y accesos intermediados está demasiado maduro como para ignorarlo. Un exploit requiere investigación, compatibilidad y, a menudo, exposición pública. En cambio, el robo de identidad “compra” acceso directo a las APIs, con el mismo canal que usa tu automatización. Además, muchas empresas han endurecido perímetros y parches, pero siguen arrastrando deuda en IAM: permisos excesivos, relaciones de confianza amplias, y poca visibilidad sobre qué identidades usan realmente los workloads.
El 83% encaja con lo que se ve en terreno: el primer acceso se obtiene con material de identidad (credenciales, tokens, sesiones) o con abuso de la cadena de confianza (IdP → SSO → roles; CI/CD → OIDC → roles; cross-account trust). No es un cambio de “moda”; es un cambio de incentivo. Si tu operación está diseñada para que la identidad sea flexible, el atacante explotará esa flexibilidad.
Un anti-patrón muy común en corporaciones es confundir “tener MFA en consola” con “estar protegido”. El atacante rara vez necesita tu consola; le basta con API access y permisos. Cuando el foco de seguridad está centrado en el login humano y no en la emisión/uso de sesiones STS, se deja abierta la puerta más rentable.
Señales tempranas en AWS que delatan robo o abuso de identidad
La detección efectiva en AWS no consiste en buscar “malware” dentro de AWS, sino en vigilar comportamientos de identidad y permisos. En incidentes reales, las señales tempranas suelen ser sutiles: cambios de patrón geográfico, nuevos agentes de usuario (SDKs), llamadas a APIs de enumeración, o picos en AssumeRole. Lo peligroso es que, si el atacante roba una sesión STS de corta duración, el evento se parece demasiado a un job de automatización legítimo.
En CloudTrail (y si aplica, en CloudTrail Lake), conviene buscar secuencias: primero GetCallerIdentity, luego ListRoles/ListPolicies, después acciones de IAM (adjuntar policies, actualizar trust), y finalmente acceso a datos (S3, Secrets Manager, Parameter Store) o a cómputo (ECS/EKS/Lambda) para persistencia. En empresas, esto aparece a menudo fuera de horario o desde un origen de red que no coincide con los runners de CI/CD.
- Uso anómalo de
AssumeRoley cambios de rol en cadena
Una cadena de asunciones (role chaining) fuera de lo habitual suele indicar exploración o movimiento lateral. Si no tienes modelado qué roles asume cada pipeline y cada equipo, separar “legítimo” de “intruso” se vuelve reactivo.
- Acciones de IAM raras en identidades no operativas
Cuando un rol de aplicación (por ejemplo, un rol de Lambda) ejecuta iam:PassRole o modifica policies, normalmente es un diseño defectuoso o una intrusión. En corporaciones, la raíz suele estar en permisos “temporales” que se quedaron para siempre por una urgencia.
- Lecturas masivas de secretos o parámetros
El atacante que entra por identidad busca credenciales secundarias: claves API de terceros, tokens internos, cadenas de conexión. Un pico de secretsmanager:GetSecretValue o ssm:GetParameter desde un principal no habitual es una señal fuerte, especialmente si coincide con nuevas sesiones STS.
Cómo hacerlo en la práctica: hardening de IAM/STS para que robar identidad no baste
El objetivo operativo no es “evitar que roben credenciales” (eso es aspiracional), sino reducir el blast radius cuando ocurre y dificultar el abuso. En AWS, eso se concreta en limitar quién puede asumir qué rol, desde dónde, con qué condiciones, durante cuánto tiempo, y con qué permisos efectivos. En entornos corporativos, el punto de fallo suele ser la trust policy demasiado abierta o el uso de identidades humanas/estáticas donde debería haber federación y credenciales efímeras.
Una medida con impacto inmediato es endurecer las trust policies con condiciones verificables. Por ejemplo, en integraciones con OIDC (CI/CD), evita trust genéricas y ata el rol a claims específicos (repo, branch, audience). En cross-account, evita confiar en el root de otra cuenta y exige ExternalId cuando un tercero asume tu rol.
Ejemplo de trust policy (cross-account) con ExternalId y restricción de principal:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:role/ThirdPartyIntegratorRole" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "CORP-UNIQUE-EXT-ID" }
}
}
]
}
Ejemplo de trust policy (OIDC) amarrada a claims (la idea es restringir “quién” y “desde qué contexto”):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:org/proyecto:ref:refs/heads/main"
}
}
}
]
}
La parte que se suele olvidar es la validación. En AWS, valida que el rol no es asumible “por accidente” revisando: relaciones de confianza (IAM → Roles → Trust relationships), eventos de AssumeRole en CloudTrail, y el permiso efectivo con IAM Access Analyzer (hallazgos de acceso externo) para detectar roles/policies que permiten acceso desde fuera de tu organización.
- Configurar límites de sesión y rotación de patrón
Reduce el tiempo de sesión cuando tenga sentido operacional (especialmente en roles sensibles) y fuerza el uso de sesiones efímeras frente a claves largas. En incidentes reales, recortar ventanas de sesión reduce el tiempo útil de un token robado y obliga al atacante a reautenticarse, donde ya puedes bloquearlo.
- Eliminar IAM users en automatización y migrar a roles con identidad federada
La deuda más cara es el IAM user “temporal” para un script o un proveedor. Sustituirlo por roles asumibles (OIDC/SAML/SSO) cambia el juego: reduces exposición de secretos estáticos y mejoras trazabilidad. En empresa, esto suele requerir coordinación con DevOps, pero baja drásticamente el riesgo de filtración en repositorios, tickets o herramientas de CI.
Recomendaciones para entornos corporativos
Si en 2026 el robo de identidades es la principal amenaza en AWS, la respuesta práctica pasa por tratar IAM/STS como superficie de ataque prioritaria. El dato del 83% se entiende porque la identidad entrega acceso real sin necesidad de explotar vulnerabilidades: por eso los controles deben centrarse en sesiones, confianza y permisos efectivos, no solo en endurecer hosts o perímetros.
En operación corporativa, lo que mejor funciona es combinar señales (CloudTrail orientado a AssumeRole, acciones IAM y accesos a secretos) con hardening pragmático: trust policies restrictivas (claims/ExternalId), reducción de permisos y eliminación progresiva de credenciales estáticas. Así, incluso si una identidad se ve comprometida, el atacante se queda sin rutas fáciles de escalada y movimiento lateral.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.