Threat Hunt Program - Part 11 - Query Formatting

Threat Hunting SOP: Standardized Microsoft KQL Query Framework

1. Purpose

This SOP establishes a standardized framework for developing, documenting, and maintaining Microsoft KQL queries used for Threat Hunting and Detection Engineering. The objective is to ensure consistency, repeatability, and operational effectiveness across all threat hunting activities.

2. Scope

This standard applies to all:

• Threat Hunting queries

• Detection Engineering queries

• Microsoft Sentinel and Defender data sources

3. General Standards

• All queries must follow a modular structure for readability and reuse

• Queries must be self-documented with clear metadata and analyst notes

• Queries should be optimized to remain within the 10,000 character limit

• Queries must support:

  • Investigation

  • Detection development

  • Reporting and baselining

4. Query Metadata Header (Required)

Every query must begin with the following standardized header:

//----Status: Development | Production-Standalone | Production-Analytic | //Testing
//
//----Version: vX.X
//
//----Author(s): First Last (SME), First Last (QA/Lead)
//
//----Type: LOLBin | Binary | TTP (e.g., MITRE ATT&CK T1490 – Inhibit //System Recovery)
//
//----Description: <Brief description of detection or hunting objective>
//
//----Data Sources: <e.g., DeviceProcessEvents, DeviceNetworkEvents>
//
//----Variables: <List variables or None>//----False Positives: Reference 
//
//FP section below

5. Query Structure (Standard Sections)

5.1 Data Source Definition

Identify relevant tables and scope data early.

//----Data 
//Example
SourcesDeviceProcessEvents

5.2 Search (Initial Filtering)

Apply broad filters to reduce dataset size.

//----Search
//example
| where Timestamp > ago(30d)| where FileName =~ "wmic.exe"

5.3 Hunting Logic (TTP Identification)

Define detection logic using flags/conditions.

//----Hunting Logic
//example
| extend isWMIQuery = (ActionType == "ProcessCreatedUsingWmiQuery")

5.4 Enrichment & Post-Processing

Add context and classification for findings.

//----Enrichment
//example
| extend DetectionType = case(isWMIQuery, "Remote WMI Query Interaction - Potential Malicious Activity",    "Unknown")

5.5 False Positives / Whitelisting

Incorporate baseline knowledge (e.g., 12-month lookback).

//----False Positives / Whitelisting// Reference known benign activity //based on historical baseline

5.6 Advanced Detection Logic

Include detailed behavioral conditions.

//example
| where IsPCL_BadArg    
   or IsIPCL_BadArg
   or IsPCL_BadPath    
   or IsIPCL_BadPath
   or isNode
   or isShadow

5.7 Detection Classification

Standardize severity and context.

//----Detection Classification
//example
| extend DetectionType = case(IsPCL_BadArg, "WMIC execution with suspicious arguments - Moderate",    
      IsIPCL_BadArg, "WMIC execution with encoded arguments - Moderate",    
      IsPCL_BadPath, "WMIC execution with suspicious paths - Moderate",    
      IsIPCL_BadPath, "WMIC execution with encoded paths - Moderate",    
      isNode, "WMIC lateral movement via node - High",    
      isShadow, "Shadow copy interaction - Possible ransomware activity - High",    "Unknown")

5.8 Output Formatting

Standardize output for analyst consumption.

//----Output
//example
| project-reorder    
  TimeGenerated,
  DeviceName,
  ActionType,
  DetectionType,
  FileName,
  FolderPath,
  ProcessCommandLine,
  InitiatingProcessCommandLine

5.9 Analysis (Development Only)

Optional section for testing and tuning.

//----Analysis
// Temporary filters or counts for validation

5.10 References

Document supporting intelligence.

//----References
// MITRE ATT&CK, threat intel reports, internal hunt findings

6. Operational Guidance

6.1 Threat Hunting Workflow

• Use CTI to define hypotheses

• Build KQL queries using this standard

• Validate findings

• Promote successful logic to detections

6.2 Detection Engineering Integration

• Matured queries should be converted into:

  • Scheduled analytics rules

  • Near-real-time detections

• Include tuning for:

  • False positives

  • Environmental baselines

6.3 Documentation Requirements

• All queries must be stored in a central repository

• Updates must include:

  • Version changes

  • Reason for modification

7. Key Principles

• Consistency → Standard structure across all queries

• Clarity → Queries must be understandable by any analyst

• Reusability → Modular logic for future detections

• Traceability → Link to threat intelligence and outcomes

• Efficiency → Optimize performance and reduce noise

8. Outcome

Following this SOP ensures:

• Faster threat hunting execution

• Higher-quality detections

• Reduced false positives

• Scalable and repeatable cyber operations