El 18 de agosto de 2026, investigadores de Huntress que investigaban un ataque de adversario en el medio (AiTM) se toparon con la consola del operador detrás de él: un kit de phishing que su autor llama Knight Office. Solo dentro de la base de clientes de Huntress, esa misma consola se ha vinculado a al menos nueve brechas confirmadas en cuentas de Microsoft 365 y Google Workspace en un lapso de dos semanas. Ampliando el rastro, los investigadores encontraron más de 700 correos con variaciones del mismo señuelo, línea de asunto y plantilla desde abril. Nada de ese volumen necesitó falsificar el dominio que decía proteger. Falsificó algo más simple: al destinatario.
Un Señuelo Dirigido de Ti, Para Ti
El primer movimiento de Knight Office es un truco de encabezados, no un truco de DNS. El correo de phishing falsifica sus campos From, To y Return-Path para que el mensaje parezca haber sido enviado desde la propia dirección del destinatario, hacia la propia dirección del destinatario, un correo autodirigido que llega a una bandeja que nunca lo envió. Encima de eso hay una solicitud de firma con estilo DocuSign y una línea de asunto urgente, y los investigadores encontraron variantes que sustituyen una “l” minúscula por una “i” en palabras como “Important” y “Signature”, un cambio lo bastante pequeño para pasar filtros de spam basados en coincidencia de palabras clave mientras se sigue leyendo correctamente a un ojo apresurado. Hacer clic no lleva a la víctima directamente a una página de inicio de sesión falsa. Primero la enruta a través de Monday.com, una plataforma legítima de gestión de trabajo, luego a través de un sitio web Joomla comprometido, antes de finalmente aterrizar en la página construida para robar algo real.
El Código de Dispositivo Es Todo el Ataque
Esa página final imita el flujo de inicio de sesión por código de dispositivo de Microsoft, el mecanismo legítimo que la gente usa para autorizar un televisor, una herramienta de línea de comandos, u otro dispositivo que no puede aceptar fácilmente una contraseña escrita. La víctima introduce el código que se le muestra, completa su inicio de sesión normal exactamente como lo haría cualquier día sin nada especial, incluyendo su propio paso de MFA, y al hacerlo entrega a Knight Office un token de sesión activo y completamente autenticado. No se hizo phishing de ninguna contraseña. No se venció ningún aviso de MFA. El kit nunca necesitó ninguno de los dos, porque un token de sesión válido ya lleva ambas cosas consigo.
Una Puerta Trasera Construida a Partir de una Función de Seguridad
Robar el token no es donde Knight Office se detiene. Huntress descubrió que, una vez dentro, los atacantes registran un dispositivo no autorizado y controlado por el atacante contra el inquilino de Microsoft Entra ID de la víctima, y vinculan una credencial de Windows Hello for Business sin contraseña a la cuenta comprometida. Ese único paso convierte una función pensada para hacer más seguro el inicio de sesión en una vía de regreso: incluso después de que se revoque el token de sesión robado original, la credencial WHfB vinculada por el atacante sigue funcionando, porque nunca estuvo atada al robo que fue detectado. La señal de alerta es lo bastante específica para buscarla: una nueva inscripción de dispositivo y una credencial de clave WHfB recién creada que aparece poco después de la repetición de un token de sesión desde una IP desconocida no es la forma en que un usuario legítimo se vuelve a autenticar.
Por Qué DMARC Nunca Fue la Capa Que Vigilaba Esto
DMARC responde a una pregunta acotada: ¿está este mensaje autorizado, mediante alineación de SPF o DKIM, a reclamar el dominio en su encabezado From? El correo inicial de Knight Office sí reclama un dominio, técnicamente, ya que la dirección From falsificada tiene que resolver a algo. Pero el truco que hace el trabajo real aquí no es la suplantación de dominio en el sentido que DMARC fue construido para vigilar. Es una señal de confianza dirigida a la persona que lee el mensaje y, tan a menudo, a la pila de seguridad de correo detrás de ella. Muchas configuraciones antiphishing aplican su escrutinio más agudo al correo que dice venir del dominio de otra persona, y lo relajan con los mensajes que parecen originarse dentro del propio inquilino del destinatario, bajo la suposición de que el correo intra-dominio es más seguro por defecto. Un mensaje falsificado para parecer autoenviado puede pasar de largo esa suposición, frente a un filtro afinado para vigilar las salidas, no el espejo.
Esta es una brecha distinta a las que este blog ya ha recorrido, la ruta de retransmisión anónima cerrada al rechazar Direct Send, o la etiqueta SCL:-1 en lista de confianza que hace pasar correo suplantado sin pasar por la aplicación antiphishing en absoluto. Knight Office no necesita ninguna de las dos. Necesita que la propia dirección de un destinatario se sienta segura de ver en su propia bandeja de entrada, y una página de código de dispositivo lo bastante convincente para hacer que entregar una sesión activa se sienta rutinario.
Qué Significa Esto Para Tu Programa
Trata “el remitente coincide con mi propio dominio” como una señal para verificar, no como una razón para relajarte. Si tu política antiphishing o tu puerta de enlace de correo seguro le da al correo intra-dominio una revisión más ligera que al correo externo, esa configuración es exactamente lo que un señuelo autofalsificado está construido para explotar. La protección contra suplantación de dominio necesita cubrir mensajes que dicen venir de tu propio inquilino, no solo de dominios similares al de otra persona.
Entrena a las personas para desconfiar de los avisos de código de dispositivo que no iniciaron ellas mismas. Un inicio de sesión por código de dispositivo solo debería seguir a una acción que el propio usuario acaba de realizar en un dispositivo nuevo. Un código que aparece tras hacer clic en un enlace de un correo no es eso, y vale la pena hacer esa distinción tan explícita y repetida como cualquier advertencia de phishing de contraseñas.
Busca el patrón de persistencia, no solo el clic inicial. Un nuevo registro de dispositivo y una credencial de Windows Hello for Business recién vinculada tras la repetición de un token de sesión desde una IP no reconocida es una secuencia específica y detectable. Revocar un token de sesión robado sin verificar si hay un registro de dispositivo no autorizado detrás deja en pie la puerta trasera real.
Recuerda que DMARC protege el dominio, no la decisión de entrega. Un dominio puede tener una política DMARC estricta de manual y aun así ver llegar phishing, porque DMARC nunca fue posicionado para evaluar la cadena de redirecciones de un mensaje, su página de código de dispositivo, o las heurísticas de confianza intra-inquilino que tu plataforma de correo aplica antes incluso de que se consulte tu política.
La Conclusión
Knight Office no necesitó romper SPF, DKIM ni DMARC para llegar a 700 bandejas de entrada y al menos nueve compromisos confirmados. Necesitó un truco de encabezados que se lee como familiar, una cadena de redirecciones que parece tráfico web ordinario, y una página de código de dispositivo construida para capturar un token de sesión a su paso. DMARC hizo su trabajo en cada uno de esos mensajes, evaluando exactamente lo que fue construido para evaluar. El ataque simplemente entró por una puerta que ese trabajo nunca tuvo asignada vigilar.
DMARC te dice si un mensaje está autorizado a reclamar tu dominio. No puede decirte si tu propia plataforma de correo está confiando silenciosamente en mensajes que solo parecen venir de dentro de tus paredes. Excello Mail te da visibilidad continua y en lenguaje claro sobre tu postura de autenticación real, para que sepas exactamente dónde termina la cobertura de DMARC y dónde debe empezar el resto de tu defensa. Regístrate gratis en Excello Mail y mira hoy tu imagen de autenticación real.