T1055.001: Dynamic-link Library Injection
Adversaries may inject dynamic-link libraries (DLLs) into processes in order to evade process-based defenses as well as possibly elevate privileges. DLL injection is a method of executing arbitrary code in the address space of a separate live process.
DLL injection is commonly performed by writing the path to a DLL in the virtual address space of the target process before loading the DLL by invoking a new thread. The write can be performed with native Windows API calls such as VirtualAllocEx and WriteProcessMemory, then invoked with CreateRemoteThread (which calls the LoadLibrary API responsible for loading the DLL). CitationElastic Process Injection July 2017
Variations of this method such as reflective DLL injection (writing a self-mapping DLL into a process) and memory module (map DLL when writing into process) overcome the address relocation issue as well as the additional APIs to invoke execution (since these methods load and execute the files in memory by manually preforming the function of LoadLibrary).CitationElastic HuntingNMemory June 2017CitationElastic Process Injection July 2017
Another variation of this method, often referred to as Module Stomping/Overloading or DLL Hollowing, may be leveraged to conceal injected code within a process. This method involves loading a legitimate DLL into a remote process then manually overwriting the module's AddressOfEntryPoint before starting a new thread in the target process.CitationModule Stomping for Shellcode Injection This variation allows attackers to hide malicious injected code by potentially backing its execution with a legitimate DLL file on disk.CitationHiding Malicious Code with Module Stomping
Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via DLL injection may also evade detection from security products since the execution is masked under a legitimate process.
Security context for executives and security teams
Dynamic-link Library Injection matters because malicious code can run inside a legitimate Windows process, making business-critical endpoint activity harder to trust. For leaders, the practical issue is not just malware execution; it is whether endpoint monitoring can distinguish normal process behavior from code being loaded into another process for stealth or privilege escalation.
Executive priority
Treat this as a Windows endpoint resilience and incident-response readiness priority. ATT&CK maps this sub-technique to Process Injection, stealth, and privilege escalation, and also links it to multiple groups, malware families, and a ransomware intrusion campaign. Executives should ask whether endpoint controls provide behavioral prevention and whether SOC teams can produce evidence of suspicious DLL loading, remote thread creation, and memory-write activity during an investigation.
Technical view
This is a Windows sub-technique of Process Injection. ATT&CK describes common use of Windows APIs such as VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, and LoadLibrary, plus variants such as reflective DLL injection, memory module loading, and module stomping/DLL hollowing. Because MITRE provides no official detection text for this object, SOC teams should validate coverage using the related detection strategy DET0389, Behavioral Detection of DLL Injection via Windows API, and confirm whether endpoint telemetry can correlate process-to-process memory writes, DLL/module loads, and new thread creation in another process context.
Likely telemetry
- Endpoint process creation and parent/child process context
- DLL/module load events on Windows endpoints
- Process-to-process memory allocation and memory-write events
- Remote thread creation or thread start telemetry
- Windows API-level endpoint events where available, including VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, and LoadLibrary-related behavior
Detection direction
- Validate behavioral detections rather than relying only on process names or file signatures, because execution may be masked under a legitimate process.
- Tune analytics around unusual combinations: a process writing to another process, loading or mapping a DLL, and starting execution in the target process.
- Account for variants described by ATT&CK, including reflective DLL injection and module stomping, where normal DLL-on-disk evidence may be incomplete or misleading.
- Review false positives from legitimate security tools, software updaters, debuggers, accessibility tooling, and enterprise management agents that may interact with other processes.
- Use relationship context for threat hunting: ATT&CK links this behavior to multiple groups, software entries, and campaign C0015, but local telemetry is required before making attribution or exposure claims.
Mitigation priorities
- Prioritize M1040 Behavior Prevention on Endpoint for Windows systems: endpoint technologies should analyze process behavior, files, API calls, and other endpoint events rather than depending only on known signatures.
- Ensure endpoint prevention policies are tested against suspicious process behavior patterns associated with DLL injection, including cross-process memory writes and remote execution in another process context.
- Sequence operational controls around high-value endpoints first, then expand validation across standard Windows workstation and server baselines.
- Document prevention and detection evidence for audit, incident response, and control assurance, especially where privileged Windows processes are in scope.
Additional notes and limits
This object is T1055.001, Dynamic-link Library Injection, an ATT&CK Enterprise Windows sub-technique under Process Injection. Relationship context includes detection strategy DET0389 and mitigation M1040, plus many ATT&CK uses relationships to groups, software, and campaign C0015. Those relationships support prioritization and hunting context, not a claim that any specific organization is currently targeted.
MITRE provides no official detection text for this object. The take is limited to supplied ATT&CK fields, external references, and relationships. Detection feasibility depends on local endpoint telemetry depth, EDR configuration, retention, and analyst ability to separate malicious injection from legitimate cross-process behavior.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Dynamic-link Library Injection
Adversaries may inject dynamic-link libraries (DLLs) into processes in order to evade process-based defenses as well as possibly elevate privileges. DLL injection is a method of executing arbitrary code in the address space of a separate live process.
DLL injection is commonly performed by writing the path to a DLL in the virtual address space of the target process before loading the DLL by invoking a new thread. The write can be performed with native Windows API calls such as VirtualAllocEx and WriteProcessMemory, then invoked with CreateRemoteThread (which calls the LoadLibrary API responsible for loading the DLL). CitationElastic Process Injection July 2017
Variations of this method such as reflective DLL injection (writing a self-mapping DLL into a process) and memory module (map DLL when writing into process) overcome the address relocation issue as well as the additional APIs to invoke execution (since these methods load and execute the files in memory by manually preforming the function of LoadLibrary).CitationElastic HuntingNMemory June 2017CitationElastic Process Injection July 2017
Another variation of this method, often referred to as Module Stomping/Overloading or DLL Hollowing, may be leveraged to conceal injected code within a process. This method involves loading a legitimate DLL into a remote process then manually overwriting the module's AddressOfEntryPoint before starting a new thread in the target process.CitationModule Stomping for Shellcode Injection This variation allows attackers to hide malicious injected code by potentially backing its execution with a legitimate DLL file on disk.CitationHiding Malicious Code with Module Stomping
Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via DLL injection may also evade detection from security products since the execution is masked under a legitimate process.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.