En incidentes reales, el atacante no “rompe” el acceso: lo usa. La diferencia entre un susto y un incidente mayor suele estar en si detectas rápido el abuso de una identidad legítima (usuario, role, managed identity, service account) antes de que se convierta en persistencia, exfiltración o sabotaje.
La detección útil no es una lista de reglas sueltas. Es entender el contexto operativo (qué hace cada identidad, cuándo y desde dónde) y vigilar desviaciones con logs que ya tienes: CloudTrail, Azure Activity Logs y GCP Audit Logs. A partir de ahí, puedes subir el nivel con comportamiento, pero sin depender de herramientas complejas para conseguir resultados.
Qué suele salir mal: credenciales válidas, contexto inválido
El patrón más común en empresa es el “acceso correcto para la persona equivocada”. Un token emitido legítimamente (SSO, OAuth, STS, federación) se reutiliza desde un entorno distinto: otra red, otro país, otra automatización, o fuera de horario. La IAM policy puede ser impecable y aun así el abuso ocurre si nadie está mirando el cómo se usa la identidad.
En cloud, esto se amplifica con identidades no humanas: managed identities en Azure, service accounts en GCP, roles asumidos en AWS, cuentas de CI/CD y workloads. Una service account que normalmente lee un bucket puede empezar a enumerar IAM o a llamar APIs de KMS. El permiso puede existir “por comodidad histórica”, y la señal de abuso está en el cambio de patrón, no en un deny.
Consecuencia real: el atacante evita el ruido de malware y se mueve con APIs. Cuando el equipo detecta “algo raro”, a menudo ya hay claves rotadas, nuevos roles creados o reglas de firewall tocadas. Por eso el objetivo operativo es detectar temprano el uso fuera de contexto, no “confirmar” el compromiso cuando ya hay impacto.
Señales tempranas que sí aparecen en los logs (y que la gente ignora)
Las señales útiles suelen ser aburridas: llamadas API y metadatos. La clave está en correlacionar identidad + acción + origen + tiempo + recurso. Si solo miras “fallos de login”, te perderás el abuso porque muchas veces no hay fallo: hay éxito.
Algunas señales que en entornos corporativos se repiten una y otra vez:
- Uso anómalo de tokens o sesiones: sesiones más largas o más frecuentes de lo normal, o múltiples sesiones paralelas desde orígenes distintos para la misma identidad. En AWS lo ves con AssumeRole / GetCallerIdentity repetidos y un patrón de sessionName extraño; en Azure con inicios de sesión y operaciones desde el mismo principal con IPs que no cuadran; en GCP con auditoría de serviceAccountToken y llamadas de API encadenadas.
- Cambios bruscos en patrones de acceso: identidades que nunca listan recursos empiezan a enumerar (IAM, Storage, Key Vault/KMS/Secrets). Esto suele ser reconocimiento para preparar exfiltración o escalada, y suele ocurrir antes de “la acción grande”.
- Llamadas API fuera de contexto: acciones administrativas desde identidades de runtime (por ejemplo, una managed identity de una app que de repente hace cambios en RBAC o políticas). En empresa esto se ve cuando se “reutiliza” una identidad por rapidez y nadie documenta el scope real.
Para que estas señales no se queden en teoría, necesitas una referencia de normalidad. No hace falta un modelo ML: vale con baselines simples por identidad (top acciones, top recursos, ventanas horarias, IPs habituales). Cuando una identidad rompe su baseline, lo tratas como evento de seguridad aunque la autenticación sea válida.
Cómo hacerlo en la práctica con CloudTrail, Azure Activity Logs y GCP Audit Logs
La mayoría de organizaciones ya tienen los logs, pero mal instrumentados: sin retención suficiente, sin centralización, o sin los campos necesarios para investigar. El primer “quick win” es garantizar que los eventos de identidad y control plane están completos y llegan a un sitio consultable.
En AWS, prioriza CloudTrail para management events y registra data events donde duele (S3, Lambda) si el riesgo lo justifica. En Azure, combina Azure Activity Logs (control plane) con Sign-in logs y Audit logs de Entra ID para entender autenticación y operaciones. En GCP, habilita y centraliza Admin Activity, Data Access (cuando aplique) y los logs de IAM/Service Accounts en Cloud Audit Logs.
Un ejemplo concreto (AWS) para detectar abuso de roles asumidos es filtrar eventos donde el rol se asume desde un proveedor o contexto no habitual y, además, aparecen acciones de enumeración IAM poco después. Señales típicas en CloudTrail:
- AssumeRole / AssumeRoleWithWebIdentity con sessionName “genérico”: cuando el sessionName deja de parecerse a tu convención (pipeline, app, equipo) y se vuelve aleatorio o “admin”, suele correlacionar con uso manual o tooling externo. No es prueba, pero es una señal barata de alto valor.
- Spike de List* y Get* sobre IAM, Organizations, KMS: en investigaciones reales, el reconocimiento se ve como un “barrido” de APIs. Si esa identidad rara vez toca IAM y de repente hace ListUsers, ListRoles, GetAccountAuthorizationDetails, tienes una ventana temprana antes de que cree persistencia.
Valida que tu instrumentación es correcta haciendo una verificación operativa, no un checklist: ejecuta una acción controlada (por ejemplo, asumir un rol y listar roles) y comprueba que puedes ver en el log centralizado quién (principal/role), desde dónde (source IP / user agent), cuándo y qué (eventName + resource). Si falta alguno, la detección estará ciega cuando lo necesites.
Reglas estáticas vs detección por comportamiento: trade-offs reales
Las reglas estáticas funcionan bien para cosas muy concretas (por ejemplo, “se creó una nueva access key”, “se cambió una policy”, “se asignó Owner”). El problema es que el abuso de identidades suele moverse en la zona gris: acciones permitidas, repetidas a un ritmo distinto o sobre recursos distintos. Ahí una regla binaria se queda corta o genera demasiado ruido.
La detección por comportamiento no necesita ser sofisticada para aportar valor: basta con medir desviaciones respecto a lo normal por identidad o por tipo de workload. En empresa, esto reduce falsos positivos cuando hay muchos cambios legítimos (deploys, migraciones), porque no alertas por “cualquier ListBuckets”, sino por “ListBuckets desde una identidad que nunca lo hace y desde una ubicación anómala”.
Un error común es intentar “cubrirlo todo” desde el día uno con decenas de reglas. El resultado suele ser fatiga de alertas y abandono. Es preferible elegir 5–8 detecciones de alta señal que se puedan investigar en menos de 15 minutos con los datos disponibles (identidad, IP, user agent, recurso, correlación temporal). Si investigar cuesta horas porque faltan logs o contexto, la alerta morirá en la cola.
Errores comunes al investigar y cómo evitar perder la ventana de contención
Cuando suena una alerta de identidad, el tiempo se pierde en dos cosas: confirmar si es “normal” y decidir qué cortar sin tumbar negocio. Si tu organización no tiene convenciones (nombres de sesiones, tags de workloads, ownership de service accounts), cada investigación empieza desde cero y la ventana de contención se cierra.
Hay dos anti-patrones muy frecuentes. El primero es asumir que “si MFA está activado, estamos bien”: MFA reduce ciertos riesgos, pero no evita robo de tokens, abuso de sesiones válidas o compromise de service accounts. El segundo es tratar identidades no humanas como usuarios: una managed identity no “inicia sesión”, pero sí hace operaciones; si solo miras autenticación, no verás el abuso.
Para acelerar investigación, prepara de antemano un mínimo de contexto y de preguntas que puedas responder con logs:
- ¿Qué debería hacer esa identidad en condiciones normales? Si no existe un baseline (aunque sea manual: top 10 APIs y recursos), acabarás decidiendo por intuición. En incidentes reales, esa intuición suele fallar cuando hay despliegues o tareas fuera de horario.
- ¿Desde qué redes/ubicaciones es razonable? Una geolocalización inusual o un ASN inesperado no condenan por sí solos, pero cuando coinciden con acciones fuera de perfil son una señal fuerte. Si tu empresa usa salida a internet centralizada, la IP “cambia” menos; si usa SaaS/remote workforce, necesitarás contextualizar mejor.
- ¿Qué acción irreversible ocurrió primero? Identifica el primer cambio con impacto (policy adjuntada, rol creado, secreto leído, firewall modificado). En cloud, el atacante suele encadenar: reconocimiento → acceso a secretos → persistencia. Cortar después de persistencia es más caro.
Si al investigar descubres que no puedes responder a estas preguntas con tus logs actuales, eso no es “mala suerte”: es un gap de detección. Documenta el gap y conviértelo en mejora operativa (campos, retención, centralización, convenciones) antes de que el siguiente caso sea real.
Recomendaciones para entornos corporativos
Detectar abuso de identidades a tiempo depende menos de una herramienta concreta y más de disciplina operativa: logs completos del control plane, contexto por identidad y detecciones centradas en desviaciones. Las señales más valiosas suelen ser el uso de tokens/sesiones fuera de lo normal, cambios bruscos de patrón y llamadas API que no encajan con el rol real del principal.
Como quick wins sin complejidad excesiva, prioriza: centralizar y retener CloudTrail/Azure Activity Logs/GCP Audit Logs con los campos necesarios, crear baselines simples por identidad (acciones, horarios, orígenes), y mantener pocas detecciones de alta señal que se puedan investigar rápido. Si una alerta no se puede validar con datos disponibles en minutos, el problema no es la alerta: es la instrumentación y el contexto.
En corporativo, el objetivo práctico es ganar ventana de contención antes de que haya persistencia: identificar temprano el “contexto inválido” aunque las credenciales sean válidas, y tener suficiente trazabilidad para decidir cortar acceso con el menor impacto posible en el negocio.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.