Section NameSection Details
Executive SummaryAn overarching summary of all contents and authorization within the RoE document.
PurposeDefines the purpose of the RoE document and its intended use.
ReferencesAny references used throughout the RoE document (e.g., HIPAA, ISO standards).
ScopeStatement of the agreement to restrictions and guidelines within the engagement.
DefinitionsDefinitions of technical terms used throughout the RoE document to ensure clarity.
Rules of Engagement and Support AgreementDefines obligations of both parties and general technical expectations of engagement conduct.
ProvisionsDefine exceptions and additional information from the Rules of Engagement.
Requirements, Restrictions, and AuthorityDefine specific expectations of the red team cell and outline its authority.
Ground RulesDefine limitations of the red team cell's interactions and conduct during the engagement.
Resolution of Issues/Points of ContactContains all essential personnel involved in an engagement and points of contact for issue resolution.
AuthorizationStatement of authorization for the engagement, indicating approval to proceed.
ApprovalSignatures from both parties approving all subsections of the preceding document.
AppendixAny further information from preceding subsections, such as additional details or supporting documentation.

Types of Plans

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.

Components and Purposes

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.

Personnel: Information on employee requirements.

Stopping Conditions: How and why should the red team stop during the engagement.

RoE (optional): Technical requirements for the red team's success.

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.

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.

Cyber Kill Chain


  • No identified TTPs, use internal team methodology


  • Command and Scripting Interpreter
    • PowerShell
    • Python
    • VBA
  • User executed malicious attachments


  • Exploit Public-Facing Applications
  • Spearphishing


  • Registry modification
  • Scheduled tasks
  • Keylogging
  • Credential dumping


  • Ingress tool transfer
  • Proxy usage

Command & Control:

  • Web protocols (HTTP/HTTPS)
  • DNS

Actions on Objectives:

  • Exfiltration over C2

Best Practices

  • Identify critical information: Critical information includes, but is not limited to, red team’s intentions, capabilities, activities, and limitations.
  • Analyse threats: Threat analysis refers to identifying potential adversaries and their intentions and capabilities.
  • Analyse vulnerabilities: An OPSEC vulnerability exists when an adversary can obtain critical information, analyse the findings, and act in a way that would affect your plans.
  • Assess risks: Risk assessment requires learning the possibility of an event taking place along with the expected cost of that event.
  • Apply appropriate countermeasures: Countermeasures are designed to prevent an adversary from detecting critical information, provide an alternative interpretation of critical information or indicators (deception), or deny the adversary’s collection system.

Steps for Establishing C2 Beaconing

Stageless Payload

  1. The Victim downloads and executes the Dropper.
  2. Beaconing to the C2 Server begins.

Staged Payload

  1. The Victim downloads and executes the Dropper.
  2. The Dropper calls back to the C2 Server for Stage 2.
  3. The C2 Server sends Stage 2 back to the Victim Workstation.
  4. Stage 2 is loaded into memory on the Victim Workstation.
  5. C2 Beaconing Initializes, and the Red Teamer/Threat Actors can engage with the Victim on the C2 Server.

C2 Beaconing in Restricted Network Segment

  1. The Victims call back to an SMB named pipe on another Victim in a non-restricted network segment.
  2. The Victim in the non-restricted network segment calls back to the C2 Server over a standard beacon.
  3. The C2 Server then sends commands back to the Victim in the non-restricted network segment.
  4. The Victim in the non-restricted network segment then forwards the C2 instructions to the hosts in the restricted segment.

Domain Fronting Process

  1. The C2 Operator has a domain that proxies all requests through Cloudflare.
  2. The Victim beacons out to the C2 Domain.
  3. Cloudflare proxies the request, then looks at the Host header and relays the traffic to the correct server.
  4. The C2 Server responds to Cloudflare with the C2 Commands.
  5. The Victim then receives the command from Cloudflare.

C2 Profiles Process

  1. The Victim beacons out to the C2 Server with a custom header in the HTTP request, while a SOC Analyst has a normal HTTP Request.
  2. The requests are proxied through Cloudflare.
  3. The C2 Server receives the request and looks for the custom header, and then evaluates how to respond based on the C2 Profile.
  4. The C2 Server responds to the client and responds to the Analyst/Compromised device.


  • Confidentiality: Ensures that only the intended persons or recipients can access the data.

  • Integrity: Aims to ensure that the data cannot be altered; moreover, we can detect any alteration if it occurs.

  • Availability: Aims to ensure that the system or service is available when needed.

  • Disclosure: The opposite of confidentiality. In other words, disclosure of confidential data would be an attack on confidentiality.

  • Alteration: The opposite of Integrity. For example, the integrity of a cheque is indispensable.

  • Destruction/Denial: The opposite of Availability.

Additional Concepts

  • Authenticity
  • Repudiation
  • Vulnerability
  • Threat
  • Risk
  • Depth
  • Trust but verify
  • Zero trust