Skills · learning

Red Team Engagements

Red Team Engagements

What red teaming is

Red teaming uses adversary tactics, techniques, and procedures (TTPs) to test how effectively an organization’s people, processes, and technology prevent, detect, and respond to a realistic threat.

The objective is agreed with the client before the engagement begins. It is not necessarily “obtain administrator access.” Administrative access may be a milestone, but the meaningful result is the business impact that access could enable, such as reaching sensitive information or demonstrating a path toward disrupting an important operation.

The engagement should answer a business question, not just produce a dramatic technical result.

Tactics, techniques, and procedures

These terms describe different levels of detail:

• A tactic is the adversary’s goal, such as credential access or lateral movement.
• A technique is the general method used to pursue that goal.
• A procedure is the concrete implementation used in a particular context.

MITRE ATT&CK uses this structure to describe adversary behavior and to support adversary-emulation planning. A TTP should be connected to a hypothesis, expected evidence, and an operational objective.

Red, blue, and purple teams

The red team performs the authorized simulation or emulation. The blue team monitors the environment, investigates suspicious activity, and responds using the organization’s incident-management processes. A blue team may be an internal security operations center, an IT team, or an external managed security provider.

Telemetry is central to the exercise. If an action leaves no usable evidence, the organization cannot reliably detect or investigate it. The final review should therefore identify gaps in logging, alerting, triage, containment, and recovery, then turn those gaps into improvements.

Emulation and simulation

Adversary emulation models a known adversary or threat profile. Threat intelligence provides the behaviors and constraints that shape the scenario. MITRE’s adversary-emulation plans are examples of this approach.

Adversary simulation is broader. It can test a plausible threat scenario without reproducing one named actor exactly, which gives the team more freedom to evaluate defensive capabilities across a wider set of behaviors.

The distinction is useful, but the terms are sometimes used differently by different training providers. The important practice is to state the scenario, the assumptions, and the behaviors being tested.

Both approaches follow a do-no-harm principle. Ransomware, destructive actions, security-control changes, and other high-impact behaviors should be replaced with safe simulations unless the client has explicitly authorized them in a controlled environment.

Operational security

Operational security describes how likely an action is to be observed by the defender or another party. In a realistic exercise, the red team must balance progress toward the objective with the risk of detection.

This is not permission to hide activity from the client or to bypass agreed controls. It is a property of the scenario that must be defined in the rules of engagement, including how the blue team will be allowed to respond.

Threat intelligence

Threat intelligence describes relevant adversaries, their methods, their targets, and the indicators or behaviors defenders may observe. It helps the red team create a realistic scenario and helps the blue team prepare detection and response hypotheses.

Threat intelligence should shape the exercise rather than become a list of tools to run. The same technique can produce different evidence depending on the operating system, security controls, and implementation.

Attack lifecycle

The Cyber Kill Chain is a useful high-level model, but it is not a complete or universal description of every intrusion. Its stages are:

1. Reconnaissance: collect information about the target.
2. Weaponization: prepare a capability for the intended attack.
3. Delivery: transmit or introduce that capability.
4. Exploitation: trigger a vulnerability or use a weakness.
5. Installation: establish malware or another foothold when applicable.
6. Command and control: communicate with a compromised system.
7. Actions on objectives: pursue the operational goal, such as accessing data or disrupting an operation.

Modern intrusions do not always follow these stages in order, and some stages may be absent. ATT&CK is often more useful for mapping the specific behaviors that occur during an engagement.

Engagement planning

The client and red team should agree on the following before testing begins:

• the business objective and success criteria
• authorized targets, environments, accounts, and time windows
• whether physical, remote, cloud, social-engineering, or wireless activity is included
• permitted techniques and prohibited actions
• whether local or domain privilege escalation is allowed
• whether lateral movement and access to sensitive data are allowed
• whether controlled exfiltration is allowed and what data may be used
• contacts, escalation paths, stop conditions, and emergency procedures
• how the blue team will be notified and how evidence will be handled

These agreements form the rules of engagement. They define responsibilities, relationships, constraints, and the boundaries of the work.

During the engagement

Record actions as they happen. A useful activity log connects each action to the hypothesis it tested, the result, the evidence collected, and the next decision. Terminal history, timestamps, screenshots, request and response artifacts, and relevant tool output can all contribute to the final report.

Evidence should show what happened before, during, and after an important step. It should also be safe to share with the client and should not contain secrets that are unnecessary for the finding.

Actions to avoid

• Do not use untested tooling against production systems.
• Do not use actions likely to crash or destabilize systems unless explicitly authorized and safely controlled.
• Do not use unencrypted command-and-control channels when the exercise does not require that risk.
• Do not exfiltrate restricted data. Use approved test data or a controlled proof of access.
• Do not disable security controls unless that action is explicitly in scope.
• Do not continue after a stop condition or emergency contact instructs the team to stop.

Review prompts

• What business question did the engagement answer?
• Which behaviors were emulated or simulated, and why?
• What evidence should each important action have produced?
• Which detection or response capability failed, and what would improve it?
• Did the exercise remain within the agreed safety boundaries?

This is a living study note. Sources and understanding may change as it is reviewed.