4 min read

Red Team Fundamentals

Foundation

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

Red teaming is for mature security programs. Organizations should have:
  • • An established SOC with 24/7 monitoring
  • • Deployed EDR/XDR solutions
  • • Incident response procedures
  • • Regular vulnerability management
If your organization doesn't have these, start with penetration testing instead.

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-engagementSigned annex with the asset list, stop authority, and deconfliction channel.
Initial accessAn approved, benign foothold on a listed asset — no real credentials collected.
EstablishmentA stable channel plus any persistence initialled in the register, with the removal step written down.
ObjectiveThe path proven end to end with canary data, timestamps, and alert IDs.
Post-engagementEvery 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

Signed authorization from an executive with authority over the systems in scope is what separates a test from a criminal act. Before starting, confirm the asset list, the deconfliction channel, the stop authority, and the indemnity terms — see Rules of Engagement for the red-team annex and the full template.