Imagina un ataque de phishing donde la víctima no introduce sus credenciales en un formulario falso. De hecho, no hay un clon de la página de inicio de sesión de Microsoft o Google. La víctima inicia sesión en el portal real, legítimo, y aun así, los atacantes se apoderan de su cuenta de forma persistente.
Bienvenidos a la era de EvilTokens, la campaña de phishing avanzada que ha dejado obsoletos los vectores de ataque tradicionales al abusar de un mecanismo de confianza fundamental en la arquitectura en la nube: los tokens de OAuth.
El Núcleo del Problema: Abusando de la Confianza Concedida
El phishing tradicional busca robar el usuario y la contraseña. Sin embargo, con la adopción masiva de la Autenticación de Múltiples Factores (MFA), este enfoque se ha vuelto costoso y propenso a fallas para los cibercriminales. Aquí es donde entra el Phishing de Consentimiento Ilícito (Illicit Consent Phishing), la técnica reina detrás de EvilTokens.
En lugar de robar credenciales, EvilTokens engaña al usuario para que autorice una aplicación de terceros maliciosa (registrada previamente por los atacantes en plataformas legítimas como Microsoft Azure o Google Cloud).
La Anatomía del Ataque
[Víctima] —> (Enlace de Phishing) —> [Portal de Login Real (MS/Google)]
|
(Inicia Sesión + MFA)
|
[Atacante] <— [Token de Acceso Omitido] <— [Ventana de Consentimiento de App]
- El Anzuelo: La víctima recibe un correo electrónico o un mensaje con un enlace que apunta directamente al servicio de autenticación oficial (por ejemplo, login.microsoftonline.com).
- La Autenticación Real: El usuario introduce sus datos y aprueba el desafío MFA. Todo es 100% real y seguro hasta este punto.
- El Engaño del Consentimiento: Una vez autenticado, aparece una ventana emergente legítima del proveedor que pregunta si desea conceder permisos a una aplicación (por ejemplo: «Permitir que ‘Validación de Seguridad General’ acceda a tus archivos y lea tu correo»).
- La Corona: Al hacer clic en «Aceptar», el proveedor genera un token de acceso y un refresh token de OAuth. Estos tokens se envían directamente al servidor del atacante.
¿Por qué EvilTokens es una Pesadilla para los Equipos de SOC?
Este vector de ataque es particularmente peligroso por tres razones críticas:
- Bypass de MFA Nativo: Dado que el usuario completa el proceso de autenticación legítimo, el MFA no detiene el ataque. El token se emite después de que el MFA ha sido validado con éxito.
- Persistencia Silenciosa: Los refresh tokens pueden tener una validez de semanas o meses. Incluso si el usuario cambia su contraseña corporativa al día siguiente, el token sigue siendo válido. El atacante mantiene el acceso a los datos sin necesidad de conocer la nueva contraseña.
- Evasión de Controles de Red: El tráfico se genera a través de APIs legítimas del proveedor de la nube. No hay malware ejecutándose en el endpoint, ni conexiones a IPs flagradas como maliciosas en el tráfico web inicial.
Análisis Técnico: Los Permisos (Scopes) Más Buscados
Los atacantes detrás de EvilTokens no buscan acceso total de administrador desde el día uno; prefieren pasar desapercibidos utilizando permisos aparentemente inofensivos pero peligrosos a nivel de API:
| Permiso (Scope) | Impacto Real para el Atacante |
| Mail.Read / offline_access | Permite leer el correo electrónico de forma persistente y descargar archivos adjuntos, ideal para espionaje industrial o comprometer facturas (BEC). |
| User.Read.All | Mapeo completo del directorio de la empresa para escalar el ataque a otros usuarios. |
| Files.ReadWrite.All | Acceso de lectura y escritura a OneDrive/SharePoint para exfiltrar datos o desplegar ransomware en la nube. |
Cómo Blindar la Infraestructura frente a EvilTokens
Para los ingenieros de IA, especialistas en seguridad y administradores de sistemas, mitigar este riesgo requiere un cambio de paradigma: de la «protección de identidad estática» a la «gobernanza de aplicaciones».
1. Restringir el Consentimiento de Usuarios
La medida más drástica y efectiva es deshabilitar la capacidad de los usuarios finales para consentir aplicaciones de terceros no verificadas. En su lugar, implementa un flujo de aprobación del administrador, donde cualquier solicitud de OAuth deba ser auditada y aprobada por el equipo de seguridad antes de ser utilizada.
2. Caza de Amenazas (Threat Hunting) en los Logs de Auditoría
Busca anomalías en los registros de consentimiento. En Azure AD/Entra ID, monitorea eventos como:
- Consent to application
- Add OAuth2PermissionGrant
Presta especial atención a aplicaciones con nombres que simulen herramientas internas o de productividad, creadas por inquilinos (tenants) externos o desconocidos.
3. Implementar Políticas de Acceso Condicional
Configura políticas que exijan que los tokens solo sean válidos si se utilizan desde dispositivos administrados (Compliance/Hybrid Azure AD joined) o desde ubicaciones de red de confianza. Esto inutiliza el token en manos del atacante si intenta usarlo desde su propia infraestructura.
EvilTokens demuestra que los atacantes ya no necesitan romper el cifrado ni vulnerar el MFA por la fuerza; simplemente prefieren pedir permiso de la manera correcta. Cuando un mecanismo legítimo se convierte en el arma, la visibilidad de lo que ocurre dentro de las autorizaciones de la nube se vuelve tan crucial como la contraseña más robusta del sistema. La seguridad moderna ya no se trata solo de quién entra, sino de qué aplicaciones dejas pasar una vez que la puerta está abierta.
Woted2 
Deja un comentario