Secuestro de sesión: por qué una cookie robada vale más que una contraseña
Una contraseña robada todavía tiene que superar el formulario de inicio de sesión: si la cuenta está protegida con autenticación multifactor, la puerta normalmente aguanta. Una cookie de sesión robada es otra cosa: se emite después de que el login ya ha tenido éxito, y todo lo que la cuenta hace después lo autentica únicamente la cookie. Esa asimetría explica por qué el robo de sesiones se ha convertido, sin estridencias, en la vía preferida hacia cuentas protegidas.
La mecánica es simple: al iniciar sesión, el servidor entrega al navegador una cookie de sesión y, desde ese momento, cada petición posterior se autentica solo con la cookie. La entrada de MITRE para la técnica T1539, Steal Web Session Cookie, señala que estas cookies pueden estar «en el disco, en la memoria del proceso del navegador y en el tráfico de red», y que quien tiene una puede usar la aplicación «como un usuario autenticado sin necesitar credenciales». La técnica complementaria para la reutilización, T1550.004, registra que una sesión reproducida «evita algunos protocolos de autenticación multifactor, ya que la sesión ya está autenticada» y que las cookies «suelen ser válidas durante un periodo prolongado».Por qué una cookie vale más que una contraseña
Tres propiedades hacen que la cookie valga más que la credencial que reemplazó. Ya está más allá del muro de la MFA, porque el usuario legítimo presentó el segundo factor cuando se creó la sesión. Su uso no genera ruido de inicios de sesión fallidos: el atacante llega pareciendo un navegador normal y autenticado. Y cambiar la contraseña no necesariamente termina la sesión. La detección se apoya en el comportamiento más que en la propia petición: MITRE señala la reutilización de cookies «desde user agents o ubicaciones inusuales» y «escenarios de viaje imposible y comportamiento anómalo». Los actores estatales trabajan la misma costura. MITRE recoge que APT29 robó cookies de Chrome copiando directorios de perfiles del navegador durante el compromiso de SolarWinds y que luego usó una cookie duo-sid falsificada para eludir la MFA, mientras que Star Blizzard empleó cookies de sesión recogidas mediante un proxy tipo Evilginx para llegar a buzones de las víctimas. Nada de eso exigió romper un cifrado ni vencer un factor: solo una copia de algo que el navegador ya posee.Los kits AiTM hacen de proxy del muro de login
La versión industrial es el kit adversary-in-the-middle. Una página de login falsa que solo cosecha contraseñas muere en el segundo factor. Un sitio AiTM en cambio actúa como proxy del login real: la víctima se autentica con normalidad a través del relé del atacante, el código se introduce y el kit recoge la cookie de sesión que se emite al final del flujo. Microsoft documentó una campaña así en julio de 2022, construida en torno a señuelos de documentos de Office y mensajes de voz, que según la compañía había afectado a unas 10.000 organizaciones desde septiembre de 2021 — una campaña diseñada, en palabras de Microsoft, para «robar contraseñas, secuestrar sesiones iniciadas (robar cookies de sesión) y eludir la MFA». El modelo funciona hoy por suscripción. En septiembre de 2026, BleepingComputer informó sobre BigBear 2.0, un framework de phishing-como-servicio basado en Evilginx2 que había eludido la MFA en 258 organizaciones. Un informe de CloudSEK citado allí cifraba el panel del operador en 5.137 registros de credenciales —incluidas 474 autenticaciones completas con MFA eludida, 1.032 contraseñas en texto plano y 4.148 cookies de sesión— vinculadas a 3.331 direcciones IP de víctimas únicas en más de 40 países. Las reproducciones se enrutan por proxies residenciales que coinciden con el país de cada víctima, y el JavaScript inyectado del kit interfiere con los avisos de FIDO2/WebAuthn para empujar a las víctimas hacia factores más débiles.Los stealer logs son inventarios de cookies
El conducto más silencioso es el malware infostealer, y su mercado ha girado a la vista. El informe de abril de 2026 de BleepingComputer sobre un stealer comercializado como Storm describe un panel de alquiler —300 dólares por una demo de siete días, hasta 1.800 dólares al mes para un plan de equipo— cuya pieza central no es un volcado de contraseñas sino un panel de restauración de cookies que reconstruye sesiones autenticadas en el lado del servidor:Alimenta al panel con un refresh token de Google y un proxy SOCKS5 geográficamente coincidente, y el panel restaura en silencio la sesión autenticada de la víctima.Los investigadores detrás del informe señalaron que el robo de cookies de sesión ha estado reemplazando al robo de contraseñas como objetivo principal del desarrollo de stealers. Eso replantea lo que es un registro de stealer: menos una lista de credenciales que probar que un inventario de puertas ya abiertas, cada una válida hasta que la sesión expira.
Qué reduce de verdad el riesgo
Las contramedidas no tienen ningún brillo, y esa es parte de la razón por la que se saltan con tanta frecuencia. Se corresponden con lo que Microsoft y MITRE han recomendado desde las primeras olas AiTM:- Acortar la vida de las sesiones y borrar cookies persistentes con regularidad — la mitigación de MITRE dice exactamente eso. Las sesiones de «mantener la sesión abierta» de larga duración son la materia prima de este negocio.
- Vincular las sesiones al contexto del dispositivo o de la red: las reglas de acceso condicional que exigen un dispositivo gestionado hacen fallar la reproducción de una cookie incluso cuando la cookie es auténtica.
- Vigilar la reproducción: los controles de viaje imposible y las alertas por anomalías de sesión detectan la mayoría de las reutilizaciones de cookies.
- Pasar las cuentas sensibles a autenticación resistente al phishing. Las passkeys ligadas a hardware (FIDO2/WebAuthn) están atadas al dominio al que se inicia sesión, así que un proxy AiTM no puede retransmitirlas — precisamente por eso kits como BigBear intentan suprimir esos avisos.
- Cerrar sesión. Terminar una sesión en el servidor invalida la cookie; cerrar la pestaña no.