Free through lesson 3

Purple Team Exercises

Purple teaming, permission and safety rules, emulation plans, running and observing step by step, scenarios on Linux, web, Windows and cloud, fixing and re-testing detections, and metrics that keep it going. In 30 lessons you learn to emulate an attack, investigate its traces, and carry it through to detection and fixes yourself.

Start from lesson 1 Unlock every course

Curriculum

The 30 lessons are grouped into six chapters. Working through from chapter 1 is recommended, but you can also dip into the parts you need. * Standard-library Python runs right in the browser. All commands and logs come from fictional hosts.

Chapter 1 — How purple teaming works (lessons 1–5)

How red and blue share results in the same room, the roles, permission and stop conditions, choosing a goal, and preparing the lab and its telemetry.

1

What this course covers: purple teaming

The capstone of the security track: re-create attacker behaviour in your own lab, then check logs, alerts and response one item at a time and fix what is missing.

Free
2

Roles and running order: red, blue and the facilitator

The three roles in a purple exercise (red, blue, facilitator). Work item by item through announce, run, report, check and judge, with one shared results sheet.

Free
3

Permission, scope and stop conditions (rules of engagement)

The rules of engagement put in writing before an exercise: targets and exclusions, time window, allowed techniques, data handling, stop conditions and contacts.

Free
4

Choosing the goal: starting from the threat model

Write the goal in one sentence, pick behaviours from the threat model, past incidents and threat intelligence, rank them, and keep each session small.

🔒 Basic
5

Preparing the lab and its telemetry

A lab cut off from production but like it. List the logs from each host, confirm a marker reaches the SIEM, align the clocks and make sure you can roll back.

🔒 Basic

Chapter 2 — The emulation plan (lessons 6–10)

Before the exercise, choose the behaviours with ATT&CK and prepare the expected telemetry and rules, harmless procedures, markers and the results sheet.

6

Listing behaviours with ATT&CK

Turn the goals from lesson 4 into ATT&CK technique IDs, order them along the attack flow, and narrow them by whether the lab can reproduce them and log them.

🔒 Basic
7

Writing the emulation plan: expected telemetry and rules

For each step, write down before running it the host, the behaviour, what each log should record and which rule should fire, so the gap shows up afterwards.

🔒 Basic
8

Making steps harmless: markers and cleanup

An exercise reproduces a behaviour and its logs, not the damage. Replace the payload with a marker, keep everything inside the lab, and decide the cleanup and rollback before you start.

🔒 Basic
9

Making results matchable by time and marker

Make sure the red execution log and the SIEM alerts can later be tied together one to one. Sync clocks, write in UTC, and match on three things: marker, source and time window.

🔒 Basic
10

Preparing the results sheet

Record the results of the exercise in a table with one row per step. Split the verdict into detected, log only and no log, and add the delay and notes. Build the empty sheet before the exercise.

🔒 Basic

Chapter 3 — The basic round trip (lessons 11–15)

Running and observing one step at a time, checking that logs arrived, the three verdicts, isolating misses, and telling the exercise apart from a real attack.

11

One step at a time: run, then look

The basic rhythm of a purple exercise. After one step is run, nobody moves on until blue has looked. Keep three records: the signals, the execution log and the observation notes.

🔒 Basic
12

Did the logs arrive? Arrival, delay and gaps

Before looking at alerts, check that the step's logs reached the SIEM. Search by marker, measure delay from event time to ingest time, and spot gaps and parse failures.

🔒 Basic
13

Verdicts: detected, log only, no log

Join the emulation plan, red's execution log, the events and the alerts by marker, or by source and time, and give each step one of three verdicts plus a delay. Steps that were not run get no verdict.

🔒 Basic
14

Isolating the cause of a miss

Split the cause of a miss into six layers: collection, ingestion, parsing, rule conditions, exceptions, and time windows and thresholds. Check them one at a time, starting from the front.

🔒 Basic
15

Deconfliction: telling the exercise from the real thing

Match exercise alerts to steps by marker, source, host and time. Anything that matches no step and is not known normal activity is treated as real: pause and check.

🔒 Basic

Chapter 4 — Working through scenarios (lessons 16–20)

Five scenarios on Linux, the web, Windows and the cloud, each taken once around the loop of emulate, observe, judge, fix and re-run.

16

Linux: SSH password guessing and login

Emulate SSH password guessing followed by a login. The rules fire at the planned pace, but a slow variant slips through; close the gap with a rule that links failures to the success.

🔒 Basic
17

Web: an uploaded script

Emulate an executable script landing in an image upload folder, using a marker file that does nothing. The alert fired but took 17 minutes; trace the delay back to the ingestion interval.

🔒 Basic
18

Linux persistence: cron, systemd and a new account

Emulate three ways of surviving a reboot, each doing nothing but writing a marker. Find the account creation that had no audit rule and the cron rule that only looked at /etc/crontab.

🔒 Basic
19

Windows: account creation, service registration and log clearing

Match Windows service registration, log clearing and an extra account-creation item by event ID, find the step lost because the System log was not forwarded, and re-run.

🔒 Basic
20

Cloud: granting privileges and the audit log

Emulate granting administrator rights to a test identity in the lab cloud account. Compare the audit log with the rule, and fix the gap of a rule that watched only one API name.

🔒 Basic

Chapter 5 — Fixing detection (lessons 21–25)

Close the gaps the exercise found with rule conditions, exceptions and preventive settings, then prove the fix by re-running the steps and updating the coverage map.

21

Fixing rule conditions: widening and narrowing

Steps that ended as "log only" usually mean a rule condition was too narrow. Check the difference in the actual events, then fix the condition without making it too wide or too narrow.

🔒 Basic
22

Tuning, and exceptions that create blind spots

Run rules against normal-period events to find the noisy ones and quiet them with exceptions. Always check against the exercise events that an exception does not also hide an exercise step.

🔒 Basic
23

Re-run to confirm, and turn it into a regression test

A fix is done only when the same step is re-run and the verdict changes to "detected". Keep the exercise events as positive tests so the next change does not break them.

🔒 Basic
24

Stopping it up front: protecting with hardening and detection together

Gaps are not only closed with rules. Change settings so the step cannot succeed, then confirm with a re-run that the attempt is still logged and still raises an alert.

🔒 Basic
25

Updating the coverage map

Move techniques up or down the ATT&CK coverage map from exercise results. Mark one "tested" only if it fired on a lab re-run, and record the date and exercise ID.

🔒 Basic

Chapter 6 — Keeping the exercises going (lessons 26–30)

Reporting results, measuring improvement with metrics, automating validation, and carrying the exercise through to response. The course ends with your own purple exercise plan.

26

Reporting results: the gap table and priorities

Turn the exercise results into a per-step verdict table and a table of gaps to fix. Give each gap an owner, a due date and a priority, and present it differently for each reader.

🔒 Basic
27

Metrics: detection rate, time to detect, time to fix

Three metrics for measuring improvement across exercises. Fix the definitions, compare each round with the same calculation, and do not turn the numbers into the goal.

🔒 Basic
28

Automating validation and keeping it running

Rerun the steps you validated on a schedule and check automatically that the alerts fired. Split the roles between human-led exercises and automated validation.

🔒 Basic
29

Carrying it through to response: combining with tabletop exercises

Extend the exercise beyond the alert into the response. Start a tabletop exercise from the alerts that fired, and check that runbooks and communication actually work.

🔒 Basic
30

Wrap-up: build your own purple exercise plan

Pull the previous 29 lessons into a single exercise plan: purpose, authorisation, scope, steps, verdicts, reporting and the next round. Then look back over the whole security track.

🔒 Basic

With all 30 lessons done, you have completed the security track. Try reconciling an exercise and fixing rules again in the purple labs on the security track page. Membership unlocks every course.