9.10 Module Assessment

90 minutes · Module 9

Module 8 — Final Assessment

Key takeaways

Email is the #1 attack vector — Defender for Office 365 is the primary prevention layer
EOP provides baseline protection (spam, malware, basic phishing). Defender adds Safe Links, Safe Attachments, advanced anti-phishing, and investigation tools.
P1 provides protection. P2 adds investigation (Threat Explorer, AIR, Campaign Views, Advanced Hunting).
Anti-phishing: protect executives and finance team by name + protect your domains and partner domains. Start at threshold 2.
First contact safety tip is a low-cost, high-value control — enable for all users
Safe Links: enable time-of-click scanning. Disable "let users click through." Track all clicks.
Safe Links fails against anti-analysis CAPTCHAs — first contact safety tips and user training fill this gap
Safe Attachments: Dynamic Delivery is the best balance (same detection, no email delay)
ZAP is a safety net, not a primary control. The ZAP gap (23+ minutes) means phishing emails are accessible before cleanup.
Email authentication (SPF, DKIM, DMARC) verifies origin, NOT safety. Attackers configure authentication on their own domains.
Deploy DMARC in stages: none (monitoring) -> quarantine -> reject. Never skip to reject without data.
Transport rules provide pre-delivery blocking. Kit URL patterns are the most effective transport rule condition.
Threat Explorer for email investigation. Advanced Hunting for cross-domain correlation.
Soft delete first, hard delete only when confirmed malicious — reversibility matters for bulk actions
Email AIR automates investigation and remediation. Start with require-approval, increase automation with confidence.

Module 9 deployment checklist

Use this checklist to verify your Defender for Office 365 configuration is complete:

Anti-Phishing (subsection 9.2):

Protected users list populated (executives + finance + IT admins)
Protected domains enabled (own domains + top 10 vendor domains)
Mailbox intelligence enabled
Mailbox intelligence for impersonation protection enabled
Phishing threshold set to 2 (Aggressive)
First contact safety tip enabled
Spoof intelligence reviewed

Safe Links (subsection 9.3):

URL scanning for email enabled
Internal email scanning enabled
Teams URL scanning enabled
Office application URL scanning enabled
“Wait for URL scanning” enabled
User click-through disabled

Safe Attachments (subsection 9.4):

Mode set to Dynamic Delivery
SharePoint, OneDrive, Teams scanning enabled

ZAP (subsection 9.5):

ZAP for phishing enabled (anti-phishing policy)
ZAP for spam enabled (anti-spam policy)

Email Authentication (subsection 9.6):

SPF record configured with -all
DKIM signing enabled for all domains
DMARC record published (p=quarantine minimum, p=reject target)
DMARC aggregate reports monitored

Transport Rules (subsection 9.7):

External email warning banner deployed
External auto-forwarding blocked
Dangerous attachment types blocked

Threat Explorer (subsection 9.8):

P2 licensing confirmed for investigation team
Campaign Views reviewed for current threats
User-reported phishing submissions reviewed daily

AIR (subsection 9.9):

Automated investigation enabled
Approval workflow configured (admin approval recommended)
Approval SLA defined (4 hours business hours)

Monitoring (all subsections):

Email protection dashboard workbook created in Sentinel
Monthly reporting cadence established

Module 9 artifact inventory

After completing this module, you should have:

Configured policies: Anti-phishing (with impersonation protection), Safe Links (with internal email), Safe Attachments (Dynamic Delivery), ZAP (verified enabled), email authentication (SPF + DKIM + DMARC), and 3 transport rules.

Monitoring queries: 12+ KQL queries covering: phishing detection rates, Safe Links click tracking, Safe Attachments malware detections, ZAP timing analysis, DMARC compliance, transport rule hits, Threat Explorer investigation patterns, AIR investigation tracking, and user-reported phishing volume.

Email protection dashboard: An 8-tile Sentinel workbook providing continuous visibility into email protection health.

Operational procedures: Monthly spoof intelligence review, quarantine management, transport rule governance, DMARC aggregate report analysis, and AIR approval workflow.

These artifacts — combined with the investigation playbooks from Modules 12-16 — provide complete email protection: prevention (policies), detection (monitoring), investigation (Threat Explorer + KQL), and response (AIR + remediation).

What comes next

Module 9 configured the email protection stack. The next modules build on this foundation:

Module 10 (Create Detections) uses the email tables populated by Module 9 to create analytics rules. The AiTM chain rule (Module 10, originally from Module 12.13) correlates UrlClickEvents with SigninLogs — this rule requires both Safe Links (for UrlClickEvents) and the Defender connector (for SigninLogs in Sentinel).

Module 11 (Threat Hunting) includes hunting queries that reference email tables. The cross-table correlation pattern from subsection 11.3 joins EmailEvents with SigninLogs to find phishing-click-then-sign-in patterns — the pre-investigation version of the Module 12 AiTM investigation.

Module 12 (AiTM Investigation) is the full application of Module 9’s protection stack to a real attack scenario. Every gap in Module 9’s configuration is an exploitable gap in Module 12. The AiTM investigation uses: EmailEvents (find the phishing email), EmailUrlInfo (extract URLs), UrlClickEvents (find clickers), EmailPostDeliveryEvents (check ZAP), and Threat Explorer (campaign scope and remediation).

Module 13 (BEC Investigation) uses email authentication analysis from subsection 9.6. The BEC investigation starts with: “Is this email from the real vendor or a spoofed/lookalike domain?” DMARC analysis (SPF/DKIM/DMARC pass/fail) provides the answer.

Module 15 (Consent Phishing) starts with a phishing email directing users to an OAuth consent prompt. The email investigation uses the same tables and techniques from Module 9 to identify: who received the consent phishing email, who clicked, and whether Safe Links or anti-phishing caught it.

The email protection stack from Module 9 is the foundation. The investigation modules from Modules 12-16 are the application. If Module 9 is configured correctly: the investigation modules have complete data to work with and fewer attacks succeed. If Module 9 has gaps: the investigation modules are harder because more attacks get through and the data may be incomplete.

Final assessment (12 questions)

1. What protection does Defender for Office 365 add beyond EOP?

Safe Links (URL time-of-click scanning), Safe Attachments (sandbox detonation), advanced anti-phishing (impersonation, mailbox intelligence), and with P2: Threat Explorer, AIR, Campaign Views, and Advanced Hunting.

Better spam filtering

Email encryption

EOP handles known threats. Defender handles unknown and sophisticated threats — zero-day URLs, unknown malware, impersonation attacks.

2. The Module 14 phishing email passed Safe Links. Why?

A Cloudflare CAPTCHA blocked automated URL scanning. Safe Links saw the CAPTCHA page, not the phishing proxy. Only human visitors who solved the CAPTCHA reached the attack page.

Safe Links was disabled

The URL was on the allow list

Anti-analysis CAPTCHAs are the primary evasion technique against automated URL scanning. Understanding this limitation prevents false confidence in Safe Links as a complete solution.

3. Why set "Let users click through" to No in Safe Links policy?

With click-through enabled, users can override Safe Links blocks — exactly what happened in Module 14 where 5 of 7 users clicked through the warning. Disabling click-through makes Safe Links blocks absolute — maximum protection at the cost of rare false positive frustration.

It improves scanning speed

It reduces Safe Links costs

A warning that users can ignore is a suggestion, not a control. Module 14 proved that most users ignore it. Remove the option to create an effective control.

4. Dynamic Delivery vs Block mode for Safe Attachments — which and why?

Dynamic Delivery — same detection (sandbox detonation) without email delivery delay. Users receive the email body immediately, attachment available within 1-2 minutes. Block mode delays the entire email, which is noticeable at scale.

Block — maximum security always

Monitor — least user impact

Same security, better UX. Dynamic Delivery is the correct default for commercial organizations. Block mode is for environments where users must not see any part of a suspicious email.

5. A phishing email passes SPF, DKIM, and DMARC. Is it safe?

No. Authentication verifies origin, not safety. The attacker owns the domain and configured authentication correctly. Passing proves "this email is from attacker-domain.com" — not that the domain is trustworthy.

Yes — all protocols passed

Depends on DMARC policy

The most dangerous misconception in email security. Authentication protects your domain from spoofing. It does not protect you from attacker-owned domains.

6. ZAP removed 4 of 23 phishing emails after 23 minutes. What is the gap?

23 minutes of exposure where all 23 emails were accessible in inboxes. 19 were not removed by ZAP (users had already interacted with them). The ZAP gap is the time between delivery and remediation — minimize it through better initial detection, not by relying on ZAP.

ZAP failed on 19 emails

23 minutes is normal and acceptable

ZAP is post-delivery cleanup, not real-time protection. The gap is inherent to the mechanism. Better initial detection (aggressive thresholds, transport rules) is always superior to post-delivery remediation.

7. You want to deploy DMARC reject for your domain. What is the correct sequence?

p=none (30 days monitoring, identify all legitimate senders) -> add all senders to SPF, configure DKIM -> p=quarantine (30 days, verify no legitimate email goes to Junk) -> p=reject. Skipping to reject blocks legitimate third-party email.

Deploy reject immediately for maximum protection

None is sufficient — reject is too aggressive

DMARC deployment is a staged process. Each stage gives you data to refine before increasing enforcement. Skipping stages risks blocking legitimate business email.

8. Why is a URL pattern transport rule more effective than a domain-based block?

Domains are disposable — the attacker registers new ones per wave. The URL pattern is generated by the phishing kit and stays consistent across all domains. One transport rule catches all waves.

Transport rules cannot block domains

URL patterns are harder to change

IOC durability: domains are minutes to register, URL patterns are baked into kit code. Same principle as Module 14 — detect the kit, not the infrastructure.

9. Threat Explorer vs Advanced Hunting for email investigation — when do you use each?

Threat Explorer for email-specific investigation (campaign view, bulk remediation, delivery timeline). Advanced Hunting for cross-domain correlation (joining email data with sign-in logs, building detection rules). Use both during a phishing investigation.

Threat Explorer always — it has a better interface

Advanced Hunting always — KQL is more powerful

Different tools for different tasks. Campaign View and bulk remediation are Threat Explorer strengths. Cross-table joins and detection rule creation are Advanced Hunting strengths. Master both.

10. You identify a phishing campaign in 200 mailboxes. Soft delete or hard delete?

Soft delete first. Verify the campaign is malicious. Then hard delete if confirmed. Soft delete is reversible — a false positive hard deletion across 200 mailboxes cannot be undone.

Hard delete — speed matters

Leave them and block the sender

Reversibility for bulk actions. Soft delete removes the emails from user view (same user experience as hard delete) while keeping them recoverable for 14 days.

11. First contact safety tip shows "You don't often get email from this sender." Why is this effective against phishing?

Phishing campaigns come from new domains the user has never seen before. The safety tip alerts them to verify the sender before interacting. It is a low-friction security awareness mechanism built into the email itself — no training required.

It blocks the email

It only works for internal emails

The Module 14 phishing domain (northgate-voicemail.com) was a first-time sender for every recipient. The first contact safety tip would have flagged every one of those 23 emails. Zero configuration per email — it works automatically for any new sender.

12. Email AIR auto-remediates 69% of email threats. The remaining 31% are pending approval. Should you increase automation?

Review the 31% pending items. If they are consistently approved without changes, the detection is accurate and automation can be increased. If some are rejected or modified, keep the approval requirement — human review is catching genuine edge cases.

Yes — 69% proves it works

No — always require human approval

The decision is data-driven, not dogmatic. If the 31% pending are all approved = increase automation. If some are rejected = keep the current level. The data tells you when it is safe to advance.

← 9.9 Automated Investigation and Response for Email