What Is Purple Teaming? How to Practice on DefendTheOrg

A red team report lands. It is good work — initial access through a document, a little discovery, credentials pulled off a host, persistence on the way out. Everyone reads the executive summary, everyone agrees it's bad, a few tickets get filed. Six months later the same chain still works, because nobody ever sat down and asked, step by step, would we have seen that?

Purple teaming is the answer to that report. It isn't a job title, and it isn't a third team. It's an exercise — something a security team runs on a cadence, with the people who attack and the people who defend working the same chain together. And it's the newest skill on Defend the Org.

What is purple teaming?

In a purple team exercise, the red team runs an emulated adversary chain — a realistic sequence of techniques, usually modelled on a real threat group — and the defenders go through it one step at a time. For every step, one question: did we see it? If the answer is no, the step doesn't leave the room without a detection. Then the red team runs it again to prove the detection works.

It helps to compare it with the exercises it gets confused with:

• A penetration test asks whether there's a way in. The output is a list of vulnerabilities.
• A red team engagement asks whether the defenders notice and respond — so the defenders usually aren't told it's happening. The output is a report on how far the red team got.
• A purple team exercise asks what the defenders can see and what they can't, with everyone in the room. The output is detections, tuned rules, and a coverage map — not a PDF.

None of them replaces the others. A red team engagement tells you how you'd fare against a real intrusion. A purple team exercise is how you get better at it.

How a purple team exercise works

It starts with a plan. Pick an adversary that plausibly targets you, drawn from threat intelligence rather than whatever technique is trending this week, and write the chain as a list of steps mapped to MITRE ATT&CK. Agree the rules of engagement before anything runs: which hosts are in scope, what is off-limits, who can stop the test, and how a real incident gets told apart from the exercise.

Then it runs in a loop. The red team executes a step. The defenders look for it. Every step gets an outcome — the common ones are blocked, alerted, logged but not alerted, and not seen at all. Each gap gets a fix: a new rule, a tuned one, or a log source that needs onboarding. Then the step runs again.

It ends with evidence. A good exercise produces a coverage map you can defend: which steps were caught, by what, and what changed. The next exercise starts by re-running the last one, so a fix that quietly broke shows up before an adversary finds it.

The skill underneath: making the coverage call

The hardest part of a purple team exercise isn't running the attack. It's answering "did we see it?" honestly. On Defend the Org every step of a report gets one of four calls:

• Detected — the step left telemetry and a deployed rule alerted on that telemetry.
• Logged, not detected — the evidence is sitting in your logs and nothing fired on it. This is the most common gap and the cheapest to close.
• Partial — a rule fires on the report's version of the step but misses a variant, or fires on legitimate activity that looks like it.
• Not logged — no source recorded the step at all. No rule can fix that until the right telemetry is onboarded.

The trap is the alert that fired around the right time. A real SOC queue is mostly unrelated noise, and an alert two minutes after a step, on a different event, isn't evidence that the step was caught. The call comes from the step's own rows and the alerts on those rows — nothing else.

Detections that survive the replay

Say the report shows a Word document starting a script host, and your SOC caught it. The deployed rule says: parent process is winword.exe, process is wscript.exe. Detected. Done?

Now the red team runs it back. The script host is copied and renamed, so the process name no longer matches. Or the document is a spreadsheet, so the parent is excel.exe. Same behaviour, same goal, and the rule misses both. Widen it to just "any wscript.exe" and you catch the spreadsheet but the rename still slips past — and now a legitimate logon script trips it every morning.

The rule that survives describes the behaviour, not a string: an Office application starting a script host, keyed on the binary's original file name rather than whatever it's called today. That's the core lesson of purple teaming. A detection that caught the report has passed one test. A detection that catches the replay is coverage. Try this exact example — it takes about thirty seconds and doesn't need an account.

How to practice purple teaming on Defend the Org

Running a real purple team exercise takes a red team, a SOC, and permission to attack production. Most people learning detection work have none of the three. So we built the defender's half of the exercise into a lab: you get the red team's report and the telemetry it produced, and you do everything that happens at the table.

Each lab grades you on the whole loop:

• The coverage call on every step, made from the evidence.
• The detections you write to close each gap — and whether they stay quiet on the legitimate activity that looks like the attack. Where a deployed rule half-works, you tune it rather than switch it off.
• The replay — hidden variants of each step that your rules have never seen: renamed binaries, different parents, living-off-the-land swaps for the same goal.
• The ATT&CK mapping of what each detection actually covers.
• The blind spot — when a step left no telemetry, picking the log source that would have seen it and onboarding it before you write the rule.

Purple Team launches with six labs: three Easy, two Medium, and one Hard. Easy labs show you the ATT&CK tactic on each step and tell you how many detections to write. By Hard, the SOC queue is full of alerts from across the estate that have nothing to do with the chain, some of them on the same host minutes from a real step, and you aren't told how many detections the lab needs — your rule set is graded as a whole.

If you're new to this, start with the Purple Team Beginner track: short lessons on reading a report and making the call, then three labs in order. Every Easy and Medium lab has a walkthrough that goes one hint at a time and never touches your score. And there are 100 Purple Team questions in Drills — rules of engagement, test outcomes, telemetry gaps, tuning, ATT&CK mapping — for the days you have ten minutes rather than an hour.

Your mentor for all of it is The Dualist: a former red team operator who got tired of handing over reports nobody acted on, and now treats any detection keyed on a filename as one that hasn't been tested yet.

Who it's for

• Detection engineers who want to know whether their rules hold up against the technique, not just the sample.
• SOC analysts moving toward detection work — purple teaming is the fastest way to learn what a good rule has to survive.
• Red teamers who want to see their work from the other side of the wire.
• Anyone preparing for a detection engineering interview, where "how would you know this rule works?" is the question that separates candidates.

It pairs naturally with Detection Engineering, which teaches writing the rule; Purple Team teaches proving it. And if you missed the last round of launches, here's what else we've added since launch.

Ten skills, one question

Purple Team makes ten skills on Defend the Org. It's the one that asks the question every other skill eventually runs into: you wrote the detection — would it catch the attack done slightly differently? See how the Purple Team labs work, or start training and close your first gap today.