Lesson 23 — Hunting in Microsoft Sentinel
Microsoft Sentinel extends threat hunting beyond product-specific security telemetry into workspace data collected from Microsoft services, cloud platforms, networks, Linux systems and third-party technologies.
Security Copilot can generate and run Sentinel KQL hunting queries, while hunts, bookmarks, entities, UEBA, watchlists, ASIM and threat intelligence help analysts organise and preserve their investigation.
This lesson explains how to build Sentinel hunting hypotheses, understand workspace coverage and validate findings across the entire organisation.
What you will learn
This lesson develops a complete workspace-based Microsoft Sentinel hunting workflow.
Microsoft Sentinel hunting workflow
↓
Select the correct Sentinel workspace
↓
Confirm connectors, tables, retention and ingestion health
↓
Start a hunt and select built-in or custom queries
↓
Use Security Copilot to generate or refine Sentinel KQL
↓
Run a narrow test and inspect raw results
↓
Pivot through Microsoft, network, Linux and third-party data
↓
Add watchlist, ASIM, UEBA and threat-intelligence context
↓
Bookmark relevant evidence and map entities
↓
Look for benign explanations and visibility gaps
↓
Escalate validated findings or improve analytics
Sentinel hunting domains
| Domain | Evidence | Hunting question |
|---|---|---|
| Workspace | Connected sources, tables, retention, tiers and permissions. | What evidence can this workspace actually provide? |
| Microsoft data | Entra, Azure, Microsoft 365 and connected Defender telemetry. | What did Microsoft services observe? |
| Network and systems | Firewall, VPN, DNS, proxy, Windows and Linux events. | What happened outside product-specific security tools? |
| Context | Watchlists, ASIM, UEBA, anomalies and threat intelligence. | How should the raw events be interpreted? |
| Hunt evidence | Queries, bookmarks, entities, comments and saved results. | Can another analyst reproduce the finding? |
| Outcome | Confirmed findings, negative results, incidents and analytics. | What did the hunt prove and what happens next? |
Learning objectives
- Build Sentinel hunting hypotheses.
- Validate workspace and connector coverage.
- Use Security Copilot for Sentinel KQL.
- Investigate Microsoft and third-party logs.
- Use bookmarks, entities, UEBA and watchlists.
- Apply ASIM and threat-intelligence context.
- Escalate reproducible findings safely.
What is Sentinel hunting?
Microsoft Sentinel hunting is the proactive search for suspicious behaviour across data collected into a Sentinel workspace.
Sentinel versus Defender XDR
Defender XDR provides deep Microsoft security telemetry, while Sentinel can combine Microsoft, cloud, network, Linux, identity and third-party data.
Workspace-based hunting
Sentinel hunting depends on the data, retention, tables, permissions and configuration of the selected workspace.
Define the hypothesis
State the suspected behaviour, affected entities, expected data sources and what would confirm or disprove the theory.
Choose the correct workspace
Confirm that the selected workspace contains the required logs and represents the intended environment.
Connected workspace in Defender
Sentinel workspaces onboarded to the Defender portal can expose Sentinel data in unified advanced hunting.
Know your data connectors
A hunting query cannot find evidence from a source that is not connected or actively ingesting data.
Check ingestion health
Confirm recent records, connector status and table freshness before interpreting empty results.
Understand data tiers
Analytics, Basic and other data tiers can affect query features, cost, retention and hunting availability.
Review retention
The investigation window must fit the available retention for each table.
Use built-in hunting queries
Microsoft and content solutions provide hunting queries that can accelerate hypothesis testing.
Use custom hunting queries
Analysts can create and save queries tailored to their environment, assets and threat model.
Start a hunt
Use Sentinel hunts to organise queries, bookmarks, comments, findings and collaboration around one hypothesis.
Use multiple query tabs
Separate queries can preserve context for different evidence sources during a hunt.
Use Security Copilot
The Natural language to KQL for Microsoft Sentinel plugin can generate and run KQL hunting queries against Sentinel data.
Standalone and Defender experiences
The Sentinel plugin can be available in standalone Security Copilot and advanced hunting in the Microsoft Defender portal.
Generated query needs validation
Copilot can select the wrong table, field, workspace, time range or assumption.
Specify the workspace context
Tell Copilot which environment and data sources the hunt is expected to use.
Specify the time range
Use explicit start and end times and account for delayed ingestion.
Specify expected tables
Name likely tables when you understand the environment, while allowing Copilot to suggest alternatives.
Explore the schema
Review table names, columns, types and recent sample rows before developing complex logic.
Custom tables
Third-party or custom connectors can use organisation-specific table names and schemas.
CommonSecurityLog
Use CommonSecurityLog for supported CEF-based security appliance telemetry where applicable.
Syslog
Use Syslog for Linux and network-device operating-system events where collected.
SecurityEvent
Use SecurityEvent for Windows security events collected through supported agents and connectors.
SigninLogs
Use SigninLogs for Microsoft Entra interactive sign-in evidence where available.
AuditLogs
Use AuditLogs for Microsoft Entra directory changes and administrative activity.
AzureActivity
Use AzureActivity for subscription-level control-plane operations and resource management changes.
OfficeActivity
Use OfficeActivity for supported Microsoft 365 audit activity where ingested.
CloudAppEvents
Use CloudAppEvents when supported Defender cloud-app data is available through the unified experience.
Device tables
Connected Defender XDR data can extend hunts into endpoint processes, files, network and logon evidence.
Threat-intelligence tables
Use the threat-intelligence schema available in the specific workspace and integration.
ThreatIntelligenceIndicator
Some Sentinel environments use ThreatIntelligenceIndicator for threat-indicator records.
ThreatIntelIndicators
Newer integrations can populate ThreatIntelIndicators, so analysts must verify the active schema.
Watchlists
Watchlists add reference data such as VIP users, sensitive systems, approved infrastructure or known exceptions.
Watchlist quality
Outdated or incomplete watchlists can create misleading hunt results.
ASIM
The Advanced Security Information Model normalises supported source data into common security schemas.
ASIM parsers
Use source-agnostic parsers to hunt across compatible products without rewriting every query.
Validate parser coverage
Not every connector or event type is represented by every ASIM parser.
UEBA
User and Entity Behavior Analytics can provide behavioural context, anomalies and entity relationships.
Behaviors layer
The Sentinel UEBA behaviors layer can summarise supported telemetry into behavioural patterns.
BehaviorInfo
Use BehaviorInfo to review behavioural summaries and their source context.
BehaviorEntities
Use BehaviorEntities to connect behaviours with associated users, devices, IPs and other entities.
Anomalies
Anomalies can guide a hypothesis but are not proof of malicious activity.
Bookmarks
Bookmarks preserve relevant query results, entities, notes and context during hunting.
Bookmark source evidence
A bookmark should retain enough information for another analyst to understand why the record mattered.
Add bookmarks to incidents
Validated bookmarks can be associated with incidents to preserve hunting evidence.
Entity mapping
Map users, hosts, IP addresses, accounts, URLs and other entities so findings can be investigated consistently.
Entity identifiers
Use stable identifiers and source fields rather than display names alone.
Use comments
Record decisions, rejected explanations, next queries and analyst ownership.
Collaborative hunting
Hunts should be reproducible by another analyst using saved queries, bookmarks and notes.
Cross-workspace hunting
Use supported cross-workspace queries when evidence spans several Sentinel workspaces.
Cross-tenant considerations
Cross-tenant hunting requires deliberate permissions, context and data governance.
Cross-resource queries
Azure Monitor query capabilities can combine approved resources and workspaces where supported.
Query cost awareness
Broad Sentinel queries can scan large data volumes and increase cost or latency.
Filter early
Apply time, entity, table and environment filters before expensive parsing and joins.
Project required fields
Return only fields necessary for the hunt and evidence review.
Use summarize carefully
Aggregations reveal patterns but can hide the raw events needed for validation.
Use joins cautiously
Joins across broad Sentinel tables can multiply rows and imply false relationships.
Use stable join keys
Prefer immutable user, host, message, alert and resource identifiers.
Use union for broad discovery
Union can search compatible tables but does not prove that returned records belong to one incident.
Parse vendor fields
Custom and third-party logs often require extraction from dynamic, extension or message fields.
Inspect raw vendor events
Understand the source format before trusting parsed values.
VPN hunting
Use VPN authentication, session, source IP and device evidence to investigate remote access.
Firewall hunting
Use network rule, source, destination, action and application context to investigate traffic.
DNS hunting
Use DNS requests and responses to find suspicious domains, beaconing and infrastructure pivots.
Proxy hunting
Use web proxy records to investigate user, device, URL, category, action and bytes transferred.
Linux hunting
Use Syslog and authentication records to investigate SSH, privilege use, persistence and command activity.
Azure control-plane hunting
Use AzureActivity and related logs to investigate deployments, permissions and configuration changes.
Microsoft 365 hunting
Use available audit and Defender evidence to investigate mailbox, SharePoint, OneDrive and Teams activity.
Third-party hunting
Sentinel can include EDR, firewall, IAM, SaaS, OT and appliance telemetry beyond Microsoft products.
Threat-intelligence enrichment
Compare internal observations with current, relevant and confidence-rated intelligence.
Hunt before and after alerts
Search outside the incident window for precursor activity and follow-on behaviour.
Disprove the hypothesis
Look for expected administration, scanner traffic, maintenance and benign explanations.
Document no evidence found
Negative findings require a documented time range, tables searched and visibility limits.
Escalate findings
Create or expand an incident only when evidence, entities, timestamps and confidence support escalation.
Convert hunts to analytics
Validated recurring behaviours can become scheduled analytics after tuning and entity mapping.
Use automation carefully
Playbooks can assist response after a finding, but automation needs approved triggers and controls.
Measure hunt outcomes
Record confirmed findings, detections improved, gaps discovered and time required.
Final analyst validation
Security Copilot and Sentinel organise the hunt, but the analyst decides what the evidence proves.
Example Sentinel hunting prompt
Use available Entra, VPN, firewall, DNS, proxy, Azure activity, Microsoft 365 and Linux authentication data.
Include:
1. Workspaces and tables searched
2. Sign-ins, VPN sessions and source IP addresses
3. Firewall and proxy activity
4. DNS requests and destination domains
5. Azure control-plane changes
6. Linux or SSH authentication activity
7. Watchlist, UEBA and threat-intelligence context
8. Confirmed, probable, possible and unsupported findings
9. Missing connectors, stale tables and retention limits
10. Bookmark recommendations and escalation criteria
Do not infer compromise from an anomaly or shared IP address alone.
Agent Foskett investigation: “The answer wasn’t in Defender…”
↓
Endpoint, email and cloud-app evidence appeared clean
↓
The incident was close to being dismissed
↓
Agent Foskett expanded the hunt into Microsoft Sentinel
↓
VPN logs showed a remote session from an unusual source
↓
Firewall logs recorded access to an internal Linux server
↓
Linux authentication logs showed a successful SSH login
↓
DNS logs revealed repeated queries to a newly observed domain
↓
Proxy logs showed outbound traffic from the server
↓
AzureActivity recorded a network-rule change by the same identity
↓
None of those events existed in the original Defender incident
↓
Bookmarks preserved the supporting evidence
↓
The identity alert became the first clue in a cross-platform compromise
↓
Defender had not missed its own data
↓
The rest of the organisation’s story was in Sentinel
Sentinel hunting validation checklist
| Area | Question | Validation action |
|---|---|---|
| Workspace | Is the correct workspace selected? | Confirm tenant, subscription and environment. |
| Connector | Is the required source connected and healthy? | Check recent ingestion and connector status. |
| Table | Does the table contain the expected data? | Inspect schema and recent rows. |
| Retention | Does the requested period still exist? | Confirm table retention and tier. |
| Query | Are fields, parsing and joins valid? | Test narrowly and inspect raw events. |
| Context | Are watchlists, UEBA and TI current? | Review freshness and provenance. |
| Entity | Are stable identifiers mapped? | Validate account, host, IP and resource fields. |
| Bookmark | Can another analyst understand the finding? | Add notes, tags, query and source context. |
| Alternative | Could maintenance or expected activity explain it? | Check change records and baselines. |
| Escalation | Is the evidence sufficient for an incident or rule? | Record scope, confidence and limitations. |
Key takeaways
- Microsoft Sentinel is a cloud-native SIEM that supports proactive hunting across multicloud and multiplatform data.
- Sentinel hunts organise hypotheses, queries, bookmarks, comments and findings.
- Security Copilot can generate and run KQL hunting queries using Sentinel data in supported experiences.
- Workspace selection, connectors, ingestion health and retention determine hunt coverage.
- Bookmarks preserve relevant query results, entities, notes and context for collaboration.
- UEBA behaviours, watchlists, ASIM and threat intelligence add context but still require validation.
- Sentinel can expose network, Linux, Azure and third-party evidence that is not present in a Defender incident.
- Broad queries, custom parsing and joins require cost and accuracy review.
- Negative findings are meaningful only when searched data and visibility limits are documented.
- The final Sentinel hunting conclusion remains a human analyst decision.
What Agent Foskett checked
- Sentinel workspace
- VPN logs
- Firewall events
- Linux authentication
- DNS requests
- Proxy activity
- AzureActivity
- Identity mapping
- Bookmarks
- Final incident scope
Best practices
- Confirm the workspace.
- Check connector health.
- Inspect table freshness.
- Start with a hypothesis.
- Use narrow queries.
- Bookmark evidence.
- Validate contextual data.
- Document missing sources.
- Escalate reproducibly.
- Tune before automating.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How do you hunt in Microsoft Sentinel with Security Copilot?
Security Copilot can generate and run Microsoft Sentinel KQL hunting queries using natural-language prompts in supported standalone and Defender advanced-hunting experiences.
Microsoft Sentinel hunts and bookmarks
Sentinel hunts organise hypotheses, queries, bookmarks, comments and findings, while bookmarks preserve relevant results, entities and analyst context.
Sentinel hunting across third-party data
Microsoft Sentinel can combine Microsoft, Azure, network, Linux, cloud and third-party logs so analysts can investigate evidence beyond product-specific Defender telemetry.
