Spotting a data leak through Microsoft 365

A leak through Microsoft 365 often needs no malware at all. A compromised account or a user in a hurry is enough: a rule that forwards mail, a link open to everyone, an application someone answered "Accept" to. All three leave traces, provided you look for them.

The commands in this guide run in the Exchange Online PowerShell module (Connect-ExchangeOnline), with an account that has the necessary read rights.

#First of all: the unified audit log

The checks below rely on the Microsoft 365 unified audit log, which you can search in Microsoft Purview. Check that it is on:

Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

True means the log is on. How long events are kept depends on your licences: check it in Microsoft Purview, before you need it.

#1. Mail forwarded outside

The classic business email compromise: the attacker obtains an account's password and sets up a rule that copies mail to an external address. Often the rule also marks the messages as read or deletes them, so that the person sees nothing. The rule keeps working after the password is changed.

Two mechanisms need checking:

• forwarding set on the mailbox itself;
• inbox rules, created in Outlook by the user or by an attacker.

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

The second command opens every mailbox one by one. With several thousand mailboxes, expect a long wait.

To close the door, set automatic forwarding to outside addresses in the Microsoft Defender outbound anti-spam policy: off for everyone, with a separate policy for the rare mailboxes that need it.

#2. Anonymous sharing links

An "Anyone" link on SharePoint or OneDrive opens without signing in, for whoever receives or finds it. A burst of links created within an hour by the same person sometimes comes before a departure, or after a compromise.

In the SharePoint admin center, under the sharing policies, check:

1. the level of external sharing allowed for SharePoint and for OneDrive;
2. how long "Anyone" links stay valid, if you keep them;
3. the link type offered by default, preferably limited to people in your organisation.

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

#3. Authorised third-party applications

When a user clicks "Accept" in an application's consent window, they give it lasting access to their data: mail, files, contacts. Changing the password changes nothing, since access goes through a token issued to the application. Some phishing campaigns rely on that single click ("consent phishing").

In the Microsoft Entra admin center, under enterprise applications:

1. Check who is allowed to consent. The most cautious setting limits users to applications from verified publishers, for low-risk permissions, and sends other requests to an administrator.
2. Go through the list of applications. For each one, the permissions granted say what it can read. Mail.Read, Mail.ReadWrite, Mail.Send and Files.Read.All call for an explanation.
3. Remove the applications nobody recognises, after checking who uses them.

#When a leak is confirmed

1. First export the audit log events that show it, then delete the rule or disable the link.
2. Reset the account's password and revoke its sessions in Entra ID.
3. Check its two-factor authentication methods: an attacker sometimes adds one of their own.
4. Establish what left: the forwarding recipient, the files opened through the links, the data read by the application.
5. If personal data is involved, talk to your data protection officer: in some cases the GDPR requires notifying the authority within 72 hours.

#What FirstSI follows

Open Microsoft 365 (#/microsoft365), Leaks section. You need the Microsoft 365 connector with its read permissions, then an administrator who clicks Enable collection. FirstSI then reads the unified log every 15 minutes, consents every 6 hours and mailbox rules once a day. FirstSI does not read message content.

Incidents arrive in the SIEM. On first activation, the forwarding rules and consents already in place serve as the baseline, with no incident. They remain visible in the Leaks section: review them once, with the steps in this guide.

The MailboxSettings.Read permission is optional. Without it, only rules created after activation are seen. See Microsoft 365.

For the person concerned, the account profile brings together their sign-ins, failures and lockouts, Microsoft 365 included. Ticket pre-diagnostics also looks at the person's leaks when a ticket mentions security or missing emails.

#Further reading

• Microsoft 365: connecting the connector and understanding a refused sign-in.
• Exposure seen from the Internet: accounts of your domains cited in public breaches.
• SIEM: correlation and security incidents: qualifying and following the incident.

Overview: Microsoft 365 security and Internet exposure↗

Source: · FirstSI Docs · updated 2026-10-11