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