El 3 de septiembre de 2026 el equipo de investigación de ReliaQuest publicó una prueba muy simple: fue suficiente con dejar en blanco el remitente del sobre SMTP para que Exchange Online aceptara un correo anónimo, enviado desde fuera y sin ninguna credencial, con la dirección de un empleado en el campo De. El ajuste que Microsoft ofrece contra esa suplantación, RejectDirectSend, estaba activado en el inquilino de la prueba y no lo detuvo. ReliaQuest acompaña el hallazgo con casos reales investigados entre septiembre de 2025 y agosto de 2026.
ReliaQuest no lo clasifica como vulnerabilidad del software de Microsoft, a quien avisó antes de publicar: se trata de una limitación en lo que el control abarca. RejectDirectSend compara el dominio del remitente del sobre con los dominios aceptados del inquilino, y un sobre sin remitente no tiene dominio que comparar, así que el mensaje pasa. Esa diferencia decide dónde hay que situar la defensa: en cómo se configura el flujo de correo entrante, con sus conectores y sus excepciones, y no en un único interruptor.
En Hard2bit, una empresa de ciberseguridad que audita entornos de Microsoft 365 de forma continua, el patrón resulta familiar: muchas de las técnicas más rentables para el atacante no rompen ningún cifrado ni dependen de un fallo con número de CVE; explotan funciones legítimas que casi nadie vigila, y Direct Send pertenece a esa familia.
¿Qué es Direct Send y por qué existe?
Exchange Online incluye una vía de envío, Direct Send, para que impresoras multifunción, escáneres y aplicaciones internas manden correo a los buzones del mismo inquilino sin autenticarse. El motivo es práctico: un escáner que envía por correo el documento que acaba de digitalizar no puede custodiar credenciales con garantías, y Microsoft le permite entregar el mensaje a través de un host cuyo nombre sigue un patrón fijo, del estilo inquilino.mail.protection.outlook.com.
Los atacantes aprovechan la vía sin autenticación de Direct Send. El host admite correo desde cualquier origen si el destinatario pertenece al inquilino, y tanto su nombre como el formato de las direcciones internas (nombre.apellido@empresa.com) se deducen de fuentes públicas. Con el dominio y una dirección válida, un tercero puede enviar un mensaje que aparenta nacer dentro de la organización sin haber tocado ninguno de sus sistemas. Varonis documentó una campaña de este tipo en más de setenta organizaciones a partir de mayo de 2025.
El hueco que deja RejectDirectSend
Microsoft respondió con el ajuste RejectDirectSend, disponible con carácter general desde septiembre de 2025. Activado, hace que Exchange Online rechace los mensajes anónimos de Direct Send cuyo dominio de remitente del sobre coincide con uno de los dominios aceptados del inquilino, siempre que no hayan llegado por un conector de confianza; el servidor devuelve un error 550 5.7.68 y el mensaje no se entrega. El control funciona, pero evalúa un único dato: el dominio del remitente.
ReliaQuest observó que el dominio del remitente del sobre puede omitirse. El protocolo SMTP admite un camino de retorno nulo, escrito MAIL FROM:<>, que los servidores usan de forma habitual en los informes de no entrega. Un mensaje enviado así no lleva dominio en el sobre, RejectDirectSend no encuentra valor que cotejar y lo deja pasar. La cabecera De, la que ve el usuario, puede seguir mostrando una dirección interna convincente, por ejemplo la del soporte de TI.
La prueba se hizo en un inquilino de ReliaQuest con RejectDirectSend activado. Dos mensajes idénticos salvo en el remitente del sobre recibieron trato distinto: el que llevaba una dirección de dominio aceptado fue rechazado con el error 550 5.7.68; el que llevaba el remitente nulo fue aceptado y puesto en cola para su entrega. En ninguno de los dos casos hicieron falta credenciales, un equipo interno comprometido, un dominio parecido registrado ni infraestructura de envío dedicada.
Aceptar un mensaje no es entregarlo en la bandeja
Sortear RejectDirectSend no garantiza la bandeja de entrada. En la prueba de ReliaQuest, Exchange Online marcó el mensaje aceptado como anónimo y sin autenticar: SPF y DKIM fallaron, DMARC se aplicó con action=oreject y el filtro le asignó un SCL de 9, el nivel máximo de confianza de spam, antes de dejarlo en la carpeta de correo no deseado.
Que el mensaje acabara en correo no deseado importa porque intervienen cuatro decisiones separadas: que el transporte acepte el mensaje, que la autenticación lo valide, que el antispam lo clasifique y que el sistema elija la carpeta. Un correo con el sobre sin remitente puede superar la primera y acabar en correo no deseado o en cuarentena, según la política. También puede acabar en la bandeja de entrada, y lo que inclina la balanza no es el ataque en sí, sino las excepciones que la organización tenga configuradas.
ReliaQuest describe al menos un caso en que un mensaje clasificado como phishing de alta confianza, con todas las comprobaciones de autenticación fallidas, llegó a la bandeja de entrada. La dirección del directivo suplantado figuraba en la lista de remitentes permitidos, y la excepción de confianza pesó más que el veredicto del filtro. Una entrada de remitentes seguros que cubre a un ejecutivo o a un buzón de finanzas es, por tanto, una decisión de riesgo.
A quién apunta y con qué señuelos
En los casos investigados por ReliaQuest, los destinatarios se concentraban en dirección, finanzas, compras y puestos de cara al cliente: personas que tramitan facturas, ofertas, instrucciones de pago y documentos compartidos con terceros. Un señuelo de pago o de documento resulta creíble para quien maneja pagos y documentos en su trabajo, y un compromiso en esos puestos abre la vía al fraude, al robo de datos o a más acceso.
Los cebos eran cotidianos antes que sofisticados: avisos de documento compartido, peticiones de pago y avisos de remesa, invitaciones a licitaciones, ofertas de inversión y notificaciones de reunión. Varios llevaban adjuntos SVG presentados como grabaciones de voz, un formato que el navegador abre directamente y que algunos productos de seguridad tratan de forma desigual. El correo dirigido a uno mismo, con el buzón del destinatario como remitente aparente, es una de las señales más constantes de la técnica, y coincide con lo que Varonis y StrongestLayer contaron a la prensa especializada durante 2025.
ReliaQuest observa la misma pauta de remitente nulo en organizaciones sin relación entre sí, lo que apunta a actividad rutinaria de phishing más que a un experimento aislado o a una campaña coordinada. Es un método de suplantación de identidad interna barato de ejecutar y sin infraestructura dedicada, y por eso sigue en uso.
Por qué los controles habituales no lo ven
El ataque se apoya en un supuesto de confianza, no en una técnica elaborada. Un mensaje que aparenta ser interno esquiva muchas comprobaciones de política reservadas a remitentes externos, y las herramientas que se guían por la reputación del remitente, por el resultado de la autenticación o por los patrones de enrutamiento externo lo tratan como tráfico de confianza. En el caso investigado por StrongestLayer, recogido por Dark Reading, el mensaje burló Microsoft Defender y pasarelas de correo de terceros.
A la confianza mal otorgada se suman dos dificultades: las cabeceras suelen llegar ausentes o mal formadas, lo que complica rastrear el origen, y el envío puede hacerse desde direcciones IP de cualquier país con herramientas de línea de comandos. La combinación de remitente interno aparente, autenticación fallida y entrega bajo una excepción es el punto ciego que un equipo de ingeniería de detección tiene que cubrir de forma deliberada.
Detección: qué buscar en la telemetría de correo
La señal más nítida combina tres elementos en un mismo mensaje: un camino de retorno vacío (Return-Path: <>), una cabecera De con uno de los dominios aceptados de la organización y un origen externo al inquilino. Los informes de no entrega que genera el inquilino mismo también llevan el sobre sin remitente, de modo que es la suma de los tres lo que distingue esta actividad del tráfico legítimo. Con esa regla, un SIEM que reciba la telemetría de correo puede alertar con pocos falsos positivos.
Otras señales de comportamiento refuerzan la detección:
- Mensajes que fallaron SPF, DKIM o DMARC y se entregaron igualmente porque una excepción anuló el veredicto; por ejemplo, DMARC con action=oreject seguido de entrega.
- Correos enviados de un usuario a sí mismo, un patrón poco natural fuera de las pruebas.
- Agentes de usuario de línea de comandos, como PowerShell, en el envío, y geolocalizaciones de origen inusuales.
- Adjuntos SVG o PDF presentados como notas de voz o faxes, tema recurrente en estas campañas.
Ninguna de esas señales prueba por sí sola un compromiso posterior, pero cada mensaje de phishing que alcanza una bandeja de entrada abre la puerta al robo de credenciales, a la ejecución de malware o al fraude en un pago. A efectos de priorización son intentos de ingeniería social con un disfraz especialmente eficaz.
Defensa: restringir el origen, no solo el remitente
El control más duradero evalúa el origen del mensaje. Un conector de entrada restringido por dirección IP admite correo solo de los dispositivos y aplicaciones inventariados que necesitan enviar sin autenticarse. En las pruebas de ReliaQuest bloqueó todos los intentos de Direct Send, con el sobre relleno o vacío, porque decide a partir de la fuente. Ahí es donde hay que situar la defensa.
Alrededor del conector restringido por IP, el resto de medidas se ordena sin dar por cerrado el problema con RejectDirectSend:
- RejectDirectSend debe seguir activado, como una capa más entre varias contra la suplantación interna.
- Revisar cada excepción capaz de anular un veredicto de filtrado: remitentes y dominios permitidos, entradas de la lista de permitidos y bloqueados del inquilino y reglas de flujo que ajusten la confianza de spam. Anotar cuáles cubren a un directivo y retirar las que no se puedan justificar.
- Aplicar una política DMARC de rechazo (p=reject) sobre un inventario previo de remitentes, como analizamos en la radiografía DMARC de las grandes empresas españolas.
- Sellar las cabeceras del correo interno legítimo con un identificador de la organización y poner en cuarentena los mensajes que se presenten como internos sin llevarlo, opción que el propio Microsoft ofrece.
- Al SIEM tienen que llegar las fuentes de correo adecuadas para cazar esta pauta; en nuestra guía sobre qué logs enviar a un SIEM explicamos cómo priorizarlas sin disparar el coste.
Para las organizaciones que enrutan el correo entrante por una pasarela, el conector restringido por IP es un ajuste inmediato. Para las demás, la defensa realista mientras se planifica el conector es mantener RejectDirectSend, reducir al mínimo las excepciones de confianza y vigilar el remitente nulo. Estas revisiones forman parte de una auditoría de Microsoft 365 y del trabajo diario de un SOC gestionado.
Lo que falla por debajo
La técnica del remitente nulo no revela una debilidad criptográfica ni una función escondida: se aprovecha de que la etiqueta «interno» sigue valiendo como salvoconducto. Un correo dirigido a uno mismo, envuelto en un flujo de negocio familiar, resulta persuasivo aunque no haya demostrado de dónde viene. RejectDirectSend valida un dominio y el atacante responde sin poner ninguno; mientras la confianza se conceda por el aspecto de la dirección y no por el origen demostrado del mensaje, seguirá existiendo un hueco por el que colarse.
El paralelismo con el secuestro de cuentas de Microsoft 365 por AiTM y con el phishing por código de dispositivo es exacto: también allí una etiqueta de confianza sustituyó a la comprobación. En Hard2bit lo vemos con frecuencia en las revisiones de correo corporativo.
Este artículo tiene carácter divulgativo y está escrito desde la perspectiva del defensor. La técnica del remitente nulo no es una vulnerabilidad del software de Microsoft, sino una limitación en el alcance de un control, según la propia investigación de ReliaQuest. Los ajustes, cabeceras y construcciones descritos (RejectDirectSend, MAIL FROM:<>, conectores de entrada restringidos por IP) proceden de fuentes públicas a fecha de publicación y deben adaptarse al inventario de remitentes y a las herramientas de cada organización; una restricción aplicada sin inventario previo puede bloquear correo legítimo. Las cifras y los casos citados corresponden a lo publicado por terceros en las fechas indicadas.
