Module 1: The Reflective Loader Problem

Why loading DLLs from memory is both essential and dangerously detectable.

1. Why Reflective Loading Exists

Programs need to load DLLs into memory to use their exported functions. The standard Windows mechanism is LoadLibrary, provided by kernel32.dll. It works perfectly for legitimate software, but it creates a trail of telemetry that is fatal for offensive operations:

Every one of these steps is visible to EDR products. The PsSetLoadImageNotifyRoutine kernel callback alone gives security products the image name, base address, and size of every DLL loaded into every process on the system. Loading a malicious DLL (like Cobalt Strike Beacon) through LoadLibrary is equivalent to announcing your presence to every defensive tool on the endpoint.

In 2008, Stephen Fewer published Reflective DLL Injection, a technique that loads a DLL entirely from a memory buffer by reimplementing the Windows loader in user mode. This technique became the foundation for virtually every offensive DLL loader that followed, including Cobalt Strike's default loader, Metasploit's meterpreter, and dozens of open-source projects.

2. How Traditional Reflective Loading Works

Stephen Fewer's original technique works by embedding a small ReflectiveLoader function inside the DLL itself. When the raw DLL bytes are injected into a target process, execution begins at a bootstrap shellcode stub in the DOS header, which transfers control to ReflectiveLoader. The function then performs the same steps the Windows loader would, but entirely in user mode from a memory buffer.

Each step of the ReflectiveLoader deserves a closer look:

Here is conceptual pseudocode showing what ReflectiveLoader does internally:

C (Pseudocode)// Conceptual ReflectiveLoader pseudocode (simplified from Stephen Fewer's work)
DWORD ReflectiveLoader(VOID)
{
    // Step 1: Find our own image base by scanning backward for MZ header
    ULONG_PTR imageBase = FindImageBase(&ReflectiveLoader);

    // Step 2: Parse PEB to find kernel32.dll
    ULONG_PTR peb      = __readgsqword(0x60);    // x64: GS:[0x60]
    ULONG_PTR ldr      = *(ULONG_PTR*)(peb + 0x18);
    ULONG_PTR modList   = *(ULONG_PTR*)(ldr + 0x20); // InMemoryOrderModuleList

    // Walk module list, hash each name, find kernel32.dll
    ULONG_PTR k32Base  = FindModuleByHash(modList, KERNEL32_HASH);

    // Step 3: Resolve needed APIs from kernel32's export table
    fnLoadLibraryA   pLoadLibraryA   = GetExport(k32Base, LOADLIBRARYA_HASH);
    fnGetProcAddress pGetProcAddress = GetExport(k32Base, GETPROCADDRESS_HASH);
    fnVirtualAlloc   pVirtualAlloc   = GetExport(k32Base, VIRTUALALLOC_HASH);

    // Step 4: Allocate memory for the full image
    PIMAGE_NT_HEADERS ntHdrs = (imageBase + dosHdr->e_lfanew);
    LPVOID newBase = pVirtualAlloc(
        NULL,
        ntHdrs->OptionalHeader.SizeOfImage,
        MEM_RESERVE | MEM_COMMIT,
        PAGE_EXECUTE_READWRITE    // <-- RWX: Detection vector #3
    );

    // Step 5: Copy headers + each section to correct VA
    memcpy(newBase, imageBase, ntHdrs->OptionalHeader.SizeOfHeaders);
    for (each section in sectionTable)
        memcpy(newBase + section.VirtualAddress,
               imageBase + section.PointerToRawData,
               section.SizeOfRawData);

    // Step 6: Process base relocations (delta = newBase - preferredBase)
    ApplyRelocations(newBase, ntHdrs);

    // Step 7: Resolve IAT - load dependencies + resolve functions
    ResolveImports(newBase, ntHdrs, pLoadLibraryA, pGetProcAddress);

    // Step 8: Call DllMain
    fnDllMain entryPoint = newBase + ntHdrs->OptionalHeader.AddressOfEntryPoint;
    entryPoint((HINSTANCE)newBase, DLL_PROCESS_ATTACH, NULL);

    return 0;
}

3. Five Detection Vectors

While reflective loading avoids the telemetry generated by LoadLibrary, it introduces five new detection surfaces that modern security tools actively scan for. Understanding these is critical because they are the exact problems Crystal-Loaders was built to eliminate.

Vector 1: Private-Commit Executable Memory

When the Windows loader maps a DLL via LoadLibrary, it creates a section object of type SEC_IMAGE. The resulting memory pages are tagged as MEM_IMAGE in the VAD tree. Memory scanners know that all legitimate executable code should reside in image-backed regions.

A reflectively loaded DLL is allocated with VirtualAlloc, which creates MEM_PRIVATE pages. When those pages are later marked executable (or allocated as RWX from the start), the combination of MEM_PRIVATE + PAGE_EXECUTE* is an immediate detection signal. Legitimate processes almost never have executable private memory outside of JIT compilers (like .NET CLR or JavaScript V8).

Vector 2: MZ/PE Headers in Private Memory

The first two bytes of every PE file are 0x4D 0x5A ("MZ"). After reflective loading, the PE headers are copied to the start of the allocated region. A trivial YARA rule can find them:

YARArule reflective_dll_in_memory {
    meta:
        description = "Detects PE header in private executable memory"
    condition:
        uint16(0) == 0x5A4D and         // MZ magic at start of region
        uint32(uint32(0x3C)) == 0x4550   // PE signature at e_lfanew offset
}

Some loaders attempt to erase the headers after loading by zeroing out the first page. However, partial artifacts often remain: the Rich header, section names like .text and .rdata, or the optional header's magic value. More advanced scanners look for these secondary indicators even when the MZ bytes are erased.

Vector 3: RWX Memory

The classic ReflectiveLoader allocates the entire image as PAGE_EXECUTE_READWRITE. This single permission flag is the most straightforward detection signal. Legitimate compiled code is mapped with granular permissions: .text is RX, .rdata is R, .data is RW. The only common legitimate source of RWX memory is JIT compilation (CLR, V8), and those regions have specific, identifiable patterns.

Vector 4: Return Address / Call Stack Analysis

When a reflectively loaded DLL calls a Windows API, the thread's call stack contains return addresses that point into the privately-allocated memory region. EDR kernel callbacks (registered via ObRegisterCallbacks) can walk the thread's stack using RtlWalkFrameChain and check whether each return address falls within a known, file-backed module.

If a return address points to MEM_PRIVATE memory with no file object in the VAD tree, the EDR knows code is executing from a dynamic allocation. Tools like pe-sieve perform this check in user mode by scanning threads and resolving their stack frames against loaded module ranges.

Vector 5: IAT Artifacts

After the ReflectiveLoader resolves the Import Address Table, the loaded DLL contains a fully populated IAT: an array of function pointers to APIs in ntdll.dll, kernel32.dll, and other system DLLs. This structure is recognizable. Even when the PE headers are erased, the pattern of pointers (consecutive addresses into the same DLL's export range) can be identified by heuristic scans.

Additionally, the import directory entries themselves (the IMAGE_IMPORT_DESCRIPTOR array) contain RVAs to DLL name strings and function name strings. These strings persist in memory after loading and provide clear evidence of a mapped PE image.

4. Cobalt Strike's Loader Evolution

Cobalt Strike has progressively replaced and extended its loader architecture over many years. Understanding this timeline shows you why Crystal Palace exists and what gap it fills.

Notable Community UDRLs

The UDRL interface (CS 4.4) enabled the security research community to build sophisticated loaders that address specific detection vectors:

Each of these UDRLs addresses some of the five detection vectors, but they all still perform the fundamental reflective loading operation: take a PE DLL, parse its headers, map its sections, fix relocations, and resolve imports. The PE structure remains in memory in some form. Crystal Palace takes a fundamentally different approach.

5. What Crystal-Loaders Brings to the Table

Crystal-Loaders (a collection of PIC loaders built with Crystal Palace, designed for Cobalt Strike) does not patch or improve the reflective loading process. It eliminates it entirely. Instead of injecting a DLL and loading it in-memory, Crystal-Loaders uses a spec-driven build system to produce raw position-independent code at compile time.

How the Detection Vectors Are Addressed

6. Module Summary