Knight Office: cómo el phishing AiTM roba sesiones de Microsoft 365 tras la MFA

Knight Office deja una lección operativa clara: la autenticación multifactor (MFA) valida un inicio de sesión, pero no protege automáticamente cada sesión que se crea después. En el incidente documentado por Huntress, una cadena de phishing adversary-in-the-middle (AiTM, adversario en el medio) capturó material de sesión de Microsoft 365 y, a continuación, se produjo el registro no autorizado de un dispositivo en Microsoft Entra ID. Por eso debe tratarse como un compromiso de identidad, no como un simple robo de contraseña. 640

Así funciona la cadena de ataque de Knight Office

La secuencia observada comenzó con un correo de phishing con apariencia de DocuSign. El enlace pasaba por un servicio de seguimiento de Monday.com y después por un sitio Joomla comprometido, una cadena diseñada para ocultar el destino final a los controles de reputación y a una inspección básica de enlaces. 6

En la fase de aterrizaje, un flujo convincente que imita la colaboración o el inicio de sesión de Microsoft puede pedir a la víctima que continúe la autenticación, incluso mediante una interacción similar a un código de dispositivo. El propósito es lograr que la persona apruebe un flujo de autenticación que parece legítimo.

El componente AiTM se comporta como un proxy inverso entre la víctima y el servicio real de inicio de sesión de Microsoft:

1. La víctima introduce sus credenciales y completa el desafío habitual de MFA.
2. El proxy transmite esas interacciones a Microsoft en tiempo real.
3. Cuando la autenticación tiene éxito, el atacante captura la cookie de sesión autenticada u otro material de token que recibe el navegador.
4. El atacante reutiliza ese estado autenticado desde su propia infraestructura para acceder a la cuenta.

Esto no significa que se haya roto la criptografía de la MFA. Significa que se robó el estado de autorización emitido después de superar la MFA. Microsoft define el robo de tokens como el compromiso y la reutilización de tokens emitidos para un usuario que puede haber completado ya la autenticación multifactor. 40

Por qué cambiar la contraseña puede no expulsar al atacante

Una sesión de navegador robada o un acceso derivado de un token de actualización puede permitir que el intruso siga operando sin otra petición de contraseña ni desafío de MFA hasta que se revoquen los tokens relevantes. La guía de Microsoft sobre robo de tokens recomienda explícitamente bloquear a los usuarios o dispositivos afectados y revocar los tokens actuales. 40

Knight Office eleva el riesgo porque la actividad posterior al compromiso incluyó el registro de un equipo no autorizado en Microsoft Entra ID y la configuración de credenciales de Windows Hello para Empresas controladas por el atacante. 6 Esto puede abrir una vía de autenticación independiente: incluso tras revocar la sesión web original o restablecer la contraseña, el equipo de respuesta debe comprobar que no persista ningún dispositivo no autorizado ni método de autenticación nuevo.

La misma idea de persistencia se ha documentado en investigaciones sobre phishing con código de dispositivo. Microsoft informó de que un token de actualización obtenido mediante el abuso de ese flujo puede utilizarse para solicitar acceso al servicio de registro de dispositivos e inscribir en Entra ID un dispositivo controlado por el atacante. 28

El phishing con código de dispositivo está relacionado, pero no es lo mismo que AiTM

El phishing AiTM intermedia un inicio de sesión en directo y roba la sesión resultante. El phishing con código de dispositivo, en cambio, abusa de un flujo legítimo de autorización de dispositivos de OAuth: el atacante inicia una solicitud de código, convence a la víctima para que introduzca ese código y se autentique, y obtiene tokens para el cliente que controla si la víctima aprueba la operación. 22

Ambas técnicas desplazan el objetivo del atacante: ya no se limita a recolectar contraseñas, sino que busca artefactos de autorización utilizables. Los programas de detección deben cubrir ambas rutas. La guía de Elastic para detectar este abuso destaca inicios de sesión interactivos correctos en Entra con el protocolo de código de dispositivo, el cliente Microsoft Authentication Broker y solicitudes a recursos propios como Exchange Online, Microsoft Graph o SharePoint. 17

Actividad observada y el contexto del phishing como servicio

La investigación de Huntress estableció una secuencia real de intrusión de Knight Office: un señuelo documental, redirecciones en varios saltos, captura de tokens de sesión y registro no autorizado de un dispositivo en Entra. Huntress también vinculó repetidas reutilizaciones de tokens de su telemetría a una misma dirección IP, pero esa observación no debe interpretarse como un recuento mundial de víctimas. 6

Knight Office encaja además en un mercado más amplio de kits de phishing como servicio —PhaaS, por sus siglas en inglés— dirigidos a sesiones de identidad de Microsoft 365:

• Mirage2FA utiliza infraestructura AiTM para capturar credenciales y sesiones autenticadas. ANY.RUN notificó 9.332 eventos potenciales de compromiso entre 2024 y 2026, incluidos 4.561 eventos de robo de cookies. Son eventos potenciales basados en telemetría, no una cifra de víctimas confirmadas. 4
• Kali365, visto por primera vez en abril de 2026 y distribuido principalmente a través de Telegram, fue objeto de una alerta del FBI por su capacidad para obtener tokens de acceso y de actualización OAuth de Microsoft 365. 1

La conclusión defensiva es directa: el abuso de sesiones y tokens debe prevenirse, detectarse y responderse con el mismo rigor que un compromiso de contraseña.

Prioridades de detección en Entra ID y Microsoft 365

La clave es correlacionar señales, no depender de una única alerta.

1. Buscar reutilización sospechosa de sesiones

Investigue inicios de sesión en los que una misma cuenta o sesión aparece desde direcciones IP, redes, ubicaciones geográficas, navegadores o propiedades de dispositivo claramente distintos en un periodo breve, especialmente justo después de una MFA correcta. Microsoft dispone de detecciones para uso anómalo de tokens y propiedades de inicio de sesión desconocidas asociadas a cookies de sesión. 38

2. Investigar actividad anómala de código de dispositivo

Revise autenticaciones correctas mediante código de dispositivo y determine si el cliente, la IP de origen, el recurso solicitado y el comportamiento del usuario son coherentes. En los registros de inicio de sesión de Entra, esta actividad puede identificarse mediante campos como authenticationProtocol: deviceCode y originalTransferMethod: deviceCodeFlow. 26

3. Vigilar cambios que permitan persistencia

Dé prioridad a los eventos de auditoría de Entra relacionados con:

• Nuevos registros o incorporaciones de dispositivos, cambios de propiedad o identificadores de dispositivo inusuales.
• Nuevos métodos de Windows Hello para Empresas, FIDO2/llaves de acceso, MFA o recuperación de cuenta.
• Concesiones de consentimiento a aplicaciones, cambios en aplicaciones empresariales, entidades de servicio o asignaciones de roles con privilegios.
• Cambios en Acceso condicional, ubicaciones con nombre, federación, reenvío de correo o reglas de bandeja de entrada.

Un registro no autorizado de dispositivo poco después de una autenticación sospechosa debe tratarse como una señal prioritaria de persistencia en la identidad. 2628

4. Correlacionar evidencia de correo e identidad

Un correo con temática de DocuSign puede ser simplemente spam y un dispositivo nuevo en Entra puede ser legítimo. Pero la combinación de un mensaje sospechoso, evidencia de la cadena de redirecciones, una MFA correcta, reutilización anómala de sesión y un cambio en un dispositivo o método de autenticación es mucho más accionable.

Respuesta al incidente: contener la identidad, no solo la contraseña

Ante una sospecha de robo de tokens mediante AiTM o código de dispositivo, utilice un flujo de contención de identidad:

1. Bloquee o deshabilite la identidad afectada cuando sea necesario. Deshabilite las cuentas de usuario y dispositivo afectadas mientras determina el alcance. 40
2. Revoque las sesiones actuales y los tokens de actualización. Aplique el proceso de revocación de sesiones de inicio de sesión de Entra y fuerce una nueva autenticación. Para incidentes de phishing con código de dispositivo, Microsoft recomienda revocar los tokens de actualización con revokeSignInSessions. 27
3. Restablezca las credenciales, pero no se detenga ahí. Cambiar la contraseña es una medida complementaria, no una prueba de que el atacante haya perdido el acceso. 4042
4. Elimine la persistencia. Identifique y retire dispositivos no autorizados de Entra; revise su propiedad; elimine credenciales añadidas recientemente de Windows Hello para Empresas, FIDO2, MFA, recuperación y aplicaciones; y examine las concesiones de consentimiento. 628
5. Busque actividad en todo el tenant. Busque URL de señuelos, infraestructura de redirección, IP de origen sospechosas, eventos de código de dispositivo, anomalías de inicio de sesión posteriores a MFA y registros de nuevos dispositivos en todos los usuarios.
6. Evalúe el impacto de negocio. Revise la actividad de Exchange, SharePoint, OneDrive, Teams, Microsoft Graph, OAuth y auditoría administrativa en busca de acceso a datos, reglas de correo, reenvíos, compartición externa, abuso de consentimiento, cambios de privilegios y accesos a aplicaciones conectadas por SSO.
7. Conserve evidencias antes de limpiar. Retenga los mensajes de phishing y sus cabeceras, trazas de correo, cadenas de redirección, registros de inicio de sesión y auditoría de Entra, registros de dispositivos, datos de consentimiento OAuth y telemetría de navegador o endpoint.

Reducir la exposición antes del próximo señuelo

La autenticación resistente al phishing es un control importante para usuarios de alto riesgo, pero debe formar parte de una defensa por capas. Microsoft recomienda métodos como las llaves de seguridad FIDO2, Windows Hello para Empresas y la autenticación basada en certificados, junto con controles que reduzcan la vida útil de las sesiones en dispositivos no administrados. 39

También conviene evaluar si el flujo de código de dispositivo es necesario en el entorno, restringir el registro no autorizado de dispositivos, aplicar Acceso condicional según dispositivos conformes y riesgo, y asegurarse de que el equipo de operaciones pueda revocar sesiones e investigar rápidamente cambios en los objetos de identidad.

La lección central de Knight Office no es que la MFA haya fracasado. Es que una MFA correcta puede ser el inicio del compromiso cuando el atacante roba la sesión que viene después. La respuesta solo estará completa cuando se hayan revisado y contenido las sesiones, los dispositivos, los métodos de autenticación y los accesos delegados del tenant.