Explain common process injection techniques and the API and behavioral signatures that reveal them.
Short answer
Process injection runs malicious code inside another process to hide and to inherit trust. Classic remote injection allocates memory in a target with VirtualAllocEx, writes a payload via WriteProcessMemory, and runs it with CreateRemoteThread. Variants include DLL injection via LoadLibrary, process hollowing that unmaps a suspended legitimate process and replaces its image, APC injection that queues code to a thread, and reflective or manual-mapped loading that avoids LoadLibrary entirely. You spot them by the telltale API sequences, RWX memory in a normally-clean process, threads with no backing file on disk, and parent-child anomalies.
Process injection lets malware execute its code inside another process — to hide from process-list inspection, to evade defenses that trust the host process, and to access another program's memory. Interviewers ask seniors this because injection is everywhere in modern malware, and recognizing it requires real Windows internals knowledge.
The classic technique
Remote thread injection follows a recognizable API sequence:
OpenProcessto get a handle on the target.VirtualAllocExto allocate memory in the target — frequently RWX (readable, writable, executable).WriteProcessMemoryto copy the payload in.CreateRemoteThread(orNtCreateThreadEx/QueueUserAPC) to execute it.
Seeing this chain in imports or at runtime is a near-certain injection tell.
Common variants
- DLL injection. Write a DLL path into the target and call
LoadLibraryvia a remote thread so the loader maps your DLL. - Process hollowing. Start a legitimate process suspended (
CREATE_SUSPENDED), unmap its original image, write a malicious image in its place, fix the entry point, and resume — the process looks legitimate by name but runs attacker code. - APC injection. Queue an asynchronous procedure call to an existing alertable thread so the payload runs when that thread next enters an alertable wait.
- Reflective / manual mapping. The payload maps itself into memory and resolves its own imports, never calling LoadLibrary, defeating detections that hook the loader.
How you detect it
Behaviorally: RWX private memory in a process that normally has none, threads with no on-disk backing file, a parent-child relationship that makes no sense (e.g. winword.exe spawning cmd.exe), and the API sequences above caught by EDR or in a debugger. In memory forensics, tools like Volatility's malfind flag injected regions. A senior answer pairs each technique with the API footprint and the artifact it leaves behind.
Likely follow-ups
- How does process hollowing differ from classic CreateRemoteThread injection?
- Why is RWX memory with no backing file a strong injection indicator?
- How does reflective DLL loading evade detections that hook LoadLibrary?