// resources · playbook
Red Team Operations Playbook
How to plan, run, and actually learn from a red team engagement — objectives over checklists, and purple over theater.
A red team is not a bigger pentest
The most common mistake we see is treating a red team engagement as a penetration test with a scarier name. They are different exercises with different goals. A pentest is coverage-driven: enumerate an environment, find as many vulnerabilities as possible, and report them so they can be fixed. A red team is objective-driven: pick a specific, high-value outcome an adversary would actually pursue, and find out whether the organization can stop, detect, and respond to someone chasing it.
Both are valuable. But if you ask a red team to "find all the bugs," you have commissioned an expensive pentest and learned almost nothing about how your defenders perform under pressure. The whole point of the exercise is the second question, not the first.
Define the objective
Before any tooling comes out, we answer one question with the client: what would actually hurt? Not "which hosts are vulnerable," but "what outcome would constitute a genuine crisis for this business." The objective might be exfiltrating the customer database, reaching a payment system, obtaining domain admin, or accessing a specific executive's mailbox.
A good objective is concrete, singular, and painful. "Improve our security posture" is not an objective. "Retrieve the file merger-terms.docx from the finance share and prove you had it" is. The sharper the crown-jewel target, the more honest the answer you get about your defenses.
Authorization and rules of engagement
Nothing starts until the rules of engagement are signed. This is not bureaucracy — it is what separates a red team from a crime. The document we agree on covers, at minimum:
- Scope. Which systems, networks, buildings, and people are in play, and which are explicitly off-limits.
- Safe words. An agreed signal that lets an operator caught in a physical or social scenario prove they are authorized without blowing the exercise on the spot.
- Deconfliction. A named point of contact who can confirm, at any hour, whether suspicious activity is us or a real intruder.
- Legal sign-off. Written authorization from someone with the standing to grant it, plus handling rules for any sensitive data we touch.
Get this wrong and even a flawless operation becomes a liability. Get it right and everyone can act decisively, because the boundaries are known.
Choose an adversary and emulate
Generic hacking teaches generic lessons. Threat-informed emulation teaches you whether you can withstand the adversary who is actually likely to target you. We pick a realistic threat profile based on the client's sector and exposure, then model its tradecraft — its preferred initial-access methods, its tooling style, its patience.
Mapping the plan to MITRE ATT&CK keeps the emulation honest and gives the blue team a shared vocabulary. Every technique we intend to use lines up against a tactic and an ID, so the after-action conversation is about specific, named behaviors rather than vague impressions of "getting in."
The execution arc
Execution follows the arc a real intrusion does, patient and deliberate rather than loud:
- Recon. Map the external footprint, the people, and the technology before touching anything.
- Initial access. Get a foot in the door — a phishing pretext, an exposed service, or a physical entry where the scope allows it.
- Foothold. Establish reliable, low-noise access that survives a reboot and a nervous defender.
- Escalation. Move from an ordinary account to the privileges the objective requires.
- Lateral movement. Pivot across the environment toward the crown jewels, quietly.
- Objective. Reach the defined goal and prove it, then stop — the exercise ends at the objective, not at "as much damage as possible."
Where social engineering and physical entry are in scope, they run inside this same arc. Tailgating past a reception desk or a convincing pretext on the phone is often a faster path to a foothold than any exploit, and testing it tells you something no network scan ever will.
The purple turn
The best value in a red team engagement usually comes after the objective is reached. This is the purple turn: we sit down with the blue team and replay the operation step by step. For each action we took, we ask what fired, what should have fired, and what stayed silent.
Then we tune. A detection that missed the lateral movement gets rewritten and re-tested against the same technique until it catches it. A gap in logging gets closed. The goal is not to win — it is to leave the defenders measurably better at spotting the next real intruder, with detections proven against genuine adversary behavior rather than assumed to work.
Measure what matters
A red team report that only says "we got in" is a failure of measurement. The metrics that tell you whether the exercise was worth it are about detection and response, not just access:
- Time to detect. How long from our first action to the first alert a human actually noticed.
- Detections fired. Which of our techniques triggered something, and which passed unseen.
- Gaps remediated. How many of the exposed blind spots were closed and re-tested by the end.
All of it lands in the after-action review — a frank, blameless session where red and blue walk the timeline together. That review, not the moment of compromise, is where an organization gets stronger. A red team that emulates a real adversary, proves a real objective, and hands the defenders a tuned set of detections has done its job. Anything less is theater.