En una campaña documentada contra creadores de YouTube, los atacantes enviaron falsas ofertas de negocio que conducían a un programa malicioso capaz de robar cookies del navegador. Las sesiones sustraídas les ayudaron a hacerse con canales sin conseguir un nuevo código de acceso. El Threat Analysis Group de Google describe la campaña. Ilustra un riesgo que permanece después de proteger bien el inicio de sesión: el servicio también debe proteger la sesión que crea.
Una cookie de sesión u otro token al portador indica al servicio que la autenticación ya se ha completado. Si un atacante obtiene uno que aún sirve, quizá pueda enviar peticiones como ese usuario sin repetir el paso inicial de autenticación multifactor. Depende de la caducidad, revocación, vinculación al dispositivo y comprobaciones adicionales del servicio. El robo de sesiones es una vía de toma de cuentas, junto con el robo de contraseñas y el acceso indebido a los métodos de recuperación.
Qué es una sesión
Tras iniciar sesión correctamente, un servicio suele emitir un identificador de sesión en una cookie. El navegador lo envía en las peticiones posteriores para que no tengas que autenticarte en cada página. El servicio también puede usar otros tokens y pedir una nueva autenticación para acciones sensibles. La guía de OWASP sobre gestión de sesiones explica cómo funcionan juntos el identificador y el estado de la sesión en el servidor.
La duración de una sesión depende del servicio, las normas de la cuenta y la actividad. Un token puede caducar, renovarse o revocarse tras cerrar sesión o a raíz de un incidente de seguridad. Algunos servicios comparan además señales del dispositivo o de la red y exigen otra comprobación. Un token robado es peligroso mientras el servicio lo acepte, pero no es válido para siempre ni necesariamente en cualquier dispositivo.
Los navegadores protegen las cookies frente a los scripts normales de una página con opciones como HttpOnly y Secure. Los sistemas también pueden proteger los valores almacenados. Eso no vuelve seguro un dispositivo comprometido: un programa malicioso con suficiente acceso local puede obtener cookies del almacenamiento o la memoria del navegador. La explicación de Google sobre sesiones vinculadas al dispositivo muestra por qué el almacenamiento protegido solo por software no evita con fiabilidad el robo tras una intrusión de ese tipo.
Cómo se roban las cookies de sesión
Una vía es un ladrón de información: software malicioso que se ejecuta en el dispositivo y busca credenciales y datos de sesiones del navegador. Puede llegar mediante una descarga falsa, un archivo adjunto malicioso u otra infección. Lo que consigue extraer depende de sus permisos, del navegador y de las protecciones del equipo. Ninguna familia roba automáticamente todas las cookies o contraseñas.
Otra vía es una página de phishing que se coloca entre tú y el servicio real. Reenvía el inicio de sesión auténtico mientras captura las credenciales y, en algunos flujos, el token de sesión emitido después. Así puede esquivar un código de un solo uso que introduzcas en la página falsa. Microsoft documenta este patrón. Las claves de acceso vinculadas al sitio real resisten este phishing durante el inicio de sesión, aunque una sesión ya autenticada aún puede verse comprometida más tarde.
Los tokens robados pueden usarse directamente o venderse junto con otros datos de la cuenta. Un atacante puede intentar imitar características conocidas del dispositivo o la red, pero copiar el agente de usuario o una IP parecida no garantiza el acceso. El servicio puede rechazar el token, exigir una nueva comprobación o detectar un comportamiento extraño después. OWASP explica la utilidad y los límites de esas comprobaciones de contexto.
Qué frenan la MFA y las claves de acceso
La autenticación multifactor mejora mucho la seguridad del inicio de sesión. Por sí sola, no demuestra que cada petición posterior con un token de sesión existente proceda de quien inició la sesión. Si el servicio acepta un token robado como credencial al portador, el atacante puede actuar en esa sesión sin repetir el desafío multifactor. Aun así, el servicio puede pedir otra comprobación para acciones sensibles o revocar sesiones sospechosas.
Las comprobaciones de contexto, como los cambios de dirección IP, navegador u horario, pueden ayudar a detectar la reutilización. También pueden activarse durante viajes o cambios legítimos de dispositivo. A la inversa, un atacante puede parecer lo bastante habitual para superar una regla simple. Rotar los tokens y acortar su vigencia reduce la ventana de exposición; la revocación desde el servidor y una nueva autenticación pueden cortar el acceso cuando se sospecha un robo.
Las claves de acceso y llaves de seguridad FIDO2 resisten los inicios de sesión en sitios falsos, una ventaja importante frente a los códigos vulnerables al phishing. No hacen inmune al robo una sesión al portador ya emitida, como explica la Alianza FIDO. Las credenciales de sesión vinculadas al dispositivo, o DBSC, añaden una prueba ligada al equipo cuando las admiten tanto el navegador como la web. Google empezó a ofrecerlas públicamente en Chrome para Windows en 2026. Su compatibilidad y despliegue aún varían.
Señales de alerta y primeros pasos
Puede que no recibas un aviso de nuevo inicio de sesión si alguien reutiliza una sesión existente, aunque el proveedor podría detectar otras anomalías. Fíjate en mensajes que no has enviado, reglas de reenvío inesperadas en el correo, cambios de cuenta que desconoces y alertas de seguridad. Cada indicio puede tener otras explicaciones: investiga pronto en lugar de confiar en que todo va bien porque no llegó un aviso de acceso.
Usa la página de gestión de sesiones o dispositivos del servicio, si existe. Google, por ejemplo, permite revisar y cerrar sesiones. La ubicación puede ser imprecisa y un solo dispositivo puede mostrar varias sesiones. Compara los detalles con tu propia actividad, revoca las sesiones desconocidas con los controles del proveedor y sigue sus indicaciones para recuperar la cuenta.
Si crees que tu dispositivo puede tener malware, deja de usarlo para accesos sensibles y haz que lo limpien o reinstalen según el procedimiento de tu organización. Desde un dispositivo fiable, revoca las sesiones y cambia las contraseñas afectadas. Revisa los métodos de recuperación, los ajustes multifactor y los cambios de cuenta según indique el proveedor. Cambiar la contraseña no siempre invalida todas las sesiones existentes.
Cómo reducir el riesgo de robo de sesión
Mantén actualizados el dispositivo y el navegador, evita las descargas que no sean de confianza y usa el método de acceso más sólido que admita el servicio. Si el proveedor ofrece revisión de sesiones, avisos, vigencias cortas o sesiones vinculadas al dispositivo, activa las medidas adecuadas para tu trabajo. Cada una reduce una parte del riesgo; ninguna vuelve inofensivo un dispositivo comprometido.
Una sesión de Browser.lol puede mantener las cookies de la web visitada en el navegador remoto, en vez de guardarlas en el perfil del navegador local. Esto no impide que el malware de tu dispositivo observe lo que escribes, controle tu navegador o ataque tu cuenta de Browser.lol y su conexión. Las sesiones remotas pueden seguir activas después de cerrar una pestaña, y los perfiles guardados pueden conservar datos del navegador. Combina el aislamiento con la seguridad del dispositivo y los controles de sesión del servicio de destino. Para conocer otros riesgos, lee Cómo pueden usar tu historial de navegación contra ti.
¿Necesitas una sesión aislada para tu próxima tarea?
Abre un navegador aislado desde el que ya usas y ponte manos a la obra.
Iniciar una sesiónSin instalar otro navegador • Las funciones dependen del plan
