LAB · SERIES

Lab 06 – find out whether your lab actually detects anything.

You have a SIEM and an IDS. Neither has proved it works. Atomic Red Team runs one documented technique at a time so you can watch an alert fire, or notice that it never does.

August 1, 20269 min readDaniel A. & Óscar S.

By the end of Lab 05 you had a working environment: an attacker box, a segmented network, a vulnerable target, host-based detection and network-based detection. What you did not have was any evidence that the detection half of it works. A dashboard with no alerts on it looks identical whether you are safe or blind. This lab closes that gap by running known techniques on purpose and checking, one at a time, whether your own tooling says anything.

An untested detection is a guess

Installing Wazuh in Lab 03 gave you a SIEM with a default ruleset, and Lab 05 gave you Suricata with the ET Open signatures. Both arrived with hundreds of rules already enabled, which is easy to read as coverage. It is not. A rule fires only when the log or packet it matches on actually reaches the tool, and in a fresh install a surprising number of interesting events are simply never collected.

The way to find out is to generate the event yourself. That sounds like it needs an attack, but it does not need a real one, and it definitely does not need a target that is not yours. It needs a small, precise, repeatable action whose exact behaviour you already know.

What Atomic Red Team is

Atomic Red Team is a free, open-source library maintained by Red Canary. Each entry, called an atomic, reproduces a single technique from the MITRE ATT&CK matrix in a handful of commands, and each one is published together with the exact commands it will run and a cleanup routine that reverses them.

That last part is what makes it usable here. You are not deploying malware and hoping for the best; you are running a documented action, with a known identifier such as T1087.001, that maps to a specific row in a public matrix. When an alert appears you can say precisely which technique produced it, and when no alert appears you know exactly what you missed.

Install the runner on a target you own

The tests are executed by a companion project, Invoke-AtomicRedTeam, which runs under PowerShell. Install it on a lab VM that is already reporting to your SIEM, so the events have somewhere to go. Take a snapshot of that VM first.

# on the lab VM, in an elevated PowerShell session
PS> IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
PS> Install-AtomicRedTeam -getAtomics

# confirm it loaded
PS> Import-Module invoke-atomicredteam -Force

The snapshot matters more than it sounds. Atomics are small, but they are not simulations: they create local accounts, write scheduled tasks and drop files for real. On a VM you can roll back, that is exactly what you want. On a machine you care about, it is not.

Read the test before you run it

Never execute an atomic you have not read. Every test can print its own plan first, and doing so is half the educational value of the exercise:

# show what T1087.001 would do, without doing it
PS> Invoke-AtomicTest T1087.001 -ShowDetails

# check and satisfy anything the test needs first
PS> Invoke-AtomicTest T1087.001 -CheckPrereqs

# run it
PS> Invoke-AtomicTest T1087.001

# put the machine back the way you found it
PS> Invoke-AtomicTest T1087.001 -Cleanup

T1087.001 is Local Account Discovery: the sort of thing an intruder does in the first minutes after landing on a host, to learn who else has an account on it. It is a deliberately mild starting point. It reads information, changes almost nothing, and still produces exactly the kind of command-line activity a SIEM is supposed to notice.

Technique	What it looks like, and why it is a good first test
T1087.001 Local Account Discovery	Enumerates local users. Almost no side effects, and it exercises whether you are collecting process command lines at all.
T1082 System Information Discovery	Asks the host to describe itself. Noisy in the logs, harmless in effect, and frequently missed by default rules.
T1053.005 Scheduled Task	Creates a persistence mechanism, so it makes a real change. Run this one only once you trust your cleanup step and your snapshot.

Read the result from both sides

Now go and look, in this order. First the SIEM: search Wazuh for events on that host in the minute you ran the test, and see whether anything was flagged rather than merely logged. Then the IDS: most discovery techniques are local and will produce nothing in Suricata, and noticing that silence is itself the lesson. Network detection and host detection see different things, which is precisely why Lab 04 and Lab 05 were worth building separately.

Write down three columns for each atomic you run: the technique ID, whether the raw event was collected, and whether a rule actually alerted on it. Those are three different states, and conflating the last two is the most common mistake people make when they assess their own coverage. An event sitting in the index that nothing matches on will not wake anybody up at three in the morning.

When nothing fires at all

Sooner or later you will run a test, go to the SIEM and find nothing. Resist the urge to treat that as a broken lab. It is the most useful result the exercise produces, and it almost always has the same cause: the data was never collected in the first place.

Check that direction before touching any rules. Is command-line process creation being recorded on the target? Is PowerShell script block logging on? Is the agent forwarding that channel to the manager, or filtering it out? Detection engineering in the real world spends far more time on collection gaps than on clever rule logic, and this is where you get to see why.

Only once you are sure the event arrives does it make sense to ask why nothing matched it. At that point you are writing or tuning a rule against a log you can actually see, which is a much better place to start than guessing.

Where this leaves the series

Six labs in, the environment is no longer just built, it is measured. You know which techniques your setup notices, which ones it records without reacting, and which ones pass through it entirely. That short list is worth more than any dashboard, because it is specific to the lab you own and you produced it yourself.

It is also the honest version of the question everyone asks about security tooling. Not whether it is installed, but what it has been shown to catch.

Legal & scope. Every technique in this series is executed against machines you built, inside a private lab you control. Atomic Red Team makes real changes to the host it runs on, so snapshot the VM first and run the cleanup step afterwards. Running these tests against systems, sites or networks you do not own – or lack explicit written authorization to test – is unlawful in most jurisdictions. The lab exists precisely so you never have to.

Frequently asked questions

What is Atomic Red Team?

Atomic Red Team is a free, open-source library of small attack simulations maintained by Red Canary. Each test, called an atomic, reproduces one technique from the MITRE ATT&CK matrix in a few commands, and ships with the exact steps it runs and a cleanup routine that undoes them. It exists so defenders can check whether their own tooling notices a technique, rather than assuming it does.

Is running Atomic Red Team on my own lab dangerous?

The atomics are deliberately small and documented, and most ship with a cleanup command, but they do make real changes: creating users, writing scheduled tasks, dropping files. Run them only on a lab VM you own, take a snapshot before you start, and always read the test with -ShowDetails before executing it so you know what it will do. Do not run them on a machine that matters to you.

Why did my SIEM not alert when I ran an atomic?

Usually because the data it needs is not being collected. A rule can only match on a log that reaches the SIEM, so the first thing to check is whether the relevant source, such as command-line process creation or PowerShell script block logging, is enabled on the target and forwarded by the agent. A silent run is a finding in itself: it marks a real gap in coverage rather than a failure of the exercise.

Is this red teaming or blue teaming?

Neither on its own. Running a known technique specifically to measure whether defenders see it is usually called purple teaming, because the point is not to win but to produce evidence about detection coverage. Atomic Red Team is built for that loop: you already know the answer to what happened, so the only open question is whether your tooling noticed.