Lion Cipher Lab

Detect malicious mailbox auto-forwarding and inbox rules (BEC)

• SOC Analyst / Blue Team
• Intermediate
• ~45 min
• Free · no account required

Why it matters

Business Email Compromise (BEC) is one of the most expensive attacks in the world, and its most damaging move is almost silent. A user gets phished, the attacker signs in, and then -- instead of doing anything loud -- they reach for the mailbox's own features. They add an AUTO-FORWARD so every message the victim receives is quietly copied to an outside address, and they add INBOX RULES that delete or hide the replies that would blow their cover, so when a colleague writes back 'wait, is this wire request real?' the victim never sees it. Microsoft lists exactly this -- inbox rules that forward…

What you'll learn

• reading a mail provider's audit log (modelled on the Microsoft 365 Unified Audit Log) and naming the operations that matter -- New-InboxRule, Set-InboxRule, UpdateInboxRules for inbox rules, and Set-Mailbox (ForwardingSmtpAddress) for mailbox-level forwarding -- and understanding that those are TWO distinct telemetry sources
• explaining why malicious mailbox rules are the quiet persistence-and-exfiltration stage of Business Email Compromise (BEC): forward the mail out, then delete or hide the copies so the victim never notices (MITRE ATT&CK T1114.003 Email Forwarding Rule and T1564 Hide Artifacts)
• seeing WHY the naive rule ('any New-InboxRule or any forwarding = alert') fails twice at once: against the seeded log it fires 14 times with 11 benign false positives AND still misses a real attack, because most inbox rules are harmless filing and legitimate users forward their own mail
• writing a structured detector in pure Python (csv, re) that scores risk from concrete features -- external forward/redirect target, a rule that also deletes or marks-as-read, keyword filters on money/credential words, mail filed into classic hiding spots, and a mailbox-level external forward -- and measuring it lift true positives 3 -> 4 while cutting false positives 11 -> 2
• proving the forward-centric blind spot with numbers: a careful attacker who only marks money mail read and moves it to RSS Feeds with NO forward at all evades any forward-keyed detector (it misses 1 of the 4 real attacks), so chasing only the forward moves the gap instead of closing it
• proving the telemetry blind spot with numbers: a detector that reads only inbox-rule operations never sees ForwardingSmtpAddress set by Set-Mailbox, so it misses the mailbox-level forward (1 of 4) -- two sources, and dropping one leaves a hole
• keeping the honest false positives: legitimate accounts-payable and procurement users who forward externally and filter on invoice/wire/payment look exactly like BEC to a feature scorer, leaving 2 false positives this data cannot clear -- so a flag is a reason to investigate, never a conviction
• pinning the whole thing in a deterministic seed script so every count is reproducible -- the same discipline a real detection rule needs so its alerts can be defended and re-tested

Steps in this lab

1. What a malicious mailbox rule is -- every term, defined once
2. The naive rule, and why it fails twice at once
3. Seed a realistic mail audit log
4. Write the detector -- four views of the same log
5. Measure the BEFORE: the naive rule floods and still misses one
6. Measure the structured detector -- more true positives, far fewer false
7. The honest negatives, measured: the evader, the blind spot, the FP you keep
8. When to trust this signal -- and when it lies
9. What you built -- and the reflex to keep

Open the full interactive lab →