In this section

TH0.8 Organizational Readiness for Hunting

3-4 hours · Module 0 · Free

Operational Objective

Not every SOC is ready to hunt. Hunting without prerequisites in place produces wasted effort — queries that return no results because the data is not ingested, hypotheses that cannot be tested because baseline detections are not established, and findings that cannot be acted on because the IR process is immature. This subsection defines the prerequisites, assesses your readiness honestly, and identifies what to fix first if you are not ready yet.

Deliverable: A readiness assessment for your organization, identifying which prerequisites are met, which are gaps, and which gaps must be closed before hunting adds value.

⏱ Estimated completion: 25 minutes

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.

// 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.

// 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

Expand for Deeper Context

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), privilege escalation 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. Email-based threats (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 application & API abuse (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 threats hunt (TH9), lateral movement hunt (TH10), and pre-ransomware activity hunt (TH12) require these tables.

Valuable but not blocking:

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

IdentityLogonEvents, IdentityDirectoryEvents — Defender for Identity telemetry. Enriches TH10 (lateral movement) and TH7 (email-based threats). 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.

A simpler approach — check what is actually ingested:

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.

Try it yourself

Exercise: Run the readiness assessment

Score your organization against each prerequisite:

1. Data ingestion: Run the Usage query from this subsection. Check each required table against the results. Score: all required tables ingested (ready) / some missing (address gaps) / most missing (not ready).

2. Detection rules: Count your active Sentinel analytics rules. Are 20+ deployed with ATT&CK mappings? Score: yes (ready) / 10-19 rules (close, build a few more) / fewer than 10 (prioritize detection engineering).

3. KQL proficiency: Can you write a join between SigninLogs and AuditLogs without reference documentation? Can you use summarize with make_set and dcount? Score: yes (ready) / partially (Mastering KQL as a parallel track) / no (complete Mastering KQL first).

4. IR process: If hunting finds a compromised account tomorrow, do you know who to notify, what containment steps to take, and how to document the finding? Score: yes (ready) / informal (acceptable for initial hunts) / no process exists (address first).

5. Protected time: Can you block 4 hours next week for hunting with no alert queue responsibility? Score: yes (ready) / maybe (negotiate with SOC lead) / impossible (address alert workload first).

If you scored "ready" on all five, proceed to TH1. If you have gaps, the Ridgeline curriculum provides the courses to close them before investing in hunting.

⚠ Compliance Myth: "We need a dedicated threat hunting team before we can start hunting"

The myth: Hunting requires a specialized team with dedicated headcount. Until we can hire threat hunters, we cannot hunt.

The reality: Most organizations that hunt effectively do not have dedicated hunting teams. They have SOC analysts who spend protected hours on hunting as part of a rotation — perhaps one analyst per week on "hunt duty" while the others handle the alert queue. The minimum viable hunting program is one analyst, 4 hours per week, with a prioritized backlog of hypotheses. That analyst can execute one hunt campaign per month from this course. Twelve campaigns per year, twelve detection rules produced, measurable coverage improvement. You do not need to hire before you hunt. You need to protect time and provide structure. This course provides the structure.

Extend this assessment

If your organization is considering a formal SOC maturity assessment — against the CMMI Cybermaturity Platform, the SOC-CMM, or a custom framework — the hunting readiness prerequisites in this subsection map directly to the proactive monitoring and threat detection domains of those frameworks. The readiness assessment exercise produces evidence that is useful for maturity assessments: documented data ingestion coverage, detection rule inventory with ATT&CK mapping, analyst capability assessment, and IR process documentation. If you are preparing for a maturity assessment anyway, the hunting readiness exercise produces dual-purpose documentation.

📋 Operational Artifact — Hunting Readiness Scorecard

Prerequisite 1 — Data ingestion: Required tables ingested? SigninLogs ☐ | AADNonInteractive ☐ | AuditLogs ☐ | CloudAppEvents ☐ | SecurityAlert ☐ | Device* tables ☐

Prerequisite 2 — Detection rules: Active analytics rules: _____ | Rules with ATT&CK mapping: _____ | Minimum met (20+)? ☐

Prerequisite 3 — KQL proficiency: Analyst can write joins, aggregations, time functions? ☐ | Mastering KQL completed or equivalent? ☐

Prerequisite 4 — IR process: Containment actions defined? ☐ | Escalation path known? ☐ | Documentation process exists? ☐

Prerequisite 5 — Protected time: 4+ hours/week available? ☐ | Off alert queue during hunting? ☐

Assessment: All met → begin with TH1. Gaps identified → address before hunting. Record date of assessment: _____

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)

Decision point

You have time for one hunt this quarter. Do you hunt for the threat in the latest advisory or for the gap in your ATT&CK coverage matrix?

Hunt the coverage gap. Advisories describe threats that are CURRENT but may not target NE. Coverage gaps describe techniques that COULD target NE and would succeed undetected. The coverage gap hunt produces a detection rule (closing the gap permanently). The advisory-driven hunt produces a point-in-time assessment (confirming the specific threat is not present today). Both are valuable — but the coverage gap hunt has a longer-lasting impact because it produces a permanent detection improvement.

A hunt query returns 200 results. You have 4 hours remaining in the hunt window. You can investigate 20 results thoroughly or review all 200 superficially. Which approach produces better hunt outcomes?

Review all 200 — you might miss a critical finding in the 180 you skip.

Investigate 20 thoroughly. A superficial review of 200 results produces 200 'looked at it, seemed okay' assessments that provide no investigative value and no documentation for future reference. A thorough investigation of 20 results produces: confirmed findings (true positives requiring remediation), confirmed benign patterns (documented baselines for future comparison), and inconclusive results (flagged for monitoring). Prioritise the 20 by: highest anomaly score, highest-value assets involved, and highest-risk users involved. Document why the remaining 180 were not investigated and recommend a follow-up hunt with refined query criteria to reduce the result set.

Investigate 20 — but only if they are from the most recent 24 hours.

Neither — refine the query first to reduce the result set below 50.

You understand the detection gap and the hunt cycle.

TH0 showed you what detection rules fundamentally cannot catch. TH1 gave you the hypothesis-driven methodology that closes that gap. Now you run the hunts.

10 complete hunt campaigns — from hypothesis through KQL execution through finding disposition, each campaign based on a real TTP
70 production hunt queries — every one mapped to MITRE ATT&CK and tested against realistic telemetry
Advanced KQL for hunting — UEBA composite risk scoring, retroactive IOC sweeps, and hunt management metrics
Hypothesis-Driven Hunt Toolkit lab pack — 30 days of realistic M365 and endpoint telemetry with multiple attack patterns seeded in
TH16 — Scaling hunts across a team — the operating model for a production hunt program

Unlock the full course with Premium See Full Syllabus

← Previous Next →