Purple Team Exercises: Attack and Defense Together

Imagine a football team where the attackers and the defenders never train together, and only meet on the day of the match. They would learn slowly, and mostly from defeats. A purple team exercise is the joint training session: attackers and defenders sit at the same table, run a technique, watch what the defenses see and improve them on the spot. It is one of the most efficient ways to strengthen a security program.

Why "purple"?

Red and blue make purple. The name is not about a third team but about a way of working: collaboration between offense and defense. In some organizations purple teaming is a one-day workshop; in others it is a continuous practice where every red team finding becomes a detection to build and test.

The problem it solves

In a classic red team exercise, the attackers work in secret and deliver a report at the end. By then, weeks have passed and details are fuzzy. The blue team gets a long list of what went undetected, but often cannot reproduce it. Worse, tension can appear: "you did not catch us" versus "you cheated". A purple approach reduces the distance between the two. Every step is an opportunity to verify detection, immediately.

The basic loop

1. Choose a behavior to test. Take a technique from the MITRE ATT&CK knowledge base (attack.mitre.org), such as a technique for guessing passwords or for abusing a legitimate tool. Pick one relevant to the organization's threats.
2. Agree on the test. The red side explains what it will do at a conceptual level and where. The test is run in a controlled way and in the agreed scope, ideally in a lab or on dedicated test machines.
3. Execute the behavior. The red side performs it with the agreed safe method.
4. Observe. The blue side checks: did a log appear? Did an alert fire? Was it prioritized correctly? Could an analyst understand it?
5. Improve. If not detected, create or tune a detection. If detected but badly, improve the context or the playbook.
6. Retest. Run the behavior again to confirm that the improvement works.
7. Document. Record the result and keep the test so it can be replayed later, for instance after a change in the environment.

This is a cycle, not a one-off. Techniques, tools and the company's systems change; detections silently break. Rerunning the same test regularly shows when a defense stopped working.

A worked example, in words

Take the Kerberoasting idea from chapter 1. The purple team asks: "If someone requested service tickets for many service accounts, would we see it?"

• Before: in the lab, the red side performs the behavior once. The blue side looks for matching events on the domain controller. They find that the relevant events exist but no alert is built for them. Result: logged, not detected.
• Improvement: the blue side writes a rule for "one account requesting service tickets for many different services in a short time", and excludes a known backup tool that legitimately does it.
• Retest: the red side repeats the behavior. This time an alert fires within a minute and includes the account name and source. Result: detected.
• Hardening: both teams also note that moving the service accounts to managed accounts would remove the problem at the root.

Observe the vocabulary. A technique can be not logged, logged but not alerted, alerted but unclear or detected and actionable. Many organizations track this on a coverage map, a table of techniques and their detection status.

A simple results table

Technique tested (lab)	Log source	Status before	Action	Status after
Many service ticket requests	Domain controller	Logged, not alerted	New correlation rule	Detected
Password guessing against one account	Sign-in logs	Alerted, low priority	Raise priority if followed by success	Detected
Use of a legitimate remote admin tool	Endpoint agent	Not logged	Enable the missing log source	Logged, rule in progress

Roles in a purple session

• Facilitator: keeps time, records decisions, makes sure the session stays friendly and focused.
• Red operator: carries out the agreed behavior and explains the logic.
• Blue analyst or detection engineer: examines logs, alerts and playbooks and proposes improvements.
• System owner: ensures that the machines used are safe to test and can answer technical questions.

Cultural rules that make it work

• No blame. The goal is to find gaps while it is safe, not to score points. A gap found in a workshop costs nothing; the same gap found by a real adversary costs a lot.
• Share knowledge both ways. The red side learns what defenders see; the blue side learns how attackers think.
• Keep the safety rules. A purple session is still an authorized exercise: scope, safe methods, written agreement.
• Prioritize by risk. Test the behaviors that matter for your real threats before exotic ones.
• Prefer harmless simulation. The point is to generate the log pattern, not to cause damage. Use test accounts and test machines.

Where purple teaming shines

• Teams with a new SIEM or monitoring tool who need to know what it truly detects.
• Training junior analysts: seeing the real logs of a real behavior is far more memorable than reading a slide.
• Measuring progress: coverage maps over time show whether the security program is improving.
• Smaller organizations that cannot afford long red team engagements but can run a few focused sessions per year.

Limits to remember

Testing isolated techniques does not equal an adversary scenario. A detection that works for a test in a lab may fail in a noisy production environment. And coverage does not mean quality: ticking a box for "detected" on a technique with many variants can create a false sense of security. Purple teaming complements, rather than replaces, pentests and red team exercises.

Your turn: plan a purple session

Using your lab, plan a 90-minute purple session for the behavior "many failed sign-ins on one account followed by a success" (a password guessing pattern). Define: (1) the safe way to generate the log pattern, (2) what the blue side must check, (3) the success criterion, (4) how you would retest.

See a solution

1. Safe generation: use a dedicated test account on a lab machine, deliberately typing wrong passwords a handful of times and then the right one. No real accounts and no production systems.
2. Blue side checks: are failed and successful sign-in events logged with timestamp, user and source? Do they reach the central log platform? Is any alert raised? Is the priority reasonable? Does the playbook say what to do?
3. Success criterion: an alert is raised within a few minutes, with the account and source address visible, and a trained analyst can act with the playbook alone.
4. Retest: after tuning the rule, repeat the same pattern, then a variation (slower pace) to see whether the rule still works, and record both results.

Portfolio step

Write purple-session-report.md in 03-red-blue, using the results table format from this lesson, filled with your lab results for at least two behaviors. Reuse your log_summary.py from chapter 2 as the "detection" for the password guessing pattern. That connects your Python work and your defensive thinking in one artifact.

The final lesson of this chapter looks at structured adversary simulation exercises and the strict framework around them.