Your implant is sitting in memory right now doing absolutely nothing — waiting for the next callback interval. And that’s exactly when it gets caught.
Modern EDRs don’t just scan on execution anymore. They scan memory periodically, they walk thread stacks, they look for RWX regions with suspicious entropy, and they do it while your beacon is sleeping. If you think “I’ll just obfuscate the shellcode at rest” is still a complete answer in 2026, you’re about two product releases behind the threat detection teams.
Sleep obfuscation isn’t a new concept, but the gap between “I’ve heard of Ekko” and “I understand why stack spoofing matters here and when it falls apart” is where most red teamers are quietly getting burned. Let me break down where things actually stand.
Why Cobalt Strike is a Liability Now
I know, I know. Everyone’s been saying this for three years. But it’s genuinely reached the point where deploying a default CS beacon in an enterprise environment is almost a courtesy to the blue team — you’re basically announcing yourself. The signature database for CS profiles across Defender, CrowdStrike, SentinelOne, and Carbon Black is enormous, and even heavily malleable profiles are getting flagged on behavioral detections now, not just static signatures.
The shift in the community has been toward Havoc C2, Sliver, and Brute Ratel C4. Havoc in particular has become the go-to for people who want to dig into the internals — it’s open source, actively developed, and the Demon agent gives you granular control over evasion behavior without needing to pay for a commercial license or reverse-engineer a closed framework.
The thing that makes Havoc actually interesting isn’t just the feature list. It’s the architecture — Demon agents are designed from the ground up to support indirect syscalls, custom sleep techniques, and in-memory execution patterns that don’t look like the canonical patterns EDRs were trained on. The Havoc documentation is surprisingly good for an open-source offensive tool. Go read it.
The Memory Scan Problem
Here’s the core issue. When your implant is sleeping between callbacks, it’s still sitting in memory. A naive implementation means your shellcode is sitting in a readable, executable heap region with high entropy — which is basically a neon sign. EDR memory scanners like BeaconHunter and internal scanners in CrowdStrike Falcon actively walk process memory looking for these patterns.
The solution space breaks down into a few categories:
1. Encrypt and flip permissions on sleep. During a sleep cycle, encrypt your implant’s memory region, mark it as RW (not RWX), sleep, decrypt on wake. Simple concept, surprisingly effective against signature-based scans. The issue is the encryption/decryption routine itself exists in executable memory, which can be spotted.
2. Stack spoofing. When your thread is sleeping, its call stack is readable by EDR. If that stack has frames pointing into your implant, you’re done. Stack spoofing involves manipulating the thread stack before sleep to look like it originated from a legitimate Windows API call.
3. Timer-based sleep with ROP chains. Instead of calling Sleep() directly (which parks your thread in an obviously suspicious state), you queue a ROP chain via RtlCreateTimer or NtApcQueueThread that handles the encrypt-sleep-decrypt cycle. The thread state looks legitimate because you’re not blocked in a suspicious sleep — you’re just waiting on a timer callback.
Havoc implements several of these via configurable sleep techniques. The relevant ones:
// Havoc Demon config - sleep technique options
// In your profile or via the interactive console
sleep_technique = "Foliage"; // NtApcQueueThread ROP chain
// sleep_technique = "Ekko"; // RtlCreateTimer approach
// sleep_technique = "WaitForSingleObjectEx"; // baseline, not recommended
Ekko is the more documented one — it uses RtlCreateTimer to queue a ROP chain that XOR-encrypts the implant, calls WaitForSingleObjectEx, then decrypts on wake. Foliage does the same conceptually but goes through NtApcQueueThread, which has a slightly different stack footprint. In 2026, Foliage tends to be cleaner against certain EDR memory walk patterns, but honestly I’ve seen both get flagged depending on the environment.
Indirect Syscalls and Hell’s Gate
Sleep obfuscation alone isn’t enough if your syscalls are being intercepted at the user-mode layer. Classic EDR hooking involves patching the prologue of ntdll.dll functions — if you call NtWriteVirtualMemory and the first bytes are a jmp to the EDR’s hook, it’s getting logged regardless of what your implant is doing during sleep.
The answer is Hell’s Gate and its descendants — enumerate the syscall numbers directly from ntdll, then execute the syscall instruction from within ntdll.dll’s own memory space (or a clean copy). This is what “indirect syscalls” means in practice: you’re not jumping to a hook-free gadget inside your implant; you’re jumping to the syscall instruction that actually lives inside ntdll.
Havoc’s Demon agent supports this natively. To verify it’s working:
[DcodeZero] Demon » syscall_method
[*] Current syscall method: Indirect
[*] Syscall address resolution: Dynamic (Hell's Gate)
[*] NtCreateThread: 0x7ffc8a2c1d40 (within ntdll range: TRUE)
[*] NtWriteVirtualMemory: 0x7ffc8a2b9f80 (within ntdll range: TRUE)
[*] NtAllocateVirtualMemory: 0x7ffc8a2ba220 (within ntdll range: TRUE)
If within ntdll range is FALSE, your syscall gadgets are in your own implant memory — which is detectable. Fix it.
What Didn’t Work: A Specific Story
Last November I was running an engagement for a mid-size fintech company in Southeast Asia — the kind of shop that’s deployed CrowdStrike Falcon Prevent with prevent mode on and has an actual IR team looking at alerts, not just a SOC that sends emails. Initial access via a phishing macro (yeah, macros still work if you do it right), dropped a Havoc Demon with Ekko sleep and indirect syscalls. First 48 hours were clean.
Then I tried to migrate the implant into a more stable process — explorer.exe via process injection. Within about 11 minutes, Falcon flagged it. Not the sleep obfuscation. The injection itself. I was using classic VirtualAllocEx + WriteProcessMemory + CreateRemoteThread, and apparently CrowdStrike’s behavioral detection on cross-process memory writes into explorer.exe specifically is extremely sensitive.
Switched to Early Bird APC injection into a freshly spawned RuntimeBroker.exe with a spoofed parent process ID (PPID spoofing via UpdateProcThreadAttribute), and that stayed clean for the rest of the engagement. The lesson: your evasion chain for in-memory operation and your evasion chain for process migration are different problems. Don’t solve one and assume the other is covered.
Read This Before You Touch Any of This
Seriously, if you’re getting into memory evasion and you haven’t read @mariuszbit’s work on PE-sieve and hunting injected implants, you’re doing this backwards. Understanding how defenders detect this stuff is the fastest path to understanding where the real gaps are. His PE-sieve tool is what I use to validate my own implant’s footprint before dropping it on an engagement.
Also worth reading: @_boku7’s research on ASLR bypass and custom loaders. The TitanLdr project is a good practical reference for building your own position-independent shellcode loader that isn’t just copying the Havoc default. The more custom your loader, the less likely you’re hitting a known signature.
My Take
The people who are still hand-waving about “just use malleable C2 profiles” are consultants who haven’t been in a real CrowdStrike Prevent environment in the last 12 months. The ground has shifted. Memory scanning is the new signature detection, and sleep obfuscation is the new obfuscation layer — not optional, not advanced, just table stakes.
Havoc is the right tool right now because it’s open enough to actually learn from. Using a black box commercial C2 framework and wondering why you’re getting caught is a dead end — you can’t fix what you can’t inspect.
The gap in most red team programs isn’t tool selection. It’s that people treat evasion as a one-time setup step instead of a continuous tuning problem specific to the target environment. The same Havoc config that sailed through CrowdStrike Falcon on your last engagement will get caught by SentinelOne’s memory scanner if you never adjusted the sleep technique. Every environment is a calibration problem.
Hot Take Closer
If you’re still measuring a “successful” engagement by whether you got DA, you’re running a compliance exercise, not a red team. The real value is in the engagement where you got caught — specifically how you got caught, how fast, and whether the blue team knew what they were looking at. An uncaught DA in 2026 just means neither team learned anything.
Resources:
