Introduction
Le 27 Juin 2025, Varonis a publié un article qui indique que Direct Send est utilisé par des attaquants (https://www.varonis.com/blog/direct-send-exploit).
Personnellement, en lisant leur article je me suis juste dit "rien de bien nouveau, je montrais déjà ça à mes apprentis en 2016 !".
Ce n'est pas la qualité de l'article de Varonis (qui est bien documenté) que je remets en question. Ce qui m'étonne, c'est que tout le monde semble découvrir avec stupeur qu'il est effectivement possible d'envoyer un e-mail anonyme à son tenant.
Un petit point s'impose.
Fonctionnalité Direct Send
La fonctionnalité Direct Send dans Exchange Online n'a rien de nouveau : elle existe depuis toujours sur Exchange Online.
Elle repose sur l'utilisation du smart host de votre tenant (votre MX company-com.mail.protection.outlook.com
) qui accepte les emails de n'importe quelle source externe.
Elle est documentée sur https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365
Prérequis de Direct Send
- Utilisation du port 25 (TCP)
- Utilisation d'une adresse expéditeur appartenant à un domaine accepté dans Exchange Online
- IP publique incluse dans le SPF du domaine (pas obligatoire mais hautement conseillé)
Limites de Direct Send
- Impossible d'envoyer des mails vers des destinataires externes au tenant
- Risque de blocage si l'IP est sur une liste noire
- Throttling appliqué par Microsoft pour protéger le service
- Messages traités comme des courriels anonymes (analyses et protections SPF, DKIM, DMARC s'appliquent)
Problème du Direct Send (depuis toujours)
Si un attaquant peut envoyer un email depuis une IP publique autorisée dans votre SPF, il pourra utiliser Direct Send pour usurper n'importe quelle adresse de votre tenant.
Donc, si vous avez inclus l'IP publique de votre réseau d'entreprise : c'est la porte ouverte aux abus.
Il faut bloquer l'envoi SMTP(s) non contrôlé et limiter la liste des IP internes (applications, MFP).
Problème remonté par Varonis
Dans l'article de Varonis (lien en début de cet article), le point 4 est remis en cause (Messages traités comme des courriels anonymes) :
Etant donné que le courrier électronique est acheminé via l'infrastructure de Microsoft [...] il peut contourner les contrôles traditionnels de sécurité du courrier électronique
NDLR : traduit de l'anglais
Je ne sais pas si Microsoft a changé quelque chose, mais sur tous mes tenants, ce type de mail finit en courrier indésirable. Ça ne semble pas contourner les contrôles, donc je vois pas vraiment où il y a un problème (mais peut-être que mes tenants sont suffisament configurés pour ne pas avoir ce problème).
Je ne sais pas si Microsoft a changé quelque chose, mais sur tous mes tenants, ce type de mail finit en courrier indésirable. Je ne constate donc pas de contournement des contrôles.
Peut-être car mes tenants sont peut-être suffisamment bien configurés pour éviter ce problème (si vous avez de l'info je suis preneur).
Quoi qu'il en soit, vous pouvez augmenter la sécurité de votre tenant en bloquant Direct Send.
Bloquer Direct Send
Bloquer Direct Send nécessite des droits administrateur Exchange et le module ExchangeOnlineManagement
https://www.powershellgallery.com/packages/exchangeonlinemanagement
Connect-ExchangeOnline
Set-OrganizationConfig -RejectDirectSend $true
Une fois configuré, si quelqu’un envoie depuis un de vos domaines approuvés vers votre tenant, il recevra ce message d’erreur :
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources
Les mails envoyés depuis des domaines externes restent traités comme des mails classiques et ne seront donc pas bloqués.
Rapports Direct Send
Avant d'activer ce blocage, vous voudrez sans doute savoir si des e-mails sont envoyés via Direct Send. Malheureusement, à ce jour, Microsoft ne fournit aucun rapport permettant d’identifier les messages reçus par cette méthode.
Note finale
Beaucoup aimeraient bloquer tout envoi anonyme (non authentifié) sur le MX. C'est impossible : pour recevoir les mails du monde entier en SMTP, il faut accepter les connexions non authentifiées. Bloquer cela reviendrait à bloquer le courrier entrant.
Comments