Building a detection lab you can break

This lesson is not keyed to a single exam objective: it builds the environment the rest of the course practises in. None of it is off-syllabus. The log sources, collection and search you set up here are the logging and telemetry practices of 1.1; the traffic you generate is what 1.2 asks you to analyse; and the SIEM, EDR and packet tooling you install is 1.3. Build it once and every later lesson has somewhere to run.

Why this matters

You cannot learn to spot abnormal without having watched normal for a while. That is the whole problem with studying detection from a book: the examples arrive pre-labelled, with the malicious line already highlighted, which is exactly the part the job does not give you.

A lab fixes that. It is also the cheapest way to answer the questions this course will keep raising — what does this actually look like in a log, how noisy is this detection really, what happens if I try the evasion — without touching anything that matters.

Build it now, before the indicator lessons. Everything after this assumes you have somewhere to try things.

The lesson

A host-only network that cannot reach production

The first requirement is isolation, and it is not negotiable. You are going to run things that behave like malware, and some of them will try to reach out.

Use a host-only or internal virtual network: virtual machines can see each other and the host, and have no route to your LAN or the internet. In VirtualBox this is a host-only adapter; in VMware, a host-only or LAN segment; in Hyper-V, an internal or private switch.

A few rules worth following exactly:

• Give the lab its own subnet, distinct from anything you use in real life, so a misrouted packet is obvious rather than plausible.
• No bridged adapters, even temporarily. The classic mistake is enabling one to install updates and forgetting to remove it.
• Snapshot every VM clean before you do anything else. You will want to return to a known state constantly.
• Do the risky work with networking off entirely where you can. Plenty of analysis needs no network at all.

If you need packages or tools inside the lab, install them while the VM is briefly attached to a NAT network, then detach it and snapshot. Treat that window as a deliberate, bounded exception.

A log source, a collector and a search interface

The minimum useful lab has three parts, and they map exactly onto the three things a real pipeline has.

A log source. One Windows VM and one Linux VM is plenty. On Windows, turn on the logging that matters and is off by default: process creation with command line (Event ID 4688 with the command-line policy enabled), PowerShell script block logging, and ideally Sysmon with a public configuration. Out of the box, Windows will not tell you what a process was launched with, which is the single most useful field you can have.

On Linux, enable auditd or use a modern equivalent, and keep authentication and shell history where you can read them.

A collector. Something that pulls or receives the logs and stores them centrally. This can be as small as a syslog server and a directory of files. The point is that logs leave the machine that generated them — an attacker who owns the host owns its local logs.

A search interface. Anything that lets you ask questions across the whole set at once. A free-tier SIEM, an open-source stack, or in a pinch grep over a collected directory. The interface matters less than the habit of searching centrally rather than reading one machine's logs.

If you build nothing else, build this. Most of what this course teaches is "ask a question across your telemetry", and that requires telemetry in one place.

Generating benign traffic so normal has a shape

This is the step everybody skips, and skipping it is why so many home labs teach bad instincts. In an empty lab, everything is anomalous, so every detection looks brilliant.

Give the lab a routine:

• Log in and out as an ordinary user, at ordinary times.
• Browse a handful of internal pages; copy files around; install something legitimate.
• Run a scheduled task that does something dull every few minutes.
• Leave it running long enough to accumulate a few days of background.

Then go and look at what normal produced. Count the distinct parent-child process pairs. Notice how many outbound connections a freshly booted machine makes before a human touches it. Notice how regular a legitimate scheduled task looks — and how much it resembles the beaconing you will be asked to spot in a later lesson.

That resemblance is the lesson. Baselining is not a formality; it is the thing that stops you escalating a backup agent.

Safely generating malicious-looking traffic

You do not need real malware, and for most of this course you should not use any. What you need is behaviour that looks like the thing you are learning to detect.

Safe and sufficient:

• Atomic-style tests: small, documented commands that emulate a single technique — creating a run key, dumping a process handle, making a DNS query with a long random label. They are readable, reversible and mapped to frameworks you will meet in a later lesson.
• Built-in tooling used the way an attacker would. Living-off-the-land behaviour is genuinely malicious-looking and completely safe, because the binaries are the ones already on the system.
• Traffic generators for beaconing patterns: a script that calls out on a fixed interval with jitter teaches you more about beacon detection than any sample will.
• Deliberately vulnerable applications for the web and vulnerability lessons, kept inside the isolated network.

If you do progress to live samples — and for the malware lesson later you may want to — that is a separate decision with its own rules: a dedicated VM, no shared folders, no clipboard sharing, network off or fully simulated, and a snapshot you revert to immediately afterwards. Never on a machine you care about, and never on a machine that can reach one.

Resetting the lab to a known state

A lab you cannot reset stops being used, because every experiment leaves residue and eventually you stop trusting what you are seeing.

Make reset cheap:

• Snapshot before every experiment, not just at build time. Name the snapshot after what you are about to do.
• Revert immediately afterwards, even when nothing seemed to happen. "Nothing seemed to happen" is exactly what persistence looks like.
• Keep the collector outside the reverted VMs, so your logs survive the revert. This is the detail people get wrong: reverting the endpoint should not erase the evidence you just generated.
• Script the rebuild if you can, so the lab is reproducible rather than precious.

That last point has a professional echo. The reason to keep evidence outside the system being restored is the same reason a real incident acquires evidence before eradication — and you will meet that idea properly in the incident response lessons.

Topics this lesson owns

• [x] A host-only network that cannot reach production
• [x] A log source, a collector and a search interface
• [x] Generating benign traffic so normal has a shape
• [x] Safely generating malicious-looking traffic
• [x] Resetting the lab to a known state