Threat Hunt (TH) Program Part 6 - Threat Hunt Mission Organization in SIEM/XDR
- brencronin
- 1 day ago
- 11 min read
Threat Hunt Mission Organization in SIEM/XDR Standard Operating Procedure (SOP)
1. Purpose
This Standard Operating Procedure (SOP) defines the standards, steps, and required configurations for organizing and executing Threat Hunt missions within Security Information and Event Management (SIEM) and Extended Detection and Response (XDR) platforms. It establishes a consistent, repeatable methodology for structuring hunt workspaces, managing queries, capturing findings, and producing outputs that contribute to the organization's detection engineering and reporting pipeline.
This SOP is structured to accommodate multiple SIEM/XDR platforms. Platform-specific procedures are documented in dedicated sections. Organizations operating multiple platforms should apply the relevant section to each environment.
2. Scope
This SOP applies to all Threat Hunters and Threat Hunt Leads who conduct hunt missions within any SIEM or XDR platform operated by the SOC. It covers the complete lifecycle of hunt organization within the platform: from workspace and hunt container creation, through query execution, finding documentation, and output production.
This SOP does not cover Threat Hunt mission planning or Threat Hunt reporting. It covers only the platform-level organization activities that occur during mission execution.
3. Platform Coverage and Versioning
This SOP is organized by SIEM/XDR platform. Each platform receives a dedicated section with platform-specific procedures. The table below tracks the current coverage status of each platform:
Platform | Status | SOP Section | Last Updated |
Microsoft Sentinel / Defender XDR | ACTIVE — Documented | Section 5 | Updated |
Elastic Security | RESERVED — Future Expansion | Section 6 | Pending |
Splunk Enterprise Security | RESERVED — Future Expansion | Section 7 | Pending |
[Additional Platform] | RESERVED | Section 8+ | Pending |
4. Universal Hunt Organization Principles
The following principles apply regardless of SIEM/XDR platform. All Threat Hunters must apply these standards in every platform environment they operate within.
4.1 Hunt Workspace Discipline
Every Threat Hunt mission must be organized within a dedicated hunt container, workspace, or case within the SIEM/XDR platform. Ad-hoc queries executed outside of an organized hunt container are not considered part of the formal mission and must not be cited as mission outputs.
The hunt container must be named consistently with the mission naming convention established by the Threat Hunt Lead at mission start.
All hunt artifacts, queries, bookmarks, findings, entity mappings, and notes, must reside within the designated hunt container for that mission.
4.2 Query Management
All queries executed during a mission must be saved and documented within the hunt container. Unsaved, ad-hoc queries that produce relevant results must be saved immediately before the session is closed.
Queries must be named descriptively, reflecting the technique, hypothesis, or behavior being tested.
Queries must be tagged with the applicable MITRE ATT&CK tactic and technique where possible.
All queries must also be uploaded to the central Threat Hunt tracker.
4.3 Finding Documentation
Any query result that is suspicious, anomalous, or relevant to the hunt hypothesis must be bookmarked, annotated, or otherwise preserved within the platform's native finding mechanism.
Each documented finding must include: the query that produced it, the timestamp of the result, the entities involved (user, host, IP, process, etc.), and the hunter's assessment.
Findings that warrant escalation to the SOC must be flagged immediately..
4.4 Hypothesis Tracking
Each hunt mission is driven by one or more hypotheses. The status of each hypothesis, Unconfirmed, Validated, or Invalidated, must be updated within the hunt container as the mission progresses.
A validated hypothesis with high-risk findings must trigger SOC escalation. A validated hypothesis with low-risk or benign findings must be documented and closed with supporting rationale.
An invalidated hypothesis must also be documented as a negative result. Negative results are valid mission outcomes.
4.5 Detection Engineering Pipeline
When a query produces results that could serve as the basis for a standing detection rule, the hunter must flag it as a detection engineering candidate within the hunt container.
Detection engineering candidates are handed off to the detection engineering function at mission close, in accordance with Detection engineering SOP.
5. Microsoft Sentinel / Microsoft Defender XDR
5.1 Platform Overview
Microsoft Sentinel is a cloud-native SIEM and Security Orchestration, Automation, and Response (SOAR) platform integrated into the Microsoft Defender portal as part of the Microsoft unified security operations (SecOps) platform. The Hunting capability within Sentinel provides a structured environment for proactive threat hunting using Kusto Query Language (KQL) across all ingested log data.
Within Sentinel, there is a critical distinction between three core objects that hunters must understand and apply correctly:
Object | Definition and Purpose |
Hunting Query | A KQL query written or sourced from the Content Hub. Executed to retrieve results from ingested log data. A hunting query is data — it has no organizational context on its own. |
Hunt | A container within Sentinel that organizes an investigation. A Hunt contains multiple query tabs, bookmarks, entity mappings, MITRE technique tags, team comments, and metrics. A Hunt is the formal mission workspace — it is data plus context plus collaboration. |
Bookmark | A preserved query result. Captures the exact data row, the KQL that found it, the timestamp, and the entities involved. Bookmarks are how evidence accumulates within a Hunt. |
Livestream | A real-time monitoring session that continuously watches incoming data for query matches. Used for hypothesis validation against live traffic and active incident monitoring. |
NOTE: Running a hunting query is not the same as creating a Hunt. A query is data. A Hunt is a formal investigation workspace. Every Threat Hunt mission must have a dedicated Hunt created in Sentinel before query execution begins.
5.2 Pre-Mission Setup in Microsoft Sentinel
5.2.1 Navigate to the Hunting Page
In the Microsoft Defender portal, navigate to Microsoft Sentinel > Threat Management > Hunting.
Confirm you are in the correct workspace for the mission environment.
Review the Queries tab to familiarize yourself with available out-of-the-box and custom hunting queries relevant to the mission hypothesis.
5.2.2 Create the Hunt Container
Select the Hunts tab and create a new Hunt for the mission.
Name the Hunt using the mission naming convention (e.g., THOC-###-2026-03-<Huntname>). Consistent naming is required for tracker alignment.
Enter the mission hypothesis in the Hunt description field.
Tag the Hunt with the applicable MITRE ATT&CK tactics and techniques relevant to the mission scope.
Assign all participating hunters to the Hunt so that all work is captured under a shared workspace.
5.2.3 MITRE ATT&CK Coverage Review
From the Hunting page, review the MITRE ATT&CK tactic bar to identify coverage gaps relevant to the mission.
Identify techniques with no active analytics rules but with available hunting queries — these are priority targets for the hunt.
Document identified coverage gaps in the Hunt comments field for inclusion in the mission report.
5.3 Query Execution and Management
5.3.1 Sourcing Queries
Sentinel provides two sources of hunting queries:
Out-of-the-Box Queries: Installed from the Content Hub as part of security solutions. Available on the Queries tab, grouped by MITRE ATT&CK tactic. These are developed and maintained by Microsoft security researchers.
Custom Queries: Created or modified by the hunt team. Must be saved to the tenant and named descriptively. Can be cloned from out-of-the-box queries as a starting point.
5.3.2 Researching Queries
Many cyber security researchers and organizations also publish queries online.
Security researchers focusing on Microsoft KQL queries:
Vendor specific query repos:
5.3.3 Running Queries
From the Queries tab, run individual queries by selecting Run Query in the query details pane.
For broad coverage assessments, use Run All Queries or Run Selected Queries to execute multiple queries simultaneously. Note that execution time increases with query volume and time range.
After execution, sort results by the Results column to identify queries with the highest result counts.
Use the Results Delta filter to identify spikes in activity over the past 24 hours compared to the prior 24-48 hour baseline. Spikes are a priority review item.
For queries returning N/A, check the required data sources and confirm whether the relevant connector is active. Document data source gaps in the Hunt and the Threat Hunt tracker.
5.3.4 Query Time Range and Scope
Set the query time range to align with the mission scope as defined in the mission plan. Default proactive hunt coverage is a minimum of 30 days unless the mission plan specifies otherwise.
For incident-driven hunts, set the time range to span from at least 14 days prior to the incident to the present, or as specified by the Threat Hunt Lead.
Document the time range used for all queries in the Hunt and in the central Threat Hunt tracker.
5.3.5 Saving and Tagging Queries
All queries executed during the mission must be saved within the Sentinel tenant. Use the Save Query function on the Queries tab.
Add the query to Favorites if it will be executed repeatedly across the mission.
Tag each query with the applicable MITRE ATT&CK technique using the Techniques field.
Upload all queries to the central Threat Hunt tracker.
5.5 Bookmark Management
Bookmarks are the primary mechanism for preserving evidence within a Microsoft Sentinel Hunt. The following standards govern bookmark creation and management:
5.5.1 When to Bookmark
Bookmark any query result that is suspicious, anomalous, or relevant to the hunt hypothesis.
Bookmark confirmed indicators of compromise identified during the hunt.
Bookmark results that establish behavioral baselines relevant to the mission, both normal and anomalous patterns.
Bookmark results that will serve as the evidentiary basis for a SOC escalation or incident creation.
5.5.2 Bookmark Configuration Standards
When creating a bookmark, select all relevant rows before clicking Add Bookmark.
In the bookmark panel, add descriptive tags to classify the finding (e.g., the campaign name, threat actor, or technique).
Configure entity mappings within the bookmark to extract and link user accounts, host names, IP addresses, processes, and other relevant entity types. Entity mapping enables Sentinel to correlate the finding across other data in the environment.
Apply MITRE ATT&CK tactic and technique tags to the bookmark.
Add a hunter note to the bookmark describing the analytical assessment, what the finding represents, why it is significant, and what follow-up action is required.
5.5.3 Bookmark Actions and Escalation
Review all bookmarks from the Bookmarks tab of the Hunting page.
For bookmarks representing high-confidence findings, create a new incident or add to an existing incident using the Incident Actions option.
Use the investigation graph from a bookmarked finding to perform deeper entity correlation, reviewing connected users, hosts, and IPs across the environment.
Notify the Threat Hunt Lead of any bookmark that has been escalated to an incident.
5.6 Detection Engineering Outputs
When a hunting query produces results of sufficient quality and frequency to warrant a standing detection, the hunter must initiate the detection engineering handoff process. Detection engineering is covered in depth in the Threat Hunting detection engineering SOP, a high level of converting threat hunt queries into detections is listed here.
From the query results, select New Alert Rule > Create Microsoft Sentinel Alert to launch the Analytics Rule Wizard.
Configure the analytics rule with appropriate scheduling, threshold, entity mapping, and MITRE ATT&CK tagging.
Save the rule as a draft if immediate deployment is not authorized, and note the draft reference in the Hunt container.
Document the detection engineering candidate in the Threat Hunt tracker and flag it for the detection engineering review process per SOC-TH-SOP-003.
5.7 Notebooks for Advanced Investigations
For complex hunt missions requiring machine learning analysis, data visualization, or cross-source correlation beyond standard KQL capability, Microsoft Sentinel Jupyter Notebooks may be employed. Notebooks are available from the Sentinel Notebooks page and leverage the MSTICPy Python library developed by the Microsoft Threat Intelligence Center (MSTIC).
Use notebooks when the hunt scope requires processing large data volumes, advanced anomaly detection, or visualization of multi-dimensional entity relationships.
Notebooks must be saved to the organization's Azure Machine Learning workspace and named consistently with the hunt mission.
All notebook-derived findings must be documented in the Hunt container using bookmarks or comments.
Notebook usage must be documented in the Analysis Summary section of the Threat Hunt Mission Report.
5.7 Workbooks for Advanced Investigations
Microsoft Sentinel Workbooks are best suited for long-term, pattern-based data analysis rather than real-time detection. They are appropriate when query results are expected to return output continuously, scenarios where the volume or nature of results would generate constant false-positive alerts if routed through an analytics rule, but where the data holds analytical value when reviewed by a human at a defined interval.
When planning workbook use, hunters must consider two distinct consumption models:
The first is passive review, where the workbook is accessed and reviewed directly within Sentinel by an analyst on a scheduled basis. This model is appropriate when the audience is internal to the SOC and review frequency is consistent and manageable.
The second is active distribution, where the query output produced by the workbook is pushed to consumers automatically via a Logic App, for example, delivered by email, posted to a Teams channel, or sent to another downstream system. This model is appropriate when the intended audience is outside the SOC, when review frequency needs to be enforced rather than voluntary, or when the data needs to reach multiple stakeholders simultaneously.
The choice between these models should be deliberate and documented in the hunt mission tracker. Factors to consider include the sensitivity of the data, the technical capability of the intended audience, the required review cadence, and whether automated distribution introduces any data handling or access control concerns.
5.8 Mission Close and Handoff
Before closing the Hunt container, confirm that all queries are saved, all significant results are bookmarked, and all entity mappings are complete.
Update the hypothesis status in the Hunt (Validated / Invalidated) with supporting notes.
Record any detection engineering candidates and visibility gaps identified during the mission.
Export or screenshot the Hunt summary metrics for inclusion in the mission report.
Update the module status to Complete in the central Threat Hunt tracker, recording the time of completion.
NOTE: The Hunt container in Sentinel must not be deleted after mission close. It serves as the permanent record of the mission's investigative activity and may be referenced during subsequent missions, audits, or incident investigations.
5.9 Microsoft Sentinel Quick Reference — Key Locations
Task | Defender Portal Navigation Path |
Access Hunting | Microsoft Sentinel > Threat Management > Hunting |
Browse Hunting Queries | Hunting > Queries tab |
Create / Manage Hunts | Hunting > Hunts tab |
View Bookmarks | Hunting > Bookmarks tab |
Create Livestream Session | Hunting > Livestream |
Install Content Hub Queries | Content Hub > Install relevant solution |
Create Analytics Rule from Query | Query Results > New Alert Rule > Create Microsoft Sentinel Alert |
Access Notebooks | Microsoft Sentinel > Threat Management > Notebooks |
View MITRE Coverage Dashboard | Hunting > Queries tab > MITRE ATT&CK tactic bar |
View HuntingBookmark Table | Logs > HuntingBookmark table query |
6. Elastic Security
[ ELASTIC SECURITY — SECTION RESERVED FOR FUTURE EXPANSION ] This section will be populated when organizational procedures for this platform are defined. |
This section is reserved for Threat Hunt Mission Organization procedures specific to Elastic Security. When organizational procedures for this platform are defined and approved, this section will be populated with the following content:
Platform overview and hunt workspace architecture in Elastic Security
Hunt session creation and management using Elastic's Timeline and Cases features
KQL and EQL query execution, management, and naming standards within Elastic
Bookmark and evidence preservation equivalents in Elastic Security
MITRE ATT&CK mapping and coverage review procedures
Detection rule creation from hunt findings using Elastic Detection Engine
Mission close and handoff procedures specific to Elastic Security
Quick reference navigation table for Elastic Security
7. Splunk Enterprise Security
[ SPLUNK ENTERPRISE SECURITY — SECTION RESERVED FOR FUTURE EXPANSION ] This section will be populated when organizational procedures for this platform are defined. |
This section is reserved for Threat Hunt Mission Organization procedures specific to Splunk Enterprise Security. When organizational procedures for this platform are defined and approved, this section will be populated with the following content:
Platform overview and hunt workspace architecture in Splunk Enterprise Security
Mission Hunt creation and management using Splunk ES Investigations and Mission Control
SPL (Search Processing Language) query execution, naming standards, and management within Splunk
Findings documentation using Splunk Notable Events, Risk-Based Alerting (RBA), and the Adaptive Response framework
MITRE ATT&CK mapping using the Splunk ES MITRE ATT&CK Coverage Dashboard
Detection rule and correlation search creation from hunt findings
Mission close and handoff procedures specific to Splunk Enterprise Security
Quick reference navigation table for Splunk Enterprise Security
8. Additional Platforms — Reserved
Additional SIEM/XDR platform sections may be added to this document as the organization expands its tooling or adopts new platforms. Each new platform section must follow the structure established in Section 5 (Microsoft Sentinel) and include:
A platform overview describing hunting architecture and key objects
Pre-mission setup procedures including hunt container or workspace creation
Query execution, naming, tagging, and saving standards
Finding documentation and evidence preservation procedures
Real-time monitoring or livestream equivalent procedures
Detection engineering output procedures
Mission close and handoff procedures
A quick reference navigation table
Candidate platforms for future sections include: IBM QRadar, Google Chronicle / Google SecOps, Palo Alto Cortex XDR, CrowdStrike Falcon Insight XDR, and others as relevant to the organization's environment.
Comments