Organizational Readiness and Data Sources

Five prerequisites for a sustainable program

Every prerequisite must be assessed honestly before committing analyst hours. Starting a hunting program without confirming readiness wastes the investment you just secured and damages the credibility of the next proposal.

Prerequisite 1: Sufficient data ingestion. Your Sentinel workspace must ingest the tables that hunting campaigns query. The minimum set for M365 hunting includes SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs, CloudAppEvents, and the DeviceEvents family if Defender for Endpoint is deployed. Run the data source audit query below to confirm which tables are actively receiving data. Any critical table that returns zero rows in the past 30 days is a gap that must be resolved before campaigns that depend on it.

// Data source audit — confirm which tables are actively ingested
Usage
| where TimeGenerated > ago(30d)
| where Quantity > 0
| summarize DailyGB = round(sum(Quantity) / 30, 2)
    by DataType
| sort by DailyGB desc

Prerequisite 2: Baseline detection rules. Your environment should have at least 20 active analytics rules before hunting begins. Hunting extends detection coverage. If the base layer is empty, the priority is detection engineering, not hunting. Twenty rules is not an arbitrary threshold. Below it, the organization lacks the foundational alerting that gives the SOC situational awareness. Hunting without baseline detection is like investigating without triage: you have no context for what your environment's normal alert patterns look like.

Prerequisite 3: KQL proficiency. The assigned hunter must write intermediate KQL: where, summarize, join, extend, and let statements without copying templates. They need to construct a multi-table join from a hypothesis without referencing documentation for basic syntax. The distinction matters. A hunter who spends 45 minutes of a 4-hour block looking up join syntax has lost 20% of the session to mechanics rather than investigation. Fluency with the query language is what allows the hunter to think about the hypothesis rather than the tool.

The proficiency threshold is not advanced. The hunter does not need to write custom parsers, build workbooks, or optimize query performance for large-scale analytics. They need to write a query that joins SigninLogs to AuditLogs on a user principal name within a time window, summarize the results by a meaningful field, and extend the output with derived columns. If the assigned hunter cannot write a summarize-by-count query from memory, invest in KQL proficiency first. The KQL for Security course (SEC201) provides this foundation.

Prerequisite 4: Incident response process. When a hunt discovers an active compromise, the finding must become an incident immediately. If no IR process exists, the discovery has no operational path to containment. Hunting without IR is like diagnosing without treating. The IR process does not need to be mature. It needs to exist: a defined escalation path, an incident lead, and a containment playbook. When Priya discovers an active OAuth compromise during a hunt, she needs to hand that finding to someone who can revoke the application's credentials, notify affected users, and begin scoping the incident. If that handoff path does not exist, the discovery sits in a document while the attacker continues operating.

Prerequisite 5: Protected time. This is the prerequisite that kills the most programs. Four hours per week, blocked on the calendar, defended from alert triage overflow. "Hunt when the queue is quiet" is not protected time. It is a guarantee the program never launches, because the queue is never quiet for four consecutive hours. The alert queue expands to fill all available analyst time. Without explicit protection, hunting hours are consumed by triage every single week.

Rachel blocks Priya's Wednesday mornings for 12 weeks. The calendar entry says "Hunting: do not schedule." If an incident requires Priya on Wednesday morning, the hunting hours move to Thursday, not to "next week." The discipline of rescheduling rather than canceling is what separates programs that survive their first quarter from programs that quietly stop producing output by Week 6.

Three data clusters map to specific attack planes and campaign modules. Missing any table in a cluster creates a gap the attacker can exploit without generating a queryable record.

Three data clusters for M365 hunting

Your M365 environment produces telemetry across three clusters. Each cluster maps to specific attack planes and campaign modules.

The identity cluster contains the tables that record authentication, authorization, and identity configuration changes. This is the most important cluster for M365 hunting because the majority of M365 attacks begin with identity compromise.

SigninLogs records every interactive sign-in: the user's IP address, device information, geographic location, conditional access policy evaluation results, MFA method used, risk level, and authentication protocol. This is the table you query first when investigating a compromised account. Every campaign that involves identity starts here.

AADNonInteractiveUserSignInLogs is the most critical and most commonly missing table. It records token refreshes, application-based authentication, and the non-interactive flows where AiTM token replay appears. When an attacker steals a session token and uses it to obtain new access tokens, the refresh events appear in this table, not in SigninLogs. Without it, the primary AiTM detection hypothesis (token refreshes from IPs not matching interactive sign-in history) has no data to query.

AADServicePrincipalSignInLogs records application-level authentication: service principals, managed identities, and automated workflows authenticating to Entra ID. When an attacker adds a credential to an existing service principal (T1098.001), the subsequent authentication appears here. Many organizations do not ingest this table because their SOC does not monitor non-human identity.

AuditLogs records directory changes: MFA method registration, role assignments, conditional access policy modifications, application consent grants, group membership changes, and administrative actions. This is the persistence detection table. Every post-compromise action that modifies the identity infrastructure produces a record here.

These four tables are the primary data sources for TH4 (identity compromise), TH5 (cloud persistence), and TH6 (application compromise).

The collaboration cluster contains the tables that record email, file sharing, application usage, and API activity.

CloudAppEvents captures OAuth consent events, inbox rule creation via Graph API, file sharing actions, and SaaS application activity through Defender for Cloud Apps. This is where inbox rule manipulation via Graph API (T1564.008) appears, and it is the only table that records consent phishing events with the application permissions granted. If your detection rules for inbox rule creation only monitor Exchange admin audit logs, they miss the Graph API path entirely.

EmailEvents and EmailUrlInfo record email delivery, link clicks, and attachment analysis. These are the starting point for phishing campaign investigation and the data source for TH7 (email-based threats).

MicrosoftGraphActivityLogs, introduced in 2024, records every Graph API call: mailbox access, directory enumeration, file operations, and user profile queries. When an attacker uses the Graph API to download an entire mailbox or enumerate organizational structure, this table records every call. Without it, API-based data exfiltration is invisible to Sentinel.

The endpoint cluster contains the tables generated by Defender for Endpoint on managed devices.

DeviceProcessEvents records every process execution: the parent process, command line arguments, file hash, and user context. This is the primary table for hunting living-off-the-land binary (LOLBin) abuse, PowerShell execution chains, and suspicious process trees. DeviceNetworkEvents records outbound and inbound network connections from each endpoint, which is essential for hunting command-and-control beaconing and data exfiltration over non-standard ports. DeviceFileEvents records file creation, modification, deletion, and rename events, which surfaces staging activity and payload drops. DeviceRegistryEvents records registry changes, which reveals persistence mechanisms like Run keys, scheduled tasks registered through the registry, and COM object hijacking. DeviceLogonEvents records local and remote authentication to each endpoint, which is the starting point for lateral movement hunting.

These five tables are the primary data sources for TH9 (endpoint persistence) and TH10 (lateral movement). Organizations without Defender for Endpoint will need to substitute with Sysmon data ingested through the SecurityEvent or Event table, though the field names and query patterns differ significantly.

Campaign-to-table mapping

Every hunt campaign in this course specifies its data source requirements in the hypothesis. Before running a campaign, verify the required tables are ingested by running the audit query above and checking for the specific table names.

The first three campaigns most organizations run map to the identity cluster. TH4 Campaign 1 (AiTM token replay detection) requires SigninLogs and AADNonInteractiveUserSignInLogs. TH5 Campaign 1 (unauthorized MFA registration) requires AuditLogs with a join to SigninLogs for temporal correlation. TH6 Campaign 1 (OAuth consent phishing) requires AuditLogs for consent events and CloudAppEvents for post-consent application behavior. If all three identity cluster tables are ingested, your first quarter of campaigns is viable.

Cross-plane campaigns are the most data-intensive. TH10 (lateral movement) joins SigninLogs, AzureActivity, IdentityLogonEvents, and DeviceLogonEvents in a single investigation. Missing any one of these tables leaves a gap in the lateral movement chain that the attacker can traverse without generating a queryable record. Confirm all required tables before committing analyst hours to a campaign.

The retention constraint

Default Sentinel retention is 90 days for most tables. Hunts that look for long-dwell-time intrusions, the ones causing the most damage, need data beyond 90 days. An attacker with 120 days of dwell time has evidence in the first 30 days that falls off the retention cliff before anyone looks.

Check your retention settings per table. In Sentinel, navigate to Settings, then Workspace settings, then Tables, and review the retention period for each hunting table. Critical hunting tables (SigninLogs, AuditLogs, AADNonInteractiveUserSignInLogs, CloudAppEvents) benefit from 180-day or 365-day retention. Basic log tier retention (at lower cost) is available for high-volume tables where you need long lookback but do not need real-time alerting.

The cost calculation is straightforward. Extended retention on SigninLogs at NE's volume (approximately 2 GB/day) costs roughly $180/month for 180-day retention versus $90/month for 90-day retention. The $90/month difference provides forensic evidence for the long-dwell-time intrusions that cause the most organizational damage. That is $1,080 per year to ensure that a 120-day intrusion leaves evidence you can still query when you discover it on Day 100.