Dynamic-link Library injection (T1055.001) is a Windows process injection method. MITRE places it under Stealth and Privilege Escalation. The aim is to execute code in the address space of a separate live process, which can evade process based defenses and may bring access to that process's memory, network resources and privileges.
How attackers use it
MITRE describes the classic form as writing the path to a DLL into the target process's virtual memory, then loading it by invoking a new thread. The write uses native calls such as VirtualAllocEx and WriteProcessMemory. The thread is started with CreateRemoteThread, which calls the LoadLibrary API that loads the DLL.
There are variations:
- Reflective DLL injection writes a self mapping DLL into a process.
- Memory module injection maps the DLL as it writes it.
- Module stomping, also called module overloading or DLL hollowing, loads a legitimate DLL into a remote process and overwrites the module's AddressOfEntryPoint before starting a thread. This can hide injected code by backing it with a legitimate DLL on disk.
The reflective and memory module forms avoid the extra APIs and the address relocation problem because they perform the loading steps manually.
How to detect it
MITRE's analytic correlates memory allocation and writing into a remote process (VirtualAllocEx, WriteProcessMemory) with remote thread creation (CreateRemoteThread) that loads a suspicious or unsigned DLL through LoadLibrary or reflective loading.
Useful questions for your telemetry:
- Which processes open handles to other processes with write access, and is that normal for them?
- Does a remote thread start in a process that did not create it?
- Is a module loaded from an unusual path, or is it unsigned?
Sysmon event ID 8 (CreateRemoteThread) and event ID 7 (image loaded) are common sources for these questions.
How to reduce the risk
MITRE lists behavior prevention on endpoint. Some endpoint security tools can block common sequences of behavior that occur during injection. For process injection broadly, MITRE adds that on Windows 10 Attack Surface Reduction rules may prevent Office applications from code injection.
Check your own environment
Confirm that your endpoint tooling logs remote thread creation and image loads, and that you can answer the three questions above for a test host. Check that the ASR rule set is enabled where Office is deployed.
Quick check
Why is module stomping harder to spot than classic DLL injection?
The injected code is backed by a legitimate DLL on disk, so it can look like a normal module load.
Which API starts the thread in classic DLL injection?
CreateRemoteThread, which calls LoadLibrary to load the DLL.
