Notebookcheck Logo

Cuenta pirateada a pesar de la autenticación de dos factores: basta con una cookie robada

Portátil con Windows sobre una mesa de madera con la página de inicio de Google abierta en el navegador
ⓘ Adam Sondel / Pexels
Cualquier persona que permanezca conectada en un navegador deja una cookie de sesión. Si esta es sustraída, el atacante no necesitará ni contraseña ni autenticación de dos factores.
El secuestro de sesión se produce tras iniciar sesión. Quienquiera que robe su cookie de sesión accede a su cuenta sin necesidad de contraseña ni de un segundo factor de autenticación, y el antivirus no lo soluciona porque la cookie robada sigue funcionando. Chrome ahora vincula las sesiones al dispositivo mediante DBSC, mientras que Firefox sigue almacenando su base de datos de cookies sin cifrar. Cómo funciona el robo y qué medidas son realmente eficaces.

El antivirus informa de que la operación se ha realizado con éxito. Se ha detectado y eliminado malware; todo está limpio. Dos días después, su cuenta de Google está enviando spam y la lista de dispositivos muestra un ordenador que no es el suyo. La autenticación de dos factores estuvo activada en todo momento.

Lo que ocurre aquí se denomina «secuestro de sesión», es decir, la apropiación de una sesión que ya está en curso. El atacante no necesita ni su contraseña ni su segundo factor de autenticación. Lo único que necesita es el pequeño archivo que su navegador almacena tras iniciar sesión, para que no tenga que volver a introducir nada en su próxima visita. Ese archivo es la cookie de sesión.

Google lo describe abiertamente en su propio blog de Chromium: el robo se produce tras el inicio de sesión y, por lo tanto, elude la autenticación de dos factores. Además, es difícil contrarrestarlo con software antivirus, ya que las cookies siguen funcionando incluso después de haber eliminado el malware.

Cómo funciona el robo

Al principio suele haber casi siempre un «infostealer», un programa diseñado para recopilar credenciales. Llega al equipo a través de software pirateado, un instalador manipulado o un archivo adjunto. Una vez allí, lee los archivos en los que el navegador almacena sus cookies. A continuación, el atacante importa la cookie a su propio navegador y accede al sitio web. El servicio detecta una sesión válida en la que se ha iniciado sesión y no solicita nada más.

La magnitud de este mercado queda patente en el Informe Global de Inteligencia sobre Amenazas que la empresa de seguridad Flashpoint publicó el 11 de marzo de 2026. Para el año 2025, Flashpoint contabiliza más de 11,1 millones de equipos infectados con programas de robo de información y 3.300 millones de credenciales y tokens de la nube sustraídos de ellos. Las cookies de sesión ni siquiera forman parte de ese recuento.

Desde el programa de robo de información en el ordenador hasta la sesión secuestrada: en ninguno de los cuatro pasos se solicita una contraseña ni un segundo factor de autenticación.

La Operación Endgame puso de manifiesto lo cerca que esto nos afecta. El 24 de junio de 2026, Europol informó de una operación contra los grupos de robo de información StealC y Amadey, así como contra la red de distribución SocGholish, en la que participó Alemania. Se desactivaron 326 servidores y 142 dominios, y se recuperaron 27 millones de conjuntos de credenciales. Se notificó a las víctimas a través de «Have I Been Pwned», entre otros canales.

El segundo factor se encuentra en el lugar equivocado. Un código SMS, una solicitud de la aplicación y una clave de seguridad verifican quién está iniciando sesión. La cookie solo se crea posteriormente, como prueba de que se ha superado dicha verificación. Quien posea dicha prueba no tiene que volver a superar la verificación. Ni siquiera el Programa de Protección Avanzada de Google cambia esto. Según Google, es posible que a quienes permanezcan conectados no se les vuelva a solicitar la clave de seguridad. En el artículo «Una contraseña por sí sola no es suficiente» se explica cómo proteger sus cuentas adecuadamente.

Qué están haciendo los navegadores al respecto

En Windows, Chrome ha cifrado las cookies con «App-Bound Encryption» desde la versión 127, de julio de 2024, y vincula la clave a la aplicación. La propia Google señala la limitación: el malware que se ejecuta con privilegios elevados elude la protección. Esto encarece el robo, pero no lo impide.

El verdadero avance se denomina «Device Bound Session Credentials» (Credenciales de sesión vinculadas al dispositivo), abreviado DBSC. El navegador genera un par de claves cuya parte privada nunca sale del dispositivo. En Windows, se almacena en el TPM, el chip de seguridad de la placa base. El servicio comprueba periódicamente si el navegador sigue disponiendo de esa clave. Una cookie en el equipo de otra persona no supera esa comprobación.

Para los sitios web, esta tecnología está disponible desde Chrome 145. Google la activó para sus propios servicios el 9 de abril de 2026 con Chrome 146 en Windows y la ha ido implantando desde el 25 de mayo de 2026 para las cuentas de Workspace y las cuentas personales de Google, sin que los usuarios tengan que habilitar nada. Siguen existiendo dos limitaciones. Según la especificación del W3C, el DBSC no impide el acceso mientras el atacante siga teniendo acceso al dispositivo. Además, cada sitio web debe participar activamente, razón por la cual la protección llega primero a los servicios de Google.

Firefox presenta una situación más delicada en este aspecto de lo que mucha gente supone. Su base de datos de cookies se almacena sin cifrar en el disco. La entrada en el sistema de seguimiento de errores de Mozilla, el error 56788, se registró hace 25 años, se cerró como «WONTFIX» en el año 2000 y se reabrió hace dos años. Tiene prioridad P3 y no está asignada a nadie. La «Protección total contra cookies» no cambia esto; se trata de la protección contra el seguimiento.

Chrome cifra las cookies desde la versión 127 y vincula las sesiones al dispositivo mediante DBSC. Firefox sigue manteniendo su base de datos de cookies sin cifrar.

Lo que puede hacer ahora

El orden es lo que marca la diferencia. En caso de infección por malware, la Oficina Federal Alemana de Seguridad de la Información (BSI) establece la secuencia siguiente: primero, reinstale el sistema; después, cambie las contraseñas. Quien lo haga al revés e introduzca la nueva contraseña en el equipo infectado, se la estará entregando directamente al atacante.

A continuación viene el paso que la mayoría de las personas se salta. Una nueva contraseña no expulsa necesariamente a un atacante que posea una cookie válida. Debe cerrar las sesiones abiertas por separado.

Google: myaccount.google.com, sección «Seguridad», «Gestionar todos los dispositivos». Cada sesión aparece en una entrada independiente; pulse sobre el dispositivo y cierre la sesión. Google no ofrece un único botón para todas ellas.

Microsoft: account.microsoft.com, opciones de seguridad avanzadas, «Cerrar sesión en todas partes». Según Microsoft, el cierre de sesión puede tardar hasta 24 horas, y la Xbox queda excluida.

Apple: account.apple.com, sección «Dispositivos», seleccione el dispositivo y haga clic en «Eliminar de la cuenta». El dispositivo volverá a aparecer si alguien sigue conectado en él.

Reinstale primero el sistema, a continuación cambie las contraseñas y, por último, cierre todas las sesiones. Si invierte el orden, tendrá que introducir la nueva contraseña en el equipo infectado.

Qué hacen y qué no hacen las claves de acceso

Las claves de acceso se consideran el sucesor de la contraseña, y la BSI las califica como una forma de autenticación muy segura. Esto es cierto, pero, una vez más, solo abarca el acto de iniciar sesión. Una clave de acceso impide que alguien inicie sesión suplantando su identidad. No impide que alguien se apropie de la sesión que usted ya tiene abierta. El hecho de que el propio inicio de sesión siga siendo vulnerable queda demostrado por el ataque «Pass-the-Passkey».

La realidad es incómoda. En su blog de seguridad del 9 de abril de 2026, Google señala que en ningún sistema operativo existe una forma fiable de impedir el robo de cookies únicamente mediante software una vez que el malware se ha instalado en el dispositivo. Lo que cambia DBSC es la vida útil del botín. La cookie robada solo se puede utilizar entonces en el equipo en el que se creó.

Hasta que esto se aplique en todas partes, la incomodidad seguirá recayendo sobre usted. No utilice software pirateado, descargue únicamente desde la fuente original y, ante cualquier sospecha, reinstale primero el sistema y cierre las sesiones después. En ese orden.

Google LogoAdd as a preferred source on Google
Mail Logo
> Análisis y pruebas de ordenadores portátiles y móviles teléfonos > Noticias > Archivo de noticias > Archivo de noticias 2026 08 > Cuenta pirateada a pesar de la autenticación de dos factores: basta con una cookie robada
Steffen Zahn, 2026-08-10 (Update: 2026-08-10)