El 14 de abril de 2026, una campaña de phishing comenzó a llegar a las bandejas de entrada de sistemas de salud, bancos, bufetes de abogados y empresas tecnológicas en 26 países. El 16 de abril, había terminado. En esas 48 horas, el equipo de inteligencia de amenazas de Microsoft había registrado más de 35.000 usuarios objetivo en más de 13.000 organizaciones. El 92% se encontraba en Estados Unidos.
Microsoft publicó su análisis el 4 de mayo de 2026. La campaña utilizó infraestructura de adversario en el medio (AiTM, por sus siglas en inglés) para capturar tokens de sesión en tiempo real, lo que significa que eludió la autenticación multifactor por completo. Pero antes de que se robara cualquier token, el ataque tuvo que llegar a una bandeja de entrada. Ese primer paso, la entrega, es donde la autenticación del correo electrónico mantiene la línea o falla.
Cómo funcionó la campaña
Los mensajes de phishing utilizaban lo que los investigadores de Microsoft denominaron “plantillas HTML pulidas al estilo empresarial con diseños estructurados y declaraciones de autenticidad preventivas”. El señuelo era una solicitud de reconocimiento de código de conducta, el tipo de mensaje al que los empleados están condicionados a responder sin demasiado escrutinio. Las organizaciones de salud y ciencias de la vida recibieron el 19% del volumen de la campaña. Los servicios financieros recibieron el 18%. Los servicios profesionales y las empresas tecnológicas dividieron el resto.
El mecanismo de entrega aprovechó un patrón que Microsoft había advertido cuatro meses antes, en enero de 2026: configuraciones de enrutamiento de correo complejas en las que los registros MX no apuntan directamente a Microsoft 365, combinadas con conectores de terceros que llevan confianza implícita. En estos entornos, un atacante que enruta a través de un relay de confianza puede inyectar mensajes que parecen originarse desde dentro de la organización, eludiendo las comprobaciones de DMARC y SPF que habrían señalado o rechazado el mismo mensaje enviado directamente.
Una vez que el mensaje llegaba a la bandeja de entrada, hacer clic en el enlace llevaba a una página de inicio de sesión servida por infraestructura AiTM. El proxy AiTM se situaba entre la víctima y el inicio de sesión real de Microsoft, capturaba las credenciales y el token de sesión resultante en tiempo real, y transmitía un inicio de sesión exitoso a la víctima para evitar levantar sospechas. Con un token de sesión válido en mano, el atacante tenía acceso autenticado a la cuenta independientemente del método de MFA inscrito.
El problema de la configuración incorrecta del enrutamiento
El aviso de seguridad de Microsoft de enero de 2026 describió la superficie de ataque con precisión. Las organizaciones que enrutan el correo entrante a través de una puerta de enlace de seguridad de terceros antes de que llegue a Microsoft 365 a menudo configuran un conector entrante que otorga a esa puerta de enlace una confianza elevada. Si ese conector está mal configurado, específicamente si permite mensajes que afirman provenir de dominios aceptados internamente sin verificar la alineación de SPF o la firma DKIM, entonces un atacante que puede llegar a ese conector puede enviar correo electrónico que Microsoft 365 trata como de origen interno.
Las condiciones técnicas que crean esta exposición son comunes:
- Los registros MX apuntan a un servicio de filtrado de terceros, no directamente a Exchange Online
- El conector entrante para ese servicio está configurado para aceptar cualquier mensaje que el servicio reenvíe, en lugar de validar la autenticación en cada mensaje
- La política DMARC en el propio dominio de la organización es
p=none, lo que significa que los sistemas receptores reciben la instrucción de monitorear pero nunca bloquear el correo no autenticado
Cada condición es individualmente poco llamativa. Las organizaciones utilizan pasarelas de correo de terceros por razones legítimas. Los conectores entrantes requieren concesiones de confianza por diseño. p=none es el punto de partida para el despliegue de DMARC. Juntas, crean un camino desde fuera de la organización hacia una bandeja de entrada que se lee como interna.
La mitigación que Microsoft recomendó en enero fue directa: establecer DMARC en p=reject con SPF configurado para hard fail (-all), y auditar cada conector de terceros para verificar que valida SPF y DKIM en lugar de heredar confianza general. Las organizaciones cuyos registros MX apuntan directamente a Exchange Online no están expuestas a este vector de ataque específico. Las que tienen enrutamiento de terceros en el camino, sí lo están, si su configuración de autenticación es permisiva.
Por qué la MFA no salvó a estos usuarios
La técnica AiTM ataca el token de sesión que se emite después de una autenticación exitosa, incluso después de completar el desafío de MFA. La víctima inicia sesión, pasa el segundo factor y recibe una cookie de sesión. El proxy AiTM captura esa cookie antes de que el navegador la almacene. El atacante presenta la misma cookie al servicio y recibe acceso autenticado completo.
Esto no es una vulnerabilidad en las implementaciones de MFA. Es una técnica que opera por encima de la capa de autenticación, en la capa de sesión. Funciona contra códigos TOTP, contraseñas de un solo uso por SMS, aprobaciones push y la mayoría de las implementaciones de tokens de hardware. Los métodos de MFA resistentes al phishing vinculados a la URL de origen, como las claves de acceso FIDO2 y la autenticación basada en certificados, bloquean AiTM porque el autenticador se niega a operar en un dominio que no reconoce. Pero la MFA resistente al phishing no es la norma en las 13.000 organizaciones que fueron objetivo en abril.
La implicación práctica es que la MFA reduce pero no elimina el riesgo del phishing de credenciales. DMARC en nivel de aplicación, combinado con SPF preciso, reduce el riesgo de entrega que hace posible el intento de phishing de credenciales en primer lugar. Ningún control por sí solo es suficiente. Ambos son componentes necesarios de una defensa en capas.
La primera barrera
La autenticación de correo electrónico en p=reject es la primera barrera en la cadena de eliminación de phishing. No detiene todas las campañas de phishing, pero elimina una categoría grande e importante: los mensajes que afirman provenir de su dominio o un dominio que usted controla y que en realidad no están autenticados desde su infraestructura.
Si las organizaciones objetivo en la campaña de abril hubieran aplicado p=reject en sus propios dominios y auditado su configuración de conectores para garantizar que la alineación SPF se verificara a nivel del conector entrante, la ruta de ataque que dependía de parecer originarse internamente habría sido bloqueada antes de la entrega. El correo electrónico de phishing que parece una comunicación interna de RRHH es mucho menos creíble cuando tiene que llegar desde un dominio que el atacante realmente controla, en lugar de suplantar la propia identidad de la organización.
Esta es la brecha de aplicación que documentan los informes de adopción de DMARC de 2026. De los aproximadamente 937.000 dominios con registros DMARC, menos de la mitad han pasado a cuarentena o rechazo. La mayoría se encuentra en p=none, que genera informes y no hace nada para bloquear la entrega. Para las organizaciones que enrutan correo a través de puertas de enlace de terceros con conectores permisivos, p=none no ofrece ninguna protección contra el patrón de ataque que Microsoft documentó.
La auditoría de configuración que debe realizar ahora
La combinación de la advertencia de enrutamiento de enero de 2026 y la divulgación de la campaña AiTM de mayo de 2026 define una lista de verificación específica para cualquier organización que utilice Microsoft 365 con enrutamiento de correo de terceros:
Nivel de política DMARC. Verifique que su dominio organizacional tenga un registro DMARC en p=quarantine o p=reject. Si su registro está en p=none, programe la migración de aplicación y trátela como una corrección de seguridad, no como una casilla de verificación de cumplimiento.
Hard fail de SPF. Revise su registro SPF y confirme que termina en -all, no en ~all. Un softfail (~all) indica a los servidores receptores que el correo no autenticado podría seguir siendo legítimo. Un hard fail (-all) les dice que lo rechacen. El ajuste ~all existe para la fase de monitoreo del despliegue de DMARC. Una vez que la aplicación está en su lugar, debe ser reemplazado.
Validación del conector entrante. Si utiliza una puerta de enlace de terceros, revise la configuración del conector en el Centro de administración de Exchange. Confirme que el conector valida SPF y DKIM en los mensajes entrantes en lugar de confiar implícitamente en todo lo que reenvía la puerta de enlace. La documentación de Microsoft cubre esto bajo “Filtrado mejorado para conectores”.
Política de subdominio. La política DMARC de su dominio ápice no se aplica automáticamente a los subdominios a menos que incluya sp=reject en su registro. La actualización RFC 9989 introdujo la etiqueta np= específicamente para subdominios inexistentes. Si los atacantes pueden enviar desde mail.sudominio.com o rrhh.sudominio.com sin alcanzar una política de aplicación, esos subdominios son superficie de ataque.
Monitoreo de informes agregados. Ejecutar en p=reject sin revisar los informes agregados significa que no sabrá cuándo aparece una nueva fuente de envío legítima y falla la autenticación. La aplicación de DMARC sin análisis continuo de informes es mantenimiento sin monitoreo.
La conclusión
La campaña de abril de 2026 apuntó a más de 13.000 organizaciones en dos días utilizando técnicas documentadas desde hace años. La vulnerabilidad de configuración incorrecta del enrutamiento que contribuyó a su alcance fue divulgada públicamente por Microsoft en enero de 2026 con pasos concretos de corrección. La brecha entre la divulgación y la corrección es donde operan los atacantes.
La autenticación de correo electrónico en nivel de aplicación no es un logro técnico sofisticado. Es un estado de configuración. El desafío no es saber qué configurar; el desafío es completar el proceso en cada fuente de envío, cada conector y cada subdominio, y luego mantener esa configuración a medida que la infraestructura cambia. Esa continuidad operativa es lo que separa a las organizaciones que están protegidas de las que están documentadas pero expuestas.
Cerrar la brecha de enrutamiento y aplicar DMARC p=reject en un entorno de envío complejo es exactamente el tipo de trabajo operativo continuo que Excello Mail gestiona por usted. Análisis de informes agregados, descubrimiento de fuentes, orientación sobre conectores y monitoreo de aplicación en una sola plataforma. Regístrese gratis en excello.email →