Threat Pulse

Threat Pulse — Instructions

Purpose

The Threat Pulse skill is a rapid, broad-spectrum security scan designed for the "if you only had 15 minutes" scenario. It executes 12 queries across 7 security domains in parallel, producing a prioritized dashboard of findings with drill-down recommendations to specialized investigation skills.

What this skill covers:

Data sources: SecurityIncident, SecurityAlert, IdentityInfo, AADUserRiskEvents, EntraIdSignInEvents, DeviceProcessEvents, DeviceLogonEvents, ExposureGraphNodes, AADServicePrincipalSignInLogs, EmailEvents, CloudAppEvents, AuditLogs, DeviceTvmSoftwareVulnerabilities, DeviceTvmSoftwareVulnerabilitiesKB

Portal URL patterns are defined in the Defender XDR Portal Links table in the Take Action section. Append tid=<tenant_id> (from config.json) to ALL security.microsoft.com URLs — use ?tid= or &tid= depending on existing query params. Omit if tenant_id is not configured.

📑 TABLE OF CONTENTS

1. Critical Workflow Rules
2. Execution Workflow — Phase 0–3
3. Phase 4: Interactive Follow-Up Loop
4. Take Action — Portal links, AH queries, defanging
5. Sample KQL Queries — 12 queries
6. Post-Processing — Drift scores, cross-query correlation
7. Query File Recommendations
8. Report Template — Inline + full markdown file structure
9. Known Pitfalls
10. Quality Checklist
11. SVG Dashboard Generation

⚠️ CRITICAL WORKFLOW RULES - READ FIRST ⚠️

1. Workspace selection — Follow the SENTINEL WORKSPACE SELECTION rule from copilot-instructions.md. Call list_sentinel_workspaces() before first query.

2. Read config.json — Load workspace ID, tenant, subscription, and Azure MCP parameters before execution.

3. Output defaults — Default to inline chat with 7d lookback. Only ask the user for output preferences if they explicitly mention a different mode (e.g., "save to file", "markdown report", "30 day lookback"). If the user just says "threat pulse", "run a scan", or similar — proceed immediately with defaults, do not prompt.

4. ⛔ MANDATORY: Evidence-based analysis only — Every finding must cite query results. Every "clear" verdict must cite 0 results. Follow the Evidence-Based Analysis rule from copilot-instructions.md.

5. Parallel execution — Run the Data Lake query (Q5) and all Advanced Hunting queries (Q1, Q2, Q3, Q4, Q6, Q7, Q8, Q9, Q10, Q11, Q12) simultaneously.

6. Cross-query correlation — After all queries complete, check for correlated findings per the Cross-Query Correlation table in Post-Processing. Escalate priority when patterns match.

7. SecurityIncident output rule — Every incident MUST include a clickable Defender XDR portal URL: https://security.microsoft.com/incidents/{ProviderIncidentId}?tid=<tenant_id>. See Tenant ID in Portal URLs.

8. ⛔ MANDATORY: Query File Recommendations (tiered) — After rendering the main report body (Dashboard Summary through Recommended Actions), append the Query File Recommendations section. This runs AFTER the report is visible to the user — not as a blocking gate. Skip only when ALL verdicts are ✅.

9. ⛔ MANDATORY: 30d drill-down lookback — ALL Phase 4 drill-down queries use 30d (AH) or 90d (Data Lake) lookback, regardless of the Threat Pulse scan window. Entity-scoped queries (filtered by UPN/IP/device) have negligible performance difference between 7d and 30d, and attacks routinely predate the pulse window. AH caps at 30d anyway. Substitute ago(7d) → ago(30d) in all query file and skill queries during drill-downs.

10. ⛔ MANDATORY: The follow-up loop is stateful, memory-backed, and self-sustaining. Three non-negotiable invariants that hold for the ENTIRE session (re-read this rule before any follow-up interaction):

• (a) Memory is the source of truth, not the conversation. The prompt pool lives ONLY in /memories/session/threat-pulse-drilldowns.md. It MUST be created the first time the pool is built (Phase 4 step 1) and is a hard precondition for rendering any selection list. If you are about to present follow-up options and this file does not exist, STOP and create it first. NEVER reconstruct the pool from conversation history — always memory view immediately before each vscode_askQuestions call.
• (b) The loop re-presents itself automatically. After EVERY completed drill-down, you MUST return to Phase 4 step 2 and call vscode_askQuestions again with the updated pool — without waiting for the user to ask for the menu. The only exits are the user selecting Skip, or an empty pool. "Bring the menu back up" should never be something the user has to request.
• (c) The Quick Pick Call Contract is mechanical, not advisory. Run the Pre-Flight Checklist and print the Pool Receipt line before every call. In particular: ZERO recommended keys, multiSelect: true, correct icon taxonomy (🔍 📄 🎯 💾 🆕 🔄 📋), and the 💾 / 🔄 / Skip tail every iteration. Do not substitute an ad-hoc "Done" option for the contracted tail.

Execution Workflow

Phase 0: Prerequisites

1. Read config.json for workspace ID and Azure MCP parameters

2. Call list_sentinel_workspaces() to enumerate available workspaces

3. Use defaults (inline chat, 7d) unless user specified otherwise

4. ⛔ MANDATORY: Display scan summary — Before executing any queries, output the following brief to the user as plain markdown text (NOT inside a fenced code block, NOT as inline code). Use the exact heading, line breaks, and emoji-prefixed bullet items shown below. Substitute <WorkspaceName>, <WorkspaceId>, lookback, and output format. Never skip this step — it sets analyst expectations for what's about to run.

   🔍 Threat Pulse — Scan Plan

   Workspace: <WorkspaceName> (<WorkspaceId>) Lookback: <N>d Output: <Inline / Markdown file / Both>

   Executing 12 queries across 7 domains:

   🔴 Incidents — Open incidents (severity-ranked) + 7d closed summary (Q1, Q2) 🔐 Identity — Identity risk posture, risk event enrichment, auth spray (Q3, Q4) 🤖 NonHuman ID — Service principal behavioral drift (Q5) 💻 Endpoint — Device process drift, rare process chains (Q6, Q7) 📧 Email — Inbound threat snapshot (Q8) 🔑 Admin & Cloud — Cloud app ops, privileged operations (Q9, Q10) 🛡️ Exposure — Critical assets, exploitable CVEs (Q11, Q12)

   Data Lake: 1 query | Advanced Hunting: 11 queries in parallel Estimated time: ~2–4 minutes

Phase 1: Data Lake Query (Q5)

Why only 1 query on Data Lake? Q5 requires a 97-day lookback for SPN baseline computation — AH Graph API caps at 30 days. All other queries use ≤30d lookback on Analytics-tier tables accessible via AH.

Phase 2: Advanced Hunting Queries (Q1, Q2, Q3, Q4, Q6, Q7, Q8, Q9, Q10, Q11, Q12)

Run all 11 in parallel — no dependencies between queries.

Design rationale: The connected LA workspace makes all Sentinel tables (SecurityIncident, IdentityInfo, AADUserRiskEvents, AuditLogs, etc.) queryable via AH. AH is preferred: it's free for Analytics-tier tables and avoids per-query Data Lake billing.

Phase 3: Post-Processing & Report

1. Interpret device drift scores from Q6 results (see Post-Processing)
2. Run cross-query correlation checks (see rule 6 above)
3. Assign verdicts to each domain (🔴 Escalate / 🟠 Investigate / 🟡 Monitor / ✅ Clear)
4. Generate prioritized recommendations with drill-down skill references
5. Render the report immediately — output the Dashboard Summary, Detailed Findings, Cross-Query Correlations, and 🎯 Recommended Actions. Do NOT block on the manifest or prompt pool building.
6. After the report is rendered, run the Query File Recommendations procedure and append the 📂 Recommended Query Files section. This happens while the user is already reading the report — no perceived delay. Skip entirely when all verdicts are ✅.

Performance note: The Recommendation Gate was previously a blocking step (Phase 3.5) that loaded the ~500-line manifest YAML and ranked entries before the report could render. By moving it after the report output, the user sees findings immediately while recommendations load in the background. The Phase 4 prompt pool building also benefits — it reuses the recommendations already computed in step 6 rather than re-scanning all 12 query results independently.

Phase 4: Interactive Follow-Up Loop

After rendering the report, present the user with a selectable list of follow-up actions — skill investigations, query file hunts, and IOC lookups. Runs when at least one 🔴, 🟠, or 🟡 verdict exists (skip only when ALL verdicts are ✅).

This is a loop, not a one-shot. After each action completes, re-present the selection list with the prompt pool updated. Tier depth (🔴/🟠 vs 🟡-only vs all ✅) follows Rule 8.

⛔ Loop invariant — verify before EVERY iteration (per Rule 10): (a) /memories/session/threat-pulse-drilldowns.md exists and was just re-read via memory view — if not, create/read it first; (b) you are re-presenting the menu automatically after the prior drill-down, not because the user asked; (c) the Pre-Flight Checklist passed and the Pool Receipt was printed. If any of the three is false, fix it before calling vscode_askQuestions. The loop only ends on Skip or an empty pool.

Prompt types (three categories, one unified list):

Skill matching rules — derive from findings:

Drill-down lookback — Per Rule 9, substitute ago(7d) → ago(30d) (AH) or ago(90d) (Data Lake) in all drill-down queries.

Procedure:

1. Build the initial prompt pool by combining:

   • Skill prompts: one per unique entity + matching skill from the table above. If the same entity appears in multiple queries (e.g., Q3 and Q9), create ONE skill prompt for that entity — the correlation context goes in the Description, not in the Label.
   • Query file prompts: from Phase 3 step 5 keyword extraction. Each query file is its OWN separate prompt — never merge a query file prompt with a skill prompt.
   • IOC prompts: any suspicious IPs/domains from non-✅ findings not already covered by a skill prompt
   • Deduplicate: if a skill prompt and IOC prompt target the same entity, keep only the skill prompt
   • 🔴 NEVER merge a skill prompt (🔍) with a query file prompt (📄) into a single option. They are different action types with different execution paths.
   • ⛔ Persist the pool. Write the final pool to /memories/session/threat-pulse-drilldowns.md using the exact template below. The format banner is mandatory — it makes the — delimiter contract visible to every iteration and every LLM that edits the file. This memory block is the single source of truth; conversation history is not.

   Memory File Template (write on first pool creation)

   # Threat Pulse Session — <YYYY-MM-DD>
   
   **Workspace:** <name> (<id>)
   **Lookback:** <7d|30d|90d>
   **Scan Start:** <YYYY-MM-DD HH:MM UTC>
   
   ## Active Prompt Pool
   
   <!-- FORMAT: `- <ICON> <action> <entity> — Q<N>: <finding> → <skill-or-query-file>` -->
   <!-- ` — ` (space-emdash-space) is the REQUIRED label/description split delimiter. -->
   <!-- One icon per line. Order = file position (no numbering). Do not edit this comment block. -->
   
   - 🔍 Investigate incident #<IncidentId> — Q1: <brief finding>, <N> alerts, <MITRE-ID> → incident-investigation
   - 🎯 Enrich and investigate IP <IP> — Q4: <N> spray attempts / <N> users → ioc-investigation
   ...
   
   ## Pulse Key Findings (quick reference)
   
   ...
   
   ## Completed Drill-Downs
   
   _(none yet)_

2. Call vscode_askQuestions using the Quick Pick Call Contract below. Apply identically on every iteration.

   Quick Pick Call Contract

   • header: Follow-Up Investigation
   • question: Select one or more actions to launch (or skip):
   • options: entity prompts (from memory), then 📋 (if truncated), then 💾 / 🔄 / Skip as the final three — in that order, every iteration. 🆕 prompts prepend to the entity portion only.
     1. 💾 Save full investigation report — Save the complete Threat Pulse session (scan + all drill-downs) as a markdown file
     2. 🔄 Refresh prompt pool — Rebuild the follow-up prompt list from existing pulse + drill-down findings (does NOT re-run the 12 pulse queries)
     3. Skip — No follow-up — investigation complete
   • Allowed Label icons: 🔍 📄 🎯 💾 🆕 🔄 📋. Verdict emoji (🔴🟠🟡🟢✅) are banned from Labels (render as �� in VS Code quick picks) but fine in Descriptions. Drop 💾 after report is saved; 🔄 and Skip always remain.

   🔴 Pre-Flight Checklist — run mechanically before EVERY vscode_askQuestions call

   □ 1. memory view → read `## Active Prompt Pool` just now (not earlier)
   □ 2. Count entity prompts (exclude 💾/🔄/📋/Skip) = N
   □ 3. Format integrity: every entity line starts with `- ` followed by exactly ONE icon. Any legacy `<N>.` prefix → migrate to `- ` first, re-read, then continue.
   □ 4. If N > 12: render top 12 (🆕 first, then memory order) + append `📋 Show full prompt pool (N items)`
   □ 5. For each rendered option: split memory line at FIRST ` — ` → label = text after `- ` up to delimiter, description = right, BYTE-FOR-BYTE (no paraphrasing; if something is missing, edit memory first then re-read)
   □ 6. Atomic check: each option Label has exactly ONE icon; Description has at most ONE `→ target`
   □ 7. `multiSelect: true` in call args
   □ 8. ZERO `recommended` keys anywhere in options[]
   □ 9. Tail = 💾 / 🔄 / Skip (or 📋 / 💾 / 🔄 / Skip if truncated)
   □ 10. Print the Pool Receipt line to chat BEFORE invoking the tool

   Pool Receipt (box 10) — one-liner printed to chat so contract violations are user-visible:

   📊 Pool: <N> total / rendering <R> (🆕×<a>, 🔍×<b>, 📄×<c>, 🎯×<d>) / truncated <✔|—> | multiSelect=true ✔ | recommended=0 ✔

   If user selects 📋: re-invoke with all entity prompts (drop 📋, keep 💾/🔄/Skip tail).

3. If user selects Skip (alone) or pool is empty: end skill execution. Ignore any freeform text if Skip is selected.

4. Freeform input routing — If user types freeform text instead of (or alongside) selecting options, route by matching intent to validated sources. Do NOT write ad-hoc KQL — find the right skill or query file first. Classified actions feed into step 7 alongside any selected options.

   1. Skill match — Check the request against copilot-instructions.md Available Skills trigger keywords. "Check vulnerabilities on that device" → exposure-investigation or computer-investigation. Route as 🔍 — the read_file gate in step 7 applies.
   2. Query file match — grep_search the request's key terms (table names, operations, attack types) against queries/**. "Check forwarding rules" → queries/email/email_threat_detection.md. Route as 📄.
   3. Contextual question — If answerable from data already in context (e.g., "is that IP in other alerts?"), answer directly. If a query is needed, loop back to sub-steps 1–2 to find the right source.
   4. No match — If no skill or query file covers the request, follow the KQL Pre-Flight Checklist from copilot-instructions.md (schema validation, table pitfalls, existing query search) before writing any KQL. Never skip the pre-flight for freeform requests.

5. 💾 Save full investigation report selected:

   • Read /memories/session/threat-pulse-drilldowns.md (critical after context compaction) and compile pulse dashboard + all drill-down findings into a single markdown file using the Report Template (file mode). Weave drill-down insights into the main report — do NOT just append raw output.
   • If no drill-downs were executed yet, omit the Drill-Down Investigation Results and Cross-Investigation Correlation sections with note: "No drill-down investigations were performed in this session."
   • Save to reports/threat-pulse/Threat_Pulse_YYYYMMDD_HHMMSS.md. Drop 💾 from subsequent pool iterations.

6. 🔄 Refresh prompt pool selected — prompt list ONLY, no KQL execution. Refresh rebuilds the follow-up list; it does NOT re-run Q1–Q12 and does NOT re-run drill-downs. Discard the current pool, rebuild by re-applying Query File Recommendations and the skill matching table against pulse findings + all drill-down findings in memory. Deduplicate against completed prompts. If selected alongside other actions, refresh FIRST, then present the new pool before executing the others.

7. One or more actions selected — execute sequentially. Build a todo list (one item per action). For each:

   • 🔍 Skill prompt: ⛔ read_file the child SKILL.md BEFORE writing ANY query → find Investigation shortcut → match TP Q# trigger → execute with entity substitution. Writing KQL without the prior read_file = schema hallucination. See 🔍 Skill Drill-Down Execution Rule.
   • 📄 Query file prompt: read the file and execute its queries verbatim with entity substitution. See 📄 Query File Execution Rule.
   • 🎯 IOC prompt: load ioc-investigation skill with the target indicator.

   After each drill-down, append a session-state entry to /memories/session/threat-pulse-drilldowns.md under ## Completed Drill-Downs:

   ### <N>. <Prompt Label> (<skill-name>, <YYYY-MM-DD HH:MM>)
   - **Entity:** <target entity>
   - **Trigger:** Q<N> — <original finding>
   - **Key Findings:** <1–8 bullets, evidence-cited>
   - **Risk Assessment:** <emoji> <level> — <1-line justification>
   - **Cross-References:** <overlaps with other drill-downs or pulse queries>
   - **Recommendations:** <top 1–3 actions>

   This survives context compaction and feeds the 💾 Save report.

   Before returning to step 2 — MANDATORY, in order:

   1. New Evidence Scan — review drill-down results for entities/TTPs not present in prior findings. Add 🆕 prompts only for meaningful leads (new attacker IP with high abuse, new critical CVE on exposed device, etc.). If nothing warrants follow-up, note: "No actionable new evidence."
   2. Manifest check — for each 🆕 item, consult .github/manifests/discovery-manifest.yaml (match by domains, mitre, or title). Only fall back to ad-hoc KQL if nothing matches.
   3. Reload → mutate → write back — memory view ## Active Prompt Pool → delete the completed bullet line(s) → prepend 🆕 prompts as new bullet lines (- <ICON> ...) → memory str_replace. Every entity line is a bullet — no ordinals, so adding/removing items never requires renumbering. Never reconstruct the pool from conversation history.
   4. Return to step 2. Never render the pool as a markdown table/list instead of calling vscode_askQuestions.

Atomic options — ONE action per option. Each option maps to ONE skill + ONE entity, OR ONE query file. When correlations link findings (e.g., Q3+Q9 same user), generate separate options, put the correlation in the Description. Bundling multiple actions/arrows in a single option is the #1 follow-up mistake.

✅ Correct: 🔍 Investigate user cameron@contoso.com / desc Q3+Q9: identity risk + inbox rule manipulation → user-investigation ❌ Wrong: 🔍 Investigate cameron ... → user-investigation, 📄 Hunt phishing → queries/email/...

📄 Query File Execution Rule

⛔ MANDATORY — applies to ALL 📄 query file prompt executions in Phase 4.

When executing a 📄 prompt, use the queries from the file verbatim with entity substitution. Do NOT rewrite queries against different tables than the file specifies.

1. Read the query file and check its Investigation shortcuts section at the top — match the (TP Q#) annotation to the triggering Threat Pulse query to identify the recommended query chain. Follow that chain for the hunt
2. Substitute entity values (hostnames, IPs, UPNs) and adjust ago(Nd) lookback if context-aware expansion applies
3. ⚠️ Hostname-safe substitution: Device names vary across tables (short hostname vs FQDN vs uppercase). NEVER use == for device/computer filters — use startswith (default, case-insensitive, matches both short name and FQDN), or in~ (multi-device). Override == in query file entity substitution notes with startswith.
4. Execute using the file's exact tables, columns, and filters
5. If supplementing with additional tables, execute the file's queries first, then add your own — clearly label which are from the file vs. supplementary

🔍 Skill Drill-Down Execution Rule

⛔ MANDATORY — applies to ALL 🔍 skill drill-down executions in Phase 4.

When executing a skill drill-down, load the child skill's SKILL.md and use its validated queries. Do NOT write ad-hoc queries from memory — schema hallucination (wrong column names, wrong table) is the #1 drill-down failure mode.

1. Load the child skill's SKILL.md
2. Match the trigger context (TP Q number) against the skill's Investigation shortcuts section to identify the relevant query chain
3. Execute the shortcut query chain — substitute only entity placeholders and date ranges. Do NOT add columns, change project/summarize by, or restructure. Column names vary across Device* tables; the SKILL.md queries already use the correct ones.
4. For quick triage: run only the shortcut chain. For deep investigation: run the full skill workflow

🎬 Take Action — Portal-Ready Remediation Blocks

⚠️ AI-generated content may be incorrect. Always review Take Action queries and portal links for accuracy before executing remediation actions.

After every non-✅ drill-down that surfaces actionable entities, append a 🎬 Take Action section with direct portal links (single entities) or Advanced Hunting queries (bulk entities). Ref: Take action on AH results

Every 🎬 Take Action heading in the output — this one and every subsequent one — MUST be immediately followed by the AI-content warning blockquote above.

Skip when: verdict is ✅/🔵, or the action was already taken (e.g., ZAP purged emails).

Single Entity vs Bulk Entity Decision Rule

The remediation format depends on how many entities need action.

⛔ PROHIBITED: Generating an AH query for a single entity when a direct portal link would suffice. AH Take Action is for bulk remediation — for a single entity, link directly to the portal page where the analyst can act.

ID sources (agent retrieves silently — never ask the user):

• User OID: Graph /v1.0/users/<UPN>?$select=id or IdentityInfo.AccountObjectId
• MDE DeviceId: DeviceInfo.DeviceId or GetDefenderMachine API
• SHA / NetworkMessageId / etc.: from the originating AH table

⛔ Never emit prompts like "Retrieve the DeviceId" — run the lookup and emit the finished link in the same turn.

Required Columns per Entity Type

Missing a required column silently disables the action menu. Always include these:

Template Queries

📧 Email — by NetworkMessageId: (no project — see Email row above)

EmailEvents
| where Timestamp > ago(7d)
| where NetworkMessageId in ("<id1>", "<id2>")

→ Take actions → Move to mailbox folder, Delete email (soft/hard), Submit to Microsoft, Initiate automated investigation

📧 Email — by compromised sender domain:

EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain =~ "<domain>" and ThreatTypes has "Phish" and DeliveryAction == "Delivered"
| take 500

→ Take actions → Move to mailbox folder, Delete email (soft/hard), Submit to Microsoft, Initiate automated investigation

💻 Single Device — direct portal link: Link to the Defender XDR machine page. If DeviceId isn't in context, look it up yourself:

DeviceInfo | where DeviceName startswith '<name>' | summarize arg_max(Timestamp, *) by DeviceId | project DeviceId

Then emit: [<DeviceName>](https://security.microsoft.com/machines/v2/<DeviceId>?tid=<tenant_id>). Never fabricate URLs with ?DeviceName=, /machines?, or bare hostnames.

→ Machine page → Response actions → Isolate device, Collect investigation package, Run antivirus scan, Initiate investigation, Restrict app execution

💻 Bulk Devices (2+) — AH query:

DeviceInfo
| where Timestamp > ago(1d)
| where DeviceName in~ ("<device1>", "<device2>")
| summarize arg_max(Timestamp, *) by DeviceId
| project DeviceId, DeviceName, OSPlatform, MachineGroup

→ Take actions → Isolate device, Collect investigation package, Run antivirus scan, Initiate investigation, Restrict app execution

📁 File — by hash:

Source-aware table selection. SHA hashes appear across many tables (DeviceProcessEvents, DeviceImageLoadEvents, DeviceFileEvents, AlertEvidence). Use DeviceFileEvents as the default — it captures file writes and has the columns needed for Quarantine. If the hash was only observed via process execution (no separate file write event), substitute or union with DeviceProcessEvents. The Quarantine action requires DeviceId + SHA1/SHA256 regardless of source table.

File write events (default — DeviceFileEvents):

DeviceFileEvents
| where Timestamp > ago(7d)
| where SHA1 == "<hash>" or SHA256 == "<hash>"
| project DeviceId, DeviceName, SHA1, SHA256, FileName, FolderPath

Process execution events (when file write not captured — DeviceProcessEvents):

DeviceProcessEvents
| where Timestamp > ago(7d)
| where SHA1 == "<hash>" or SHA256 == "<hash>"
| project DeviceId, DeviceName, SHA1, SHA256, FileName, FolderPath, ProcessCommandLine

→ Take actions → Quarantine file

🔗 Bulk Indicators (2+ IPs/domains/hashes) — AH query for Add Indicator:

When blocking multiple IPs, domains, or hashes, provide an AH query that surfaces the values as clickable columns. There is no Take actions dropdown — the analyst clicks each value directly in results → Add indicator.

Source-aware table selection. The table MUST match where the IPs were originally discovered. DeviceNetworkEvents is the default for network-layer IPs (endpoint connections, firewall events). However, IPs from authentication-layer sources (AADUserRiskEvents, EntraIdSignInEvents, SigninLogs, AADServicePrincipalSignInLogs) may never appear in endpoint network events — querying DeviceNetworkEvents for those returns 0 results. Use the originating table so the analyst sees the IPs in context and can click to add indicators.

Network-layer IPs (from DeviceNetworkEvents, DeviceLogonEvents, firewall logs):

// Surface attacker IPs as clickable values for Add Indicator
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIP in ("<ip1>", "<ip2>", "<ip3>")
| summarize Connections = count(), Ports = make_set(LocalPort) by RemoteIP
| order by Connections desc

Auth-layer IPs (from AADUserRiskEvents, EntraIdSignInEvents, SigninLogs):

// Surface attacker IPs from sign-in/risk events for Add Indicator
EntraIdSignInEvents
| where Timestamp > ago(30d)
| where IPAddress in ("<ip1>", "<ip2>", "<ip3>")
| summarize SignIns = count(), Users = dcount(AccountUpn), Countries = make_set(Country, 5) by IPAddress
| order by SignIns desc

→ Click any IP value in results → Add indicator → Block and remediate

Variant — domains/URLs:

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any ("<domain1>", "<domain2>")
| summarize Connections = count() by RemoteUrl
| order by Connections desc

→ Click any RemoteUrl value → Add indicator → Block and remediate

Defender XDR Portal Links — All Entity Types

🔴 Every entity (user, domain, URL, IP, file hash) in action/recommendation tables MUST be a clickable Defender XDR portal link — the entity name IS the link. Do NOT add a separate "Portal" column or leave entities as plain text. VS Code renders bare UPNs as mailto: and bare URLs/IPs as broken links.

User fallbacks: ?upn=<UPN> when ObjectId is unavailable; ?sid=<SID>&accountName=<Name>&accountDomain=<Domain> for on-prem AD.

Device ID source: DeviceId from the DeviceInfo AH table or the id field from GetDefenderMachine API. This is the MDE machine identifier — NOT the Entra Device Object ID (which is different). The computer-investigation skill retrieves this in Step 1b.

🔴 Portal URL Allowlist — No Invented Paths. The 7 patterns above plus /v2/advanced-hunting?tid=<tenant_id> are the ONLY security.microsoft.com URLs you may emit. For any other action (Custom Indicators, Safe Links policy, Email Explorer, CA policy editor, Secure Score, etc.), write a textual breadcrumb — e.g., "Defender XDR → Settings → Endpoints → Indicators → URLs/Domains → Add item". Never guess a path from memory.

Entity Display — Portal Link vs Defang (Mutually Exclusive)

Defang rules: http:// → hxxp://, https:// → hxxps://, . in domain → [.]. VS Code auto-linkifies anything URL-shaped, which is why defanging is required in data tables. Conversely, a portal-linked entity has the portal URL as the link target, so linkification is safe \u2014 defanging would just break the link.

Rules Summary

Sample KQL Queries

All queries below are verified against live Sentinel/Defender XDR schemas. Use them exactly as written. Lookback periods use ago(Nd) — substitute the user's preferred lookback where noted.

Query 1: Open Incidents with Severity-Ranked Backfill & MITRE Techniques

🔴 Incident hygiene — Surfaces unresolved incidents prioritized by severity (Critical → High → Medium → Low), with age, owner, alert count, MITRE tactics, MITRE technique IDs, and extracted entity names (accounts + devices) for cross-query correlation. In large environments, all 10 slots fill with High/Critical. In smaller environments, Medium/Low backfill remaining slots automatically.

Tool: RunAdvancedHuntingQuery

let OpenIncidents = SecurityIncident
| where TimeGenerated > ago(30d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where Status in ("New", "Active");
let TotalHighCritical = toscalar(OpenIncidents | where Severity in ("High", "Critical") | count);
let TotalAll = toscalar(OpenIncidents | count);
OpenIncidents
| extend SevRank = case(Severity == "Critical", 0, Severity == "High", 1, Severity == "Medium", 2, Severity == "Low", 3, 4)
| extend ParsedLabels = parse_json(Labels)
| mv-apply Label = ParsedLabels on (
    summarize Tags = make_set(tostring(Label.labelName), 5)
)
| extend Tags = set_difference(Tags, dynamic([""]))
| mv-expand AlertId = AlertIds | extend AlertId = tostring(AlertId)
| join kind=leftouter (
    SecurityAlert
    | where TimeGenerated > ago(30d)
    | summarize arg_max(TimeGenerated, Entities, Tactics, Techniques, AlertName, AlertSeverity) by SystemAlertId
    | extend ParsedEntities = parse_json(Entities)
    | mv-expand Entity = ParsedEntities
    | extend EntityType = tostring(Entity.Type),
        AccountUPN = case(
            tostring(Entity.Type) == "account" and isnotempty(tostring(Entity.UPNSuffix)),
            tolower(strcat(tostring(Entity.Name), "@", tostring(Entity.UPNSuffix))),
            tostring(Entity.Type) == "account" and isnotempty(tostring(Entity.AadUserId)),
            tostring(Entity.AadUserId),
            ""),
        HostName = iff(tostring(Entity.Type) == "host", tolower(tostring(Entity.HostName)), "")
    | project SystemAlertId, Tactics, Techniques, AlertName, AlertSeverity, AccountUPN, HostName
) on $left.AlertId == $right.SystemAlertId
| mv-expand Technique = parse_json(Techniques)
| extend Technique = tostring(Technique)
| extend TacticsSplit = split(Tactics, ", ")
| mv-expand Tactic = TacticsSplit
| extend Tactic = tostring(Tactic)
| summarize 
    Tactics = make_set(Tactic),
    Techniques = make_set(Technique),
    AlertNames = make_set(AlertName, 5),
    AlertCount = dcount(AlertId),
    Accounts = make_set(AccountUPN, 5),
    Devices = make_set(HostName, 5),
    Tags = take_any(Tags)
    by ProviderIncidentId, Title, Severity, SevRank, Status, CreatedTime,
       OwnerUPN = tostring(Owner.userPrincipalName)
| extend Techniques = set_difference(Techniques, dynamic([""]))
| extend Tactics = set_difference(Tactics, dynamic([""]))
| extend Accounts = set_difference(Accounts, dynamic([""]))
| extend Devices = set_difference(Devices, dynamic([""]))
| extend AgeDisplay = case(
    datetime_diff('minute', now(), CreatedTime) < 60, strcat(datetime_diff('minute', now(), CreatedTime), "m ago"),
    datetime_diff('hour', now(), CreatedTime) < 24, strcat(datetime_diff('hour', now(), CreatedTime), "h ago"),
    strcat(datetime_diff('day', now(), CreatedTime), "d ago"))
| extend PortalUrl = strcat("https://security.microsoft.com/incidents/", ProviderIncidentId, "?tid=<TENANT_ID>")
| extend TotalHighCritical = TotalHighCritical, TotalAll = TotalAll
| project TotalHighCritical, TotalAll, ProviderIncidentId, Title, Severity, SevRank, AgeDisplay, AlertCount, 
    OwnerUPN, Tactics, Techniques, Accounts, Devices, Tags, PortalUrl, AlertNames, CreatedTime
// --- Deduplicate by Title: keep one representative incident per title for variety ---
| as AllOpenIncidents
| join kind=leftouter (
    AllOpenIncidents | summarize TitleDupCount = count() by Title
) on Title
| project-away Title1
| order by Title asc, SevRank asc, bin(CreatedTime, 1d) desc, AlertCount desc
| extend _rn = row_number(1, prev(Title) != Title)
| where _rn == 1
| project-away _rn
| order by SevRank asc, bin(CreatedTime, 1d) desc, AlertCount desc
| take 10

Purpose: Top 10 open incidents with severity-ranked backfill (Critical→High→Medium→Low). In large envs, all slots fill with High/Critical; small envs backfill with Medium/Low. TotalHighCritical and TotalAll drive the adaptive report header ("Showing 10 of {TotalAll} open incidents ({TotalHighCritical} High/Critical)") and are computed across all open incidents pre-dedup, so header counts stay accurate. The list is deduplicated by Title so the top 10 shows distinct incident types rather than near-identical rows — in noisy envs a single recurring title (password-spray, DLP rule) can otherwise monopolize all 10 slots; the single highest-priority representative per title is kept (severity → newest day → alert count) and TitleDupCount preserves the volume signal. Joins SecurityAlert for MITRE tactics/techniques and extracts Accounts (UPN or AAD ObjectId, lowercased), Devices (hostname, lowercased), and Tags (from Labels — both AutoAssigned ML classifications and User-applied SOC tags) — each capped at 5 per incident — for cross-query correlation with Q3/Q4/Q6/Q7/Q12. Flags unassigned incidents (empty OwnerUPN).

Sort: SevRank asc, bin(CreatedTime, 1d) desc, AlertCount desc — severity tier first, then calendar day (newest first), then complexity within each day.

Verdict logic:

• 🔴 Escalate: 5+ new High/Critical in 24h, OR any incident with AlertCount > 50, OR any unassigned High/Critical with CredentialAccess/LateralMovement tactics
• 🟠 Investigate: Any unassigned High/Critical, OR AlertCount > 10, OR multiple High/Critical in <6h
• 🟡 Monitor: Only Medium/Low incidents exist (no High/Critical), OR High/Critical assigned with low alert count
• ✅ Clear: 0 open incidents of any severity (Q2 closed summary still renders as context)