Reflective DLL Injection: How Malware Executes DLLs Directly in Memory Without Disk Files

Reflective DLL Injection enables attackers to execute code without placing a suspicious library on disk or registering it through normal Windows module lists. The technique prepares a full working copy of a Portable Executable image directly in process memory, skipping the standard LoadLibrary path.

In a classic reflective scheme, a small loader embedded inside the DLL performs the work normally handled by the Windows loader. It parses its own headers, maps sections, applies base relocations, resolves imports, initializes Thread Local Storage, registers exception tables, and calls entry points. The approach is named after this self-contained preparation step.

What Makes Loading Reflective

Three distinct concepts must be separated: reflective loading prepares the library, manual mapping uses an external loader, and process injection delivers code into another address space. Only the first two affect how the image itself becomes executable; injection adds separate requirements for cross-process access rights.

• Ordinary LoadLibrary – Windows loader maps the file and resolves dependencies.
• Reflective loading – Code inside the DLL prepares its own working copy from a memory buffer.
• Manual mapping – External code performs mapping and relocation instead of the system loader.

Why Raw DLL Bytes Are Not Yet a Working Library

PE images store sections at file offsets that differ from their final RVA locations. A loader must translate between file offsets, relative virtual addresses, and actual virtual addresses while respecting SizeOfRawData versus VirtualSize. Incorrect arithmetic or failure to process relocation records of type HIGHLOW or DIR64 produces corrupted code that may crash later.

Where Simplified Implementations Usually Fail

Common omissions include proper handling of delayed imports, correct OriginalFirstThunk versus FirstThunk tables, full TLS directory processing, and registration of x64 exception unwind data. A function that returns a constant value often succeeds while the first exception or thread-local access triggers an immediate crash.

Memory Artifacts and Detection

Reflective modules frequently appear in MEM_PRIVATE executable regions without corresponding ImageLoad events. Analysts should combine memory-region provenance, thread start addresses, preserved PE headers, and surrounding process behavior. Volatility 3 plugins such as malfind help locate candidate regions, while Sysmon events 7, 8, and 10 provide timeline context when collection is enabled.

Limitations and Protections

The technique respects DEP and can be blocked by Arbitrary Code Guard when the process policy forbids converting memory to executable. It also requires appropriate access rights for cross-process injection and does not grant privileges by itself.