A SOC escalates a host: unusual outbound traffic, an EDR alert that fired and then went quiet, and instead of a clean IOC someone hands you a memory image and says "figure out what ran." No process name, no known-bad hash yet, just a few gigabytes of RAM captured off a box nobody wants to reimage until they know what happened. This is the moment memory forensics actually matters, and it's also the moment a lot of people freeze, because there's no single command that says "here's the malware."
There's an order that actually works, though, and it starts narrower than most people expect.
Process trees before anything else
A flat process list gives you names, but the tree is what actually matters, because malware families lie less about who spawned them than they lie about their own name. A process called svchost.exe sitting under explorer.exe as a parent instead of services.exe is a bigger tell than a slightly unusual filename. You're not looking for something with an obviously evil name, you're looking for a parent-child relationship that doesn't happen on a normal Windows box.
Then the injected-memory scan, for what the process list can't show you
A process can look completely legitimate in a listing and still be hollowed out or carrying an injected DLL, because a listing only tells you a process exists, not what's actually living in its memory. Scanning for memory regions with execute permissions that don't map back to a file on disk is close to a direct signature for process injection and reflective DLL loading. This is usually where the actual payload shows up once the process tree points you at a candidate.
Network connections, because most of this exists to talk to something
Almost nothing in this category sits quiet. Pulling network connections and listening ports out of the memory image catches ones a live netstat on the box would never see, because the malware already tore the socket down. Cross-reference the PID against whatever the process tree flagged, and an unexplained outbound connection to an IP that doesn't belong to anything on your asset list is usually the corroboration, not the discovery.
Loaded modules, for the hijacked-not-injected cases
Not everything is injection. Sometimes it's a legitimate process that loaded a malicious DLL because of a search-order hijack or a planted file sitting somewhere earlier in the load path. Listing what's actually loaded per process and checking for anything loading from a user-writable directory instead of System32 is worth doing even when nothing upstream flagged it.
None of this replaces a full investigation, timeline reconstruction and log correlation still matter. But this four-step pass, process tree, injected-memory scan, network connections, loaded modules, is what turns "here's a memory dump, good luck" into an actual starting point in under twenty minutes instead of an afternoon of undirected poking.
Codelivly's Digital Forensics Playbook walks through this exact triage workflow across a 259-page manual built around real investigations. If you want to run it hands-on first, the free Memory Forensics lab puts an actual dump in front of you before you spend anything.
