Blocking Automatic Outbound Email Forwarding Rules

What it stops

This control shuts down the simplest way to steal data continuously; it goes after inbox rules that automatically forward copies of mail to external addresses. A low-skill attacker loves this because it builds a silent pipe for sensitive data, allowing them to walk away while information flows out on its own.

Why let them have that? Without this block, every new invoice or password reset and every confidential project update gets mirrored to an Outlook or Gmail account the adversary controls. If you block these rules at the gateway or set up alerts when they're made, you change the game. The attacker can't be lazy anymore, and they have to use methods that are harder to pull off and much easier for you to spot.

What it does not stop

Vendor brochures claim this secures the mailbox. They're wrong. This control only watches the rule engine; an attacker who has a compromised session token can just use the Microsoft Graph API to hit the mailbox directly. They call the messages endpoint to read and download mail in bulk. Since they never create a forwarding rule, no alert ever fires, and the data just leaves through HTTPS requests to the attacker's own infrastructure, skipping rule based detection entirely.

What happens when an attacker uses a two step hop? This control fails there too. They set up a rule to forward mail to another internal account that's been compromised and isn't watched as closely. That second account then sends the mail out. The first jump is internal so it's ignored, while the second jump stays hidden. Third party SaaS apps with authorized Mail.Read permissions also move data via API, and it looks like a normal business integration and avoids the inbox rule mechanism altogether. Security teams often assume that if there are no forwarding rules, no data left the building, and that is a common failure point in these incidents.

What it looks like when it is working

When a control actually works, it puts high-fidelity telemetry right into the SIEM; an analyst sees an alert triggered by New-InboxRule or Set-InboxRule operations in the Office 365 Unified Audit Log. The log entry points to a ForwardTo or RedirectTo parameter with a domain that doesn't match the corporate tenant list. If you've enabled blocking, the audit log shows the operation failed.

The alert gives you the requester's source IP address and the external email address they targeted. In a mature setup, this is tied to a risk score, and that score goes up if the user has done other weird things lately, like logging in from a country they don't live in. Is there any room for doubt? No. The signal is binary and clear: someone tried to move mail outside the organization; the log entry doesn't lie.

How to prove it

Set up a controlled test this quarter with its own mailbox. Log in as a standard user and use the web interface to build a new inbox rule; set that rule to forward all incoming mail to an external address, like a personal Gmail account. Write down the exact second you save it.

Watch the SIEM for an alert, and the test is a success if the alert shows up on the security dashboard within 15 minutes of creating the rule. What happens if the control blocks it? Then you need an immediate error message in the mailbox and a failed operation log in the audit trail to pass. Note the time difference between the creation and the alert. Document the Log Name and Event ID the system generates.