9.1 Email Threat Landscape and Architecture

Email Threat Landscape and Defender for Office 365 Architecture

By the end of this subsection, you will understand the email protection stack, the difference between EOP and Defender for Office 365, and how P1 and P2 capabilities differ.

Email is the #1 attack vector

Over 90% of successful cyberattacks begin with email. Phishing delivers credentials to attackers. Malicious attachments deliver malware. Business email compromise tricks finance teams into wiring money. Every other security control you have configured — endpoint protection, conditional access, Sentinel analytics — is secondary to email protection. If the phishing email never reaches the inbox, the attack chain never starts.

The protection stack

Email passes through multiple layers before reaching the user. Understanding this stack tells you where each threat is caught — and where gaps exist.

P1 vs P2 — what you get at each level

P2 is included in M365 E5. P1 is included in M365 Business Premium and available as an add-on to E3. The investigation scenarios in this course (Modules 13-22) require P2 for Threat Explorer and the full email investigation workflow.

Where Module 14’s attack bypassed protection

In the AiTM investigation (Module 14), the phishing email passed through every layer:

• Connection filter: sender IP was clean (newly registered domain, fresh IP)
• Anti-malware: no attachment (URL only)
• Anti-spam: low spam confidence (personalized content, no bulk indicators)
• Anti-phishing: domain was not impersonating a known sender
• Safe Links: URL was behind a Cloudflare CAPTCHA (automated detonation saw the CAPTCHA, not the phishing page)
• ZAP: caught 4 of 23 emails after 23 minutes (verdict update delay)

The attack exploited the gap between automated analysis (which was blocked by the CAPTCHA) and human interaction (which bypassed it). This module teaches you to configure every layer optimally and understand what each layer can and cannot catch.

Email attack types you will encounter

Understanding the attack types helps you configure the right policies:

The email investigation data model

Every email protection tool in this module produces data that flows into the same tables in Microsoft Sentinel and Defender XDR Advanced Hunting. Understanding the data model before configuring policies tells you what telemetry each policy generates.

Cross-table investigation pattern. Module 12 (AiTM) uses all six tables in sequence: EmailEvents (find the phishing email) → EmailUrlInfo (extract the phishing URL) → UrlClickEvents (find who clicked) → EmailPostDeliveryEvents (check if ZAP removed it) → SigninLogs (check if the clicker was compromised). The email tables are the starting point for every phishing investigation.

1
2
3
4
5
6
7
8

// Verify all email tables are populated (run after connector configuration)
union
    (EmailEvents | where TimeGenerated > ago(1d) | summarize count() | extend Table = "EmailEvents"),
    (EmailUrlInfo | where TimeGenerated > ago(1d) | summarize count() | extend Table = "EmailUrlInfo"),
    (UrlClickEvents | where TimeGenerated > ago(1d) | summarize count() | extend Table = "UrlClickEvents"),
    (EmailAttachmentInfo | where TimeGenerated > ago(1d) | summarize count() | extend Table = "EmailAttachmentInfo"),
    (EmailPostDeliveryEvents | where TimeGenerated > ago(1d) | summarize count() | extend Table = "EmailPostDeliveryEvents")
| project Table, count_

Run this after enabling the Defender connector in Sentinel (Module 8.3). Any table showing zero: the connector is not ingesting that table, or the protection feature that populates it is not enabled. Fix the gap before proceeding — investigation queries that reference empty tables return misleading zero results.

The cost of getting email protection wrong

Each configuration decision in this module has a direct impact on investigation capability:

Safe Links disabled → UrlClickEvents empty → you cannot determine who clicked a phishing URL during an AiTM investigation. You know who received the email (EmailEvents) but not who interacted with it. The investigation scope expands to “everyone who received the email” instead of “the 6 people who clicked.”

Safe Attachments disabled → EmailAttachmentInfo has no sandbox verdicts → you rely entirely on signature-based malware detection (EOP). A zero-day attachment passes undetected. You discover the malware only when Defender for Endpoint detects the executed payload — by which time the endpoint is compromised.

ZAP disabled → EmailPostDeliveryEvents shows no automated remediation → phishing emails that are clean at delivery but later identified as malicious remain in inboxes indefinitely. The window between verdict change and user click has no automated safety net.

Email authentication not configured → spoofed email from your domain reaches external partners → your organisation’s reputation is damaged, and your partners may be compromised by email appearing to come from you.

Every subsection in this module closes one of these gaps. By the end, all six email tables are populated, all protection layers are active, and the investigation data model is complete.

Defender for Office 365 licensing decision matrix

The licensing question determines what protection you have. Use this decision matrix to assess your environment:

E3 (EOP only): You have: connection filtering, anti-malware, anti-spam, basic anti-phishing (spoof detection), and ZAP. You do NOT have: Safe Links, Safe Attachments, advanced impersonation protection, Threat Explorer, AIR, or Campaign Views. Your email investigation capability is limited to KQL queries against EmailEvents (if the Defender connector is enabled in Sentinel). Recommendation: Add Defender P1 as an add-on (approximately £1.50/user/month). The ROI on Safe Links alone justifies the cost — one prevented AiTM compromise saves months of investigation and remediation effort.

E5 / Business Premium / Defender P2 add-on: You have everything. Configure all subsections in this module. Use Threat Explorer and AIR for investigation and response. Build the 8-tile email protection dashboard from subsection 9.9.

Mixed licensing: Some users on E3, some on E5. Safe Links and Safe Attachments only protect E5-licensed users. Create a conditional approach: apply aggressive transport rules (subsection 9.7) to E3 users to partially compensate for the missing Defender features. Prioritise E5 licensing for: finance team, executives, IT admins, and anyone in the protected users list from subsection 9.2.

1
2
3
4
5
6
7
8
9

// Assess: are all users protected by Defender for Office 365?
// Check: are Safe Links events appearing for all users?
UrlClickEvents
| where TimeGenerated > ago(30d)
| summarize ProtectedUsers = dcount(AccountUpn)
| extend TotalMailboxes = toint(
    // Compare against total mailbox count from Azure AD
    // This requires cross-referencing with your user inventory
    0) // Replace with your known mailbox count

If ProtectedUsers is significantly lower than your total mailbox count: some users are not covered by Safe Links — either unlicensed or excluded from the policy.

Module 9 within the course narrative

This module sits between data connectors (Module 8) and detection rules (Module 10) in the curriculum. The positioning is deliberate:

Module 8 connects the data sources — including the Defender for Office 365 tables (EmailEvents, UrlClickEvents, etc.). Without Module 8, the email tables are empty and the queries in this module return nothing.

Module 9 (this module) configures the protection policies — the active defence layer that prevents threats from reaching users. It also teaches you to monitor these policies with KQL — building investigation skills you will need in Modules 12-16.

Module 10 creates detection rules — including email-based rules that reference the tables and patterns from this module. The AiTM detection rule (Module 12.13, Rule 1) correlates UrlClickEvents with SigninLogs — a pattern that only works if Safe Links is configured (UrlClickEvents populated) and the Defender connector is active (data flowing to Sentinel).

Modules 12-16 investigate scenarios that begin with email — AiTM phishing (M12), BEC (M13), and consent phishing (M15). Each investigation uses Threat Explorer, the email tables, and the protection policies configured here. If this module is skipped: the investigation modules are significantly harder because the data and the prevention layers are missing.

The email kill chain — mapping attacks to defences

Every email attack follows a predictable chain. Mapping each step to the defence layer that stops it clarifies where gaps exist:

Step 1: Attacker crafts email. They choose: a sender identity (spoofed domain, lookalike domain, or compromised account), content (social engineering lure), and payload (URL, attachment, or QR code).

Step 2: Email traverses the internet. Connection filtering (EOP Layer 1) checks the sending IP against reputation lists. If the IP is on a blocklist: rejected. If the attacker uses fresh infrastructure (newly registered domain, clean IP): passes.

Step 3: Content analysis. Anti-malware (Layer 2) scans attachments for known signatures. Anti-spam (Layer 3) evaluates content patterns. Anti-phishing (Layer 4-5) checks for impersonation and spoof indicators. If any layer flags the email: blocked or quarantined. If all layers pass: the email proceeds to delivery.

Step 4: URL and attachment deep analysis. Safe Links (Layer 6) detonates URLs in a sandbox. Safe Attachments (Layer 7) detonates attachments. If either identifies malicious content: the email is blocked or the malicious component is removed (Dynamic Delivery). If the attacker uses evasion techniques (CAPTCHA, conditional redirect): the sandbox sees benign content and the email passes.

Step 5: Delivery. The email arrives in the user’s inbox. At this point, the automated defences have either caught the threat or been evaded.

Step 6: User interaction. The user reads the email. If they click a URL: Safe Links performs time-of-click scanning (a second chance to catch the threat). If they open an attachment: the endpoint’s defences (Defender for Endpoint, Module 2) become the last line.

Step 7: Post-delivery remediation. If the threat verdict updates after delivery: ZAP (Layer 8) removes the email. If user-reported: the submission triggers review. If AIR triggers: automated investigation scopes the campaign.

The gap analysis question for your environment: At which step does your protection end? If you have EOP only: Steps 1-4 (basic). If you have Defender P1: Steps 1-7 (full protection stack). If you have Defender P2: Steps 1-7 plus investigation and automation (Steps 8-9). Each missing step is an exploitable gap.

Email protection in the broader security architecture

Email protection (this module) does not exist in isolation. It connects to:

Identity protection (Module 1, Conditional Access). If the phishing email succeeds and the user enters credentials: conditional access policies are the next defence. MFA stops credential replay. Token binding stops AiTM token capture. CAE stops token replay from different IPs.

Endpoint protection (Module 2, Defender for Endpoint). If a malicious attachment executes: endpoint detection catches the malware. If the user downloads a file from a phishing URL: endpoint network protection blocks the download. Email protection reduces the volume of threats reaching endpoints — endpoint protection catches what gets through.

Data protection (Module 3, Purview). If a compromised account attempts to exfiltrate data: DLP policies block the transfer. Sensitivity labels prevent unauthorised sharing. Email protection prevents the compromise — data protection limits the damage if the compromise succeeds.

SIEM and detection (Modules 8, 10). Email telemetry flows to Sentinel via the Defender connector. Analytics rules correlate email events with sign-in anomalies, endpoint detections, and cloud activity. The email tables populated by this module’s policies are the data source for every phishing investigation in Modules 12-16.

This interconnection is why Module 9 sits in the curriculum between data connectors (Module 8) and detection rules (Module 10). The email protection policies generate the telemetry that the detection rules consume.