Lesson 13 — Advanced Hunting in Defender for Endpoint

Learning objectives

After completing this lesson, you should be able to use Advanced Hunting to investigate endpoint activity with KQL.

• Explain what Advanced Hunting is.
• Build a clear hunting hypothesis.
• Choose the correct endpoint telemetry table.
• Filter, project, summarise and join data.
• Pivot from hunting results into a wider investigation.

The problem this solves

Automated detections cannot answer every security question.

Advanced Hunting lets analysts search the raw telemetry directly and investigate behaviour that may never generate an alert.

Why hunt?

Alerts are based on predefined detections and analytics.

Hunting allows analysts to ask new questions, test assumptions and search for weak signals before an alert exists.

Start with a hypothesis

A hypothesis is a testable security question.

For example: Has any Office application launched PowerShell in the last seven days?

Avoid random searching

Searching without a question often creates noise rather than insight.

A focused hypothesis helps determine the table, timeframe, fields and pivots required.

Choose the right table

Each endpoint table answers a different type of question.

Select the table that best matches the behaviour you are investigating.

Timeframe first

Always define a sensible timeframe early in the query.

This improves performance, reduces noise and keeps the hunt aligned with the investigation window.

Filter early

Use where statements as early as possible.

Filtering early reduces the volume of records processed by later operators.

Line 1: choose the table

DeviceProcessEvents tells Advanced Hunting to search process execution telemetry.

The first line establishes the data source for the hunt.

Line 2: set the timeframe

Timestamp > ago(24h) limits the results to the last twenty-four hours.

Adjust the period to match the hypothesis and available data retention.

Line 3: filter the process

The case-insensitive equals operator matches powershell.exe regardless of letter casing.

This query is intentionally simple and provides a clean starting point.

contains

contains searches for a value anywhere within a string.

It is useful for command-line arguments, URLs and partial paths.

startswith and endswith

These operators test how a string begins or ends.

They are useful for folder paths, file extensions and command prefixes.

in

in allows several values to be tested in one expression.

It is useful when searching for multiple binaries, ports, action types or filenames.

project

project selects and orders the columns returned.

Use it to remove noise and keep only the fields required for analysis.

project-away

project-away removes unwanted columns while preserving the rest.

This is useful when only a few fields create clutter.

sort and top

sort orders results, while top returns the highest-ranked records.

Use them to identify the newest, largest or most frequent activity.

summarize

summarize groups records and calculates counts or other aggregations.

It can reveal rare processes, active devices or repeated destinations.

Rare process hunting

Rare activity can be more interesting than common activity.

Summarise process counts and prioritise binaries seen on very few devices.

Suspicious parent processes

Hunt for Office applications, browsers or document readers launching script engines and command shells.

The parent-child relationship often exposes attacker execution chains.

Encoded commands

Search command lines for encoded PowerShell arguments or obfuscation patterns.

Encoding is not proof of maliciousness, but it increases the need for review.

Living-off-the-land binaries

Search for unusual use of rundll32, mshta, regsvr32, certutil, bitsadmin, wscript and cscript.

Context matters more than the executable name alone.

Suspicious download activity

Use DeviceNetworkEvents and DeviceFileEvents to connect remote destinations with files written to disk.

Then confirm whether the downloaded file executed.

Registry persistence hunts

Search DeviceRegistryEvents for run keys, service changes and other startup locations.

Pivot to the referenced file and initiating process.

Logon hunts

Search DeviceLogonEvents for unusual remote interactive, network or service logons.

Correlate the source device, account and processes that followed.

DeviceEvents hunts

Use ActionType to search for USB, SmartScreen, antivirus, ASR and device-control activity.

Parse AdditionalFields when event-specific details are required.

Why joins matter

A join combines records from different tables using shared values.

This is useful when one table contains execution and another contains communication or file evidence.

Choose join keys carefully

Device identifiers, process identifiers, timestamps, hashes and filenames can support correlation.

A weak key can create false matches or miss the correct relationship.

Time-aware correlation

Events should occur within a reasonable time window.

Use timestamps to avoid joining unrelated activity from different executions.

Start without a join

Joins can be expensive and difficult to troubleshoot.

Validate each side of the investigation separately before combining tables.

Use let statements

let creates reusable variables or subqueries.

It improves readability when the same dataset or timeframe is used more than once.

Use comments

Comments document the hypothesis, assumptions and purpose of each section.

Clear comments make queries easier to review and reuse.

Pivot from results

A hunting result is usually the beginning of a deeper investigation.

Open the device, user, alert, incident, file, IP address or domain associated with the record.

Validate with the timeline

The Device Timeline provides a chronological view of surrounding activity.

Use it to confirm that the KQL result fits the expected sequence.

Search across the organisation

Once suspicious behaviour is confirmed, broaden the search.

Look for the same hash, command line, destination, registry path or account across other devices.

Document findings

Record the hypothesis, query, timeframe, results, pivots and conclusion.

Good documentation supports handover, reporting and future detection engineering.

Save useful queries

Queries that answer repeatable security questions should be saved and maintained.

Review them when schemas, threats or business environments change.

From hunt to detection

A reliable hunting query may become a custom detection rule.

Validate noise, frequency, business impact and response requirements before operationalising it.

Common mistake

A common mistake is querying everything without a timeframe or hypothesis.

This produces noise, slow queries and results that are difficult to interpret.

Another common mistake

Do not stop at the first matching record.

Validate the process, user, device, timeline and related telemetry before reaching a conclusion.

Best practices

• Begin with a clear hypothesis.
• Set a realistic timeframe.
• Filter early and project only useful fields.
• Validate each table before joining.
• Pivot into timelines, incidents and related entities.
• Document and save repeatable hunts.

Agent Foskett takeaway

Advanced Hunting transforms Defender for Endpoint from a detection platform into an investigation platform.

When analysts understand the telemetry, KQL allows them to test hypotheses, connect evidence and uncover behaviour that automated detections may never surface.