0.2 How the Course Is Built

Introduction

Lesson 0.1 said what the course covers. This lesson explains how it is built, so you know what to expect from a lesson, how the lab pack works, and how the exercises, answer guides and other resources fit together. Each part has a reason, and knowing the reasons makes the course easier to use well.

The short version: every lesson is built on real evidence that you also have, every command in it was run on that evidence at a named tool version, every finding carries a stated level of confidence, and every exercise has an answer guide you open after you have answered. The rest of this lesson takes each of those in turn, then the learning aids and the resources you keep.

These choices make the course slower to build and, at first, slower to work through than one that only describes what a tool would show. They make it faster to learn from, because every claim in it can be checked by running a command, and checking claims is most of what an investigation is.

Every lesson in the teaching modules has the same shape, and recognizing it saves time:

The introduction says what the lesson answers and why it matters, usually in terms of something an analyst is handed. It is short, and it ends by listing what the lesson works through, so you can see the path before you start.

The sections each teach one thing. A section opens with prose that says what it is about to show, shows it, and then draws the consequence in prose: what the evidence means, what it does not, and what to do next. Most sections carry a command and its output, a figure or a learning aid, and many carry more than one.

A section is short enough to read in one go and long enough to teach its point properly. Sections are numbered within each lesson, and each has a short descriptor under its title saying what it covers, so a lesson can be scanned before it is read and revisited one section at a time afterward.

The practice at the end of each lesson says what to do with the lab pack and what you will have when you have done it. It is not optional. The practice is where the lesson's method becomes yours, and the course's exercises assume you have done it.

Exercise lessons, the eighth in most modules, follow a different shape. They hand you a new lab window or case, work the first question in full, then give the method and a starting command for each remaining question and leave the answers to you. Lesson 0.5 shows you how to start one.

The capstone lessons in Module 14 are written the same way as the exercises, because the capstone is the course's practical assessment: the lessons give the method and point at the evidence, and the conclusions are yours.

Lessons also refer to one another by number, such as lesson 12.7 or Module 9. Those references are to lessons that exist, and following them is the quickest way to revisit a method when a later lesson relies on it. The course is designed to be read in order the first time and dipped into afterward, and the numbering makes both easy.

Every command in a lesson was run on the lab pack when the lesson was built, and the output you see is what that command printed. Nothing is typed by hand or tidied for the page. Here is the first one you will meet, from the Module 1 folder of the pack:

$ capinfos -c -u -a -e inside.pcap
File name:           inside.pcap
Number of packets:   128
Capture duration:    15.601059 seconds
Earliest packet time: 2026-11-09 19:42:03.288701
Latest packet time:   2026-11-09 19:42:18.889760

That output comes from capinfos, part of Wireshark 4.6.9, run on the capture in the m01 folder. When you run the same command on the same file, you should see the same numbers. If you do not, the difference is information: a different tool version, a different file, or a different folder. Finding which is a small investigation of its own, and doing it is good practice.

Each lesson that relies on a tool's behavior names the version it was written against, in a line at the foot of the lesson. Tools change between versions: a field is renamed, a default changes, a protocol is parsed differently. The version line tells you which version produced the lesson's output, so a difference on your machine can be traced to its cause.

The commands are written the way you would type them, wrapped to fit the page with a backslash at the end of each continued line, and they use only the tools lesson 0.3 lists. Where a command is long, the lesson explains each part. Where a lesson uses a short script, the script is in the pack, and the lesson walks through what it does.

The course's own build process enforces this: before any lesson is written, the build checks that each tool reports the version the course teaches, and stops if one does not.

The point of all this is trust. When a lesson says a capture holds a certain number of packets, or a log shows a certain connection, you can check it yourself in seconds, and you should. A course whose outputs cannot be reproduced teaches you to accept claims; one whose outputs can be reproduced teaches you to check them, which is the habit an investigator needs most.

You will also notice that the outputs are not always tidy. Real tools print warnings, extra columns and lines that do not matter to the question. The lessons leave most of that in, cut only where a line would be too wide for the page, and say so when they do.

The evidence for every lesson, exercise and case is in one download, the course lab pack, which lesson 0.4 shows you how to get. It is a single zip file holding one folder per module window, exercise and case:

$ ls | tr '\n' ' ' | fold -s -w 80
ls | wc -l
case1 case2 case3 case4 case5 case6 case7 case7b m01 m01x m02 m03 m03x m04 m04x 
m05 m06 m06x m07 m08 m09 m10 m11 m12 m12x m13 m13x 27

There are 27 folders. The ones beginning with m are the module windows, and an x after the number marks a module's exercise; the case folders hold the seven practical cases, with case7b the benign window the capstone's detection is tested on.

Each folder holds the captures, the logs the tools wrote from them, any records the case needs, such as a firewall's NAT events or a domain controller's audit, and the asset notes for that window's network.

Every folder also holds a file called SHA256SUMS, which lists a checksum for every file in it. Checking the folder against it is the first step of every exercise:

$ cd m01 && sha256sum -c SHA256SUMS
inside.pcap: OK
outside.pcap: OK
hosts.txt: OK
traceroute-ws45.txt: OK

Every file reports OK. The check matters for two reasons. It confirms your copy is complete and undamaged, so your outputs will match the lessons'. And it is the habit Module 2 teaches for any evidence you are handed: a file whose checksum you have not verified is not yet evidence.

The captures were produced in an isolated lab built for the course, with real clients and servers talking real protocols, captured with tcpdump and processed by the same Zeek and Suricata versions the lessons use. Where a case needed packet loss, a wrong clock or a gap in a sensor, it was introduced by a documented edit, and the answer guide for that case says exactly what was changed.

Keep the pack unzipped in one place on your machine, with its folder names unchanged, and run each lesson's commands from inside the folder the lesson names. Several commands refer to files by relative path, and a few, in the later modules, refer from one folder to its neighbor, so the layout matters.

Lesson 0.4 suggests a location and shows the commands to put it there. Lessons refer to a folder by its name alone, such as the m01 folder, and assume the rest of the layout is as the zip left it.

The pack is large, because it holds real captures, and you only need to download it once. If a lesson's output differs from yours and the checksums all pass, the pack is not the cause.

Network evidence rarely proves something outright. More often it supports a conclusion strongly, weakly, or not at all, and an investigation is only as useful as its honesty about which. The course uses one scale for every finding, introduced properly in lesson 12.7 and used from the first module:

Confirmed means two independent sources agree on the key and the time, with their clocks measured. Likely means one source supports it, or two sources that share a weakness. Possible means the evidence fits but so does something else. Not established means no source reaches it at all, and saying so is a finding, not a failure.

You will see these levels in every exercise and case, and the answer guides use them throughout. The exam marks them too: a correct conclusion stated at a level the evidence does not support is marked as an error, because in practice it is one.

A report that says an account was compromised, when the evidence shows only that it logged on from an unusual host, leads to the wrong decisions.

The scale has only four steps on purpose. A scale with more steps invites argument about whether a finding is seventy or eighty per cent, which no evidence can settle; four steps, each with a condition you can check, can be applied the same way by different analysts and checked by a reviewer.

The levels describe the evidence, not the truth. A confirmed finding can still be wrong if both sources were deceived in the same way, and a possible one can still be right. What the level tells a reader is how much weight the evidence can bear, which is what they need to decide what to do.

In practice, attaching a level to every finding changes how you investigate, not just how you write. It makes you ask, for each claim, what the second source would be, and whether you have it. That question is what turns a plausible story into a supported finding, and it is the question the exercises keep asking.

Alongside the commands and figures, the lessons use four kinds of learning aid. Each does a particular job:

A predict asks you to commit to an answer before you see it: how many hosts a command will list, whether two alerts are the same activity, which summary line the evidence supports. You decide, then reveal the output and the reason.

The course has 47 of them. They are most useful when you get one wrong, because the gap between what you expected and what the evidence shows is exactly what the lesson is teaching.

A clip is a short animation for something that changes over time: a capture ring overwriting old files, a lease passing from one device to another, a scope growing pivot by pivot. There is one in each teaching module, 14 in all.

A practice tool asks a set of questions about real records from the pack, laid out in tabs, and checks your answers. Each one tests the judgments a module turns on, with the evidence in front of you. There are 14, one per module, and they are a good check before an exercise.

A mistake card describes a reasonable error, the kind a careful analyst might make, and what to do instead. They are not there to warn you off obvious blunders; they mark the places where the evidence invites a wrong conclusion.

None of the aids replaces running the commands. They are there to make the method stick, and they work best after you have done the work they refer to.

The predicts deserve a particular habit. Write your prediction down, even as a single word, before you reveal the answer. It is tempting to reveal first and decide afterward that you would have got it right; writing it down makes the comparison honest, and the comparison is where the learning is.

The practice tools are graded on the spot and can be taken more than once. Use them as a check after a module's lessons and before its exercise: if a question surprises you, go back to the lesson it draws on before you start the exercise, because the exercise will ask the same judgment with less help.

Each teaching module ends with an exercise, and seven of them are practical cases. Every one has an answer guide in the Phase 0 walkthroughs, 14 guides in all:

Each guide works the exercise end to end: the commands, their outputs with packet numbers and log references, the finding each step settles, a wrong turn a careful analyst might take and what corrects it, the known limitations of the evidence, a scorecard and a model of the record or report the exercise asked for.

Open a guide after you have written your own answers, not before. The exercise is the practice and the guide is the check. Where your answer and the guide's differ, do not adopt the guide's; find the command that settles the difference and run it.

Sometimes the guide's answer holds, and you learn why. Sometimes yours is as well supported, and the difference is one of wording or emphasis, which is fine.

A difference in a host's category, a finding's level or a detection's score is the kind that matters. A difference in how a sentence is phrased is not. The guides are written to make that distinction easy: each finding is stated with the evidence and level that support it, so you can check yours against the same evidence rather than against the words.

Keep your answers. The exercises build on one another, and several later lessons refer back to an earlier exercise's evidence. The capstone, in particular, asks for the same kinds of record the exercises taught, and having your earlier ones to hand makes it easier to see how far your method has come.

The guides are also useful long after you have finished an exercise. Each one is a worked investigation of a realistic incident, with its evidence and limits laid out, and rereading one is a quick way to refresh a method when a similar question arrives at work.

The mistake is common because the lessons are readable on their own, and the outputs look convincing on the page. Reading them gives you the shape of a method; producing them gives you the method. The difference shows in the exercises, where the commands are yours to choose and run, and most of all in the capstone, where nothing is worked for you.

A practical rule helps: do not read past a command you have not run. If you are reading away from your machine, note the lessons to come back to, and run their commands before starting the next exercise.

At the top of the course, before Module 0, sit the Phase 0 resources. They are written for use during the course and after it, when you are investigating something real and need the command, the field or the next step:

The cheatsheets cover each subject: the commands, the fields that matter, and what each source cannot show. The cookbooks are procedures for each kind of investigation, step by step, with what each step must produce and where it branches.

Lab Setup shows you how to build a small lab of your own, with a script you can download, so you can produce your own traffic to practice on. The walkthroughs are the answer guides. And the playbooks say what to do when a particular thing fires: a download alert, a beacon detection, an abuse report, a gap in a sensor.

Phase 0 also holds a practice playground, which gathers the predicts, practice tools and exam in one place, and a page of references: the standards, tool documentation and further reading the course draws on.

The resources are written to the same standard as the lessons: every command run, every claim checked. They are dense rather than long, because they are for looking things up, and they assume you have taken the lesson they draw on. Read them alongside the modules, and keep them open when you work.

Several of the resources build on the course's own scripts, which are in the lab pack: a timeline merger, a beacon and upload detector, a scorer for detections, and a few smaller tools for periods, sizes and paths. The cookbooks show how to use them on evidence other than the course's, and the Lab Setup pages show how to produce that evidence.

None of the resources is required reading before Module 1. Open each when the module it draws on is underway, and come back to it when you need it.

Versions this lesson relies on: Wireshark and TShark 4.6.9; Zeek 9.0.1 (LTS); Suricata 8.0.8; tcpdump 4.99.4.