LaunDroMARC: Cómo una laguna jurídica de Microsoft SRS está blanqueando correos electrónicos falsificados
por
Última actualización: Tiempo de lectura: 5 minutos
Puntos clave
- El reenvío de correos electrónicos puede eludir inadvertidamente las protecciones DMARC.
- El SRS de Microsoft puede «blanquear» correos electrónicos maliciosos, haciéndolos parecer fiables.
- LaunDroMARC afecta tanto a los mensajes reenviados internos como externos.
- La supervisión continua y la visibilidad son fundamentales para la seguridad del correo electrónico.
- PowerDMARC proporciona herramientas para detectar y mitigar estas lagunas en el reenvío.
El investigador de seguridad Aaron Hart estaba investigando lo que parecía un intento habitual de compromiso del correo electrónico empresarial. Pero cuanto más profundizaba, más extraño se volvía. Todo lo relacionado con el ataque parecía pulido y creíble: el dominio del remitente, los resultados de la autenticación y la ruta que seguía el correo electrónico.
Sin embargo, había ocurrido algo imposible. Un correo electrónico que no cumplía con DMARC en el origen , había superó el DMARC después de ser reenviado a través de Microsoft Exchange Online.
Esto no debería ser posible. Pero lo era, y ocurría debido a un efecto secundario del esquema de reescritura del remitente (SRS) .
Este blog analiza el tema en un lenguaje sencillo, compartido originalmente por Engage Security, y explica cómo funciona esta laguna y cómo las organizaciones pueden detectar y mitigar el riesgo.
Cómo Microsoft SRS provoca el bypass de DMARC
Durante la investigación, Aaron observó lo siguiente:
- El correo electrónico afirmaba provenir de un dominio interno de confianza (ORG 1).
- Se entregó en la bandeja de entrada del usuario en otra organización (ORG 2).
- ORG 2 consideró que el mensaje estaba perfectamente autenticado, es decir, SPF aprobado, DMARC aprobado.
- Pero el correo electrónico original enviado a ORG 1 por el atacante no superó la verificación DMARC.
- El reenvío SRS de Microsoft reescribió el MAIL FROM durante el reenvío.
- El MAIL FROM reescrito creó una alineación, haciendo que DMARC pasara a continuación.
En resumen: Un correo electrónico falsificado que debería haber sido rechazado fue reenviado, reescrito y «limpiado», y luego entregado como un mensaje confiable. Esto dio lugar a un compromiso real de la cuenta, y no fue un caso aislado.
Por qué es importante
El reenvío de correos electrónicos es muy habitual en las organizaciones:
- Consultores que reenvían correos electrónicos de clientes
- Los miembros del consejo de administración reenvían las direcciones corporativas a sus buzones personales.
- Buzones compartidos o listas de distribución que envían correo al exterior
- Grupos de colaboración entre organizaciones
Desde 2023, Microsoft ha habilitado SRS para todos los inquilinos de Exchange Online, con la intención de solucionar los fallos de SPF causados por el reenvío de correos electrónicos. Desafortunadamente, esta solución creó un nuevo problema: los correos electrónicos maliciosos reenviados ahora aparecen completamente autenticados, incluso cuando originalmente fallaron DMARC.
Este fenómeno se ha denominado «LaunDroMARC» porque el proceso de reenvío literalmente «blanquea» los mensajes maliciosos.
Un repaso rápido: SMTP, SPF, DKIM y DMARC
CORREO DE vs DE
- CORREO DE (Remitente del sobre): invisible para los usuarios y utilizado para gestionar los rebotes.
- DE: remitente visible en su bandeja de entrada.
SPF
El Marco de Política del Remitente verifica si el servidor remitente está autorizado para enviar correo para el dominio MAIL FROM. SPF no valida la dirección FROM visible y se interrumpe en el reenvío (los reenviadores no están en el registro SPF del remitente).
DKIM
Correo identificado con DomainKeys firma digitalmente los encabezados de los correos electrónicos, incluido el campo «De». Los atacantes pueden firmar con DKIM sus propios dominios maliciosos, lo que pone de manifiesto una de las debilidades del protocolo.
DMARC
La autenticación, notificación y conformidad de mensajes basadas en dominios soluciona los problemas de alineación al exigir que el dominio MAIL FROM coincida con el dominio FROM, o que el dominio de firma DKIM coincida con el dominio FROM, para poder superar la autenticación. Si la alineación falla, la política DMARC del dominio política DMARC indica a los receptores si deben entregar, poner en cuarentena o rechazar el mensaje.
DMARC redujo significativamente la suplantación de identidad hasta que esta laguna lo reintrodujo.
Dónde falló: la implementación del SRS de Microsoft
El SRS se introdujo para evitar fallos del SPF durante el reenvío. Sin embargo, la implementación de Microsoft tiene una laguna crítica:
Microsoft reescribe el MAIL FROM incluso cuando:
- El correo electrónico original falsifica la dirección DE del dominio de reenvío.
- El correo electrónico falsificado falla DMARC en el primer salto.
- El mensaje proviene de un dominio controlado por un atacante.
Una vez reescrito utilizando SRS, el MAIL FROM ahora se alinea con el dominio FROM, haciendo que DMARC pase en el destino final.
El resultado: un correo electrónico malicioso que normalmente debería fallar DMARC termina siendo reenviado, reescrito por SRS y perfectamente alineado con los registros de autenticación del dominio de reenvío. Como resultado, se entrega al destinatario como un mensaje totalmente legítimo. En resumen, el spoofing a través del reenvío de correo electrónico vuelve a ser posible, anulando las protecciones que DMARC fue diseñado para proporcionar.
Actualmente, Microsoft no considera que esto sea una vulnerabilidad de seguridad.
Ejemplo de escenario
Imagina que un atacante controla el dominio maliciousmailer.com, con registros SPF configurados para permitir el envío desde la IP 198.51.100.25. El atacante redacta un correo electrónico dirigido a una consultora, Sarah, cuyo correo electrónico de trabajo es [email protected], pero que se reenvía automáticamente a su buzón personal en [email protected].
El atacante configura los encabezados del correo electrónico de la siguiente manera:
- CORREO DE: [email protected]
- DE: Sarah [email protected] (suplantado para que parezca interno)
- Para: [email protected]
Cuando se envía, la validación SPF se supera porque el dominio MAIL FROM está controlado por el atacante. Cuando el correo electrónico llega a company.com, Exchange Online lo procesa con SRS: ignora el fallo DMARC en el FROM falsificado, reescribe el MAIL FROM para alinearlo con el dominio de reenvío (por ejemplo, sarah+SRS=…@company.com) y lo reenvía al buzón personal de Sarah.
En personalmail.com, DMARC ahora pasa porque el MAIL FROM reescrito y el FROM visible están alineados. El correo electrónico se entrega en la bandeja de entrada de Sarah con apariencia legítima, eludiendo eficazmente las protecciones que deberían haberlo detenido.
En resumen, un mensaje falsificado que debería haber sido bloqueado ahora goza de la confianza del destinatario, lo que ilustra cómo el SRS puede «blanquear» inadvertidamente correos electrónicos maliciosos.
Por qué LaunDroMARC es peligroso para las organizaciones
Esta vulnerabilidad es peligrosa porque los usuarios confían naturalmente en los correos electrónicos que parecen provenir de su propia organización o de un dominio interno conocido. Cuando se reenvían correos electrónicos maliciosos, estos eluden los controles de seguridad originales y llegan con un aspecto limpio y legítimo.
Los atacantes aprovechan las reglas de reenvío predecibles para explotar este punto ciego, mientras que los equipos de seguridad suelen centrarse en las amenazas entrantes en lugar de en el correo reenviado. Como resultado, esta laguna abre la puerta a riesgos graves, como el robo de datos confidenciales, la recopilación de credenciales, el spear-phishing interno e incluso los ataques de suplantación de identidad en la cadena de suministro.
Lo que Microsoft podría arreglar
Hay varias medidas sencillas que Microsoft podría implementar:
- No reescribas MAIL FROM a través de SRS si el encabezado FROM pertenece al dominio de reenvío pero falla DMARC en el salto inicial.
- Aplica SRS solo a los mensajes que superen DMARC del remitente.
- Compare los encabezados Authentication-Results antes y después del reenvío.
Si no coinciden, ponga el mensaje en cuarentena.
Cómo pueden las organizaciones detectar LaunDroMARC
1. El dominio de reenvío (Exchange Online)
Puede detectar posibles abusos buscando correos electrónicos en los que el dominio MAIL FROM sea externo, pero el encabezado FROM parezca pertenecer a su organización. Estos mensajes suelen mostrar un patrón de pasar SPF pero fallar DMARC: una señal de alerta en el contexto de la reescritura de SRS. Cuando esos mismos mensajes se reenvían posteriormente, se convierte en un fuerte indicador de que sus reglas de reenvío se están utilizando para retransmitir contenido falsificado o malicioso.
2. El dominio del destinatario final
Si un correo electrónico muestra una alineación entre la dirección FROM visible y el MAIL FROM reescrito, pero el dominio MAIL FROM original oculto dentro del valor SRS no coincide con ninguno de los dos, es un fuerte indicio de que el mensaje ha sido «blanqueado» mediante reenvío y puede ser un correo electrónico falsificado o malicioso.
La perspectiva de PowerDMARC
Como plataforma dedicada a reforzar la autenticación global del correo electrónico, problemas como LaunDroMARC ponen de relieve por qué la supervisión y la visibilidad son tan importantes como la aplicación. Incluso cuando se implementan correctamente estándares como DMARC, las deficiencias de implementación de los proveedores de buzones de correo pueden crear vulnerabilidades que escapan a su control.
PowerDMARC ayuda a las organizaciones a:
- Analizar los resultados de autenticación en todos los saltos.
- Detectar anomalías de alineación y comportamiento de reenvío.
- Reciba alertas en tiempo real sobre intentos de suplantación de identidad.
- Comprender cómo los sistemas de terceros gestionan el correo reenviado.
- Supervisar el tráfico entre dominios en busca de patrones de suplantación de identidad.
- Mantenga la visibilidad de los ataques que aprovechan las cadenas de reenvío.
Prueba prueba gratuita o programe una demostración con uno de nuestros expertos internos para empezar a proteger su dominio hoy mismo.
Reflexiones finales
El problema LaunDroMARC vuelve a abrir un vector de ataque que DMARC fue diseñado para detener, haciendo posible nuevamente la suplantación de dominios internos a través del correo reenviado. Si bien Microsoft actualmente considera que esto es un «riesgo bajo», los compromisos en el mundo real demuestran lo contrario.
Las organizaciones que utilizan Microsoft 365 deben ser conscientes de esta laguna en el reenvío y aplicar medidas de detección adicionales.
Experto en seguridad de dominios y correo electrónico de PowerDMARC
Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.
Últimas publicaciones de Ahona Rudra (ver todas)
- Registro SPF de Avanan: cómo configurar, corregir y optimizar tu SPF para Check Point Harmony Email - 7 de mayo de 2026
- Registro SPF de DNS: cómo funciona y cómo configurarlo - 6 de mayo de 2026
- ¿Qué es v=spf1? ¿Para qué sirve? - 5 de mayo de 2026
