El token que elude la MFA: Por qué el robo de OAuth es la nueva puerta de entrada
7 Min. de lectura
La autenticación multifactor asegura la sesión, pero no protege la clave que se genera tras el inicio de sesión. Es precisamente aquí donde los atacantes actúan: roban tokens OAuth que ya contienen una MFA validada y acceden a servicios SaaS sin necesidad de realizar una segunda verificación de factor. El phishing OAuth ha aumentado casi 39 veces en el último año; más de mil entornos SaaS han sido afectados.
Lo más importante en resumen
- El token contiene ya la MFA. Un token OAuth robado permite acceso sin necesidad de realizar una nueva verificación de factor.
- El phishing OAuth ha experimentado un aumento vertiginoso. Desde 2025 hasta 2026, el número de casos aumentó en aproximadamente 3.750%, impulsado por el uso indebido del código de dispositivo.
- SaaS es la superficie de ataque. Más de mil entornos SaaS han sido comprometidos a través de este método.
Relacionado:El dispositivo Edge como puerta de entrada para ransomware / Cuando el propio producto de protección es la vulnerabilidad
Cómo un token supera la MFA
¿Qué es un token OAuth? Un token OAuth es un certificado de autorización digital emitido por un servicio después de que el usuario haya realizado correctamente su registro. En lugar de volver a iniciar sesión con contraseña y segundo factor cada vez que se realiza una solicitud, la aplicación utiliza este token para confirmar que el acceso ya ha sido autenticado. Esta comodidad es precisamente la debilidad.
La lógica es sorprendentemente sencilla. La MFA funciona en el momento del inicio de sesión; luego, el servicio genera un token de sesión o OAuth que representa el estado de autenticación. Quien obtiene este token no necesita volver a iniciar sesión. En su lugar, presenta la clave que ya ha sido validada por la MFA. La segunda etapa de verificación no se vulnera, sino que se evita, porque al momento del ataque ya quedó obsoleta.
Es especialmente peligroso cuando se aprovecha el procedimiento de código de dispositivo. De hecho, la autenticación de dispositivos sin teclado, como las smart TV, está permitida. Los atacantes inducen a sus víctimas a confirmar un código que, en realidad, les otorga acceso al dispositivo del atacante. La víctima pasa por una autenticación MFA legítima y, sin saberlo, acepta la sesión ajena. Desde la perspectiva del servicio, todo está correcto: un usuario autorizado ha dado su consentimiento.
Por qué la MFA clásica resulta ineficaz aquí
La incómoda verdad: la MFA fue diseñada para un problema diferente. Evita que una contraseña robada sea suficiente por sí sola. Sin embargo, no ayuda frente a un token robado después de haber iniciado sesión, porque en ese momento ya no está en juego. Quien considera la MFA como una medida final está defendiendo la puerta y pasa por alto que el atacante puede entrar por la ventana abierta de la sesión.
Esto desplaza la defensa desde el inicio de sesión hasta la propia sesión. Ya no basta con verificar el acceso una vez; es necesario supervisar y limitar la sesión en sí. Un token válido indefinidamente y aceptado desde cualquier lugar es como una llave permanente. En cambio, un token que caduca tras un corto periodo, está vinculado al dispositivo y al lugar de uso, y se revoca ante cualquier comportamiento sospechoso, resulta mucho menos valioso si es robado.
Qué hace valioso al token
- Vigencia larga o ilimitada
- Aceptación desde cualquier dispositivo y ubicación
- No hay supervisión de la sesión tras el inicio de sesión
Qué lo desvaloriza
- Vida útil corta del token
- Vinculación al dispositivo y la ubicación
- Revocación ante comportamientos sospechosos
Qué debería hacer concretamente un SOC
El primer palanca es la duración del token. Muchos servicios SaaS permiten valores predeterminados muy generosos, porque así los usuarios rara vez tienen que volver a iniciar sesión. Precisamente esa comodidad debe ser revisada. Una vida útil más corta y la obligación de reautenticarse ante acciones sensibles reducen el margen de tiempo durante el cual un token robado puede ser utilizado.
La segunda palanca es el Acceso Condicional. Un token no debería ser válido desde cualquier lugar. Si la misma sesión se utiliza repentinamente desde otro país o desde un dispositivo desconocido, debe ser cuestionada, no aceptada automáticamente. Esta verificación contextual es la verdadera respuesta al token robado, porque no protege el inicio de sesión, sino el uso posterior.
La MFA cierra la puerta. Pero si el atacante copia la llave que luego se emite, ni el mejor candado servirá. Lo que hay que defender es la sesión, no solo el inicio de sesión.
La tercera palanca afecta directamente al propio procedimiento del código de dispositivo. Donde no sea necesario, debe limitarse o desactivarse. Además, el personal debe comprender que la solicitud de confirmar un código merece la misma desconfianza que una petición de contraseña en una página ajena. Un código confirmado puede autorizar una sesión ajena. Esa simple información evita gran parte de los ataques basados en el código de dispositivo.
Ninguna de estas tres palancas elimina la MFA. Sigue siendo la base. Pero es la primera línea de defensa, no la última. Quien pierde de vista la sesión tras el inicio de sesión ha abandonado la defensa justo donde los ataques actuales hacen presión. La buena noticia: la duración del token, el Acceso Condicional y la higiene del código de dispositivo son configurables, no necesitan inventarse desde cero.
Preguntas frecuentes
¿Se vulnera la MFA cuando se roba un token OAuth?
No, se evade. El token se genera tras una MFA exitosa y lleva consigo el estado autenticado. Quien lo robe ya no necesita iniciar sesión y, por lo tanto, no activa ninguna nueva solicitud de factor adicional.
¿Qué es el abuso del código de dispositivo?
El procedimiento del código de dispositivo permite iniciar sesión en dispositivos sin teclado. Los atacantes logran que la víctima confirme un código que, en realidad, otorga acceso al dispositivo del atacante. La víctima pasa por una MFA genuina y, sin saberlo, autoriza la sesión ajena.
¿Por qué no basta la MFA contra estos ataques?
La MFA actúa en el momento del inicio de sesión. El ataque se produce después, sobre la sesión ya emitida. En este punto, la MFA ya no interviene, por lo que no puede detener el token robado.
¿Qué medida ayuda más rápidamente?
Revisar y reducir la duración del token, así como activar el acceso condicional. Ambas acciones reducen la ventana temporal y el alcance de un token robado, sin sustituir a la MFA.
¿Debería desactivarse el procedimiento de código de dispositivo?
Donde no sea necesario, sí. Donde sea imprescindible, debe restringirse y supervisarse. Además, ayuda formar a la plantilla para que comprenda que confirmar un código puede autorizar una sesión ajena.
Más contenido de la red MBF Media
Fuente de la imagen: generada por IA (mayo de 2026)
