Module 1: Memory Scanning Threat Model

What memory scanners look for, how they catch sleeping implants, and why ShellcodeFluctuation exists.

1. The Memory Scanner Landscape

Post-exploitation implants (Cobalt Strike Beacon, Meterpreter, Sliver, etc.) must reside in memory to execute. Once loaded, they become targets for a class of defensive tools that scan process address spaces for anomalies. Three tools are particularly relevant to understanding ShellcodeFluctuation:

Each tool targets different evidence, but they share a common assumption: the shellcode or implant is present in cleartext in executable memory at the time of scanning.

2. What Moneta Detects

Moneta walks every process's virtual address space using VirtualQueryEx and flags memory regions exhibiting suspicious properties. Its detection categories are critical to understand because ShellcodeFluctuation is designed specifically to evade them.

When Moneta scans an unprotected Cobalt Strike Beacon, it immediately flags the shellcode allocation as "Abnormal private executable memory" — this is the primary IOC that ShellcodeFluctuation targets.

3. What pe-sieve Detects

pe-sieve focuses on PE image integrity. It enumerates loaded modules in a process and compares them byte-for-byte against their on-disk counterparts. Key detection capabilities:

For ShellcodeFluctuation, pe-sieve is relevant in two ways: it can detect the shellcode itself (if present in cleartext), and it can detect the inline hook on kernel32!Sleep that the fluctuation mechanism installs.

4. What BeaconEye Detects

BeaconEye takes a targeted approach, specifically hunting for Cobalt Strike Beacon configurations in memory. Beacon stores its configuration (C2 URLs, sleep time, watermark, etc.) in a predictable structure that can be identified through pattern matching.

// Simplified Beacon config structure in memory
// BeaconEye scans for these characteristic patterns:
struct BeaconConfig {
    uint16_t setting_id;      // e.g., 0x0001 = BeaconType
    uint16_t data_type;       // 0x0001=short, 0x0002=int, 0x0003=data
    uint16_t data_length;
    char     data[];          // the actual configuration value
};
// The config block is XOR'd with a single byte key in memory
// BeaconEye tries all 256 possible XOR keys to decode it

BeaconEye scans all private memory regions in every process, attempting single-byte XOR decryption with each of the 256 possible keys. If the decoded data matches the Beacon configuration signature, detection occurs. ShellcodeFluctuation's multi-byte XOR encryption defeats this brute-force approach because 256 keys is insufficient to crack a 32-bit XOR key.

5. The Idle-Time Detection Window

C2 implants follow a predictable lifecycle: execute briefly, then sleep for an extended period. This creates a massive asymmetry that defenders exploit:

During the sleep window, the shellcode memory region has these properties that make it trivially detectable:

6. How Scanners Enumerate Memory

Understanding the API surface that scanners use helps explain why certain evasion strategies work:

// Core scanning loop used by tools like Moneta
MEMORY_BASIC_INFORMATION mbi;
LPVOID address = 0;

while (VirtualQueryEx(hProcess, address, &mbi, sizeof(mbi))) {
    // Check for suspicious attributes
    if (mbi.Type == MEM_PRIVATE &&
        (mbi.Protect & (PAGE_EXECUTE | PAGE_EXECUTE_READ |
                        PAGE_EXECUTE_READWRITE | PAGE_EXECUTE_WRITECOPY))) {
        // FLAG: Private executable memory - potential shellcode
        ScanRegion(hProcess, mbi.BaseAddress, mbi.RegionSize);
    }

    if (mbi.Protect == PAGE_EXECUTE_READWRITE) {
        // FLAG: RWX memory - highly suspicious
        FlagRWX(hProcess, mbi.BaseAddress, mbi.RegionSize);
    }

    // Advance to next region
    address = (LPBYTE)mbi.BaseAddress + mbi.RegionSize;
}

The key insight: scanners use VirtualQueryEx to read the current page protection. If the memory is marked PAGE_READWRITE (no execute), it does not match the "private executable memory" heuristic. This is the foundation of ShellcodeFluctuation's evasion strategy.

7. The ShellcodeFluctuation Strategy

ShellcodeFluctuation (by mgeeky / Mariusz Banach) addresses the idle-time detection window with a straightforward but effective approach:

The mechanism is called "fluctuation" because the memory protection constantly oscillates between RW (encrypted) and RX (executable), and the content constantly toggles between ciphertext and plaintext.

8. Detection Evasion Summary