Module 8: Full Chain, Detection & Variants

Comparing sleep obfuscation approaches, detection engineering, and the evolution of the technique.

1. The Sleep Obfuscation Family

Multiple open-source implementations of sleep obfuscation have been released, each taking a different approach to the core problem of encrypting an implant's memory while it sleeps. Understanding their differences illuminates the design tradeoffs in this technique.

2. Ekko vs. Cronos

Cronos by Idov31 uses the same NtContinue-based execution model as Ekko but replaces CreateTimerQueueTimer with waitable timers (CreateWaitableTimer / SetWaitableTimer). Cronos creates waitable timer objects for scheduling the sleep obfuscation operations:

C// Cronos approach (simplified):
HANDLE hTimer = CreateWaitableTimer(
    NULL,    // Security attributes
    TRUE,    // Manual reset
    NULL     // Timer name
);

// Set the timer to fire after a delay
LARGE_INTEGER dueTime;
dueTime.QuadPart = -10000LL * delay_ms;  // Negative = relative
SetWaitableTimer(hTimer, &dueTime, 0, NtContinue, &CtxProtRW, FALSE);

3. Ekko vs. DeathSleep

DeathSleep by janoglezcampos takes a fundamentally different approach. Instead of using callbacks and NtContinue, it terminates the main thread entirely and recreates it after the sleep period. The key insight is that a dead thread leaves no context to inspect — there is no sleeping thread for detection tools to analyze:

C// DeathSleep approach (conceptual):
// 1. Main thread saves its own context and state
// 2. Main thread creates a helper thread with the saved state
// 3. Main thread terminates itself (the thread is killed, not suspended)
// 4. Helper thread:
//    a. VirtualProtect(main_image, RW)
//    b. Encrypt(main_image)
//    c. Sleeps for the requested duration
//    d. Decrypt(main_image)
//    e. VirtualProtect(main_image, RX)
//    f. Creates a new thread with the saved context
//       (effectively recreating the original thread)
// 5. New thread resumes execution where the old one left off

4. Ekko vs. FOLIAGE

FOLIAGE by SecIdiot is the most comprehensive implementation, using a chain of Asynchronous Procedure Calls (APCs) queued to the current thread:

C// FOLIAGE approach (conceptual):
// 1. Generate fresh RC4 key
// 2. Encrypt the private heap (separately from the code)
// 3. Queue 10 APCs to the current thread:
//    APC 0: Wait (setup timer)
//    APC 1: NtGetContextThread (capture)
//    APC 2: NtSetContextThread (spoof RIP to ntdll)
//    APC 3: NtProtectVirtualMemory (RX -> RW)
//    APC 4: SystemFunction032 (encrypt code)
//    APC 5: NtWaitForSingleObject (actual sleep)
//    APC 6: SystemFunction032 (decrypt code)
//    APC 7: NtProtectVirtualMemory (RW -> RX)
//    APC 8: NtSetContextThread (restore context)
//    APC 9: NtSetEvent (signal done)
// 4. Enter alertable wait (NtWaitForSingleObject with alertable=TRUE)
// 5. APCs drain in FIFO order during the alertable wait

5. Detection Vectors for Ekko

Understanding how defenders detect Ekko helps both offensive operators improve their implementations and defensive engineers build better detections:

6. Hunt-Sleeping-Beacons Deep Dive

Hunt-Sleeping-Beacons by thefLink is the primary open-source tool targeting sleep obfuscation techniques. It operates by:

Against Ekko's PoC, Hunt-Sleeping-Beacons will detect the sleeping thread because:

• The main thread is waiting on an event (detected as sleeping)
• The main thread's call stack contains return addresses from EkkoObf, which is in the implant's (unbacked) image region
• Even though the code is encrypted during sleep, the return addresses on the main thread's stack still point there

7. Evasion Improvements Over the PoC

A production-grade implementation based on Ekko's technique would need these enhancements:

8. The Evolution: KrakenMask

KrakenMask, also by Cracked5pider, represents the evolution of Ekko into a more complete sleep masking solution. While the full implementation details differ, KrakenMask addresses many of the PoC's shortcomings:

9. The Complete Ekko Chain — Final Review

Let us review the complete Ekko execution from start to finish with all the knowledge from this course:

During step 6, between the encrypt and decrypt operations, the implant's entire image is RC4-encrypted in non-executable memory. This is the stealth window. A memory scanner running during this period sees only encrypted data in RW pages — no code signatures, no configuration patterns, no executable memory.

10. Defensive Recommendations

For blue team engineers and detection developers, these are the highest-value detection opportunities:

11. Summary: Sleep Obfuscation Landscape