finding malware hiding inside a trusted process's memory

hook

malware doesn't usually run around wearing a name tag that says "hi i'm evil.exe". it hides inside a process you already trust, something like explorer.exe or svchost.exe, and just rides along quietly. that's process injection, and it's one of the most common tricks in the book because it works. the good news is memory doesn't lie, and if you know where to look, injected code leaves a very specific footprint.

why this trick works

your antivirus and your own eyeballs are trained to trust well known process names. if explorer.exe is running, most people assume it's just... explorer.exe doing explorer.exe things. but windows doesn't stop a process from allocating new memory inside itself and stuffing executable code into it at runtime. that memory never touches disk as a file, so file based scanning and hash checks miss it completely. the process looks legit from the outside while running someone else's code on the inside.

the tell: private, writable, executable

normal program code lives in memory regions that are typically executable but not writable, because legit code doesn't need to rewrite itself while running. injected code breaks that pattern. it needs a region that's private (not backed by a normal file on disk), writable (so the malware can drop its payload in), and executable (so it can actually run). that combo, private plus writable plus executable, almost never happens naturally. it's basically a neon sign.

this is exactly what volatility's malfind plugin hunts for. it walks through a memory dump, checks every memory region for that specific combination, and flags the suspicious ones for you to inspect.

vol -f mem.raw windows.malfind

you point it at a memory dump file, tell it which plugin to run, and it spits out a list of processes with suspicious regions, along with a hex dump of the start of that memory so you can eyeball it.

reading the output

the part that turns "suspicious" into "confirmed" is the header. a normal PE (portable executable) file, the format for every .exe and .dll on windows, starts with the letters MZ. if malfind shows you a private RWX region inside explorer.exe and the first two bytes of that hex dump are 4D 5A, that's literally "MZ" in ascii. that means there's a whole separate executable sitting inside a process that never loaded it from disk. that's not a coincidence, that's an injected payload, full stop.

once you've got a hit, don't stop there. figure out what that process actually did next.

vol -f mem.raw windows.pstree

pstree rebuilds the parent-child process relationships from the same memory dump. if your "trusted" explorer.exe suddenly spawned powershell.exe, or some renamed copy of cmd.exe, or reached out and launched a network tool it has no business touching, that's your blast radius. this is how you go from "found a needle" to "here's everywhere the needle poked."

why this beats antivirus alone

signature based tools look for known bad files. injected code was never a file, it was assembled in memory at runtime, so there's nothing on disk to hash or scan. memory forensics doesn't care what the malware calls itself or whether it matches a known signature, it cares about behavior: is there a chunk of memory that shouldn't exist in a normal, unmodified process. that's a much harder thing for malware to hide, because the injection technique itself is the giveaway, not the payload's identity.

the takeaway

process injection works because most defenses trust a familiar process name and never look inside it. malfind flips that by checking the actual shape of memory, private, writable, and executable all at once, which legitimate code almost never needs. if you're building out your own defensive toolkit, grab a memory dump of a system you own with something like winpmem, run malfind against it, and get comfortable reading the output before you ever need it under pressure. pair it with pstree so you're not just finding the injection, you're tracing what it touched. practicing this on your own lab machines now means you're not learning volatility for the first time in the middle of an actual incident.