0.5 How Hunts Are Practiced Here

Every lesson in this course is a hunt, and every hunt is written the same way. That consistency is deliberate. A hunter who knows where each part of a hunt sits can read any lesson quickly, compare one with another, and write their own hunts in a shape colleagues can follow. This lesson shows the shape and the practice tools that go with it, each working on ordinary data.

The shape follows the way hunting is done in Microsoft's own tooling. Sentinel's hunts let an analyst state a hypothesis, run queries, keep the rows that matter as bookmarks, which preserve "the specific row results, KQL query, and time range", and close the hunt when its actions are complete.

The course writes the same steps into every lesson, so that what you practice here is what you will do in a real workspace.

Two kinds of page make up the course. Lessons teach a technique through a hunt on Northgate's data, and end with a short practice and a check.

Labs hand you a case with less guidance and grade your queries by running them, and most end with a document you write, such as a hunt plan, a detection specification or the capstone's investigation portfolio, which you mark against acceptance criteria before opening a model answer.

Nothing in this lesson is a finding. The example hunt asks what starts Microsoft Word on Northgate's laptops, which has an ordinary answer, and the tools are shown on equally ordinary questions.

The brief is the first part of every lesson. It says why the hunt starts, the question it answers, the data it reads, the window and the platform. A reader who stops after the brief knows what the lesson is for; a reader who carries on knows what to look for in each step.

The figure lists the six parts in the order a lesson presents them. The first four are the hunt itself, written by the course. The last two are yours: a notebook in which you write the hunt's queries, and a set of questions on rows the lesson produced. The rest of this lesson takes each part in turn.

Each step names its move, states its query and shows the result the query returns on the course's data. A small hunt: every run of Word in the month, grouped by the process that started it.

DeviceProcessEvents
| where Timestamp >= datetime(2026-02-13 12:00)
    and Timestamp < datetime(2026-03-15 12:00)
| where FileName == "WINWORD.EXE"
| summarize Runs = count(), Devices = dcount(DeviceName)
    by Parent = InitiatingProcessFileName
| order by Runs desc

Two parent programs account for every single run of Word across the laptops in the month:

Parent        Runs  Devices
------------  ----  -------
explorer.exe  716   15
OUTLOOK.EXE   58    15

774 runs of Word in the month, started by two programs. explorer.exe started it 716 times: a person double-clicking a document or launching Word from the desktop. OUTLOOK.EXE started it 58 times: a person opening an attachment. Both on all 15 laptops. That is the whole picture of how Word starts at Northgate, and it is entirely ordinary.

Reading a result is a skill the course practices on every page. The first question is always whether the result answers the step's question; here it does, completely. The second is whether anything in it is surprising; here nothing is.

The third is what it rules out. Because every run of Word has one of two parents, a hunt for Word started by something else, a script or a browser, would have found it in this result, and it found none.

The paragraph after a result is the most important part of a step. It says what the result means: here, that the two parents are the two ways a person opens a document. A step that showed the result and moved on would leave the reader to interpret it, and the course's steps never do that.

Notice what the step did not do. It did not read individual runs, open documents or look for anything suspicious; it asked one question and stopped when the result answered it. That restraint is part of the method. A step that wanders produces results nobody asked for and decisions nobody can follow, while a step that answers its own question leaves a clear trail for the next one.

The query itself is short, and most of the course's queries are. A filter to the window, a filter to the thing being asked about, and a summarize that turns rows into an answer is the backbone of most hunting KQL. Module 4 teaches the language properly, with joins, time series and the operators that make larger hunts possible, but the backbone stays the same.

Check coverage Word starts in two ordinary ways. Check when it starts, by editing the query.

Each step ends on a decision like the one above: a short line naming the next move and its reason. The four moves are widen, to look at more data; check, to test what a result means; refine, to sharpen a query; and escalate, to hand something on. Reading the decisions alone gives the logic of a hunt in a few lines.

Every query in a lesson runs in your browser against the course's data, and you can edit it before running. A block can be run exactly as written, or changed line by line first and then run. The same rows, grouped by hour to see whether Word starts in working hours:

DeviceProcessEvents
| where Timestamp >= datetime(2026-02-13 12:00)
    and Timestamp < datetime(2026-03-15 12:00)
| where FileName == "WINWORD.EXE"
| summarize Runs = count() by Hour = hourofday(Timestamp)
| summarize WorkingHours = sumif(Runs, Hour between (8 .. 17)), Total = sum(Runs)

Word's runs in the month, split into those inside working hours and the total:

WorkingHours  Total
------------  -----
769           774

769 of 774 runs fell between 08:00 and 17:59 UTC, which in March is also UK time. Northgate opens Word when it works, and almost never outside those hours. Try changing the hour range, or the file name to EXCEL.EXE, and run it again: the result changes, and the change is the point. Hunting is learned by asking a question, predicting the answer and comparing it with what comes back.

Time is the one thing to keep in mind when editing. The data is in UTC, as Microsoft's advanced hunting is, and a query that compares hours with a working day needs to know the organization's time zone.

Northgate is in the UK and the window is in late winter, when UK time and UTC are the same, so the course's hours are also Northgate's. A tenant elsewhere would need hourofday() shifted before the comparison meant anything.

The results shown under each query are the results that query returns, generated when the lesson was built. If you edit a query and get a different answer, the difference comes from your edit, not from the data changing underneath you. The data is fixed for the whole course, which is what lets every lesson's numbers be checked by anyone.

Editing a query is also how you check a lesson's reasoning. If a lesson says a result means one thing, you can change the query to test that claim, narrow it to one device, widen it to a second table, and see whether the claim survives.

The course is written to survive that kind of reading, and doing it is one of the fastest ways to learn both the data and the language.

Predicting before running is the habit worth building here. Before you press Run on an edited query, write down what you expect: roughly how many rows, which value at the top. If the result matches, your model of the data is right; if it does not, you have learned something about Northgate or about KQL, and either is worth more than a result you did not predict.

Widen The hunt is answered. Widen to how you practice: the tools at the end of each lesson.

Each lesson ends with two pieces of practice. The hunt notebook gives you a brief, an empty query cell and questions answered by bookmarking rows from your own results; a model hunt opens when you want to compare.

Evidence questions give you rows the lesson produced and ask what they support. Some lessons and labs add the pivot workbench, which starts from one entity, an account or a device, and lets you follow the rows to others, citing the rows that answer each question.

All three work on the same data as the lessons. The kind of question they ask can be as simple as this one, which programs run on every laptop:

DeviceProcessEvents
| where Timestamp >= datetime(2026-02-13 12:00)
    and Timestamp < datetime(2026-03-15 12:00)
| where DeviceName endswith "-LT"
| summarize Laptops = dcount(DeviceName), Runs = count() by FileName
| top 6 by Runs

The six programs that ran most often across the fifteen laptops in the month:

FileName                Laptops  Runs
----------------------  -------  ----
msedge.exe              15       975
WINWORD.EXE             15       774
powershell.exe          15       771
chrome.exe              15       750
svchost.exe             15       749
SearchProtocolHost.exe  15       671

Word, the browsers, OneDrive, the Windows search indexer and the service host, each on all 15 laptops. A notebook built on this question would ask you to write the query, bookmark the most common program, and compare your query with the model. The practice at the end of this lesson is exactly that.

The tools check your answers against rows, not against wording. A notebook question is answered when the row you bookmarked has the required values; an evidence question when you pick the rows or option the data supports. Each answer comes with a short explanation of why, drawn from the lesson.

The pivot workbench needs a word of its own because it works differently. Instead of writing queries, you open entities, and each opening runs the queries the scenario defines and shows their rows.

Rows that mention another entity let you pivot to it, and your trail is recorded with a line on why you followed each pivot. It teaches the investigative habit of following evidence from one object to the next, and the model trail at the end shows the route an experienced hunter would take.

Every practice tool is tied to a lesson's data. The rows they show come from the same queries, run on the same month, so nothing in the practice contradicts the lesson. When a practice question seems to disagree with something a lesson said, the disagreement is worth reading closely, because it usually means a step in the lesson's reasoning has been missed.

A simple list like this one is worth building before any hunt for unusual programs, and Module 5 builds a fuller version. Knowing what runs everywhere lets a hunter set it aside quickly and spend attention on what runs almost nowhere. The same idea, measuring how common something is before judging it, ran through 0.1's alerts and 0.4's sign-ins, and it will run through most of the course.

Check coverage The lesson tools are shown. Check how the labs grade your queries.

Labs grade each query by running it. You write the query; the page runs it on the course's data and checks the shape of the result: how many rows, which columns, and whether a particular value appears. A query that returns the right rows passes however it is written. The small hunt above, as a graded exercise:

The grader checks three things, and each catches a common mistake. The row count catches a query that groups by the wrong column or forgets to group at all.

The required columns catch a query that answers the question under a different name, so the next step cannot use it. The required value catches a query that returns the right shape but the wrong rows, filtered too tightly or on the wrong field.

Write it from the prompt, run it, and use the hints if you need them. The model solution and a note on what the result means open once you have tried. Grading by result rather than by text matters for hunting: there are many correct ways to write a query, and the course accepts all of them.

A lab usually has five to eight exercises, each building on the last, so that by the end the queries you wrote are the query pack the lab's document needs. The document is assembled from your own work, which is why the acceptance criteria can ask whether each claim names its rows: the rows are the ones your queries returned.

Labs also hand you a document to produce, with a template, acceptance criteria and a model. You mark your own work against each criterion, met, partly met or not met, and read how the model meets it before the model opens. The criteria name the mistakes the course sees most often, so marking honestly against them teaches as much as the model does.

The labs come at the end of each module and use what its lessons taught on a case with less guidance. A lab's brief gives the trigger and the question, and each step gives a prompt rather than a query.

Your query is graded when you run it, and the lab's prose after each exercise explains what the right result shows. The capstone lab at the end of the course gives a single signal and leaves the rest to you.

Acceptance criteria are also how the course handles answers that differ from the model. A detection specification can be written several good ways, and a portfolio can order its sections differently and still be excellent.

The criteria name what every good answer must do, and each model says plainly what not to compare, wording or order, so that a different but sound answer is marked as met rather than as wrong.

Escalate The practice is shown. Close with the part every hunt ends on: the record.

Every hunt closes on a record, and the record is the part other people read when the hunt is over. It states the finding in a paragraph, lists the bookmarked rows that support it, states the bounds of what was searched, names the next steps, and gives one outcome. The outcomes the course uses:

Bookmarks in the record are the rows a reader would need to check the finding, written in a line each. They are the course's version of Sentinel's bookmarks, and they serve the same purpose: someone who doubts the finding can go straight to the rows that support it, rerun the query and see them.

A finding without bookmarks asks the reader to trust the analyst, and the course never asks that.

The outcome is a statement about the evidence, not about how the hunt felt. Explained and disproven are good outcomes, and so is inconclusive when the data cannot settle the question and the record says why. Microsoft's own hunting metrics count validated hypotheses for the same reason: a hypothesis tested and found false has added knowledge as surely as one found true. This lesson's own record follows.

The record closes the lesson. Planned means it ends on a way of working ready to use, as a preparation hunt does.

The record's bounds line deserves the most attention of its parts, because it is the one most often missing from real hunt reports. It says what the hunt looked at and, by implication, what it did not.

A record that says "nothing found" without bounds invites the reader to assume the hunt looked everywhere; one that says "nothing found in interactive sign-ins for the month" tells them exactly how much reassurance they have.

The shape will become familiar quickly, and that is when it starts to help. A reader who knows that the paragraph after each result says what it means, and that the decision line says why the next step follows, can read a lesson at speed and slow down only where the reasoning is new. The same shape in your own hunts makes them readable by colleagues for the same reason.

Some readers will want to skip ahead to the labs, and the course allows it, but the lessons carry the reasoning the labs assume. A lab's prompt that says "classify the results" relies on 9.2's five classes; one that says "prove the silence" relies on the controls 10.2 builds. Reading the lesson first makes the lab a test of judgment rather than a search for the right operator.

The practice is where the learning happens. A lesson read without its practice teaches the vocabulary; a lesson whose notebook you have written teaches the work. Each notebook is short by design, a single question you can answer in a few minutes, so that doing it is never the step you skip.

Step 3 listed the programs that run most often on the laptops. Write the query yourself and bookmark the answers.

Write down the program that runs on every laptop most often. Then write one sentence on why a hunter would want this list before hunting for unusual programs.

The check gives you the Word parents from step 1. Decide what each row supports.

Resources

Publishers revise these pages; where a page and this lesson disagree, the page is newer.

• Conduct end-to-end proactive threat hunting in Microsoft Sentinel (Microsoft Learn)
• Understand the advanced hunting schema (Microsoft Learn)