Module 8: Extending Crystal-Loaders

The adaptation guide — module stomping, sleep mask integration, call stack spoofing, IAT hooking PICOs, guardrailed loaders, custom DFR resolvers, and porting the architecture beyond Cobalt Strike.

1. What Crystal-Loaders Leaves on the Table

Crystal-Loaders is deliberately minimal. It proves the spec-driven PIC architecture works, but it ships without several capabilities that a production-grade loader would need. Each omission is an extension opportunity:

The rest of this module walks through seven of these extensions in detail, showing what structures to modify, what code to change, and what detection vectors each extension addresses.

2. Extension 1 — Module Stomping

The single biggest detection surface in Crystal-Loaders today is that Beacon lives in private-commit executable memory allocated via VirtualAlloc. Tools like Moneta and pe-sieve specifically scan for MEM_PRIVATE + PAGE_EXECUTE* regions. Module stomping (also called module overloading) eliminates this by placing Beacon in file-backed MEM_IMAGE memory.

The Concept

1. Instead of VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE), load a legitimate but unused DLL from disk.
2. Use NtCreateSection with the SEC_IMAGE flag to create a file-backed section object.
3. Map it into the process with NtMapViewOfSection.
4. Overwrite the legitimate DLL's sections with Beacon's sections.
5. The result: Beacon lives in MEM_IMAGE (file-backed) memory, defeating Moneta and pe-sieve's private-commit detection.

Code Changes to go()

C (Conceptual Diff)// Before (current Crystal-Loaders)
PBYTE dst = KERNEL32$VirtualAlloc(NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);

// After (module stomping)
// 1. Find a suitable sacrificial DLL (not loaded, large enough)
// 2. NtCreateSection with SEC_IMAGE
// 3. NtMapViewOfSection
// 4. Copy sections over the mapped DLL

Updating ALLOCATED_MEMORY

The BUD ALLOCATED_MEMORY structure tracks how each region was allocated. When switching to module stomping, you must update the allocation method so the sleep mask and other BUD consumers know they are dealing with file-backed memory:

C// Use METHOD_MODULESTOMP instead of METHOD_VIRTUALALLOC
region->CleanupInformation.AllocationMethod = METHOD_MODULESTOMP;
// or METHOD_NTMAPVIEW if using NtMapViewOfSection directly

The MODULESTOMP_INFO Structure

Beacon's beacon.h defines a structure for tracking module-stomped allocations:

C (beacon.h)typedef struct _MODULESTOMP_INFO {
    HMODULE ModuleHandle;
} MODULESTOMP_INFO, *PMODULESTOMP_INFO;

This structure simply stores the module handle of the stomped DLL. BUD consumers (especially the sleep mask and cleanup routines) use the ModuleHandle to identify which loaded module was overwritten, enabling proper cleanup (e.g., unmapping the view) when the implant exits or the region is freed.

3. Extension 2 — Sleep Mask Integration

Crystal-Loaders populates the ALLOCATED_MEMORY structure with section-level tracking, but it does not include a sleep mask. A sleep mask PIC would use this BUD data to encrypt Beacon's memory sections during sleep and decrypt them before the next check-in.

The Sleep Mask Cycle

Conceptual Implementation Using BUD

C (Sleep Mask - BUD Integration)// Conceptual sleep mask flow using BUD's ALLOCATED_MEMORY
for (int r = 0; r < 6; r++) {
    ALLOCATED_MEMORY_REGION * region = &bud->allocatedMemory->AllocatedMemoryRegions[r];
    if (region->Purpose == PURPOSE_EMPTY) continue;

    for (int s = 0; s < 8; s++) {
        ALLOCATED_MEMORY_SECTION * sec = ®ion->Sections[s];
        if (!sec->MaskSection || sec->VirtualSize == 0) continue;

        // Change to RW so we can encrypt in place
        DWORD oldProtect;
        NtProtectVirtualMemory(
            NtCurrentProcess(),
            &sec->BaseAddress,
            &sec->VirtualSize,
            PAGE_READWRITE,
            &oldProtect
        );

        // Encrypt the section contents
        xor_encrypt(sec->BaseAddress, sec->VirtualSize, key);
    }
}

The Ekko-Style Timer Queue Pattern

The Ekko sleep obfuscation technique uses CreateTimerQueueTimer to queue ROP-style callbacks that change memory permissions, encrypt, sleep, decrypt, and restore — all without the Beacon thread being active during the sleep window. Adapting Ekko for BUD means replacing Ekko's hardcoded memory ranges with the ALLOCATED_MEMORY regions tracked by BUD.

4. Extension 3 — Call Stack Spoofing

Even with LibGate's indirect syscalls routing execution through ntdll, the return stack still reveals that the calling code lives in private memory. A full call stack walk shows:

Call Stack (Anomalous)ntdll!NtAllocateVirtualMemory       (syscall;ret gadget)
  → returns to 0x00007FF6`1A3C0842   ← loader PIC blob (PRIVATE memory!)
  → returns to 0x00007FF6`1A3C0210   ← still in PIC blob
  → ...

The return addresses in private memory are the anomaly. EDR stack walkers flag any frame that falls outside a file-backed module.

The Draugr Approach

The Draugr technique (covered in a separate course) creates synthetic stack frames that make the call stack look like it originates from legitimate system code. It uses JMP [RBX] gadget chaining with fake RUNTIME_FUNCTION and UNWIND_INFO structures so that the Windows unwinder produces a clean, believable stack trace.

The ThreadStackSpoofer Approach

A simpler alternative: before entering sleep, overwrite the return addresses on the current thread's stack with pointers into legitimate modules. On wake, restore the real return addresses. This defeats point-in-time stack scans during the sleep window.

Integration via Crystal Palace PICO

Crystal Kit demonstrated call stack spoofing as a PICO merged via Crystal Palace. The integration approach:

5. Extension 4 — IAT Hooking PICO

Crystal Kit's most sophisticated extension was an IAT hooking PICO that intercepts specific API calls made by Beacon's loaded dependencies. This operates during and after the ProcessImports phase of LibTCG.

How It Works

1. During LoadDLL / ProcessImports, the PICO hooks the loaded DLL's IAT entries by replacing function pointers with addresses inside the PIC blob.
2. The PIC blob intercepts the call, adds evasion (call stack spoofing, argument sanitization), and then forwards to the real API.
3. The hooking is invisible to Beacon — it calls APIs normally through its IAT, unaware that they are being intercepted.

Key Hook Targets

The LoadLibraryA/W hook is particularly important. When Beacon executes powerpick or execute-assembly, Windows loads the CLR and PowerShell automation DLLs. EDR products monitor for these loads (via PsSetLoadImageNotifyRoutine) as they strongly indicate offensive tooling. An IAT hook can intercept these loads and apply additional obfuscation or timing manipulation.

6. Extension 5 — Guardrailed Loaders

Guardrailing ensures that a captured payload is useless outside the target environment. The Tradecraft Garden includes a simple_rdll_guardrail example demonstrating this concept, though Crystal-Loaders itself does not implement guardrailing. The full guardrail pattern works as follows:

The Guardrail Flow

Implementation (simple_rdll_guardrail pattern)

The simple_rdll_guardrail example in the Tradecraft Garden derives its key from the target machine's C: drive volume serial number and uses RC4 encryption via the undocumented SystemFunction033 export from advapi32.dll:

C (Link Time - Operator Workstation)// Obtain the target's C: volume serial (from recon)
DWORD targetSerial = ...; // e.g., 0xABCD1234

// Encrypt the Beacon DLL with RC4 using the serial as key material
RC4_Encrypt(beacon, beaconSize, &targetSerial, sizeof(DWORD));

C (Runtime - Target Host)// Re-derive the key from the current host's C: volume serial
DWORD volumeSerial = 0;
GetVolumeInformationA("c:\\", NULL, 0, &volumeSerial, NULL, NULL, NULL, 0);

// Decrypt via SystemFunction033 (RC4)
USTRING data = { beaconSize, beaconSize, encrypted };
USTRING key  = { sizeof(DWORD), sizeof(DWORD), (PBYTE)&volumeSerial };
SystemFunction033(&data, &key);

// If wrong host: volumeSerial differs → RC4 produces garbage
// No valid PE signature → ParseDLL fails → loader exits cleanly
// No crash, no IOCs, no Beacon artifacts for blue team to analyze

7. Extension 6 — Custom DFR Resolvers

Crystal Palace's Dynamic Function Resolution system supports multiple resolver strategies. The spec file controls which strategy applies to which modules. The default Crystal-Loaders configuration uses ROR13 hashing, but the DFR system is designed to be customizable.

The Dual-Resolver Pattern

From rasta-mouse's "Arranging the PIC Parterre" blog post, the recommended pattern uses two resolvers:

Crystal Palace Specdfr "resolve_explicit" "ror13" "KERNEL32, NTDLL"
dfr "resolve_default" "strings"

Advanced Resolver Modifications

• Substitute LdrLoadDll for LoadLibraryA: LoadLibraryA (kernel32) is commonly hooked by EDRs. Calling LdrLoadDll (ntdll) directly bypasses kernel32 hooks while achieving the same result.
• Custom hash algorithms: Replace ROR13 with CRC32, djb2, or a unique hash to avoid YARA rules that signature the ROR13 constant (0x3CFA685D, defined as NTDLL_HASH in Crystal-Loaders' loader.c).
• Proxy through threadpool: Route API calls through TpAllocWork / TpPostWork / TpReleaseWork threadpool work items. The call stack then shows the Windows threadpool infrastructure rather than direct calls from the PIC blob.

8. Extension 7 — Porting Beyond Cobalt Strike

Crystal Palace and the PIC architecture are not Cobalt Strike-specific. The core value — spec-driven PIC generation, LibTCG PE loading, LibGate indirect syscalls, DFR — is C2-framework agnostic. The Cobalt Strike coupling comes from only a few interfaces.

What You Would Need to Change

Potential Targets

• Mythic agents — Mythic's payload generation is already modular; Crystal Palace PIC output can be wrapped in a Mythic payload type
• Sliver implants — Sliver uses shellcode stagers; the PIC blob can serve as the shellcode payload
• Havoc agents — Havoc's Demon agent uses UDRL-style loading that maps directly to Crystal Palace concepts
• Custom C2 frameworks — Any framework that accepts shellcode or reflective DLL input
• Standalone shellcode runners — Use the PIC blob as a generic payload without any C2 framework

A Minimal Generic Loader

Stripped of all Cobalt Strike specifics, a Crystal Palace loader reduces to this core:

C (Generic Loader)void go(void)
{
    // Get the embedded DLL and XOR key from the PIC's resource section
    PRESOURCE dll = GETRESOURCE(_DLL_);
    PRESOURCE key = GETRESOURCE(_KEY_);

    // XOR unmask the embedded payload
    PBYTE buf = VirtualAlloc(NULL, dll->length, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    for (DWORD i = 0; i < dll->length; i++)
        buf[i] = dll->data[i] ^ key->data[i % key->length];

    // Parse and load the DLL using LibTCG
    DLLDATA dlldata;
    ParseDLL(buf, &dlldata);
    PBYTE dst = VirtualAlloc(NULL, SizeOfDLL(&dlldata), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    LoadDLL(&dlldata, dst);
    ProcessImports(&dlldata, dst);
    FixSectionPermissions(&dlldata, dst);

    // Simple: just call DllMain directly
    DLLMAIN_FUNC entry = (DLLMAIN_FUNC)EntryPoint(&dlldata, dst);
    VirtualFree(buf, 0, MEM_RELEASE);
    entry(dst, DLL_PROCESS_ATTACH, NULL);
}

This is the entire loading pipeline without BUD, without the three-call protocol, and without Aggressor integration. LibTCG, LibGate, and DFR all still function — only the Cobalt Strike handshake is removed. You can then add back whatever data-passing contract your C2 agent expects.

9. Detection & OPSEC Considerations

This table summarizes the detection posture of Crystal-Loaders in its current PoC state versus what becomes possible with the extensions described in this module:

10. Module Summary