39 — Purple Team Drills and Detection Validation

Level: Advanced · Time: ~22 min · Prerequisites: Lesson 38 — Build Your Blue-Team Lab

Why this matters

Most home labs die at the same point: the tools are installed, the attack runs, the alert appears — and nobody ever asks whether the alert would have fired if the attacker had done the same thing slightly differently. Purple teaming is the discipline that answers that question, and it is the difference between a rule collection and a defended network. It is also the single most employable habit in security, because the skill on display is not a tool but a loop: hypothesise, test, measure, improve, record. This lesson turns your lab from a place where things run into a place where you can state, with evidence, what you would and would not catch.

What purple teaming is, and what it is not

Purple teaming means offensive knowledge and defensive detection used in the same room, against the same lab, by people who are trying to improve the defence rather than beat it. The frame is improvement, not victory.

	A red-team engagement	A purple-team drill
Objective	achieve the goal set in the scope, against a live environment	make the detection coverage measurably better
Scoreboard	yes — success or failure against the objective	none — a gap found is a result, not a loss
The attacker's job	win	make the defender better, in real time
Information flow	findings delivered at the end, in a report	shared continuously, while it is happening
Where it runs	the client's environment, under a contract	your lab, with snapshots
Output	a report of what was achieved	tuned rules, a gap register and a coverage view

The last row matters for you personally. In a drill, "the technique worked and nothing fired" is a productive outcome you document; in a red-team report that same sentence is a finding someone has to explain.

The drill loop

One technique per iteration. The cycle is short on purpose — a 90-minute session is four or five complete loops, not one enormous scenario.

Choose one attacker technique from the tactics in Lesson 7, ideally one your threat model says matters.
State the hypothesis: "a detection exists for this, and it will fire, with these fields populated."
Run the test safely in the lab — snapshot first, one technique at a time.
Capture the telemetry, and keep the raw evidence: the alert, the log line, the timestamp, the asset, the account.
Check whether a detection fired. Yes or no, recorded before you interpret anything.
If it fired, validate it: run a benign lookalike and confirm the rule stays quiet, or is clearly explained.
If it did not fire, choose one of three outcomes and write down which: write a rule, accept the gap with a compensating control, or explicitly accept the risk with a reason.
Record the outcome — the drill log entry, the rule change, the gap register update, or the coverage note.

Step 7 is where the value sits. Refusing to decide is how a gap survives for years while everyone assumes someone else covered it.

Choosing a technique, and running it safely

Pick by threat model, not by list order. Ask which actors would plausibly target an organisation of your kind, what they do first, and which of those behaviours your estate could even produce telemetry for. Then map it: a published technique matrix makes this concrete, because the 14 tactics from Lesson 7 run from Reconnaissance to Impact, and most organisations have no coverage at all in several of them.

Tactic (Lesson 7)	A technique worth testing	What a lab run looks like
Execution	Command and Scripting Interpreter (T1059)	run a script through the shell or PowerShell on the lab target
Persistence	Create Account (T1136)	create a local account with the test library's documented test
Persistence	Scheduled Task or Job (T1053)	register a job that runs a harmless command on a schedule
Privilege Escalation	Create or Modify System Process (T1543)	install a service or unit file that starts a trivial process
Credential Access	Brute Force (T1110)	repeated failed authentications against the lab target
Discovery	Network Service Discovery (T1046)	your port scan from Lesson 37, run deliberately as a test
Defence Evasion	Impair Defences (T1562)	disable a lab-only logging component and see whether its silence is noticed
Command and Control	Application Layer Protocol (T1071)	a periodic outbound request to a destination you control in the lab

Running safely is a short list of habits, not a checklist of fear:

Use the community test library and the simulation framework from Lesson 38, against your own lab targets only.
One technique at a time. If three things ran, you cannot attribute the alert to any of them.
Snapshot before, revert after — including when the test looks harmless.
Write down exactly what ran: the test identifier, the command, the target, the timestamp. A result nobody can reproduce is an anecdote.
Read the test before executing it. Some published tests write files, add accounts or clear logs; that is fine in the lab and unacceptable anywhere else.

Detection validation — the three checks

A rule exists, a rule fires when it should, and a rule you trust are three different things. This is where most labs stop: the rule appears in the configuration and is assumed to work. Trust requires three checks, and you run them every time.

Check	What you do	What you must record	What it proves
Forced positive	run the technique and confirm the alert appears	the alert's timestamp, asset and account, and the log line behind it	the detection path works end to end
Forced negative	run something adjacent but benign	that it did not fire, or fired at a low severity with a stated reason	the rule distinguishes behaviour rather than matching a keyword
Time-to-detect	measure from technique execution to alert appearing	the interval, in seconds or minutes	whether you could have responded, not merely whether you would have seen it

Worked example, so the shape is clear: the technique is a new local account on the Linux target; the forced positive gives an alert at 14:02:11 on target-01 for account support1; the forced negative creates a user through your configuration-management tool and confirms the alert either stays quiet or arrives as low severity with "expected" noted; time-to-detect is eleven seconds, because the agent shipped the event immediately and the rule matched on a single record. Eleven seconds is a response-relevant number. Two days, discovered during a monthly review, is not.

[!IMPORTANT] Measure time-to-detect from the technique, not from the alert. An alert that appears in an interface nobody opens has a time-to-detect of infinity, and writing that number down honestly is the most useful thing a first drill produces.

Coverage measurement and what to do with a gap

Turn drill results into a view across the tactics: for each one, what was tested, what fired, what did not, and what is untested.

Tactic	Tested	Fired	Gap	Response
Execution	yes	yes	—	rule retains, positive and negative recorded
Persistence	yes	no	yes	new rule written and validated (see drill 4)
Credential Access	yes	yes	—	rule validated; time-to-detect 40 s
Defence Evasion	no	—	untested	scheduled for next session
Command and Control	yes	no	yes	no sensor visibility: gap logged, compensating control is egress logging

Two distinctions decide what you write in the response column:

Preventive coverage — the technique failed because a control stopped it. Good, and worth recording as a result: a technique that does not work is coverage, even though no alert ever fired.
Detective coverage — the technique succeeded but you saw it. Also good, and it is where a detector earns its keep, because prevention always has a bad day eventually.

A realistic answer for a small team is not "complete coverage". It is: deep in a handful of tactics, blind in others, and honest about which ones are blind. The honesty is the valuable output — an unrecorded blind spot is a shock waiting to happen, while a documented one is a budget conversation.

There are exactly two legitimate responses to a gap, and both are acceptable:

Build a detection — write the rule, run the forced positive and the forced negative, record both.
Document a compensating control and the reason you accept it — "we cannot see this on the host, but the technique requires outbound traffic we log and alert on at the gateway, and we accept the residual risk because the telemetry does not exist on that platform".

What is not acceptable is leaving the cell blank.

What a drill leaves behind

Four artefacts, every time. If a session produced none of them, it produced entertainment.

Artefact	What it contains
Drill log entry	date, technique, target, exact command, expected result, actual result, time-to-detect
Rule change	the rule written or tuned, with the reason, the positive and the negative outcome
Gap register entry	the gap, an owner, and a review date — a gap without an owner is a wish
Coverage summary	the tactic-by-tactic view above, updated with this session's results

The drill log entry, as the one form worth standardising:

DRILL LOG
Date/time:          <when the technique was executed, to the minute>
Tactic / technique: <tactic name> — <technique name and identifier>
Target:             <lab hostname and address>
Command run:        <the exact test or command, copied, not paraphrased>
Hypothesis:         <which rule should fire, and with which fields populated>
Result:             <alert name and timestamp, or: nothing fired>
Time-to-detect:     <interval from execution to alert>
Forced negative:    <the benign lookalike, and what the rule did with it>
Outcome:            <rule written / rule tuned / gap logged / risk accepted>
Artefacts changed:  <rule file, gap register, coverage summary>
Reverted:           <snapshot name restored, yes/no>

A 90-minute agenda that fits a solo practitioner or a pair:

Minutes	Activity
0–5	pick the tactic and technique; write the hypothesis before touching anything
5–10	snapshot the target and the sensor host; note the addresses in use
10–20	state the expected alert, then run the technique using the library's documented test
20–35	search the telemetry: did it fire, which fields, which asset, which account
35–50	forced negative: the benign lookalike, and what the rule did with it
50–65	write or tune the rule if there is a gap; re-run the positive to confirm
65–80	measure time-to-detect; update the coverage summary and gap register
80–90	revert the snapshots, write the drill log entry, and pick the next technique

[!TIP] Keep two consecutive snapshots' worth of time free at the end of a drill. The clean revert is what makes the next session cheap, and the drill log entry is the only part of the session anyone will remember in three months.

This habit is also what makes detection engineering employable. Anyone can list tools; far fewer people can say "I chose a technique from our threat model, wrote a rule for it, forced a positive and a negative, measured time-to-detect at under a minute, and logged the two tactics we cannot see at all". That sentence describes the loop, and the loop is the job — Lesson 47 covers how to present it.

Attack it / Defend it

The attack	How it works	The control that stops it
A rule that was never tested	the detection exists in the configuration and has never matched a real technique	forced positive: run the technique and confirm the alert with its timestamp, asset and account
A keyword rule that fires on everything	it matches a string that normal administration also produces	forced negative: the benign lookalike, and a recorded outcome either way
A blind spot nobody recorded	a tactic with no telemetry and no rule, assumed to be covered	the coverage summary and a gap register with an owner and a review date
Detection that arrives too late to act	the alert exists, but hours or days after the activity	measure time-to-detect from technique execution, then reduce forwarding and matching delay
Practising the same easy technique forever	repeating what fires and feels satisfying, while the hard tactics stay untested	choose next session's technique from the threat model, not from preference
Attacking out of scope "for realism"	running the test against a host outside the lab because it is more representative	written scope, own targets only, and one technique at a time on a snapshotted VM
Losing the evidence of the drill	no log entry, no rule note, so the result cannot be reproduced or defended	the four artefacts, kept with the lab documentation, not in your head
Prevention assumed to be detection	a technique fails, so nobody checks whether the attempt was noticed	record preventive coverage explicitly, and still test whether the attempt left a trace

Key takeaways

Purple teaming is a loop, not a contest. No scoreboard: the attacker's job is to make the defender measurably better, in real time, with everything shared as it happens.
One technique per iteration, snapshot before and revert after, with a written record of exactly what ran so the result is reproducible.
A rule is trusted only after three checks — forced positive, forced negative, and a measured time-to-detect from execution to alert.
Coverage is measured per tactic, and honest blind spots are the valuable output. A gap gets a rule or a documented compensating control with a reason; it never gets left blank.
A failed technique is a result. Preventive coverage is coverage, and it belongs in the record alongside the alerts that fired.

Check yourself

Give two differences between a red-team engagement and a purple-team drill, and explain why a detection gap is a better outcome than a successful compromise in a drill.
A rule fires when you run the technique. What is the second check, and what does it prove that the first does not?
You have no telemetry for one tactic at all. Name the two legitimate responses to that gap and what each one must include.
Time-to-detect is nine hours, because the alert appeared in an interface nobody opens until the next morning. What does that tell you, and which two things would you measure to fix it?
Write the four artefacts a 90-minute drill should leave behind, and explain what an owner and a review date add to a gap register entry.