Module 1: Why Sleep Obfuscation Matters

Your implant spends 99% of its life sleeping — and that is exactly when it gets caught.

1. The Beacon Sleep Cycle

Modern C2 implants — whether Cobalt Strike Beacons, Sliver implants, or custom agents — operate on a check-in cycle. The implant wakes up, contacts the C2 server, executes any tasked commands, sends results back, and then goes to sleep for a configured interval (typically 30 to 300 seconds). This cycle repeats indefinitely until the operator kills the session or the implant is discovered.

The critical insight is the time distribution. If a beacon sleeps for 60 seconds between check-ins and the active communication phase takes roughly 200 milliseconds, the implant spends approximately 99.7% of its lifetime sleeping. During that sleep window, the implant's code and data sit in memory completely idle, waiting for the next cycle.

This asymmetry creates a fundamental problem: the implant is most vulnerable during the phase where it spends most of its time.

2. Memory Scanners & the Detection Window

Endpoint Detection and Response (EDR) products and memory forensics tools periodically scan process memory for indicators of compromise. These memory scanners look for several telltale signs of an implant:

The key point is that these scanners can run at any time, and since the beacon is sleeping 99%+ of the time, a scan will almost always catch the beacon in its idle state — with all of its code and configuration data sitting in memory in plaintext, in executable memory pages.

3. What Sleep Obfuscation Solves

Sleep obfuscation addresses this problem by transforming the implant's memory before entering the sleep state and reversing the transformation upon wakeup. The goal is to make the memory region indistinguishable from random data while the implant sleeps.

An effective sleep obfuscation technique must accomplish three things during the sleep window:

The challenge is that you cannot simply call VirtualProtect and an encryption function from your own code — because your code is in the region being encrypted. You would encrypt yourself mid-execution and crash. This is the self-encryption paradox, and it is the central problem that Ekko, Foliage, Cronos, and DeathSleep each solve in different ways.

4. The Self-Encryption Paradox

Consider what happens if a beacon naively tries to encrypt itself:

C// BROKEN: This will crash
void sleep_and_encrypt(DWORD sleep_ms) {
    DWORD old;
    // Step 1: Change permissions to RW (removes execute)
    VirtualProtect(image_base, image_size, PAGE_READWRITE, &old);

    // Step 2: Encrypt our own code region
    // CRASH: This instruction is INSIDE the region we just
    // made non-executable. We can't even reach the encrypt call.
    rc4_encrypt(image_base, image_size, key);

    // Steps 3-5 never execute...
    Sleep(sleep_ms);
    rc4_decrypt(image_base, image_size, key);
    VirtualProtect(image_base, image_size, PAGE_EXECUTE_READ, &old);
}

The code above fails at Step 1 — the moment VirtualProtect removes the execute permission from the page containing the currently executing code, the CPU faults on the next instruction fetch because the instruction pointer is in a non-executable page.

Even if we reversed steps 1 and 2 (encrypt first, then change permissions), the encryption function itself is in the region being encrypted. Halfway through the encryption operation, the bytes of the encrypt function get encrypted, and the CPU starts executing encrypted garbage.

5. The Ekko Approach at a Glance

Ekko, created by Cracked5pider (C5pider), uses a technique originally discovered by Peter Winter-Smith and implemented in MDSec's Nighthawk. The approach chains together CreateTimerQueueTimer callbacks, each of which uses NtContinue to restore a pre-configured CONTEXT structure. Each CONTEXT has its RIP set to a different Windows API function, and its registers set to the arguments that function expects.

The result is a sequence of API calls executed by the timer thread, not by the beacon itself:

During step 3, the implant's code is encrypted with RC4, its memory permissions are RW (non-executable), and the main thread is waiting on an event. A memory scanner running during this window sees nothing but encrypted data in a non-executable memory region.

6. Detection Without Sleep Obfuscation vs. With

7. Historical Context

Sleep obfuscation evolved through several milestones in the red team community:

Ekko occupies an important position in this lineage as the first public, clean implementation of the timer queue approach. Its simplicity makes it an ideal learning tool for understanding the underlying concepts that all sleep obfuscation techniques share.

8. What You Will Learn in This Course