Module 8: Full Chain, Detection & Comparison

Comparing Ekko, FOLIAGE, and ShellcodeFluctuation — detection vectors, Moneta/pe-sieve bypass results, limitations, and the state of the art.

1. The Complete Execution Chain

Here is the full end-to-end execution flow of ShellcodeFluctuation with ThreadStackSpoofer integration, from initial loading through multiple beacon cycles:

// ============================================
// PHASE 0: LOADER INITIALIZATION
// ============================================
// 1. Read shellcode (beacon.bin) from disk/resource
// 2. VirtualAlloc(NULL, size, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE)
// 3. memcpy(allocation, shellcode, size)
// 4. VirtualProtect(allocation, size, PAGE_EXECUTE_READ, &old)
// 5. Generate random XOR32 key
// 6. Resolve kernel32!Sleep via GetProcAddress
// 7. Install inline hook: Sleep -> MySleep
// 8. Save original bytes + hook bytes
// 9. (Optional) Register VEH for Mode 2
// 10. CreateThread(NULL, 0, allocation, NULL, 0, NULL)
//     -> Beacon shellcode begins executing

// ============================================
// PHASE 1: BEACON ACTIVE (repeats each cycle)
// ============================================
// Beacon performs its check-in:
// - Connects to C2 server
// - Downloads tasks
// - Executes commands
// - Uploads results
// Duration: ~100ms

// ============================================
// PHASE 2: BEACON CALLS Sleep(interval)
// ============================================
// Beacon's sleep call is redirected to MySleep via inline hook

// ============================================
// PHASE 3: MySleep HANDLER
// ============================================
// 3a. Spoof stack: *_AddressOfReturnAddress() = 0
// 3b. VirtualProtect(shellcode, RW)
// 3c. xor32(shellcode, key)  [encrypt]
// 3d. Unhook: restore original bytes to kernel32!Sleep
// 3e. Sleep(interval)        [actual sleep - maximally hidden]
// 3f. Rehook: restore hook bytes to kernel32!Sleep
// 3g. xor32(shellcode, key)  [decrypt]
// 3h. VirtualProtect(shellcode, RX)
// 3i. Restore stack: *_AddressOfReturnAddress() = origAddr

// ============================================
// PHASE 4: RETURN TO BEACON
// ============================================
// MySleep returns, Beacon resumes at next instruction
// -> Back to Phase 1

2. Technique Comparison: Ekko vs FOLIAGE vs Fluctuation

Three prominent sleep evasion techniques take fundamentally different architectural approaches to the same problem:

3. Moneta Detection Results

Moneta is the gold standard for memory anomaly detection. Here are the actual detection results for each configuration:

// Moneta output for unprotected Cobalt Strike Beacon:
[!] SUSPICIOUS: Private executable memory
    Process: beacon.exe (PID: 4832)
    Region:  0x000001A00000 - 0x000001A4C000
    Size:    0x4C000 (311,296 bytes)
    Protect: PAGE_EXECUTE_READ
    Type:    MEM_PRIVATE
    IOC:     Abnormal private executable memory

// Moneta output for ShellcodeFluctuation Mode 1 during sleep:
// Region 0x000001A00000 - 0x000001A4C000:
//   Protect: PAGE_READWRITE
//   Type:    MEM_PRIVATE
//   Content: Encrypted (no recognizable patterns)
//   IOC:     None - RW private memory is normal

// However, kernel32.dll shows:
[*] MODIFIED: kernel32.dll
    Region:  0x00007FFB1A240000
    IOC:     Modified code (private working set page)
    Note:    Page modified but content matches disk
             (hook was removed before sleep)

The fluctuating Beacon eliminates the "Abnormal private executable memory" IOC. The remaining IOC is the kernel32 private page artifact from the copy-on-write caused by the hook installation. Crucially, the content matches the on-disk file (because the hook bytes are restored), so the IOC is a weaker "private working set" anomaly rather than a clear "modified code" detection.

4. pe-sieve Detection Results

5. BeaconEye Detection Results

BeaconEye specifically targets Cobalt Strike Beacon configuration structures in memory:

6. Remaining Detection Vectors

Even with both ShellcodeFluctuation and ThreadStackSpoofer active, several detection paths remain available to defenders:

7. Fundamental Limitations

8. State of the Art and Evolution

ShellcodeFluctuation represents one point in the evolution of sleep evasion research. Understanding where it fits helps assess its current relevance:

9. Defense Recommendations

For blue team operators and detection engineers, the following approaches can detect ShellcodeFluctuation and similar techniques:

10. Course Summary