Dentro de Knight Office, un nuevo kit de phishing AiTM para Microsoft 365

Agradecimientos: un agradecimiento especial a Tanner Filip, Susannah Matt, Truman Kain y Rich Mozeleski por sus contribuciones a esta investigación y artículo. 

Mientras investigaban un ataque AiTM contra una organización el 18 de agosto de 2026, los investigadores de Huntress se encontraron con la consola de un kit de phishing llamado Knight Office. 

El incidente siguió la estructura de un ataque AiTM estándar: comenzó con un correo de phishing con estilo DocuSign que incluía un enlace de redirección que pasaba por un servicio de seguimiento de Monday.com y enviaba a la víctima a un sitio Joomla comprometido, como forma de ocultar la página de destino final del phishing ante los escáneres de reputación y los analistas que inspeccionaban el correo. Estas redirecciones allanaron el camino para el ataque AiTM en sí, donde el atacante pudo capturar los tokens de sesión de la víctima. Tras obtener el acceso inicial, el actor de amenazas inscribió un dispositivo no autorizado en Microsoft Entra ID, completó un registro de dispositivo fraudulento controlado por el atacante, y vinculó una credencial de clave de Windows Hello for Business (WHfB) a la cuenta. 

Durante las primeras detecciones de este incidente, la telemetría de Huntress identificó que la dirección IP 104.37.188[.]94 estaba vinculada a repeticiones de tokens robados durante el incidente. Un analista del Centro de Operaciones de Seguridad de Huntress (SOC) buscó esta dirección IP en Validin y encontró la consola de administración del operador de phishing para Knight Office. Mientras tanto, al inspeccionar la IP en sí a través de Validin y VirusTotal, se revelan al menos 25 dominios web con un dominio de nivel superior .vu usados para alojar los sitios de phishing.

Como se ve en la Figura 1, la consola en sí (Login — KNIGHT OFFICE) presume varias funciones: "Capture & Management from Single place", "Webmail access & auto-refresh", "Deploy custom links" y "Real-time visitor statistics". La aplicación web del lado del servidor del atacante fue creada con Python Flask (con el complemento Flask-WTF) e incluye un Cloudflare Turnstile. 

Figura 1: La consola de Knight Office

Una distinción importante: nuestros investigadores descubrieron la consola de Knight Office, que es el panel orientado al operador construido sobre el código fuente del kit subyacente. Esta es la página de inicio de sesión de la interfaz web donde los atacantes pueden monitorear sesiones de víctimas en vivo, ver credenciales capturadas y exportar datos robados. Esto es distinto del código fuente en sí, que proporciona la mayoría de los componentes orientados a la víctima de los kits, como las plantillas HTML usadas en los ataques de phishing, los scripts de captura de credenciales, y más. 

Por ello, durante nuestra investigación usamos nuestra propia telemetría de detección del ataque AiTM inicial, además de OSINT de plataformas externas como Validin y VirusTotal, para entender mejor cómo funcionaba la cadena de ataque vinculada al kit, investigar la IP que alojaba la consola, y encontrar dominios relacionados y otra infraestructura. 

También queda claro que este ataque no es phishing aislado;  una revisión de la telemetría de Huntress usando esta IP reveló que al menos nueve inicios de sesión con repetición de tokens en identidades se han vinculado a este kit durante las últimas dos semanas. La telemetría interna también muestra que cientos de correos con la misma plantilla de mensaje usada en este ataque se han reportado a través de la plataforma de Huntress Security Awareness Training (SAT) desde abril.  A continuación, un desglose del ataque. 

Figura 2: Desglose del ataque basado en la telemetría de detección y OSINT de VirusTotal  

Un ataque AiTM de agosto abre la puerta  

El 18 de agosto, el SOC respondió a una actividad de autenticación sospechosa vinculada a una cuenta de Microsoft 365. La actividad consistió en dos eventos de autenticación posteriores a MFA contra la aplicación Microsoft Authentication Broker. La aplicación provenía de una IP (73.125.13[.]x) registrada a Comcast Cable Communications, pero marcada por la empresa de inteligencia de IP Spur como un proxy de devolución de llamada que se ha asociado con múltiples operadores de reventa de proxies (por ello, hemos ocultado esta IP en este blog). 

La IP ofreció la primera pista de que el empleado había sido blanco de un ataque AiTM. Las IP de proxy de devolución de llamada revelan una ruptura en la conexión normal uno a uno entre los usuarios y los proveedores de identidad. Mientras que los inicios de sesión legítimos muestran IP consistentes en los pasos de inicio de sesión y de devolución de llamada del token, en un AiTM, un kit de phishing con proxy inverso se ubica entre la víctima y el servicio real, como forma de que los actores de amenazas retransmitan credenciales y MFA en tiempo real. La solicitud inicial puede mostrar la IP de la víctima, pero la devolución de llamada donde en realidad se emite el token se completa a través de un servidor proxy del atacante, por lo general con una IP sin relación con la ubicación de la víctima, como ocurrió en este incidente.

Nuestra investigación adicional sobre el incidente reveló más detalles sobre la cadena de ataque.

El señuelo

Obtuvimos el correo señuelo inicial mientras investigábamos este incidente. Como se ve en la Figura 3, el actor de amenazas inició este incidente al enviar un correo con estilo DocuSign con una línea de asunto urgente que pedía completar una firma: Reminder: Signature Required - Approval Pending Your Review!!! Ref ID-<random> 

El señuelo usó una técnica de autosuplantación, que consiste en falsificar un correo de phishing para que parezca provenir de la propia dirección del destinatario (a través de los encabezados From, To y Return-Path).

Figura 3: El correo señuelo detrás del ataque AiTM

Al revisar nuestra telemetría de SAT, que recopila datos sobre correos de phishing reportados por los clientes, encontramos al menos 700 correos reportados desde abril con varias variaciones de este señuelo, línea de asunto y plantilla.

Externamente, el señuelo de phishing también parecía ser frecuente. En este ataque específico, la IP del remitente del correo inicial vinculada al correo era 154.127.53[.]78. 

Una inspección más detallada de esta dirección IP en VirusTotal mostró 14 mensajes de correo adicionales, todos relacionados con el correo original tanto por el contenido del correo (las líneas de asunto siguen un patrón) como por la página de phishing final. Cada uno de los mensajes contenía enlaces que apuntaban a sitios web diferentes que redirigían el navegador del usuario a una de un número menor de URL finales donde se alojan las páginas de phishing.

Las líneas de asunto de estos mensajes incluían:

• Reminder: Signature Required - Approval Pending Your Review!!! REF-ID [10 letras aleatorias]

• You Missed (2) lmportant VoiceMessage; Please Review Now!!! REF - [10 letras aleatorias]

• Sjc Shared an lmportant Document with you that required your Attention and Slgnature!! - REF - [10 letras aleatorias]

• VERlVIED: Caller left [dígitos aleatorios] minutes [dígitos aleatorios] seconds REF - [10 letras aleatorias]

• lmportant: (3) Playback-MSG Arrived from [nombre] - Listen Now

Vale la pena notar la sustitución de la letra minúscula "L" en lugar de la letra "i" en palabras como lmportant, Slgnature, y VERlVIED como una característica distintiva de esta campaña, además del uso frecuente de signos de exclamación.

Las páginas de "inicio de sesión"

Al revisar la telemetría de detección de Huntress del ataque AiTM, los investigadores obtuvieron más información sobre la siguiente fase de este ataque. El mensaje "Review Button" en el correo llevaba a un enlace malicioso. Este enlace de redirección pasaba por un dominio de la plataforma de gestión de trabajo Monday. Luego, el objetivo era redirigido a un sitio de Joomla comprometido. Sin embargo, cuando los investigadores de Huntress inspeccionaron esta página de Joomla comprometida, ya había sido dada de baja.

Como esta cadena de ataque inicial ya no funcionaba, investigamos el correo de spam original y usamos los correos encontrados a través de VirusTotal (detallados en la sección anterior) para rastrear copias de un mensaje similar que enlazaba a la misma URL. A través de esto, determinamos cómo los actores de amenazas probablemente lanzaron la siguiente fase del ataque: a las víctimas se les mostraba una página que afirmaba ser un mensaje de Microsoft SharePoint o Teams. La página sugería que había un documento (en el caso de la versión de SharePoint) o un mensaje de voz (en el caso de la versión de Teams) para que los objetivos descargaran.

Figura 4: La página de phishing le presenta al visitante un código de autenticación de dispositivo. Si el visitante ingresa este código e inicia sesión en su cuenta de Microsoft, le da al actor de amenazas acceso a la computadora del objetivo.

La página les da a los objetivos un código de verificación para copiar y les indica "Sign In With Microsoft", tras lo cual se les presenta la página de la Figura 5.

Figura 5: La página de phishing abre una nueva pestaña con la ventana de inicio de sesión de Microsoft para códigos de autenticación de dispositivo, y sus instrucciones le piden al objetivo pegar el código en el formulario. El formulario irónicamente indica: no ingreses códigos de fuentes en las que no confías.

Esta siguiente página abre una nueva pestaña en el navegador con la pantalla de inicio de sesión "deviceauth" de Microsoft. Si el objetivo sigue las instrucciones de la página anterior y pega el código de nueve letras deviceauth en el formulario, y hace clic en Next, la página le pide al objetivo ingresar sus credenciales de Microsoft y completar la solicitud push de MFA que sigue (a través de Microsoft Authentication Broker / OfficeHome).

Figura 6: Después de ingresar el token de autenticación de código de dispositivo, se le pide al objetivo iniciar sesión con sus credenciales, incluyendo MFA si la tiene configurada.

el relay. Detrás de escena, los tokens de sesión capturados se enviaban luego a la consola del operador del actor de amenazas.

En este punto, las piezas del rompecabezas empezaron a encajar cuando revisamos el ataque AiTM inicial. La telemetría de Huntress mostró que los tokens robados se reproducían desde los rangos de hosting del centro de datos mediante el User-Agent predeterminado python-requests/2.34.2, OAuth2:Token. 

Como el operador usó tokens de sesión pre-validados, pudo evadir los controles de autenticación sin activar alertas de detección basadas en contraseñas en el equipo del usuario. Los registros de autenticación mostraron cero intentos de contraseña incorrecta, y los demás intentos fallidos observados se debieron únicamente a tokens vencidos o claves de dispositivo faltantes.

Intentos de inicio de sesión y persistencia

Después de obtener los tokens de sesión, el actor de amenazas registró un dispositivo no autorizado desde 104.37.188[.]94 y luego hizo dos intentos de autenticación de token OAuth 2.0 usando los tokens de sesión reproducidos, pero ambos fallaron porque la clave NGC requerida aún no estaba disponible. La clave NGC se usa para la función de autenticación sin contraseña Windows Hello for Business (WHfB).

Poco después, el actor de amenazas inscribió un equipo no autorizado en Microsoft Entra ID y completó el registro de un dispositivo fraudulento controlado por el atacante.

Luego, vinculó una credencial de clave WHfB a la cuenta (identificada mediante Dsreg/10.0 (Windows 10.0.19044.1826). Si bien WHfB suele brindar una autenticación sin contraseña sólida para usuarios legítimos, si un atacante inscribe su propia clave puede recuperar fácilmente el acceso después de que se revoquen los tokens existentes de una cuenta. 

El actor de amenazas luego volvió a iniciar sesión, esta vez con éxito, usando la autenticación sin contraseña de WHfB.

AiTM y kits de phishing

Knight Office es solo uno de los muchos kits de phishing que hemos visto que apuntan específicamente a tokens de sesión válidos en un esfuerzo por eludir MFA. Aunque el panel de control se veía simple, solo era parte de una cadena de ataque más amplia que usaba infraestructura de redirección confiable, sitios web comprometidos y proxies de retransmisión residenciales para lanzar un ataque AiTM. Una vez que la víctima completaba MFA, sin saberlo le entregaba al atacante un token de sesión válido, con lo cual el enfoque pasaba de robar contraseñas a abusar de un acceso ya autenticado.

Al igual que muchos otros kits de phishing que hemos visto durante el último año (como EvilTokens, Kali365, y otros), el ataque vinculado a Knight Office se basa en AiTM, que se ha vuelto popular porque evade MFA. En lugar de solo robar contraseñas, AiTM roba tokens de sesión después de que el usuario real completa MFA, lo que da a los atacantes sesiones válidas, persistentes y ya autenticadas. 

Para quienes se encargan de la defensa, ataques AiTM como estos exigen mirar más allá de los inicios de sesión fallidos y la actividad sospechosa de contraseñas: 

• Detectar autenticación inesperada posterior a MFA desde proxies de retransmisión, y los inicios de sesión asociados con dispositivos desconocidos, puede ayudar a exponer el robo de tokens de autenticación de sesión.  

• Revisar los dispositivos de Microsoft Entra recién registrados y las credenciales de Windows Hello for Business. 

• Eliminar los métodos de autenticación no autorizados.

• Deshabilitar cualquier cuenta sincronizada en sistemas de identidad on-premises. 

Relacionado: otra forma de robar sesiones de Microsoft 365. Kits como Knight Office capturan sesiones mediante una página de inicio de sesión falsa. El phishing mediante código de dispositivo logra el mismo resultado usando el inicio de sesión real de Microsoft. Mira una demostración en vivo.

Indicadores de compromiso (IOC)