0.6 What This Course Builds

Introduction

The attacker leads, and by the end of the course you will have led a whole exercise yourself: planned it, run it, read what the defense did, repaired what it missed and reported the result, from both seats.

This lesson shows where that ends and what you build on the way. It reads the engagement's arc from the first run to the last, the way the defense improved over it, the deliverable each module asks you to produce, and the eight the capstone asks for together.

It also shows the course's own arc in miniature. Module 0 has read four tests and a range; the modules after it read the whole engagement, one kind of test at a time, and the capstone reads an exercise of your own. Each step widens what you are trusted to read alone, and each is checked before the next.

The course is ten modules after this one, with three staged assessments and a course exam.

It is designed to be worked in order, because each module's deliverable is an input to a later one: the charter from Module 1 shapes the matrix in Module 2, the lab from Lessons 0.7 to 0.11 runs every later procedure, and the assessment in Module 9 is built from records the earlier modules taught you to keep.

None of what the course builds is a certificate alone.

The certificate comes with passing the exam, and it is worth having, but the things you will use afterward are the habits and the documents: a way of reading a test that does not stop at the alert, a way of repairing a rule that proves itself, and a set of templates you can take into your own team's next exercise.

What the course commits to building, stated before it starts so that you can check it at the end:

The decision line is the course's real test, and the capstone is where you take it. Module 10 has no worked answer for your own run: you plan Operation Broken Signal for your lab, run it, observe it, repair two detections and report, and then the staged assessment checks the same phases on a recorded run. If you can do both, the course has done its job.

Being able to run an exercise alone does not mean running it alone in practice. Most exercises are run by a small team, and the course's two seats exist so that each person knows what the other is doing. What it does mean is that you could hold either seat, or both, without someone else telling you what to look at next.

The last line is meant literally. Every template the course gives you, from the charter to the final report, is a file you download and keep, and every query in the lessons is one you can adapt to your own workspace. None of them depends on the course's range to be useful.

Working in order does not mean working quickly. The course is about thirty hours, and the modules are uneven: the tooling and validation modules take longest because their labs do. Most students find a module a week comfortable, with the staged assessments taken at the end of the module they follow while the lessons are fresh.

From the operator's seat the engagement has a shape you will follow yourself, and every step of it was an attack run with a tool. The test log, run by run, with the techniques each run tested and the tool behind each test:

PurpleTestLog_CL
| extend Tool = case(isnotempty(AtomicTestGuid), "Atomic", AtomicTestName startswith
    "Caldera", "Caldera", "By hand")
| summarize Tests = count(), Techniques = dcount(Technique), Atomic = countif(Tool ==
    "Atomic"), Caldera = countif(Tool == "Caldera"), ByHand = countif(Tool ==
    "By hand") by Run
| order by Run asc

Nine runs, and the number of techniques falls as the engagement goes on:

Run  Tests  Techniques  Atomic  Caldera  ByHand
---  -----  ----------  ------  -------  ------
1    14     14          14      0        0
2    4      4           4       0        0
3    13     11          8       0        5
4    11     6           6       2        3
5    12     7           10      0        2
6    8      7           3       0        5
8    9      6           2       0        7
10   2      1           0       2        0
11   5      4           5       0        0

52 of the 78 tests are Atomic Red Team tests run by GUID, 4 are Caldera operations, and 22 were written by hand: ports of Atomic tests to Microsoft Graph, variants shaped to a rule's text, chains, retests and lookalikes, each logged with its exact command.

The first week leans on Atomic, because breadth comes cheaply from a library; the repair runs lean on procedures written by hand, because closing a gap means attacking the specific rule that was repaired; and the regression run returns to Atomic, because a scheduled job can only rerun what has a GUID.

The first run tested fourteen techniques in fourteen tests: breadth, one procedure each, to find where the defense stood. Later runs test fewer techniques with more tests each: retests of the repairs, the operator's variants against them, and the adaptations that answered the variants. The last two runs are one collaborative operation run twice and an unattended regression job.

The two runs with only a handful of tests are some of the most instructive. The collaborative operation is one Caldera profile run twice, transparent and then blind, and its lesson is about people rather than rules. The regression run is a scheduled job with nobody watching, and its lesson is that a defense can break without anyone touching a rule. Neither needs many tests to make its point.

That shape is the method. A purple team starts wide to find the gaps and narrows to close them, and it ends with a regression run that keeps them closed. Your capstone follows the same arc on a small scale: a plan with several techniques, two repairs, and a retest.

Across all nine runs the operator tested a number of distinct techniques:

PurpleTestLog_CL
| summarize Techniques = dcount(Technique)

27 distinct techniques in all, from discovery to exfiltration:

Techniques
----------
27

Twenty-seven techniques on the endpoint, the network and the tenant is a respectable engagement. It is also the number most often misused in purple team reports, as the denominator of a coverage percentage.

A technique tested once by one procedure says little about the technique: Module 9 of the course shows a technique that was detected for one procedure and missed for the next, and builds the engagement's coverage by procedure instead.

The techniques also span the course's three domains unevenly, which is honest about where the engagement spent its time. The endpoint has the most, because that is where most procedures run and most telemetry is recorded; identity and the tenant have fewer, from the second week; the network has the fewest, because its sensor arrived last. A purple team's coverage always reflects its instruments as much as its intentions.

The operator's view of the number is simpler. Twenty-seven techniques is what was tried; whether each was seen is the defender's half, and the next sections read it.

The recording covers one engagement on one range. The operator's note on what your own lab adds:

In your lab the capstone uses the same tools the engagement did. Its procedures start like this:

PS C:\> Invoke-AtomicTest T1053.005 -TestGuids $g -CheckPrereqs
PS C:\> Invoke-AtomicTest T1053.005 -TestGuids $g -ExecutionLogPath $log
$ python3 server.py --insecure
PS C:\> Connect-MgGraph -Scopes RoleManagement.ReadWrite.Directory

An Atomic test checked and run by GUID, a Caldera server started on the lab segment, and Microsoft Graph for the tenant. What your own lab adds to them, in the operator's words:

The last question is the most useful one you can ask of any training. A result that holds in your environment is one you can rely on; one that does not is a finding about your environment, and the course's method is how you find out why. Every lab in the course ends by asking you to compare your lab's result with the range's.

Repetition is underrated as a feature. In the recording each test happened once, at a fixed time, and the result is what it is. In your lab you can run the same Atomic test ten times, change one setting between runs, and watch which records change. That is how a defender learns what a telemetry source actually captures, as opposed to what its documentation says it captures.

Your own variants are where the course stops and your practice begins. The operator's variants in the lessons are described and then run in a later module; yours can be run the same day, in your lab, and read with the same six steps.

The defender's view of the engagement is a defense that changed. Its incidents, split into the first week and the rest:

SecurityIncident
| summarize TruePositive = countif(Classification == "TruePositive"), Other =
    countif(Classification != "TruePositive") by Week = iff(CreatedTime <
    datetime(2026-09-21), "Week 1", "Weeks 2 and 3")
| order by Week asc

Three incidents in the first week, twenty after it:

Period         TruePositive  Other
-------------  ------------  -----
Week 1         2             1
Weeks 2 and 3  12            8

In the first week the range raised alerts that mostly never became incidents, as Lesson 0.1 found for PT-0103, and the one incident it opened for a test was closed on a weak basis, as Lesson 0.4 found for PT-0104.

Over the following fortnight the defense opened incidents for far more of its alerts and confirmed far more of them, with comments naming the test. Part of that is simply more tests. Part of it is a SOC that learned, from the engagement's findings, to treat an exercise alert as evidence to check rather than noise to close.

The other column matters too. Eight incidents in the later fortnight were not true positives, and they are not all errors: some are lookalikes correctly closed as benign, some are white cards announced in advance, and at least one is a misjudged test. The course reads each of them by its comment in the module where it happened, and Module 9 counts them properly.

That change is as much a result of the engagement as any repaired rule, and it is the kind of result a purple team is best placed to produce, because only the purple team sees the operator's record beside the analyst's verdict.

Every module ends with a lab that produces a deliverable, in your own lab, from the module's work:

Read the table as a sequence rather than a list. Each deliverable is written by the module's lab in your own environment, and each assumes the ones before it exist: you cannot write a gap report in Module 5 without the register Module 4 taught you to keep, or a backlog in Module 9 without the reports of Modules 5 to 8.

The deliverables build on each other. The charter's rules of engagement govern every later test. The test matrix becomes the plan's matrix in the capstone. The readiness checklist is rerun before every exercise. The registers and reports from Modules 4 to 8 are the evidence an assessment is written from in Module 9, and the backlog from Module 9 is the next exercise's starting list.

The deliverables are also the course's answer to a question every student eventually asks: what would I show someone to prove I can do this? A charter, a matrix, an evidence register and a report from your own lab, each traceable to records you can reproduce, is a stronger answer than a certificate, and the course is designed so you finish with them.

Each comes with a template and a model to check yourself against. The models are not answers to copy: your lab's results will differ, and the model shows what a finished document looks like, at the level of detail the course expects, so you can see where yours falls short and why.

The capstone asks for eight deliverables from one exercise, each from a lesson of Module 10:

Together they are an exercise from start to finish, and they are the portfolio the course leaves you with. A reviewer who reads them in order should be able to see what was planned, what ran, what the defense did, what was repaired, whether the repairs held, and what is still open, without asking you anything. That is the standard every module trains toward.

The eight are deliberately ordinary documents. Nothing in them is unique to this course's range or to Microsoft's tools: a plan, a log, a register, an analysis, two rule changes, a comparison and a report are what any purple team produces, in any estate. Learning to write them well on a small, clear exercise is what makes them quick to write on a large, messy one.

The staged assessment that closes the capstone asks for the same phases on a recorded run of the same exercise, marked as you go. Doing your own run first is the better order: your run has no answer key, and the assessment shows you how your reading compares with one that does.

The documents are the visible part. The habits behind them are what change in your daily work:

The left column is not a caricature. Each is a reasonable way of working that most teams use, and each produces results that look fine until someone checks them against the operator's record. The course does not ask you to stop reading the alert queue; it asks you to read it after the operator's row and the host's records, so that the queue's silences are visible too.

Each row is a habit the course practices dozens of times. Reading a test from the operator's row is Lesson 0.4's six steps, repeated in every module.

Checking a silence for records is the difference between a rule gap and a visibility gap, which sends work to different owners. Proving a repair on its attack, its lookalike and its retest is Module 7's method. Reporting by outcome rather than percentage is Module 9's.

The habits also change how you talk about results. A defender who has worked the course says "PT-0602 left ten failed sign-ins and PU-R16 did not read them, because each address stayed under the threshold" rather than "the spray rule doesn't work".

The first can be checked, assigned and fixed; the second starts an argument. Most of a purple team's influence on a defense comes from speaking in the first way.

None of these habits needs the course's range once it is formed. They apply to any detection stack, any test library and any team size, which is why the course teaches them on a small range where the results are clear rather than on a large one where they would be lost.

The course's ten modules fall into five phases, followed by the resource modules and the course exam:

The resource modules, and what each is for:

The walkthroughs deserve a special mention. Each takes one whole recorded day and reads it from the first test to the last, including the readings that turned out to be wrong, so you can see how an experienced purple team corrects itself during an exercise rather than only the finished account afterward.

The resource modules sit at the top of the course navigation: cheatsheets, cookbooks, the lab setup for both stacks, walkthroughs of whole recorded days, playbooks for what comes up during an exercise, and a playground. You can use them at any point, and most students keep the cheatsheets open in a second window while they work.

The obvious way to summarize what the engagement achieved is the number of techniques it tested:

PurpleTestLog_CL
| summarize Techniques = dcount(Technique)

SecurityIncident
| where Classification == "TruePositive"
| extend TestId = extract(@"(PT-\d{4})", 1, ClassificationComment)
| where isnotempty(TestId)
| summarize Tests = dcount(TestId)

The gap between the two numbers is not a failure of the engagement. It is the engagement's result, and every later module explains a part of it: the tests that were missed and why, the ones that were seen and not handled, and the ones that were closed on a weak basis. A course that started from twenty-seven techniques and ended there would have measured nothing.

The refined number is smaller and more honest. Twelve tests were seen and confirmed by the defense; the rest were missed, closed on weak bases, never opened, or blocked without anyone being told. Module 9 builds the full picture from there, and the capstone asks you to report your own exercise the same way. On the chain both seats use, the course reads:

Two numbers in the chain, seventy-eight tests and twelve confirmed, will come up again. Lesson 9.1 starts from the first as its denominator, after removing the tests that did not run; Lesson 9.2 measures how long the defense took for each of the confirmed ones; and the capstone's report states its own versions of both for the exercise you run.

The chain is the course in one card. Module 1 starts filling it in, from the charter onward.

The course is written for several roles, and each will find its center of gravity in different modules:

The roles are not exclusive, and the course does not assume you hold only one. Many purple teams are a detection engineer and an analyst taking turns in the operator's seat, and the course is written so that each module is useful whichever seat you usually sit in. The variants card marks where each role's own work is closest to the course's material.

A SOC analyst will get most from the verdict steps and the collaborative modules, which change how an exercise alert is handled. A detection engineer will live in Modules 5 to 7, where rules are tested and repaired.

A purple team operator will find the planning, tooling and capstone modules closest to the job. A security lead will use Module 9's measurement and reporting most. Every role works both seats throughout, because the method depends on it.

The case below reads the engagement's arc, how the defense's verdicts changed, and the difference between techniques tested and tests confirmed. Work in the platform's Advanced hunting console with the Purple Range selected.

Keep these four answers with the cards you wrote for PT-0103 and PT-0104 in the earlier lessons of this module. Together they are a small but accurate picture of the whole engagement before Module 1 starts, and the first module's lessons will add to it, one test at a time.

The last two answers together are the course's argument: twenty-seven techniques tried and twelve tests confirmed is a result you can act on, and only reading both seats' records produces it.

The practice is in the console, against the recording; your own lab is built in Lessons 0.7 to 0.11.

Resources

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

• NIST SP 800-55 Volume 1, Measurement Guide for Information Security
• Invoke-AtomicRedTeam wiki
• Caldera: Learning the terminology