Skip to content

Des attaquants exploitent Microsoft 365 : comment rester protégé

Des cyberattaquants exploitent des fonctionnalités légitimes de Microsoft 365 pour contourner les contrôles de sécurité. Voici à quoi ressemblent ces attaques et comment les stopper.

Jack Lilley·Sr. Comms & Content Marketing Manager
Published: July 29, 2025·Updated: August 6, 2025·5 min read

Résumé exécutif : Varonis a mis au jour une campagne de phishing active qui usurpe l'identité d'utilisateurs internes en exploitant la fonctionnalité Direct Send de Microsoft 365. Comme Direct Send ne nécessite pas d'authentification et est traité comme « interne », ces messages contournent souvent les contrôles sur lesquels vous vous appuyez pour le courrier externe. Microsoft propose désormais une option d'activation, RejectDirectSend, pour bloquer cette voie, mais l'activer sans préparation peut perturber les imprimantes, scanners et applications métier qui dépendent encore de Direct Send.

Points clés à retenir

  • Direct Send permet à n'importe quel hôte au sein de Microsoft 365 d'envoyer des e-mails à vos utilisateurs sans authentification. Les cyberattaquants l'utilisent pour usurper l'identité de collègues et échapper aux contrôles du courrier externe.
  • Cette campagne, active depuis mai 2025, a déjà ciblé plus de 70 organisations dans divers secteurs.
  • Le nouveau commutateur RejectDirectSend de Microsoft bloque ce vecteur, mais peut casser des appareils qui dépendent encore de Direct Send. Testez avant de l'appliquer.

Quel est le problème ?

Direct Send existe pour permettre aux appareils et applications d'envoyer des e-mails aux personnes au sein de votre tenant Microsoft 365 sans authentification. Pensez aux imprimantes multifonctions qui numérisent vers e-mail, aux outils de surveillance qui envoient des alertes, ou aux applications héritées qui n'ont jamais été mises à jour pour utiliser SMTP Auth.

Les attaquants ont réalisé qu'ils pouvaient utiliser cette même voie non authentifiée pour déposer des messages de phishing directement dans les boîtes de réception en usurpant l'identité de vrais collègues. Comme le trafic reste à l'intérieur de l'infrastructure de Microsoft, de nombreux contrôles orientés vers l'extérieur, tels que les bannières, les mises en quarantaine, voire certaines vérifications Domain-based Message Authentication, Reporting, and Conformance (DMARC) n'entrent jamais en jeu. Cette technique a été utilisée contre plus de 70 organisations depuis mai 2025, et rien n'indique qu'elle ralentit.

Pourquoi est-ce important pour les clients de Red Sift ?

Premièrement, la confiance interne est puissante. Vos utilisateurs sont conditionnés à se détendre lorsqu'un e-mail semble provenir des « RH » ou de l'« informatique » et utilise un nom d'affichage et une adresse internes. Cela rend les taux de clics et la capture d'identifiants bien plus probables.

Deuxièmement, DMARC protège le périmètre ; il est excellent pour stopper les usurpations exactes de domaine provenant d'Internet, mais un message injecté via Direct Send peut sembler parfaitement aligné car il ne quitte jamais le cloud Microsoft. Troisièmement, de nombreuses solutions de détection sont paramétrées pour scruter le courrier externe. Si vos règles SIEM, vos politiques SEG ou la formation de vos utilisateurs se concentrent sur « de l'extérieur vers l'intérieur », le trafic d'apparence interne peut passer inaperçu. Enfin, une remédiation précipitée peut être néfaste : si vous bloquez simplement Direct Send sans plan de migration, des flux de travail critiques pour l'entreprise pourraient échouer silencieusement.

Ce que cela pourrait signifier pour le courrier légitime et comment éviter les dysfonctionnements

Bloquer Direct Send sans préparation peut avoir des effets secondaires bien réels. Les imprimantes multifonctions peuvent cesser de livrer des PDF numérisés vers des boîtes aux lettres partagées. Les systèmes métier pourraient échouer silencieusement à envoyer des factures ou des tickets de support. Les outils de sécurité et de surveillance pourraient perdre leur canal de notification par e-mail, créant des angles morts dans les alertes. Même après la migration, n'oubliez pas que SMTP Auth et les connecteurs relais ont leurs propres limites de débit et de taille ; planifiez la capacité en conséquence et surveillez les journaux pour détecter les limitations ou erreurs.

Comment agir rapidement et en toute sécurité

Commencez par découvrir qui et quoi utilise encore Direct Send dans votre environnement. Effectuez des traces de messages ou des recherches de journaux pour le trafic atteignant votre tenant sans résultats d'authentification, et croisez ces données avec un inventaire simple : imprimantes, scanners, outils de surveillance, systèmes ERP ou de billetterie, scripts personnalisés. Attendez-vous à des surprises, les anciens flux de travail ont tendance à perdurer.

Une fois cette liste établie, migrez les expéditeurs légitimes. L'option la plus propre consiste à faire passer les appareils et applications vers une soumission client SMTP Auth via le port 587 avec un compte de service dédié. Si possible, allez plus loin et mettez en place un connecteur lié à un certificat qui n'accepte que le courrier provenant d'IP ou d'identités TLS connues. Ces deux options vous offrent l'authentification, la journalisation et le contrôle des limites de débit que Direct Send n'a jamais fournis.

Une fois ces méthodes validées, bloquez la voie d'abus. Le nouvel indicateur à l'échelle du tenant de Microsoft fait exactement cela :

Code
Set-OrganizationConfig -RejectDirectSend $true

Déployez-le dans un groupe pilote ou pendant une fenêtre de maintenance, surveillez les NDR ou les baisses soudaines du courrier attendu, et gardez la possibilité de revenir en arrière à portée de main. Traitez cela comme tout autre changement pouvant affecter les processus métier.

Le renforcement ne devrait pas s'arrêter à la couche de transport. Assurez-vous que vos domaines principaux sont en application DMARC (p=reject) et que vous surveillez activement les anomalies. Nous recommandons de vérifier les en-têtes des e-mails potentiellement suspects. Si vous avez besoin d'aide pour atteindre l'application DMARC, Red Sift OnDMARC simplifie la mise en œuvre, vous offrant une tranquillité d'esprit en aussi peu que 6 à 8 semaines. De plus, ajoutez des détections pour les leurres spécifiques observés dans cette campagne (par exemple, les thèmes « nouveau message vocal » ou les pièces jointes contenant des QR codes) et rappelez aux utilisateurs que « interne » ne garantit plus « sûr ».

Vous ne savez pas vraiment par où commencer ? Vérifiez votre statut DMARC et la sécurité de votre domaine gratuitement avec Red Sift Investigate.

Jack Lilley
Jack Lilley
Sr. Comms & Content Marketing Manager

Jack leads content, PR, GEO, and email security research at Red Sift.