Los usuarios de Microsoft 365 están siendo blanco de una técnica de phishing que consiste en dejar en blanco el remitente del sobre SMTP. Esta omisión permite que mensajes no autenticados superen las medidas de seguridad de Direct Send, haciendo que el correo parezca provenir de la propia organización del empleado. Se ha aclarado que este método no es un fallo de software de Microsoft.

Los usuarios de Microsoft 365 se enfrentan a una técnica de phishing basada en un pequeño cambio: los atacantes dejan en blanco el remitente del sobre SMTP.

Esta omisión puede permitir que un mensaje no autenticado supere una salvaguarda de Direct Send, mientras muestra a los empleados una dirección que parece pertenecer a su propia organización.

Este enfoque no es un fallo de software de Microsoft y no requiere una cuenta robada. Explota la forma en que el control RejectDirectSend de Exchange Online comprueba el dominio en el remitente del sobre, en lugar de la dirección que se muestra en el campo visible "De" (From).

Esa diferencia ofrece a los criminales una ruta sencilla para la suplantación de identidad. Elimina una barrera diseñada para detener una forma especialmente arriesgada de correo falsificado.

Investigadores de ReliaQuest identificaron el patrón en casos activos de phishing y lo reprodujeron en un tenant de Microsoft 365 controlado.

Reliaquest señaló en un informe que la técnica ha aparecido repetidamente en organizaciones no relacionadas durante el último año. Un correo convincente con apariencia interna puede llevar un aviso de documento, una solicitud de pago o un señuelo de buzón de voz.

Incluso si los filtros de correo detectan algunos intentos, cualquier mensaje que llegue a un destinatario crea una oportunidad para el robo de credenciales, la entrega de malware, transferencias fraudulentas y un compromiso más amplio de la cuenta.

La técnica de phishing de Microsoft 365 utiliza un remitente de sobre vacío

Direct Send permite que dispositivos y aplicaciones envíen correo dentro del mismo tenant de Microsoft 365 sin autenticación. Coberturas anteriores sobre Microsoft 365 Direct Send documentaron a atacantes imitando a usuarios internos sin comprometer ninguna cuenta.

RejectDirectSend está diseñado para rechazar el correo de Direct Send no autenticado que afirma provenir del dominio aceptado de una organización. ReliaQuest envió dos mensajes al host de correo de un tenant.

El mensaje que utilizaba el dominio del tenant en su remitente de sobre fue rechazado, pero uno que utilizaba el comando SMTP MAIL FROM:<> fue aceptado y puesto en cola.

El destinatario siguió viendo la misma dirección de soporte técnico interno en el campo visible "De". Dado que el remitente vacío no contiene ningún dominio, RejectDirectSend no tiene nada con qué comparar los dominios aceptados del tenant.

Por lo tanto, el control no aplica su condición de rechazo, a pesar de que el mensaje provenía de una fuente externa no autenticada.

Que sea aceptado no significa que llegue a la bandeja de entrada. Microsoft 365 marcó el mensaje de prueba como anónimo, le asignó un Nivel de Confianza de Spam (SCL) de 9 y lo envió a Correo No Deseado después de que SPF y DKIM no devolvieran resultado y DMARC fallara.

Sin embargo, los resultados del filtrado pueden variar según el contenido, la infraestructura, la configuración y las excepciones de remitentes confiables. En un caso, un mensaje que falló todas las comprobaciones de autenticación del remitente fue clasificado como phishing de alta confianza, pero llegó a la bandeja de entrada porque el ejecutivo suplantado era un remitente permitido.

Si sigues la guía de configuración de autenticación de correo electrónico, también deberías revisar las excepciones que pueden anular las comprobaciones.

Objetivos y pasos defensivos

ReliaQuest examinó ejemplos desde septiembre de 2025 hasta agosto de 2026 dirigidos a ejecutivos, gerentes, personal de finanzas, equipos de adquisiciones y roles de atención al cliente. Estas personas manejan regularmente facturas, ofertas, archivos compartidos e instrucciones de pago, lo que hace que el lenguaje empresarial sea convincente.

Los avisos de archivos compartidos fueron los más comunes, seguidos de solicitudes de pago y remesas, invitaciones de adquisición, ofertas de préstamos o inversiones e invitaciones a reuniones. Algunos mensajes utilizaban archivos adjuntos SVG disfrazados de grabaciones de buzón de voz.

Este enfoque recuerda a los casos de archivos phishing SVG maliciosos, que pueden activar la redirección del navegador en lugar de actuar como imágenes. Los equipos de seguridad deben mantener RejectDirectSend, pero no considerarlo como una defensa completa.

Un conector entrante restringido por IP permite Direct Send no autenticado solo desde dispositivos y aplicaciones aprobadas. Esto bloqueó cada intento de Direct Send, incluidos aquellos con un sobre de remitente en blanco.

Debes identificar los sistemas que realmente necesitan Direct Send y restringir estrictamente las direcciones IP de origen aprobadas.

Elimina las excepciones de filtrado injustificadas, incluidos los remitentes permitidos, los dominios permitidos, las entradas de remitentes seguros y las reglas que cambian las puntuaciones de spam. Casos anteriores de suplantación de correo interno muestran por qué las rutas confiables y las reglas permisivas necesitan un escrutinio.

Finalmente, como defensor, deberías buscar un remitente de sobre vacío emparejado con una dirección "De" visible en un dominio interno aceptado, lo cual difiere del correo de rebote. Prioriza las alertas donde SPF, DKIM o DMARC también fallaron, pero la entrega ocurrió a través de una anulación.

Tú y tus empleados deben verificar las solicitudes inesperadas de pago, documentos o acceso utilizando un canal conocido antes de actuar. Esta comprobación debe realizarse primero, antes de responder o abrir archivos adjuntos.

Fuentes:
https://cybersecuritynews.com/microsoft-365-phishing/