La autenticación de dos factores protege el proceso de inicio de sesión, pero tras una verificación exitosa el sitio suele crear una sesión. El navegador recibe una cookie u otro token y lo presenta en las solicitudes siguientes. La contraseña, el código de un solo uso o la clave de acceso ya no son necesarios cada vez que se abre la página.
Por eso al atacante a veces no le hace falta romper la 2FA. Si un info‑stealer robó un token válido, el delincuente puede presentarlo al servidor como confirmación de una sesión ya creada. El servidor ve la continuación de una sesión previamente autorizada, no un nuevo inicio de sesión. Comprobaciones por dirección de red, dispositivo y otros indicios pueden frenar el ataque, por lo que una sola copia del token no basta en todos los servicios.
La dimensión del problema la mostró la investigación de Okta del 9 de septiembre de 2026. La empresa analizó 7 GB de datos de info‑stealers de 5 871 equipos infectados en 162 países. El volcado apareció en Telegram el 2 de agosto. Los investigadores encontraron 44 791 JWT únicos, de los cuales 555 probablemente estaban relacionados con la autenticación en servicios de inteligencia artificial.
Cómo el robo de sesión permite eludir la 2FA
La cadena habitual es: contraseña → segundo factor o clave de acceso → el servidor confirma la identidad → crea una sesión → el navegador recibe un identificador de sesión → las siguientes solicitudes se realizan con ese identificador.
El segundo factor actúa al inicio de la cadena. Tras el inicio de sesión, el sitio necesita una forma de recordar al usuario ya verificado. Muchos datos de sesión funcionan mediante la presentación de un secreto válido. Si el atacante obtiene ese secreto, el servidor debe recurrir a otros métodos para determinar si la solicitud procede realmente del usuario anterior.
El robo de sesión no rompe la autenticación de dos factores. El atacante utiliza el resultado de una comprobación que ya se pasó con éxito.
Una clave de acceso protege bien contra el phishing y el robo de contraseña, pero por sí sola no protege cada token de sesión que el servicio entregue tras el inicio. Por eso bancos, servicios de correo y otros sistemas pueden volver a solicitar la confirmación de identidad antes de cambiar la contraseña, añadir un nuevo método de acceso o realizar otra operación sensible.
Qué son cookie, token de acceso, token de actualización y JWT
La cookie de sesión guarda el identificador o el token de la sesión actual. Un token de acceso otorga ciertos permisos por un tiempo limitado, y un token de actualización permite obtener nuevos tokens de acceso. El robo del último es especialmente peligroso, porque el atacante puede renovar el acceso hasta que el secreto sea revocado o expire.
JWT, o JSON Web Token, es un formato de token. Una firma criptográfica protege el contenido frente a modificaciones inadvertidas, pero no impide copiar un JWT válido en su totalidad. Un JWT firmado tampoco tiene por qué estar cifrado.
Okta encontró 44 791 JWT únicos. En el 17,7 % de los tokens había datos personales abiertos, por ejemplo nombre, dirección de correo electrónico o número de teléfono. Esa información sigue siendo útil para phishing incluso después del vencimiento del token.
Los investigadores también hallaron 2 937 JWE relacionados con autenticación. Según Okta, una parte importante de esos tokens la emitía OpenAI usando NextAuth.js. Al 2 de agosto, 1 843 de los JWT y JWE encontrados aún no habían expirado. El cifrado oculta el contenido de un JWE, pero no impide por sí solo volver a presentar un token válido al servidor.
En una tabla aparte Okta indicó 9 829 tokens únicos de autenticación de Google, de los cuales 9 213 seguían vigentes. Para Microsoft los valores fueron 2 491 y 1 763, y para Anthropic 561 y 164. Las cifras de Google y Microsoft no deben interpretarse como número de cuentas robadas en servicios de IA, porque los sistemas de autenticación compartida cubren distintos productos.
El coste de una filtración puede ser alto. Unit 42 describe un caso con gastos de casi 1 millón de dólares. En otro incidente público citado por Okta, el arquitecto de software Jesse Davies informó del uso no autorizado de Gemini por aproximadamente 25 673 AUD. El atacante llamó a un servicio público de Cloud Run, no robó la sesión del navegador.
Otro caso independiente ocurrió en METR. Por un error fail‑open, una instancia pública de EC2 quedó prácticamente sin comprobación de acceso, tras lo cual el atacante logró la exposición de una clave de API y durante casi tres semanas consumió créditos por un valor aproximado de 600 000 dólares. Allí no se usó un info‑stealer ni el robo de cookies. El caso muestra el riesgo general: obtenido un secreto válido, el atacante a menudo puede usar el acceso sin un nuevo inicio de sesión.
Qué hacer si roban la sesión o la cookie
Los info‑stealers buscan contraseñas guardadas, cookies, datos de perfiles del navegador, tokens de aplicaciones y claves de API. El atributo HttpOnly dificulta que una página web ordinaria lea las cookies, pero no protege frente a un programa malicioso que ya esté en el equipo.
Si sospecha de un info‑stealer, no cambie la contraseña ni inicie sesión en cuentas importantes desde el dispositivo infectado. El malware puede robar al instante las nuevas cookies y tokens.
- Desconecte el dispositivo sospechoso de la red.
- Desde un dispositivo limpio, abra la configuración de seguridad de la cuenta.
- Cierre todas las sesiones activas.
- Revoque aplicaciones desconocidas, claves y tokens.
- Cambie la contraseña.
- Reemita los códigos de respaldo de la 2FA.
- Revise el historial de accesos y los cambios de configuración.
- Limpie el sistema infectado y, si la compromisión es grave, reinstálelo.
El botón «Cerrar sesión» a menudo termina solo la sesión actual. Cambiar la contraseña tampoco siempre revoca todos los tokens emitidos con anterioridad.
Primero revoque las sesiones antiguas desde un dispositivo limpio. Cambiar la contraseña en un equipo infectado puede simplemente entregar al info‑stealer la nueva contraseña y una nueva sesión.
Cómo los navegadores protegen la sesión frente a la copia
En 2024 Google añadió en Chrome 127 para Windows App‑Bound Encryption. El mecanismo vinculó el descifrado de datos protegidos del navegador a Chrome y dificultó la extracción directa de cookies. La protección elevó el coste del ataque, pero no resolvió el problema por completo. Especialistas de Red Canary hallaron saltos en Stealc, Vidar, LummaC2 y otros info‑stealers. El malware, por ejemplo, extraía cookies de la memoria del navegador o usaba depuración remota.
Device Bound Session Credentials, o DBSC, va más allá y vincula la continuación de la sesión a una clave criptográfica del dispositivo. El navegador crea un par de claves, y la clave privada no debería abandonar el dispositivo. Para emitir una nueva cookie de corta duración, el servidor pide al navegador que demuestre la posesión de la clave. Así, una copia robada de la cookie en otro equipo pierde rápidamente valor.
Google empezó a desplegar DBSC en Chrome 145 para Windows, donde las claves las protege el módulo TPM. En abril de 2026 la empresa anunció la disponibilidad pública de DBSC para Windows en Chrome 146. En el mismo comunicado Google mencionó solo la intención de soportar macOS en una de las versiones siguientes de Chrome y no dio una versión concreta. Por eso no puede afirmarse que DBSC para macOS apareció precisamente en Chrome 147 sin una confirmación oficial aparte.
DBSC no se puede activar simplemente en cualquier sitio y considerar el problema resuelto. El servidor del servicio debe soportar el protocolo, y el malware en el equipo de origen aún puede actuar en nombre del usuario directamente en el dispositivo infectado.
Preguntas y respuestas
¿Se puede entrar en una cuenta sin contraseña ni código 2FA?
Sí, si el servicio acepta un token válido robado como continuación de una sesión ya creada. En ese caso no se inicia un nuevo acceso, por lo que podrían no solicitarse la contraseña ni el segundo factor.
¿Salvará cambiar la contraseña tras el robo de cookies?
No en todos los servicios. Es más seguro, desde un dispositivo limpio, cerrar todas las sesiones, revocar las aplicaciones y tokens asociados, y luego cambiar la contraseña.
¿Protege la firma de un JWT contra el robo?
No. La firma protege el JWT frente a modificaciones inadvertidas, pero no impide copiar un token válido entero y presentarlo al servidor.
¿Cómo saber si robaron la sesión de una cuenta?
Los indicios pueden ser dispositivos activos desconocidos, acciones en la cuenta sin la participación del propietario, cambios en la configuración, cargos inesperados o notificaciones de actividad sospechosa. Puede no haber un aviso de nuevo inicio de sesión si el delincuente usó una sesión ya válida.
¿Qué es más peligroso: la cookie de sesión o el token de actualización?
Ambos secretos son peligrosos. La cookie de sesión puede dar acceso inmediato a una sesión activa, y el token de actualización puede permitir obtener nuevos tokens de acceso durante más tiempo. El riesgo concreto depende de la arquitectura del servicio y de las reglas de revocación de tokens.
¿Ayuda eliminar las cookies del navegador tras una infección?
Eliminar las cookies locales no revoca la copia que el delincuente ya obtuvo. Hay que cerrar las sesiones activas en el lado del servicio y hacerlo desde un dispositivo limpio.
¿Protege el modo de incógnito contra el robo de sesión?
No. El modo de incógnito limita sobre todo el almacenamiento de historial y datos locales al cerrar la ventana. Si un info‑stealer ya actúa en el equipo, el modo privado no protege frente al robo de tokens activos.
Conclusión
La 2FA y las claves de acceso aumentan mucho la seguridad de una cuenta, pero no eliminan la amenaza del robo de una sesión ya creada. Tras una infección, hay que revocar las sesiones y tokens activos desde un dispositivo limpio y luego eliminar el malware. Los tokens de corta duración, la verificación adicional antes de acciones críticas y la vinculación de la sesión al dispositivo reducen la posibilidad de reutilizar un secreto robado.
El material está destinado a proteger cuentas y sistemas propios. El robo, la interceptación y el uso de tokens o sesiones ajenos sin el permiso del titular pueden infringir la legislación rusa. Verifique esos mecanismos solo en sus propios sistemas o con permiso expreso.
