LaunDroMARC : comment une faille dans le système SRS de Microsoft permet de blanchir des e-mails frauduleux

Le chercheur en sécurité Aaron Hart enquêtait sur ce qui semblait être une tentative classique d'usurpation d'adresse e-mail professionnelle. Mais plus il approfondissait ses recherches, plus l'affaire lui semblait étrange. Tout dans cette attaque semblait parfait et crédible : le domaine de l'expéditeur, les résultats d'authentification et le chemin emprunté par l'e-mail.

Pourtant, quelque chose d'impossible s'était produit. Un e-mail qui échouait au contrôle DMARC à la source a été comme par magie passé le contrôle DMARC après avoir été transféré via Microsoft Exchange Online.

Cela ne devrait pas être possible. Mais ça l'était, et cela se produisait en raison d'un effet secondaire du Sender Rewriting Scheme (SRS) .

Ce blog explique le problème dans un langage simple, initialement partagé par Engage Security, expliquant comment fonctionne cette faille et comment les organisations peuvent détecter et atténuer le risque.

Comment Microsoft SRS provoque le contournement de DMARC 

Au cours de l'enquête, Aaron a remarqué :

• L'e-mail prétendait provenir d'un domaine interne fiable (ORG 1).
• Il a été livré dans la boîte de réception de l'utilisateur dans une autre organisation (ORG 2).
• ORG 2 a considéré le message comme parfaitement authentifié, c'est-à-dire SPF , DMARC validé.
• Mais l'e-mail original envoyé à ORG 1 par l'attaquant n'a pas respecté le protocole DMARC.
• Le transfert SRS de Microsoft a réécrit le champ MAIL FROM pendant le transfert.
• La réécriture de MAIL FROM a créé un alignement, permettant à DMARC de passer en aval.

En bref : Un e-mail frauduleux qui aurait dû être rejeté a été transféré, réécrit et « nettoyé », puis livré comme un message fiable. Cela a entraîné une compromission réelle du compte, et ce n'était pas un cas isolé.

Pourquoi c'est important

Le transfert d'e-mails est extrêmement courant dans les organisations :

• Consultants transmettant les e-mails des clients
• Les membres du conseil d'administration transfèrent les courriers professionnels vers leurs boîtes aux lettres personnelles.
• Boîtes aux lettres partagées ou listes de distribution acheminant le courrier vers l'extérieur
• Groupes de collaboration interorganisations

Depuis 2023, Microsoft a activé le SRS pour tous les locataires Exchange Online, dans le but de corriger SPF causés par le transfert d'e-mails. Malheureusement, cette correction a créé un nouveau problème : les e-mails malveillants transférés apparaissent désormais comme entièrement authentifiés, même s'ils ont initialement échoué au DMARC.

Ce phénomène a désormais été baptisé « LaunDroMARC » car le processus de transfert « blanchit » littéralement les messages malveillants.

Petit rappel : SMTP, SPF, DKIM et DMARC

MAIL DE vs DE

• MAIL DE (Enveloppe de provenance) : invisible pour les utilisateurs et utilisé pour la gestion des rebonds.
• DE: expéditeur visible dans votre boîte de réception.

SPF

Le Sender Policy Framework vérifie si le serveur expéditeur est autorisé à envoyer des e-mails pour le domaine MAIL FROM. SPF valide SPF l'adresse FROM visible et interrompt le transfert (les transféreurs ne figurent pas dans SPF de l'expéditeur).

DKIM

DomainKeys Identified Mail signe numériquement les en-têtes des e-mails, y compris le champ « FROM » (De). Les pirates peuvent potentiellement signer leurs propres domaines malveillants avec DKIM, ce qui met en évidence l'une des faiblesses du protocole.

DMARC

L'authentification, le rapport et la conformité des messages basés sur le domaine corrigent les problèmes d'alignement en exigeant que le domaine MAIL FROM corresponde au domaine FROM, ou que le domaine de signature DKIM corresponde au domaine FROM, afin de passer l'authentification. Si l'alignement échoue, la politique DMARC du domaine politique DMARC indique aux destinataires s'ils doivent livrer, quarantine ou rejeter le message. 

DMARC a considérablement réduit l'usurpation d'identité jusqu'à ce que cette faille le réintroduise.

Où les choses ont mal tourné : la mise en œuvre du SRS par Microsoft

Le SRS a été introduit pour empêcher SPF lors du transfert. Mais la mise en œuvre de Microsoft présente une lacune critique :

Microsoft réécrit le champ MAIL FROM même lorsque :

• L'e-mail original usurpe l'adresse d'expéditeur du domaine de transfert.
• L'e-mail frauduleux échoue au test DMARC dès le premier saut.
• Le message provient d'un domaine contrôlé par un pirate informatique.

Une fois réécrit à l'aide du SRS, le MAIL FROM s'aligne désormais sur le domaine FROM, ce qui permet au DMARC passe à la destination finale.

Résultat : un e-mail malveillant qui devrait normalement échouer au contrôle DMARC finit par être transféré, réécrit par SRS et parfaitement aligné avec les enregistrements d'authentification du domaine de transfert. Il est donc livré au destinataire comme un message tout à fait légitime. En bref, l'usurpation d'identité par le biais du transfert d'e-mails redevient possible, annulant ainsi les protections que DMARC était censé fournir.

Microsoft ne considère actuellement pas cela comme une faille de sécurité.

Exemple de scénario

Imaginez qu'un pirate contrôle le domaine maliciousmailer.com, avec SPF configurés pour autoriser l'envoi depuis l'adresse IP 198.51.100.25. Il rédige un e-mail destiné à une consultante, Sarah, dont l'adresse e-mail professionnelle est [email protected], mais qui est automatiquement transférée vers sa boîte mail personnelle [email protected].

L'attaquant définit les en-têtes de l'e-mail comme suit :

• MAIL DE : [email protected]
• DE : Sarah [email protected] (faussé pour apparaître comme interne)
• À : [email protected]

Une fois envoyé, le message passe SPF , car le domaine MAIL FROM est contrôlé par l'attaquant. Lorsque l'e-mail arrive à company.com, Exchange Online le traite avec SRS : il ignore l'échec DMARC sur le champ FROM usurpé, réécrit le champ MAIL FROM pour l'aligner sur le domaine de transfert (par exemple, sarah+SRS=…@company.com) et le transfère vers la boîte aux lettres personnelle de Sarah.

Sur personalmail.com, DMARC passe désormais car le MAIL FROM réécrit et le FROM visible sont alignés. L'e-mail est livré dans la boîte de réception de Sarah en semblant légitime, contournant ainsi efficacement les protections qui auraient dû l'arrêter.

En bref, un message falsifié qui aurait dû être bloqué est désormais considéré comme fiable par le destinataire, ce qui illustre comment le SRS peut involontairement « blanchir » des e-mails malveillants.

Pourquoi LaunDroMARC est dangereux pour les organisations 

Cette vulnérabilité est dangereuse car les utilisateurs font naturellement confiance aux e-mails qui semblent provenir de leur propre organisation ou d'un domaine interne familier. Lorsque des e-mails malveillants sont transférés, ils contournent les contrôles de sécurité initiaux et arrivent sous une forme apparemment saine et légitime. 

Les pirates exploitent les règles de transfert prévisibles pour tirer parti de cette faille, tandis que les équipes de sécurité se concentrent souvent sur les menaces entrantes plutôt que sur les e-mails transférés. Cette faille ouvre donc la voie à des risques graves, notamment le vol de données sensibles, la collecte d'identifiants, le spear phishing interne et même les attaques par usurpation d'identité dans la chaîne d'approvisionnement.

Ce que Microsoft pourrait améliorer

Microsoft pourrait mettre en œuvre plusieurs mesures d'atténuation simples :

1. Ne réécrivez pas MAIL FROM via SRS si l'en-tête FROM appartient au domaine de transfert mais échoue au DMARC lors du premier saut.
2. Appliquez uniquement le SRS aux messages qui passent le DMARC de l'expéditeur.
3. Comparez les en-têtes Authentication-Results avant et après le transfert.
   S'ils ne correspondent pas, quarantine message quarantine .

Comment les organisations peuvent détecter LaunDroMARC

1. Le domaine de transfert (Exchange Online)

Vous pouvez repérer les abus potentiels en recherchant les e-mails dont le domaine MAIL FROM est externe, mais dont l'en-tête FROM semble appartenir à votre organisation. Ces messages présentent souvent un schéma de passage SPF échouant au DMARC : un signal d'alarme dans le contexte de la réécriture SRS. Lorsque ces mêmes messages sont ensuite transférés vers l'extérieur, cela devient un indicateur fort que vos règles de transfert sont utilisées pour relayer du contenu usurpé ou malveillant.

2. Le domaine du destinataire final

Si un e-mail présente une correspondance entre l'adresse FROM visible et le MAIL FROM réécrit, mais que le domaine MAIL FROM d'origine enfoui dans la valeur SRS ne correspond à aucun des deux, cela indique clairement que le message a été « blanchi » par transfert et qu'il s'agit peut-être d'un e-mail usurpé ou malveillant.

Le point de vue de PowerDMARC

En tant que plateforme dédiée au renforcement de l'authentification mondiale des e-mails, des problèmes tels que LaunDroMARC soulignent pourquoi la surveillance et la visibilité sont tout aussi importantes que l'application. Même lorsque des normes telles que DMARC sont correctement déployées, les lacunes dans la mise en œuvre chez les fournisseurs de messagerie peuvent créer des vulnérabilités échappant à votre contrôle.

PowerDMARC aide les organisations à :

• Analyser les résultats d'authentification à tous les niveaux
• Détecter les anomalies d'alignement et le comportement de transfert
• Recevez des alertes en temps réel sur les tentatives d'usurpation d'identité
• Comprendre comment les systèmes tiers traitent les e-mails transférés
• Surveiller le trafic interdomaines à la recherche de modèles d'usurpation d'identité
• Maintenir la visibilité sur les attaques qui exploitent les chaînes de transfert

Faites un essai gratuit ou programmez une démonstration avec l'un de nos experts internes pour commencer à protéger votre domaine dès aujourd'hui ! 

Réflexions finales

Le problème LaunDroMARC réouvre un vecteur d'attaque que DMARC était censé bloquer, rendant à nouveau possible l'usurpation de domaine interne via les e-mails transférés. Bien que Microsoft considère actuellement ce problème comme présentant un « faible risque », les compromissions observées dans le monde réel prouvent le contraire. 

Les organisations qui utilisent Microsoft 365 doivent être conscientes de cette faille de transfert et mettre en place des mesures de détection supplémentaires.

• À propos de
• Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des courriels chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

• Intégration PowerDMARC Splunk : visibilité unifiée pour la sécurité des e-mails - 8 janvier 2026
• Qu'est-ce que le doxxing ? Guide complet pour le comprendre et le prévenir - 6 janvier 2026
• Meilleures alternatives à Palisade Email - 31 décembre 2025