Use this skill when asked to investigate a security incident by ID from Microsoft Defender XDR or Microsoft Sentinel. Triggers on keywords like "investigate incident", "incident ID", "incident investigation", "analyze incident", "triage incident", or when an incident number/ID is mentioned with investigation context. This skill provides comprehensive incident analysis including metadata retrieval, alert listing, asset enumeration, evidence filtering, and deep entity investigation using Sentinel MCP tools and specialized skills.
Use this skill when asked to investigate a security incident by ID from Microsoft Defender XDR or Microsoft Sentinel. Triggers on keywords like "investigate incident", "incident ID", "incident investigation", "analyze incident", "triage incident", or when an incident number/ID is mentioned with investigation context. This skill provides comprehensive incident analysis including metadata retrieval, alert listing, asset enumeration, evidence filtering, and deep entity investigation using Sentinel MCP tools and specialized skills.
This skill performs comprehensive security investigations on incidents from Microsoft Defender XDR and Microsoft Sentinel. It retrieves incident details, lists alerts, enumerates assets and evidences, and then performs deep investigation on user-selected entities using appropriate tools and specialized skills.
ALWAYS track and report time after each major step
ALWAYS filter evidences - Remove internal IPs (RFC1918) and tenant domains from investigation scope. Also remove all public IPs from the devices listed as assets involved in the incident.
ALWAYS defang malicious/suspicious URLs and IPs - NEVER return them as clickable links. Use defang format: hxxps://evil[.]com, 203[.]0[.]113[.]42
⛔ NEVER auto-select a Sentinel workspace when multiple exist - Workspace selection is MANDATORY:
❌ DO NOT select a workspace on behalf of the user when multiple exist
❌ DO NOT switch to another workspace if a query fails
❌ DO NOT proceed with investigation without explicit user selection
✅ If query fails: STOP, report error, ask user to select different workspace
✅ If multiple workspaces: STOP, list all, WAIT for user selection
✅ Only auto-select if exactly ONE workspace exists
Incident ID Patterns:
Pattern
Source
Tool to Use
Numeric (e.g., 12345, 98765)
Defender XDR / Sentinel
GetIncidentById
GUID format
Sentinel (internal)
Sentinel query_lake MCP tool
INxx-xxxxx format
Defender XDR
GetIncidentById
⚠️ Sentinel → Defender XDR ID Mapping (Critical):
When an incident is discovered via Sentinel KQL (e.g., SecurityIncident or SecurityAlert tables), its IDs are Sentinel-local and will NOT work with the Triage MCP:
Sentinel Field
Triage MCP Accepts?
Correct Field to Use
SecurityIncident.IncidentNumber
❌ Returns "not found"
Use SecurityIncident.ProviderIncidentId
SecurityAlert.SystemAlertId
❌ Returns "not found"
Extract parse_json(ExtendedProperties).IncidentId
SecurityIncident.ProviderIncidentId
✅
Pass directly to GetIncidentById
Rule: When querying SecurityIncident for later Triage MCP drill-down, always project ProviderIncidentId alongside IncidentNumber. Use ProviderIncidentId for all GetIncidentById calls.
Date Range Rules:
Default analysis window: 7 days before current date to current date (Standard)
Investigation depth options:
Comprehensive: 30 days window (for thorough analysis)
Standard: 7 days window (default)
Quick: 1 day window (for rapid triage)
Format: ISO 8601 (e.g., 2026-01-17T00:00:00Z to 2026-01-24T00:00:00Z)
Phase 1: Incident Description
This phase retrieves and presents all incident information. Follow the exact structure below.
1.1 Incident Metadata
Retrieve and list the incident's metadata using GetIncidentById:
Field
Description
Title
Incident display name
Description
Detailed incident description
Status
Active, Resolved, Redirected
Severity
High, Medium, Low, Informational
Priority assessment
If available from incident data
Classification
TruePositive, FalsePositive, BenignPositive, etc.
Determination
Malware, Phishing, etc.
Created Date
When incident was created
First Activity Date
First malicious activity timestamp
Last Updated Date
Most recent modification
Assigned To
Analyst assigned to incident
MITRE Categories
Tactics and techniques involved
Tags
Labels applied to incident
1.2 Incident Alerts
🔴 Tool Selection for Alert Retrieval
Use GetIncidentById with includeAlertsData=true to retrieve incident-specific alerts. This returns only alerts correlated to the incident.
⛔ DO NOT use ListAlerts to retrieve alerts for a specific incident.ListAlerts has NO incidentId parameter — it can only filter by createdAfter, createdBefore, severity, status. Calling it returns all tenant alerts (up to page size 10,000), not incident-specific ones. Any unsupported parameter (e.g., incidentId) is silently ignored.
If GetIncidentById(includeAlertsData=true) returns a truncated or excessively large response (e.g., incident has hundreds of correlated alerts from noise sources like Purview IRM or DLP), use RunAdvancedHuntingQuery as the fallback:
// Get alerts linked to the incident's primary user/entity
AlertInfo
| where Timestamp > datetime(<incident_created_minus_7d>)
| join kind=inner (
AlertEvidence
| where Timestamp > datetime(<incident_created_minus_7d>)
| where EntityType == "User"
| where AccountUpn =~ "<primary_user_upn>" or AccountObjectId == "<user_object_id>"
| distinct AlertId
) on AlertId
| project Timestamp, AlertId, Title, Severity, Category, AttackTechniques, DetectionSource, ServiceSource
| order by Timestamp asc
This approach bypasses the Triage MCP's alert cap and gives full control over date range and entity filtering.
Alert Fields to Retrieve
For each alert, retrieve:
Alert name
Tags
Severity
Investigation state
Status
Impacted assets
Correlation reason
Detection source
First activity
Last activity
Presentation Rules:
Return as a table (exclude Alert ID column from display)
Order by last activity date descending
Add row numbers starting from 1
If more than 30 alerts exist, note this after the table and provide a Defender portal link
NEVER calculate and write the total number of alerts
1.3 Incident Assets
Retrieve and list ALL assets involved in the incident by type:
Device Assets:
Field
Description
Name
Device hostname
Domain
AD domain
Risk Level
Device risk assessment
Exposure Level
Vulnerability exposure
OS Platform
Operating system
User Assets:
Field
Description
Display Name
User's full name
UPN
User Principal Name
User Status
Account status
Domain
User's domain
Department
Organizational department
App Assets:
Field
Description
App Name
Application name
App Client ID
OAuth client ID
Risk
Application risk level
Publisher
App publisher
Cloud Resource Assets:
Field
Description
Resource Name
Cloud resource identifier
Status
Resource status
Cloud Environment
Azure, AWS, GCP, etc.
Type
Resource type
Count assets by type ONLY after retrieving complete lists.
1.4 Incident Evidences
Retrieve evidences classified as malicious or suspicious only:
Processes (Top 10):
Get ALL malicious/suspicious processes
Return only the 10 most probable signs of malicious activity (use judgment)
Files (Top 10):
Get ALL malicious/suspicious files
Return only the 10 most probable signs of malicious activity (use judgment)
IP Addresses (Top 10, Filtered):
Get ALL malicious/suspicious IPs
Filter out RFC1918 internal IPs: 10.x.x.x, 172.16-31.x.x, 192.168.x.x
Filter out public IPs associated to the devices listed as assets involved in the incident
Return only the first 10 from filtered list
DEFANG ALL IPs:** When presenting IPs and domains to the user, ALWAYS use defanged format: 203[.]0[.]113[.]42, evil[.]com. NEVER output clickable malicious indicators.
URLs and DNS Domains (Top 10, Filtered):
Get ALL malicious/suspicious URLs and DNS Domains
Filter out tenant domain URLs (DNS domains associated with the organization)
Return only the first 10 from filtered list
DEFANG ALL URLs AND DNS DOMAINS:** When presenting URLs to the user, ALWAYS use defanged format: hxxps://evil[.]com/path, hxxp://malware[.]net. NEVER output clickable malicious URLs.
AD Domains:
Return ALL malicious/suspicious AD domains (no limit)
For each evidence type: If more than 10 exist, note this after the table and provide Defender portal link.
Phase 2: Incident Investigation Menu
⛔ MANDATORY CHECKPOINT: Workspace Selection
This checkpoint MUST be completed before ANY entity investigation can proceed.
Step 2.1: List Sentinel Workspaces
ALWAYS execute this step first, regardless of any other considerations:
list_sentinel_workspaces (MCP tool)
Store the result. This determines the workflow for Step 2.3.
Step 2.2: Present Entity Summary
Show a summary of the incident entities and assets from Phase 1:
Users (with UPN and display name)
Devices (with hostname and risk level)
URLs (defanged)
IPs (defanged, filtered)
File hashes
Domains (defanged)
🔴 DEFANG ALL URLs AND DOMAINS: When presenting URLs and DNS Domains to the user, ALWAYS use defanged format: hxxps://evil[.]com/path, hxxp://malware[.]net, evil[.]com. NEVER output clickable malicious URLs.
🔴 DEFANG ALL IPs: When presenting IPs to the user, ALWAYS use defanged format: 203[.]0[.]113[.]42. NEVER output clickable malicious indicators.
Step 2.3: Workspace Selection Gate
IF workspace_count == 1:
- Auto-select the single workspace
- Display: "Using Sentinel workspace: [NAME] ([ID])"
- Set SESSION_WORKSPACE_SELECTED = true
ELSE IF workspace_count > 1 AND SESSION_WORKSPACE_SELECTED == false:
- Display all workspaces with Name and ID
- ASK USER: "Which Sentinel workspace should I run my searches in? Select one or more, or choose 'all'."
- WAIT for user response
- Set SESSION_WORKSPACE_SELECTED = true after selection
ELSE IF workspace_count > 1 AND SESSION_WORKSPACE_SELECTED == true:
- Display: "Continuing with previously selected workspace: [NAME] ([ID])"
- DO NOT ask again
⛔ DO NOT PROCEED PAST THIS POINT WITHOUT A WORKSPACE SELECTED
If SESSION_WORKSPACE_SELECTED == false after Step 2.3, STOP and ask the user to select a workspace.
Step 2.4: Ask User to Select Entities
Ask the user:
"Which assets and entities involved in the incident should be investigated in depth? Please select them by providing their numbers or names, or simply ask to analyze all of them. The more entities you select, the longer the analysis will take."
🔴 DO NOT OFFER OTHER OPTIONS: Only ask the user whether they want to investigate one or more of the incident entities and assets listed above in more depth.
Read the response.
If they do not want to proceed with the proposed investigations, ask them what they want to do.
If they want to proceed with one or more of the proposed investigations, continue with Step 2.5.
Step 2.5: Start Investigations
Pre-flight check: Confirm SESSION_WORKSPACE_SELECTED == true before proceeding.
Proceed in accordance with the instructions described below for Phase 2-A, Phase 2-B, and Phase 2-C.
When multiple investigation types are selected (users, devices, IoCs) run them in parallel as much as possible.
Phase 2-A: User Investigation
Pre-requisites (MANDATORY)
⛔ VERIFY BEFORE PROCEEDING:
✅ SESSION_WORKSPACE_SELECTED == true (workspace explicitly selected by user)
✅ SELECTED_WORKSPACE_IDS array is populated with user's selection
✅ User has explicitly selected which user(s) to investigate
If any pre-requisite is FALSE: STOP and return to Phase 2.3 Workspace Selection Gate.
User Investigation Workflow
⚡ PARALLEL EXECUTION: When multiple users are selected, execute user investigations in parallel as much as possible.
📦 WORKSPACE CONTEXT: Pass the selected workspace(s) to all child skill invocations:
Use SELECTED_WORKSPACE_IDS from Phase 2.3 for all Sentinel queries
If a query fails with table/workspace error: STOP, report error, ask user to select different workspace
⛔ DO NOT automatically retry with a different workspace
For EACH user selected by the user:
🔴 REFERENCE THE SKILL FILE: Read and follow the complete workflow defined in:
.github/skills/user-investigation/SKILL.md
Key Steps (summary - see skill file for full details):
Get User Object ID from Microsoft Graph
Calculate date ranges based on investigation type (Standard/Quick/Comprehensive)
Run parallel data collection:
Sign-in anomalies (Signinlogs_Anomalies_KQL_CL — note lowercase 'l' in "logs")
Sign-in statistics (apps, locations, IPs)
Audit log events
Office 365 activity
Security incidents involving user
Identity Protection risk detections
MFA and authentication methods
Device compliance status
IP enrichment for flagged addresses
Compile and present findings
Generate HTML report (if requested)
DO NOT copy the full workflow here - always read the skill file for the most current instructions.
Phase 2-B: Device Investigation
Device Investigation Workflow
⚡ PARALLEL EXECUTION: When multiple devices are selected, execute device data collection queries in parallel for ALL devices simultaneously. Run Defender alerts, compliance, logged-on users, vulnerabilities, network/process/file events queries concurrently.
For EACH device selected by the user:
🔴 REFERENCE THE SKILL FILE: Read and follow the complete workflow defined in:
.github/skills/computer-investigation/SKILL.md
Key Steps (summary - see skill file for full details):
Get Device IDs (Entra Device ID + Defender Device ID)
Determine device type (Entra Joined, Hybrid Joined, Entra Registered)
Run parallel data collection:
Defender alerts for device
Device compliance status
Logged-on users
Software vulnerabilities
Network connections
Process events
File events
Automated investigations
Compile and present findings
DO NOT copy the full workflow here - always read the skill file for the most current instructions.
Phase 2-C: IoC Investigation
IoC Investigation Workflow
⚡ PARALLEL EXECUTION: When multiple IoCs are selected, execute ALL IoC investigation queries in parallel. Run threat intel lookups, Sentinel queries, and organizational exposure queries concurrently for all IoCs.
For EACH IoC selected by the user:
🔴 REFERENCE THE SKILL FILE: Read and follow the complete workflow defined in:
DO NOT copy the full workflow here - always read the skill file for the most current instructions.
Phase 3: Post-Investigation Loop (MANDATORY)
⛔ CRITICAL: DO NOT END THE RESPONSE WITHOUT COMPLETING THIS PHASE
After completing ALL selected entity investigations in Phase 2, you MUST:
List remaining uninvestigated entities - Show all entities from Phase 1 that were NOT yet investigated
Ask the user to select additional entities - Prompt user to continue or conclude
Wait for user response - Do not assume the investigation is complete
Phase 3 Checklist (Execute After Every Phase 2 Completion)
☐ Step 3.1: Compile list of UNINVESTIGATED entities (exclude already-investigated items)
☐ Step 3.2: Present remaining entities to user with numbered list
☐ Step 3.3: Ask: "Would you like to investigate any of the remaining entities? Select by number/name, or say 'done' to conclude."
☐ Step 3.4: Wait for user response before concluding
Required Prompt Format
After presenting investigation findings, ALWAYS end with:
📋 Remaining Uninvestigated Entities:
#
Type
Entity
Notes
1
Device
[DEVICE_NAME]
[Risk level or relevant context]
2
File
[FILENAME]
[Hash or detection status]
3
URL
[DEFANGED_URL]
[Threat assessment]
...
...
...
...
Would you like to investigate any of these remaining entities? Select by number/name, type "all" to investigate everything, or say "done" to conclude the investigation.
Rules
DO NOT include entities that were already investigated in the list
DO NOT ask the user to select Sentinel workspaces again (use previously selected workspace)
DO NOT provide a final summary or recommendations until the user explicitly says "done" or declines further investigation
DO NOT assume the investigation is complete just because selected entities were analyzed
Loop Behavior
IF user selects additional entities:
→ Return to Phase 2 (2-A, 2-B, or 2-C based on entity type)
→ After completion, return to Phase 3 again
ELSE IF user says "done" or declines:
→ Proceed to Final Summary
→ Provide recommendations
→ Offer to generate consolidated report
Sentinel MCP Tools Reference
analyze_user_entity
Purpose: Starts asynchronous security analysis of a user entity.
Parameters:
Parameter
Type
Required
Description
userId
string
Yes
User's Azure AD Object ID (GUID)
startTime
string
Yes
ISO 8601 format start time
endTime
string
Yes
ISO 8601 format end time
workspaceId
string
No
Sentinel workspace GUID (optional if only one workspace)
Time Window Options: 30 days (Comprehensive), 7 days (Standard), 1 day (Quick)
Returns:202 Accepted with analysisId
get_entity_analysis
Purpose: Retrieves results of an asynchronous entity analysis.
Parameters:
Parameter
Type
Required
Description
analysisId
string
Yes
Analysis ID returned from analyze_*_entity
Returns:200 OK with analysis results when complete, or status if still processing
Quick Start (TL;DR)
When a user requests an incident investigation:
Phase 1 - Incident Description:
Retrieve incident metadata using GetIncidentById
List top 30 alerts as a table
Enumerate all assets by type (devices, users, apps, cloud resources)
List filtered evidences (processes, files, IPs, URLs, domains)
⛔ Phase 2 - Mandatory Workspace Selection:
Call list_sentinel_workspaces MCP tool FIRST
Present entity summary from Phase 1
If 1 workspace: auto-select and display
If multiple workspaces: ASK USER to select before proceeding
DO NOT proceed to investigations without a workspace selected
Phase 2-A - User Investigation:
For each selected user: Follow .github/skills/user-investigation/SKILL.md
Present findings
Phase 2-B - Device Investigation:
For each selected device: Follow .github/skills/computer-investigation/SKILL.md
Present findings
Phase 2-C - IoC Investigation:
For each selected IoC (IPs, URLs, Files, Domains, Hashes): Follow .github/skills/ioc-investigation/SKILL.md
Present findings
Export & Summary:
Create consolidated JSON file
Present investigation summary with recommendations
Verify incident ID format; try Sentinel query if Defender fails
User Object ID not found
Verify UPN is correct; check if user exists in Entra ID
analyze_user_entity returns error
Check userId is GUID format; verify time window ≤ 30 days
get_entity_analysis still processing
Poll again after 5-10 seconds; max 2 minutes
No workspace found
Use list_sentinel_workspaces MCP tool to get workspace ID
Device investigation fails
Verify device exists in Defender; check device ID type
IoC investigation timeout
Reduce date range; check IoC format
Workspace ID Retrieval
If workspace ID is unknown, retrieve it first:
list_sentinel_workspaces (MCP tool)
Returns: List of workspace name/ID pairs
Workspace ID Selection
If there is more than one Sentinel workspace (as retrieved from list_sentinel_workspaces MCP tool), present the list - in terms of workspace names and IDs - to the user so that the user can select which workspace to use for the investigation.
Offer also to the user the possibility to use all existing workspaces.
If only one workspace is selected by the user, use the workspaceId of that workspace when calling investigation tools.
If the user asks to consider more than one workspace, use one by one the workspaceId of all of them when calling investigation tools.
Time Window Limits
Tool
Time Window Options
User Investigation
30 days (Comprehensive), 7 days (Standard), 1 day (Quick)
Computer Investigation
30 days (Comprehensive), 7 days (Standard), 1 day (Quick)
IoC Investigation
30 days (Comprehensive), 7 days (Standard), 1 day (Quick)
Example Investigation Workflow
User Request: "Investigate incident 12345"
Phase 1: Incident Description
[00:00] Starting incident investigation for ID: 12345
### Incident Metadata
- **Title:** Multi-stage attack with credential theft
- **Severity:** High
- **Status:** Active
- **Classification:** TruePositive
- **Created:** 2026-01-20T10:30:00Z
- **MITRE Categories:** Initial Access, Credential Access, Lateral Movement
### Incident Alerts
| # | Alert Name | Severity | Status | Last Activity |
|---|------------|----------|--------|---------------|
| 1 | Suspicious sign-in from unusual location | High | New | 2026-01-23 |
| 2 | Credential theft attempt detected | High | InProgress | 2026-01-22 |
| ... | ... | ... | ... | ... |
### Incident Assets
**Devices:**
| Name | Domain | Risk Level | OS |
|------|--------|------------|-----|
| WORKSTATION-01 | contoso.com | High | Windows 11 |
| LAPTOP-EXEC | contoso.com | Medium | Windows 11 |
| SERVER-DC01 | contoso.com | Low | Windows Server 2022 |
**Users:**
| Display Name | UPN | Status | Department |
|--------------|-----|--------|------------|
| John Smith | jsmith@contoso.com | Active | Finance |
| Admin Account | admin@contoso.com | Active | IT |
| Jane Doe | jdoe@contoso.com | Active | HR |
| Service Account | svc-backup@contoso.com | Active | IT |
### Incident Evidences
**IPs (after filtering - excluded private IPs):**
- `203[.]0[.]113[.]42` (Malicious - C2 communication)
- `198[.]51[.]100[.]10` (Suspicious - Data exfiltration)
- `192[.]0[.]2[.]50` (Suspicious - Unusual connection)
...
**URLs (after filtering - excluded managed domains):**
- `hxxps://evil-site[.]com/payload[.]exe` (Malicious)
- `hxxps://phishing[.]example[.]com/login` (Suspicious)
...
[01:30] Phase 1 completed (90 seconds)
Phase 2-A: User Investigation
Which users from the incident assets should be investigated deeply?
Available users:
1. jsmith@contoso.com (Finance)
2. admin@contoso.com (IT)
3. jdoe@contoso.com (HR)
4. svc-backup@contoso.com (IT)
User selects: "1, 2"
[01:35] Starting parallel user analysis for 2 users...
- Getting user Object IDs from Graph API (parallel)
- Starting analyze_user_entity for jsmith@contoso.com (Analysis ID: abc123-def456)
- Starting analyze_user_entity for admin@contoso.com (Analysis ID: xyz789-ghi012)
- Polling for results (parallel)...
[02:15] All analyses complete
### User Analysis: jsmith@contoso.com
**Risk Level:** High
**Key Findings:**
1. Sign-in from unusual location (IP: `203[.]0[.]113[.]42`, Country: Russia)
2. Multiple failed MFA attempts followed by success
3. Unusual file access pattern detected
...
### User Analysis: admin@contoso.com
**Risk Level:** Medium
**Key Findings:**
1. Service account usage from new device
...
[02:20] Phase 2-A completed (45 seconds - parallel execution)
Phase 2-B: Device Investigation
Which devices from the incident assets should be investigated deeply?
Available devices:
1. WORKSTATION-01 (High risk)
2. LAPTOP-EXEC (Medium risk)
3. SERVER-DC01 (Low risk)
