Module 1 — Check My Knowledge (15 questions)
1. Four separate alerts fire: suspicious email (Defender for Office 365), risky sign-in (Entra ID Protection), inbox rule creation (Defender for Cloud Apps), and lateral movement (Defender for Identity). All involve the same user within 1 hour. How does Defender XDR present these?
As a single incident containing four correlated alerts. The XDR correlation engine identifies the shared user entity and groups them. The analyst investigates one multi-stage incident, seeing the complete attack chain: phishing → credential theft → persistence → lateral movement.
Four separate incidents
One alert with four details
XDR's value is connecting the dots. Without correlation, an analyst might triage the email alert, close it, and never connect it to the identity compromise happening simultaneously.
2. The incident queue shows: High (10 min ago), High (6 hours ago, auto-disrupted), Medium (2 hours ago). Triage order?
Recent High → Disrupted High → Medium. The 10-minute incident is potentially active. The 6-hour disrupted incident is contained (needs verification, not emergency response). The Medium is lowest priority.
Disrupted first — most serious
Medium first — waiting longest
Active threats before contained threats. Recency indicates potential ongoing attack activity. Auto-disruption buys you time on the older incident.
3. You need to purge phishing emails from 50 mailboxes. Which tool and action?
Threat Explorer → filter to the campaign → select all → Soft delete. Soft delete removes from user access immediately while remaining recoverable for 14 days. Use Threat Explorer (not Advanced Hunting) because Explorer provides the bulk remediation interface.
Advanced Hunting with a delete query
Block the sender and wait for ZAP
Advanced Hunting is read-only — it cannot take actions. Threat Explorer provides the investigation + remediation combination for email threats.
4. A device timeline shows: winword.exe → cmd.exe → powershell.exe -enc [base64]. Your first response action?
Collect the investigation package (captures live state including the running process and its network connections), then immediately isolate the device (cuts the attacker's C2 channel). Collection before isolation preserves evidence that isolation would destroy.
Isolate immediately
Run antivirus scan
Collect before isolate. Live state is perishable — once you isolate, active connections drop and running processes may change behavior. The 30 seconds for collection does not meaningfully increase risk.
5. Defender for Identity detects Kerberoasting. What is the attacker trying to obtain?
Service account passwords. Kerberoasting requests Kerberos tickets for accounts with SPNs, then cracks them offline. The attacker wants credentials for lateral movement to higher-value systems. Investigate: which service accounts were targeted, do any have admin privileges, and check those accounts for post-compromise activity.
Access to specific files
Domain controller access directly
Kerberoasting targets service accounts — often high-privilege accounts with old passwords that can be cracked quickly. The offline cracking leaves no network evidence, so by the time the Kerberos ticket request is detected, the attacker may already have the password.
6. An inbox rule that forwards all emails containing "invoice" to an external address is detected. Which Defender product detected this?
Defender for Cloud Apps — inbox rule creation is a cloud application event in CloudAppEvents, not an email event in EmailEvents. Defender for Office 365 handles email delivery. Defender for Cloud Apps handles mailbox configuration changes.
Defender for Office 365
Defender for Endpoint
Knowing which product detects which activity prevents you from searching the wrong place during investigation. Email content → Office 365. Mailbox configuration → Cloud Apps. Device activity → Endpoint. Directory changes → Identity.
7. You write a KQL query using SigninLogs in Advanced Hunting and it fails. Why?
SigninLogs is a Sentinel table, not an Advanced Hunting table. Use IdentityLogonEvents or AADSignInEventsBeta in Advanced Hunting. The KQL syntax is identical — the table names differ between the two query interfaces.
KQL syntax error
Insufficient permissions
A practical gotcha that trips up analysts who switch between Sentinel and Advanced Hunting. Always verify which query interface you are using and use the correct table names.
8. Auto-disruption disabled j.morrison's account and isolated DESKTOP-NGE042. You confirm it is a true positive. What is your next action?
Investigate the scope: are other accounts compromised? Was data exfiltrated? How did the attacker get in? Then eradicate: reset credentials, remove inbox rules, remove any persistence. Then restore: re-enable the account with a new password and verify the device is clean before releasing isolation. Auto-disruption handled the emergency; you complete the response.
Close the incident — it is contained
Re-enable the user immediately
Contained ≠ resolved. The attacker may have compromised other accounts, exfiltrated data, or established persistence that survives the disruption. Complete the investigation before closing.
9. You are at shift start. Before triaging incidents, you check data pipeline health. This query returns: SigninLogs last event 6 hours ago. All other tables are current. What do you do?
Investigate the SigninLogs gap immediately. 6 hours without sign-in data means brute-force detection, token replay detection, and impossible travel detection are all blind. Check the Entra ID diagnostic settings — the most common cause is the diagnostic setting being deleted or modified. Fix the pipeline before triaging incidents, because your incident queue may be incomplete.
Proceed to triage — 6 hours is normal
Log a ticket for the next maintenance window
Data gaps are the highest-priority operational issue. Fix ingestion before investigating incidents, because you cannot trust an incident queue built on incomplete data.
10. The cross-product correlation query shows: phishing email at 08:02, sign-in from attacker IP at 08:14, inbox rule at 08:15, mailbox access at 08:16. No endpoint activity. Does this mean the endpoint is safe?
Not necessarily. No endpoint alert means no detection rule fired — not that no activity occurred. The attacker operated through cloud services (Exchange Online) using the stolen token, without needing device access. However, you should still check DeviceProcessEvents for the user's device during this window. The user may have opened the phishing link on their device, and browser-based activity would appear in endpoint telemetry even if it did not trigger an alert.
Yes — no alert means no compromise
The endpoint is irrelevant in AiTM attacks
No alert ≠ no activity. AiTM attacks primarily operate at the cloud layer, but the initial click often happens on the user's device. Always check endpoint telemetry even when the attack chain appears cloud-only — you may find evidence of the initial access vector.
