0.6 What This Course Builds

This is the last lesson of the orientation, and it answers the practical question every learner has before committing to a course: what is in it, and what will I be able to do at the end?

The answer is read from the course itself. The modules, lessons and labs are counted from the pages, the practice tools from their scenario files, and the templates from the files the labs hand you, so the counts here are the counts you will meet.

The course is built in five phases. Foundations sets out what hunting is and how a hypothesis is formed. Platform and Language teaches the two Microsoft platforms and KQL for hunting. Hunting Domains takes the endpoint, identity and email and collaboration data in turn.

Correlation and Operations joins them into reconstructions and turns hunts into lasting value. The Capstone puts everything on two whole cases. After the capstone come the resources, then course completion and the exam.

The course is written for analysts who work in Microsoft security tooling or are about to: SOC analysts who want to move beyond the alert queue, incident responders who want to find intrusions before they become incidents, and detection engineers who want their rules to come from hunting rather than guesswork. It assumes you can read a query and know what an alert is, and teaches everything else.

The course runs on one month of one organization's data, Northgate's, and every lesson's queries run on it in your browser. That choice shapes the experience more than any other. Findings in one module become context in the next, the same accounts and devices recur, and by the capstone you know the tenant well enough to see what does not belong in it.

The lesson is a hunt in the course's shape, like the five before it, and its question is about the course rather than the organization.

The course's ten teaching modules after this one, read from the pages, with the phase each belongs to:

50 lessons and 12 labs across ten modules, plus one planning exercise in Module 1.

Most modules have five lessons and a lab; Module 4, the KQL module, has two labs because the language needs more practice than any single topic; Module 5 has two because endpoint hunting has two distinct shapes, a known chain and an unfamiliar program; Module 9 has two because operationalizing a hunt means both specifying a detection and validating someone else's.

Module 10 has five lessons on one case and a lab on another.

The phases are also natural places to pause. Each ends on a lab that uses everything in it, so finishing a phase means you can do that phase's work on your own, and returning after a break means starting from a known point rather than the middle of a topic.

Each phase changes what you can do. After Foundations you can turn an intelligence report into hypotheses a hunt can test, and plan the hunt before running it. After Platform and Language you can find any of Northgate's rows and ask them precise questions in KQL.

After Hunting Domains you can hunt each kind of data on its own terms, with the baselines and techniques each needs. After Correlation and Operations you can reconstruct an intrusion across all of it and leave behind detections that keep working. The capstone is where you show all four at once.

The order is the order a hunter needs things. You cannot hunt well in identity data before you know KQL, and you cannot reconstruct a multi-stage intrusion before you can hunt each domain. Each module's index page lists the hunts it contains and the outcome each reached, so you can see where a module is going before you start it.

Time is the other thing the map tells you. The specification sets each module's length from about an hour and a half for the shortest to four hours for the KQL module, and twenty-four hours for the course, which is also its CPE value.

Most learners take longer on the labs than the estimate, because writing a query and deciding what its rows mean takes longer than reading someone else's. That extra time is where most of the learning happens.

Each module also stands on the ones before it in a specific way. Module 5's endpoint hunts use Module 4's operators without reintroducing them; Module 8's reconstructions start from threads Modules 5 to 7 opened; Module 9 operationalizes hunts from Module 8; Module 10 assumes all of it.

A learner who already knows KQL well can move quickly through Module 4, but should still do its labs, because later modules lean on the exact patterns they practice.

Check coverage The modules are mapped. Check the labs, where the course tests what it taught.

Every lab closes a module and applies its lessons to a case with less guidance. The twelve, in course order:

Labs are where the course stops leading you. A lesson gives each query and explains each result; a lab gives a prompt and expects you to write the query, then explains what the right result shows only after you have run yours.

The step from lesson to lab is deliberate, and most learners find the first lab or two harder than expected. That difficulty is the point: it is the gap between understanding a hunt and being able to run one.

Read in order, the labs trace the course's arc. The first two build hypotheses and choose tables. The KQL and endpoint labs hunt execution on devices. The identity, email and correlation labs each follow a thread across tables. The two operations labs turn hunts into detections and test someone else's rule. The last lab, the capstone, starts from a single signal and asks for a complete investigation.

The lab titles name what each lab is about, and several of them name intrusions you will uncover. That is not a spoiler in any sense that matters. Knowing that a lab follows a service account across hosts does not tell you which account, which hosts, or how to prove the path, and the lab is about the proving.

Each lab's queries are graded by running them, and most labs end with a document you write from a template. A lab is not finished when its queries pass; it is finished when the document it asks for would stand up to a colleague's reading, and the acceptance criteria are how you check that before opening the model.

Two labs differ in kind from the rest. Lab 10 asks you to specify a detection for production from a hunt the course has already run, and Lab 11 asks you to validate a colleague's rule on data that mixes benign and malicious activity.

Neither finds a new intrusion. Both teach the part of hunting that makes it last: a finding that becomes a tested detection is found again automatically, and a rule validated before it ships does not flood the queue it was meant to help.

Check coverage The labs are listed. Check the practice tools that run through every lesson.

Every lesson ends with practice of its own, and the labs add graded queries. The tools and how much of each the course carries:

59 notebook scenarios, 56 evidence checks and 4 pivot investigations, with 55 graded exercises in the labs and in 0.5. 0.5 showed how each works. The numbers mean that every lesson has its own practice rather than a shared bank, and each practice uses the rows its lesson produced.

The practice is also where the course is most demanding. A lesson can be read in an hour; its practice asks you to write the queries yourself, without the lesson's steps beside them, and to decide what the rows mean.

Learners who do every notebook and check come out of each module able to do its work; those who read and skip come out able to describe it. The difference shows in the labs and again in the exam.

Nothing you write is stored or graded as free text. The course's specification records that decision: written work is compared with a model answer against a rubric, by you. The tools grade only what can be checked against rows: a bookmark, a selected row, a query's result.

The pivot investigations are fewer because they are larger. Each one is a whole case in miniature, with several entities, many queries and four questions answered by citing rows, and each sits at the point in the course where following evidence across tables is the skill being taught. The notebooks and checks are small and frequent; the pivots are big and occasional.

Check coverage The tools are counted. Check the documents the labs ask you to produce.

The labs' documents are probably the course's most practical output, because they are the documents hunting produces in real work. Each comes as a template you write in and a model whose every value was emitted by a query:

threat hunting plan, hypothesis register, telemetry matrix, hunting query pack, endpoint investigation report, identity hunting report, Microsoft 365 compromise hunting report, multi-stage timeline and evidence matrix, detection specification, hunt closure report and the investigation portfolio.

Together they are a set of working templates a hunting team can adopt. Each model shows one good answer, and the acceptance criteria name the mistakes the course sees most, so the set teaches the standard as well as the shape.

The formats follow where each document is used. A hunt plan and a register are working documents a team edits together, so they come as a Word document and a spreadsheet.

A query pack is code, so it comes as a KQL file. The reports, specifications and the portfolio are written as plain text that any editor opens and any ticketing or wiki system accepts. You can adopt any of them as they are.

The models are the part most worth studying after you have written your own version. Each was built from the lab's own queries, so every number in it came from the data, and comparing your document with it line by line shows exactly where your reasoning or your evidence differed. The acceptance criteria tell you which differences matter.

Check coverage The modules and labs are known. Check what follows the capstone.

After Module 10 the course adds 32 pages of resources in 7 sets and closes with completion and an exam:

The resources draw on the modules and the same month of data.

A cheatsheet entry gives a query, its result, what to read and what it does not prove, and names the lesson that taught it; a runbook works a recurring part of a hunt on one case; a walkthrough works a thread the modules counted and never opened, from the first query to a scored finding; a playbook sets out what to do the moment a hunt confirms something.

They are the course arranged for use, so that work learned in order can be found by need.

The resources are for use after the course as much as during it: cheatsheets to look up a query pattern, cookbooks for recurring hunts, walkthroughs that work a hunt end to end, playbooks for what to do when a hunt finds something, a playground for open queries on the whole month, and the references the course cites.

The exam is an answer exam with one task per teaching module, each answered from the course's data, and the pass mark is 70 for every course on the platform.

The resources are numbered after the teaching modules, 90 and up, because they are a different kind of material. A module teaches by working a hunt; a resource is something you consult while working your own. The cheatsheets, for example, collect the course's query patterns by subject so that a pattern learned in Module 5 can be found in seconds months later, without rereading the lesson.

The exam's design follows the course's. Each task gives a question and the data, and asks for an answer the data supports, which is the same work the lessons and labs practice. A learner who has done the labs properly has already done the kind of work the exam asks for.

The exam page holds a query console under every task, over the same month, with now() fixed at noon on 15 March 2026. Each task names its tables and its window and asks for one number, and answers are checked on the server when you submit, so the page never holds them.

The answer exam is the same kind the platform's detection engineering, Active Directory and Windows forensics courses use. It does not ask you to recall definitions or pick from options about KQL syntax. It asks for answers the data supports: which account, which host, which time, which technique at which stage, each found by running your own queries on the course's month.

A learner who has written the labs' queries has practiced every move the exam needs.

Check coverage The course is mapped. Check the one thing every part of it shares: the month of data.

Every query in every module runs on the same month. Counted once, across the sixteen activity tables the course reads most:

let start = datetime(2026-02-13 12:00);
let stop = datetime(2026-03-15 12:00);
union
    (union DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents,
        DeviceLogonEvents, DeviceEvents, EmailEvents, EmailUrlInfo, UrlClickEvents,
        IdentityLogonEvents
        | where Timestamp >= start and Timestamp < stop
        | summarize Rows = count(), Days = dcount(startofday(Timestamp))
        | extend Platform = "Defender XDR"),
    (union SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs, OfficeActivity,
        SecurityEvent, Syslog, CommonSecurityLog
        | where TimeGenerated >= start and TimeGenerated < stop
        | summarize Rows = count(), Days = dcount(startofday(TimeGenerated))
        | extend Platform = "Sentinel workspace")
| project Platform, Rows, Days

The month's activity on each platform, with the days each one covers:

Platform            Rows   Days
------------------  -----  ----
Defender XDR        65182  31
Sentinel workspace  46288  31

111,470 rows of activity across both platforms, on every day of the window. Microsoft notes that advanced hunting can "explore up to 30 days of raw Defender XDR data"; the course's month is that window, and every hunt you run sits inside it.

The intrusions the course uncovers are in these rows, alongside a month of ordinary work by an organization of 97 directory accounts, and telling the two apart is the whole of the course.

The record closes the orientation. Planned means it ends on a course ready to start.

The month is also what makes the course's numbers checkable. Every count in every lesson comes from a query on these rows, run when the lesson was built, and every query is in the lesson for you to rerun.

If a number in a lesson ever disagrees with what its query returns, the query is right and the lesson is wrong, and that is a standard the course holds itself to.

Two rows of numbers in the result are worth a glance. Both platforms hold rows on every day of the window, so there is no day the course cannot hunt; and the Defender XDR tables hold more rows than the workspace tables, because every process, connection and message link on a covered device or mailbox is recorded.

That balance shapes the course: endpoint and mail hunts have the most rows to work with, identity hunts the most context per row.

You finish the course able to do the work a hunting team does: plan a hunt with every answer written down in advance, write KQL that can see what it looks for and prove it, hunt the endpoint, identity and mail data of a Microsoft tenant, reconstruct an intrusion across them, turn a hunt into a tested detection, and write a report each reader can act on.

The capstone portfolio is the evidence of it, and the exam is the check.

None of it requires your own Microsoft tenant. The queries run in the browser on Northgate's data, the labs grade in the browser, and the templates open in ordinary tools. A learner with access to a real Defender XDR or Sentinel workspace can run the same queries there against their own data, and the Lab Setup resource will describe how, but the course is complete without one.

The orientation ends here, and the course proper begins. Module 1 starts the method properly, with the fundamentals of hunting and the lifecycle every hunt follows, and its first lesson opens on an account in this same month.

Step 6 counted the month once. Split the activity by weekday and weekend and see how the organization's week shapes the data.

Write down the share of activity on weekdays. Then write one sentence on why a hunt for weekend activity would need its own baseline.

The check gives you the modules with their lessons and labs. Decide what the map tells you.

Resources

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

• Proactively hunt for threats with advanced hunting in Microsoft Defender XDR (Microsoft Learn)