6.3 Deployment flow


In this section, we’ll take a closer look at the automated deployment flow—how to use the dashboard to provision a complete attack infrastructure setup, including a log server, teamservers, and redirectors.


Automated attack-infrastructure deployment

The dashboard’s built-in logic follows a strict sequence to ensure installation and configuration steps run in the correct order and dependencies don’t conflict. The dashboard handles most of the orchestration, but when you’re doing a fresh deployment, operators should follow this order:

  • Step 1: deploy log server

  • Step 2: deploy teamserver

  • Step 3: deploy redirector

Step A: Provision logserver

When starting a new red team engagement, always begin by deploying a new log server. As mentioned previously, this crucial step ensures separation of sensitive client data.


  1. In the Operation Name field under Deploy Operations ➜ 1. Operation Identity, enter the alias for the new red teaming engagement. This name must be unique and not already used for another operation.


  2. Under 2. Infrastructure Role, select Logging Server.


  3. Then under 3. Component Selection, choose the logging stack you want to use (currently only Grafana with Loki and Alloy is supported). At this point, you should see an automatically generated server name. Log server names follow this format: OperationName-C2FrameWork-LogOption-ServerRole-Number


  4. To start the installation and configuration process, click Deploy Infrastructure. Progress is displayed in the output window.

    Important: After a successful deployment, expand the Provision Success section. At the bottom of the output, you’ll find the Grafana web URL and the username/password to log in.

    If the installation fails at any point, the Deploy Infrastructure button changes to Resume, allowing you to continue from the last completed step. This only works after you’ve resolved the issue that caused the deployment to fail. For troubleshooting guidance—or instructions on what to do if you can’t resolve the issue—see Section 6.4.


Step B: Provision teamserver

After provisioning a log server, you can deploy a new teamserver and connect it to the log server. A single log server can support multiple teamservers.


  1. Enter an existing engagement alias in the Operation Name field for which you want to deploy a new teamserver (the backend will identify the corresponding log server and use it during the installation process).


  2. Under 2. Infrastructure Role, select Teamserver.


  3. Then under 3. Component Selection, choose the attack framework to install (currently only Cobalt Strike is supported). For Cobalt Strike, enter a valid license key in the Cobalt Strike License Key field. At this point, you should see an automatically generated server name. Teamserver names follow this format: OperationName-C2Framework-ServerRole-Number


  4. To start the teamserver installation and configuration process, click Deploy Infrastructure. Progress is shown in the output window below.

    As in Step A, if the installation fails at any point, the Deploy Infrastructure button changes to Resume, allowing you to continue from the last completed step. This only works after you’ve resolved the issue that caused the deployment to fail. For troubleshooting guidance—or instructions on what to do if you can’t resolve the issue—see Section 6.4.


Step C: Deploy redirector

Once you’ve provisioned a log server and at least one teamserver via the Deploy Operation page, switch to the Deploy Redirector page to deploy one or more redirectors and connect them to a teamserver of your choice.


  1. Enter the existing engagement alias in the Operation Name field for which you want to deploy a new redirector (the backend will validate the name, identify the corresponding log server and teamserver, and use them during the installation process).


  2. After the dashboard detects an existing operation, the redirector configuration fields will appear. As a first step, under 1. Operation Discovery, select the teamserver the redirector should connect to (you can leave the log server set to the prefilled value).


  3. Then, under 2. Redirector Configuration, paste your custom malleable.profile into the Malleable Profile field.

    Note: If you don’t provide a custom profile, a default profile is used so the installation can complete successfully. You can always update the malleable.profile manually later on the teamserver and redirector.

    If you provide a custom profile, ensure it includes the required placeholders so the backend can replace them with the correct values. For Cobalt Strike malleable.profile, the required placeholders are (see the default profile for examples of where they’re used):

    • EngagementPlaceholder: replaced with the red team engagement alias

    • KeyStorePlaceHolder: replaced with the https-certificate block

    • DomainNamePlaceHolder: replaced with the redirector’s domain name

    Important: If you use a custom malleable.profile, note that the dashboard updates the teamserver’s profile only when deploying the first redirector. During the first deployment, the dashboard also restarts the teamserver service so the updated profile takes effect. For redirector #2 and onward, the custom malleable.profile is used only for redirector configuration—the dashboard will not automatically update the teamserver profile. If you don’t want to update the teamserver manually, make sure the malleable.profile you use supports multiple redirectors from the start.


  4. In the Beacon Domain field, enter the domain name that will be assigned to this redirector (i.e., the domain your beacon will connect to).


  5. In the Decoy Domain field, enter a domain name to use as a decoy destination for invalid C2 traffic.


  6. In the DigitalOcean API Key field, enter a valid API key for your DigitalOcean workspace so the redirector VPS can be deployed.


  7. To start the redirector installation and configuration process, click Deploy Redirector. Progress is shown in the output window below.

    As in Steps A and B, if the installation fails at any point, the Deploy Infrastructure button changes to Resume, allowing you to continue from the last completed step. This only works after you’ve resolved the issue that caused the deployment to fail.


  8. During the installation, the deployment process will pause and prompt you to update DNS at your domain registrar by pointing the A record for the domain you entered in Step 4 to the public IPv4 address of the newly deployed DigitalOcean VPS. The required details will be shown in the output window at that time.

    Once the DNS change is in place—and you’ve verified it resolves correctly to the public IP address of the VPS (e.g., using dnschecker.org)—click the DNS confirmation button to continue. The installation will then complete, and the redirector will be ready for use.

RT-C2E: Advanced Red Team C2 Infrastructure Engineering

Buy nowLearn more

Course Introduction

  • What is this course about?
  • What you will learn
  • Requirements
  • How the rest of this course is structured

Module 1 - C2 Infrastructure Design

  • Module introduction
  • 1.1 Hosting the infrastructure
  • 1.2 Operator workflow
  • 1.3 Design principles
  • 1.4 Infrastructure blue print
  • Assignment

Module 2 - Build the Core Platform

  • Module introduction
  • 2.1 Virtualization platform
  • 2.2 Debian VM template
  • 2.3 OPNsense platform
  • 2.4 Management server (P1)
  • 2.5 Remote access VPN
  • 2.6 Network firewall
  • 2.7 Remote access gateway
  • 2.8 Fine-grained access control
  • Assignment

Module 3 - On-prem essentials

  • Module introduction
  • mgmt-server-package.zip
  • 3.1 Management server (P2)
  • 3.2 Operator Clients
  • 3.3 Client deployment
  • 3.4 Teamservers
  • 3.5 Cobalt Strike
  • 3.6 Cobalt Strike connectivity
  • 3.7 Mythic
  • 3.8 Mythic logging
  • 3.9 Mythic connectivity
  • Assignment

Module 4 - Cloud essentials & Connectivity

  • Module Introduction
  • 4.1 Redirectors
  • 4.2 Providers & registrars
  • 4.3 VPS deployment
  • 4.4 Restricted VPS access
  • 4.5 RedWarden
  • 4.6 HAProxy
  • 4.7 Nebula
  • 4.8 Lighthouse
  • 4.9 Listener
  • 4.10 Forward C2 traffic
  • Assignment

Module 5 - Expand the Infrastructure

  • Module Introduction
  • 5.1 Centralized logging
  • 5.2 Grafana Loki
  • 5.3 Grafana Alloy C2 logs
  • 5.4 Grafana Alloy CLI logs
  • 5.5 Grafana data analytics
  • 5.6 Edge collectors
  • 5.7 Internal file sharing
  • 5.8 Secure data storage
  • 5.9 Operational attack infrastructure
  • Assignment

Module 6 - C2 Automation

  • Module Introduction
  • dashboard-package.zip
  • 6.1 Management dashboard
  • 6.2 Automated deployment
  • 6.3 Deployment flow
  • 6.4 Troubleshooting
  • 6.5 Guacamole connectivity
  • 6.6 User management
  • 6.7 Deployment cleanup
  • 6.8 Health monitor
  • Assignment

Bonus Content

  • B.1 Notifications via aggressor script

Closing Remarks

  • Course Wrap-Up