Havoc

Havoc is a modern and malleable post-exploitation command and control framework, originally created by @C5pider and co-developed by @Kr0ff.

The free upstream version of Havoc is no longer maintained. This is a private fork actively maintained by @Kr0ff with substantial protocol hardening, agent stability fixes, and operator UX improvements.

Please see the Wiki for complete documentation.

Havoc works well on Debian 10/11, Ubuntu 20.04/22.04 and Kali Linux. It's recommended to use the latest versions possible to avoid issues. You'll need a modern version of Qt and Python 3.10.x to avoid build issues.

See the Installation docs for instructions. If you run into issues, check the Known Issues page as well as the open/closed Issues list.

This release focuses on hardening the HTTP(S) transport layer against network-level detection and packet analysis. All changes are applied to the Demon agent and the teamserver; the client and SMB transport are unaffected. Full details and revert instructions are in CHANGES.md.

• Removed the X-Havoc: true response header that was returned on every rejected HTTP request. This header made the teamserver trivially identifiable by passive scanners and IDS rules matching the response.

• All HTTP POST bodies sent by the Demon are now Base64-encoded before transmission; the teamserver decodes them before parsing.
• The teamserver Base64-encodes all responses before writing them to the wire; the Demon decodes them after reading.
• A compact RFC 4648 Base64 encode/decode implementation was added to the Demon (MiniStd.c) with no CRT dependency.
• Applies to both the HTTP listener (http.go) and the External C2 handler (external.go).
• Raw binary POST bodies are immediately anomalous to DPI systems. Base64 payloads are indistinguishable from the token fields and encoded data that appear routinely in legitimate web traffic.

• The 20-byte outer packet header contains the static value 0xDEADBEEF at a fixed byte offset in every POST body. This was the single highest-confidence network IDS signature for Havoc traffic.
• The four header fields that follow the SIZE field (magic value, agent ID, command ID, request ID — bytes 4–19) are now XOR-masked before transmission using a mask derived from the packet SIZE field: mask = SIZE ^ 0xA3F1C2B4.
• Because SIZE varies per packet, the masked magic value is different on every transmission and no longer matchable by a static byte pattern.
• The teamserver reverses the mask before parsing. Both sides derive the same mask independently from the SIZE field alone — no additional key material is required.

• Previously, all beacon packets were encrypted with the same static AES-CTR IV embedded in the Demon binary. Reuse of the same keystream allows an observer to XOR two captured ciphertexts and recover plaintext differences.
• A fresh 16-byte random IV is now generated for every PackageTransmitAll call using RandomNumber32(). The IV is prepended in plaintext between the outer header and the encrypted payload so the teamserver can extract it.
• The registration packet (DEMON_INITIALIZE) continues to use the compiled-in IV; only post-registration beacon packets use per-request IVs.

• AES-CTR provides confidentiality but not integrity — an attacker who can observe and modify ciphertext can flip bits in a predictable way without knowing the key.
• A 32-byte HMAC-SHA256 tag is now appended to every beacon packet after encryption (encrypt-then-MAC). The tag is computed over the entire wire buffer (SIZE, masked header, random IV, and ciphertext).
• A separate MAC key is derived per session: HMAC-SHA256(AES_session_key, "mac"), keeping the authentication key independent from the encryption key.
• The teamserver verifies the tag before parsing any packet fields. Packets with an invalid or missing tag are silently dropped with a fake 404 response.
• A pure-C SHA-256 and HMAC-SHA256 implementation was added to the Demon (src/crypt/HmacSha256.c) with no CRT or BCrypt API dependency. All intermediate keying material is wiped from the stack before return.
• Registration packets are not authenticated with HMAC (the session key is not yet established when they arrive at the teamserver).

After all transport hardening changes, every beacon POST body has the following structure on the wire:

base64(
  [SIZE(4 bytes)]
  [XOR-masked header fields(16 bytes)]
  [random AES IV(16 bytes)]
  [AES-CTR encrypted payload]
  [HMAC-SHA256 tag(32 bytes)]
)

Cross-platform UI written in C++ and Qt5

• Modern, dark theme based on Dracula
• Multi-operator session graph and session table views with live agent state
• Payload builder dialog with profile-driven defaults
• Sleep obfuscation option selectability — invalid combinations (e.g. JmpGadget or Stack Duplication with non-timer techniques) are automatically disabled in the builder
• Task queue management commands: task list, task clear, task cancel <id|all>
• TaskID injected into all console output messages so operators can correlate output to specific queued tasks
• File browser, process list, loot vault, and credential manager widgets
• Script manager with Python API integration
• Connect dialog with saved profile support

Written in Go

• Multiplayer with WebSocket-based client connections
• Payload generation (exe / shellcode / DLL / service exe)
• HTTP/HTTPS listeners with malleable profile support
• SMB pivot listener (parent → child relay over named pipes)
• External C2 endpoint for third-party agents
• Customizable C2 profiles via YAOTL (HCL-based) with full spec test suite
• SQLite persistence layer for agent sessions, tasks, and credentials
• Discord webhook integration for new-agent notifications
• RSA-2048-OAEP-SHA256 session key wrapping for the registration packet (HVC-005)
• Per-request random AES-256-CTR IV for every beacon packet (HVC-004)
• HMAC-SHA256 encrypt-then-MAC authentication on all post-registration traffic (HVC-006)
• LZNT1 payload compression for large beacon responses (HVC-007)
• XOR-masked outer wire header — eliminates the static 0xDEADBEEF magic-value signature (HVC-003)
• Base64-encoded HTTP request and response bodies (HVC-002)
• SMB pipe framing obfuscation — XOR-masks the [DemonID][PkgSize] header on parent↔child pipes (HVC-008)
• Removed X-Havoc: true response header that previously fingerprinted the teamserver (HVC-001)
• Mutex-protected agent job queue and task list (data-race fix, ISSUE-1)
• SMB packet fragmentation — large responses (>64 KB) are split into DEMON_PACKAGE_FRAGMENT chunks and reassembled server-side (ISSUE-5)
• HTTP beacon stability fixes for retransmission, HMAC handling on reconnect, and AES-CTR counter reuse (BUGFIX-004)
• SMB pivot stability fixes for package leaks, error masking, NULL allocation, and PIPE_BUFFER_MAX overflow (BUGFIX-003)

Havoc's flagship agent written in C and x86/x64 ASM

• Sleep obfuscation via Ekko, Zilean, or FOLIAGE
• Sleep obfuscation source split into per-technique files (ObfTimer.c, ObfFoliage.c) with compile-time SLEEPOBF_USE_TIMER / SLEEPOBF_USE_FOLIAGE guards — only the selected technique is compiled into the binary
• Sleep jump gadget bypass: jmp rax and jmp [rbx] ROP-chain dispatch (Ekko/Zilean)
• x64 return address spoofing during indirect syscalls
• Indirect syscalls for Nt* APIs with dynamically resolved SSNs
• SMB transport for child agents over named pipes
• Token vault and impersonation primitives
• Kerberos authentication support
• Hardware-breakpoint-based AMSI / ETW patching (HwBpEngine)
• Proxy library loading via RtlRegisterWait / RtlCreateTimer / RtlQueueWorkItem
• Stack duplication / call-stack spoofing during sleep
• BOF (Beacon Object File) loader and inline .NET assembly execution
• Per-process AES-256-CTR session encryption with embedded key material
• Pure-C SHA-256 + HMAC-SHA-256 implementation (no CRT, no BCrypt dependency)
• LZNT1 compression of large response payloads via RtlCompressBuffer
• Spinlock-protected Instance->Packages linked list (data-race fix, ISSUE-2)
• mingw-w64 v15 / GCC 14+ compilation compatibility (MINGW-COMPAT)
• Hardware breakpoint engine fixes: thread handle leaks, NULL guards, parameter handling (HVC-009)
• Working-hours scheduling and kill-date enforcement

• External C2
• Custom Agent Support
  • Talon
• Python API
• Modules

You can join the official Havoc Discord to chat with the community!

Please do not open any issues regarding detection.

The Havoc Framework hasn't been developed to be evasive. Rather it has been designed to be as malleable & modular as possible. Giving the operator the capability to add custom features or modules that evades their targets detection system.