La cybersécurité ressemble parfois à un jeu d’équilibriste permanent entre facilité d’usage et protection. Microsoft 365 nous en offre aujourd’hui un parfait exemple avec sa fonctionnalité « Direct Send« , conçue pour simplifier l’envoi d’emails depuis les équipements internes, mais qui se révèle être une porte d’entrée idéale pour les cybercriminels.
Comprendre Direct Send : une fonctionnalité mal comprise
Pour bien saisir l’ampleur du problème, il faut d’abord comprendre ce qu’est Direct Send et pourquoi Microsoft l’a créé. Imaginez une imprimante de bureau qui doit envoyer un scan par email, ou un serveur de monitoring qui transmet des alertes automatiques. Ces équipements ne sont pas des clients de messagerie sophistiqués comme Outlook, ils ont besoin d’un moyen simple d’envoyer des emails sans passer par des configurations complexes d’authentification.
Direct Send répond à ce besoin en permettant « d’envoyer des emails directement vers les boîtes aux lettres hébergées d’Exchange Online depuis des appareils locaux, des applications ou des services cloud tiers en utilisant le domaine accepté du client ». Le principe semble logique : ces emails internes n’ont pas besoin d’authentification puisqu’ils proviennent de l’environnement de l’entreprise elle-même.
Le problème fondamental réside dans cette absence d’authentification. Cette méthode « ne nécessite aucune forme d’authentification car, par nature, elle imite les emails anonymes entrants d’internet, à l’exception du domaine de l’expéditeur ». Microsoft a supposé que les administrateurs configureraient correctement les protections SPF, DKIM et DMARC pour sécuriser cette fonctionnalité, mais la réalité du terrain est bien différente.
L’exploitation malveillante : une technique redoutablement efficace
Les recherches menées par l’équipe de Varonis ont révélé comment cette fonctionnalité est détournée à des fins malveillantes. Plus de 70 entreprises, principalement américaines, ont déjà été ciblées par des attaquants qui « se font passer pour des utilisateurs internes et diffusent des messages de phishing sans compromettre de comptes ».
La technique est d’une simplicité déconcertante. Les cybercriminels n’ont besoin que de deux éléments facilement accessibles : le nom d’hôte au format standard de l’organisation cible (généralement sous la forme tenantname.mail.protection.outlook.com) et une adresse email valide de l’entreprise. Ces informations sont souvent disponibles publiquement sur les sites web, les réseaux sociaux ou dans des bases de données de violations antérieures.
Une fois ces éléments en possession, les attaquants peuvent envoyer des emails qui semblent provenir de l’intérieur de l’organisation. Dans les campagnes analysées, « les cybercriminels ont utilisé un script PowerShell pour diffuser de faux messages de messagerie vocale, accompagnés d’un fichier PDF contenant un QR code » qui redirige vers des sites de vol d’identifiants.
Pourquoi cette attaque est-elle si dangereuse ?
L’efficacité de cette technique repose sur plusieurs facteurs psychologiques et techniques qui la rendent particulièrement redoutable. Premièrement, ces emails sont traités comme des messages internes légitimes par l’infrastructure Microsoft 365, ce qui leur permet d’échapper aux filtres de sécurité traditionnels qui se basent sur l’authentification, la réputation de l’expéditeur ou les schémas de routage habituels.
Deuxièmement, ils exploitent la confiance naturelle que nous accordons aux communications internes. Comme l’explique Ensar Seker, RSSI chez SOCRadar : « Les employés sont habitués à recevoir des notifications de documents numérisés, qu’ils ne remettent que rarement en question ». Cette familiarité avec les notifications d’équipements bureautiques crée un climat de confiance que les attaquants exploitent habilement.
Le caractère technique de l’attaque la rend également difficile à détecter pour des utilisateurs non avertis. Les emails passent par l’infrastructure officielle de Microsoft, utilisent des domaines légitimes de l’entreprise, et ne montrent pas les signes d’alerte habituels des tentatives de phishing externes.
La réponse de Microsoft : Reject Direct Send
Face à cette menace croissante, Microsoft a développé une solution technique appelée « Reject Direct Send« . Cette fonctionnalité « bloquera tout trafic qui répond à ces conditions » en évaluant si « le domaine d’envoi est un domaine accepté dans votre tenant ».
La mise en œuvre de cette protection nécessite une intervention manuelle de l’administrateur via PowerShell. La commande à exécuter est relativement simple :
Set-OrganizationConfig -RejectDirectSend $true
Une fois activée, « tout message Direct Send reçu verra le message suivant :
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources".
Il est important de noter que le changement « devrait se propager à l’ensemble de notre service dans les 30 minutes », mais les administrateurs doivent anticiper d’éventuelles perturbations pour les équipements légitimes qui utilisent cette fonctionnalité.
Les défis de l’implémentation
L’activation de Reject Direct Send n’est pas sans risques pour les organisations qui utilisent légitimement cette fonctionnalité. Microsoft met en garde contre un scénario de transfert particulier qui pourrait être affecté. Si « quelqu’un de votre organisation envoie un message à un tiers et que celui-ci le transfère à une autre boîte aux lettres de votre organisation » et que « le fournisseur de messagerie du tiers ne prend pas en charge le Sender Rewriting Scheme (SRS), le message reviendra avec l’adresse de l’expéditeur original ».
Cette complexité explique pourquoi Microsoft propose cette fonctionnalité en tant que préversion publique et sollicite activement les retours des administrateurs. L’objectif est de valider le fonctionnement dans des environnements réels avant un déploiement généralisé.
Pour les organisations qui ne sont pas prêtes à bloquer complètement Direct Send, Microsoft recommande de « créer une règle de transport qui met en quarantaine ou redirige tous les emails qui ne proviennent pas des adresses IP distantes que vous avez approuvées ». Cette approche offre un compromis entre sécurité et continuité opérationnelle.
Recommandations pratiques pour les administrateurs
L’implémentation d’une protection efficace contre l’exploitation de Direct Send nécessite une approche méthodique. La première étape consiste à auditer votre environnement actuel pour identifier tous les équipements et applications qui utilisent cette fonctionnalité. Microsoft suggère qu’un « bon point de départ serait l’enregistrement SPF de votre domaine » car « tout expéditeur utilisant Direct Send sans faire partie de l’enregistrement SPF du domaine accepté aura déjà du mal à faire livrer les messages avec succès dans les boîtes de réception des destinataires ».
Pour les organisations utilisant Microsoft Defender for Office 365, il est possible d’utiliser « Threat Explorer et Advanced Hunting pour générer des rapports supplémentaires » qui permettent d’identifier précisément le trafic Direct Send des 30 derniers jours.
Une fois l’audit terminé, l’activation de Reject Direct Send peut être planifiée en coordination avec les équipes métier. Pour les équipements légitimes qui doivent continuer à utiliser cette fonctionnalité, la solution consiste à « créer un connecteur de flux de messagerie partenaire qui correspond au certificat (recommandé) ou aux adresses IP utilisées pour envoyer les messages ».
L’évolution future : sécurité par défaut
Microsoft a annoncé son intention de renforcer la sécurité par défaut des nouveaux tenants. L’entreprise « prévoit d’activer cette fonctionnalité à l’avenir pour les nouveaux tenants par défaut » dans le cadre de ses « efforts pour rendre vos organisations plus sûres par défaut ». Plus significatif encore, le plan « inclut que les nouveaux tenants ne pourront pas désactiver cette fonctionnalité alors que nous cherchons à dissuader l’utilisation du trafic Direct Send non authentifié ».
Cette évolution marque un changement de philosophie important chez Microsoft, qui privilégie désormais la sécurité par défaut plutôt que la facilité de configuration. Pour les organisations existantes, cela signifie qu’il est temps d’anticiper cette transition et de mettre en place dès maintenant les protections nécessaires.
Au-delà de Direct Send : repenser la sécurité des communications internes
Cette vulnérabilité soulève des questions plus larges sur notre perception de la sécurité des communications internes. Comme le souligne Ensar Seker : « Cette faille illustre parfaitement le compromis constant entre simplicité et sécurité ». Direct Send avait été conçu pour faciliter l’intégration des équipements bureautiques, mais cette commodité est devenue un risque lorsqu’elle n’est pas correctement comprise et configurée.
L’exploitation de Direct Send nous rappelle qu’aucune communication ne doit être considérée comme intrinsèquement sûre, même au sein de l’infrastructure interne d’une organisation. Les principes de sécurité Zero Trust, qui préconisent de vérifier systématiquement l’identité et les autorisations avant d’accorder l’accès aux ressources, trouvent ici une nouvelle application.
Les administrateurs doivent également renforcer la sensibilisation des utilisateurs aux nouvelles techniques d’attaque. Une « sensibilisation des utilisateurs aux attaques par QR code, aussi appelées ‘quishing’, est également conseillée », car ces techniques exploitent des vecteurs d’attaque moins familiers que les liens traditionnels.
Conclusion : agir maintenant pour protéger demain
La vulnérabilité de Direct Send illustre parfaitement les défis de sécurité de l’ère cloud. Des fonctionnalités conçues pour simplifier les opérations peuvent devenir des vecteurs d’attaque sophistiqués lorsqu’elles ne sont pas correctement sécurisées. Comme le résume un expert : « Si l’on ignore ce que les appareils peuvent faire ou ce qu’ils sont autorisés à faire, il devient difficile de les sécuriser ».
Pour les administrateurs Microsoft 365, le message est clair : l’évaluation et la sécurisation de Direct Send ne peuvent plus être reportées. Que vous choisissiez d’activer immédiatement Reject Direct Send ou d’opter pour une approche progressive avec des règles de transport, l’inaction n’est plus une option viable.
Cette situation nous rappelle également l’importance de maintenir une veille technologique active et de questionner régulièrement les configurations par défaut de nos environnements. Dans un paysage de menaces en constante évolution, ce qui était considéré comme sûr hier peut devenir un risque critique aujourd’hui.
L’avenir de la sécurité Microsoft 365 semble s’orienter vers des paramètres plus restrictifs par défaut, une évolution que nous ne pouvons qu’encourager. En attendant, il appartient à chaque organisation de prendre les mesures nécessaires pour protéger son environnement de messagerie contre ces nouvelles formes d’exploitation.
M365 Journey 
Laisser un commentaire