Robo de cookie de sesión: el ataque que ignora tu 2FA

En enero de 2023, CircleCI divulgó una brecha que dejó incómoda a la comunidad de seguridad por un motivo específico: el atacante no rompió ninguna contraseña, no explotó ningún zero-day y no necesitó un solo código de autenticación. Un malware instalado en el dispositivo de un empleado extrajo el token de sesión SSO protegido por 2FA y, con esa cookie en la mano, mantuvo acceso irrestricto a la infraestructura de la empresa durante semanas. El segundo factor fue completamente ignorado, no porque estuviera mal configurado, sino porque el ataque ocurrió después del inicio de sesión.

Eso es el session hijacking mediante robo de cookie. Y es, según Bleeping Computer, el objetivo principal de los infostealers modernos, más incluso que las contraseñas en sí.

Qué es una cookie de sesión

Cuando inicias sesión en cualquier servicio (Gmail, GitHub, banco digital, cuenta del trabajo), el servidor genera un identificador único llamado cookie de sesión y lo envía a tu navegador. Esa cookie funciona como una credencial temporal: en lugar de pedir tu contraseña y el 2FA en cada clic, el servidor verifica la cookie y confirma "este navegador está autenticado".

El problema es que la credencial es transferible. Si alguien copia esa cookie y la presenta al servidor desde otro dispositivo, el servidor no tiene forma de distinguir al titular original del impostor, porque, al fin y al cabo, la credencial es válida. La autenticación ya ocurrió. El 2FA ya fue aprobado. La cookie es la prueba de ello.

Cómo ocurre el robo en la práctica

Existen tres formas principales de robar cookies de sesión activas:

Infostealers que extraen cookies del disco

Navegadores como Chrome, Firefox y Edge almacenan las cookies en archivos de base de datos SQLite dentro del perfil local del usuario. Los infostealers, malwares diseñados específicamente para la recolección de credenciales, leen esos archivos directamente, descifran los valores (usando las claves del sistema operativo) y exportan todo al servidor del atacante.

Storm, un infostealer que surgió en redes de cibercrimen a principios de 2026, ofrecía exactamente esa capacidad por menos de 1.000 dólares al mes en modelo de suscripción, incluyendo extracción de cookies, credenciales guardadas y carteras de criptomonedas. No es un malware sofisticado: es barato, está disponible y es eficaz porque la mayoría de los usuarios no esperan que los archivos locales del navegador sean un vector de ataque.

Este tipo de amenaza encaja en la categoría de los malwares que difícilmente detecta el antivirus tradicional, sobre todo cuando se ejecutan rápidamente y luego se eliminan.

Extensiones maliciosas en el navegador

Una extensión instalada en el navegador tiene acceso nativo a las cookies de cualquier dominio que cubra su permiso. Extensiones maliciosas en Chrome ya han sido detectadas exfiltrando tokens de autenticación en silencio, sin ninguna interacción del usuario más allá de la instalación inicial.

La diferencia respecto al infostealer es que la extensión ni siquiera necesita descifrar nada: opera dentro del contexto del navegador, donde las cookies ya están descifradas y disponibles vía API.

XSS e interceptación en redes abiertas

El cross-site scripting (XSS) permite que un atacante inyecte código JavaScript en una página vulnerable y lea cookies que no tienen configurada la marca HttpOnly. En redes sin HTTPS, que todavía existen en algunos servicios heredados, las cookies pueden capturarse en tránsito por interceptación de red. Ambos vectores tienen mitigaciones técnicas del lado del servidor (marcas de seguridad en las cookies, HTTPS obligatorio), pero dependen de una implementación correcta por parte de los desarrolladores del servicio, no del usuario final.

¿Por qué el 2FA no protege contra el session hijacking?

El 2FA autentica el inicio de sesión, no la sesión. Una vez que el servidor emite la cookie tras un inicio de sesión exitoso con el segundo factor, esa cookie representa una sesión ya autenticada. El servidor no repite el 2FA en cada solicitud, sería inviable. Entonces, al presentar la cookie robada desde otro dispositivo, el atacante llega después de la puerta de autenticación, en un momento en que el 2FA ya cumplió (y terminó) su papel.

Esto es distinto de ataques como el MFA fatigue, que intentan engañar a la víctima para que apruebe el segundo factor. En el session hijacking, el 2FA ni siquiera se invoca: el atacante se salta esa etapa por completo.

Cómo protegerte: 6 medidas concretas

Del lado del usuario, es posible reducir bastante la superficie de ataque:

• Cierra sesión de forma explícita en servicios sensibles al terminar. El cierre de sesión invalida la cookie en el servidor: una cookie robada de una sesión cerrada deja de funcionar.
• Revisa las sesiones activas periódicamente. Google, GitHub, Microsoft y la mayoría de los servicios importantes muestran dónde está conectada tu cuenta. Cierra las sesiones desconocidas de inmediato.
• Evita extensiones innecesarias. Cada extensión instalada es una superficie de ataque. Elimina las que no uses y prefiere las publicadas por organizaciones verificadas, con historial largo y pocos permisos excesivos.
• Mantén el endpoint protegido. Un infostealer que nunca se ejecuta no roba nada. Mantener Windows con las configuraciones de seguridad correctas, el antivirus actualizado y SmartScreen activo reduce significativamente el riesgo de ejecución de malware.
• Usa HTTPS en todas partes. En 2026 esto está casi garantizado, pero todavía existen servicios heredados sin HTTPS. Si el candado no aparece en la barra de direcciones, no introduzcas credenciales ni confíes en sesiones.
• Considera las passkeys. Las passkeys FIDO2/WebAuthn eliminan las cookies de sesión vinculadas a credenciales tradicionales. La autenticación se vincula al dispositivo mediante criptografía asimétrica, y el token resultante no es exportable de la misma forma que una cookie convencional.

Lo que hizo Chrome 146 para mitigarlo

Google lanzó en Chrome 146 (Windows) el Device Bound Session Credentials (DBSC), una protección que vincula criptográficamente la cookie de sesión al dispositivo donde se creó. En la práctica, aunque un infostealer logre extraer la cookie del disco, no puede usarla en otro dispositivo: presentar la cookie exige una prueba de posesión de la clave privada que nunca sale del chip de seguridad del hardware.

El DBSC no es magia: exige soporte por parte del servidor (los servicios necesitan adoptar el protocolo), y la protección se limita a los escenarios en que la cookie se usa desde otro dispositivo. Si el atacante opera en el mismo dispositivo comprometido, el DBSC no ayuda. Pero representa un avance real contra el vector de infostealer clásico, que es precisamente el más frecuente.

La lección que queda

La seguridad de la autenticación va más allá del momento del inicio de sesión. El token que recibes después de autenticarte con contraseña, 2FA y biometría es tan valioso como la contraseña misma, y muchas veces está menos protegido. Tratar las cookies de sesión como credenciales desechables (cerrar sesión, revisar sesiones activas, mantener el dispositivo limpio) es la defensa más eficaz que tiene hoy el usuario final, mientras la industria estandariza protecciones como el DBSC.

Si quieres entender otros vectores mediante los cuales los atacantes burlan la autenticación moderna, el post sobre MFA fatigue y push bombing cubre el lado de la ingeniería social, el complemento directo de lo que vimos aquí.