Agent Foskett Academy • Microsoft Sentinel • Module 2 • Lesson 14

Lesson 14 — Microsoft Sentinel Hunting

Microsoft Sentinel Hunting allows analysts to search security data proactively instead of waiting for an alert or incident to be created.

A hunt begins with a question or hypothesis, uses KQL to test that idea and follows the evidence across users, devices, IP addresses, applications and timelines.

Strong hunting turns unknown activity into understood evidence and can lead to bookmarks, investigations, incidents and new analytics rules.

Great hunters do not wait for alerts. They ask questions of the data and follow the evidence.
Agent Foskett Microsoft Sentinel Hunting lesson
What you will learn

This lesson explains how analysts use Microsoft Sentinel Hunting to search proactively for suspicious activity.

What threat hunting is
How hypotheses guide hunts
How KQL and bookmarks are used
When to create a detection rule

Learning objectives

After completing this lesson, you should understand how Microsoft Sentinel supports proactive threat hunting.

  • Explain the difference between detection, investigation and hunting.
  • Build a hunting hypothesis.
  • Run and customise hunting queries.
  • Save evidence with bookmarks.
  • Convert repeatable findings into analytics rules.

The problem this solves

Automated detections only find activity they were designed to recognise. Hunting helps analysts search for unusual or emerging behaviour that has not yet generated an alert.

What is threat hunting?

Threat hunting is a proactive, analyst-led process used to search security telemetry for signs of compromise, suspicious behaviour or attacker techniques that may have bypassed existing detections.

Agent Foskett tip:

A hunt should begin with a clear question. “Show me everything unusual” is too broad. “Did any newly created administrator account sign in from an unfamiliar IP address?” is a testable hypothesis.

Hunting workflow

Form a hypothesis │ ▼ Choose relevant tables and time range │ ▼ Run and refine KQL │ ▼ Review users, devices, IPs and timelines │ ▼ Save evidence as bookmarks │ ├── Continue investigation ├── Create incident └── Build analytics rule │ ▼ Document findings and improve detection coverage

Detection vs investigation vs hunting

ActivityHow it startsPrimary purpose
DetectionAutomated analytics rule or Microsoft detectionIdentify known suspicious patterns and create alerts.
InvestigationAn alert, incident or reported concernDetermine what happened, scope impact and support response.
Threat huntingAn analyst hypothesis or emerging threatSearch proactively for evidence that existing detections may have missed.

Built-in hunting queries

Microsoft Sentinel provides hunting queries through installed solutions and content. Analysts can run them, review the underlying KQL and customise them for their own environment.

Custom hunting queries

Custom queries should reflect your organisation's identities, devices, applications, normal activity and known risks. A useful hunt is specific enough to test but flexible enough to reveal unexpected evidence.

Example hunting query

Recently created accounts with sign-in activity
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
let NewAccounts = IdentityDirectoryEvents
| where Timestamp > ago(7d)
| where ActionType has "Account created"
| project AccountUpn, AccountObjectId, CreatedTime = Timestamp;
SigninLogs
| where TimeGenerated > ago(7d)
| join kind=inner NewAccounts on $left.UserId == $right.AccountObjectId
| project TimeGenerated, AccountUpn, IPAddress,
          AppDisplayName, ResultType, CreatedTime

This query tests whether recently created accounts have already been used to sign in. The exact table schema and action names should be validated against the data available in your workspace.

Start broad, then narrow

Begin with enough data to understand the pattern, then reduce noise using time windows, account types, device context, geography, application names and known-good exclusions.

Pivot across tables

A suspicious sign-in may lead to email activity, endpoint execution, identity changes or cloud application access. Hunting often requires moving between tables to reconstruct the wider story.

Bookmarks

Bookmarks preserve important query results and analyst notes. They can capture entities, timestamps and evidence so findings can be revisited, shared or grouped into an investigation.

Entities and context

Mapped accounts, hosts, IP addresses and URLs help analysts pivot from a hunting result into related alerts, incidents, entity pages and historical activity.

Common hunting scenarios

ScenarioQuestion to test
Privileged accessWere any users unexpectedly added to an administrator role or group?
Suspicious PowerShellDid encoded, downloaded or unusual PowerShell commands execute?
Credential theftWere there abnormal sign-ins followed by mailbox, file or privilege activity?
BeaconingDid a device make repeated connections to the same rare destination?
PersistenceWere new accounts, scheduled tasks, services or OAuth applications created?
PhishingDid multiple users receive or interact with the same suspicious sender, URL or attachment?

Time range matters

A hunt can fail because the selected time range is too short or produce excessive noise because it is too long. Match the period to the behaviour being tested and the retention available.

Baselines matter

Unusual does not automatically mean malicious. Compare activity with normal patterns for the user, device, team, application and business process.

Validate findings

Confirm suspicious results using surrounding evidence. Check whether the account is expected, the device is managed, the IP belongs to a trusted service and the action matches legitimate administration.

Document the hunt

Record the hypothesis, data sources, query versions, time range, exclusions, findings and recommended detection improvements. Repeatability makes hunting valuable to the wider SOC.

From hunt to analytics rule

If a hunt reliably identifies risky behaviour and can be expressed with clear thresholds and low false-positive rates, convert it into a scheduled analytics rule. This turns analyst knowledge into repeatable detection coverage.

Agent Foskett tip:

The best outcome from a successful hunt is not just finding one threat. It is improving the environment so the same behaviour is detected automatically next time.

Common mistake

A common mistake is treating every unusual result as malicious. Hunting identifies leads. Analysts must validate context before escalating or taking disruptive action.

Agent Foskett takeaway

Threat hunting is structured curiosity. Form a hypothesis, ask focused questions of the data, preserve the evidence and turn repeatable discoveries into stronger detections.

Lesson summary
Microsoft Sentinel Hunting helps analysts search proactively for suspicious behaviour using hypotheses, KQL, bookmarks, entity pivots and repeatable investigation workflows. Strong hunts validate context and improve future detection coverage.
Sentinel Academy Home

Microsoft Sentinel Hunting

Microsoft Sentinel Hunting helps security analysts proactively search Log Analytics data for suspicious users, devices, IP addresses, processes, email activity and attacker behaviour using KQL.

Microsoft Sentinel Lesson 14

This Agent Foskett Microsoft Sentinel Academy lesson explains hunting hypotheses, built-in and custom hunting queries, bookmarks, entity pivots, validation and converting successful hunts into analytics rules.