Interrumpida la infraestructura de EvilTokens; Microsoft informa de más de 12 000 buzones comprometidos

Según una investigación publicada por Microsoft el 22 de septiembre de 2026, EvilTokens facilitó campañas de fraude por correo electrónico empresarial (BEC) en las que se comprometieron más de 12 000 buzones en más de 10 000 organizaciones de todo el mundo. Estos son los resultados de la investigación de Microsoft, no cifras exactas de víctimas verificadas de forma independiente.

La interrupción no eliminó la amenaza

La Unidad de Delitos Digitales de Microsoft (DCU) afirmó que colaboró con socios para interrumpir la infraestructura utilizada para operar EvilTokens. BleepingComputer informó de que la intervención no llegó a desmantelar por completo la infraestructura y de que la amenaza sigue activa.

Según BleepingComputer, dos sospechosos fueron detenidos en el Reino Unido en el marco de la investigación sobre EvilTokens. The Record informó de que ambos fueron puestos posteriormente en libertad bajo fianza, mientras continúa la investigación policial.

Cómo se utiliza indebidamente el flujo de código de dispositivo

Microsoft afirma que los atacantes que utilizan EvilTokens pueden aprovechar de forma indebida el flujo legítimo de autenticación mediante código de dispositivo. El atacante inicia el flujo y envía un código al usuario mediante un señuelo de phishing. Si el usuario introduce el código, puede autorizar sin saberlo la sesión del atacante, lo que le permite a este acceder a la cuenta sin que se exponga la contraseña.

Otro conjunto de datos utiliza una medida distinta

El conjunto de datos de SpyCloud citado por BleepingComputer muestra más de 8 708 cuentas comprometidas en 6 585 dominios de correo electrónico corporativo de 79 países. Su alcance y su unidad de medida difieren de los del recuento de buzones de Microsoft, por lo que no debe considerarse una confirmación independiente de la cifra de más de 12 000.

Recomendaciones de Microsoft sobre el flujo de código de dispositivo

Microsoft recomienda bloquear el flujo de código de dispositivo siempre que sea posible. Para los dispositivos Teams que requieren este flujo, la empresa aconseja limitar la excepción a cuentas de recursos específicas para dispositivos Teams y excluir el recurso Device Registration Service de la política de Conditional Access correspondiente.