kql-core

KQL Core: Filter First

Learn to isolate signal early so every later stage is faster, cleaner, and more accurate.

Duration: 18 minutes | Level: Beginner

Step 1: Learning Outcomes

What you should be able to do after this module.

Write strict `where` filters that reduce noise without dropping critical evidence.
Choose evidence fields that support triage decisions.
Explain why early filtering improves both speed and correctness.

Step 2: Core Concepts

Read each concept and tick when understood.

Start NarrowYour first stage should shrink the dataset as much as possible with deterministic predicates.auth_events | where Action == "LoginFailed"Field PrecisionPrefer explicit field conditions over broad keyword matching to prevent false positives.where User startswith "admin" and Location != "TrustedHQ"Evidence SelectionOnly project fields analysts need for action: actor, source, time, and severity context.project Timestamp, User, SrcIp, Device, Location

Step 3: Worked Example

SOC sees a login-failure spike and needs the top suspicious sources within minutes.

Filter failures only.
Group by source and count failures.
Sort descending and keep top rows.
Project only triage evidence fields.

auth_events | where Action == "LoginFailed" | summarize Failed=count() by SrcIp | sort by Failed desc | limit 10

Step 4: Common Mistakes

Aggregating before filtering, which mixes unrelated events.
Using contains when exact equality is available.
Returning too many fields, making triage slower.

Step 5: Checkpoint Quiz

What should usually come immediately after table selection in KQL hunting?

whereprojectsummarize

Step 6: Practice Labs

Apply the theory immediately in these mapped labs.

Filter only failed auth events.
Return just high-signal triage fields.

Launch Lab 1 Launch Lab 12 Launch Lab 14

Back to Academy