Deep Memory Forensics of Reflective DLL Injection in Windows

In the landscape of modern malware, stealth is the primary currency. Traditional DLL injection-utilizing the `LoadLibrary` API-is noisy. It leaves a clear audit trail: a new module is registered in the process's Loader Data Table (`Ldr`), a file-backed mapping exists in the Virtual Address Descriptor (VAD) tree, and the `Module` list in the Process Environment Block (PEB) is updated.

Reflective DLL Injection (RDI) circumvents these standard telemetry points. By implementing a custom, minimal version of the Windows PE loader within the DLL itself, an attacker can load a library directly from a buffer in memory. To a standard EDR monitoring API calls or module loads, the process appears unchanged. For the forensic practitioner, detecting RDI requires moving beyond high-level API monitoring and descending into the granular structures of process memory.

The Mechanics of the Reflective Loader

To understand the forensic footprint, one must first understand the lifecycle of a reflective injection. The process typically follows this sequence:

1. Allocation: The injector uses `VirtualAllocEx` to carve out a region of memory in the target process, usually with `PAGE_READWRITE` permissions.
2. Payload Transfer: The raw bytes of the DLL (the entire PE file) are written into the allocated region via `WriteProcessMemory`.
3. Execution Trigger: The injector uses `CreateRemoteThread` (or a hijacked thread) to point the instruction pointer (`EIP`/`RIP`) to the "Reflective Loader" function-a specific exported function within the injected buffer.
4. The Self-Loading Routine: This is where the magic happens. The exported stub performs the duties of the Windows OS Loader:

• Parsing the PE Header: It locates the `IMAGE_DOS_HEADER` and `IMAGE_NT_HEADERS`.
• Base Relocation: It iterates through the Base Relocation Table, adjusting absolute addresses to match the current load address in memory.
• Import Resolution: It parses the Import Address Table (IAT), uses `LoadLibraryA` and `GetProcAddress` (often via a custom implementation to avoid detection) to resolve dependencies, and populates the IAT.
• Section Mapping: It maps the various PE sections (`.text`, `.data`, `.rsrc`) into their proper relative virtual addresses (RVAs).
• Execution Transfer: Finally, it calls the `DllMain` entry point.

Because the Windows Loader is never invoked, the `Ldr` list (specifically `InLoadOrderModuleList`) remains oblivious to the presence of the malicious code.

Forensic Fingerprints: Finding the Invisible

Since the PEB is not updated, forensics must rely on the discrepancies between the VAD Tree and the Module List.

1. The VAD/Module Mismatch

The most significant indicator of RDI is the presence of "unbacked" executable memory. In a legitimate scenario, when a DLL is loaded, the VAD entry for that memory range points to a `FILE_OBJECT` (the DLL on disk). In RDI, the memory is allocated via `MEM_PRIVATE`.

When analyzing a memory dump (e.'g., via Volatility), look for memory regions with `PAGE_EXECUTE_READWRITE` (RWX) or `PAGE_EXECUTE_READ` (RX) protections that are marked as `MEM_PRIVATE`. If you find an MZ/PE header in a region that has no corresponding file on disk, you have found a high-fidelity indicator of injection.

2. Discrepancies in Thread Start Addresses

When `CreateRemoteThread` is used to trigger the reflective loader, the start address of the new thread will point to the allocated buffer. If you inspect the thread's start address and find it points to a memory region not associated with any known module (i.e., it is not within the range of a loaded `.dll` or the `.exe`), this is a massive red flag.

3. The Residual IAT/Relocation Artifacts

Even if an attacker attempts to wipe the PE headers after loading to evade scanners, the functional requirements of the DLL leave traces. The IAT must remain intact for the DLL to function. Scanning for patterns of `GetProcAddress` or `LoadLibrary` calls within private, executable memory can reveal the presence of the reflective stub.

Practical Detection Workflow

When performing live memory analysis or post-mortem forensics, follow this methodology:

Step 1: Scan for RWX/RX Private Memory

Use a tool like Volatility's `malfind` plugin. This plugin specifically looks for VAD nodes that are marked as executable and are not backed by a file.

```bash

Example Volatility 3 command

python3 vol.py -f memory.dmp windows.malfind

```

Look for: `PAGE_EXECUTE_READWRITE` and the presence of `MZ` headers.

Step 2: Verify Module Integrity

Cross-reference the output of `modules` (which parses the PEB) with `vadinfo` (which parses the VAD tree).

• Legitimate: VAD entry $\rightarrow$ `SEC_IMAGE` $\rightarrow$ `C:\Windows\System32\kernel32.dll`
• Suspect: VAD entry $\rightarrow$ `MEM_PRIVATE` $\rightarrow$ No file mapping.

Step 3: Inspect Thread Call Stacks

For suspicious processes, examine the call stack of all active threads. If a thread's stack contains return addresses pointing to `MEM_PRIVATE` regions, the thread is executing injected code.

Advanced Evasion and Operational Challenges

As defenders have improved VAD analysis, attackers have evolved. Two primary techniques complicate forensics:

Module Overloading

To bypass the "unbacked memory" detection, attackers use a technique called Module Overloading. Instead of `VirtualAlloc`, the attacker finds a legitimate, unused DLL on disk (e.g., a printer driver), maps

Conclusion

As shown across "The Mechanics of the Reflective Loader", "Forensic Fingerprints: Finding the Invisible", "Practical Detection Workflow", a secure implementation for deep memory forensics of reflective dll injection in windows depends on execution discipline as much as design.

The practical hardening path is to enforce host hardening baselines with tamper-resistant telemetry, behavior-chain detection across process, memory, identity, and network telemetry, and continuous control validation against adversarial test cases. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track time from suspicious execution chain to host containment and reduction in reachable unsafe states under fuzzed malformed input, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.