Red Team Engagements

Summary

When planning an engagement, remember that your number 1 goal is to meet the client’s objectives.

Planning and documenting are often overlooked and are crucial to a successful engagement.

Introduction

The key to a successful engagement is well-coordinated planning and communication through all parties involved.

Red team engagements come in many varieties; including:

• Tabletop exercises 
• Adversary emulation
• Physical assessment

Defining Objectives and Scope

Objectives

The key to a successful engagement is clearly defined client objectives or goals. Client objectives should be discussed between the client and red team to create a mutual understanding between both parties of what is expected and provided.

Engagements can be categorized between a general internal/network penetration test or a focused adversary emulation.

• A focused adversary emulation will define a specific APT or threat group to emulate within an engagement.
• An internal or network penetration test will follow a similar structure but will often be less focused and use more standard TTPs¹.

Client objectives will also affect the engagement’s general rules of engagement and scope.

Scope

A client’s scope will typically define what you cannot do or target; it can also include what you can do or target. While client objectives can be discussed and determined along with the providing team, a scope should only be set by the client.

Example:

• Objectives:
  1. Identify system misconfigurations and network weaknesses.
     1. Focus on exterior systems.
  2. Determine the effectiveness of endpoint detection and response systems.
  3. Evaluate overall security posture and response.
     1. SIEM and detection measures.
     2. Remediation.
     3. Segmentation of DMZ and internal servers.
  4. Use of white cards² is permitted depending on downtime and length.
  5. Evaluate the impact of data exposure and exfiltration.
• Scope:
  1. System downtime is not permitted under any circumstances.
     1. Any form of DDoS or DoS is prohibited.
     2. Use of any harmful malware is prohibited; this includes ransomware and other variations.
  2. Exfiltration of PII is prohibited. Use arbitrary exfiltration data.
  3. Attacks against systems within 10.0.4.0/22 are permitted.
  4. Attacks against systems within 10.0.12.0/22 are prohibited.
  5. Bean Enterprises will closely monitor interactions with the DMZ and critical/production systems.
     1. Any interaction with “*.bethechange.xyz” is prohibited.
     2. All interaction with “*.globalenterprises.thm” is permitted.

Rules of Engagement

Rules of Engagement (RoE) are a legally binding outline of the client objectives and scope with further details of engagement expectations between both parties. This document often acts as the general contract between the two parties; an external contract or other NDAs (Non-Disclosure Agreement) can also be used.

Each RoE structure will be determined by the client and red team and can vary in content length and overall sections. Below is a brief table of standard sections you may see contained in the RoE.

Section Name	Section Details
Executive Summary	Overarching summary of all contents and authorization within RoE document
Purpose	Defines why the RoE document is used
References	Any references used throughout the RoE document (HIPAA, ISO, etc.)
Scope	Statement of the agreement to restrictions and guidelines
Definitions	Definitions of technical terms used throughout the RoE document
Rules of Engagement and Support Agreement	Defines obligations of both parties and general technical expectations of engagement conduct
Provisions	Define exceptions and additional information from the Rules of Engagement
Requirements, Restrictions, and Authority	Define specific expectations of the red team cell
Ground Rules	Define limitations of the red team cell’s interactions
Resolution of Issues/Points of Contact	Contains all essential personnel involved in an engagement
Authorization	Statement of authorization for the engagement
Approval	Signatures from both parties approving all subsections of the preceding document
Appendix	Any further information from preceding subsections

Seealso

ROE Template | Red Team Development and Operations

Example: Rules-of-Engagement-NCSA-Facing.pdf (cyberstudents.org)

Campaign Planning

Campaign planning uses the information acquired and planned from the client objectives and RoE and applies it to various plans and documents to identify how and what the red team will do.

The campaign summary we will be using consists of four different plans varying in-depth and coverage adapted from military operations documents.

Type of Plan	Explanation of Plan	Plan Contents
Engagement Plan	An overarching description of technical requirements of the red team.	CONOPS, Resource and Personnel Requirements, Timelines
Operations Plan	An expansion of the Engagement Plan. Goes further into specifics of each detail.	Operators, Known Information, Responsibilities, etc.
Mission Plan	The exact commands to run and execution time of the engagement.	Commands to run, Time Objectives, Responsible Operator, etc.
Remediation Plan	Defines how the engagement will proceed after the campaign is finished.	Report, Remediation consultation, etc.

Seealso

Red team checklist | Red Team Development and Operations

Engagement Documentation

Engagement documentation is an extension of campaign planning where ideas and thoughts of campaign planning are officially documented.

Engagement Plan

Component	Purpose
CONOPS (Concept of Operations)	Non-technically written overview of how the red team meets client objectives and target the client.
Resource plan	Includes timelines and information required for the red team to be successful—any resource requirements: personnel, hardware, cloud requirements.

Concept of Operations

The Concept of Operation (CONOPS) is a part of the engagement plan that details a high-level overview of the proceedings of an engagement; we can compare this to an executive summary of a penetration test report.

The CONOPS document should be written from a semi-technical summary perspective, assuming the target audience/reader has zero to minimal technical knowledge. Although the CONOPS should be written at a high level, you should not omit details such as common tooling, target group, etc.

Below is an outline of critical components that should be included in a CONOPS:

• Client Name
• Service Provider
• Timeframe
• General Objectives/Phases
• Other Training Objectives (Exfiltration)
• High-Level Tools/Techniques planned to be used
• Threat group to emulate (if any)

Example:

Holo Enterprises has hired TryHackMe as an external contractor to conduct a month-long network infrastructure assessment and security posture. The campaign will utilize an assumed breach model starting in Tier 3 infrastructure. Operators will progressively conduct reconnaissance and attempt to meet objectives to be determined. If defined goals are not met, the red cell will move and escalate privileges within the network laterally. Operators are also expected to execute and maintain persistence to sustain for a period of three weeks. A trusted agent is expected to intervene if the red cell is identified or burned by the blue cell throughout the entirety of the engagement. The last engagement day is reserved for clean-up and remediation and consultation with the blue and white cell.

The customer has requested the following training objectives: assess the blue team’s ability to identify and defend against live intrusions and attacks, Identify the risk of an adversary within the internal network. The red cell will accomplish objectives by employing the use of Cobalt Strike as the primary red cell tool. The red cell is permitted to use other standard tooling only identifiable to the targeted threat.

Based on customer security posture and maturity, the TTP of the threat group: FIN6, will be employed throughout the engagement.

Resource Plan

The resource plan is the second document of the engagement plan, detailing a brief overview of dates, knowledge required (optional), resource requirements. Unlike the CONOPS, the resource plan should not be written as a summary; instead, written as bulleted lists of subsections. As with most red team documents, there is no standard set of resource plan templates or documents.

Example:

Operations Plan

Component	Purpose
Personnel	Information on employee requirements.
Stopping conditions	How and why should the red team stop during the engagement.
RoE (optional)	-
Technical requirements	What knowledge will the red team need to be successful.

The operations plan is a flexible document(s) that provides specific details of the engagement and actions occurring. The plan expands upon the current CONOPS and should include a majority of specific engagement information; the ROE can also be placed here depending on the depth and structure of the ROE.

The operations plan should follow a similar writing scheme to the resource plan, using bulleted lists and small sub-sections. As with the other red team documents, there is no standard set of operation plan templates or documents.

The most notable addition to this document is the communications plan. The communications plan should summarize how the red cell will communicate with other cells and the client overall.

Example:

Mission Plan

Component	Purpose
Command playbooks (optional)	Exact commands and tools to run, including when, why, and how. Commonly seen in larger teams with many operators at varying skill levels.
Execution times	Times to begin stages of engagement. Can optionally include exact times to execute tools and commands.
Responsibilities/roles	Who does what, when.

The mission plan is a cell-specific document that details the exact actions to be completed by operators.

How the document is written and detailed will depend on the team; as this is an internally used document, the structure and detail have less impact. Below is a list of the minimum detail that cells should include within the plan:

• Objectives
• Operators
• Exploits/Attacks
• Targets (users/machines/objectives)
• Execution plan variations

Example:

Info

The two plans can be thought of similarly: the operations plan should be considered from a business and client perspective and the mission plan should be thought of from an operator and red cell perspective.

Remediation Plan (optional)

Component	Purpose
Report	Summary of engagement details and report of findings.
Remediation/consultation	How will the client remediate findings? It can be included in the report or discussed in a meeting between the client and the red team.

Related

list
from outgoing([[Red Team Engagements]])
sort file.ctime asc

Resources

• TryHackMe | Red Team Engagements

Footnotes

1. tactics, techniques and procedures describe the methodologies, tools, behavioural patterns and strategies that adversaries use to plan and execute attacks against target networks and organisations. Source: tactics, techniques, and procedures (TTP) - Glossary | CSRC (nist.gov) ↩

2. are simulated events in an operational test. White cards are used when a system is too fragile or operationally critical for the adversarial team to pursue an exploitation, or when the adversarial team is unable to penetrate the system, but there is still a desire to evaluate the ability of the system to react to a penetration. White cards should be used only when necessary. Source: terminology - Penetration Testing Vocabulary - Information Security Stack Exchange. Examples: simulated DDoS attack or simulated malware infection. ↩