compromised account created hidden forwarding rule; mail audit alert failed to fire

TL;DR

Attackers hide rules by naming them innocuously, moving mail to obscure folders like RSS feeds, and deleting or forwarding copies so the victim sees nothing. If no alert fired, the audit configuration is the first suspect: mailbox auditing or the specific rule-creation events may not be enabled or retained long enough. Turn on the right auditing, then sweep every mailbox for rules matching the attacker pattern.

compromised account created hidden forwarding rule; mail audit alert failed to fire

Use this when

• A mailbox is found with a rule forwarding or hiding mail that the user never created.
• An account compromise is confirmed but the audit log shows no rule alert.

Not for this skill when

• The rule is the user own, created in a recorded change. Close it as benign with evidence.
• No compromise is suspected and this is a routine rule tidy-up. Use standard mailbox management.

Steps

1. Preserve evidence first: export the mailbox rules and relevant audit events before removing anything. Verify: the rule definition and timestamps are saved to the case.
2. Check audit configuration for the tenant: unified audit on, mailbox rule events captured, and the alert policy for rule creation enabled and assigned. Verify: each audit layer state is known.
3. Enable or fix the missing layer, noting that new auditing only captures future events. Verify: the setting change is recorded with its scope.
4. Sweep all mailboxes for rules that forward externally, delete, or move mail to low-visibility folders, and review matches with owners. Verify: the tenant-wide sweep completes and suspicious rules are listed.
5. Remove confirmed malicious rules, reset credentials and revoke sessions for affected accounts, then test the alert with a controlled rule creation. Verify: the alert now fires within its expected window.

Variant phrasings

hidden inbox rule compromised account audit alert

The hidden rule variant.

mailbox forwarding rule sweep attacker pattern powershell

The sweep variant.

Compatibility: Microsoft 365 unified audit log and alert policies, Exchange mailbox rule auditing.

Why it happens

Alert policies only fire on events the audit pipeline records. Rule creation inside a mailbox is a detail many tenants never confirmed was captured, so the attacker favourite persistence move happens in a logging blind spot.

Edge cases / pitfalls

• Attackers also use transport-level and client rules. Sweep both mailbox rules and mail flow rules.
• Rules that mark mail as read and move it are as dangerous as forwarding rules. Include them in the pattern.
• Audit retention windows are finite. Export compromise evidence early in every investigation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_r3Jq6hQMTJlYLwunrKP7Kw