How do you show from a memory image that code was injected into a signed running process?

## Why the process list cannot help An operator injects a payload into a process that is already running: a signed, correctly installed Windows binary on a production application server. No file is written, no process is created, no unusual parent-child pair appears. The image on disk is genuinely untampered and its signature genuinely verifies. Every enumeration-based check passes. The evidence, if it exists at all, is inside one process's address space. ## The region map is the instrument Windows describes each process's address space as a set of regions, each with a size, a protection value and - crucially - a **backing**. A region is either *image-backed* (it maps a portion of an executable file the loader opened), *file-backed* (it maps some other file) or **private** (it maps nothing; the kernel simply gave the process memory). Legitimate program code lives in image-backed regions, because that is what loading an executable does. So the first-order question is: **is there private, committed memory in this process that carries execute permission?** That is code with no file behind it. Nothing the loader did put it there. ### Strengthening the finding Unbacked executable memory alone is suggestive; it is the corroboration that makes it defensible. - **A PE header in anonymous memory.** If the first bytes of a private executable region are `MZ` and a valid PE structure follows, someone mapped a whole executable image by hand rather than through the loader. Compilers that generate code at runtime emit bare instructions, not full PE images. - **Thread origin.** Every thread has a start address. A thread whose start address falls inside a private executable region - or anywhere outside every loaded module - is executing code the loader never loaded. - **Module-list divergence.** The loader keeps a per-process list of loaded modules. A module visible in the region map but missing from that list was mapped deliberately outside the loader, or unlinked afterwards. - **Ownership of network state.** If the kernel's endpoint structures show an outbound connection owned by that process id and the process's function does not explain it, the injected code has a purpose you can name. - **Handles and access.** A separate process holding a handle to this one with rights sufficient to write memory and create a remote thread is the other half of the story, when that process is still alive. ### Hollowing looks different Process hollowing does not add a private region; it replaces the contents of one that is image-backed. The tell is a **comparison**: read the mapped image's bytes out of memory and compare them against the file on disk that the region claims to map. Legitimate divergence exists - the loader applies relocations and patches the import table - so compare section characteristics and code bytes with that in mind rather than expecting a byte-for-byte match. A base address recorded in the process's own environment block that disagrees with the module list is another signal. ## The false positives are the hard part This is where candidates separate. Runtimes that compile code while the program runs - managed application hosts, Java virtual machines, browser script engines - allocate private executable memory continuously and by design. On an IIS worker process running managed code, private executable regions are the *normal* condition, and an analyst who flags every one of them will drown a purple-team report in noise and lose the argument. The discriminators hold up: JIT-emitted code has no PE header, its threads belong to the runtime and start inside runtime modules, and it does not open a long-lived connection to an address nobody can account for. Other benign sources of unbacked or unusual executable memory include software packers used by legitimate products, and security tooling that hooks processes on purpose. ## What the finding actually proves Be careful with the claim. The image shows that executable, unbacked memory existed in that process and that a thread ran from it. It proves code executed that the loader did not load. It does not, on its own, prove *what* the code did - and the analysis of the recovered payload itself is a different discipline. In an exercise context the useful statement is narrower and stronger: the technique executed on this host, it is visible in memory, and nothing in the estate recorded it - no rule fired and no sensor produced a record - which is a statement about coverage, evidenced by the image. ## The signature argument When someone objects that the host process is signed, the answer is that Authenticode covers a *file* and is verified when it is loaded. Nothing re-verifies a process's memory afterwards. The injected thread inherits the host's name, its signature, its user context and often its network reputation - which is the entire reason the technique is used.