EvilTokens: phishing cifrado que se activa en el DOM del navegador y rompe las defensas

Un nuevo vector de phishing está explotando una debilidad operativa que muchos equipos de seguridad asumen cubierta: el ataque permanece cifrado y «fantasma» hasta que el navegador del empleado lo descifra y lo renderiza. La campaña EvilTokens que está detectando actividad en Estados Unidos y Europa usa exactamente esa técnica: la página maliciosa llega como una carga cifrada (AES‑GCM) y sólo se vuelve visible tras ser descifrada en el DOM del navegador, donde activa un flujo legítimo de Microsoft Device Code para convencer a la víctima de autorizar acceso a su cuenta sin revelar la contraseña.

La consecuencia inmediata es que los controles convencionales —revisión estática de URLs, bloqueos en pasarelas de correo o filtrado a nivel de red— pueden dar un falso negativo. El enlace inspeccionado en frío muestra contenido inocuo o un blob cifrado, mientras que el usuario, al abrirlo en su navegador, ve una página que inicia el flujo de autenticación y entrega un código de dispositivo que termina siendo usado para obtener tokens y acceso a Microsoft 365. Microsoft documenta cómo funciona el Device Code Flow y por qué no requiere ingreso de credenciales en el contexto original del atacante https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code.

Esto crea un «punto ciego» crítico en las operaciones del SOC: la evidencia que llega a la cola de análisis de Tier 1 puede ser incompleta, las decisiones de contención se retrasan y los atacantes ganan ventana para consolidar acceso, mover laterales y extraer datos. Los sectores más afectados, según el telemetraje de sandbox como ANY.RUN, incluyen consultoría, servicios financieros, manufactura y tecnología, donde la exposición a phishing reportada es superior al 65% en muchas verticales; un inicio de sesión comprometido en Microsoft 365 puede significar correo corporativo, archivos y flujos de trabajo comprometidos, así como riesgos de fraude y BEC.

La forma más práctica de cerrar ese punto ciego es llevar la inspección al navegador. Herramientas de sandboxing interactivo que capturan el DOM, XHR/Fetch y el tráfico detrás de escena permiten ver el momento exacto en que la carga cifrada se descifra, qué solicitudes backend lanza el código de dispositivo y qué endpoints se usan (por ejemplo, rastreando llamadas a /api/device/start y similares). ANY.RUN es un ejemplo de este enfoque interactivo, donde las sesiones reproducen la experiencia del usuario y generan evidencia accionable para la respuesta https://any.run/.

Para los líderes de seguridad esto implica reequilibrar controles: no basta con bloquear URLs sospechosas, hay que complementar con inspección en navegador y controles de identidad fuertes. Microsoft ya recomienda políticas de consentimiento y controles sobre aplicaciones OAuth; revisar y limitar qué aplicaciones pueden obtener permisos, bloquear consentimiento de aplicaciones de terceros por defecto y auditar permisos es básico para reducir el daño posible si un token se emite a un actor malicioso https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/secure-your-app-consent.

En términos operativos, hay medidas concretas y urgentes que deberían formar parte de la respuesta a este tipo de incidentes: aislar la sesión comprometida y revocar tokens y sesiones federadas desde Azure AD, eliminar consentimientos de aplicaciones no reconocidas, analizar los registros de Sign‑In y Audit para identificar cuándo y cómo se emitieron los tokens, y aplicar políticas de acceso condicional y MFA que dificulten la reutilización de credenciales o tokens robados. También es esencial conservar evidencia del DOM y de las solicitudes XHR para obtener indicadores de compromiso (dominios, endpoints, hashes) que permitan bloquear infraestructura relacionada y alimentar reglas de detección.

Más allá de la respuesta técnica, conviene ajustar procesos: dotar a Tier 1 de mayor visibilidad (capturas del navegador, resúmenes automatizados y IOCs) reduce la presión sobre analistas senior y acelera la contención; automatizar la generación de informes con contexto de la sesión evita pérdida de tiempo en reconstrucciones manuales y disminuye el coste operativo. Revisar playbooks para incluir pasos específicos frente a flujos de autorización OAuth/device code debe ser prioridad.

No todos los ataques cifrados son idénticos, pero el patrón se repite: contenido que escapa a los filtros tradicionales reaparece dentro del navegador y desencadena un flujo legítimo que otorga acceso. La protección efectiva combina restricciones de identidad y consentimiento, detección basada en comportamiento de navegador, y sandboxes que registren el DOM y las llamadas XHR para rastrear la cadena completa del ataque. Entender y capturar la fase en la que el HTML pasa de cifrado a ejecución es la diferencia entre un incidente contenido y uno que escala a fraude, pérdida de datos y respuesta costosa.

Para equipos que gestionan riesgos en entornos Microsoft 365, la prioridad inmediata es instrumentar controles de identidad y consentimientos, añadir inspección en navegador a la cadena de detección y establecer playbooks que incluyan revocación de tokens y auditoría de consentimientos. A la vez, conviene revisar el cifrado utilizado por los atacantes —por ejemplo, AES‑GCM es la técnica que oculta el payload en estas campañas— para entender por qué las soluciones basadas únicamente en URL o en contenido estático fallan https://en.wikipedia.org/wiki/Galois/Counter_Mode.

En resumen, EvilTokens y variantes similares no introducen una vulnerabilidad nueva en Microsoft, sino un vector operativo que explota la falta de visibilidad en el navegador y la confianza en flujos legítimos de autorización. La defensa pasa por trasladar la inspección al lugar donde ocurre el ataque: el DOM y las comunicaciones del navegador, apalancar sandboxes interactivas para obtener evidencia completa y endurecer políticas de consentimiento y acceso en la nube. Esa combinación reduce la ventana de exposición y evita que un único acceso a Microsoft 365 se convierta en un incidente mayor.