Repérer une fuite de données par Microsoft 365

Une fuite par Microsoft 365 se passe souvent de logiciel malveillant. Un compte compromis ou un utilisateur pressé suffit : une règle qui transfère le courrier, un lien ouvert à tous, une application à qui quelqu'un a répondu « Accepter ». Les trois laissent des traces, à condition de les chercher.

Les commandes de ce guide se lancent dans le module PowerShell Exchange Online (Connect-ExchangeOnline), avec un compte qui a les droits de lecture nécessaires.

#Avant tout : le journal d'audit unifié

Les vérifications ci-dessous reposent sur le journal d'audit unifié de Microsoft 365, consultable dans Microsoft Purview. Vérifiez qu'il est actif :

Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

True veut dire que le journal est actif. La durée de conservation des événements dépend de vos licences. Vérifiez-la dans Microsoft Purview avant d'en avoir besoin.

#1. Le courrier transféré vers l'extérieur

Le scénario classique de compromission de messagerie : l'attaquant obtient le mot de passe d'un compte et pose une règle qui copie le courrier vers une adresse externe. Souvent, la règle marque aussi les messages comme lus ou les supprime, pour que la personne ne voie rien. La règle continue de fonctionner après le changement de mot de passe.

Deux mécanismes sont à vérifier :

• le transfert réglé sur la boîte elle-même ;
• les règles de boîte de réception, créées dans Outlook par l'utilisateur ou par un attaquant.

Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } | Select-Object DisplayName, ForwardingSmtpAddress, DeliverToMailboxAndForward
Get-Mailbox -ResultSize Unlimited | ForEach-Object { Get-InboxRule -Mailbox $_.UserPrincipalName } | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo } | Select-Object MailboxOwnerId, Name, ForwardTo, RedirectTo, DeleteMessage, MarkAsRead

La seconde commande ouvre chaque boîte une à une. Sur plusieurs milliers de boîtes, comptez une longue attente.

Pour fermer la porte, réglez le transfert automatique vers l'extérieur dans la stratégie anti-spam sortante de Microsoft Defender. Désactivez-le pour tous, avec une stratégie à part pour les rares boîtes qui en ont besoin.

#2. Les liens de partage anonymes

Un lien « Tout le monde » sur SharePoint ou OneDrive s'ouvre sans connexion, par quiconque le reçoit ou le retrouve. Une rafale de liens créés en une heure par la même personne précède parfois un départ, ou suit une compromission.

Dans le centre d'administration SharePoint, rubrique des stratégies de partage, vérifiez :

1. le niveau de partage externe autorisé pour SharePoint et pour OneDrive ;
2. la durée de validité des liens « Tout le monde », si vous les gardez ;
3. le type de lien proposé par défaut, de préférence limité aux personnes de votre organisation.

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) -Operations AnonymousLinkCreated -ResultSize 1000 | Select-Object CreationDate, UserIds

#3. Les applications tierces autorisées

Quand un utilisateur clique sur « Accepter » dans la fenêtre de consentement d'une application, il lui ouvre un accès durable à ses données : courrier, fichiers, contacts. Changer le mot de passe n'y change rien, puisque l'accès passe par un jeton délivré à l'application. Certaines campagnes d'hameçonnage reposent sur ce seul clic (« consent phishing »).

Dans le centre d'administration Microsoft Entra, rubrique des applications d'entreprise :

1. Vérifiez qui a le droit de consentir. Le réglage le plus prudent limite les utilisateurs aux applications d'éditeurs vérifiés, pour des autorisations à faible risque, et envoie les autres demandes à un administrateur.
2. Parcourez la liste des applications. Pour chacune, les autorisations accordées disent ce qu'elle peut lire. Mail.Read, Mail.ReadWrite, Mail.Send et Files.Read.All méritent une explication.
3. Retirez les applications que personne ne reconnaît, après avoir vérifié qui s'en sert.

#Quand une fuite est confirmée

1. Exportez d'abord les événements du journal d'audit qui la montrent, puis supprimez la règle ou désactivez le lien.
2. Réinitialisez le mot de passe du compte et révoquez ses sessions dans Entra ID.
3. Vérifiez ses méthodes de double authentification, car un attaquant en ajoute parfois une à son nom.
4. Établissez ce qui est sorti : destinataire du transfert, fichiers ouverts par les liens, données lues par l'application.
5. Si des données personnelles sont touchées, voyez avec votre délégué à la protection des données. Le RGPD prévoit dans certains cas une notification à l'autorité sous 72 heures.

#Ce que FirstSI suit

Ouvrez Microsoft 365 (#/microsoft365), section Fuites. Il faut le connecteur Microsoft 365 avec ses droits de lecture, puis un administrateur qui clique sur Activer la collecte. FirstSI lit alors le journal unifié toutes les 15 minutes, les consentements toutes les 6 heures et les règles des boîtes une fois par jour. FirstSI ne lit pas le contenu des messages.

Les incidents arrivent dans le SIEM. À la première activation, les règles de transfert et les consentements déjà en place servent de référence, sans incident. Ils restent visibles dans la section Fuites, où vous pouvez les passer en revue une fois avec les étapes de ce guide.

Le droit MailboxSettings.Read est facultatif. Sans lui, seules les règles créées après l'activation sont vues. Voir Microsoft 365.

Pour la personne concernée, la fiche compte rassemble ses connexions, ses échecs et ses verrouillages, Microsoft 365 compris. Le pré-diagnostic des tickets regarde aussi les fuites de la personne quand un ticket parle de sécurité ou d'e-mails disparus.

#Pour aller plus loin

• Microsoft 365 : brancher le connecteur et comprendre une connexion refusée.
• Exposition vue d'Internet : les comptes de vos domaines cités dans des fuites publiques.
• SIEM : corrélation et incidents de sécurité : qualifier et suivre l'incident.

Présentation : Sécurité Microsoft 365 et exposition sur Internet↗

Source : · Docs FirstSI · mis à jour le 11/10/2026