Red Team Operations

A penetration test measures how much is broken. A red team engagement measures whether anyone notices. That is the whole distinction, and nearly everything else follows from it.

The confusion between the two is expensive in both directions: a client expecting broad coverage who gets a single stealthy objective feels short-changed, and a client expecting a detection test who gets a noisy vulnerability sweep learns nothing about their response capability.

Authorization is the whole game

Red teaming operates under written authorization with explicitly agreed rules of engagement, scope, and deconfliction. Evasion tradecraft — including the detection-avoidance below — is covered so defenders can build and test against it. It is not for use outside an authorized engagement, and the authorization is what separates this discipline from the crime it resembles.

Pentest versus red team

	Penetration test	Red team engagement
Goal	Find vulnerabilities across scope	Achieve a defined objective
Coverage	Breadth — test everything in scope	Depth — one path to the goal
Stealth	Usually out of scope	Central constraint
Measures	What is broken	Whether defenders detect and respond
Blue team knows?	Often	No — that’s the test
Output	Findings list	Timeline vs. defender response

Neither is better; they answer different questions. An organization with no vulnerability baseline should pentest first — red teaming a fundamentally broken environment tests response against threats it isn’t ready for and produces a demoralising report that changes nothing.

Engagement design

The design work is where a red team engagement is won or lost, and it happens before any tooling:

• Objectives. Concrete and few: “obtain access to the customer database”, “demonstrate access to the wire-transfer system”. Objectives make the engagement measurable and bound its risk.
• Rules of engagement. What is in scope, what is forbidden, what happens if you find a real incident already in progress, and the stop conditions.
• Deconfliction. A channel to confirm “was that us?” so a real intrusion isn’t dismissed as the exercise — and the exercise isn’t escalated as a real intrusion.
• The white cell. The small group who know the engagement is happening. They can call it off, confirm actions, and protect against the test causing genuine harm.

The stop conditions matter most. An engagement that reaches production data has an obligation to stop and confirm before acting, not to prove the point by causing damage.

Threat-informed emulation

The strongest engagements emulate a specific adversary relevant to the organization rather than testing generic capability. Choosing an actor — from threat intelligence about who actually targets this sector — and emulating its known techniques answers a question leadership actually has: are we ready for the threats we face, not for a red team’s personal repertoire.

This grounds the engagement in ATT&CK: the actor’s known techniques become the plan, and the mapping becomes the report’s spine.

C2 infrastructure and OPSEC

Command-and-control is where red team tradecraft concentrates, because the infrastructure is what defenders hunt:

• Redirectors sit between implants and the team server, so the real infrastructure isn’t exposed by a single caught beacon.
• Domain fronting and categorised domains help blend traffic with legitimate flows, though the techniques and their viability shift constantly.
• Beacon configuration — jitter, sleep, and traffic profile — trades speed for stealth. Fast beacons are convenient and detectable.
• Infrastructure OPSEC — separation, attribution hygiene, and disposability — so burning one component doesn’t burn the operation.

The frameworks (Sliver, Havoc, Mythic) are commodity; the tradecraft of running them undetected is the actual skill, and it is a moving target as detection improves.

Evasion as measurement, not trophy

This is the framing that keeps red teaming honest and defensible. Detection evasion is not the point — it is the instrument. The deliverable is a map of what the organization caught, what it missed, and why.

An engagement that evades everything and reports “we won” has failed at its actual job, which is to improve the defense. The valuable output is granular: this technique was detected immediately, this one fired an alert nobody worked, this one was invisible because the telemetry isn’t collected. Each of those is a detection gap with a specific cause and fix.

Which reframes success. The best possible outcome is not that you achieved the objective undetected — it is that the organization learns exactly where its response breaks, and closes it.

Blue team handoff

The handoff is the entire value, and it is a document most teams underinvest in. It should give the defenders, per technique: what you did, when, what they would have seen, whether they saw it, and where the gap was — telemetry, rule, or triage.

Walking the timeline together beats delivering a PDF. The engagement produced a real adversary timeline in their environment; overlaid on their alert history it shows precisely where detection and response broke, which lands as backlog for detection engineering and rehearsal for incident response.

Measuring an engagement

By defender response, not objectives achieved. The metrics that matter:

• Time to detect each phase — and which phases were never detected.
• Time to respond once detected — detection without response is not defense.
• Which techniques were caught, mapped to ATT&CK for a coverage picture.
• What the gaps were — the durable output that turns into work.

“We achieved the objective in six hours undetected” is a headline. “Initial access was caught in minutes, lateral movement was invisible for four days because east-west traffic isn’t logged” is the finding that changes something.

Where this connects

Red teaming is the offensive half of the purple team loop, producing the detection gaps that become backlog. Its output is a live rehearsal for incident response. And its targeting is threat-informed — which adversary, and why.