The Detection Gap
Incident Brief
Context: Your SOC completed an incident response for a credential compromise that resulted in data exfiltration. The post-incident review revealed a critical finding: the adversary operated in the environment for 8 days before DET-SOC-008 (inbox forwarding) triggered the first alert. The 8-day gap represents detection failures across multiple techniques.
Adversary timeline (reconstructed from logs during the investigation):
| Day | Adversary action | Detection rule that should have caught it | Did it fire? |
|---|---|---|---|
| Day 1 | Credential phishing email delivered | DET-SOC-012 (AiTM indicators) | No — phishing URL was on a legitimate hosting service, not in TI feeds |
| Day 1 | User entered credentials on phishing page | No detection exists for credential entry | N/A |
| Day 1 | Adversary authenticated with stolen token from hosting provider IP | DET-SOC-001 (anomalous sign-in) | No — the hosting provider ASN was in the TrustedMobileASNs watchlist (misconfigured) |
| Day 2 | Adversary read 800+ emails over 6 hours | DET-SOC-011 (bulk mailbox access) | No — the baseline was miscalculated due to a KQL error |
| Day 3 | Adversary created OAuth consent (Mail.ReadWrite) | DET-SOC-022 (OAuth consent) | No — the rule was disabled during a tuning exercise and never re-enabled |
| Day 5 | Adversary began targeted email searches for “wire transfer” | No detection exists for search activity | N/A |
| Day 8 | Adversary created inbox forwarding rule | DET-SOC-008 (inbox forwarding) | Yes — this was the first and only alert |
Your Investigation
Phase 1: Root Cause Analysis (45 minutes)
Prompt the AI with the adversary timeline. Ask it to perform a root cause analysis for each detection failure: what specifically went wrong, and what is the corrective action?
Three failures are technical (misconfigured watchlist, KQL error, disabled rule). One is a coverage gap (no detection exists). Prompt the AI to categorise each failure and recommend a priority order for remediation.
The TrustedMobileASNs watchlist contained ASN 14061 (DigitalOcean). This was added 6 months ago when a user reported their mobile carrier sign-ins were being flagged. Prompt the AI: What went wrong with this watchlist entry? How should watchlist changes be governed to prevent this?
Phase 2: Build New Detection Rules (60 minutes)
Two techniques in the timeline have no existing detection: credential entry on phishing pages, and email search activity. Prompt the AI to develop detection hypotheses for both. Are these detectable with M365 log data?
For the email search detection (Day 5), prompt the AI to generate a KQL detection rule that identifies unusual email search patterns — specifically searches for financial keywords by users who do not normally search for those terms.
Prompt the AI to review the generated KQL for false positive conditions and suggest tuning strategies.
Phase 3: PIR Action Plan (30 minutes)
Prompt the AI to generate a complete PIR action plan from the root cause analysis. Each action item needs: description, owner role, deadline, success criteria, and verification method.
Prompt the AI to draft a detection health check procedure that would catch the three technical failures (misconfigured watchlist, KQL error, disabled rule) before they result in missed detections. This procedure should be run weekly.
Solution Notes
Reveal key points
Watchlist governance: Adding a hosting provider ASN to TrustedMobileASNs is a critical error — it effectively creates a permanent blind spot for all sign-ins from that hosting provider. Watchlist changes should require approval and review (like code review for detection rules). The corrective action: remove the ASN, investigate the original user’s mobile sign-ins (they may have been using a VPN, not a mobile carrier), and implement watchlist change management.
KQL error in DET-SOC-011: The most likely error is a baseline calculation issue — the baseline window was too wide, the aggregation was incorrect, or the threshold was set too high. The corrective action: review the baseline query, test with known-good data, and add unit tests to the detection-as-code pipeline.
Disabled rule: Detection rules should never be disabled for tuning. Instead, tune in a development copy and deploy the tuned version when ready. If a rule must be temporarily disabled in production, create a tracking ticket with a re-enable date and an automation rule that alerts if the rule remains disabled past the deadline.
Email search detection: CloudAppEvents records SearchQueryPerformed events in some configurations. This is a detectable technique, but the data source availability varies by Defender for Cloud Apps configuration.