Red Team Tradecraft

Red Team Tradecraft

Red teaming emulates a real adversary to test whether an organization can detect and respond, not just whether a vulnerability exists. This page covers the professional craft at a conceptual level — the frameworks, process, and standards that distinguish authorized red teaming from unauthorized access. It is written for defenders and authorized operators; it intentionally does not provide attack payloads or step-by-step intrusion instructions.

Authorization is the line

Every technique here is legal only under explicit, written authorization (a signed statement of work / rules of engagement) for systems within an agreed scope. The same actions without authorization are crimes (e.g. under the U.S. Computer Fraud and Abuse Act and equivalents elsewhere). No authorization, no engagement.

Adversary emulation vs penetration testing

	Penetration test	Adversary emulation (red team)
Goal	Find as many vulnerabilities as possible	Test detection/response against a specific threat
Scope	Often broad, noisy	Narrow, objective-driven, stealthy
Driven by	Coverage	Threat intelligence (emulate a known actor’s TTPs)
Output	Vulnerability list	Did the blue team detect/respond, and where are the gaps

Emulation plans are built from threat intelligence — pick an actor relevant to the organization and reproduce their tactics, techniques, and procedures.

C2 frameworks (landscape)

Command-and-control frameworks coordinate an engagement. The well-known open-source ones are Sliver (Go), Mythic (modular, multi-language), and Havoc. For defenders, the relevant point is that each has detection signatures — knowing the toolset helps blue teams build detections (see Blue Team Tools).

Infrastructure and operational security

Professional engagements separate test infrastructure from operator identity and reduce attributable indicators — using redirectors, categorized domains, and tuned C2 profiles. This is an application of the OPSEC Framework: the critical information is operator identity and infrastructure, and countermeasures reduce the indicators a blue team would use to attribute the activity. (Conceptual here — the value to most readers is recognizing these patterns defensively.)

MITRE ATT&CK mapping

Document every technique against MITRE ATT&CK so findings speak a language the blue team already uses. Reporting against the ATT&CK Navigator turns an engagement into a concrete map of detection coverage and gaps.

Rules of engagement

Before anything starts, get in writing: scope (in/out), authorized techniques, timing windows, an emergency-stop procedure and contact, handling of unexpected findings (a real in-progress breach, exposed PII, or a third-party system discovered in scope), and data-handling rules. The ROE protects the client, the operators, and any third parties.

Reporting

A red team report drives improvement, so structure it for action: executive summary (business risk), technical narrative (the attack story), ATT&CK mapping, risk-rated findings, prioritized remediation, and an evidence appendix. “We got domain admin” is not a deliverable; “here’s what wasn’t detected and how to detect it” is.

Purple-team handoff

The highest-value output is a purple-team debrief: replay the attack chain with the blue team watching, confirm what their telemetry caught, and fix the gaps together. This converts a point-in-time test into durable detection improvements — see the purple-team workflow in Blue Team Tools.

Related

• OPSEC Framework — the methodology behind operator/infra OPSEC
• Blue Team Tools — the defensive counterpart and detection building
• Cyber Red Teaming — the community’s existing red-team overview
• Threat Modeling — anticipating the techniques to emulate