8.7 Transport Rules for Security

90 minutes · Module 8

Transport Rules for Security

By the end of this subsection, you will know the most effective transport rules for email security, understand how the Module 13 transport rules blocked Waves 4-5, and be able to create rules for your environment.

Transport rules (also called Exchange mail flow rules or Exchange Online protection rules in some documentation) process every email that flows through Exchange Online. They evaluate conditions and take actions before the email reaches the user’s mailbox — making them a powerful pre-delivery security control.

The four essential security transport rules

RuleWhat it doesImpact
External sender bannerPrepends a warning to all emails from external sendersUsers see “[EXTERNAL]” and a warning banner on every external email. Reduces impersonation success.
Phishing kit URL pattern blockBlocks emails containing URLs matching known phishing kit patternsPre-delivery blocking of phishing campaigns — zero user exposure
Attachment type blockBlocks emails with executable attachment types (.exe, .scr, .bat, .js, .vbs, .ps1)Prevents direct malware delivery via email
Lookalike domain blockBlocks external emails from domains containing your organization nameCatches impersonation domains (northgateeng.co, northgate-eng.com)

The Module 13 transport rules — how they blocked Waves 4-5

In Module 13, three transport rules were deployed during the incident:

Rule 1: URL pattern block. Condition: message body or URL matches /auth/[a-f0-9]{32}/login. Action: reject with NDR explaining the block. This caught the phishing kit’s URL structure regardless of which domain it was deployed on. Waves 4 and 5 used new domains but the same URL pattern — blocked before delivery.

Rule 2: External sender banner. Condition: sender is external. Action: prepend HTML banner. Users reported this helped identify Wave 5’s “project update” lure as external when the subject line implied internal communication.

Rule 3: Lookalike domain block. Condition: sender domain contains “northgate” AND sender is external. Action: reject. Caught all future domains matching the attacker’s naming pattern.

Transport rules fill the gap between Safe Links and manual blocking

Safe Links scans URLs at click time. Transport rules block emails before delivery. If you identify a phishing kit URL pattern, a transport rule prevents the email from ever reaching the inbox — users never see it, never click it. This is why detection maturity progressed from reactive (ZAP at 23 minutes) to preventive (transport rule at 0 minutes) across the Module 13 waves.

Creating the URL pattern block rule

  1. Navigate to Exchange admin center -> Mail flow -> Rules -> Add a rule
  2. Condition: “The subject or body includes” -> enter the URL pattern
  3. For regex patterns: use “The subject or body matches text patterns” -> enter the regex
  4. Action: Reject the message with the explanation -> “This email was blocked by a security transport rule. Contact IT if you believe this is an error.”
  5. Exceptions: None (or add specific senders if needed)
  6. Priority: Set high (lower number = higher priority)

Try it yourself

Your organization's name is "Meridian Financial." Write a transport rule condition that blocks external emails from domains containing "meridian" that are not your actual domain (meridianfinancial.com). Consider: what about legitimate partner domains that happen to contain "meridian"?

Condition: Sender domain contains "meridian" AND sender is external AND sender domain is NOT in (meridianfinancial.com, meridian-bank.com [legitimate partner]).

Action: Quarantine (not reject, because you want to review for false positives initially).

Start with quarantine for the first 2 weeks. Review quarantined emails daily. If zero false positives, switch to reject. The exception list for legitimate partner domains is critical — blocking a real business partner's email is worse than missing a phishing email.

Attachment type blocking rule

Block executable attachment types that have no legitimate business purpose in email:

Blocked file types: .exe, .scr, .bat, .cmd, .ps1, .vbs, .js, .wsf, .hta, .com, .pif, .reg

Configuration: Exchange admin center -> Mail flow -> Rules -> “Block dangerous attachment types” -> Condition: Any attachment file extension includes [list above] -> Action: Reject message with explanation.

This rule has near-zero false positive risk

Legitimate business communication almost never involves sending .exe or .ps1 files via email. If your organization has a specific workflow that requires it (rare), create a narrow exception for those specific senders/recipients. For everyone else, block.

Monitoring transport rule effectiveness

1
2
3
4
5
6
7
8
9
// Check which transport rules are firing and how often
EmailEvents
| where TimeGenerated > ago(30d)
| where DeliveryAction == "Blocked"
| where DetectionMethods has "Transport rule"
| summarize BlockCount = count(), UniqueRecipients = dcount(RecipientEmailAddress)
    by Subject = tostring(split(Subject, " ")[0]), SenderMailFromDomain
| sort by BlockCount desc
| take 10
Expected Output
Subject (first word)SenderMailFromDomainBlockCountUniqueRecipients
Newnorthgate-benefits.com1515
Projectnorthgate-projects.com3131
What to look for: Your transport rules caught Wave 4 (15 emails from northgate-benefits.com) and Wave 5 (31 emails from northgate-projects.com) — pre-delivery blocking with zero user exposure. This confirms the URL pattern and lookalike domain rules from Module 13 are working.

Check your understanding

1. Why is the URL pattern (/auth/[hash]/login) a more effective transport rule than blocking the phishing domain?

The domain changes every wave (northgate-voicemail.com, northgate-docs.com, etc). The URL pattern is generated by the phishing kit code and stays consistent across all domains. One transport rule catches all waves, regardless of which domain the attacker registers next.
URL patterns are harder for attackers to see
Transport rules cannot block domains