Process Injection: How It Works and How Defenders Catch It

Process injection is one of the first techniques you meet when studying malware, and one of the first that endpoint products learned to catch. This writeup covers the classic remote thread variant in an isolated lab, focusing on what each step looks like from the defender's side.

The technique in four calls

• OpenProcess: get a handle on the target with write and thread-creation rights.
• VirtualAllocEx: reserve a memory region inside the target process.
• WriteProcessMemory: copy the payload into that region.
• CreateRemoteThread: start a thread in the target at the payload address.

Each call is legitimate on its own; debuggers and accessibility tools use them every day. It is the sequence, the memory protection, and the pairing of source and target process that make it suspicious.

What it leaves behind

• Sysmon Event ID 10 (ProcessAccess) with a broad access mask from an unusual source image.
• Sysmon Event ID 8 (CreateRemoteThread) where the start address is not backed by a module on disk.
• A private memory region that is both writable and executable inside the target.

Detecting it

A simple starting point is to alert on remote threads landing in processes that rarely receive them, while excluding known system sources. Tune the filter against your own baseline before relying on it.

title: Remote Thread Created In Uncommon Target
logsource:
  product: windows
  category: create_remote_thread
detection:
  selection:
    TargetImage|endswith:
      - '\notepad.exe'
      - '\explorer.exe'
  filter:
    SourceImage|startswith: 'C:\Windows\System32\'
  condition: selection and not filter
level: medium

Takeaways

Understanding the offensive side is what makes the detection meaningful: once you know which artifacts are unavoidable, you know where to look. Everything here was run in an offline lab VM against my own test processes.