Fuga de Datos en Servidor de Phishing: El Origen de las Campañas Evilginx

Un error de configuración en un servidor utilizado por ciberdelincuentes ha permitido a la firma de seguridad Lexfo descubrir y analizar tres campañas de phishing distintas. Estas campañas utilizan el framework Evilginx para atacar cuentas de Microsoft 365. El servidor, que tenía el listado de directorios activado, expuso las herramientas, configuraciones y registros de los operadores. Ofreció una visión sin precedentes del funcionamiento interno de la infraestructura de phishing como servicio.

Las Tres Variantes de Evilginx en la Operación

El análisis de Lexfo reveló tres forks personalizados de Evilginx, cada uno con su propio estilo y método de ataque:

1. codemado (picis[.]net). La campaña más «ruidosa», que utilizaba un Evilginx estándar para el phishing de credenciales. El operador, un actor egipcio, también había desarrollado un mailer llamado «MaDoO Blaster» para monetizar el acceso.
2. mail-argenta (red-queen). Un fork más pulido que añadió un motor de reescritura de URLs y modificó atributos HTML para evadir la detección. El operador fue identificado a través de sus propias credenciales filtradas en logs de infostealers.
3. saroula01 (black-queen). La campaña más sigilosa y de mayor duración (más de un año). Esta campaña phishing Evilginx Microsoft 365 se basaba en una técnica más avanzada. Abusa del flujo de código de dispositivo de OAuth de Microsoft.

Ataque de Código de Dispositivo OAuth: La Nueva Frontera del Phishing

La variante black-queen de esta campaña phishing Evilginx Microsoft 365 no robaba contraseñas. En su lugar, generaba un código de dispositivo legítimo de Microsoft y lo presentaba a la víctima en una página de phishing con temática de «Autenticador». La víctima, al introducir el código en el sitio real de Microsoft (microsoft.com/devicelogin), autenticaba la sesión del atacante, otorgándole un token de acceso sin necesidad de que el atacante tuviera sus credenciales.

Esta técnica, conocida como «EvilTokens», es particularmente peligrosa porque:

• Elude el MFA de forma nativa, ya que la víctima completa el desafío de autenticación en la infraestructura genuina de Microsoft.
• No puede ser bloqueada por FIDO2 o passkeys, ya que el origen de la autenticación es legítimo.
• Los tokens robados pueden ser refrescados automáticamente, manteniendo el acceso del atacante durante meses.

Lecciones de una Campaña de Phishing a Gran Escala

La exposición de esta campaña phishing Evilginx Microsoft 365 ofrece lecciones cruciales para los defensores:

1. Bloquear el flujo de código de dispositivo. Microsoft recomienda bloquear este flujo mediante Conditional Access en la mayoría de los entornos, excepto en aquellos que lo necesiten para dispositivos sin entrada (como salas de Teams).
2. Monitorizar el ID de cliente de Office. Buscar en los logs de inicio de sesión el ID de cliente d3590ed6-52b3-4102-aeff-aad2292ab01c (el de Microsoft Office) en contextos donde no se use este cliente, puede indicar un ataque de código de dispositivo.
3. Revisar el campo «Original transfer method». Para detectar sesiones iniciadas por código de dispositivo, hay que buscar en el campo «Original transfer method» de los logs de Entra ID, ya que las sesiones posteriores pueden no mostrar el método original.
4. Monitorear la instalación de RMM. Los operadores de estas campañas suelen instalar herramientas de acceso remoto como XEOX para mantener la persistencia.

El simple error de configuración que expuso todo el operativo subraya que, incluso los atacantes, pueden cometer errores. La lección más importante es que defender un entorno Microsoft 365 hoy requiere ir más allá del simple MFA y comprender los flujos de autenticación más oscuros.