Havoc C2

Build, configure, and use the Havoc C2 teamserver with the Demon agent through the Apache redirector.

Havoc is a modern open-source C2 framework developed by Paul Ungur (5pider) with a focus on evasion and advanced post-exploitation techniques. It features a Qt-based GUI client that connects to a remote teamserver — similar in model to Cobalt Strike. Havoc’s agents (called Demons) are written in C and include features like indirect syscalls and sleep obfuscation, making it well-suited for practicing modern detection and evasion techniques.

Access model: The Havoc GUI client runs directly on the Havoc server inside an XFCE4 desktop session. You access it through Guacamole via VNC — no local client install is required.

Unlike Mythic and Sliver, Havoc is not pre-built. The Go compiler, Havoc source, and Qt5 GUI client are compiled on first use. This is a one-time step that takes 15–25 minutes. SSH and VNC are available immediately after boot; the build runs as a manual step.

The goal here is not to learn Havoc. The objective is to confirm the environment works end-to-end: get a Windows .exe Demon calling back through the redirector. Once you have a callback, the lab is proven functional. For full documentation, see the Havoc Framework docs.

Step 1: Build Havoc

Connect to the Havoc server via Guacamole → Havoc C2 Server (SSH), then run the build script:

~/build_havoc.sh

The script logs everything to ~/havoc_build.log. It is safe to re-run if anything fails.

What the build script does:

1. Installs Go 1.22.5 to /usr/local/go/
2. Clones the latest Havoc release from GitHub to /opt/Havoc/
3. Copies the pre-configured teamserver profile to /opt/Havoc/profiles/default.yaotl
4. Builds the teamserver binary: /opt/Havoc/teamserver/teamserver
5. Builds the Qt5 GUI client: /opt/Havoc/client/Havoc
6. Creates the havoc-client wrapper script at /usr/local/bin/havoc-client
7. Enables and starts the havoc systemd service

When complete, the terminal shows:

===== Havoc Build Complete ...

  Teamserver:   sudo systemctl status havoc
  Profile:      /opt/Havoc/profiles/default.yaotl
  Client:       havoc-client client
  VNC:          Reconnect via Guacamole — client autostarts on desktop

You can monitor progress in a separate terminal while the build runs:

tail -f ~/havoc_build.log

Step 2: Verify the teamserver

The build script starts the teamserver automatically. Confirm it is running:

sudo systemctl status havoc

The teamserver listens on port 40056 using the profile at /opt/Havoc/profiles/default.yaotl.

Operator credentials (same lab password used across all machines — retrieve from terraform output deployment_info):

Field	Value
Username	operator
Password	<lab-password from deployment_info>

If the teamserver starts and immediately crashes, a stale database from a previous deployment may be the cause. Delete it and restart:

rm /opt/Havoc/teamserver/data/teamserver.db
sudo systemctl restart havoc

Step 3: Connect the Havoc client

Havoc has two separate Guacamole connections. Havoc C2 Server (SSH) gives terminal-only access for checking service status and logs. Havoc C2 Desktop (VNC) opens the full XFCE4 desktop where the GUI client runs. The Havoc client can only be used from the VNC session.

In the Guacamole portal, click Havoc C2 Desktop (VNC). An XFCE4 desktop loads.

Double-click the Havoc Client icon on the desktop. If prompted that the file is not executable, click Mark Executable, then double-click again to launch.

If the desktop icon is not present, open an XFCE terminal and run:

havoc-client client

When the login dialog appears, enter:

Field	Value
Name	operator
Host	localhost
Port	40056
Username	operator
Password	<lab-password>

Step 4: Create a listener

Before creating the listener, retrieve your X-Request-ID token — it gets baked into the Demon at generation time:

terraform output deployment_info
# Look for: C2 Header: X-Request-ID: <token>

In the Havoc client, navigate to View → Listeners → Add and configure the following fields:

Field	Value
Payload	Http
Hosts	yourdomain.tld — or <REDIR_PUBLIC_IP> for closed/IP-only environments — then click Add
Host (Bind)	0.0.0.0
PortBind	80
PortConn	80
Uris	/edge/cache/assets/update — then click Add (all URIs must start with /edge/cache/assets/)
Headers	X-Request-ID: <token> — then click Add (no quotes around the token value)

Click Save.

The Hosts value is the callback address baked into the Demon. The Uris and Headers are embedded in every Demon generated from this listener. The Apache redirector validates the URI prefix and the X-Request-ID header, then forwards the full path (prefix intact) as plain HTTP to Havoc on port 80.

Unlike Mythic and Sliver, Havoc receives the full URI path including the prefix. This is why all URIs must start with /edge/cache/assets/.

Step 5: Generate a Demon

In the Havoc client, navigate to Attack → Payloads.

1. Select the listener

   Select the listener you just created.

2. Set agent options

   Field	Value
   Arch	x64
   Format	Windows Exe

3. Configure injection settings

   Expand the Injection section and fill in both spawn process fields:

   Field	Value
   Spawn64	C:\Windows\System32\notepad.exe
   Spawn32	C:\Windows\SysWOW64\notepad.exe

   The Spawn64 and Spawn32 fields are required. Leaving either blank causes a silent build error — the Generate button will appear to succeed but no file will be produced.

4. Generate

   Click Generate. The Demon executable is saved to /home/admin/Desktop/demon.x64.exe on the Havoc server.

Step 6: Deploy and test

1. Transfer the Demon to the Windows workstation

   From the Windows workstation (via Guacamole RDP or MobaXterm), pull the file from the Havoc server:

   scp admin@havoc:/home/admin/Desktop/demon.x64.exe C:\Users\Administrator\Desktop\demon.x64.exe
   

   Authenticate with the lab SSH password when prompted.

2. Execute the Demon

   Double-click demon.x64.exe in File Explorer on the Windows workstation.

3. Confirm callback

   In the Havoc client, watch the Sessions panel. A new session should appear within a few seconds.

4. Run a test command

   Right-click the session → Interact. In the terminal that opens, run:

   shell whoami
   

   Expected output: win-operator\administrator

5. Monitor redirector traffic

   SSH to the redirector and watch the HTTPS access log:

   sudo tail -f /var/log/apache2/redirector-ssl-access.log
   

   Look for requests to paths under /edge/cache/assets/. Unlike Mythic and Sliver, the full path including the prefix is visible in the log because Havoc receives it unstripped.

Verify all three C2 backends

With all three C2 listeners running, confirm the redirector can reach all backends:

sudo /home/admin/test_redirector.sh

All three entries under Testing direct backend connectivity should show OK.

Teamserver profile reference

The teamserver profile is pre-configured at deploy time and copied to /opt/Havoc/profiles/default.yaotl by the build script.

View the teamserver profile

cat /opt/Havoc/profiles/default.yaotl

Key settings:

Setting	Value
Teamserver host	0.0.0.0 (all interfaces)
Teamserver port	40056
Compiler (64-bit)	/usr/bin/x86_64-w64-mingw32-gcc
Compiler (32-bit)	/usr/bin/i686-w64-mingw32-gcc
Assembler	/usr/bin/nasm
Demon sleep	2 seconds
Demon jitter	0
Operator user	operator

Check teamserver logs

sudo journalctl -u havoc -f

Or check the systemd service status for a compact summary:

sudo systemctl status havoc

Reference

Havoc Framework docs

Official documentation for the Havoc C2 framework.

Havoc on GitHub

Source code for the Havoc teamserver and client.

Redirector security layers

How the Apache redirector validates headers and routes URI prefixes.

Troubleshooting

Debug Havoc build failures, service crashes, and callback issues.