0.6 What This Course Builds

Introduction

This lesson is the map. The first five lessons of this module explained what Active Directory is, who runs Northgate's domain, what evidence the course reads, how an investigation runs and how a detection is written.

This one sets out what the course does with all of that: the order the modules come in and why, what every lesson asks you to do, the eight tools you build along the way, the resources that outlast the lessons, the Project and the exam that close the course, and the lab domain, which is the one part you can leave out.

The course is built around things you keep. Many of its 24 teaching modules end with something you can run on a domain of your own, and eight of those things are tools in the outline's sense: scripts, a detection pack, a playbook and a runbook you'll use after the course ends. The figure places each tool at the lesson that builds it:

The tools aren't spread evenly, and that follows from the subjects. The first three auditors arrive with privileged access, service accounts and ACLs, because those are the questions they answer; the detection pack waits for detection engineering, and the response playbook and recovery runbook come with the modules that use them.

Tool 1, the assessment, is last because it runs Tools 2 to 4 together, and it can only be built once they exist. The rest of this lesson takes each part of the course in turn.

The course's modules follow a published outline of 24 topics, in the outline's order apart from one deliberate move, and they group into eight phases. Each phase answers one question about the domain, and the order is the order in which the answers depend on each other:

Foundations comes first because everything after it reads events and directory state. Module 1 explains the directory through the attacks on it, including stealing the database and DCSync, and Module 2 is logging, moved forward from the end of the outline so you learn what a controller records before you're asked to read it.

Module 3 sets out the stages of an intrusion, and Module 4 the reconnaissance that begins one.

Some attacks have no module of their own, and the course places each where its evidence is taught rather than inventing a module for it. Stealing the directory database and DCSync are in Module 1, because they explain how the database and replication work.

Taking credentials from LSASS is in Module 6, beside the protections that stop it, and DCShadow, which registers a rogue controller, is in Module 22, among the persistence it is used for. When you look for an attack in the course, look in the module about the thing it abuses.

The placement is also why the course has no catch-all attacks module: each technique is taught once, in full, next to the defense it tests.

Privileged Access and Credential Theft are the center of most real intrusions. An attacker who controls an administrator's account, or a service account with too much power, rarely needs anything clever, so these phases spend a long time on who holds power and how credentials are taken: pass-the-hash and relay in Module 8, the Kerberos attacks in Module 9, service accounts in Module 10.

Attack Paths then joins those pieces, through permissions, Group Policy and delegation, into routes from an ordinary account to the domain, and Module 14 reads those routes the way an attacker's graph tool does.

The privileged access design the course teaches is Microsoft's current guidance: privileged access boundaries drawn around what an account can control, and attack paths reduced until none reaches tier 0. Tier 0, tier 1 and tier 2 are still used throughout as a model, because they name a real difference between the accounts that control the directory and everything else.

The Enhanced Security Admin Environment, the separate administrative forest once called the Red Forest, appears only as history; Microsoft no longer recommends it for most organizations, and the course doesn't teach it as a design.

The last four phases turn from attacks to the defender's own systems and work. Infrastructure hardens the controllers, DNS, trusts and certificate services. Detection Engineering collects every lesson's detection into one catalog and tests it, and covers Defender for Identity.

Response and Recovery cover what happens when the defenses fail, through to rebuilding a forest, and Module 24 closes the course by assembling everything into a security program with an operating cadence and measures.

The teaching modules hold 100 lessons, from three to six a module, each followed by a module summary that carries the knowledge check. Every lesson is named after one attack or one defender task, and the name decides its shape. A lesson named for an attack walks through six parts; a lesson named for a task walks through three:

The attack lessons are most of the course, and the six parts never change order. You meet the attack's purpose before its mechanics, and the mechanics only to the depth a defender needs: what the attacker does and why it works, never a working procedure beyond what the public tool documentation already says.

Observe is the part that makes the rest possible, because it puts the attack's evidence in front of you on the corpus, and the detection in the next part is built from exactly those rows.

The defender-task lessons are the work that has no attacker in it: setting an audit policy, auditing delegation across the domain, building the incident playbook, running a forest recovery. They follow Investigate, Act, Verify.

Investigate reads what's there now, Act changes it with a numbered procedure that names the console or host each step runs on, and Verify reads the state again. In both shapes Verify is never optional. A fix that hasn't been read back is a change you hope worked, and the course treats it as unfinished.

Every lesson ends with practice of one or more of three kinds, chosen by what that lesson teaches, followed by a short task for your own estate:

Detect exercises run in the page. The in-page queries read the course's AD corpus, a month of events from Northgate's controllers, servers and workstations from 14 February to 15 March 2026, in the tables and indexes lesson 0.3 described. Different parts of the course lean on different parts of that month, and the difference in volume is large:

Kerberos tickets dominate because every sign-in and every access to a service writes them, and the credential theft phase lives in that volume. Directory changes and reads are a fraction of it, and certificates and NTLM validations are rare. The scale matters for detection.

A rule over Kerberos tickets has to say precisely which ticket is wrong, because about 524 a day is ordinary, while a rule over certificate issuance can afford to look at every one. Try the shape of a Detect exercise on that month now:

The exercise is graded on the rows your query returns, so a query that gets the right answer by a different route passes, and one that returns the right column names over the wrong rows doesn't. Every Detect exercise in the course works this way, and every solution has been run on the corpus before the lesson was published.

Audit and Decide work differently, because they ask for judgment rather than rows. An Audit gives you an artifact as a defender would meet it, a template's settings or an object's permissions, with some lines that are faults and some that only look like faults, and asks you to mark the faults, say what each one permits and say how you'd fix it.

The decoys are the point: a controller trusted for delegation looks alarming and is how Windows is designed. A Decide gives you a call an incident or a design forces, such as whether to reset an account now or watch it for another day, with the trade-offs on each side, and asks you to commit to one in writing before you see how a practitioner weighed it.

The tools are the course's most durable output. Each is built in the lesson that teaches its subject, tested against that lesson's evidence files before the lesson shows its output, and finished in Module 24. Each is available on the course page as a download once its lesson is published:

Three of the tools are packages rather than single scripts, because the work they support is not one command. The detection pack is a catalog: each rule with its owner, its test status and its four surfaces, ready to load into Sentinel or Splunk, and its PowerShell forms for an estate with neither.

The rules in fewer surfaces are the ones whose source rules some out: evidence that exists only in Defender for Identity's tables, as lesson 0.5 explained, and checks that compare a month against a baseline or read the directory's own state rather than one event.

The incident playbook pairs a written procedure with a script that turns an incident's evidence into a scope, and the recovery runbook pairs its procedure with a check that a restored controller is what it should be.

The PowerShell auditors share one design you'll see repeatedly. Each reads the directory and changes nothing. Each takes a register of decisions already made, so a finding someone has accepted with a reason is reported as Accepted rather than raised again every month.

Each reports the time it read the domain, so two runs can be compared and a change between them dated. And each can run on exported files as well as a live domain, which is how the lessons show their output and how you can run them on data a domain owner has exported for you.

Tool 1 is numbered first and built last. It is the outline's AD Security Assessment, and rather than duplicate what the auditors already find, it runs them and judges their output against a written AD security standard:

The tree is the reason for the build order. Tool 2's rows answer whether tier 0 is the size it should be, Tool 3's whether service accounts are where and what they should be, Tool 4's whether every dangerous permission is a recorded decision, and the delegation report from lesson 13.4, a report beside the eight tools, whether any account can act as a protected one.

The assessment adds none of its own findings. What it adds is the standard: a written list of what your domain should be, with a check behind each line that it can measure. The checks, grouped by the auditor they read:

The standard is yours, written in lesson 24.1, and the assessment only measures against it. That split is deliberate. Two organizations can disagree about whether a service account may carry a service principal name, and both can be right, so the course doesn't hard-code the answer; it gives you a tool that reports what your own standard says, item by item, with the accounts behind each verdict.

Run monthly, its summary file is a record of the domain's security over time, which is what Module 24 turns into measures.

Exceptions get the same discipline as findings. A failing item can be marked Excepted only by an entry in an exception file that names the line, the item and a date it expires, and on the day after that date the item counts as a failure again and the report says why.

An accepted risk with no end date is how a domain accumulates the weaknesses the course spends its first twenty modules finding, and the assessment is built so that every acceptance has to be renewed by someone who reads it.

The lessons teach, and you read most of them once. The reference layer is what you return to afterwards, and it is organized by the question you'll have rather than the order you learned things in:

The cheatsheets and the operational reference are the pages to keep open at work. Each cheatsheet is one module's queries and commands, every entry run against the corpus or the evidence, so a query copied from it is one that has returned rows.

The operational reference is the detection library itself, the source the detection pack is built from. The cookbooks, walkthroughs and playbooks are longer: procedures for the questions the course raises, complete investigations worked on the corpus, and the hunting patterns and calendar that keep a domain's security from drifting after a hardening project ends.

Two of the eight serve the practice rather than the reference. Lab Domain Setup is where the lab domain is built, covered at the end of this lesson. The Practice Playground points to the places you can keep working beyond the course's own exercises.

The References module lists the sources behind the course by the question each answers, with every link checked, so a claim in a lesson can be traced to the vendor or standards document it rests on.

The course closes with two pieces of work that test different things. The Project tests whether you can run an investigation end to end, the exam whether you can find a specific value in the evidence on demand:

The Project's case belongs to a different company on purpose. Brackmoor Freight's intrusion happens in its own domain, in its own month, with its own evidence pack, so nothing you learned about Northgate's month gives an answer away, and nothing in the Project can contradict the timeline the lessons teach.

Its stages follow the course: an intrusion that starts with a phishing message, moves through a workstation and stolen credentials to a server administrator, and climbs through Kerberoasting, a service account and an ACL to Domain Admin, DCSync and persistence. You work it with the tools you've built, and the deliverables are the ones an incident lead hands over.

No answer page is published for the Project, deliberately. An investigation in practice has no answer page either, and the course's standard for your write-up is the one it applies to its own lessons: every time in the timeline, every account in the scope and every edge in the attack path traces to a row in the evidence that you can point to.

A finding you can't trace is an inference, and the write-up should say so. Checking your work against that standard is the skill the Project exists to practice.

The exam is narrower and more exact. Each of its 24 tasks belongs to one teaching module and asks for a value: a count, an account, a time, found by writing a query against the corpus or reading an exam evidence file.

A score of 70 per cent passes, which is 17 correct answers, and there is no higher tier. The tasks don't repeat any lesson's exercise, so the exam measures whether you can apply a module's method to a question it didn't ask, which is the skill the course exists to build.

Observe and Detect happen in the page, against the corpus. Defend and Verify are changes to a directory, and changing a directory needs a directory, which is what the lab domain provides. It is an optional extension, and every lesson is complete without it:

Without a lab, each Defend and Verify section shows the directory state before and after the change from evidence files, so you see what the fix changed and how the check proves it.

With a lab, you make the change yourself and run the check, which teaches the part evidence files can't: what the console looks like, which permission the change needed, and what happens when you get a step wrong.

The network has to be isolated because the seeding is real. After the script runs, the lab holds a service account that can be Kerberoasted, permissions that hand over accounts and a server trusted for unconstrained delegation, which are exactly the weaknesses the lessons remove. On a network shared with anything else they're weaknesses in that network too.

The evaluation's 180 days also suggest a timing: build the controller when you start Module 1 and it lasts well into the course, and the seeding script can be run again on a fresh controller if it expires first, because a second run changes nothing it has already done. The choice, as a reader of the course meets it:

The middle route needs care. Every auditor in the course reads and none of them changes anything, which makes them safe to run on a real domain, but safe isn't the same as permitted.

Reading a domain's ACLs, delegation and privileged membership is reconnaissance in any other context, and it needs the domain owner's written agreement before you start. With that, running Tools 2 to 4 on your own employer's domain while you take the course is the fastest way to make the lessons concrete.

Everything beyond that is optional: the lab, your own domain, a second SIEM. The lessons, the corpus and the evidence are enough to finish the course, and the Practice card at the end of each lesson is where you choose how far to take it.

Practice

Next, Module 1: How Active Directory Really Works, starting with lesson 1.1, the sign-ins to the domain controllers.