> For the complete documentation index, see [llms.txt](https://blog.r00t-hunter.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blog.r00t-hunter.com/c2-infrastructure/how-to-deploy-your-first-c2-server-havoc.md).
# How to Deploy Your first C2 server Havoc
> **Scope and intent:** This guide covers installing and configuring [Havoc](https://github.com/HavocFramework/Havoc), an open-source, publicly available post-exploitation framework, inside an isolated virtual lab (Kali Linux). It is written for defenders, students, and red-teamers who want to understand how commercial and open-source C2 frameworks are built and operated so they can better detect and defend against them. Only run C2 tooling against systems and networks you own or are explicitly authorized to test deploying it against third-party systems without permission is illegal in most jurisdictions.
***
### 1. What Is a Command-and-Control (C2) Server, Really?
If you've read about ransomware outbreaks, APT campaigns, or red-team engagements, you've almost certainly seen the term "C2" thrown around. At its core, a **Command and Control server** is the piece of infrastructure an attacker (or, in an authorized engagement, a red-team operator) uses to stay in touch with machines they've already compromised.
Once an implant sometimes called an agent, beacon, or "Demon" in Havoc's terminology is running on a target machine, it needs a way to:
* Tell the operator "I'm alive and here's what I can see" (check-in / beaconing)
* Receive new instructions (run a command, move laterally, escalate privileges, harvest credentials)
* Send data back out (command output, files, screenshots)
A C2 server is the piece that sits on the operator's side and brokers that entire conversation.
#### Common C2 architectures
C2 infrastructure isn't one-size-fits-all. A few common patterns:
* **Dedicated team server / client model** (what Havoc, Cobalt Strike, Sliver, and Mythic all use): a central "teamserver" process holds all the session state and listeners, while one or more GUI or CLI clients connect to it this is what lets multiple operators collaborate on the same engagement in real time.
* **Remote Access Trojan (RAT) style backdoors**: a simpler implant that phones home directly to a single listener, often with less operational tooling around it.
* **Botnets**: large fleets of compromised hosts coordinated toward a common goal, like DDoS or spam distribution, usually with much simpler, more resilient C2 channels (IRC, P2P, domain generation algorithms) built for scale rather than interactivity.
#### Why C2 matters operationally
Whether it's used by a criminal group or a red team under contract, the C2 layer is what turns "we got code execution on one box" into an actual campaign: pivoting through a network, escalating privileges, and exfiltrating data all flow through it. Understanding how a C2 framework is built its listeners, its traffic profile, its agent lifecycle is directly useful for defenders, because most detection strategies (network signatures, EDR behavioral rules, threat hunting playbooks) are built around exactly those mechanics.
#### How defenders push back
None of the following stops a determined, well-resourced attacker on their own, but layered together they meaningfully raise the cost of running C2 infrastructure undetected:
* Firewalls and IDS/IPS tuned to catch anomalous outbound beaconing patterns, not just known-bad IPs
* EDR/antivirus focused on behavior (process injection, unusual parent-child process chains) rather than static signatures
* Aggressive patch management to close the initial-access vulnerabilities that get an implant on the box in the first place
* Security awareness training, since a large share of initial footholds still start with phishing
That's really a topic on its own for this post, let's focus on standing up the framework itself so you can see what defenders are actually up against.
***
### 2. Meet Havoc
Havoc is a modern, modular, open-source C2 framework written primarily in Go and C++, with a Qt-based cross-platform GUI client. It's popular in the offensive security community as a free alternative to commercial frameworks like Cobalt Strike, and it ships with:
* A **teamserver**, which hosts listeners, manages agent ("Demon") sessions, and stores engagement data in a local SQLite database
* A **GUI client**, which multiple operators can connect to simultaneously over a websocket connection secured with mutual TLS
* A **profile system** (`.yaotl` files), which lets you configure the teamserver's network behavior, operator credentials, and build toolchain paths from a single config file
Because it's fully open-source, it's an excellent teaching tool: you can read the Go and C++ source, watch the traffic on the wire, and see exactly how a "beacon calling home" actually looks at the network and process level.
***
### 3. Lab Prerequisites
Before starting, you should have:
* A Kali Linux VM (this walkthrough assumes a fairly recent Kali release) with internet access for cloning and building
* At least a few GB of free disk space and a decent amount of RAM compiling Go and C++/Qt components isn't lightweight
* Comfort with the terminal and basic `git`/`make` usage
* **Isolation**: run this in a lab network segment, not on infrastructure connected to production systems or the open internet
***
### 4. Step-by-Step Installation
#### Step 1 : Clone the repository
Open a terminal in your Kali VM and pull down the source:
```bash
git clone https://github.com/HavocFramework/Havoc.git
```
Git will fetch the full repository, resolve deltas, and drop you back at a prompt once it's done:
Move into the new directory and take a look around with `ls` you'll see folders for the client, the teamserver, build profiles, payload templates, and documentation:
```bash
cd Havoc
ls
```
#### Step 2 : Install build dependencies
Havoc's teamserver and client have a fairly long list of dependencies: build tooling, Qt5 for the GUI, Go for the server, and a MinGW cross-compiler toolchain for generating Windows payloads. Install them all in one shot:
```bash
sudo apt install -y git build-essential apt-utils cmake libfontconfig1 \
libglu1-mesa-dev libgtest-dev libspdlog-dev libboost-all-dev \
libncurses5-dev libgdbm-dev libssl-dev libreadline-dev libffi-dev \
libsqlite3-dev libbz2-dev mesa-common-dev qtbase5-dev qtchooser \
qt5-qmake qtbase5-dev-tools libqt5websockets5 libqt5websockets5-dev \
qtdeclarative5-dev golang-go python3-dev mingw-w64 nasm
```
This will take a while on a fresh VM. Once it finishes, you'll see apt finalize its post-install triggers (man-db, kali-menu, etc.):
#### Step 3 : Pre-fetch a couple of Go modules
Move into the `teamserver` directory:
```bash
cd teamserver
ls
```
You'll see the Go source layout `main.go`, a `cmd` and `pkg` directory, `go.mod`/`go.sum`, and an `Install.sh` helper:
A couple of Go modules are worth fetching explicitly before the full build, since they occasionally need a manual nudge depending on your Go version:
```bash
go mod download golang.org/x/sys
go mod download github.com/ugorji/go
cd ..
```
#### Step 4 : Build the teamserver
Back in the Havoc root directory, kick off the server-side build using the provided Makefile target:
```bash
make ts-build
```
This compiles the Go teamserver binary, pulling down its remaining dependencies (cobra, gin, gorilla/websocket, go-sqlite3, and friends) as it goes:
Once the last modules resolve, the build finishes and drops you back at a clean prompt:
I'd recommend splitting your terminal into two vertical panes at this point one for the running teamserver, one for everything else since you'll want to watch the server's debug log while you interact with it.
#### Step 5 : Start the teamserver and build the client
On the left pane, launch the teamserver against one of the bundled connection profiles, with verbose debug logging on:
```bash
./havoc server --profile ./profiles/havoc.yaotl -v --debug
```
Havoc will print its ASCII-art banner and version info, generate a self-signed TLS certificate for the operator connections, and sit listening for client connections:
On the right pane, build the GUI client the same way you built the server:
```bash
cd Havoc
make client-build
```
building the client
Once that's done, launch the client:
```bash
./havoc client
```
You'll be greeted with an empty **Connect** dialog, asking for a profile name and the teamserver's connection details:
#### Read the connection profile to get your credentials
To fill that dialog in, you need three things from the server: the port it's listening on, and a valid operator username/password. All three live in the profile file the teamserver was started with. Open a new terminal and take a look:
```bash
cd Havoc
cd data
ls
```
Then open the profile in a text editor:
```bash
nano havoc.yaotl
```
The file is a straightforward config block. It defines the host/port the teamserver binds to, the build toolchain paths, and importantly the operator accounts and passwords that are allowed to connect:
In the default profile shipped with the repo, you'll find operator accounts like `Spider` and `Neo`, both using the placeholder password `password1234`, and the server bound to port `40056`. **If you use this anywhere beyond a throwaway lab VM, change these credentials before exposing the teamserver on any network** they're intentionally weak example values, not something to run in production.
You'll also need the IP address of your VM. Close the editor and grab it with:
```bash
ifconfig
```
#### Step 7 : Connect the client to the teamserver
Back in the Connect dialog, fill in a profile name of your choosing (I used "Demon," after Havoc's agent type), your VM's IP as the host, and the port/username/password pulled from `havoc.yaotl`:
Click **Connect**. If everything lines up, the client authenticates over the mutual-TLS websocket connection, and you land on the main Havoc dashboard an empty session table, ready for agents, and an Event Viewer confirming the operator connection:
At this point you have a fully functional, self-hosted C2 teamserver and an authenticated operator client talking to it the same foundation used in real red-team engagements, just running entirely inside your lab.
***
### 5. Where to Go From Here
With the teamserver and client running, the natural next steps in a lab environment are generating a payload ("Demon" agent), catching a callback from a lab victim VM, and watching the traffic in Wireshark to see exactly what a beacon looks like on the wire. That's a good foundation for building detection rules of your own you now know what's generating the traffic you're trying to catch.
A final reminder: everything above is intended for an isolated, authorized lab. Running C2 infrastructure against systems you don't own or don't have explicit written permission to test crosses from "learning red-team tradecraft" into unauthorized computer access, which carries serious legal consequences in most countries.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://blog.r00t-hunter.com/c2-infrastructure/how-to-deploy-your-first-c2-server-havoc.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.