DLL Injection via CreateRemoteThread

 

What Is DLL Injection?

From game injectors to malicious actors, at its core, DLL injection is a method attackers use to sneak malicious code into legitimate processes. Instead of launching a standalone malware process, they embed their code inside a trusted one, great for evading detection!

One of the most common ways to do this on Windows is using a combination of:

  1. VirtualAllocEx

  2. WriteProcessMemory

  3. CreateRemoteThread

  4. LoadLibraryA

Here’s how it works step by step:

Step-by-step Injection Method: Create, Write, Load

  1. Pick a Target Process
    An attacker chooses a host process (e.g., svchost.exe), locates it via Windows APIs, and grabs a handle using OpenProcess

  2. Get LoadLibraryA Address
    Since kernel32.dll is loaded in most Windows processes, locating the address for LoadLibraryA is easy—and crucial for the next step 

  3. Prepare the DLL Path
    The attacker allocates memory inside the victim process (VirtualAllocEx) and writes the path to their malicious DLL using WriteProcessMemory

  4. Trigger DLL Loading
    They call CreateRemoteThread, pointing to the LoadLibraryA location in memory and passing the DLL path pointer as an argument 

In the end, target process silently loads the attacker’s DLL or even binary and the malicious code begins executing inside its memory space. Yikes..!

Why Attackers Love This Technique

  • Stealth & Privilege: The code runs under the chosen process’s privileges, making it hard for detection tools to spot or block.

  • Evasion: Since the attack only lives in memory, disk-based defenses often miss it.

Detection in the Wild

Sysmon (a Windows system monitoring tool) can make this visible:

  • Event ID 8: A process “writes” to another using VirtualAllocEx + WriteProcessMemory.

  • Event ID 7: A module is loaded in a process.

  • Event ID 11: A new file has been created, useful if the DLL was just dropped.

  • Synthetic Hunt Example: Match a “write into process” (ID 8) targeting kernel32.dll’s LoadLibraryA, followed by module loading or DLL creation activity, all within a tight time window.

In plain language: if one process injects memory into another and then the victim loads a new DLL, it's likely malicious.

False Positives

Some legitimate tools also use these techniques (debuggers, performance utilities), so it's important to:

  • Baseline normal behavior: Know which processes regularly allocate memory/write into others.

  • Check the chain: Who started it? Was the DLL path expected?

If a trusted tool like procdump.exe always behaves this way and is signed by the owner, and no new DLLs appear, you might consider it to be a False Positive.

Reflective DLL Injection 

This sub-variation of content injection is a stealthier, more advanced variant of DLL injection and it's a favorite among red teamers and threat actors alike. Unlike classic DLL injection (which uses Windows APIs like LoadLibrary), reflective injection doesn't rely on Windows to load the DLL. Instead, the attacker loads it from memory, bypassing the file system and many traditional defenses. This version of DLL injection is harder to detect and more evasion against traditional anti-virus.

Here’s what a attack usually does (assuming he wants the biscuit badly):

  1. Craft or download a reflective DLL
    This DLL includes custom code to load itself into memory, resolve imports, and perform relocations, basically everything LoadLibrary would usually handle.

  2. Open a target process
    Using OpenProcess, just like traditional injection.

  3. Allocate memory inside the target
    Via VirtualAllocEx, they create space to drop the reflective DLL.

  4. Write the entire DLL into that memory
    Using WriteProcessMemory, the attacker copies the whole DLL binary into the allocated memory region.

  5. Create a remote thread into the reflective loader
    Instead of calling LoadLibrary, they point the new thread to the entry point of the custom reflective loader inside the DLL as we have previously loaded it into memory in step 1.

Note that detection for reflective DLL injection will be unable to use Sysmon ID of 7 since LoadLibraryA is not being called and DLL is loaded via memory.

Comparison

Normal DLL Injection (LoadLibraryA Method)

  • You write the path to the DLL file into the memory of the target process.

  • Then you call LoadLibraryA in the target process using CreateRemoteThread.

  • Windows takes care of:

    1. Reading the DLL from disk

    2. Mapping it into memory

    3. Resolving imports and relocations

Reflective DLL Injection

  • You don’t call LoadLibrary at all.

  • Instead, you:

    1. Load the entire DLL binary into memory manually using WriteProcessMemory

    2. Use CreateRemoteThread (or equivalent) to jump into a function inside the DLL often a custom reflective loader

    3. The reflective loader manually performs what LoadLibrary would do, parsing the PE headers and resolving imports.