Principles of Red Teaming

A penetration test asks "what weaknesses exist?". A red team exercise asks a different question: "if a determined adversary targeted us, could they reach what matters most, and would we notice?" In this lesson you will learn how red teaming differs from the test you already know, what its building blocks are and why it is built on trust, rules and paperwork rather than on tricks.

Pentest or red team?

Imagine a bank wants to know how safe its vault is. It can hire a building inspector who checks every door, lock and camera and writes a long list of weaknesses. That is a penetration test: broad, systematic, in a defined time and scope, usually known to the IT team.

Or the bank can hire a team that behaves like a real burglar crew for several weeks, with a precise goal: "reach the vault and bring back a marked object, without being stopped". That is a red team exercise. The goal is not to list every weakness but to test the entire organization: technology, people, processes and the ability to detect and respond.

Aspect	Penetration test	Red team exercise
Question	Which weaknesses exist?	Can an adversary reach our critical assets, and will we detect them?
Coverage	Broad, as many findings as possible	Narrow, only the path to the objective
Stealth	Usually not required	Often a key element
Who is informed	IT and security usually know	Only a small group knows
Duration	Days to a couple of weeks	Often weeks or months
Main output	List of vulnerabilities and fixes	Attack story, detection gaps and response lessons

Neither is better. A young security program usually needs pentests first. A red team makes sense when the basics are in place and the organization wants to test its detection and response.

Objectives: the "crown jewels"

A red team starts from the client's business, not from technology. Which assets would hurt most if lost? Examples: customer database, payment systems, industrial control systems, intellectual property, the ability to sign software. Together with the client, the team defines objectives such as "obtain read access to a specific protected dataset" or "reach the build system".

The objective makes the exercise measurable. Success or failure is described in business terms: "the adversary reached the target in this many steps, and the security team noticed at step X".

Threat emulation: copying a realistic adversary

Rather than doing whatever the team likes, a good exercise emulates a realistic threat. Threat intelligence tells us which groups target an industry and which behaviors they use, described using the MITRE ATT&CK knowledge base (attack.mitre.org), which you will study in chapter 4. The team builds a scenario from those behaviors: how a realistic adversary might get in, move and reach the target. This makes the exercise relevant and defensible: "we tested what attackers like you actually do".

The documents that make it legal and safe

• Contract and authorization letter: signed by someone entitled to authorize the test on the systems concerned. It states the objectives, period, and what the team may and may not do. Some teams carry a copy during physical activities.
• Rules of engagement (RoE): the detailed rules. Which systems are out of limits? Is social engineering allowed, and against whom? Can the team touch production? What happens if sensitive personal data is found? What are the allowed hours?
• Third-party check: cloud providers, hosting companies and partners have their own policies. You cannot authorize what is not yours to authorize.
• Emergency contacts and a stop procedure: a way to pause everything immediately if something goes wrong, for instance if a production system becomes unstable.

Who knows what: the white cell

Because stealth is part of the test, only a handful of people at the client know about the exercise. This group is often called the white cell (or control group). Its job is to keep the exercise safe: it can answer questions from the red team, prevent the real incident response from escalating to the police or customers by mistake, and decide to stop. A key concept is deconfliction: when the blue team detects something suspicious, the white cell can tell whether it is the exercise or a real attacker, so no one wastes the wrong resources or, worse, ignores a genuine attack because "it must be the red team".

Phases of a typical exercise

1. Preparation: objectives, scope, rules, threat profile, contacts.
2. Reconnaissance and planning: collect information, choose entry options.
3. Initial access: the first foothold, through a technical or human route allowed by the rules.
4. Progression: privilege growth, lateral movement, persistence within the limits of the rules.
5. Objective: the target is reached, or the team documents how close it came.
6. Debrief and report: an attack narrative, the detection timeline, recommendations.

The final phase is the most valuable. The exercise exists to make the organization stronger, not to embarrass anyone.

The red team mindset

• Think in goals and paths, not in tools. You succeed when you chain small weaknesses, as you saw with Active Directory paths in chapter 1.
• Respect the rules above all. An out-of-scope shortcut is a failure, however clever.
• Be quiet and careful. Avoid damage. Do not destroy or leak real data.
• Document everything with timestamps. A good log lets the client replay the exercise and learn from it.
• Be kind in the debrief. People who clicked a link are not the enemy; the system that allowed it is the problem.

What an apprentice can do now

You will not be given a red team engagement on day one. The path is: learn the fundamentals, do well in labs and CTFs, work in a pentest or defensive team, and then specialize. What you can do today is learn the vocabulary, study how real adversary behavior is documented, and practice small, self-contained scenarios in your own lab where you control both sides.

Your turn: write the objective and the limits

Imagine your own lab company "LabCorp" with a fictional file server that holds a file called payroll-demo.txt. Write: (1) one objective for a red team exercise, in business terms; (2) three rules of engagement; (3) one reason a stop procedure is needed.

See a solution

• Objective: "Demonstrate whether an adversary starting from an ordinary employee workstation can read payroll-demo.txt on the file server, and measure whether and when the defenders detect the activity."
• Rules of engagement (examples): only machines in the lab network are in scope; no destructive action or data deletion; the file is read, never copied outside the lab; actions happen only during the agreed time window; any out-of-scope machine discovered must be reported and left untouched.
• Why a stop procedure: if an action makes a server unstable or reveals unexpected real data, the team must be able to pause at once. Safety is more important than the objective.

Portfolio step

Create a folder 03-red-blue in your portfolio and add red-team-exercise-plan.md with your answers, and a short paragraph comparing pentest and red team in your own words. A one-page "exercise plan" for a fictional lab company is a strong sample for entry-level applications.

Now let us meet the other side of the table: the people who defend every day.