Reflective DLL Injection: Loader Evidence in Memory
Reflective DLL injection places a DLL-like image into memory without relying on the ordinary file-backed loading path. Understanding the high-level loader responsibilities gives defenders a structured way to hunt for mapping inconsistencies and execution outside expected modules.
The material below describes evidence and controls. It omits loader source, injection sequences, and executable demonstrations.
High-level architecture
The Windows loader normally maps an image, applies relocations, resolves imports, establishes protections, registers metadata, and invokes initialization. A reflective loader performs enough of those responsibilities from memory for the module to run. Imperfect emulation of the normal loader can leave discrepancies in page type, headers, protection boundaries, loader lists, unwind information, and file provenance.
High-value indicators
- PE-like structures or executable sections inside private rather than image-backed memory.
- A module visible to a memory scanner but absent from expected loader inventories.
- Headers erased or inconsistent with in-memory section boundaries.
- Thread start addresses or stack frames inside unbacked executable regions.
- Cross-process handle access followed by remote memory modification and execution.
Do not alert on one item alone. Managed runtimes, packers, browsers, and endpoint products can produce unusual memory. Weight the target process, source signer, access rights, page history, prevalence, and subsequent behavior.
Investigation workflow
Preserve a memory image and process timeline. Enumerate VADs, loaded modules, threads, handles, and network state. Compare suspicious regions with disk images, validate PE structures, and inspect call stacks around the first observed execution. Then trace backward to the creating process and forward to child processes, persistence, credentials, and network activity.
GitHub tools and safe validation
PE-sieve and Moneta highlight suspicious mappings; Volatility 3 supports offline memory analysis; capa assists capability triage. Validate rules against benign manually mapped application components supplied by your own engineering team, then measure false positives across browsers, .NET applications, anti-cheat systems, and EDR software.
ATT&CK, CVEs, and controls
The canonical mapping is T1055.002 Portable Executable Injection. Reflective loading is a technique, not a vulnerability, and has no universal CVE. Relevant CVEs concern the initial access or privilege-escalation flaw used in a specific incident. Reduce exposure with WDAC, least privilege, ASR rules, credential isolation, protected processes where supported, and endpoint products that retain memory-protection and thread telemetry.