Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
▾
Purple Teaming for Blue Teams: Course Orientation
Module 0
PURPLE TEAMING FOR BLUE TEAMS · MODULE 00
You think your detections fire. Purple teaming proves it.
Your detection rules sit green on the dashboard and you assume they work. Most have never been tested. A rule can be scoped wrong, watching a field the attacker never touches, and it does nothing while looking perfectly healthy, and you find out during the incident. This course removes the assumption: you emulate each attacker technique in a controlled, safe way, watch whether your detection actually fires, fix the ones that don't, and measure your real coverage, across 61 ATT&CK techniques and three SIEMs. You leave with validated detections and a coverage number you can defend. This module shows you what you'll validate, the loop you'll run, and how the course gets you there.
15 modules
foundations to capstone
61 techniques
walked end to end
3 SIEMs
Sentinel, Splunk, Elastic
No prerequisites
every concept built up
Why this course exists
Every SOC has a wall of detection rules and a quiet assumption underneath it: that the rules fire when they should. Most teams have never tested that assumption. A rule can be subtly broken, scoped to the wrong host, parsing a field the attacker doesn't populate, watching for a process name a living-off-the-land technique never spawns, and it sits green on the dashboard contributing nothing. The dashboard says covered. The technique runs anyway. You discover the gap during the incident, which is the most expensive possible time to learn it.
Purple teaming closes that gap by refusing to assume. You take an attacker technique, emulate it in a controlled and safe way, and watch whether your detection actually fires. If it does, you have proof. If it doesn't, you have a specific, reproducible gap and you fix it, then run the technique again to confirm the fix holds. Do that across the kill chain and across your SIEMs and "we're covered" stops being a hope and becomes a measured number with evidence behind it. This course walks 61 ATT&CK techniques end to end, every one emulated, detected, and validated across Microsoft Sentinel, Splunk, and Elastic.
What you will be able to do
This course is built around the detections you can prove at the end, not the techniques you can name. Every module either builds the method or runs a full emulate-detect-validate cycle against real adversary behavior.
Build a purple-team lab
Stand up four environments and three SIEMs: the safe place to emulate attacks and watch exactly what fires.
Emulate the full kill chain
Run every ATT&CK tactic from initial access to impact as controlled emulations with Atomic Red Team and Caldera.
Validate detections one by one
Run the technique, confirm whether the rule fires, and fix the ones that don't, then re-run to prove the fix holds.
Work across SIEMs
Write detections once and translate them across Sentinel, Splunk, and Elastic with Sigma, so coverage isn't tied to one tool.
Measure coverage you can defend
Track results per technique in VECTR and turn "we're covered" into a number with evidence behind every cell.
Run a full-chain exercise
Chain the techniques into the CHAIN-HARVEST capstone and validate detection across an entire intrusion, start to finish.
You also leave with things you keep: validated cross-SIEM detections, an emulation-to-detection map across 61 techniques, a measured coverage baseline in VECTR, and the full-chain CHAIN-HARVEST exercise to re-run as your environment changes.
The loop you will run
Purple teaming is not a one-off exercise; it runs on a loop you repeat for every technique. You emulate the technique, check whether detection fired, tune the detection if it didn't, and measure the result, and you run that loop across three SIEMs so coverage never depends on a single vendor. Atomic Red Team and Caldera emulate the attacks, Sigma lets you write a detection once and translate it across Sentinel, Splunk, and Elastic, and VECTR records what fired so coverage becomes a measured, reportable number.
You build the lab in Module 1 against Northgate Engineering's estate, four environments to attack, a Windows endpoint, an Active Directory domain, a Linux host, and a Microsoft 365 developer tenant, wired into Sentinel, Defender XDR, and your secondary SIEM. The discipline is what carries: emulate, detect, tune, measure works against any SIEM and any technique catalog, so the method applies far beyond these three tools. Sentinel, Splunk, and Elastic are where you run it; proving your coverage instead of assuming it is the skill.
How the course is built
Fifteen modules move through three phases. You build the mindset and the lab, walk the entire ATT&CK kill chain emulating and validating as you go, then chain it all into a full-intrusion capstone.
What you need and who this is for
There are no prerequisites, and every concept is explained the first time it appears. This is a specialist course and it goes deep, but it builds the depth in front of you rather than assuming it. It's for anyone who needs proof rather than assurances: detection engineers who want to know their rules actually fire, SOC analysts and leads who have to show real coverage, and blue teamers who want controlled adversary emulation they can run safely.
A modest home lab
Most of it is free and open source. The one recurring cost is Microsoft Sentinel in your own Azure subscription, roughly $19 to $38 a month while you're actively testing, and new Azure accounts get $200 of credit that covers the first month. Module 1 walks the whole build.
Transferable validation discipline
Emulate, detect, tune, measure works against any SIEM and any technique catalog. The three SIEMs and the tooling are the implementation; proving coverage instead of assuming it is the skill.
How to get the most
Run every emulation in your own lab and record the result in VECTR before moving on. The coverage map you build as you go is the artifact you take to your team.
Do I already know this material?
Six quick scenarios across the full range of this course, from what purple teaming is to validating detection across an entire chain. Answer them to find out where you sit, and whether this course fits or it will sharpen knowledge you already have.
What distinguishes purple teaming from a penetration test?
Purple teaming is just a faster penetration test.
Purple teaming runs red and blue together: you emulate a technique and immediately check whether your detection caught it, to validate and improve detection, not to score a breach.
A pentest asks whether someone can get in. Purple teaming asks whether you would have seen it: emulate the technique, watch the SIEM, and fix what did not fire. The output is proven detection coverage, not a breach report.
Purple teaming only attacks and never involves defense.
There is no real difference.
Your dashboard shows green across your detections. Why is that not the same as being covered?
A rule can be misconfigured, scoped wrong, or watching a field the attacker never touches and so never fire; only emulating the technique proves the detection actually triggers.
A green dashboard shows that rules exist and are enabled, not that they work. The only way to know a detection fires on the real technique is to run the technique and watch it fire, which is exactly what purple teaming does.
It is the same; green means covered.
Green dashboards are always wrong.
Coverage cannot be measured at all.
You emulate a technique with Atomic Red Team and no detection fires, yet the telemetry is present in the logs. What is the right next step?
Conclude the technique is simply undetectable.
Tune or build the detection against the telemetry you can see, then re-run the emulation to confirm it now fires.
Telemetry present plus no alert is a detection gap, not a dead end. You write or fix the rule against the evidence that is already there, then re-emulate to prove it triggers, closing the loop.
Stop emulating that technique.
Assume the SIEM is broken and move on.
You want one detection to work across Sentinel, Splunk, and Elastic without rewriting it three times by hand. What is the right approach?
Write it natively three times and keep them in sync manually.
Only ever support one SIEM.
Author the detection logic in Sigma and translate it to each platform's query language, so one rule maps to all three.
Sigma is a vendor-neutral detection format. Writing the logic once and translating it keeps the three SIEMs in step from a single source, instead of hand-maintaining three copies that inevitably drift apart.
Use the identical query unchanged in all three.
How should you measure your real detection coverage of a tactic?
Count the number of detection rules you have for it.
Ask the SIEM vendor for a coverage score.
Assume full coverage unless proven otherwise.
Track, per technique, whether an emulation actually triggered a detection, recording tested-and-detected versus gaps, for example in VECTR, because rule count says nothing about whether rules fire.
Coverage is a measured fact, not a tally of rules. Recording, per technique, whether an emulation actually fired a detection, and tracking that over time, is the only honest measure, and tooling like VECTR exists to keep that record.
You have validated every individual technique in isolation. Why still run a full-chain emulation?
It is redundant; per-technique testing is enough.
Only to produce a longer report.
A real intrusion chains techniques, and detections that fire in isolation can be missed in sequence through timing, suppression, alert fatigue, or correlation gaps; the chain reveals those.
Attacks are sequences, not isolated moves. A detection that fires alone can be drowned, suppressed, or lost amid the noise of a full chain, so running the whole chain surfaces the gaps that single-technique tests cannot.
Because single techniques never matter.
This course is for you.
You will build a purple-team lab and walk the entire ATT&CK kill chain, emulating each technique, checking whether detection fires, fixing the gaps, and measuring real coverage across Sentinel, Splunk, and Elastic.
You have the fundamentals. The value here is the harder half.
You understand validation and coverage, so the payoff is the back half: the later tactics across the kill chain, cross-SIEM detection with Sigma, coverage measurement, and the full-chain CHAIN-HARVEST capstone.
You handled what purple teaming is, the emulate-detect-tune loop, cross-SIEM detection, and coverage measurement, the senior end of the discipline. Take the course to sharpen what you have, close the gaps you did not expect, and turn strong instincts into proven, measured coverage.
You are a student of this course now, so start by deciding what you want from it. Are you here to prove the coverage you already think you have, to find the specific gaps before an attacker does, or to build a purple-team capability your team doesn't yet run? Name that outcome, then turn it into a study plan: which tactics map to the threats your environment actually faces, how much time you'll give it each week, and what coverage you want to be able to prove by the time you finish.
The rest of Module 0 sets you up to do exactly that. Work through it to see how real incidents unfold, the purple-team mindset, the vocabulary of coverage, and the toolkit you'll use, then build the lab in Module 1 and start walking the kill chain.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
