El equipo forense de Varonis Threat Labs descubrió una campaña de phishing que atacó a más de 70 organizaciones – la mayoría en Estados Unidos – explotando una función legítima de Microsoft 365 de una manera que la mayoría de los equipos de seguridad no había anticipado. El ataque no requirió credenciales robadas, cuentas comprometidas ni ninguna vulnerabilidad de software en el sentido tradicional. Solo necesitó un endpoint predecible, un enrutamiento de correo permisivo y una comprensión incompleta de cómo Microsoft 365 procesa el correo que llega a través de su propia infraestructura.
Esa función se llama Direct Send.
Qué es Direct Send y para qué fue diseñado
Direct Send es un método de flujo de correo en Microsoft 365 que permite a impresoras, escáneres, dispositivos de red, aplicaciones empresariales y servicios internos enviar correo electrónico sin autenticarse en Exchange Online. Un escáner que envía un documento digitalizado, un sistema de punto de venta que genera un recibo o una herramienta de monitoreo que emite una alerta – estos son los casos de uso previstos.
El mecanismo funciona a través de un endpoint predecible: [nombredetenant].mail.protection.outlook.com. Cualquier dispositivo o aplicación que pueda conectarse al puerto 25 en esa dirección puede inyectar correo en el flujo del tenant sin proporcionar credenciales. Microsoft lo diseñó así para dar soporte a hardware heredado y sistemas internos que no pueden realizar autenticación moderna.
El formato del endpoint es completamente predecible a partir del nombre del tenant de la organización, que normalmente puede descubrirse consultando el registro MX público del dominio.
Cómo los atacantes lo convirtieron en un vector de suplantación
La campaña de Varonis, activa desde al menos mayo de 2025, funcionó de la siguiente manera: los atacantes identificaron los endpoints de tenant de las organizaciones objetivo, se conectaron a esos endpoints desde direcciones IP externas y enviaron mensajes con encabezados From: configurados con nombres de empleados reales dentro de la organización objetivo. Esos mensajes viajaron entonces a través de la propia infraestructura de Microsoft y, bajo ciertas configuraciones de enrutamiento, fueron entregados a destinatarios dentro de la misma organización con apariencia de provenir de un remitente interno de confianza.
Como los mensajes transitaron por los servidores de Microsoft 365, los filtros receptores los trataron de forma diferente al correo externo ordinario. La propia telemetría de Microsoft reveló la combinación específica de encabezados que señala esta condición: InternalOrgSender=True apareciendo junto a MessageDirectionality=Incoming. El mensaje parece generado internamente para Exchange Online Protection, aunque se originó desde un atacante externo.
La verificación SPF falla. La IP remitente no está incluida en el registro SPF de la organización. DKIM está ausente. No hay clave privada con la que firmar. DMARC falla. Tanto SPF como DKIM fallan, por lo que no se puede establecer la alineación. Pero nada de eso importa si la organización tiene una regla de flujo de correo que establece el Nivel de Confianza de Spam (SCL) en -1 para el tráfico del conector entrante, o si la configuración de enrutamiento no aplica validación estricta a lo que Exchange Online Protection ya ha clasificado como tráfico de apariencia interna.
Los entornos vulnerables muestran encabezados de autenticación como spf=fail y dmarc=fail action=none reason=905. Los entornos protegidos muestran dmarc=fail action=reject u oreject en su lugar. Esa diferencia – action=none frente a action=reject – es la diferencia entre un mensaje que llega al buzón y uno que es bloqueado.
Cómo se ven los correos de phishing para los destinatarios
Varonis documentó los señuelos específicos utilizados en la campaña. El formato más común fue una notificación de buzón de voz: un mensaje que parecía provenir de un sistema informático interno informando al destinatario que tenía un nuevo mensaje de voz. El correo contenía un archivo PDF adjunto. Dentro del PDF había un código QR. Al escanear el código QR, el destinatario era dirigido a un sitio de phishing construido sobre infraestructura Tycoon2FA – una plataforma de phishing como servicio que incluye páginas para eludir CAPTCHA y capturar credenciales de Microsoft 365.
El análisis de Microsoft de campañas relacionadas documentó tipos de señuelos adicionales:
Suplantación de DocuSign. Mensajes indicando que un documento está pendiente de firma del destinatario, usando la imagen de Microsoft 365 y una dirección de remitente interno falsa para establecer credibilidad.
Suplantación de Recursos Humanos. Avisos de que se acerca un plazo de inscripción en beneficios o que se requiere la aceptación de una política, usando nombres de contactos internos de RRHH como remitente aparente.
Compromiso de correo empresarial. Mensajes falsificados que parecen provenir del CEO y dirigen al equipo de contabilidad a pagar facturas fabricadas, acompañados de formularios W-9 falsos y cartas bancarias inventadas solicitando transferencias ACH.
Todos estos mensajes compartían una característica visible desde la perspectiva del destinatario: la dirección del remitente era la de un colega real o un sistema interno reconocible. El dominio coincidía. El enrutamiento parecía interno. No había ninguna señal visible de que algo estuviera mal.
Qué organizaciones están expuestas
No todos los tenants de Microsoft 365 son vulnerables. Las organizaciones cuyos registros MX apuntan directamente a Microsoft 365 están protegidas por la detección nativa de suplantación de Exchange Online Protection, que identifica la anomalía de enrutamiento y bloquea los intentos de Direct Send no autenticados.
El ataque funciona específicamente contra organizaciones que cumplen una o más de estas condiciones:
- El correo entrante se enruta a través de una pasarela de seguridad de correo de terceros antes de llegar a Exchange Online (configuraciones comunes con Proofpoint, Mimecast o Barracuda como destino MX)
- La política DMARC está configurada en
p=noneen lugar dep=quarantineop=reject - Las reglas de flujo de correo asignan un SCL de -1 al tráfico que llega a través de ciertos conectores, desactivando efectivamente todos los filtros de spam y suplantación para esa ruta
- La configuración organizacional
RejectDirectSendintroducida por Microsoft en abril de 2025 no ha sido habilitada
La configuración de pasarela de terceros es especialmente común en grandes empresas que enrutan el correo entrante a través de dispositivos externos antes de que entre a Exchange Online. Esa topología crea la brecha que el ataque explota.
Cómo cerrar la brecha
Microsoft introdujo una configuración específica para abordar esta clase de ataque en abril de 2025:
Set-OrganizationConfig -RejectDirectSend $true
Este comando, ahora habilitado por defecto en los tenants creados recientemente, rechaza los intentos de Direct Send no autenticados aproximadamente 30 minutos después de ser aplicado. Los tenants creados antes de abril de 2025 pueden no tener esta configuración habilitada y deben verificar su estado en el Centro de Administración de Exchange.
Esa configuración aborda específicamente el vector de Direct Send. Cerrar la clase más amplia de omisiones de autenticación basadas en enrutamiento requiere un enfoque por capas:
DMARC en p=reject. La campaña de Varonis fue más efectiva contra organizaciones con políticas p=none. Pasar a p=reject significa que un fallo de DMARC produce una acción de rechazo en lugar de un evento de solo reporte.
Revisar cada conector de flujo de correo. Cada conector entrante en Exchange Online debe auditarse para confirmar que no aplica configuraciones SCL:-1 globales al tráfico que podría inyectarse externamente. Las excepciones basadas en conectores deben limitarse solo a rangos de IP verificados.
SPF con fallo duro. Configurar -all (fallo duro) en lugar de ~all (fallo suave) envía una señal de rechazo más fuerte y reduce la ambigüedad que los conectores permisivos pueden explotar.
MFA resistente al phishing. Si las credenciales de un empleado son capturadas a través de una página de Tycoon2FA, las llaves de hardware FIDO2, las passkeys o Windows Hello for Business impiden que esas credenciales sean reutilizadas incluso si el atacante posee un token de sesión válido. Los códigos TOTP estándar no proporcionan esta protección contra la interceptación de intermediarios.
La brecha estructural que las estadísticas de DMARC no muestran
El exploit de Direct Send expone algo que los números globales de adopción de DMARC tienden a ocultar: los registros de autenticación definen lo que debería ocurrir cuando llega correo no autenticado. No impiden que los atacantes encuentren rutas a través de la infraestructura de correo que traten los mensajes maliciosos como si estuvieran autenticados.
Una política DMARC en p=reject sobre un dominio con una configuración de enrutamiento MX no estándar puede que nunca se active – porque el mensaje fallido llega a través de una ruta de conector a la que la política de rechazo nunca se aplica. La política existe en el DNS. La protección no existe en el flujo de correo.
Monitorear lo que la capa de autenticación de tu dominio realmente hace – no solo lo que tus registros DNS publicados dicen que debería hacer – es la diferencia entre DMARC como documento de cumplimiento y DMARC como defensa operativa.
Los atacantes están enrutando phishing a través de tu propia infraestructura de correo. Excello Mail te muestra lo que realmente ocurre en la capa de autenticación de tu dominio, no solo lo que declaran tus registros DNS. Regístrate gratis en Excello Mail y obtén una visión completa de quién envía en nombre de tu dominio y cómo se comporta tu autenticación en el mundo real.