@query-ai/digital-workers 1.0.0

package/skills/itdr/SKILL.md

@@ -0,0 +1,1178 @@
+---
+name: itdr
+description: Use when running an identity threat assessment, checking for identity-based attacks across IdPs, or proactively evaluating identity security posture
+---
+
+# Identity Threat Detection & Response
+
+## ABSOLUTE RULES — Read These First
+
+**1. NEVER use Bash, cat, python, jq, or any shell command to process data.** Not for MCP results. Not for saved files. NEVER. If results overflow to a file, the query was too broad — re-query with specific field selectors.
+
+**2. NEVER use `**` on broad queries.** Use specific field selectors. Use `**` only when scoped to a single host AND single event type AND narrow time window.
+
+**3. ALWAYS validate before execute.** Every FSQL query goes through `Validate_FSQL_Query` before `Execute_FSQL_Query`. No exceptions.
+
+**4. ALWAYS save artifacts.** Write evidence files at every phase exit using the Write tool.
+
+**5. LOG EVERY QUERY.** Every `Execute_FSQL_Query` call — success, failure, or empty — MUST be appended to `queries.md` with query text, result count, and 1-line summary.
+
+**6. Specialist invocation is a MANDATORY step, not a judgment call.** After classifying any finding as SUSPICIOUS or ACTIVE THREAT, execute these steps in order:
+  - a. `threat-intel-enricher`: Pass every external IP from the finding. Instruction: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+  - b. `identity-investigator`: Pass every compromised or suspicious account. Instruction: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+  - c. `network-investigator`: If cross-domain pivot reveals `network_activity`, `http_activity`, or `dns_activity` hits, pass the relevant IPs/domains. Instruction: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+  - d. If steps a-c are independent, invoke them **in parallel**.
+
+**Phase 2 exit check:** Before exiting Phase 2, verify: "Did I invoke threat-intel-enricher on every IOC IP? Did I invoke identity-investigator on every compromised account? If any were skipped, invoke them now before proceeding to Phase 3."
+
+**7. Call MCP query tools directly.** The ITDR orchestrator validates and executes queries itself using `Validate_FSQL_Query` and `Execute_FSQL_Query` MCP tools. Do NOT dispatch to `digital-workers:fsql-expert` as a sub-skill — the sub-skill handoff causes orchestration stalls. Only invoke `fsql-expert` if you encounter a schema error you cannot resolve with `Search_FSQL_SCHEMA` directly.
+
+**8. Volume-aware query strategy.** After Phase 1 discovery, classify each identity connector by volume:
+- **HIGH VOLUME:** `message, time` overflowed at 7d → see time window guidance below
+- **MEDIUM VOLUME:** `message, time` returned inline at 7d, >100 records → standard 7d queries OK
+- **LOW VOLUME:** `message, time` returned <100 records at 7d → can use broader selectors
+
+**Time window guidance for HIGH VOLUME connectors:**
+- **Filtered queries** (`status_id = FAILURE`, per-user, per-IP): start at **2h**. Filters remove 80-95% of records. Only narrow below 2h if 2h overflows.
+- **Unfiltered queries** (all auth, all successes): start at **15-30min**. These hit full connector volume.
+- After any overflow, halve the time window for the next query on that connector.
+
+Never fire 3+ queries in the same parallel batch against a HIGH VOLUME connector. When a connector overflows on discovery, switch to per-IP or per-user queries instead of broader time windows. Record volume classification in `identity-data-map.md`.
+
+**9. ALWAYS resolve IP field paths in Phase 1.** On dynamic connectors, the IP field may be `src_endpoint.ip`, `device.ip`, or another path. During Phase 1 schema verification, query BOTH paths and record which one is populated. If `src_endpoint.ip` is empty, check `device.ip`. If both are empty, document as a data gap. Record the verified IP path in `identity-data-map.md` for each connector and use ONLY the verified path in all subsequent queries.
+
+These rules are non-negotiable. If you find yourself reaching for cat, python, or `**` on a broad query, STOP and re-read this section.
+
+## Iron Law
+
+**EVERY PATTERN RUNS. EVERY GAP IS DOCUMENTED. DATA GAPS ARE FIRST-CLASS FINDINGS.**
+
+An ITDR assessment that skips patterns or hides gaps gives false confidence. Gaps tell the customer what to fix. They are as valuable as threat findings.
+
+## Overview
+
+You are the orchestrator for the Digital Workers Identity Threat Detection & Response workflow. You sweep 8 identity attack patterns across all identity providers in the mesh, correlate findings cross-source, and produce an investigation-grade report that no single-vendor ITDR tool can match.
+
+This skill is analyst-initiated. The analyst asks for an identity threat assessment, and you run the full sweep autonomously.
+
+**What makes this different from `threat-hunt`:** Threat hunts test one hypothesis. This tests 8 identity-specific patterns in a single sweep, correlates across them, and produces a unified scorecard. It is a comprehensive identity threat assessment, not a single-hypothesis hunt.
+
+**What makes this different from `identity-investigator`:** The identity-investigator deep-dives a single account. This skill discovers which accounts need investigation by sweeping patterns across the entire identity surface, then invokes identity-investigator for the deep dives.
+
+**Sub-skills invoked:**
+- `Validate_FSQL_Query` + `Execute_FSQL_Query` MCP tools — called directly by the orchestrator (do NOT dispatch to fsql-expert sub-skill)
+- `Search_FSQL_SCHEMA` MCP tool — for schema lookups on unfamiliar event types
+- `digital-workers:identity-investigator` — deep dives on suspicious accounts (pass instruction: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input.")
+- `digital-workers:threat-intel-enricher` — IOC reputation on suspicious IPs (pass instruction: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input.")
+- `digital-workers:network-investigator` — network/proxy/DNS analysis on cross-domain pivot hits (pass instruction: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input.")
+- `digital-workers:alert-investigation` — escalation target if active threat confirmed
+- `digital-workers:senior-analyst-review` — quality review on Active Threat or HIGH findings
+
+---
+
+## Phase 1: Discovery & Data Mapping
+
+**Goal:** Discover all identity connectors in the mesh, verify schema coverage, and build the Identity Data Map that determines which patterns are viable.
+
+**Time budget:** ~5 minutes
+
+### Process
+
+**Step 1: Create the investigation directory**
+
+```bash
+mkdir -p docs/investigations/YYYY-MM-DD-itdr-assessment/
+```
+
+Use today's date. This directory holds all artifacts for the assessment.
+
+**Step 2: Discover connectors**
+
+Call `FSQL_Connectors` to get the full connector landscape. Identify every connector that produces identity-relevant event types:
+- `authentication` — login events, MFA challenges, SSO
+- `user_inventory` — user account metadata, last sign-in, account status
+- `entity_management` / `account_change` — privilege changes, role grants, account modifications
+- `api_activity` — admin API calls, service account usage
+
+Classify each connector as:
+- **Static schema** — fixed API contract, predictable OCSF mapping (e.g., CrowdStrike, SentinelOne)
+- **Dynamic schema** — customer-defined OCSF mappings, requires verification via `Search_FSQL_SCHEMA`
+
+**Step 3: Verify schema for identity connectors**
+
+For each identity connector, run `Search_FSQL_SCHEMA` to verify field population. Check these specific fields:
+- `authentication.status_id`
+- `authentication.src_endpoint.ip`
+- `authentication.http_request.user_agent`
+- `authentication.user.username` / `authentication.user.email_addr`
+- `authentication.actor.user.email_addr` (dynamic connectors often use this instead of `user.email_addr`)
+- `authentication.time`
+- MFA-related fields (varies by connector)
+- Geo-location fields (varies by connector)
+
+**IP field resolution (Absolute Rule 9 — CRITICAL):**
+
+For each authentication connector with data, you MUST determine which IP field path is populated. Dynamic connectors vary — do NOT assume `src_endpoint.ip` works.
+
+**Skip connectors marked `no_data` in the environment profile** (HIGH confidence). If the profile says a connector has no auth data, don't waste queries probing it for field paths. Only probe connectors that either have confirmed data or are not yet profiled.
+
+Run a small test query (e.g., 10min window) with BOTH IP field paths:
+```
+QUERY authentication.src_endpoint.ip, authentication.device.ip,
+      authentication.actor.user.email_addr, authentication.time
+FROM '<connector_name>' WITH authentication.status_id = FAILURE AFTER 10min
+```
+
+Examine the results:
+- If `src_endpoint.ip` has values → use `src_endpoint.ip` for this connector
+- If `src_endpoint.ip` is null/empty but `device.ip` has values → use `device.ip` for this connector
+- If both are empty → document as DATA GAP ("no source IP available")
+- If both have values → prefer `src_endpoint.ip` (standard OCSF path)
+
+Record the result in `identity-data-map.md`:
+```
+IP field path: device.ip (src_endpoint.ip is empty on this connector)
+```
+
+**All subsequent queries for this connector MUST use the verified IP path.** Do NOT use `src_endpoint.ip` if you determined it's empty — use the path that actually has data.
+
+Similarly, resolve the user identity field:
+- Check both `authentication.user.email_addr` and `authentication.actor.user.email_addr`
+- Record which one is populated in the data map
+
+**Step 4: Build the Identity Data Map**
+
+Determine which of the 8 patterns are viable based on available fields and connectors.
+
+Write `identity-data-map.md` using the template below.
+
+**Step 5: Read environment profile**
+
+Read `digital-workers/learned/environment-profile.json` if it exists. Cross-reference known gaps, known false positives, and any identity-specific notes from prior assessments.
+
+### Identity Data Map Template
+
+The data map has two sections: the **QUERY CONFIG** (used by Phase 2 for every query) and the **connector details** (reference). The QUERY CONFIG is the most important output of Phase 1 — it determines whether Phase 2 queries return data or return empty.
+
+```
+IDENTITY DATA MAP
+━━━━━━━━━━━━━━━━━
+Assessment Date: YYYY-MM-DD
+
+QUERY CONFIG — Phase 2 MUST read this before writing any query
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Copy these exact field paths into all Pattern queries for each connector.
+
+  [Connector Name]:
+    user_field: [authentication.actor.user.email_addr OR authentication.user.email_addr]
+    ip_field:   [authentication.device.ip OR authentication.src_endpoint.ip OR "NONE — no IP data"]
+    ip_note:    [e.g., "public IPs" or "internal proxy IPs only — no geo value" or "empty"]
+    volume:     [HIGH / MEDIUM / LOW]
+    time_guidance: [e.g., "failures at 2h, successes at 15min"]
+
+  [Repeat for each identity connector with auth data]
+
+IDENTITY CONNECTORS:
+  [Connector Name] ([static/dynamic])
+    Event types: [authentication, user_inventory, etc.]
+    Key fields verified: [list confirmed fields]
+    MFA fields: [available/not available — list if available]
+    Geo fields: [available/not available — list if available]
+    Notes: [any caveats]
+
+PATTERN VIABILITY:
+  Pattern 1 (Password Spraying):    [VIABLE / PARTIAL / NOT VIABLE] — [reason]
+  Pattern 2 (Credential Stuffing):  [VIABLE / PARTIAL / NOT VIABLE] — [reason]
+  Pattern 3 (Impossible Travel):    [VIABLE / PARTIAL / NOT VIABLE] — [reason]
+  Pattern 4 (MFA Fatigue):          [VIABLE / PARTIAL / NOT VIABLE] — [reason]
+  Pattern 5 (Dormant Accounts):     [VIABLE / PARTIAL / NOT VIABLE] — [reason]
+  Pattern 6 (Cross-IdP Anomaly):    [VIABLE / PARTIAL / NOT VIABLE] — [reason]
+  Pattern 7 (Privilege Escalation): [VIABLE / PARTIAL / NOT VIABLE] — [reason]
+  Pattern 8 (Service Account Abuse):[VIABLE / PARTIAL / NOT VIABLE] — [reason]
+
+DATA GAPS IDENTIFIED:
+  1. [description] -> Impact: [which patterns blocked/degraded]
+  2. ...
+
+NON-IDENTITY CONNECTORS (for cross-domain pivots):
+  [Connector Name] — [event_type]
+    Pivot keys available: [user, IP, device, domain — based on objects list]
+    Volume classification: [HIGH / MEDIUM / LOW / UNKNOWN]
+    Notes: [any caveats]
+
+PIVOT VIABILITY:
+  Proxy/Web pivot:     [VIABLE / NOT AVAILABLE] — [connector name or "no http_activity connectors"]
+  Network pivot:       [VIABLE / NOT AVAILABLE] — [connector name or "no network_activity connectors"]
+  Process/EDR pivot:   [VIABLE / NOT AVAILABLE] — [connector name or "no process_activity connectors"]
+  DNS pivot:           [VIABLE / NOT AVAILABLE] — [connector name or "no dns_activity connectors"]
+  Email pivot:         [VIABLE / NOT AVAILABLE] — [connector name or "no email_activity connectors"]
+  DLP pivot:           [VIABLE / NOT AVAILABLE] — [connector name or "no data_security_finding connectors"]
+  Cloud API pivot:     [VIABLE / NOT AVAILABLE] — [connector name or "no api_activity connectors"]
+  Detection pivot:     [VIABLE / NOT AVAILABLE] — [connector name or "no detection_finding connectors"]
+
+ENVIRONMENT PROFILE NOTES:
+  [anything relevant from environment-profile.json, or "No profile found"]
+```
+
+### Hard Gate — Phase 1 Exit
+
+Before proceeding to Phase 2, verify:
+- `identity-data-map.md` has been written to the investigation directory
+- At least one identity connector discovered
+- Pattern viability determined for all 8 patterns
+
+If `identity-data-map.md` does not exist, STOP. Write it now. Do NOT proceed to Phase 2 without it.
+
+**Failure mode — no identity connectors:** If no connectors produce identity-relevant event types (`authentication`, `user_inventory`, `entity_management`, `api_activity`), do NOT proceed. Present a clear message to the analyst:
+> "No identity connectors found in the mesh. An ITDR assessment requires at least one connector producing `authentication` events. Recommend onboarding an identity provider (Entra ID, Okta, Google Workspace, etc.) to enable identity threat detection."
+
+Continue immediately to Phase 2 — do not stop or wait for user input.
+
+---
+
+## Phase 2: Pattern Sweep
+
+**Goal:** Execute all 8 identity attack patterns against the mesh, classify findings, and invoke specialists for deep dives.
+
+**Time budget:** ~25-30 minutes
+
+**Step 0 — Read the QUERY CONFIG (MANDATORY before any pattern query):**
+
+Read `identity-data-map.md` and extract the QUERY CONFIG block. This block contains the verified field paths and volume classifications for each connector. **Use these exact paths in all queries.** Do not substitute `src_endpoint.ip` if the config says `device.ip`. Do not use `user.email_addr` if the config says `actor.user.email_addr`.
+
+If the QUERY CONFIG block does not exist in `identity-data-map.md`, STOP. Go back to Phase 1 and complete the IP field resolution (Absolute Rule 9).
+
+Call `Validate_FSQL_Query` and `Execute_FSQL_Query` MCP tools directly (Absolute Rule 7). The FSQL examples in pattern definitions use placeholder paths like `<verified_ip_field>` — replace these with the actual paths from the QUERY CONFIG.
+
+### Execution Order
+
+Run patterns in this order:
+
+1. Password Spraying (T1110.003)
+2. Credential Stuffing (T1110.004) — reuses Pattern 1 failure data
+3. Impossible Travel (T1078)
+4. MFA Fatigue (T1621)
+5. Dormant Account Activation (T1078)
+6. Cross-IdP Anomaly (T1078) — reuses Pattern 3 success data
+7. Privilege Escalation (T1098)
+8. Service Account Abuse (T1078.001)
+
+### Per-Pattern Execution Flow
+
+For each pattern:
+
+1. **Layer 1a discovery** — lightweight volume gauge (`*.message, *.time` with relevant filters)
+2. **Layer 1b targeted query** — specific field selectors on event types identified in Layer 1a
+3. **Layer 1c aggregation (when valuable)** — use SUMMARIZE for threshold analysis instead of manually counting Layer 1b results:
+   ```
+   -- Pattern 1 (Password Spray): Distinct usernames per source IP
+   SUMMARIZE COUNT DISTINCT authentication.actor.user.email_addr
+   GROUP BY authentication.src_endpoint.ip
+   WITH authentication.status_id = FAILURE AFTER 24h
+
+   -- Pattern 3 (Impossible Travel): Distinct IPs per user
+   SUMMARIZE COUNT DISTINCT authentication.device.ip
+   GROUP BY authentication.actor.user.email_addr
+   WITH authentication.status_id = SUCCESS AFTER 24h
+
+   -- Pattern 4 (MFA Fatigue): Auth attempts per user
+   SUMMARIZE COUNT authentication.user.uid
+   GROUP BY authentication.actor.user.email_addr
+   WITH authentication.message ICONTAINS 'MFA' AND authentication.status_id = FAILURE AFTER 24h
+
+   -- Pattern 8 (Service Account Anomaly): Distinct source IPs per service account
+   SUMMARIZE COUNT DISTINCT authentication.src_endpoint.ip
+   GROUP BY authentication.actor.user.email_addr
+   WITH authentication.actor.user.email_addr ICONTAINS 'svc' AFTER 7d
+   ```
+   Use SUMMARIZE to identify which entities exceed pattern thresholds, then follow up with QUERY on flagged entities for detailed timeline analysis. Use the IP and user field paths verified in Phase 1 (Absolute Rule 9) — the examples above use common paths but your environment may differ.
+
+   > **Constraints:** SUMMARIZE has known execution limits — `status_id` filtering fails on detection_finding (use GROUP BY instead), `FROM` not supported, high-cardinality GROUP BY can overflow. If SUMMARIZE returns empty, fall back to QUERY. See fsql-expert Layer 1c for workarounds and check `summarize_support` in the environment profile.
+
+4. **Classify** — apply thresholds to determine: CLEAN, SUSPICIOUS, or ACTIVE THREAT
+5. **If SUSPICIOUS or ACTIVE THREAT — cross-domain pivot and specialist invocation:**
+   - a. **Cross-domain pivot** — run Layer 1a discovery scans (`*.message, *.time`) against non-identity event types using the compromised user or attacker IP as the pivot key (see Cross-Domain Pivot Table below)
+   - b. **Follow up on pivot hits** — if the pivot returns records for non-identity event types, run targeted Layer 1b queries with specific field selectors. Use `Search_FSQL_SCHEMA` if querying an unfamiliar event type.
+   - c. **Invoke threat-intel-enricher** on all IOC IPs (Absolute Rule 6a)
+   - d. **Invoke identity-investigator** on all compromised accounts (Absolute Rule 6b)
+   - e. **Invoke network-investigator** if pivot reveals `network_activity`, `http_activity`, or `dns_activity` hits (Absolute Rule 6c)
+   - f. Invoke independent specialists **in parallel**
+6. **Log all queries** — append to `queries.md` immediately after every query execution, including pivot queries under a "Cross-Domain Pivot" subheading
+
+### Query Sharing Rules
+
+- **Patterns 1 & 2 share failure data:** Pattern 1 queries authentication failures. Pattern 2 reuses the same failure data for its analysis — do NOT re-query.
+- **Patterns 3 & 6 share success data:** Pattern 3 queries successful authentications with IP and geo data. Pattern 6 reuses this data for cross-IdP correlation — do NOT re-query.
+
+### Live Progress Reporting
+
+After EVERY query, report status to the analyst:
+
+```
+━━━ ITDR STATUS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Phase 2: Pattern Sweep | Pattern 3/8 (Impossible Travel) | Query 12
+Patterns complete: P1 CLEAN | P2 CLEAN | P3 running...
+Findings so far: 0 suspicious, 0 active threats
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+**Escalation and circuit breaker rules apply during this phase.** See the Escalation Rules section below for Active Threat hard gate, senior analyst review triggers, and circuit breaker checkpoints.
+
+---
+
+## Pattern Definitions
+
+### Pattern 1: Password Spraying (T1110.003)
+
+**What it detects:** An attacker trying a small number of common passwords against many accounts — the inverse of brute force. Designed to stay below per-account lockout thresholds.
+
+**MITRE technique:** T1110.003 — Brute Force: Password Spraying
+
+**Query approach:**
+
+Layer 1a — gauge authentication failure volume:
+```
+-- Discovery: how many auth failures exist in the window?
+QUERY authentication.message, authentication.time
+WITH authentication.status_id = FAILURE AFTER 7d
+```
+
+If failure volume exceeds ~1000 records, narrow with per-IdP queries or shorter time windows.
+
+Layer 1b — specific fields for spray analysis (use verified field paths from Phase 1):
+```
+QUERY authentication.<verified_ip_field>, authentication.<verified_user_field>,
+      authentication.time, authentication.status_id, authentication.message
+WITH authentication.status_id = FAILURE AFTER 7d
+```
+
+**Use the IP and user field paths verified in Phase 1 (Absolute Rule 9).** If Phase 1 determined `device.ip` is the populated IP field, use `device.ip` — NOT `src_endpoint.ip`. For HIGH VOLUME connectors, start at 2h (failures are filtered, lower volume than all auth).
+
+**Analysis logic:** Group results by source IP. Flag any IP that attempted 5+ distinct usernames within a 1-hour window. This is the spray signature — many users, few passwords, same source.
+
+**Thresholds:**
+
+| Level | Criteria |
+|-------|----------|
+| SUSPICIOUS | 5-15 distinct usernames per source IP per hour |
+| ACTIVE THREAT | 15+ distinct usernames per source IP per hour, OR spray followed by successful authentication from the same IP |
+
+**Follow-up actions:**
+- Check for subsequent successful authentication from the same source IPs
+- Invoke `digital-workers:threat-intel-enricher` on flagged source IPs: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- If success after spray detected, invoke `digital-workers:identity-investigator` on the compromised account: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+
+**Targeted actor search (critical):** After identifying spray source IPs, do NOT stop at aggregate analysis. For each spray source IP with successful authentications:
+1. Extract the specific usernames that succeeded from that IP
+2. Query each compromised user's full auth history across ALL IdPs (7d, per-user queries to avoid overflow)
+3. These users become priority targets for Pattern 3 (impossible travel) and Pattern 6 (cross-IdP)
+4. Run cross-domain pivot on each compromised user (see Cross-Domain Pivot Table)
+
+This ensures the skill finds the specific attack actors instead of getting lost in aggregate noise.
+
+**Note:** Pattern 2 reuses this failure data — do not discard.
+
+---
+
+### Pattern 2: Credential Stuffing (T1110.004)
+
+**What it detects:** An attacker using stolen credential pairs (from breaches) against your identity providers. Distinguished from spraying by volume, velocity, and cross-IdP indicators.
+
+**MITRE technique:** T1110.004 — Brute Force: Credential Stuffing
+
+**Query approach:** Reuses Pattern 1 failure data. No redundant query needed. Focus analysis on:
+- **Volume + velocity:** 50+ failures in a 10-minute window from a single IP or small IP range
+- **Cross-IdP signal:** Same IP stuffing both Entra ID and Okta (or any two IdPs). This is the strongest indicator — legitimate users do not authenticate across multiple IdPs from the same IP in rapid succession.
+
+If Pattern 1 did not surface sufficient data, query additional IdPs:
+```
+QUERY authentication.src_endpoint.ip, authentication.user.username,
+      authentication.time, authentication.status_id
+WITH authentication.status_id = FAILURE AFTER 7d
+```
+
+**Thresholds:**
+
+| Level | Criteria |
+|-------|----------|
+| SUSPICIOUS | 50+ failures in 10 minutes from one IP, OR 20+ failures across 2+ IdPs from the same IP |
+| ACTIVE THREAT | Stuffing failures followed by successful authentication from the same IP |
+
+**Follow-up actions:**
+- Check for post-stuffing successes — query successful auths from the same source IPs within 1 hour of the stuffing burst
+- If compromised accounts found, invoke `digital-workers:identity-investigator`: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- Invoke `digital-workers:threat-intel-enricher` on stuffing IPs: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+
+---
+
+### Pattern 3: Impossible Travel (T1078)
+
+**What it detects:** A user authenticating from two geographic locations that are physically impossible to travel between in the elapsed time — strong indicator of credential compromise or session hijacking.
+
+**MITRE technique:** T1078 — Valid Accounts
+
+**Query approach:**
+
+Layer 1a — gauge successful authentication volume:
+```
+QUERY authentication.message, authentication.time
+WITH authentication.status_id = SUCCESS AFTER 7d
+```
+
+Layer 1b — per-IdP query with username, IP, and time (shared with Pattern 6). **Use verified field paths from Phase 1:**
+```
+QUERY authentication.<verified_user_field>, authentication.<verified_ip_field>,
+      authentication.time, authentication.status_id, authentication.message
+WITH authentication.status_id = SUCCESS AFTER 7d
+```
+
+**If the verified IP field for a connector is `device.ip`, use that — NOT `src_endpoint.ip`.** A connector with empty `src_endpoint.ip` is NOT a reason to skip impossible travel — check `device.ip` first.
+
+**Geo resolution strategy (in order of preference):**
+1. **Geo fields in auth events** — check if the IdP connector provides geo fields (e.g., `authentication.src_endpoint.location`). Use if available.
+2. **TI connector fallback** — invoke `digital-workers:threat-intel-enricher` to resolve IP geolocation: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+3. **Raw IP comparison** — if geo is unavailable, flag same user authenticating from different IPs within a short window. Reduced confidence — note in findings.
+
+**Analysis logic:** For each user, sort authentications by time. Compare consecutive logins — if two logins from different locations are 500+ miles apart and within 1 hour, flag as impossible travel.
+
+**Priority order for actor checks (critical):** Do not analyze users at random. Check in this order:
+1. **Users identified as spray victims** (from Pattern 1 targeted actor search) — highest priority
+2. **Users with auth from known-malicious IPs** (from Pattern 1 IOCs or TI enrichment)
+3. **Users with auth from cloud/VPS IP ranges** (DigitalOcean, AWS, Azure, GCP, Linode, Vultr, OVH, Hetzner, Tencent, UCloud)
+4. **Broad per-user analysis** only if the above don't produce findings
+
+This priority order ensures seeded/targeted attack actors are checked before background noise drowns them out.
+
+**Thresholds:**
+
+| Level | Criteria |
+|-------|----------|
+| SUSPICIOUS | 500+ miles between logins within 1 hour |
+| ACTIVE THREAT | Impossible travel followed by post-authentication activity (data access, privilege changes, lateral movement) |
+
+**Follow-up actions:**
+- Invoke `digital-workers:identity-investigator` on the user: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- Invoke `digital-workers:threat-intel-enricher` on the anomalous IP: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+
+**Note:** Pattern 6 reuses this successful authentication data — do not discard.
+
+---
+
+### Pattern 4: MFA Fatigue (T1621)
+
+**What it detects:** An attacker triggering repeated MFA push notifications to exhaust the user into approving one — a social engineering technique that bypasses MFA entirely.
+
+**MITRE technique:** T1621 — Multi-Factor Authentication Request Generation
+
+**Schema-dependent gate:** Phase 1 must verify that MFA-specific fields exist in at least one identity connector. MFA fields vary by IdP — check for challenge/response events, push notification events, or MFA status fields.
+
+**If MFA fields exist:**
+
+```
+-- Query for MFA challenge events per user
+QUERY authentication.user.username, authentication.time, authentication.message,
+      authentication.status_id
+WITH [MFA-specific filter based on available fields] AFTER 7d
+```
+
+**Analysis logic:** Group MFA challenges by user. Flag any user with 5+ MFA challenges within a 10-minute window.
+
+**If MFA fields do NOT exist:** Mark as DATA GAP with specific remediation guidance:
+> "MFA Fatigue pattern requires MFA challenge/response event data. Current identity connectors do not expose MFA-specific fields. Remediation: Enable MFA audit logging in [IdP name] and verify OCSF mapping includes MFA event fields."
+
+**Thresholds:**
+
+| Level | Criteria |
+|-------|----------|
+| SUSPICIOUS | 5-10 MFA challenges per user within 10 minutes |
+| ACTIVE THREAT | 10+ MFA challenges followed by a successful authentication (user approved the push) |
+
+**Follow-up actions:**
+- Invoke `digital-workers:identity-investigator` on the targeted user: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- Check post-authentication activity — if the user approved under fatigue, what did the attacker do next?
+
+**Expected result in many environments:** DATA GAP. Most IdP connectors do not yet expose granular MFA challenge events. This is a valuable finding — it tells the customer what to enable.
+
+---
+
+### Pattern 5: Dormant Account Activation (T1078)
+
+**What it detects:** An account that has been inactive for an extended period suddenly authenticating — could indicate a compromised dormant account being activated by an attacker.
+
+**MITRE technique:** T1078 — Valid Accounts
+
+**Query approach:**
+
+Step 1 — Authentication-as-baseline (ALWAYS run this, regardless of user_inventory):
+
+This is the primary dormancy detection method. It works even when user_inventory has a different domain or no `last_sign_in` field.
+```
+-- Get authentication activity for the past 7 days (use verified field paths from Phase 1)
+QUERY authentication.<verified_user_field>, authentication.time,
+      authentication.<verified_ip_field>, authentication.status_id
+WITH authentication.status_id = SUCCESS AFTER 7d
+```
+
+**Use the verified IP and user field paths from Phase 1.** If Phase 1 determined that `device.ip` is the populated IP field, use `device.ip` here — NOT `src_endpoint.ip`.
+
+**HIGH VOLUME connector strategy:** The 7d query will overflow on HIGH VOLUME connectors. Instead of giving up, use this approach:
+1. Query the **most recent 2h** of successes (per QUERY CONFIG time guidance) — this is your "recent set"
+2. Query a **2h window from 3-5 days ago** (e.g., `AFTER 5d` with a 2h slice) — this is your "baseline set"
+3. Extract distinct usernames from each set
+4. Any user in the "recent set" who does NOT appear in the "baseline set" is a candidate dormant activation
+
+If the baseline query also overflows, narrow to per-connector 1h windows. The goal is two comparable time slices — you do NOT need the full 7d dataset.
+
+**Do NOT mark Pattern 5 as INCOMPLETE because of overflow.** Overflow is expected on HIGH VOLUME connectors. The chunked approach above works within the volume constraints. Only mark INCOMPLETE if both time slices overflow even at 1h windows.
+
+Partition approach for non-HIGH-VOLUME connectors (7d query fits inline):
+- **Baseline set** = users who authenticated between 2d and 7d ago
+- **Recent set** = users who authenticated in the last 1d
+- Any user in the "recent set" who does NOT appear in the "baseline set" is a candidate dormant activation
+- This is an analytical partition of the 7d query results, not separate queries. FSQL does not support BEFORE clauses.
+
+For each candidate dormant activation, check the source IP:
+- Suspicious geolocation (Russia, China, North Korea, Iran for accounts that normally authenticate domestically) → SUSPICIOUS
+- Cloud/VPS IP → SUSPICIOUS
+- Use the `Geolocate IPs` connector if available: `QUERY *.message, *.time WITH %ip = '<activation_ip>'` against the Geolocate IPs connector to resolve geography
+
+Step 2 (supplemental) — Check user_inventory for `last_sign_in` if available:
+
+If user_inventory has a `last_sign_in` or equivalent timestamp AND the user domain matches the auth domain, use it to extend dormancy detection beyond 7 days. Accounts with `last_sign_in` older than 90 days that suddenly authenticate are dormant activations.
+
+**Domain mismatch is NOT a blocker for Step 1.** The auth-as-baseline approach works entirely within authentication data — it does not need user_inventory. If user_inventory has a different domain, Step 1 still runs. Step 2 is supplemental.
+
+**Caveat:** With a 7-day authentication window, Step 1 can only detect accounts dormant for 7+ days that activated within the window. Step 2 (if `last_sign_in` is available) extends this. Document this limitation in findings.
+
+**Thresholds:**
+
+| Level | Criteria |
+|-------|----------|
+| SUSPICIOUS | Account dormant 6+ days authenticates from an unknown or unusual IP |
+| ACTIVE THREAT | Dormant account activates AND shows post-authentication activity (data access, account changes, lateral movement) |
+
+**Follow-up actions:**
+- Invoke `digital-workers:identity-investigator` on the activated account: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- Check for account modifications — was the password reset before activation? Were MFA settings changed?
+
+---
+
+### Pattern 6: Cross-IdP Anomaly (T1078) — THE DIFFERENTIATOR
+
+**What it detects:** The same user authenticating to different identity providers from different IP addresses within a short time window. No single-vendor ITDR tool can detect this because vendors only see their own IdP. Query federates across all IdPs in the mesh.
+
+**MITRE technique:** T1078 — Valid Accounts
+
+**This is the primary differentiator of the ITDR skill.** It exploits Query's unique position as a cross-IdP data mesh to detect identity threats that are invisible to any individual IdP vendor.
+
+**Query approach:** Reuses Pattern 3 successful authentication data. Query each IdP's authentication events separately if not already captured. **Use verified field paths from Phase 1:**
+
+```
+-- Per-IdP authentication with username and IP (use verified paths)
+QUERY authentication.<verified_user_field>, authentication.<verified_ip_field>,
+      authentication.time, authentication.message
+WITH authentication.status_id = SUCCESS AFTER 7d
+```
+
+**If one IdP uses `device.ip` and another uses `src_endpoint.ip`, that's fine — use the correct path per connector.** The cross-IdP comparison is by username and IP value, not by field path.
+
+**Analysis logic:** Correlate by username across IdPs. For each user who appears in multiple IdPs, compare source IPs and timestamps. Flag any user authenticating to different IdPs from different IPs within a 30-minute window.
+
+**Single-IdP handling:** If the mesh contains only one identity provider, mark Pattern 6 as NOT APPLICABLE (not CLEAN, not DATA GAP). Cross-IdP correlation requires 2+ IdPs by definition.
+
+**Thresholds:**
+
+| Level | Criteria |
+|-------|----------|
+| SUSPICIOUS | Same user, different IdPs, different source IPs within 30 minutes |
+| ACTIVE THREAT | Different geolocations across IdPs AND post-authentication anomalies (privilege changes, unusual data access) |
+
+**Follow-up actions:**
+- Invoke `digital-workers:identity-investigator` for a full deep dive on the user: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- Invoke `digital-workers:threat-intel-enricher` on both source IPs: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- Determine if this is a legitimate scenario (user on VPN + mobile) or compromise
+
+---
+
+### Pattern 7: Privilege Escalation (T1098)
+
+**What it detects:** Unauthorized or anomalous privilege grants — admin role assignments, group membership changes, permission escalations that may indicate an attacker consolidating access.
+
+**MITRE technique:** T1098 — Account Manipulation
+
+**Schema-dependent gate:** Phase 1 must verify that `entity_management` or `account_change` events exist.
+
+**If entity_management/account_change exists:**
+```
+QUERY entity_management.message, entity_management.time,
+      entity_management.user.username, entity_management.type_name
+AFTER 30d
+```
+
+Or for account_change:
+```
+QUERY account_change.message, account_change.time,
+      account_change.user.username, account_change.type_name
+AFTER 30d
+```
+
+**30-day lookback is intentional.** Privilege escalation is low-volume, high-impact. A 7-day window may miss slow-burn attacks.
+
+**Fallback:** If neither `entity_management` nor `account_change` exist, try `api_activity` for admin API calls:
+```
+QUERY api_activity.message, api_activity.time,
+      api_activity.user.username, api_activity.type_name
+AFTER 30d
+```
+
+**If none of these event types exist:** Mark as DATA GAP with remediation guidance.
+
+**Thresholds:**
+
+| Level | Criteria |
+|-------|----------|
+| SUSPICIOUS | Admin role granted outside business hours, OR granted by a non-admin account, OR self-grant of elevated privileges |
+| ACTIVE THREAT | Privilege grant to a recently compromised account (flagged in another pattern), OR multiple escalations in a short window |
+
+**Follow-up actions:**
+- Invoke `digital-workers:identity-investigator` on BOTH the granting account and the receiving account: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- Check if the receiving account was flagged in Patterns 1-6
+
+**Expected result in many environments:** DATA GAP. Many IdP connectors do not yet map privilege change events to OCSF `entity_management` or `account_change`. Document this gap with specific remediation.
+
+---
+
+### Pattern 8: Service Account Abuse (T1078.001)
+
+**What it detects:** Service accounts being used interactively — a strong indicator of credential theft or misuse, since service accounts should authenticate only via automated processes.
+
+**MITRE technique:** T1078.001 — Valid Accounts: Default Accounts
+
+**Query approach:**
+
+Step 1 — Identify service accounts from TWO sources:
+
+**Source A: user_inventory** (if available and same domain as auth events):
+```
+QUERY user_inventory.user.username, user_inventory.user.type,
+      user_inventory.message, user_inventory.time
+AFTER 1d
+```
+
+Look for naming conventions (svc_, service_, sa-), account type fields, or accounts flagged as non-interactive.
+
+**Source B: authentication data directly** (ALWAYS run this, even if Source A returns results):
+```
+-- Search for service account naming patterns in auth events
+QUERY authentication.<verified_user_field>, authentication.<verified_ip_field>,
+      authentication.http_request.user_agent, authentication.time,
+      authentication.status_id, authentication.message
+WITH authentication.<verified_user_field> ICONTAINS 'svc' AFTER 7d
+
+-- Also search for 'service' and 'sa-' patterns
+QUERY authentication.<verified_user_field>, authentication.<verified_ip_field>,
+      authentication.time, authentication.message
+WITH authentication.<verified_user_field> ICONTAINS 'service' AFTER 7d
+```
+
+Run Source B against EVERY IdP connector. Service accounts may exist in one IdP but not another. **Do NOT skip Source B even if Source A found nothing** — service accounts authenticate even when they're not in user_inventory.
+
+Step 2 — For each service account found (from either source), query its full auth history:
+```
+QUERY authentication.<verified_user_field>, authentication.<verified_ip_field>,
+      authentication.http_request.user_agent, authentication.time,
+      authentication.status_id, authentication.message
+WITH authentication.<verified_user_field> = '<service_account>' AFTER 7d
+```
+
+**Analysis logic:** Flag service accounts with:
+- Browser user agents (interactive login)
+- Workstation/desktop source IPs (not server IPs)
+- Authentication from unexpected networks
+- Off-hours authentication (if the service should run on a schedule)
+
+**Thresholds:**
+
+| Level | Criteria |
+|-------|----------|
+| SUSPICIOUS | Service account with browser user agent or workstation source IP |
+| ACTIVE THREAT | Service account source IP was flagged in another pattern (spraying source, impossible travel endpoint, etc.) |
+
+**Follow-up actions:**
+- Invoke `digital-workers:identity-investigator` on the service account: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+- Determine blast radius — what systems does this service account have access to?
+- **Identify the human user on the workstation.** If the anomalous login came from a workstation IP, query auth events from that IP to find the regular user who was logged in at the time:
+  ```
+  QUERY authentication.<verified_user_field>, authentication.time,
+        authentication.status_id, authentication.message
+  WITH authentication.<verified_ip_field> = '<workstation_ip>' AFTER 24h
+  ```
+  Filter out the service account itself — the remaining users are the workstation's regular operators. The user logged in closest to the anomalous service account login time is the most likely person who used the credentials.
+
+---
+
+## Cross-Domain Pivot Table
+
+When a pattern classifies a finding as SUSPICIOUS or ACTIVE THREAT, use this table to determine the next best move. The pivot extends the investigation beyond identity data into proxy, network, process, and other domains — following the attack chain where no single-vendor ITDR tool can go.
+
+### Pivot Lookup
+
+| Identity Finding | Pivot Key | Pivot Query | What You're Looking For |
+|---|---|---|---|
+| Compromised account (spray success, impossible travel, cross-IdP) | `%email` (the compromised user) | `QUERY *.message, *.time WITH %email = '<user>' AFTER 24h` | Which non-identity event types contain this user's activity — proxy browsing, file access, process execution, cloud API calls |
+| Compromised account | `%ip` (the attacker IP) | `QUERY *.message, *.time WITH %ip = '<attacker_ip>' AFTER 7d` | What else has this IP touched — other users, other systems, other event types |
+| Service account abuse | `%email` (svc account) | `QUERY *.message, *.time WITH %email = '<svc_account>' AFTER 24h` | What did the service account access after the interactive login — cloud admin consoles, internal systems, data stores |
+| Service account abuse | `%ip` (workstation IP) | `QUERY *.message, *.time WITH %ip = '<workstation_ip>' AFTER 24h` | What else originated from the workstation that accessed the service account |
+| Any malicious IP (from TI enrichment) | `%ip` | `QUERY *.message, *.time WITH %ip = '<malicious_ip>' AFTER 7d` | Full mesh-wide footprint of this IP across all event types |
+| Cross-IdP anomaly | `%email` + both IPs | Same as compromised account pivots | Verify the IP discrepancy, check for post-auth activity from both IPs |
+
+### Reading Pivot Results
+
+The Layer 1a pivot returns records with the `__event` field showing which event types matched. Here's what each event type means and what to look for in the Layer 1b follow-up:
+
+| Event Type | Domain | What To Look For |
+|---|---|---|
+| `http_activity` | Proxy/Web | C2 beaconing (regular interval connections), phishing clicks, cloud admin console access (AWS/Azure/GCP consoles), exfil to cloud storage (Dropbox, OneDrive, IceDrive) |
+| `network_activity` | Network flow/IPS | Lateral movement (SMB port 445, RDP 3389, SSH 22, WinRM 5985/5986), unusual ports, data exfil volume, scanning patterns |
+| `process_activity` | Endpoint/EDR | Post-compromise tooling, LOLBins, credential dumping, persistence mechanisms |
+| `file_activity` | File system | Staging directories, exfil preparation, malware drops, sensitive file access |
+| `dns_activity` | DNS | Beaconing patterns (regular interval queries to same domain), DGA domains, DNS tunneling (TXT record queries) |
+| `email_activity` | Email | Phishing delivery, BEC, forwarding rule creation |
+| `data_security_finding` | DLP | Exfiltration attempts, policy violations, large outbound transfers |
+| `api_activity` | Cloud control plane | Privilege escalation, resource creation, key generation, IAM changes |
+| `detection_finding` | Security alerts | Existing alerts the SOC may have missed or not correlated with the identity finding |
+
+### Pivot Execution Rules
+
+1. **Trigger condition:** Pivot runs ONLY when a pattern classifies a finding as SUSPICIOUS or ACTIVE THREAT. CLEAN and DATA GAP patterns do not trigger pivots.
+2. **Always Layer 1a first.** The pivot query is always `*.message, *.time` with an observable filter. This returns the `__event` field showing which event types matched — without overflowing.
+3. **Follow up on hits.** If Layer 1a returns records for a non-identity event type, run a targeted Layer 1b query with specific field selectors for that event type. Use `Search_FSQL_SCHEMA` if you haven't queried this event type before.
+4. **Maximum 3 pivot queries per finding.** The pivot is investigative triage, not a full incident investigation. If the pivot reveals a complex attack chain, document what you found and note it for the analyst — don't try to investigate everything.
+5. **Log every pivot query in queries.md** under a "Cross-Domain Pivot" subheading for the pattern.
+6. **Pivot queries count toward the circuit breaker.** The 25-minute checkpoint and 45-minute hard pause include pivot query time.
+7. **Run independent pivot queries in parallel.** If pivoting on both a user email and an IP for the same finding, batch them in a single parallel call.
+8. **Pivot time windows are defaults, subject to Rule 8.** If the target connector is HIGH VOLUME, start with shorter windows per the volume heuristic.
+9. **All pivot queries are called directly** via `Validate_FSQL_Query` and `Execute_FSQL_Query` MCP tools per Absolute Rule 7. Do NOT dispatch to fsql-expert sub-skill for pivot queries.
+10. **Check pivot viability first.** Consult the Pivot Viability section of `identity-data-map.md` before running pivots. If no connectors produce the target event type, skip that pivot and document the gap.
+
+---
+
+## Phase 2 Exit Gate
+
+### Hard Gate — Phase 2 Exit
+
+Before proceeding to Phase 3, verify:
+- `queries.md` has entries for every pattern attempted (8 patterns, even if some are DATA GAP or NOT APPLICABLE)
+- `iocs.md` has been written if any IOCs were discovered
+- Every pattern has a classification: ACTIVE THREAT, SUSPICIOUS, CLEAN, DATA GAP, ERROR, INCOMPLETE, or NOT APPLICABLE
+
+**Phase 2 exit verification checklist:**
+- [ ] All 8 patterns attempted or documented as NOT VIABLE (from Phase 1 data map)
+- [ ] Every query logged in `queries.md`
+- [ ] Specialist skills invoked for all SUSPICIOUS and ACTIVE THREAT findings
+- [ ] IOCs written to `iocs.md` if any discovered
+- [ ] No undocumented queries
+
+If `queries.md` does not have entries for all patterns, STOP. Complete the missing patterns or document why they were skipped.
+
+Continue immediately to Phase 3 — do not stop or wait for user input.
+
+---
+
+## Phase 3: Synthesis & Report
+
+**Goal:** Correlate findings across patterns, build the scorecard, construct the attack narrative, and produce the final assessment report.
+
+### Process
+
+**Step 1: Cross-pattern correlation**
+
+Look for accounts and IPs that appear in multiple patterns:
+- Account flagged in Pattern 1 (spraying target) AND Pattern 5 (dormant activation) = likely compromised dormant account
+- IP flagged in Pattern 1 (spray source) AND Pattern 8 (service account login source) = attacker pivoting from spraying to service account abuse
+- Account flagged in Pattern 3 (impossible travel) AND Pattern 7 (privilege escalation) = attacker with stolen credentials escalating access
+
+Document every cross-pattern correlation. These are the highest-confidence findings.
+
+**Step 2: Build the scorecard**
+
+Create the per-pattern status table (see scorecard template below).
+
+**Step 3: Construct attack narrative**
+
+Build a chronological timeline across all IdPs, connecting findings into a coherent narrative. If multiple patterns fire for the same actor, this is where the kill chain emerges.
+
+**Step 4: Score overall risk**
+
+| Risk Level | Criteria |
+|------------|----------|
+| HEALTHY | All patterns CLEAN or DATA GAP, no SUSPICIOUS findings |
+| ELEVATED RISK | One or more SUSPICIOUS findings, no ACTIVE THREAT |
+| ACTIVE THREAT | One or more ACTIVE THREAT findings confirmed |
+
+**Step 5: Generate the report**
+
+Write `report.md` following the report template below. Display the report inline in the conversation — the analyst reads and acts in the conversation. The file is the durable audit trail.
+
+**Step 6: Invoke senior analyst review (MANDATORY HARD GATE)**
+
+Before presenting the report to the analyst, check these conditions:
+- If `overall_risk` = ACTIVE THREAT → invoke `senior-analyst-review`. **NOT OPTIONAL.**
+- If `finding_count(SUSPICIOUS)` >= 2 → invoke `senior-analyst-review`.
+- If cross-pattern correlation identifies a kill chain → invoke `senior-analyst-review`.
+- If analyst explicitly requests it → invoke `senior-analyst-review`.
+
+Invoke with instruction: "Return results to the ITDR orchestrator and continue. Do not present to the user or wait for input."
+
+The review skill writes `review.md`. Wait for it to complete before presenting the report. This gate exists because ACTIVE THREAT findings have compliance and escalation implications. The senior analyst review catches blind spots, false escalations, and missing context before the analyst acts on the report.
+
+**Step 7: Save all artifacts**
+
+Write using the Write tool (never Bash/echo):
+- `report.md` — full assessment report
+- `queries.md` — should already be complete from Phase 2
+- `iocs.md` — all IOCs discovered (should already exist if IOCs found)
+- `scorecard.md` — machine-parseable scorecard (YAML format)
+
+**Step 8: Update environment profile**
+
+If `digital-workers/learned/environment-profile.json` exists, note identity-specific findings:
+- Identity connectors discovered and their capabilities
+- Data gaps identified
+- Patterns that worked well vs. those that need better data
+- Any false positive patterns to note for future assessments
+
+**Step 9: Present report inline**
+
+Display the full report in the conversation. The analyst reads and acts here. The saved files are the audit trail — the conversation is the workspace.
+
+### Report Template
+
+```markdown
+# ITDR Assessment Report
+
+## 1. Business Summary
+
+[2-3 sentences in plain English. What did the assessment find? What is the overall risk posture?
+What are the top 1-2 actions the security team should take?]
+
+## 2. Scorecard
+
+- **Environment:** [customer/mesh name]
+- **Identity Providers:** [list of IdPs discovered]
+- **Users analyzed:** [count from user_inventory or authentication data]
+- **Time range:** [lookback period]
+- **Overall risk:** [HEALTHY / ELEVATED RISK / ACTIVE THREAT]
+
+| # | Pattern | MITRE | Status | Confidence | Finding Summary |
+|---|---------|-------|--------|------------|-----------------|
+| 1 | Password Spraying | T1110.003 | [status] | [HIGH/MEDIUM/LOW] | [1-line summary] |
+| 2 | Credential Stuffing | T1110.004 | [status] | [HIGH/MEDIUM/LOW] | [1-line summary] |
+| 3 | Impossible Travel | T1078 | [status] | [HIGH/MEDIUM/LOW] | [1-line summary] |
+| 4 | MFA Fatigue | T1621 | [status] | [HIGH/MEDIUM/LOW] | [1-line summary] |
+| 5 | Dormant Account Activation | T1078 | [status] | [HIGH/MEDIUM/LOW] | [1-line summary] |
+| 6 | Cross-IdP Anomaly | T1078 | [status] | [HIGH/MEDIUM/LOW] | [1-line summary] |
+| 7 | Privilege Escalation | T1098 | [status] | [HIGH/MEDIUM/LOW] | [1-line summary] |
+| 8 | Service Account Abuse | T1078.001 | [status] | [HIGH/MEDIUM/LOW] | [1-line summary] |
+
+## 3. Findings
+
+[Ordered by severity — ACTIVE THREAT first, then SUSPICIOUS]
+
+### Finding [N]: [Title]
+
+- **Severity:** [ACTIVE THREAT / SUSPICIOUS]
+- **MITRE Technique:** [ID — Name]
+- **Pattern:** [which pattern detected this]
+- **What happened:** [description of the finding]
+- **Evidence:**
+  - Query: `[exact FSQL query]`
+  - Result: [count] records, [summary of key data points]
+- **Identity Investigation:** [results from identity-investigator, or "Not applicable"]
+- **Threat Intel:** [results from threat-intel-enricher, or "Not applicable"]
+- **Recommended Action:** [specific remediation steps]
+
+## 4. Cross-Pattern Correlation
+
+### Entity Correlation Table
+
+Build a correlation table linking every entity (user, IP, host, service account) discovered across patterns and pivots. This table is the connective tissue of the investigation — it shows how identity findings link to network, endpoint, and application activity.
+
+| Entity | Type | Patterns | Pivots | Context |
+|--------|------|----------|--------|---------|
+| [e.g., svc-backup@...] | Service Account | P8 | Okta auth, DHCP (LAP-890) | Interactive browser login from workstation |
+| [e.g., 172.16.82.127] | IP (Workstation) | P8 | DHCP, HTTP, network, vuln | LAP-890 laptop, CVE-2013-1985, regular user + svc-backup@ |
+| [e.g., barbara.salazar@...] | User | P1, P3, P6 | email, HTTP, proxy | Spray victim, impossible travel VA→Singapore, C2 beaconing |
+
+Include EVERY entity that appeared in a finding or pivot — users, IPs, hostnames, service accounts, domains. The table should let the analyst trace connections: "this IP maps to this host, which was used by this user, who also appeared in this pattern."
+
+### Accounts in Multiple Patterns
+[List accounts that appeared in 2+ patterns with what was found in each]
+
+### IPs in Multiple Patterns
+[List IPs that appeared in 2+ patterns with what was found in each]
+
+### Kill Chain Assessment
+[If cross-pattern findings suggest a coherent attack chain, describe it here.
+If no cross-pattern correlation found, state: "No cross-pattern correlation identified."]
+
+## 5. Attack Narrative
+
+[Chronological timeline connecting all findings across all IdPs]
+
+| Timestamp | Event | Source | Significance |
+|-----------|-------|--------|-------------|
+| [time] | [what happened] | [which IdP/connector] | [why it matters] |
+
+[If no attack narrative emerges, state: "No coherent attack narrative identified. Findings are isolated events."]
+
+## 6. Data Gaps & Recommendations
+
+[Per gap identified]
+
+### Gap [N]: [Title]
+
+- **Impact:** [which patterns were blocked or degraded]
+- **Blocked techniques:** [MITRE technique IDs that cannot be tested]
+- **Remediation:** [specific steps to close the gap]
+- **Priority:** [CRITICAL / HIGH / MEDIUM / LOW]
+
+## 7. MITRE ATT&CK Coverage
+
+| Technique | Status | Finding |
+|-----------|--------|---------|
+| T1110.003 — Password Spraying | [TESTED / GAP] | [summary or gap reason] |
+| T1110.004 — Credential Stuffing | [TESTED / GAP] | [summary or gap reason] |
+| T1078 — Valid Accounts | [TESTED / GAP] | [summary or gap reason] |
+| T1621 — MFA Request Generation | [TESTED / GAP] | [summary or gap reason] |
+| T1098 — Account Manipulation | [TESTED / GAP] | [summary or gap reason] |
+| T1078.001 — Default Accounts | [TESTED / GAP] | [summary or gap reason] |
+```
+
+### Scorecard YAML Format (scorecard.md)
+
+```yaml
+itdr_assessment:
+  date: "YYYY-MM-DD"
+  environment: "[mesh name]"
+  identity_providers:
+    - name: "[IdP name]"
+      connector: "[connector name]"
+      type: "[static/dynamic]"
+  overall_risk: "[HEALTHY/ELEVATED RISK/ACTIVE THREAT]"
+  patterns:
+    - id: 1
+      name: "Password Spraying"
+      mitre: "T1110.003"
+      status: "[ACTIVE THREAT/SUSPICIOUS/CLEAN/DATA GAP/ERROR/INCOMPLETE/NOT APPLICABLE]"
+      confidence: "[HIGH/MEDIUM/LOW]"
+      finding_count: 0
+      summary: "[1-line summary]"
+    - id: 2
+      name: "Credential Stuffing"
+      mitre: "T1110.004"
+      status: "[status]"
+      confidence: "[confidence]"
+      finding_count: 0
+      summary: "[summary]"
+    - id: 3
+      name: "Impossible Travel"
+      mitre: "T1078"
+      status: "[status]"
+      confidence: "[confidence]"
+      finding_count: 0
+      summary: "[summary]"
+    - id: 4
+      name: "MFA Fatigue"
+      mitre: "T1621"
+      status: "[status]"
+      confidence: "[confidence]"
+      finding_count: 0
+      summary: "[summary]"
+    - id: 5
+      name: "Dormant Account Activation"
+      mitre: "T1078"
+      status: "[status]"
+      confidence: "[confidence]"
+      finding_count: 0
+      summary: "[summary]"
+    - id: 6
+      name: "Cross-IdP Anomaly"
+      mitre: "T1078"
+      status: "[status]"
+      confidence: "[confidence]"
+      finding_count: 0
+      summary: "[summary]"
+    - id: 7
+      name: "Privilege Escalation"
+      mitre: "T1098"
+      status: "[status]"
+      confidence: "[confidence]"
+      finding_count: 0
+      summary: "[summary]"
+    - id: 8
+      name: "Service Account Abuse"
+      mitre: "T1078.001"
+      status: "[status]"
+      confidence: "[confidence]"
+      finding_count: 0
+      summary: "[summary]"
+  data_gaps:
+    - pattern: "[pattern name]"
+      impact: "[description]"
+      remediation: "[steps]"
+      priority: "[CRITICAL/HIGH/MEDIUM/LOW]"
+  cross_pattern_correlations:
+    - accounts: ["[username]"]
+      patterns: [1, 5]
+      description: "[what was found]"
+```
+
+### Artifact Structure
+
+```
+docs/investigations/YYYY-MM-DD-itdr-assessment/
+  identity-data-map.md  <- Phase 1 output
+  queries.md            <- Every query (all phases)
+  iocs.md               <- IOCs discovered (if any)
+  scorecard.md          <- Machine-parseable scorecard (YAML)
+  report.md             <- Full report (displayed inline + saved)
+```
+
+Create the directory at Phase 1 entry. Write artifacts at each phase exit using the Write tool (never Bash/echo). The `review.md` file is written by the `senior-analyst-review` skill when invoked at Phase 3, Step 6 — the ITDR orchestrator does not write it directly.
+
+---
+
+## Escalation Rules
+
+### Active Threat Hard Gate
+
+If ANY pattern classifies a finding as ACTIVE THREAT at any point during the sweep:
+
+1. **STOP the pattern sweep immediately.** Do not continue to the next pattern.
+2. Package the evidence gathered so far — all queries, findings, IOCs.
+3. Present the analyst with three options:
+
+```
+ACTIVE THREAT DETECTED — Pattern [N]: [Pattern Name]
+  [Description of the finding]
+  Evidence: [key data points]
+
+  Options:
+    1. "escalate"  — Hand off to alert-investigation for formal incident triage
+    2. "continue"  — Continue the ITDR sweep (threat documented, analyst accepts risk)
+    3. "wrap up"   — Stop the sweep, produce report with current findings
+```
+
+4. Wait for analyst decision. This is the ONE place where the skill pauses for input.
+
+### Senior Analyst Review Triggers
+
+Senior analyst review is now a **mandatory hard gate** in Phase 3, Step 6. See that section for the full trigger conditions and invocation instructions. It is NOT optional when ACTIVE THREAT findings exist.
+
+### Circuit Breaker
+
+- **25-minute checkpoint:** Pause and report progress. How many patterns complete? How many remaining? Any findings so far?
+- **45-minute hard pause:** If the sweep has been running for 45 minutes, stop and present status:
+
+```
+ITDR SWEEP PAUSED — Circuit breaker at [time] minutes
+  Patterns complete: [N]/8
+  Patterns remaining: [list]
+  Findings so far: [summary]
+
+  Options:
+    "continue" — extend the sweep to complete remaining patterns
+    "wrap up"  — produce report with current findings (incomplete noted)
+```
+
+---
+
+## Error Handling
+
+### Pattern Status Taxonomy
+
+Every pattern MUST be assigned one of these 7 statuses:
+
+| Status | Meaning |
+|--------|---------|
+| ACTIVE THREAT | Confirmed malicious activity detected |
+| SUSPICIOUS | Anomalous behavior that warrants investigation but is not confirmed malicious |
+| CLEAN | Pattern tested, no evidence of the attack. Confidence level attached (HIGH = good data, MEDIUM = limited data, LOW = minimal data) |
+| DATA GAP | Required data not available. Specific remediation documented. |
+| ERROR | Query failed after retry. Error logged, pattern not tested. |
+| INCOMPLETE | Pattern partially tested — some queries succeeded, some failed or timed out |
+| NOT APPLICABLE | Pattern cannot apply to this environment (e.g., Cross-IdP with only one IdP) |
+
+### Query Error Handling
+
+When a query fails:
+1. Log the error in `queries.md` with the full error message
+2. Run `Search_FSQL_SCHEMA` to verify field paths
+3. Retry with corrected field paths
+4. If retry also fails, mark the pattern as ERROR and move to the next pattern
+
+### Empty Result Handling
+
+When a query returns 0 records:
+- **Static schema connector:** CLEAN with HIGH confidence — the data source is reliable, empty means no matching events
+- **Dynamic schema connector:** CLEAN with MEDIUM confidence — add caveat that empty results on a dynamic connector may mean data is mapped differently. Document possible explanations:
+  - Data genuinely does not exist
+  - Data exists but mapped to a different OCSF path
+  - Time range or filter excluded records
+
+### Specialist Invocation Failure
+
+If a specialist skill fails to return results:
+1. Log the failure in `queries.md`
+2. Continue the sweep — do not block on specialist failure
+3. Note in the report that specialist analysis was attempted but unavailable
+
+### No Identity Connectors
+
+If Phase 1 discovers zero identity connectors, do not proceed to Phase 2. Present a clear message (see Phase 1 failure mode). This is NOT an error — it is a legitimate finding about the customer's mesh configuration.
+
+---
+
+## Hard Gates
+
+| Gate | Phase | Required Artifacts | If Missing |
+|------|-------|--------------------|------------|
+| 1 | Phase 1 Exit | `identity-data-map.md` | STOP. Write the data map. Do NOT proceed to Phase 2. |
+| 2 | Phase 2 Exit | `queries.md` with entries for all 8 patterns | STOP. Complete missing pattern queries or document why skipped. |
+| 3 | Phase 2 Exit | `iocs.md` (if IOCs found) | STOP. Write IOC file before Phase 3. |
+| 4 | Phase 3 Exit | `report.md`, `scorecard.md` | STOP. Generate the report and scorecard. Do NOT present without artifacts saved. |
+| 5 | Phase 3 Exit | `review.md` (if ACTIVE THREAT) | STOP. Invoke senior-analyst-review before presenting. Do NOT skip this on ACTIVE THREAT findings. |
+
+---
+
+## Red Flags
+
+| Red Flag | Correct Action |
+|----------|---------------|
+| "Only 3 patterns detected threats, skip the other 5" | STOP. Every pattern runs. Every gap is documented. The Iron Law is non-negotiable. |
+| "No data for this pattern, marking as CLEAN" | STOP. No data is DATA GAP, not CLEAN. These are fundamentally different statuses with different implications. |
+| "This is just a service account, skip it" | STOP. Service account compromise is often MORE severe than user compromise. Run Pattern 8 fully. |
+| "Only one IdP in the mesh, skip Cross-IdP" | Mark as NOT APPLICABLE, not skipped. Document why and note the gap in cross-IdP visibility. |
+| "The spray volume is low, probably not an attack" | STOP. Low-volume sprays are intentionally designed to evade thresholds. Complete the analysis. Apply the thresholds. |
+| Starting Phase 2 without the identity data map | STOP. Go back to Phase 1. The data map determines which patterns are viable. Without it, you are guessing. |
+| Using `**` on authentication queries across all IdPs | STOP. Authentication events across multiple IdPs will overflow. Use specific field selectors. |
+| Processing MCP results with Bash/python/jq | STOP. You are an LLM. Parse JSON natively. Re-read Absolute Rule 1. |
+| Skipping specialist invocation for SUSPICIOUS findings | STOP. Absolute Rule 6 requires specialist invocation. The identity-investigator and threat-intel-enricher exist for a reason. |
+| Not logging a query because it returned empty | STOP. Every query is logged — success, failure, or empty. Absolute Rule 5. |
+| "INCIDENT DECLARED" in the report | STOP. Use "RECOMMEND ESCALATION" or "Proposed Disposition." The worker recommends — humans declare incidents. |
+| Presenting findings without saving artifact files | STOP. Hard Gate 4 requires saved artifacts. Write the files first, then present inline. |
+| Marking a pattern CLEAN when query returned an error | STOP. Error ≠ Clean. Use the ERROR status. Errors mean data may exist but couldn't be accessed. |
+| Marking CLEAN on a dynamic connector without a confidence caveat | STOP. Dynamic connectors have customer-defined mappings. Empty results could mean the data is mapped differently. Mark CLEAN with MEDIUM confidence and document the caveat. |
+| Not querying all available IdPs for each pattern | STOP. Every pattern runs against every identity source in the data map. A pattern only tested against Entra but not Okta is incomplete. |
+| Producing the report without an attack narrative for findings | STOP. The attack narrative is the differentiator. If there are findings, there must be a chronological timeline. This is what no other ITDR tool produces. |
+| Generating the scorecard without confidence levels | STOP. Confidence tells the analyst how much to trust each result. HIGH for static connectors, MEDIUM for dynamic, N/A for DATA GAP. Always include it. |
+| Finding a compromised account but not checking what they did next | STOP. Run the cross-domain pivot. Identity is the starting point, not the endpoint. Follow the attack chain into proxy, network, process, and cloud API logs. |
+| Documenting "Identity Investigation: Not invoked" or "Threat Intel: Not invoked" in the report | STOP. Absolute Rule 6 makes specialist invocation mandatory on SUSPICIOUS and ACTIVE THREAT findings. "Not invoked" means you skipped a required step. Go back and invoke them. |
+| Analyzing only aggregate data without drilling into specific actors | STOP. Aggregate analysis finds patterns; targeted actor search finds the attackers. After identifying suspicious IPs, extract the specific users and investigate each one. |
+| Skipping the cross-domain pivot because "this is an identity assessment" | STOP. The cross-domain pivot is what makes this assessment valuable. Identity compromise → what happened next? That's the question only Query can answer across the mesh. |
+| Completing the assessment without invoking senior-analyst-review on ACTIVE THREAT | STOP. Phase 3 Step 6 is a mandatory hard gate. The review catches blind spots before the analyst acts on the report. |
+| Marking a pattern CLEAN because `src_endpoint.ip` is empty, without checking `device.ip` | STOP. Absolute Rule 9 requires IP field resolution in Phase 1. If you skipped it, go back and check both paths. Empty `src_endpoint.ip` does NOT mean no IP data exists. |
+| Pattern 8: "No service accounts found in user_inventory, marking CLEAN" | STOP. User_inventory is only one source. You MUST also search authentication data directly for svc/service/sa- naming patterns across ALL IdPs. Service accounts authenticate even when they're not in user_inventory. |
+| Pattern 5: "Domain mismatch, marking CLEAN" | STOP. Domain mismatch does NOT block Pattern 5. The auth-as-baseline approach (Step 1) works entirely within authentication data and does not need user_inventory. Run it. |
+| Using `src_endpoint.ip` in queries when Phase 1 determined that `device.ip` is the populated field | STOP. Use the verified IP path from Phase 1. Using the wrong path returns empty results and leads to false CLEAN classifications. |