Threat Hunting in Microsoft Sentinel: KQL Queries and MITRE ATT&CK Methodology 2026

What Threat Hunting Is (and Why It Is Not Threat Detection)

Threat hunting is proactive, analyst-driven investigation. Threat detection is rule-driven automation. Both are necessary, and confusing them is how organizations end up with a detection backlog and no hunting program.

The distinction is structural: Detection fires an alert when a known bad pattern occurs. A Sentinel analytics rule watches for EventID 4625 with more than 10 failures in five minutes and creates an incident. Detection requires no analyst to initiate it. It scales with hardware. It cannot find what it does not have a rule for. Threat hunting starts with an analyst asking a question: "If a sophisticated attacker was living in our environment using pass-the-hash lateral movement, what would that look like in our logs?" The analyst writes KQL, queries historical data, evaluates results, and either finds evidence of compromise or closes the hypothesis as not confirmed. Hunting can find threats that have no matching detection rule. It does not scale with hardware. It scales with analyst skill.

The hunter mindset has three properties:

1. Assume breach. Hunters operate on the working assumption that an attacker is already inside. This removes the psychological barrier of "we would have gotten an alert if something was wrong."
2. Follow the data. Every hypothesis must be testable against log data. If a hypothesis cannot be expressed as a query, it is not a hunting hypothesis.
3. Document everything. A hunt that finds nothing is still valuable if the methodology is recorded, because it tells you what you checked and when.

---

The Threat Hunting Cycle

Effective hunting is a continuous cycle, not a one-time project. Each completed hunt either produces a new detection rule or refines the next hypothesis.

The cycle has six stages:

1. Hypothesis: A testable statement about attacker behavior. "Attackers are using scheduled tasks for persistence on domain-joined Windows servers."
2. Data Collection: Identify which data sources contain evidence of the hypothesized behavior. For scheduled tasks: SecurityEvent logs with EventID 4698.
3. Hunt: Write and execute KQL queries against the identified data sources.
4. Findings: Evaluate query results. Are there anomalies? Does the behavior match expected patterns or indicate attacker activity?
5. Detections: If the hunt confirms malicious activity, convert the successful query into a Sentinel analytics rule so future occurrences alert automatically.
6. Hypothesis update: Use findings to generate new hypotheses. A confirmed scheduled task persistence finding leads to: "If the attacker used scheduled tasks, they likely moved laterally first. Hunt for lateral movement via WMI in the same timeframe."

---

Hypothesis-Driven vs Data-Driven Hunting

Both approaches are valid. Most mature hunting programs use both. Understanding the difference helps allocate analyst time appropriately.

For most SOC teams starting a hunting program, hypothesis-driven hunting against the MITRE ATT&CK framework provides the fastest return. Pick a technique your threat intel says is relevant to your industry, write the KQL, run it, and document the result.

---

MITRE ATT&CK as the Hunting Backbone

MITRE ATT&CK is a knowledge base of adversary tactics, techniques, and procedures based on real-world intrusions. For threat hunters, it is a menu of testable hypotheses organized by phase of the attack lifecycle.

Every technique in ATT&CK has an ID (e.g., T1003), a description of what attackers do, and documented sub-techniques. When you map your hunting queries to ATT&CK IDs, you get coverage visibility: a heat map showing which techniques you actively hunt for and which you have never tested.

The eight KQL queries below cover common high-impact techniques. Each query is written for a Microsoft Sentinel Log Analytics workspace and tuned for production environments.

T1003: Credential Dumping

Attackers dump credentials from LSASS memory to harvest password hashes or plaintext credentials for lateral movement. Tools include Mimikatz, Procdump, and custom loaders.

SecurityEvent
| where EventID == 4688
| where CommandLine has_any ('lsass', 'mimikatz', 'procdump')
| where TimeGenerated > ago(24h)
| project TimeGenerated, Computer, Account, CommandLine, ParentProcessName
| order by TimeGenerated desc

What to look for: Any process launching with these strings in the command line is suspicious. Procdump against lsass.exe is a common defender technique too, so correlate with the initiating account and time of day.

T1558.003: Kerberoasting

Attackers request Kerberos service tickets for accounts with SPNs, then crack the ticket offline to recover the service account password. Ticket encryption type 0x17 (RC4) is the tell-tale sign.

SecurityEvent
| where EventID == 4769
| where TicketOptions == '0x40810000'
| where TicketEncryptionType == '0x17'
| summarize count() by Account, IpAddress
| where count_ > 5
| order by count_ desc

What to look for: A single source IP requesting many RC4-encrypted service tickets in a short window. Legitimate kerberos traffic uses AES (0x12 or 0x11). RC4 requests outside a known admin process are high-fidelity.

T1550.002: Pass-the-Hash

Attackers use stolen NTLM password hashes to authenticate as a user without knowing the plaintext password. The indicator is an NTLM network logon where the source workstation differs from the authenticating computer.

SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AuthenticationPackageName == 'NTLM'
| where WorkstationName != Computer
| where TimeGenerated > ago(1h)
| project TimeGenerated, Computer, Account, WorkstationName, IpAddress
| order by TimeGenerated desc

What to look for: Lateral movement via NTLM where the source workstation does not match the target computer. Filter out known administrative accounts and service accounts with documented NTLM requirements before escalating.

T1047: Lateral Movement via WMI

Attackers use Windows Management Instrumentation to execute commands on remote systems. WMI is built into Windows, rarely blocked, and generates minimal logs unless specifically audited. The indicator is wmiprvse.exe spawning shells.

DeviceProcessEvents
| where InitiatingProcessFileName =~ 'wmiprvse.exe'
| where FileName in~ ('powershell.exe', 'cmd.exe', 'mshta.exe')
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by Timestamp desc

What to look for: wmiprvse.exe is the WMI service host. If it spawns PowerShell, cmd, or mshta, an attacker is likely executing remote commands via WMI. This data comes from Microsoft Defender for Endpoint (DeviceProcessEvents table).

T1053.005: Scheduled Task Persistence

Attackers create scheduled tasks to maintain persistence after a reboot or credential rotation. EventID 4698 logs scheduled task creation. Tasks in non-Microsoft namespaces are suspicious.

SecurityEvent
| where EventID == 4698
| extend TaskName = tostring(EventData.TaskName)
| where TaskName !startswith '\\Microsoft'
| project TimeGenerated, Computer, Account, TaskName
| order by TimeGenerated desc

What to look for: Scheduled tasks created outside the \Microsoft\ namespace by non-standard accounts, especially outside business hours. Correlate with the account that created the task and whether that account has any other suspicious activity.

T1059.001: PowerShell Obfuscation

Attackers obfuscate PowerShell commands using Base64 encoding or the -EncodedCommand parameter to evade content-based detection. This query surfaces encoded PowerShell executions.

DeviceProcessEvents
| where FileName =~ 'powershell.exe'
| where ProcessCommandLine has_any ('-enc', '-encodedcommand', 'frombase64')
| where ProcessCommandLine !has 'WindowsPowerShell'
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
| order by Timestamp desc

What to look for: Encoded PowerShell from non-administrative users, from unexpected parent processes (e.g., Word, Excel spawning encoded PowerShell), or at unusual hours. Decode the Base64 payload to understand intent.

T1071.004: DNS Tunneling

Attackers exfiltrate data or maintain C2 communication by encoding data in DNS query strings. The pattern is high query volume with high unique query entropy from a single client.

DnsEvents
| summarize QueryCount=count(), UniqueQueries=dcount(Name) by ClientIP, bin(TimeGenerated, 1h)
| where QueryCount > 200 and UniqueQueries > 150
| order by QueryCount desc

What to look for: A client generating more than 200 DNS queries per hour where more than 150 are unique queries is a strong signal. Normal DNS behavior has high repetition (cached responses). DNS tunneling generates mostly unique queries because each query carries a different data payload.

T1071.001: Beacon Detection

Attackers maintain persistent access via beaconing malware that checks in with a C2 server at regular intervals. The pattern is periodic, small-payload connections to the same remote IP.

DeviceNetworkEvents
| where ActionType == 'ConnectionSuccess'
| summarize ConnectionCount=count(), avg_bytes=avg(SentBytes) by RemoteIP, DeviceName, bin(TimeGenerated, 1h)
| where ConnectionCount > 20 and avg_bytes < 2000
| order by ConnectionCount desc

What to look for: More than 20 successful connections per hour to the same remote IP with average payload under 2KB per connection is characteristic of beaconing. Correlate the remote IP against threat intelligence and check whether it matches known CDN or update server IP ranges before escalating.

---

The Sentinel Hunting Interface

Microsoft Sentinel has a dedicated hunting interface at Sentinel > Threat Management > Hunting. It provides three capabilities that distinguish structured hunting from ad-hoc KQL queries. Hunting Queries: A library of saved KQL queries, each mapped to a MITRE ATT&CK tactic and technique. Sentinel ships with over 200 built-in hunting queries maintained by Microsoft. You can add custom queries and tag them with technique IDs. The interface shows when each query was last run and how many results it returned, so you can track hunting coverage over time. Bookmarks: When a hunting query returns a suspicious result that needs deeper investigation, you bookmark it. A bookmark captures the query, the result row, your notes, and optionally links it to an existing Sentinel incident. Bookmarks are the hunting equivalent of evidence collection: a chain of custody for findings before they become formal incidents. Livestream: Hunting Livestream runs a query in near-real-time against incoming data, rather than against historical logs. Use Livestream when you are actively investigating a suspected ongoing compromise and want to see new matching events as they arrive. Livestream sessions can be bookmarked and promoted to incidents. To run a hunt in Sentinel:

1. Navigate to Microsoft Sentinel > Threat Management > Hunting
2. Filter queries by MITRE ATT&CK technique or tactic to find relevant queries
3. Select a query and click "Run Query"
4. Review results in the query results panel
5. Right-click suspicious rows and select "Add Bookmark" to preserve findings
6. From the Bookmarks tab, promote confirmed findings to incidents or attach them to existing incidents

---

Building a Hunting Hypothesis from Threat Intelligence

Threat intelligence reports describe specific attacker behaviors. Those behaviors map directly to hunting hypotheses. Here is an example using the Cl0p ransomware group's documented MOVEit exploitation campaign. Threat intel input: Cl0p exploited a zero-day SQL injection vulnerability in MOVEit Transfer (CVE-2023-34362) to deploy a web shell, exfiltrate data, and extort victims. Documented TTPs include SQL injection for initial access, web shell deployment for persistence, and mass data staging before exfiltration. Hypothesis derivation:

Each row becomes a KQL hunt. Even if your organization was not directly targeted, running these hunts validates that you would have detected the activity if it occurred in your environment.

The general pattern for hypothesis-driven hunting from threat intel:

1. Read the threat intel report and extract documented TTPs
2. Map each TTP to a MITRE ATT&CK technique ID
3. Identify which Sentinel data sources contain evidence of each technique
4. Write a KQL query to detect the technique pattern
5. Run the query against historical data covering the relevant threat window
6. Document results and promote confirmed findings to incidents

---

From Hunt to Detection: Promoting Findings to Analytics Rules

A hunt that confirms malicious behavior has two outputs: an incident for the current finding, and a detection rule so future occurrences alert automatically.

The conversion process from a successful hunting query to a Sentinel Scheduled Alert Rule: Step 1: Validate the query

Ensure the query returns the correct results with no false positives on a clean data set. Add filters as needed to reduce noise. Step 2: Define the alert logic

In Sentinel > Analytics > Create > Scheduled Query Rule:

• Set the query (paste your working KQL)
• Set query frequency (how often the rule runs): typically every 5 or 15 minutes for high-priority techniques
• Set the lookback window (how far back the rule queries): match to the frequency plus buffer
• Set the alert threshold: "Greater than 0" for high-fidelity queries; tune higher for noisier queries

Step 3: Map to ATT&CK

In the rule configuration, add the MITRE ATT&CK tactic and technique. This populates the coverage map and enables SOC dashboards to show which techniques have active detections. Step 4: Configure incident creation

Enable "Create incidents from alerts" if the query is high-fidelity enough to generate direct incidents. For noisier queries, enable alert grouping to aggregate multiple alerts into a single incident. Step 5: Test and monitor

After the rule is active, monitor false positive rates for the first two weeks. Tune the query or add watchlist-based exclusions as needed.

The goal is a virtuous cycle: hunting finds behavior that has no rule, hunting confirms that behavior is malicious, hunting produces the KQL that becomes the detection rule, and the detection rule closes the gap permanently.

---

Hunting Workbook Template

Every hunt should be documented in a structured workbook. Documentation is what transforms a one-time investigation into institutional knowledge, and it is what you reference when auditors or incident responders ask what you checked and when.

A complete hunting workbook entry contains:

Maintain hunting workbooks in a shared location (SharePoint, Confluence, or a dedicated Sentinel workbook) so all analysts can review prior hunts before starting new ones.

---

Frequently Asked Questions

What is the difference between threat hunting and threat detection?

Threat detection is automated: analytics rules, machine learning models, and threat intelligence feeds fire alerts when a known bad pattern occurs. Threat hunting is manual and analyst-initiated: a hunter forms a hypothesis about attacker behavior, queries historical telemetry, and either confirms or disproves the hypothesis. Detection scales with hardware and rules; hunting scales with analyst skill. Both are required in a mature SOC because detection only finds what it has a rule for, while hunting can find threats that have never been defined as rules before.

How do I get started with threat hunting in Microsoft Sentinel?

Start with Sentinel's built-in hunting queries. Navigate to Sentinel > Threat Management > Hunting and sort by MITRE ATT&CK tactic. Pick one technique relevant to your threat model (credential dumping is a good starting point), read the query, understand what it looks for, and run it against your data. Document the results. If results are empty, document that you checked. If results are interesting, bookmark them. After three or four hunts, you will have a working process and can begin writing custom queries for your environment.

What KQL skills do I need for threat hunting?

The core KQL functions used in most hunting queries are: where (filter), summarize (aggregate), project (select columns), join (combine tables), extend (add calculated columns), parse (extract structured data from strings), bin (time bucketing), and dcount (distinct count). You do not need to master all of KQL before hunting. Start with the built-in queries, read them to understand the pattern, modify parameters to fit your environment, and add complexity as your skill grows. The Microsoft KQL Quick Reference and the Sentinel GitHub repository of hunting queries are the two most valuable learning resources.

How long should a threat hunting engagement take?

A single hypothesis-driven hunt, from forming the hypothesis to documenting results, typically takes one to four hours for an experienced analyst. A formal hunting sprint covering eight to ten techniques over a two-week period is a common model for teams building a structured program. Detection engineering follow-up, converting successful hunts into analytics rules, adds another hour per finding. For organizations running a continuous program, a rule of thumb is one full-time analyst-equivalent for every 500 endpoints in scope, spending 20 to 30 percent of their time on proactive hunting.

What data sources are most valuable for threat hunting in Sentinel?

In order of hunting value: SecurityEvent (Windows Event Logs, required for identity and authentication hunting); SigninLogs and AADNonInteractiveUserSignInLogs (Entra ID authentication, required for identity-based TTPs); DeviceProcessEvents and DeviceNetworkEvents (from Defender for Endpoint, required for endpoint-based TTPs); DnsEvents (DNS logs, required for DNS tunneling and C2 detection); OfficeActivity (Microsoft 365 activity, required for data exfiltration hunting); and AzureActivity (Azure control plane, required for cloud resource manipulation hunting). If you have only one data source, start with SecurityEvent. If you have Defender for Endpoint deployed, add DeviceProcessEvents immediately because it provides command-line visibility that Windows Event Logs alone cannot give you.