El 26 de octubre de 2026, The Hacker News publicó datos que atribuyó a Huntress: la empresa de seguridad vinculó 97 cuentas de Microsoft 365 comprometidas, en 79 organizaciones, con actividad observada entre el 14 de julio y el 22 de septiembre de 2026. La campaña recurrió a la reutilización de tokens de sesión y, según esos datos, también dejó cambios en métodos de autenticación, dispositivos de Microsoft Entra ID y reglas de correo.
Cómo se reutiliza un token después de la autenticación
Un token de sesión permite acceder a servicios después de que el usuario haya iniciado sesión. En el método de intermediario (AiTM), una página falsa retransmite las credenciales y los códigos de autenticación multifactor (MFA) a los servicios legítimos de Microsoft. Después, el atacante recoge el token emitido y lo reutiliza desde un dispositivo bajo su control. Como el token representa una sesión ya autenticada, su uso puede continuar sin repetir el reto inicial de MFA.
Huntress también señaló el phishing mediante el flujo de código de dispositivo y la ingeniería social durante un inicio de sesión legítimo como posibles vías para obtener tokens.
Los cambios de acceso y correo que se comunicaron
Huntress informó de 497 inicios de sesión correctos entre más de 200.000 intentos. También registró 48 dispositivos no autorizados en Microsoft Entra ID. En al menos 19 organizaciones, los atacantes habrían eliminado métodos MFA existentes y registrado otros nuevos en las tres horas siguientes al primer inicio de sesión. En un caso del 21 de julio, se activó un autenticador llamado «iPhone 13» menos de 51 minutos después del secuestro de una sesión.
Las reglas ocultas de correo desviaban o eliminaban mensajes sobre nóminas, depósitos y bonificaciones. En un buzón, una regla marcaba como leídos y eliminaba todos los mensajes entrantes. La cuenta se utilizó después para enviar spam a cientos de destinatarios, antes de que Microsoft Entra ID Protection la clasificara como de alto riesgo.
Qué cubre Microsoft Token Protection
Microsoft Token Protection, configurado mediante Conditional Access, vincula criptográficamente al dispositivo los tokens de actualización compatibles. La guía de Microsoft exige un token de actualización principal (Primary Refresh Token, PRT) y describe compatibilidad con aplicaciones nativas de Windows que se conectan a Teams, SharePoint y Exchange. Los dispositivos no registrados que carecen de PRT quedan fuera del escenario descrito en esa guía.
Por tanto, Token Protection no cubre todos los dispositivos y aplicaciones. Para otros escenarios, Microsoft recomienda combinar medidas como reforzar los dispositivos, exigir dispositivos compatibles mediante Conditional Access, vigilar el riesgo de identidad y usar controles de red. También aconseja restringir el flujo de código de dispositivo cuando no sea necesario, ya que puede utilizarse en campañas de phishing o para acceder a recursos corporativos desde dispositivos no gestionados. Los requisitos de licencia varían según el control.
La guía de Microsoft sobre protección de tokens detalla el alcance de Token Protection y otras medidas de defensa. El vídeo de Microsoft Mechanics aporta contexto general sobre el robo de tokens y muestra una configuración de Token Protection; no trata la campaña descrita.
Qué revisar ante un inicio de sesión sospechoso
Una ubicación inusual, por sí sola, no demuestra que se haya robado un token. Una respuesta en un foro técnico recomendó revisar los detalles de autenticación para comprobar si MFA se había solicitado de nuevo o figuraba como «previamente satisfecha», y comparar el identificador del dispositivo con uno conocido. Es una orientación de foro, no un diagnóstico de una cuenta concreta.
Microsoft enumera detecciones de riesgo como «Anomalous Token», «Attacker in the Middle» y «Unfamiliar sign-in properties». Si se sospecha una intrusión, Huntress recomendó revocar las sesiones y restablecer la contraseña, revisar los dispositivos de Entra ID y los métodos MFA, inspeccionar las reglas de entrada y las aplicaciones empresariales inesperadas, y limitar el flujo de código de dispositivo mediante Conditional Access.
