Module 3 — Check My Knowledge (20 questions)
1. Your organisation has M365 E3 licenses. A user account was compromised via AiTM phishing. Your CISO asks how many emails the attacker read. What can you tell them?
You cannot determine this. MailItemsAccessed — the only audit event that records which emails were read — requires E5 or the E5 Compliance add-on. With E3, you can identify emails sent by the compromised account and inbox rules created, but not which emails were accessed. The recommended action: advocate for E5 licensing on high-value accounts to enable this investigation capability for future incidents.
Check the message trace for all read emails
Use eDiscovery to find accessed emails
Run a KQL query against SigninLogs
MailItemsAccessed is the single most important licensing consideration for security investigations. Message trace records email delivery, not access. eDiscovery searches content but cannot identify which items were accessed by a specific user. SigninLogs records authentication, not mailbox activity.
2. A DLP alert shows "UK National Insurance Number" detected with High confidence, 340 instances, in an email to an external address. The DLP action was "Audit" (no block). Is this a data breach?
Yes — the email was delivered because the policy was audit-only. 340 instances of NINOs (personal data under UK GDPR) have been sent to an external address. This is a confirmed personal data breach. Begin the ICO notification assessment immediately — the 72-hour deadline starts from the point of awareness, which is now. The investigation must determine the sender's intent (compromised account vs insider) and recommend upgrading the DLP policy to block mode.
No — DLP audit-only means it was just a test
It depends on whether the recipient is a trusted partner
No — National Insurance Numbers are not personal data
Audit-only detects but does not prevent. The data was delivered to the external recipient. NINOs are personal data under UK GDPR. 340 instances suggests a bulk export (spreadsheet, database extract). The combination of high confidence, high volume, external recipient, and delivered status makes this a high-severity data breach requiring notification assessment.
3. You need to investigate an insider risk alert. You have Security Administrator access. You navigate to Insider Risk Management in the Purview portal but see no alerts. Why?
IRM requires the specific Insider Risk Management Analyst or Investigator role, which is separate from Security Administrator. IRM's privacy-by-design architecture deliberately restricts access to employee behavioral data. Even Global Administrator does not automatically have IRM access. You need explicit role assignment by an IRM administrator.
There are no active IRM policies configured
IRM alerts only appear in the Defender portal
IRM requires E5 and your tenant has E3
IRM's role separation is a core exam concept. The privacy controls exist because IRM monitors employee behavior — access must be explicitly granted, audited, and justified.
4. An IRM alert shows a Critical risk score for a departing employee. The indicators include: 500 SharePoint downloads (10x average), USB device connected (first time in 90 days), 500 files copied to USB, and Dropbox accessed via browser. What detection capability triggered the Critical classification?
Sequence detection. The completed sequence — bulk download → USB connection → USB copy → personal cloud access — matches the departing employee data theft pattern. Individual indicators would raise the score incrementally. The completed sequence elevates it to Critical because the full exfiltration chain was executed in order, after a resignation triggering event.
The volume — 500 files exceeds the Critical threshold
The USB device — removable media always triggers Critical
The resignation — all departing employees are Critical
Sequence detection distinguishes IRM from simple threshold alerting. The pattern (download → USB → cloud) after a trigger event (resignation) matches the known data theft behavioral model with high confidence.
5. You de-anonymize a user in an IRM alert out of curiosity — the alert was Low severity and did not warrant investigation. What is the consequence?
The action is permanently logged in the IRM audit trail. De-anonymization is an audited, irreversible action. If audited, you would need to justify identifying an employee based on a Low-severity alert that did not warrant investigation. This may violate your organisation's employee monitoring policies and could result in disciplinary action. The principle: de-anonymize only when the alert severity and indicator pattern genuinely warrant formal investigation.
Nothing — de-anonymization is routine
The alert is automatically escalated to HR
The user receives a notification
IRM's privacy controls are not just technical features — they are governance mechanisms with real audit and accountability implications.
6. What is the difference between DLP and IRM in detecting data exfiltration?
DLP detects sensitive content at the point of action (this email contains credit card numbers). IRM detects behavioral patterns over time (this user's data access pattern matches a data theft profile). DLP operates on content classification. IRM operates on behavioral deviation from baseline. A departing employee downloading 500 unlabeled documents does not trigger DLP but does trigger IRM.
They are the same — IRM replaced DLP
DLP monitors email, IRM monitors endpoints
IRM is real-time, DLP only works retroactively
DLP and IRM are complementary. DLP detects sensitive content crossing boundaries regardless of user intent. IRM detects suspicious user behavior regardless of content sensitivity. Together they cover both content-based and behavior-based data protection.
7. You search the audit log for a compromised user's activity that occurred 20 minutes ago. No results appear. Is the compromise not real?
No — the audit log has ingestion latency of 30-90 minutes for most events. The absence of results 20 minutes after the activity does not mean no activity occurred. Use Defender XDR Advanced Hunting (CloudAppEvents) for near-real-time data. Retry the audit log search in 2-4 hours for the comprehensive record.
Correct — no audit events means no activity
The audit log is disabled
The user has an E3 license so events are not logged
Audit log latency is a common investigation pitfall. Advanced Hunting provides near-real-time data for immediate triage. The audit log provides the authoritative comprehensive record, but not in real-time.
8. During a compromised account investigation, which post-compromise audit query should you run FIRST?
Inbox rule query (New-InboxRule, Set-InboxRule). A forwarding rule creates ongoing exfiltration that persists even after password reset and session revocation. Finding and removing it is an immediate containment action. The other queries (MailItemsAccessed, FileDownloaded, admin changes) are assessment — they tell you what was lost but do not represent ongoing active threats.
MailItemsAccessed — determine what was read
FileDownloaded — files are more sensitive
Admin changes — privilege escalation is highest priority
Containment before assessment. A forwarding rule is ongoing active exfiltration. MailItemsAccessed, file downloads, and admin changes are historical — the damage is done. The forwarding rule is still doing damage right now.
9. SearchQueryInitiatedExchange shows the attacker searched for "wire transfer" and "bank account details." What does this reveal?
The attack objective is BEC/financial fraud. The attacker is searching for financial transaction information to redirect payments. Immediate action: notify the finance team to verify all pending wire transfers and hold new payment requests from the compromised account. The search terms directly inform incident classification and the urgency of the finance team notification.
General reconnaissance — no specific threat
The user was doing their normal job
Search queries cannot determine attacker intent
SearchQueryInitiated events directly reveal attacker objectives. Financial search terms from an attacker IP = BEC preparation. This evidence drives response urgency — pending wire transfers may be reversible within 24-48 hours but unrecoverable after settlement.
10. The audit log shows a compromised account downloaded 47 files from SharePoint. The CISO asks whether any contained customer PII. Which tool do you use?
eDiscovery Content Search. The audit log shows which files were downloaded (metadata) but not their content. eDiscovery searches the actual content of files in SharePoint. Create a case, search the specific SharePoint site for the downloaded file names, examine the content for PII, and export relevant files as evidence.
Audit log — it records file content
DLP — it classifies all files automatically
Defender XDR Advanced Hunting
The audit log provides metadata (who, when, what file). eDiscovery provides content (what the file contains). DLP classifies content in transit but does not retroactively classify existing files. Advanced Hunting contains event telemetry, not document content.
11. During an insider risk investigation, legal counsel advises preserving all of the suspect's email. The suspect must not be alerted. What mechanism do you use?
eDiscovery legal hold on the suspect's mailbox. Legal hold preserves all content from deletion without notifying the user. The hold operates silently — the user's experience is unchanged, but content they delete is preserved in a hidden folder and remains searchable. This is the standard evidence preservation mechanism for investigations that may lead to legal proceedings.
Export all email to PST immediately
Disable their account to prevent deletion
Enable mailbox audit logging
Legal hold is silent, continuous, and comprehensive. PST export is a point-in-time snapshot that misses future content. Disabling the account alerts the suspect. Audit logging captures activity metadata, not content preservation.
12. A DLP alert fires for a user. The Defender XDR incident also contains an identity alert showing the user signed in from an unusual country 30 minutes before the DLP alert. What does this correlation suggest?
The account is compromised and the attacker is exfiltrating data. The identity alert (anomalous sign-in) indicates credential compromise. The DLP alert (sensitive data sent externally) indicates data exfiltration using the compromised account. The 30-minute gap between sign-in and DLP trigger represents the attacker's dwell time — the period during which they searched the mailbox and found the data they exfiltrated. Response: contain the account immediately, then investigate the full scope of compromise and data exposure.
The user is traveling and triggered a false positive
The DLP alert is unrelated to the identity alert
The identity alert is a false positive
Correlation is the key investigative principle in Defender XDR. An anomalous sign-in followed by a DLP alert within 30 minutes is a high-confidence attack sequence: compromise → search → exfiltrate. The Defender XDR correlation engine groups these alerts into a single incident precisely because the combination is more significant than either alert alone.
13. What determines whether a DLP alert represents an actual data breach or an attempted breach that was prevented?
The DLP action: block vs audit. If the policy action was "Block," the data was prevented from leaving — this is an attempted breach (no data exposure). If the action was "Audit" (or the block failed), the data was delivered — this is an actual data breach requiring breach notification assessment. The action field in the DLP alert is the single most important data point for determining exposure.
The confidence level of the SIT match
The number of instances detected
Whether the sender is an internal or external user
The action determines exposure. High confidence and high instance count determine severity. But severity without exposure is not a breach — a policy that correctly blocked 500 credit card numbers is a successful prevention, not a data breach. The action field is the dividing line between "the system worked" and "data was lost."
14. You are building a cross-product investigation timeline for a BEC attack. Which five data sources do you union in KQL?
EmailEvents (phishing delivery), UrlClickEvents (link click), SigninLogs (authentication compromise), CloudAppEvents (post-compromise mailbox activity including MailItemsAccessed, inbox rules, DLP alerts), and OfficeActivity (file downloads from SharePoint/OneDrive). These five tables cover the complete BEC kill chain from initial phishing through data exfiltration.
DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents
SigninLogs, AADNonInteractiveUserSignInLogs, AADManagedIdentitySignInLogs, AADServicePrincipalSignInLogs, AADRiskyUsers
SecurityAlert, SecurityIncident, ThreatIntelligenceIndicator, Syslog, CommonSecurityLog
The five tables map to the five phases of BEC investigation: email delivery (EmailEvents), user engagement (UrlClickEvents), credential compromise (SigninLogs), post-compromise activity (CloudAppEvents), and data access (OfficeActivity). The Device* tables are for endpoint investigations (Module 2). The AAD* tables are identity-specific. The Security* tables are Sentinel infrastructure tables.
15. A forwarding rule was created at 09:35 on a compromised account. The password was reset at 11:30. Is the forwarding rule still active?
Yes. Inbox forwarding rules are mailbox configurations, not user sessions. Resetting the password and revoking sessions does not affect inbox rules. The rule continues forwarding all incoming email to the attacker's external address until explicitly deleted. This is why the inbox rule query is the first post-compromise check — it detects ongoing exfiltration that survives standard containment actions.
No — password reset disables all rules
No — session revocation stops rule execution
It depends on the rule type
This is one of the most critical concepts in BEC investigation. Password reset stops the attacker from signing in again. It does NOT stop a forwarding rule from operating. The rule is a persistent mailbox configuration that runs server-side — it does not require the attacker to be signed in. Containment is not complete until forwarding rules are identified and removed.
16. Under GDPR, what is the notification deadline when personal data is confirmed exposed to an external recipient?
72 hours from the time the organisation becomes aware of the breach. The clock starts when you confirm the exposure (not when the email was sent, not when the DLP alert fired, but when you determine the data was delivered and constitutes a personal data breach). Article 33 requires notification to the supervisory authority "without undue delay and, where feasible, not later than 72 hours."
30 days from discovery
72 hours from when the email was sent
No deadline — notification is at the organisation's discretion
The 72-hour clock starts from awareness — the point at which you determine personal data was exposed. This is why DLP investigation speed matters: the faster you confirm whether data was blocked or delivered, the sooner you know whether the notification clock has started.
17. Where do DLP alerts appear for SOC analyst investigation?
In the Defender XDR portal (security.microsoft.com) unified incident queue, alongside endpoint and identity alerts. DLP alerts are integrated into the same investigation workflow you use for all other alert types. You do not need to go to the Purview portal for DLP alert investigation.
Only in the Purview portal
Only in Microsoft Sentinel
In the Exchange admin center
DLP alert integration into the Defender XDR incident queue is a core design principle — SOC analysts should not need to switch portals for different alert types. The Purview portal is for policy configuration, not for alert investigation.
18. An Audit (Standard) log search shows all activity for a compromised account EXCEPT which emails the attacker read. You have E3 licenses. What specific event is missing and why?
MailItemsAccessed is missing because it requires Audit (Premium), which requires E5. With Standard audit, you can see emails sent (via message trace), inbox rules created (New-InboxRule), files downloaded (FileDownloaded), admin changes, and most other actions. But the specific event that records "user opened/read email X" requires the Premium tier.
FileDownloaded — file events require E5
New-InboxRule — inbox rule events require E5
UserLoggedIn — sign-in events require E5
Only three specific events require Premium audit: MailItemsAccessed, Send, and SearchQueryInitiatedExchange/SharePoint. All other audit events (file operations, admin changes, inbox rules, sign-ins) are available with Standard audit at E3.
19. A DLP policy tip warns a user that their email contains sensitive data. The user provides a business justification and overrides the tip to send the email. Is this a DLP alert?
It depends on the policy configuration. A policy can be set to generate an alert on override (sending the alert to the SOC even when the user provides justification) or to only generate alerts when the action is blocked without override. If the policy generates alerts on override, the alert appears in the Defender queue with the user's justification text. The analyst reviews the justification to determine legitimacy.
No — overrides never generate alerts
Yes — every policy match generates an alert
Only if the justification is blank
The relationship between policy tips, overrides, and alerts is configurable. Not every policy tip generates an alert, and not every override generates an alert. Understanding the policy configuration is necessary to interpret the absence of alerts — "no DLP alerts" does not always mean "no policy matches."
20. You are building the incident report for a BEC attack. The cross-product investigation timeline shows: phishing email delivered → user clicked link → attacker signed in from Russia → attacker searched mailbox for "wire transfer" → attacker read 52 emails → attacker created forwarding rule → attacker downloaded customer database → attacker sent email with 15 credit card numbers → account contained. What is the single most important piece of evidence for the GDPR notification?
The DLP alert showing 15 credit card numbers sent to an external address with Action = "Audit" (delivered). This is the evidence of confirmed personal data exposure: specific data type (credit card numbers = personal data), specific volume (15 records = 15 affected individuals minimum), specific recipient (external Gmail = data left organisational control), and confirmed delivery (audit-only = not blocked). The customer database download may also contain personal data, but the credit card exfiltration is confirmed and quantifiable — making it the strongest evidence for the notification.
The phishing email — it started the attack
The sign-in from Russia — it proves compromise
The MailItemsAccessed count — 52 emails were read
GDPR notification requires evidence of personal data exposure — not just compromise, not just access, but confirmed exposure to an unauthorized party. The DLP alert with delivered action provides this: specific personal data (credit cards), specific volume (15), specific external recipient (Gmail), confirmed delivery (audit-only). The other evidence supports the incident narrative, but the DLP evidence is what triggers the notification obligation.
