Reflective DLL injection is a malware technique that loads a dynamic-link library directly into a process from memory instead of using normal operating system loading. The DLL carries its own loader logic, which reduces file-based traces and can help evade endpoint detection while enabling code execution inside a trusted process.
How Reflective DLL Injection Works
Reflective dll injection is a memory-loading technique, not a normal file-based load. The DLL includes its own loader, resolves imports and relocations in memory, and starts execution inside a target process without relying on the standard operating system loading path.
That design matters because traditional detections often key off file creation, module load events, or suspicious disk artefacts. By keeping the payload largely in memory, reflective loading can reduce those traces and make analysis harder.
The technique is commonly discussed alongside process injection, process hollowing, unhooking, and other forms of runtime execution abuse. It is best understood as a way to place attacker-controlled code inside a legitimate process boundary while avoiding the visibility that comes from ordinary DLL loading.
Why It Is Dangerous in Endpoint and Process Security
Its danger comes from the combination of stealth and execution context. Once a malicious DLL is running inside a trusted process, it can inherit that process's privileges, network reach, and perceived legitimacy, which complicates both prevention and response.
It also weakens assumptions that security tools often make about what “normal” process behaviour looks like. If telemetry is focused on disk artefacts, conventional module lists, or user-visible installation paths, reflective loading can create a gap between what is running and what defenders expect to observe.
For this reason, the technique is a frequent component of EDR evasion tradecraft. The relevant defensive problem is not just spotting a DLL, but identifying suspicious in-memory execution, abnormal thread start patterns, API usage associated with manual mapping, and process behaviour that does not match the trusted image on disk.
How Defenders Look for It
Exposure review starts with knowing where the technique could matter most: endpoints that execute untrusted content, hosts that run administrative tooling, and high-value processes that are attractive targets for code injection. That inventory view is often more useful than looking for a specific file name.
Detection usually depends on combining behavioural telemetry. Analysts look for unusual memory regions, executable pages that do not map cleanly to loaded modules, remote thread creation, suspicious handle access, and process ancestry that suggests one process has staged code inside another. The goal is to reconstruct the execution path, not just identify a file on disk.
For broader context on evasion patterns, the EDR Evasion and Defence Guide covers the sensor-blinding and tamper patterns that often sit around reflective loading. External baseline references such as the OWASP Top 10 are not about this technique specifically, but they remain useful as a general reminder that executable abuse often exploits gaps between intended and actual trust boundaries.
Mitigation and Response
Defence is strongest when organisations combine hardening, prevention, and post-execution review. Application control, restriction of unsigned or untrusted code, and limiting which processes can create remote threads or load memory-resident payloads all raise the cost of abuse.
Where patching or full prevention is not yet possible, compensating controls should reduce the opportunity for execution inside privileged or highly monitored processes. Tighten least-privilege boundaries, reduce exposure of administrative tooling, and ensure EDR policies and tamper protections are hardened so they are harder to blind or disable once a process is compromised.
After suspected use, response should include a review of the parent-child process chain, injected memory regions, loaded modules, command-line context, and any credentials or tokens used by the affected process. If the injected code had access to service accounts, session material, or privileged automation, those identities and secrets should be treated as potentially exposed and rotated as needed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Reflective DLL injection is a process injection method used to run code inside another process. |
| T1620 — Reflective Code Loading | This technique directly describes code loaded and executed from memory rather than from disk. | |
| Recommendation — Map injected-process activity to T1055 and hunt for unusual thread creation, memory mapping and process ancestry. Treat in-memory DLL loaders as reflective code loading and alert on manual mapping behaviour. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection of reflective injection depends on collecting and retaining host telemetry and process activity logs. |
| Recommendation — Centralise endpoint and process telemetry so injected-code activity can be investigated after execution. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Reflective DLL injection is detected through monitoring of process and memory behaviour that deviates from normal execution. |
| AC-6 — Least Privilege | Injected code becomes more dangerous when it inherits unnecessary privileges from the host process. | |
| Recommendation — Monitor process, memory and module behaviour for signs of manual mapping and injected execution. Limit process and account privileges so injected code cannot inherit more access than necessary. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org