Process Injection: How Code Ends Up Running Inside Something Legitimate

Process injection makes code run inside a process that already exists. The malicious code inherits that process's identity, its privileges, and its reputation — so network connections appear to come from a signed, trusted application, and a scanner looking for suspicious files finds nothing because the code was never a file on disk.

Why attackers do it

Three benefits, and they compound.

Evasion. Application allowlisting permits the legitimate process, and it is the legitimate process that is running. File-based scanning has no file to examine. Behavioural analysis sees activity attributed to a trusted binary.

Privilege and access. Injecting into a process running with higher privileges, or one already holding credentials and open handles, grants those without exploiting anything further.

Plausibility. Outbound connections from a browser process look entirely normal. The same connections from an unknown executable in a temporary directory do not.

The techniques, roughly by sophistication

DLL injection. The classic. Write the path of a malicious library into the target process's memory, then create a thread in that process which calls the standard library-loading function with that path. The target loads and executes the library as its own. Simple, well understood, and well detected — the library exists on disk and the loaded module list shows it.

Reflective DLL loading removes the disk requirement. The library is written directly into memory and performs its own loading — resolving imports and applying relocations itself — so it never touches the filesystem and does not appear in the module list.

Process hollowing. Start a legitimate process in a suspended state, unmap its original executable image from memory, write a malicious image in its place, and resume it. The process retains the name, path and often the signature of the legitimate program while executing entirely different code. Defeats anything checking only what was launched.

Thread execution hijacking suspends an existing thread, redirects its instruction pointer to injected code, and resumes it — no new thread is created, which removes one of the more obvious signals.

APC injection queues code to run when a thread enters an alertable state, and SetWindowsHookEx abuse loads a library into processes handling particular events.

Living-off-the-land variants achieve similar ends without custom code, using scripting engines and management frameworks already present — the territory under fileless malware and persistence.

Detection

Since the file-based signals are absent by design, detection has to come from behaviour, and the good news is that injection is behaviourally distinctive.

The API sequence is the strongest signal: opening a handle to another process, allocating memory in it with executable permissions, writing to that memory, and creating or redirecting a thread in it. Very little legitimate software does this, and the combination is rare enough to alert on directly — which is exactly what behaviour-based EDR is for.

Memory anomalies give the rest: executable regions not backed by a file on disk, a process whose loaded modules do not match its image, and a running image that differs from the file it claims to come from — the hollowing signature.

Unexpected parent-child relationships and unusual network behaviour from a process that does not normally connect out round it out. Because so much of this lives in memory, an infected host's RAM holds evidence that exists nowhere else, which is the reasoning behind the collection sequence under order of volatility.

Prevention

No single control stops it, and several raise the cost meaningfully.

Exploit mitigations help: arbitrary code guard, which prevents allocating executable memory dynamically, and code integrity guard, which requires loaded libraries to be properly signed. Both break some legitimate software, so they are applied per-application rather than globally.

Protected process light restricts which processes may open handles to sensitive ones, which is how credential stores are shielded. Application allowlisting reduces what can run in the first place, and least privilege limits which processes an attacker can reach — a standard user cannot inject into a process running as another user, which is why the escalation routes under Windows privilege escalation usually come first in a real chain.

And keeping endpoint tooling's own protections enabled matters, since disabling the agent is frequently the injected code's first action.

Exam angles

Define process injection as executing code within another process to inherit its privileges and evade detection. Know DLL injection as the basic technique, reflective loading as the diskless variant, and process hollowing as replacing a legitimate process image while keeping its identity. Recognize that these defeat file-based detection and application allowlisting, and that behavioural detection of the allocate-write-execute API sequence, plus memory analysis, is how they are found.

Comments