Defender XDR series · Lab 5 of 5 · Advanced

One reported email, eleven mailboxes, and a Friday

At 07:41 UTC a user reported an invoice mail. The submission queue has three items waiting, two real-time alerts fired, and the finance team has already paid a changed bank detail on another thread. This lab grades the campaign response: scope before you delete, approval before you act on a mailbox you do not own, and a tracker record a regulator could read.

Required

Console replica · not Microsoft software · offline.

Simulated 2026 portal layout, six synthetic mail tables, and a KQL engine that runs entirely in your browser. No tenant, no Graph permissions, no mailbox is touched, and nothing is uploaded. Addresses, message IDs, URLs and attachments are fabricated; only documentation ranges are used for IPs and domains.

Objectives · 100 pts

Seven graded steps

1
Real-time alert triage · 10Which alerts are the same campaign, and what the delivery action already tells you.
2
Submission queue · 10Adjudicate three submissions without letting the verdict drift into policy.
3
Campaign scope · 20KQL over the mail tables plus the exact mailbox list that needs action.
4
Remediation & approvals · 20Soft delete, hard delete, ZAP, indicator — in the order that keeps evidence and trust.
5
Mail policy hardening · 15Impersonation, detonation for unknown malware, and the audit switch you forgot.
6
User communication · 10Tell people what to do without blaming them or naming victims.
7
Tracker record & clocks · 15Threat tracker entry, GDPR judgement, and what stays open.

Timeline so far

What is already known

07:12

Campaign mail delivered to 11 mailboxesSubject pattern “Invoice 88xxx · open immediately”, sender n1ghtbloom@relay-secure.example

07:20

4 users clicked the link; 2 entered credentials on the pagelogin-contoso.secure-mail.example · 203.0.113.64

07:31

Mailbox rule created on FIN-CLERK: forward + deletePost-delivery action recorded; this is why mail is not the whole story

07:41

User reported the message with the Report Message add-inSubmission queue now holds three items, one of them a newsletter

08:02

Payment made to a changed bank detail (separate thread, 2 weeks earlier)Finance reports it as a possible business email compromise

Simulated “now”: 2026-09-04T09:00:00Z · tenant contoso-rcw.example · 1,840 mailboxes · MDO Plan 2 · mailbox audit already enabled on 40% of hosts.

Objective 1 · 10 pts

Real-time detections · 2026-09-04

Group the campaign alerts, and be explicit about the one that is a different problem entirely.

Required

Queue

Five alerts

Select every alert that belongs to this campaign. No rows selected
Alert	Detection	Delivery action	Users	Time	Note
MA-9001Phish delivered	Phish · High confidence	Delivered (allowed by admin override 2026-08-19)	11	07:12	Same URL as MA-9003
MA-9002Credential theft page visited	URL click · Safe Links detonation	n/a	4	07:20	2 posted credentials
MA-9003Suspicious email reported by users	User submission triage	Delivered	3	07:41	Same sender and template
MA-9004Mailish anomaly: forwarding rule created	Post-delivery behavioural	Rule added	1	07:31	FIN-CLERK mailbox
MA-9005Malware detected by attachment detonation	Malware · Doc.Dropper	Quarantined	1	Tue	Different sender, different payload, unrelated thread

Objective 1

Triage decision

Required

Reading mail alerts

Three distinctions that decide your next click

Detected vs delivered: A detection with a delivery action of Delivered is a hit; Quarantined is a block. Only the first needs user-side work.
Allowed by policy: When a rule or an allow list let it through, the mail fix is not the only fix — the policy needs a finding.
Reported ≠ confirmed: A user submission is a hypothesis. The verdict comes from detonation and message trace, not from the report count.

Compliance gate.

Actions on other people's mailboxes are authorised only for the incident scope you declare. The lab records that gate; so should your ticket.

Objective 2 · 10 pts

Threat submission queue

Verdicts here also train the tenant's allow/block lists, which is precisely why a careless “close it” costs more than a minute.

Required

Three submissions

Remediation and verdict per item

Item	Detonation	Analyst notes
SUB-1101Invoice 88216 (FIN-CLERK)	URL leads to a credential page; form posts to an external host	Matches MA-9001 template; 8 similar mails in the tenant
SUB-1102Vendor newsletter (OPS-ADMIN)	Clean; link resolves to a known subscription service with valid domain history	Reported by three people because the layout changed
SUB-1103“Scanner scan-to-email” with macro (RECEP-01)	Macro executes and beacons; detonation still running (in progress)	Attachment 214 KB · sender is a spoofed internal display name

In the real portal you can request a re-scan and, on a shared or dirty tenancy, decide whether a tenant-level allow applies. Here you record the decision; the validator checks the reasoning, not just the label.

Objective 2

Record the adjudication

Required

SUB-1101 verdict and action SUB-1102 verdict and action SUB-1103, with detonation still running

Queue discipline Verdicts are recorded with the evidence reference, not just the label The reporters get a reply telling them the outcome No tenant-wide allow list entry is created from a single submission

Objective 3 · 20 pts

How far did it get, and into whose mailbox?

Two answers, both from data: one query over the mail tables, and the mailbox list that actually needs user-level work.

Required

Query

Every message from this sender in 7 days, by delivery action

Requirements: start from EmailEvents, bound the window to 7 days or less, filter on the sender n1ghtbloom@relay-secure.example, and summarize … by DeliveryAction with a distinct-user count.

KQL

Tables: EmailEvents, EmailUrlInfo, EmailPostDeliveryEvents, EmailAttachmentInfo, DeviceNetworkEvents, IdentityLogonEvents.

Mailboxes

Select the four that need user-level work

Multi-select exactly four. No rows selected
Mailbox	Message	Clicked	Creds	Rule	Audit
FIN-CLERK	Delivered	Yes	Yes · 07:22	Forward + delete	On
FIN-MGR	Delivered	Yes	Yes · 07:24	None	Off
HR-ASST	Delivered	Yes	No — page error	None	On
RECEP-01	Delivered	Yes	No — closed tab	None	Off
OPS-ADMIN	Delivered	No	No	None	On
IT-SHARED (deck)	Delivered	Blocked	No	None	Not auditable (shared)
PAY-BATCH (service)	Quarantined	No	No	None	n/a

Clicked-and-delivered is the boundary for user-level work: credential reset, rule removal and ZAP. Everyone else is covered by the tenant-wide search-and-remove.

Objective 3

State the scope you will act on

Required

Messages your query counted as delivered Read it off your own result — the grid above, not the briefing text. Why summarise by delivery action rather than by user Scope of the search-and-remove operation

Scope statement for the ticket (min 120 chars, no personal data)

Objective 4 · 20 pts

Execute the remediation in a defensible order

Seven operations. Click them in the order that preserves evidence, gets approval before it touches a mailbox, and never leaves the attacker a listening rule.

Required

Operations

Click in order

Two of these are here to be refused. “Hard delete everything immediately” removes the copy you may still need and skips the approval that mailbox content deletion requires in most change policies; the all-staff notice is a communications decision, not a mail action.

Objective 4

Authorisation record

Required

Approval for mailbox actions Soft delete vs hard delete

Conditions before the last operation Message list exported into the incident as evidence The inbox rule removal is verified in the mailbox, not just requested Credential reset happened before ZAP was relied on as “done” Indicators added for URL, sender and hash so the block is not limited to one action

Action record (min 150 chars, no addresses)

Objective 5 · 15 pts

Close the gate that let it in

The mail flow rule that allowed this campaign is a finding. So is the missing audit on half the tenant. Fix both without turning the gateway into a noise machine.

Required

Candidate changes

Apply today · schedule · refuse

Change	Effect	Risk of the change itself
Enable mailbox audit on the remaining 60% and on shared mailboxes	You can prove who read and forwarded what	Storage and retention planning
Impersonation protection for finance leadership and the two named vendors	Blocks display-name spoofing of the accounts used here	Low — protected users get tips, not blocks, until tuned
Enable impersonation protection for every mailbox in the tenant	Broad	High false-positive load on day one
Block until detonation completes for unknown malware on inbound mail	No more “delivered, then retracted”	Delivery delay for some legitimate attachments
Remove the tenant rule that allowed n1ghtbloom@relay-secure.example	Removes the reason MA-9001 was delivered	None — but record why it existed first
Enable zero-hour auto purge for phishing, malware and spam	Retracts after delivery	Users lose mail silently unless notifications are on
Turn on aggressive file sandbox for all outbound mail too	Not needed for this incident	Outbound delay for finance batches

Objective 5

Policy decision

Required

Select exactly the four changes to apply today

ZAP notifications The allow rule that caused this

Guardrails Changes are made in the change window with a rollback for each one Mail flow is re-tested after the allow rule is removed (a test message, not a hope) The policy change is linked to the incident record so the audit trail is bidirectional

Objective 7 · 15 pts

The record that outlives the incident

A tracker entry is how the next analyst recognises this template in ninety days, and how the DPO proves what was known when.

Required

Threat tracker

NIGHTBLOOM / invoice-88xxx · new entry

Campaign: invoice-88xxx · n1ghtbloom@relay-secure.example
Indicators: 1 URL · 1 sender · 1 file hash (from SUB-1103, pending confirmation)
Delivery: 11 mailboxes · 11 delivered (allowed by rule) · 4 clicked · 2 posted credentials
Post-delivery: 1 inbox rule · 1 mailbox with audit disabled · 1 ZAP candidate
Related: MA-9001…9004 · submission SUB-1101 · endpoint alert on FIN-CLERK (none)

The file-hash indicator is not confirmed.

SUB-1103's detonation finished after the mail remediation was queued. An indicator added from an unfinished detonation is a policy change built on a guess — the record has to say which is which.

Objective 7

Close it out properly

Required

Tracker status at 09:00 Classification Personal-data breach assessment (GDPR Art. 33) Regulatory clock for this tenant

Indicator handling Confirmed indicators (URL, sender) are applied tenant-wide with expiry The unconfirmed hash is recorded as pending, not enforced The tracker entry links the incident, the submissions, the policy finding and the notice

What stays open after this shift (min 180 chars)

Reference

Marking, the mail-specific traps, and provenance

Marking

How the 100 points are awarded

#	Objective	Pts	What the validator checks
1	Real-time alert triage	10	Exactly the four campaign alerts; the “allowed by override” and the unrelated malware alert handled correctly; proof/disproof written out
2	Submission queue	10	Three verdicts with the right remediation breadth; no tenant allow list from one submission; re-scan held for the unfinished detonation; three discipline items
3	Campaign scope	20	Bounded KQL over EmailEvents grouped by DeliveryAction with a distinct-user count, the delivered figure matching your result, exactly four mailboxes selected, scope written to match the choice
4	Remediation & approvals	20	Seven operations in the evidence-preserving order, no hard-delete-first, approval recorded for the declared scope, four verified conditions, 150-character action record
5	Mail policy	15	The four changes that address this failure mode, ZAP notifications on, the allow rule removed as a finding, three guardrails
6	User communication	10	Audience, no names, no fraud amounts, and a notice that contains the ask and the deadline
7	Tracker & clocks	15	Open status with the reason, correct classification, Article 33 assessed on risk, NIS2 (not DORA) clocks, confirmed vs pending indicators separated, 180-character open list

Traps

Seven ways this lab catches a shortcut

Deleting first, scoping second. Without the exported message list you cannot prove what was removed, and you cannot re-check who was affected.
Tenant-wide allow lists born from one submission. A newsletter reported by three people is not a domain trust decision.
Hard delete “to be sure”. It removes the artefact, and usually needs the approval you skipped.
Fixing mail only. The inbox rule and the two credential-posting accounts are identity events; mail remediation without them leaves the door open.
Enforcing an indicator from an unfinished detonation. Pending is a valid state; write it as pending.
Naming who clicked. The reporting rate is your cheapest sensor; spend it once and it is gone for a year.
“Delivered means they must have clicked.” Delivery, click and credential entry are three different facts and each changes your next action.

Standards mapped in this lab

Process: NIST SP 800-61r3 §3.2–§3.4 and ISO/IEC 27001:2022 A.5.24–A.5.28 (incident management) with A.8.16 (monitoring) for the audit gaps. Controls: PCI DSS v4.0 requirements 12.10 (incident response) and 6.3 for the change to the mail flow rule. Clocks: NIS2 Art. 23(4) — 24 h early warning, 72 h notification, one-month final report; GDPR Art. 33/34 on risk, not on proof. MITRE ATT&CK: T1566.002, T1204.003, T1534, T1078.004, T1098.003. Training aid only — not certification preparation, and not affiliated with or endorsed by Microsoft.

Provenance

Every value in this lab is fabricated

Kind	Used here	Rule
Addresses	fin.clerk@contoso-rcw.example	RFC 2606/6761 reserved domains only; never a real tenant
Message IDs	m-88216a …	Invented; not real Graph identifiers
URLs / IPs	login-contoso.secure-mail.example · 203.0.113.64	Documentation ranges; nothing resolves to real infrastructure
Attachments	Fabricated names and hashes	No real malware sample fingerprint is reproduced
Logos	Text brand mark only	No Microsoft 4-square or vendor marks are reproduced

Offline by design: no analytics, no web fonts, no third-party requests, and no state leaves this browser. Evidence redaction masks anything shaped like a real identity unless it is obviously documentation data.

Access

Keyboard, screen readers, printing

Grids: arrow keys move, Space toggles a row, Shift+Arrow extends; the caption announces the running count, so selection is never colour-only.
The operations list is a labelled group of real buttons; the sequence state is announced in a live region and mirrored into the audit log.
Every form message sits inside its form, uses aria-live, and repeats the expected value in words — no red outline alone.
Skip link, visible focus at 3:1, Escape closes the audit flyout and modals, forced-colours mode and prefers-reduced-motion supported, and the views print with the tabs expanded.

Read the series compliance and accessibility standard →