Red Team Fundamentals
Red teaming is goal-oriented adversary simulation: reach an agreed objective against a real defence stack, and measure what the defenders saw while you did it. The objective is the unit of success, not the vulnerability count, which is why an engagement can succeed without a single exploit and fail with a dozen.
Core Principles
1. Goal-Oriented
Success is defined by achieving the objective, not finding vulnerabilities. If you can reach the target through a misconfiguration rather than a CVE, that is a finding about the controls that should have caught you.
2. Stealth Within Agreed Bounds
Remaining unnoticed is what makes the test realistic, but stealth is bounded by the rules of engagement: no disabling client tooling, no clearing logs, no hiding from the deconfliction contact.
3. Realistic Adversary Emulation
Emulate the actor your threat model says is aimed at you — its tooling, infrastructure, and tempo. A generic toolchain produces detections that do not map to any real adversary.
4. Collaboration, Not Confrontation
Red teams exist to improve blue teams. The deliverable is a detection backlog with owners, not a scoreboard, and the defenders who were tested should recognise their own telemetry in the report.
When to Conduct Red Team Operations
- • An established SOC with 24/7 monitoring
- • Deployed EDR/XDR solutions
- • Incident response procedures
- • Regular vulnerability management
Red Team Methodology
Five phases, and each one has a gate: an artefact that must exist before the next phase starts. The gates are the part worth memorising, because every engagement that goes wrong went wrong at one of them.
| Phase | Gate to the next phase |
|---|---|
| Pre-engagement | Signed annex with the asset list, stop authority, and deconfliction channel. |
| Initial access | An approved, benign foothold on a listed asset — no real credentials collected. |
| Establishment | A stable channel plus any persistence initialled in the register, with the removal step written down. |
| Objective | The path proven end to end with canary data, timestamps, and alert IDs. |
| Post-engagement | Every register line removed and evidenced; detection gaps assigned to owners. |
Phase 1: Pre-Engagement
Everything that makes the rest of the engagement legal and safe happens here. The output is a document, not a toolchain.
- Objective stated as an outcome the client cares about, with the evidence that would prove it.
- Rules of engagement signed by the primary and alternate authoriser, with the asset list as an annex.
- Adversary profile selected from the client's own threat intelligence, mapped to ATT&CK techniques.
- Infrastructure inventoried: domains, collectors, certificates, owners, and teardown dates.
- Deconfliction channel and phrase issued to the SOC and help desk before anything runs.
Phase 2: Initial Access
The phase with the most ways to cause harm, so it is the one with the tightest controls. Prefer channels the client can measure over channels that impress.
- Consented phishing or pretexting against an approved pilot group, with no credential capture.
- Physical entry under the agreed escort, insurance, and local-law conditions.
- Perimeter validation limited to proof-of-exposure checks on listed assets.
- Every attempt recorded with a campaign ID so the SOC can correlate reports and alerts.
Phase 3: Establishment
Convert a foothold into something that survives normal operations — then write down how it comes out.
- Command channel on an approved domain, with the beacon interval and transport recorded.
- Persistence only under separately initialled approval, one register line per mechanism.
- Internal reconnaissance scoped to the asset list; unlisted systems are out of bounds even when reachable.
- Credential handling limited to approved test accounts and synthetic secrets.
Phase 4: Objective Completion
The objective proves reach and control response. Take the shortest path that produces evidence, not the most impressive one.
- Move toward the target with the least privilege that works, documenting each hop and its telemetry.
- Demonstrate access to the objective and prove the exfiltration path with canary records.
- Record which controls fired, which did not, and how long detection took at each step.
- Stop at the objective. Continuing past it adds client risk and no finding.
Phase 5: Post-Engagement
The engagement ends when the client can act on it. That means removal evidence first, narrative second.
- Persistence and infrastructure removed, with removal evidence attached to the register.
- Debrief with the defenders who were tested: timeline, decisions, alert latency, blind spots.
- Executive report framed around control gaps and the detection backlog, not the exploit chain.
- Follow-up purple team iterations to confirm the new detections actually fire.
Authorization is the first control, not paperwork
Related Topics
Adversary Simulation
Choosing an actor to emulate and turning it into an ATT&CK-mapped plan.
Rules of Engagement
Scope by asset list, deconfliction, and the stop authority behind every phase.
Internal Pentest
The phase-by-phase internal methodology these gates sit in front of.
Reporting Templates
Executive and technical report structures for the post-engagement deliverables.