El patrón se repite en incidentes modernos: el administrador “hizo todo bien”, tiene MFA, y aun así el atacante termina dentro de la consola cloud con permisos altos. No es magia ni un “bypass” clásico de MFA: es reutilización de sesión. Si el adversario consigue la cookie/token de sesión después de que el usuario haya completado el MFA, la consola acepta esa sesión como válida y el atacante opera como si fuese el usuario.
En consolas de Cloud, el impacto no suele ser ruidoso al principio. Se ve como actividad legítima: mismo usuario, mismas APIs, a veces incluso mismo navegador/OS si el atacante replica cabeceras. La diferencia es que el control que esperabas (MFA) ya se consumió en el momento de crear la sesión; lo que hay que proteger es la sesión en sí y el contexto bajo el que se permite usarla.
Qué salió mal: el MFA protegía el login, no la sesión
En un AitM, el atacante se coloca entre el usuario y el IdP/SSO o la propia consola (por ejemplo, mediante un proxy malicioso detrás de un dominio parecido, un enlace de “verificación” en un flujo de urgencia, o una cadena de redirecciones creíble). El usuario introduce credenciales y completa MFA en un entorno que parece legítimo. El AitM no necesita romper MFA: solo necesita capturar lo que el navegador recibe tras autenticarse (cookies de sesión, tokens, headers o artefactos equivalentes) y reutilizarlo.
En empresa esto se vuelve crítico porque la consola es un plano de control: desde ahí se crean credenciales, se cambian políticas IAM, se tocan claves KMS, se abren reglas de red o se despliegan workloads. Una vez dentro, el atacante suele priorizar persistencia y capacidad de volver: crear un nuevo principal/rol, registrar un factor de recuperación, o habilitar un canal de acceso alternativo. Todo eso ocurre “después” del MFA, usando una sesión ya autorizada.
La consecuencia operativa más dura es cultural: muchos equipos interpretan “MFA habilitado” como cierre del riesgo. En AitM, MFA se vuelve un requisito necesario pero insuficiente. El control real es condicionar el uso de la sesión a señales difíciles de clonar (dispositivo gestionado, red corporativa, cumplimiento, ubicación, risk score) y reducir al mínimo el valor temporal de la cookie.
Cómo se ve en la consola: patrones de sesión y señales que suelen pasar desapercibidas
Un AitM bien ejecutado no dispara alertas obvias. Los logs reflejan un inicio de sesión correcto, con MFA válido, y una secuencia de acciones coherente. Por eso muchas detecciones basadas solo en “failed MFA” o “impossible travel” llegan tarde o son ignoradas por falsos positivos.
Lo que sí suele delatar el abuso es el contexto: cambios de IP/red, user-agent anómalo, accesos a la consola desde ubicaciones no habituales, o acciones administrativas sin el patrón normal del equipo (por ejemplo, un administrador que normalmente solo gestiona identidades y de pronto toca redes, claves o exporta datos). En organizaciones con varios admins, este “ruido semántico” es más útil que buscar una firma técnica específica.
- Sesión válida con salto de contexto: el usuario se autenticó desde un endpoint corporativo, pero la actividad administrativa intensa aparece desde IP residencial/VPN pública. Ese salto suele ocurrir minutos después del MFA, cuando el atacante ya tiene la cookie.
En operaciones reales, este patrón se detecta comparando “ubicación/red” del login frente a “ubicación/red” de las llamadas posteriores de consola/API, no solo mirando el evento de autenticación. Cuando no existe esa correlación (o nadie la revisa), el incidente se descubre por síntomas secundarios: recursos creados, reglas abiertas, facturación anómala o integridad de logging afectada.
- Acciones de persistencia que imitan tareas legítimas: creación de un rol “temporal”, cambio de un policy adjunto “por mantenimiento”, o ajuste de una regla de firewall “para troubleshooting”.
El problema en corporativo es que esas acciones son plausibles: ocurren en ventanas de incidentes, migraciones o despliegues. Un atacante lo sabe y se apoya en esa plausibilidad. Por eso la defensa debe ser preventiva: aunque la cookie sea válida, el contexto no debe permitir operar fuera de guardrails.
La superficie de ataque: dónde se roba una cookie de sesión en entornos corporativos
No hace falta malware sofisticado para que exista AitM; el factor humano y el flujo de autenticación son el terreno. Las consolas cloud suelen depender de SSO/IdP, y ese es el punto de alto valor: si el atacante captura el resultado del login (la sesión), hereda todo lo que el IdP concedió.
En empresas, el disparador típico es la urgencia: “revísame este dashboard”, “tenemos un P1”, “hay que aprobar un cambio”. El usuario abre una URL, completa MFA y sigue su día. Si el proxy AitM está bien montado, incluso puede pasar el login al sitio real y el usuario no percibe fricción. La cookie obtenida tiene una ventana de explotación que suele ser suficiente para hacer daño y dejar acceso preparado para más tarde.
Un anti-patrón frecuente es operar administración de cloud desde dispositivos no gestionados o desde navegadores personales “porque es más rápido”. En AitM esto amplifica el riesgo: no hay posture de dispositivo para cortar la sesión, no hay controles de red, y es más difícil correlacionar telemetría. Aunque el IdP tenga MFA fuerte, el punto débil es el navegador como contenedor de sesión.
Cómo hacerlo en la práctica: acceso condicional y validación de red para que la cookie robada no sirva
La mitigación efectiva no es “más MFA”, sino exigir contexto. La idea operativa es simple: incluso si un atacante clona la cookie, que al usarla falle por no cumplir condiciones que el atacante no puede replicar de forma consistente (dispositivo compliant, red corporativa, sesión de navegador endurecida, restricción de ubicación/ASN, risk-based policies).
En un entorno corporativo, esto se implementa en dos planos: en el IdP/SSO (acceso condicional para consola cloud) y en el propio proveedor cloud (controles de red/condiciones sobre la administración cuando existan). El objetivo es que la sesión sea “no portable”. Si hoy un admin puede abrir la consola desde cualquier red y cualquier equipo, el atacante también.
- Crear una política de acceso condicional para “Consola Cloud / AWS/Azure/GCP Console” que exija dispositivo gestionado (MDM/EDR + compliance) y bloquee acceso desde navegadores no corporativos.
Esto fuerza a que la sesión se emita y se use solo en endpoints que reportan postura. En AitM, el atacante puede tener la cookie, pero no puede “convertir” su equipo en compliant sin levantar señales fuertes. En la práctica, reduce drásticamente el éxito del replay de sesión.
- Restringir por red: permitir consola solo desde rangos corporativos/VPN de empresa o desde un proxy de acceso (ZTA) con identidad, y bloquear el resto.
La validación de red es especialmente efectiva contra atacantes oportunistas y contra replay desde infra pública. En incidentes reales, el atacante suele operar desde hosting/VPN comercial. Si la sesión solo es válida desde tu egress corporativo, la cookie pierde valor fuera.
- Reducir duración de sesión y forzar reautenticación frecuente en flujos administrativos, priorizando tareas de alto impacto.
Esto no “evita” el robo, pero acorta la ventana de abuso. Si además combinas reautenticación con verificación de contexto (step-up condicionado), obligas a que cada acción sensible ocurra bajo controles actuales, no bajo una sesión antigua.
Validación operativa: no basta con “configurar” y asumir. Hay que probar con un dispositivo no gestionado y con una IP fuera de corporativo para verificar que la consola queda bloqueada o que el IdP no emite sesión. También conviene validar el caso inverso: desde un endpoint corporativo compliant, que el acceso funcione sin empujar a atajos (si la fricción es alta, los equipos buscarán excepciones).
Recomendaciones para entornos corporativos
El robo de cookies de sesión (AitM) en consolas de Cloud funciona porque el MFA se aplica en el momento del login, pero la sesión resultante se puede reutilizar. En ese escenario, el atacante no “rompe” MFA: opera con una sesión ya autorizada. La defensa real consiste en hacer que esa sesión dependa de contexto difícil de clonar.
Para reducir el riesgo de forma práctica, el foco debe estar en acceso condicional (dispositivo gestionado y compliant, bloqueo de navegadores no corporativos), validación de red (permitir administración solo desde egress controlado) y ventanas de sesión ajustadas para tareas administrativas. Si estas medidas se prueban activamente (desde redes/hosts no permitidos) y se evitan excepciones por comodidad, una cookie robada deja de ser una llave maestra para la consola.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.