0.1 What This Course Is

Introduction

This module sets out what the course teaches and how to use it. Network evidence is what the wire recorded: the packets that crossed it, the logs sensors wrote about them, and the records firewalls, resolvers, proxies and servers kept as the traffic passed.

An investigator uses it to answer questions an endpoint cannot answer alone: what a host said, to whom, when, how much, and whether anything else on the network did the same.

This course teaches you to use that evidence the way an investigation needs it. You start from something you are handed, find the evidence that can answer it, say what the evidence shows and what it cannot, and write the detection that would catch the same thing sooner next time.

The course has no single case company. Each module has its own lab window and its own exercise, and seven practical cases, each with its own organization, sit where their subject is taught. The last module is a capstone investigation of an incident you have not seen before.

This module has five lessons. This one says what the course is and who it is for. Lesson 0.2 explains how the course is built. Lesson 0.3 sets out the tools and the exact versions the lessons use, and lesson 0.4 installs them with the lab pack.

Lesson 0.5 opens your first capture. The module is free to read, so you can judge whether the course suits you before subscribing. By the end of it your machine is ready for Module 1, and you have run the same commands the lessons run on the same evidence.

Most investigations begin somewhere other than the network. An alert fires on a host, an endpoint timeline shows a process, or someone outside the organization reports something. The network is where those leads are tested, because it records what actually crossed between systems, regardless of what any one system says about itself.

Each of those starting points needs the network for a different reason. An alert needs validating against the traffic it fired on. An endpoint process needs its conversations: where it connected, how often, and how much it sent.

An outside report names an address and a time that only the organization's own records can attach to a device and an account. And a question about data leaving can only be answered, as far as it can be answered at all, from what the network recorded about the transfer.

Network evidence also has a property the endpoint does not: it is hard for an intrusion to change after the fact. A compromised host can lie about itself; it cannot reach back into a sensor on another box and edit what was written there.

That makes network records especially valuable when the question is what really happened, and especially important to understand properly, because their limits are just as real as their strengths.

The course is built around that balance. Every module teaches what a source records and what it misses, so that when you use it, you know how far it reaches.

The balance shows up in small ways throughout. A lesson that teaches a Zeek log also says which traffic Zeek did not see; a lesson that teaches a beacon test also shows the legitimate software that passes it; a lesson that reconstructs a file transfer also asks whether the capture dropped a packet in the middle of it.

None of that is pessimism about network evidence. It is what lets a finding survive the first question a careful reviewer asks.

It also means you will often finish an investigation with a smaller claim than you started with, and that is the point. A finding that says exactly what the evidence supports, and names what would settle the rest, is worth more to the people acting on it than a larger one that falls apart the first time someone checks a capture.

The course is written for people who handle security investigations and want the network half of them done properly:

It does not assume you have opened Wireshark before. Every protocol is explained the first time it matters, and Module 1 teaches the networking an investigator needs rather than assuming it: addresses and ports, the layers a packet carries, how TCP and UDP behave, and where in a network a capture point sits.

If you already know this, the module is quick; if you do not, it is the foundation everything else stands on.

It does assume you are comfortable at a command line. The course's tools are command-line tools, and most of what you do in a lesson is run a command against a capture or a log and read what comes back.

You do not need to be a programmer. Where a lesson uses a short script, it explains every line, and the course's own scripts are in the lab pack for you to read and run.

The course is not written for network engineers looking for performance troubleshooting or certification preparation. Those are different jobs with different questions, and section 5 lists what the course leaves out on purpose.

If you work in a security operations center, the course will change how you handle the alerts that reach you. If you work in incident response, it will give you the network evidence your investigations correlate against. And if you build detection or sensors, it will show you what investigators need those systems to record.

The course is pitched at advanced practice. It moves quickly through material a working analyst already knows, and spends its time on the parts that decide whether an investigation holds up: what a source cannot see, how to join sources honestly, and how to state a finding at the level the evidence supports.

If you are newer to security operations, take the foundations slowly and do every exercise; the later modules assume the habits the early ones build. If you are experienced, the cases and the capstone are where you will find the course's real test.

The course has 14 teaching modules and 112 lessons, in four phases. The order follows how an investigation uses evidence: first how evidence is made and kept, then the investigations it supports, then turning findings into detections and attributing activity to people, and finally the response and a capstone.

The foundations are Module 1, Network Fundamentals for Investigators; Module 2, Collecting and Preserving Network Evidence; Module 3, Packet Investigation with Wireshark and TShark; and Module 4, Network Security Telemetry. They cover what a packet and a log can show, how captures go wrong, how to reconstruct sessions and files, and what Zeek, Suricata and flow records add.

The investigations are Module 5, DNS Investigations; Module 6, Web and Encrypted Traffic; Module 7, Reconnaissance and Exposure; Module 8, Command-and-Control Investigation; Module 9, Lateral Movement and Remote Access; and Module 10, Data Staging and Exfiltration. Each starts from a kind of thing analysts are handed and teaches the evidence and method that answer it.

The third phase is Module 11, Detection Engineering, which builds detections from investigation findings and tests them, and Module 12, Cross-Source Correlation, which joins network activity to devices, processes and accounts. The last phase is Module 13, Scoping, Response and Reporting, and Module 14, Capstone Investigation.

Every module follows the same loop, shown above. That is deliberate: by the capstone, the loop is a habit, and an unfamiliar incident is a matter of running it again with new evidence.

The phases also mark where the course changes pace. The foundations are dense with tools and protocols, because everything later depends on reading them fluently. The investigations are where most of the course's time goes: each module is a kind of question, worked through on its own lab window and tested on an exercise or a case.

The third phase steps back from single investigations to what makes them repeatable and attributable. The last phase puts the whole loop together, first on a module window and then on the capstone.

You can read the modules out of order once the foundations are done; each investigation module stands on its own. But the capstone assumes all of them, and the exam draws on every one.

Six practical cases sit where their subject is taught, and the capstone is the seventh:

Each is a complete investigation in miniature. Each comes with the capture and logs, asset notes for its organization, and questions that lead through the investigation in the order the evidence allows, so working one is practice in the method as well as the subject. Each case has its own organization, its own capture and logs, a set of asset notes and investigation questions.

They cover a malicious download followed by recurring connections, a suspected DNS tunnel among legitimate automated queries, an internet-facing server scanned by many sources, legitimate administration that looks like lateral movement, an unusual cloud upload that needs more evidence before it is called exfiltration, and a capture with packet loss and misleading timestamps.

Two of those cases are designed so that the right answer is not the alarming one. The administration case concludes that the activity was legitimate; the upload case concludes that the evidence supports escalation but cannot establish a compromise. Real investigations end that way often, and an analyst who can only find intrusions is as unreliable as one who never does.

The capstone, in Module 14, begins with a Suricata alert in an organization the course has not used before.

You validate the alert against the traffic, identify the system and activity that began the incident, build a timeline and scope every affected system, correlate with endpoint and identity evidence across a gap in the sensors, recommend a proportionate response, and write a detection tested on a malicious window and a separate benign one.

Every case and exercise has an answer guide in the course's Phase 0 resources, with packet numbers, log references, the alternatives considered and the known limitations. The guides are for after you have answered, and lesson 0.2 explains how to use them.

The cases are also where the course's evidence is least tidy. Lab windows in the teaching lessons are built to show one thing clearly; the cases mix that thing with routine traffic, partial visibility and an explanation that looks right and is not. That is closer to what arrives on a real analyst's desk, and it is why the cases, more than the lessons, are where the skill is built.

A course that teaches everything about networks would teach nothing about investigations. This one leaves several things out deliberately:

Network performance troubleshooting and engineering certifications are different disciplines. They share tools with this course, but they ask different questions: why is this slow, rather than what happened here.

Building and operating a production sensor estate at scale is a job in itself. The course teaches sensor placement, sizing and retention where they affect the evidence an investigation has, because an investigator needs to know why a capture is missing a stretch of time, but it does not teach you to run a fleet of sensors.

Offensive tooling is used only as far as a case needs it to produce realistic traffic, and the course never teaches exploitation. Where an attack appears in a lab window, the lesson is about recognizing its traffic, not reproducing it.

Email protocol analysis was part of an earlier version of this course and is not carried forward. Email investigations rely mostly on message headers and mail-system logs rather than network captures, and other courses cover them.

There is one more thing the course does not do, which is worth stating because other network courses do it: it does not rely on a commercial platform or a particular vendor's console.

Every investigation runs on open-source tools at named versions, against capture files and logs you download and keep. What you learn transfers to whatever tools your organization uses, because the underlying evidence, and the questions you ask of it, are the same.

Leaving these things out keeps the course on its subject. Every hour you spend in it is spent on evidence an investigation uses. If one of the subjects left out is part of your job, the skills here still apply to it: a capture, a log and the question of what each can show are the same whatever the reason you are reading them.

Network evidence connects to most of the rest of security operations, and several other courses go further where this one stops:

The overlaps are intentional. Module 11 builds network detections from investigation findings and tests them on malicious and benign traffic, which is enough to make a finding repeatable; the detection engineering courses treat detection as a discipline in its own right.

Module 12 joins network activity to endpoint processes and accounts; the endpoint courses teach where those records come from and how far they can be trusted. Module 9 shows what Kerberos, NTLM, SMB and WinRM look like on the wire; the Active Directory course teaches how they are attacked and defended.

If you take this course first, the others will feel familiar where they touch it. If you take it after them, it supplies the network evidence their investigations assume someone else has.

The course sits in the investigation and response path. Its natural companion is the incident response course, whose investigations it supplies with the network half of the evidence.

None of the other courses is a prerequisite. This course explains every protocol and tool it uses, and teaches the endpoint and identity records it correlates with as far as an investigation needs them. Where a lesson touches a subject another course covers in depth, it says so in a line, so you know where to go if the subject becomes your job.

The neighbors also explain some of the course's choices. Module 11's detections are written in Suricata and in a small Python script rather than in a SIEM query language, because the detection courses teach those languages and this course needs a detection you can run on the lab pack anywhere.

Module 12's endpoint records are deliberately simple, a list of connections with their process and user, because the endpoint courses teach the full records and this course needs only the join. Where a subject could have been taught here at length, it is taught to the depth the investigation needs and no further.

If you work in a team, the courses also map onto roles. An analyst who triages alerts gets most from Modules 1 to 8 and 11; a responder from Modules 9, 10, 12 and 13; and anyone who reviews investigations from the cases and the capstone.

By the end of the course you can start from an alert or a suspicious connection, reconstruct the activity from packets and logs, establish its scope across hosts and accounts, correlate it with endpoint and identity records, and develop a detection from what you found, tested on real traffic.

You can also say, precisely and without hedging, what the evidence cannot establish, which is the skill the course treats as most often missing.

You also leave with things you built and can keep: the records from every exercise, the detection records from Module 11 and the capstone, a set of scripts the course provides and you will have used, and the Phase 0 resources: cheatsheets for each subject, procedures for each kind of investigation, playbooks for the things that fire, and the answer guides.

The course is estimated at 35 to 40 hours including the labs, and it earns 40 CPE credits. It ends with a question-pool exam drawn across all fourteen modules, with case studies, and a verifiable certificate on a pass. The capstone is the practical assessment; the exam checks the knowledge behind it.

The time estimate assumes you run every command in the lessons yourself, do every exercise before opening its answer guide, and work the capstone properly. Reading the lessons without the lab would take less time and teach much less. The course is designed around doing: the lesson shows a command and its output, and you are meant to produce the same output on your own machine before moving on.

Keep your work as you go. The records you write in the exercises are the material the capstone and the exam draw on, and they are useful long after the course: a set of investigations you have done end to end, each with its evidence and its limits stated.

Lesson 0.2 explains how the course is built: how a lesson works, what the lab pack holds, and how the answer guides, predicts and practice tools fit together.

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