Part of Defend, in progress — Threat Intel and Security are now part of Defend, not separate products. This area is still being built: some screens, menu names and actions described here may not be available yet, or may still show the older Threat Intel or Security names.
Not available today: KQL queries and KQL rules ran against an event store that is now stopped, and hunting is retired on the current build. You may see these screens, but they don't return results today. Sigma and behavioral rules are described as designed.
Threat hunting lets you run ad-hoc queries against the normalized event store to look for activity that detection rules may not have flagged. Use it for proactive investigations, historical lookups, and confirming or ruling out indicators of compromise across your fleet.
The threat hunt interface accepts natural-language questions or direct KQL queries, and returns timestamped results with device and event context.
Running a Query
- Go to Defend and open Threat Hunt.
- Choose your input mode:
- Natural language — type a question in plain English. For example: "show me PowerShell executions on servers in the last 24 hours" or "find outbound connections to IP addresses in Russia."
- KQL — paste or type a Kusto Query Language query directly against the normalized event tables.
- Set the time range. The default is the last 24 hours. Adjust as needed for historical investigations.
- Click Run.
- Results return with timestamps, device names, event types, and a drill-down link for each row.
Natural Language to KQL
When you submit a natural-language query, Defend translates it into a KQL query before execution. You can view the generated KQL in the results panel. Review it to confirm the translation captured your intent — if it did not, switch to KQL mode and edit the query directly.
Available Event Data
Threat hunting queries run against normalized events ingested through active connectors and endpoint agents. Available data depends on which connectors are configured and active:
- Endpoint events — process executions, network connections, file operations (from RMM agents)
- M365 events — sign-ins, audit actions, mailbox activity (from M365 connector)
- Google Workspace events — admin actions, login events (from Google connector)
- Azure events — Entra ID sign-ins and audit logs, Azure activity (from Azure connector)
If a query returns no results, confirm that the relevant connectors are syncing and that the time window covers the period you are investigating.
Saving a Query
- After running a query that returns useful results, click Save Query.
- Give it a name and optional description.
- Saved queries appear in the Saved Queries list and can be re-run at any time.
Scheduled Hunts
Saved queries can be promoted to scheduled hunts that run on a recurring cadence:
- Open a saved query.
- Click Schedule.
- Set the interval (daily, weekly, or a custom cron expression).
- Specify what to do when results are found: generate an alert, send a notification, or both.
- Save the schedule.
Scheduled hunts let you codify proactive detection logic that does not fit neatly into a rule — for example, a weekly review of admin account usage across all tenants.
Attack Chain and MITRE Map
The Attack Chain view in the advanced section assembles observed events into an attack storyline mapped to MITRE ATT&CK stages. Use it to visualize whether activity spans multiple tactics (Initial Access → Execution → Exfiltration) and to identify gaps in the observed chain.
The MITRE Map shows coverage across your fleet for the last 30 days — which techniques have been observed, which have detection rules, and which have neither.
FAQ
Can I hunt across multiple client orgs at once? No. Threat hunt queries are scoped to a single org. Switch between orgs using the org selector and re-run your query for each one.
How far back can I query? Query range depends on event retention configured for your account. KQL queries are executed against the ADX event store; retention limits apply.
The natural-language query is returning unexpected results. What do I do? Review the generated KQL query shown in the results panel. Edit it directly in KQL mode to tighten the conditions. If a field name is wrong, consult the connector documentation for the correct normalized field names.