Agent Foskett Academy • Lesson 4 • Filtering KQL Results

Filtering KQL Results

Filtering is where KQL starts becoming powerful.

A table may contain thousands, millions or even billions of events. The investigator's job is not to stare at everything. The job is to narrow the data until the important activity becomes visible.

In this lesson, you will learn how to use common KQL filters such as where, contains, has, == and time filtering to reduce noise inside Microsoft Defender XDR and Microsoft Sentinel.

The goal is simple:

Start broad. Filter carefully. Follow the evidence.

Agent Foskett Academy lesson explaining how to filter KQL results
Lesson overview

Learn how to use common KQL filters to reduce noise, focus investigations and find the events that matter.

Plain-English filtering introduction
where, contains, has and ==
Filtering telemetry during investigations
🧠 Filtering is how investigators reduce the noise.
Dashboards show summaries. KQL filters help defenders focus on the specific users, devices, domains, timestamps and events that matter.
View KQL Hunting Guide →

Why filtering matters

Microsoft security telemetry can be extremely noisy. A single tenant may generate thousands of sign-ins, email events, URL clicks and endpoint events every day. Filtering helps you narrow the data to the activity you actually need to investigate.
Reduce the noise Filters help you remove irrelevant events and focus on the activity connected to the investigation.
Find patterns faster Filtering by user, sender domain, timestamp, device name or URL can make suspicious patterns easier to see.
Ask better questions Good filtering turns a broad query into a focused investigation question.

The where operator

The where operator is one of the most important parts of KQL. It keeps rows that match a condition and removes rows that do not.
where-filter-example.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
EmailEvents
| where Timestamp > ago(24h)
| take 20
Plain-English translation:

Show me email events from the last 24 hours, then return 20 rows.

Filtering by time

Time filtering is usually one of the first filters defenders apply. It prevents the query from searching too much history and helps focus the investigation window.
Last 24 hours Useful when investigating recent alerts, user reports or suspicious activity that happened today.
Last 7 days Useful when checking whether suspicious behaviour has repeated over the last week.
Custom timeframe Useful when an incident has a known start time, such as a reported phishing email or suspicious sign-in.
time-filtering.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
SigninLogs
| where TimeGenerated > ago(7d)
| take 50

Using == for exact matches

Use == when you want an exact match. This is useful when you know the precise value you are looking for, such as a sender domain, user principal name, device name or application.
exact-match-example.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
EmailEvents
| where SenderFromDomain == "paypal.com"
| take 20
Plain-English translation:

Show me email events where the sender domain is exactly paypal.com.

Using contains for partial matches

Use contains when you want to search for text inside a larger value. This is useful for subject lines, URLs, file names, command lines and fields where the exact full value may not be known.
contains-example.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
EmailEvents
| where Subject contains "invoice"
| take 20
Plain-English translation:

Show me email events where the subject contains the word invoice.

Using has for word-based matching

Use has when you want to match a whole term rather than any partial text. It can be useful when you want cleaner word-based matching inside fields such as subjects, command lines or URLs.
has-example.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| take 20
Plain-English translation:

Show me device process events where the command line includes the term powershell.

Combining multiple filters

Real investigations often use more than one filter. You may filter by time first, then by user, sender, domain, device or action.
combined-filters.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
EmailEvents
| where Timestamp > ago(24h)
| where Subject contains "invoice"
| where DeliveryAction == "Delivered"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction
Plain-English translation:

Show me delivered email from the last 24 hours where the subject contains invoice, then only show the columns I care about.

Filtering mistakes beginners make

Filtering is powerful, but it is easy to filter too narrowly or too broadly. Good investigators test their assumptions as they build the query.
Filtering too narrowly If you use an exact match too early, you may accidentally hide useful evidence that uses a slightly different value.
Forgetting the time window Without a time filter, the query may return too much data or take longer than needed.
Assuming one query is enough Investigations usually require several small queries, each asking a better question than the last.

Investigator mindset

Filters should not be random. Every filter should represent an investigation decision.
What am I trying to remove? Use filters to remove noise that does not help the investigation.
What am I trying to prove? Use filters to test a suspicion, such as whether a user clicked a link or whether an email was delivered.
What should I check next? Use the results of one filtered query to decide the next pivot.
The logs already know the story.
Filtering helps defenders uncover that story one question at a time.
Continue Learning

What you learned

In this lesson, you learned how filtering helps defenders reduce noise and focus on useful evidence inside Microsoft security telemetry.
where filters rows The where operator keeps only the events that match your investigation condition.
Time filters focus the window Filtering by time helps keep investigations focused, fast and relevant.
Different filters answer different questions Use == for exact matches, contains for partial text and has for term-based matching.

Next lesson coming soon

The next Agent Foskett Academy lesson will build on filtering and show how to choose useful columns with project, so your results show only the evidence that matters.
Lesson 5 — Choosing Useful Columns Learn how project helps investigators remove clutter and focus on the fields that matter most.
Keep building the investigation After filtering results, the next step is deciding which fields help explain what happened.

Continue learning with Agent Foskett Academy, Microsoft Defender KQL Threat Hunting Guide, EmailEvents KQL Guide, KQL Email Spoofing, Microsoft Security and the GEMXIT Security Review.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD

Filtering KQL Results

Agent Foskett Academy Lesson 4 teaches defenders how to filter KQL results using where, contains, has, exact matches and time filtering inside Microsoft Defender XDR and Microsoft Sentinel.

Learn KQL Filtering for Microsoft Defender XDR

KQL filters help defenders reduce noisy telemetry, focus on suspicious users, domains, devices, URLs and events, and follow evidence across Microsoft security investigations.

KQL for Security Investigations

Filtering KQL results helps defenders investigate EmailEvents, UrlClickEvents, DeviceProcessEvents, DeviceNetworkEvents, SigninLogs, AuditLogs, suspicious sign-ins, DMARC failures, phishing emails, endpoint behaviour and Microsoft security telemetry.