Free Cheatsheet

Purple Teaming Cheatsheet

Red with blue, not red versus blue. Run the technique, check the detection fires, close the gap. The purple loop and the attack-to-detection pairing across the kill chain, the practical way to prove your detections actually work. No account needed.

What it is The purple loop Execution Credential access Defense evasion Lateral movement C2 & exfil Coverage scorecard Quick lookup

A detection you have never tested is a hypothesis, not a control, and most detection estates are full of hypotheses, rules written against documentation, never fired in anger, quietly broken or far too narrow. Purple teaming closes that gap: emulate a real technique in a controlled way, watch whether the detection fires, and tune until it does, so that what you believe about your coverage and what is true about it converge. This reference pairs each technique with the detection that should catch it, organized by ATT&CK tactic, so you can work the kill chain methodically rather than testing whatever comes to mind. The detections run in Sentinel and Defender XDR; the attack side stays deliberately at technique level, the goal is validating defenses, not operating offense, and the value to a blue team is entirely in the detection side of each pairing.

What purple teaming is

Red teams find gaps; blue teams build detections; purple teaming is the two working as one loop so the finding and the fix happen together. Instead of an adversarial exercise that ends in a report, you run a technique and immediately answer three questions: did anything detect it, was the alert good enough to action, and if not, what do we change. The point is not to win as attacker or defender but to leave with measurably better coverage than you started with, technique by technique.

Approach	Output
Red team alone	A list of what got through. Gaps found, not closed.
Blue team alone	Detections built, but untested against the real technique.
Purple (together)	Each technique run, detection verified or built, gap closed and re-tested. Coverage that is proven.

The purple loop

Purple teaming is a repeatable cycle, run per technique. The discipline is to finish the loop: emulating without verifying the detection is just attacking, and building a detection without re-testing is just hoping. Each pass leaves one technique provably covered.

Pick a technique. Choose from ATT&CK by relevance to your threat model and your suspected gaps.
Emulate safely. Run the technique in a controlled way (test account, isolated host, known time window) so the signal is attributable to you.
Verify detection. Did a rule fire? Was the alert timely and actionable, or buried and vague?
Measure the gap. No detection, slow detection, or unactionable alert, each is a different gap with a different fix.
Tune and re-test. Build or fix the detection, then run the technique again to confirm it now fires cleanly.

Execution

Execution is where an attacker runs code, and the favored techniques deliberately use trusted, signed tools so that allowlisting and signature checks wave them through: PowerShell with encoded commands, script interpreters, signed LOLBins like certutil and mshta. Because the binary is legitimate, the detection cannot key on the file, it has to read the command line and the behavior, which is exactly what an emulation tests. Running a download cradle, an encoded command, and an AMSI bypass as three separate variants probes three different facets of your coverage, and it is common to find the rule catches one and misses the others, which is precisely the gap purple teaming exists to surface.


// Suspicious PowerShell: encoded command + stealth flags
// Sigma rule: rc-pt-exec-001
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine matches regex @"(?i)\s-e[cnodma]*\s"
| where ProcessCommandLine has_any (
    "-nop", "-NoProfile",
    "-w hidden", "-WindowStyle Hidden",
    "-NonInteractive"
)
| project TimeGenerated, DeviceName, AccountName,
          ProcessCommandLine, InitiatingProcessFileName,
          InitiatingProcessCommandLine
| sort by TimeGenerated desc

Technique to emulate	What the detection keys on
Download cradle	PowerShell with web-download patterns (IEX, DownloadString) in the command line.
Encoded command	-EncodedCommand / base64 in the command line; decode and inspect.
AMSI bypass	Known bypass strings, and the absence of expected AMSI telemetry.

Credential access

Credential access is the technique class worth validating most carefully, because if your LSASS-dump detection does not fire, an attacker walks away with everyone's credentials and you never know. Emulate the dump with a known tool and confirm the detection catches the access to LSASS, not just the tool name, which the attacker will change.


// LSASS dump via known tools
// Sigma rule: rc-pt-cred-001
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where (FileName =~ "mimikatz.exe"
    or ProcessVersionInfoOriginalFileName has "mimikatz")
    or (FileName =~ "procdump.exe"
    and ProcessCommandLine has "lsass")
    or (FileName =~ "rundll32.exe"
    and ProcessCommandLine has "comsvcs"
    and ProcessCommandLine has "MiniDump")
    or ProcessCommandLine has "pypykatz"
| project TimeGenerated, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName

Technique to emulate	What the detection keys on
LSASS dump	A process opening LSASS with read access; suspicious handle/memory access, not just tool names.
SAM/registry dump	Access to the SAM hive or reg save of sensitive hives.
DCSync (where applicable)	Directory replication requests from a non-DC account.

Defense evasion

Defense evasion is the attacker working directly against your visibility, so validating detection here is really validating that the rest of your detections survive an adversary trying to blind them, an evaded AMSI means your script detections never get the telemetry they depend on. The honest and uncomfortable finding is often that the evasion simply succeeds: AMSI is bypassed, ETW is patched, a log is cleared, and the technique that should have generated the signal generates nothing. The lesson that purple teaming drives home is to detect the evasion itself rather than only its downstream effects, because the evasion action is high-signal, there is rarely a legitimate reason to clear the security log or patch ETW, so catching the act of blinding is often more reliable than catching what the attacker does once blind.

Evasion to emulate	Detect the evasion itself
AMSI bypass	Known bypass patterns; gaps where expected script telemetry goes missing.
ETW tampering	Provider disable/patch attempts; sudden telemetry loss from a host.
Event log clearing	Security log cleared (1102): rare, high-signal, almost always malicious.
Defender exclusion add	New AV exclusion paths; an attacker carving out a safe zone.

Lateral movement

Lateral movement is where containment decisions live, every host the attacker reaches widens the incident, so a working detection here is what lets you scope and stop a spread early. Emulate the common methods (WinRM, PsExec, RDP) from an unexpected source and confirm the logon and remote-execution telemetry surfaces it.


// Hunt: WinRM lateral movement: Defender XDR
let admin_accounts = dynamic(["admin.lab", "sccm-svc"]);
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName == "wsmprovhost.exe"
| where InitiatingProcessFileName == "svchost.exe"
| where AccountName !in (admin_accounts)
| project Timestamp, DeviceName, AccountName, AccountDomain, InitiatingProcessCommandLine
| summarize SessionCount=count() by DeviceName, AccountName, bin(Timestamp, 1h)

Technique to emulate	What the detection keys on
WinRM / remote PowerShell	Remote execution telemetry; wsmprovhost spawning processes.
PsExec	Service creation (7045) for a remote-exec service; admin-share writes.
RDP from unexpected source	Type 10 logons from internal hosts that should not initiate RDP.

Command, control, and exfiltration

C2 and exfiltration are the late-stage techniques where detection failure is most costly, the attacker is operating and data is leaving. Emulate a beacon (regular check-ins to a controlled endpoint) and a bulk transfer, then confirm the network telemetry surfaces the pattern: the periodicity for C2, the volume and destination for exfil.


DeviceNetworkEvents
| where Timestamp > ago(1h)
| where RemotePort == 443
| where ActionType == "ConnectionSuccess"
| where InitiatingProcessFolderPath has_any ("\\Temp\\", "\\ProgramData\\", "\\AppData\\Local\\Temp\\", "\\Public\\", "\\Downloads\\")
| where InitiatingProcessFileName !in~ ("OneDrive.exe", "Teams.exe", "chrome.exe", "msedge.exe", "firefox.exe")
| summarize ConnectionCount=count(), DistinctDests=dcount(RemoteIP), FirstSeen=min(Timestamp), LastSeen=max(Timestamp) by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, RemoteIP
| where ConnectionCount > 10
| project FirstSeen, LastSeen, DeviceName, InitiatingProcessFileName, RemoteIP, ConnectionCount

Technique to emulate	What the detection keys on
HTTP/S beaconing	Regular-interval connections to one destination; size consistency.
DNS tunnelling	High-volume or high-entropy DNS to one resolver.
Bulk exfiltration	Large outbound transfer to a rare destination, correlated with prior staging.

These are abbreviated real detections. Each is a detection from the course, paired with the technique it validates. The full versions, the complete kill-chain coverage, the emulation guidance, and the safe-execution methodology, are in Purple Teaming for Blue Teams.

The coverage scorecard

The output of purple teaming is not a pass/fail, it is a coverage map: per technique, whether you detected it, how well, and what you changed. Tracked over time across the kill chain, it shows where your detection is strong, where the gaps are, and whether your tuning is actually improving things. This is the artifact that turns a series of exercises into a measurable defensive posture.

Per-technique result	The gap it names
Detected, actionable	Covered. Record it and move on.
Detected, but noisy/slow	Tuning gap: the signal exists but the alert is not usable. Fix the rule, not the coverage.
Not detected, data present	Detection gap: the telemetry is there, the rule is missing. Write it.
Not detected, no data	Visibility gap: you cannot detect what you do not log. Fix the data source first.

Worked example, the purple loop on LSASS dump

Emulate: on an isolated test host, run a known credential-dumping tool against LSASS in a marked time window. Verify: check whether a detection fired, and whether it keyed on the LSASS access (durable) or just the tool name (the attacker changes that in a minute). Measure: say it fired only on the tool name, that is a tuning gap, the rule is brittle. Tune: rewrite it to detect the suspicious handle/memory access to LSASS regardless of the calling process.

Re-test: run a different dumping tool and confirm the rebuilt rule still fires. Now the technique is provably covered, not just covered against the one tool you happened to test.

Quick lookup

Tactic	Detect on
Execution	DeviceProcessEvents, command line (encoded, download patterns), suspicious parents
Persistence	Registry/startup writes, scheduled tasks, device registration
Credential access	LSASS access, SAM dump, DCSync replication requests
Defense evasion	AMSI/ETW tampering, log clearing (1102), AV exclusion adds
Lateral movement	DeviceLogonEvents, WinRM/PsExec/RDP, service creation 7045
C2 / exfiltration	DeviceNetworkEvents, beacon periodicity, bulk outbound volume

From testing one technique to proving your coverage

This cheatsheet is the loop and the pairings. Purple Teaming for Blue Teams teaches the full discipline: safe emulation across the entire kill chain, the detection for every technique, and building the coverage program that proves your defenses work.

Explore the course