Resumen: reenvio de token de sesion tras autenticacion entre dispositivos
- La brecha: Cada presentacion trata MFA como linea de meta. El robo de cookies desmonta el farol. MFA autentica el evento de login, y una cookie de sesion robada es el recibo que prueba que el login ya ocurrio, asi que el servidor entrega la cuenta sin volver a preguntar.
- La evidencia: SpyCloud recupero mas de 17.000 millones de registros de credenciales robadas del bajo mundo criminal en 2024, y DBSC solo cubre Chrome 146+ en Windows. cside huellas dispositivos con mas de 250 señales al 99,7% de precision para atrapar el momento en que una cookie se reenvia desde la maquina equivocada.
- La decisión: Cualquier equipo que confie en MFA mas HttpOnly para proteger sesiones vivas esta expuesto. Añade este trimestre monitorizacion runtime de scripts para exfiltracion de tokens y scoring conductual a nivel de dispositivo, antes de que una venta de infostealer en Telegram sea tu incidente.
¿Poco tiempo? Consulta la detección de robo de cuentas de cside. Cubre todo lo de abajo en un solo despliegue.
El robo de cookies ocurre cuando un atacante captura el token de sesión que un sitio web emitió tras el inicio de sesión de un usuario y lo reproduce desde un dispositivo diferente. El atacante hereda el acceso del usuario sin conocer su contraseña. No se activa ningún aviso de MFA. El usuario permanece conectado y no nota nada; ambas sesiones se ejecutan en paralelo.
La razón por la que el MFA no detiene esto es estructural. El MFA autentica al usuario en el evento de inicio de sesión. Después del inicio de sesión, el servidor depende de la cookie de sesión, una credencial de tiempo limitado que prueba que el navegador ya pasó la autenticación. Una cookie robada es prueba de que el navegador ya la superó. El servidor no puede distinguir al usuario real del atacante a menos que verifique algo más allá del propio token.
Los investigadores de seguridad llaman a esto un ataque pass-the-cookie. Es la técnica dominante detrás de una gran parte de las tomas de control de cuentas en 2026.
Cómo funciona el secuestro de sesión
La cadena de ataque es la misma independientemente de cómo se obtuvo la cookie.
- El usuario se autentica. El navegador completa el inicio de sesión y el MFA. El servidor emite una cookie de sesión, una cadena aleatoria larga, y la devuelve con la respuesta.
- El atacante captura la cookie. Esto sucede a través de malware infostealer, un proxy de phishing o un script malicioso que se ejecuta en la página.
- El atacante reproduce la cookie. Desde su propio navegador o un script, establece la cookie robada y envía una solicitud al sitio objetivo.
- El servidor ve una sesión válida. La cookie está activa y fue emitida a un usuario autenticado. Se concede el acceso.
La sesión legítima permanece abierta. El usuario sigue navegando en su dispositivo; el atacante navega por la misma cuenta en el suyo.
Tres formas en que los atacantes roban tokens de sesión
Malware infostealer
El malware infostealer es la ruta más común. Familias como Lumma, Vidar y RedLine escanean el almacén de cookies en disco del navegador, extraen tokens de sesión de cientos de sitios y los transmiten a un servidor controlado por el atacante en minutos de infección. El Informe Anual de Exposición de Identidad 2025 de SpyCloud recuperó más de 17.000 millones de registros de credenciales robadas del submundo criminal en 2024. Las cookies de sesión robadas llegan a los mercados de Telegram en horas de una infección exitosa.
El almacén de cookies del navegador es un archivo local, en texto plano o una base de datos SQLite local. Cualquier proceso que se ejecute con los privilegios del usuario puede leerlo. Los infostealers no interceptan el tráfico de red; leen desde el disco después de que el navegador ya ha descifrado los datos.
Phishing adversario-en-el-medio (AiTM)
El phishing AiTM coloca un proxy inverso entre la víctima y la página de inicio de sesión real. La víctima ve una copia visual exacta del inicio de sesión, introduce las credenciales y completa el MFA. El proxy reenvía todo al sitio real y captura la cookie de sesión resultante cuando regresa. El atacante ahora tiene un token post-autenticación válido sin haber pasado el MFA ellos mismos.
Esta técnica derrota los controles antiPhishing tradicionales porque la página parece auténtica, el aviso de MFA se completa contra el servicio real y la víctima inicia sesión normalmente. Solo el proxy del atacante se sitúa en el medio, invisible.
Scripts de terceros maliciosos y XSS
Una vulnerabilidad XSS o un script de terceros comprometido puede extraer tokens de sesión del navegador en tiempo de ejecución. JavaScript que se ejecuta en el contexto de origen de la página puede leer cookies no marcadas como HttpOnly, codificarlas y exfiltrarlas en solicitudes que parecen llamadas de análisis rutinarias.
Este es el vector de la cadena de suministro del lado del cliente: el atacante no apunta directamente a su sitio sino que compromete una etiqueta de análisis, un widget de chat o una biblioteca de pagos en la que su sitio confía y carga en cada página. El skimmer llega dentro de código que el sitio ya considera seguro.
Por qué las defensas estándar fallan ante esto
La marca HttpOnly
HttpOnly evita que JavaScript lea la cookie a través de document.cookie. Bloquea las lecturas de tokens XSS para esa cookie específica, lo cual importa. Pero no hace nada contra el malware infostealer que lee la cookie directamente desde el disco después de que el navegador la ha almacenado, y no protege contra un proxy AiTM que captura el token a través de la red antes de que llegue al almacén protegido.
HTTPS y TLS
TLS cifra el tráfico en tránsito y detiene el espionaje pasivo de red. Los infostealers leen desde el disco, después del descifrado. Los proxies AiTM terminan TLS en ambos lados de la conexión. Ninguno de los dos se detiene solo con el cifrado de transporte.
MFA
El MFA verifica al usuario en el inicio de sesión. Después del inicio de sesión, el servidor depende solo de la cookie. Una cookie robada nunca activa otro aviso de MFA a menos que el servidor fuerce la reautenticación basándose en señales de dispositivo o comportamiento, lo que la mayoría de los servidores no hace en cada solicitud.
Sesiones vinculadas a dispositivo y DBSC
La solución estructural para los ataques pass-the-cookie es vincular la sesión al hardware que la creó. Una cookie robada se vuelve inútil si el servidor requiere prueba criptográfica de que el navegador todavía controla una clave privada específica del dispositivo.
El protocolo Device Bound Session Credentials (DBSC) de Google hace esto usando el TPM o Secure Enclave del dispositivo. En Chrome 146+ para Windows, el navegador genera una clave privada en el hardware durante el establecimiento de la sesión. Las cookies de sesión de corta duración solo se emiten mientras el navegador pueda demostrar la posesión de esa clave. Un atacante que roba la cookie desde otro dispositivo no puede renovarla sin la clave privada.
Los límites prácticos a mediados de 2026:
- Cobertura: Chrome 146+ en Windows es el despliegue principal. iOS, Firefox y Safari no admiten DBSC todavía.
- Rutas de reserva: cuando no hay TPM disponible o se produce un error de red durante la verificación de la clave, DBSC puede omitir la vinculación. Esa sesión se comporta como una cookie convencional.
- Malware en el mismo dispositivo: si un infostealer se ejecuta en la misma máquina que tiene la clave privada, el atacante puede usar la sesión desde ese dispositivo. DBSC aborda la reproducción fuera del dispositivo, no el compromiso en el mismo dispositivo.
Estas brechas hacen que DBSC sea una capa, no una solución completa.
Lista de verificación de prevención del secuestro de sesión
| Control | Lo que detiene |
|---|---|
| TLS + HSTS | Espionaje de red (session sidejacking) |
| Marcas HttpOnly, Secure, SameSite | Lecturas XSS vía document.cookie |
| Rotación del ID de sesión tras el inicio de sesión | Fijación de sesión |
| Tiempos de espera absolutos e inactivos cortos | Ventana para reproducción tras el robo |
| Tokens de sesión aleatorios largos | Adivinación de tokens |
| Revocación del lado del servidor al cerrar sesión | Sesiones activas tras acción de cuenta |
| DBSC (Chrome 146+ / Windows) | Reproducción fuera del dispositivo de cookie robada |
| Monitoreo de scripts del lado del cliente | Exfiltración de tokens vía XSS o cadena de suministro |
| Inteligencia de dispositivos + puntuación de comportamiento | Token reproducido en la sesión activa |
Ningún control individual es completo. Los infostealers derrotan los controles de transporte. Los proxies AiTM derrotan el MFA y HTTPS en la capa de sesión. HttpOnly limita un vector de lectura JavaScript pero no las lecturas desde disco. El modelo por capas funciona porque cada control derrota lo que los demás no pueden.
Detectar una sesión secuestrada en el navegador activo
La prevención reduce la probabilidad de robo de tokens. La detección captura la sesión que ya fue robada y se está reproduciendo.
cside se ejecuta como un único snippet de JavaScript propio en el navegador del visitante sin proxy y sin cambios de DNS. Monitorea lo que los scripts de terceros y la propia sesión hacen en la página activa para usuarios reales, no lo que un rastreador o escáner observa en el código en reposo.
Exfiltración de tokens en la fuente. Un script de terceros que adjunta detectores de eventos inesperados a los campos de formulario, lee valores de cookies fuera de las llamadas de análisis normales o envía datos a un dominio desconocido activa una señal de detección antes de que el token abandone la página. Esto cierra el vector XSS y de cadena de suministro antes de que una cookie sea robada. La misma monitorización en tiempo real también detecta el relleno de cookies de afiliado y el secuestro de enlaces: donde los scripts inyectados insertan cookies de afiliado controladas por el atacante o reescriben los enlaces salientes para redirigir la atribución, un ataque de capa del navegador igualmente invisible.
Discrepancia de dispositivo en la reproducción. Cuando se usa una cookie robada desde un dispositivo diferente, la huella digital de la sesión cambia. La inteligencia de dispositivos de cside genera un ID de dispositivo persistente a partir de más de 250 señales de navegador, hardware y red con un 99.7% de precisión. Una discrepancia de huella digital después de una sesión establecida es una anomalía que la capa de puntuación de comportamiento señala para reautenticación o bloqueo.
Señales de comportamiento. La reproducción automatizada de sesiones desde un script o un agente de IA produce patrones diferentes a las sesiones humanas reales: sin movimiento realista del ratón, sin varianza de desplazamiento, sin cadencia de escritura natural. Las señales a nivel de comportamiento de cside separan la automatización del uso genuino.
cside también integra detección de agentes de IA, capturando herramientas de orquestación y navegadores automatizados que reproducen sesiones robadas o ejecutan acceso de cuentas mediante scripts a escala.
PCI DSS 4.0.1 y seguridad de sesiones en páginas de pago
Para plataformas de comercio electrónico y pagos, los vectores de scripts del lado del cliente y XSS que exfiltran tokens de sesión son los mismos riesgos que abordan los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1. El requisito 6.4.3 exige un inventario de scripts y un método de autorización para cada script en las páginas de pago. El requisito 11.6.1 requiere monitoreo continuo y alertas sobre cambios no autorizados en los scripts de páginas de pago y los encabezados HTTP de seguridad.
Un script de terceros malicioso que exfiltra un token de sesión o datos de tarjeta de pago en una página de pago es precisamente la amenaza que abordan esos requisitos. cside automatiza ambos controles y produce informes semanales listos para QSA (validado por VikingCloud). El monitoreo que detecta un script malicioso robando tokens de sesión también satisface el mandato de detección de manipulaciones que los QSA ahora evalúan.
Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 son obligatorios y se evalúan desde el 1 de abril de 2025.
