Phishing avanzando, EvilTokens y combinación tóxica de OAuth, MFA e IA para robar credenciales
En febrero de 2026, se lanzó EvilTokens, una plataforma de phishing como servicio (PhaaS). En tan solo cinco semanas, había comprometido a más de 340 organizaciones de Microsoft 365 en cinco países.
Las víctimas de la plataforma recibían un mensaje solicitándoles que introdujeran un código corto en microsoft.com/devicelogin y completaran su verificación MFA habitual. A continuación, creían haber iniciado sesión correctamente. En realidad, habían proporcionado al operador un token de actualización válido con acceso a su buzón, unidad, calendario y contactos, con una duración equivalente a la de una política de inquilino, no a la de una sesión.
El operador nunca necesitó introducir una contraseña, nunca se activó la solicitud de MFA y nunca se produjo ningún evento de inicio de sesión que pareciera una intrusión. El ataque tuvo éxito porque la pantalla de consentimiento de OAuth se ha convertido en un clic instintivo, y los controles diseñados para detener el phishing de credenciales no tienen en cuenta la capa de consentimiento.
Los investigadores de seguridad denominan a esta situación phishing de consentimiento o abuso de la concesión de OAuth. El clic de phishing que importaba la década pasada entregaba una contraseña. El clic de phishing que importa ahora entrega un token de actualización, y se sitúa estructuralmente por debajo de los controles de identidad que la mayoría de las organizaciones aún consideran el perímetro de seguridad.
¿Por qué la autenticación multifactor no puede ver una concesión de OAuth?
Un ataque de phishing de credenciales proporciona un nombre de usuario y una contraseña que deben ser reutilizados en algún lugar, y la mayoría de las plataformas de identidad ahora exigen un segundo factor de autenticación durante la reutilización. Incluso los kits de ataque de intermediario (AiTM) generan una cookie de sesión vinculada a un evento de inicio de sesión que el SIEM correlaciona con la geografía, el dispositivo y los patrones de viaje.
Una concesión OAuth no genera credenciales repetidas. El usuario se autentica en el proveedor de identidad legítimo, completa el desafío de MFA en el dominio legítimo y hace clic en Aceptar. El token que obtiene el atacante es el resultado del funcionamiento previsto del sistema. Está firmado por el proveedor de identidad, tiene el alcance acordado por el usuario y es actualizable. La MFA no puede bloquearlo porque ya se ha realizado.
El otro problema es que los tokens de actualización extienden la ventana de validez. Los tokens emitidos por EvilTokens sobrevivieron a los restablecimientos de contraseña y permanecieron válidos durante semanas o meses, según la configuración del inquilino. Cambiar la contraseña no invalidaba la concesión. Solo la revocación explícita o una política de acceso condicional que exigiera un nuevo consentimiento la cerraban.
Cómo se normalizó el consentimiento
Este vector de ataque existe desde que OAuth se convirtió en estándar. Lo que cambió es el entorno en el que opera. Los usuarios se han acostumbrado a aceptar las pantallas de consentimiento con la misma frecuencia con la que antes aceptaban las cookies. Todas las integraciones de productividad lo muestran. Todas las extensiones de navegador que interactúan con una cuenta SaaS lo muestran. El volumen de consentimientos legítimos que un trabajador del conocimiento ve en un mes supera con creces cualquier cosa que existiera cuando se redactaron los modelos de amenazas originales de OAuth.
Los ámbitos en sí mismos utilizan un lenguaje que no se corresponde claramente con el riesgo. Un ámbito llamado "Leer tu correo" suena limitado, pero en la práctica abarca todos los mensajes, archivos adjuntos e hilos compartidos a los que el usuario puede acceder. Un permiso denominado "Acceder a archivos sin estar presente" implica un token de larga duración emitido sin que el usuario esté frente a una pantalla para revocarlo. La brecha entre el lenguaje de consentimiento y el alcance operativo es precisamente donde operan los atacantes.
Combinaciones tóxicas se forman bajo el control del propietario de la aplicación.
Un único consentimiento de OAuth proporciona a un atacante un punto de acceso limitado dentro de una aplicación. El riesgo aumenta cuando esos puntos de acceso se conectan.
Un usuario del departamento de finanzas otorga a un resumidor de reuniones con IA acceso a su calendario y buzón de correo. Posteriormente, el mismo usuario otorga a un asistente de productividad acceso a la unidad compartida de la empresa. Un tercer permiso conecta una herramienta de enriquecimiento de CRM con la base de datos de clientes. Cada uno se aprobó individualmente. Ningún propietario de la aplicación autorizó la combinación. La superficie de riesgo ahora son tres ámbitos que se cruzan a través de una misma identidad humana, donde la vulnerabilidad del resumidor de reuniones puede acceder a borradores de contratos y registros de clientes a través de la misma persona.
Esto se denomina combinación tóxica. Consiste en una distribución de permisos entre aplicaciones, mediada por una concesión OAuth, una integración o un agente de IA, que ningún propietario de aplicación autorizó como su propia superficie de riesgo. No se puede observar en el registro de auditoría de ninguna aplicación, ya que la conexión existe fuera de todas ellas.
La instalación de MCP, el clic de consentimiento de OAuth y la concesión de la extensión del navegador: cada uno de estos pasos se realiza con un solo clic. Los servidores del Protocolo de Contexto de Modelo (MCP) se están convirtiendo en la próxima superficie de ataque al estilo OAuth, permitiendo a los agentes obtener acceso restringido mediante el mismo mecanismo de confianza única que ya utilizan las pantallas de consentimiento.
El incidente Salesloft-Drift de 2025 demostró cómo se manifiesta esto a gran escala. Un conector descendente comprometido se propagó a más de 700 clientes de Salesforce mediante tokens de OAuth que los clientes habían aprobado legítimamente. Todos los clientes autorizaron la integración, pero ninguno autorizó la propagación.
Fuente: THN
