TH0.8 Organizational Readiness for Hunting

Prerequisites are not optional

Hunting is a capability that builds on other capabilities. It is not the first thing you deploy. It is the thing you deploy after your detection foundation is solid enough that hunting can extend it rather than duplicate it.

An organization that cannot triage alerts effectively should not hunt. The hours are better spent fixing alert triage first. An organization that does not ingest the data sources hunting requires should not hunt. The queries will return empty results. An organization without an IR process should not hunt — because when hunting finds a compromise, the finding needs to go somewhere.

This is not gatekeeping. It is sequencing. The prerequisites described below are achievable by any M365 security operation that has been running for 6–12 months. If yours is newer than that, the Mastering KQL and SOC Operations courses on this platform build the foundations this course requires.

Prerequisite 1: Sufficient data ingestion

Hunting queries data. If the data is not in your SIEM, the hunt cannot find anything. The minimum data sources for the campaigns in this course:

Required (non-negotiable):

SigninLogs — interactive user sign-ins. Every authentication hunt (TH4) and most other campaigns reference this table. If this is not ingested into Sentinel, your identity visibility is functionally zero.

AADNonInteractiveUserSignInLogs — application and token-based sign-ins. AiTM token replay detection (TH4), OAuth abuse investigation (TH6), and service principal monitoring all require this table. Many organizations ingest SigninLogs but not this companion table — leaving a critical blind spot.

AuditLogs (Entra ID) — directory changes. Privilege escalation (TH7), application consent (TH6), and conditional access modification monitoring all require this table.

CloudAppEvents — Defender for Cloud Apps telemetry. Email manipulation (TH5), file access (TH8), and shadow IT (TH11) campaigns depend on this table. Requires Defender for Cloud Apps to be connected.

SecurityAlert — aggregated alerts from all detection sources. The ATT&CK coverage analysis (TH3) and several campaign modules reference alerts to correlate hunting findings with existing detections.

Required for endpoint campaigns:

DeviceProcessEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceNetworkEvents, DeviceLogonEvents — Defender for Endpoint telemetry. The endpoint persistence hunt (TH9), lateral movement hunt (TH10), and ransomware pre-encryption hunt (TH12) require these tables.

Valuable but not blocking:

AADServicePrincipalSignInLogs — service principal authentication. Enriches TH6 (OAuth hunt) significantly. If not ingested, the hunt proceeds but with reduced visibility.

IdentityLogonEvents, IdentityDirectoryEvents — Defender for Identity telemetry. Enriches TH10 (lateral movement) and TH7 (privilege escalation). If not ingested, the hunts rely on Entra ID logs only.

MicrosoftGraphActivityLogs — Graph API activity. If available, significantly enriches TH5 and TH6 with API-level visibility into how applications access data.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Check which hunting-critical tables are ingested
// Run in your Sentinel workspace
let requiredTables = datatable(TableName:string)
[
    "SigninLogs",
    "AADNonInteractiveUserSignInLogs",
    "AuditLogs",
    "CloudAppEvents",
    "SecurityAlert",
    "DeviceProcessEvents",
    "DeviceFileEvents",
    "DeviceNetworkEvents",
    "DeviceLogonEvents"
];
requiredTables
| extend HasData = iff(
    toscalar(
        union isfuzzy=true
            (SigninLogs | take 1),
            (print check="na")
    ) != "na", "✓ Ingested", "✗ Missing")
// NOTE: This pseudo-query illustrates the check.
// In practice, run: Usage | distinct DataType
// and compare against the required list.

A simpler approach — check what is actually ingested:

1
2
3
4
5
6
7
8

// What tables have data in your workspace?
Usage
| where TimeGenerated > ago(7d)
| summarize DataGB = sum(Quantity) / 1024
    by DataType
| sort by DataGB desc
// Compare this list against the required tables above
// Missing tables = hunting blind spots

Prerequisite 2: Baseline detection rules

Hunting fills the gaps between detection rules. If there are no rules, there is no gap to define — there is just a void. A minimum set of analytics rules must be deployed before hunting can productively extend them.

The minimum is not large. You need enough rules to establish a functioning alert and incident pipeline — so that when hunting discovers a compromise and escalates it to IR, the IR process can handle it. You also need enough rules that the ATT&CK coverage analysis in TH3 produces a meaningful result rather than a blank heatmap.

As a practical threshold: if your Sentinel workspace has fewer than 20 active analytics rules, prioritize detection engineering before hunting. SOC Operations on this platform provides the detection rule library and deployment methodology. If you have 20+ rules with ATT&CK technique mappings, you have enough of a foundation that hunting can identify and fill the gaps.

Prerequisite 3: KQL proficiency

Every hunt campaign in this course is built on KQL queries. Not basic queries — aggregations, joins, time-series functions, let statements, and multi-table correlation. If the analyst running the hunt cannot modify a KQL query to adapt it to their environment, the hunt degrades to “copy-paste the query and hope it works.” That is not hunting. That is automated scanning with extra steps.

The minimum KQL proficiency for this course: you can write where, project, summarize, join, extend, let, parse, and datetime operations fluently. You can use make-series with guidance (TH2 teaches the hunting applications). You can read an annotated KQL query and understand what each line does.

If this does not describe your current capability, start with Mastering KQL. That course builds the proficiency this course assumes.

Prerequisite 4: Incident response process

Hunting discovers compromises. Compromises require incident response. If your organization does not have an IR process — even a basic one — a hunting finding has nowhere to go.

The minimum: when hunting discovers evidence of compromise, the analyst knows who to notify, what containment actions to take, and how to document the finding. That process does not need to be formal or documented (though it should be). It needs to exist.

If your organization does not have an IR process, the Practical Incident Response course provides the complete methodology, from evidence collection through containment through reporting. But for hunting readiness, the bar is lower: you need the ability to respond to a finding, not the ability to run a full forensic investigation.

Prerequisite 5: Protected analyst time

This prerequisite is organizational, not technical — and it is the one that fails most often.

Hunting requires dedicated, uninterrupted time. An analyst who is on the alert queue cannot hunt effectively because every alert interrupts the hunting session. Hunting requires sustained focus — building context, iterating on queries, analyzing results, enriching with additional data. An interruption every 10 minutes prevents the analyst from building the mental model that hunting depends on.

The minimum: 4 hours per week or one full day every two weeks, protected from the alert queue. The analyst doing the hunting is not on call during those hours. If an alert fires, someone else triages it.

If your SOC cannot protect 4 hours per week for hunting, the team is likely understaffed for its current alert volume — and the solution is to fix the alert triage workload (through better rule tuning, more automation, or additional headcount) before adding hunting to the workload. Hunting on top of an already overloaded SOC does not work.

Figure TH0.8 — Hunting readiness prerequisites. All five must be met for hunting to produce value. Gaps in any prerequisite should be addressed before investing hunting hours.

The maturity sequence

Where does hunting fit in the SOC maturity journey? After detection engineering, before continuous monitoring. The typical sequence:

Stage 1 — Alert triage. Alerts fire, analysts triage them. The SOC is reactive. This is where most organizations start and some never leave. Prerequisite 4 (IR process) and Prerequisite 5 (protected time) are typically the gaps here — the SOC is consumed by alert volume with no capacity for anything proactive.

Stage 2 — Detection engineering. The SOC begins building custom analytics rules to close coverage gaps. Alert quality improves. False positive rates decrease. The team can articulate what they detect and what they do not. Prerequisites 1–3 are typically met at this stage.

Stage 3 — Proactive hunting. The detection foundation is solid. The SOC has capacity (even if limited) for proactive work. Hunting begins — initially as ad hoc queries by senior analysts, then formalized into a structured program. This course teaches this stage.

Stage 4 — Continuous monitoring. Hunting campaigns that proved their value are automated as scheduled queries. UEBA baselines run continuously. The SOC operates across all three layers of the detection pyramid simultaneously. TH16 (Scaling Hunts) teaches the automation and scheduling that enables this stage.

If your SOC is at Stage 1, this course is not your next step. Mastering KQL and SOC Operations are. If your SOC is at Stage 2 — detection engineering is active, alert quality is improving, and you can protect analyst hours — you are ready for this course.

References Used in This Subsection

• Microsoft. “Microsoft Sentinel — Data Connectors.” Microsoft Learn. https://learn.microsoft.com/en-us/azure/sentinel/data-connectors-reference
• Microsoft. “Usage table — Azure Monitor Logs.” Microsoft Learn. https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/usage
• Course cross-references: Mastering KQL (KQL proficiency), SOC Operations (detection engineering), Practical IR (incident response process)