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

⚠️
La fonctionnalité est actuellement en public preview, donc attention avant de la mettre en production.

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

banner-Bastien Perez
Bastien Perez's avatar

Freelance Microsoft 365 - Active Directory - Modern Workplace

France