0.3 The Environment You Will Build

The barrier to practicing this discipline is unusually low, and it is worth stating plainly because most security tooling makes the opposite true.

One binary

The entire product is a single executable. The same file is the server, the client, the offline collector builder and the command-line tool, and which of those it behaves as is decided by how you invoke it.

There is no license, no tier, no feature gated behind a purchase, and no trial that expires. Everything in this course, including the parts most tools reserve for their enterprise edition, is available to somebody working on their own machines.

That has two consequences for how you learn it. You can build the lab this course assumes without asking anybody for anything, which removes the usual excuse for reading about a tool rather than running it. And the deployment you build for learning is architecturally the same as one serving eight hundred endpoints, which means the habits you form transfer rather than needing unlearning.

There is a third consequence that shows up later. Because the tool is free and the barrier is low, a great deal of community material exists, including a large body of contributed artifacts. Module 7 covers how to judge those, and the reason it needs a whole section is the same reason the tool is accessible: anybody can write one, and running somebody else's artifact is running somebody else's code on every machine you point it at.

# The entire barrier to entry, on the machine you are reading this on.
velociraptor gui
#
# A console on localhost, one enrolled client, and everything
# Modules 1 to 4 need, available in about a minute.

The minimum that works

One machine. A server and a client on the same host, which the tool supports directly for development. This is enough for Modules 1 through 4 and for all of Module 3, since the query language does not care how many clients exist. It is also the fastest way to start, since it needs nothing you do not already have in front of you.

Two machines. A server and a separate client. This is the point at which the console stops being an abstraction: a host record describes a machine that is genuinely somewhere else, and a collection genuinely travels.

Three or four. Where Modules 5 and 6 come alive. A hunt against three clients behaves exactly like a hunt against eight hundred in every respect that matters, and with three you can do the thing that teaches the most: leave one powered off, watch the count settle, then turn it on and watch it move without touching the hunt.

Plus one you can break. Module 7 contains a host and reverses it. Doing that on a virtual machine you can restore is comfortable; doing it on the laptop you are reading this on is not, and the section says so.

Virtual machines are entirely adequate throughout. Nothing in this course needs physical hardware, and a mixed set of operating systems is better than a uniform one because several sections turn on the difference.

A Linux server and a Windows client is the most useful pair if you have a choice, because it exercises the cross-platform behavior that a uniform lab hides: preconditions that select a platform, artifacts that exist on one side and not the other, and the deployment differences that make a Linux server the common production choice while most of what you investigate is Windows.

Northgate Engineering

The course investigates a fictional organization, and it is the same one across every module so that findings accumulate rather than resetting.

Northgate Engineering is an 810-person engineering firm with sites in Manchester, Bristol and London. It runs a mixed Windows estate with a handful of Linux servers, a small security team, and the ordinary operational mess of a real company: service accounts with more reach than anybody intended, a deployment tool that touches every machine, laptops that are frequently elsewhere, and an asset inventory that does not quite match reality.

Each of those is load-bearing rather than scenery. The service account is what makes the worked case in Module 7 turn out to be about a credential rather than a laptop. The deployment tool is why prevalence analysis fails in one of Module 6's sections. The laptops are the population every hunt misses. And the imperfect inventory is the reason coverage is a recurring question rather than a number the console can tell you.

The people recur. Priya Sharma and Tom Ashworth work the front line, Marcus Webb is the security architect, Rachel Okafor is the CISO whose approval containment sometimes needs, and Phil Greaves runs IT and owns the systems security wants to collect from.

That last relationship matters more than it sounds. Several sections turn on the fact that the machine you want to collect from belongs to somebody whose priorities are not yours, and an environment with only a security team in it would teach the technical half of this discipline and none of the organizational half.

How the examples were chosen

Everything shown in this course is real, and that constraint shaped the material more than any other decision.

Artifact names and definitions come from the published library. Where a section shows an artifact, it is one that exists, with its actual parameters. One of the more useful moments in the course is reading a real definition and discovering it hashes every executable it lists, which its name does not mention and which makes it far heavier than it appears.

Queries are runnable. The invocations shown are the form you would type, using real functions with real argument names, rather than pseudocode that gestures at the idea.

Output is representative rather than decorative. Where a result is shown, it carries the thing the section is teaching: a process launched with profile loading disabled from a directory no user writes to by hand, a collection reporting as finished with a locked registry hive in its logs, the same host's connections ninety seconds apart with a beacon present in one and gone from the next.

Interface screens are drawn rather than photographed. The console views are rendered as diagrams in the course's own visual language. That keeps them readable, keeps them current when a release moves a button, and means nothing here depends on a screenshot of somebody else's software. The tradeoff is that they are simplified, so treat them as a map of what a screen is for rather than as a picture of what it looks like today.

What the lab cannot give you

Two things, and knowing them prevents a false sense of readiness.

Scale is simulated. Three clients teach every mechanism of a hunt and none of the cost. A collection that is comfortable on three machines and ruinous on eight hundred looks identical in a lab, which is why Sections 5.3 and 7.5 spend their time on the arithmetic rather than on the buttons: the arithmetic is the part a lab cannot show you. The habit those sections teach, measuring per-host cost on a few machines and multiplying before widening, is precisely the habit that makes a lab-sized deployment adequate preparation for a real one.

Adversary behavior is described rather than present. This is not a course with a compromised image to work. What it has instead is the reasoning applied to representative evidence, and a final section that walks one incident end to end so the joins are visible.

That is a deliberate choice rather than a gap being apologized for. A canned image teaches you to find the thing the image contains, and every student finds it, which measures nothing. The skills this course is trying to build are the ones that decide whether a real result means what you think it means, and those are exercised by reasoning about evidence rather than by locating a planted artifact.

If you want adversary behavior in your lab, generate it yourself. Run something from a roaming profile, create a scheduled task pointing at it, make an outbound connection, and then investigate what you did using only the tool. Reconstructing an event whose shape you already know is the fastest way to learn which evidence actually carries a sequence and which merely feels like it does.

Do it on two machines rather than one if you can, with something on the first that touches the second, because the hardest part of this discipline is not finding evidence on a host but establishing that two hosts belong to one story. That is Module 6's whole subject and it is the thing a single-machine lab cannot rehearse.

Before Module 1

You do not need the lab to start. Module 0 and most of Module 1 read perfectly well ahead of building anything, and Section 0.6 covers getting a deployment running when you are ready.

What is worth doing now is deciding which machines you will use, because the sections that need more than one are better experienced than read, and the difference between a course you worked and a course you read is almost entirely in whether the deployment existed while you were reading.