Memory Forensics Cheatsheet

Memory is the one place a running attack cannot fully hide: injected code, decrypted payloads, live network connections, and the processes a rootkit conceals from the operating system are all present in RAM even when the disk and the live tools show nothing. The cost is that memory is volatile and acquisition is one-shot, you capture it once, at the right moment, or it is gone. These commands use Volatility 3; the syntax is vol -f <image> <plugin>.

Why memory is ground truth

Disk forensics tells you what was stored; memory forensics tells you what was running. The gap between them is exactly where modern malware lives: fileless payloads that never touch disk, code injected into legitimate processes, credentials cached in LSASS, and rootkits that edit the kernel's own view so that ps, netstat, and the task list lie. Memory is also the only source for the decrypted form of something the disk holds only encrypted. The discipline is to acquire first and analyze offline, because every tool you run on the live host changes the memory you are trying to preserve.

Acquisition and first steps

Acquisition captures RAM to an image with the smallest possible footprint, then all analysis happens offline against that file, never on the live host, because every tool you run there overwrites the memory you are trying to preserve. Acquire as early as possible: memory changes by the second, and a process you wait to capture may exit, taking its evidence with it. First step on any image is to identify it. windows.info (or linux.banner) confirms the OS and build so Volatility loads the right symbol table; get this wrong and every subsequent plugin returns garbage or nothing, which examiners new to memory forensics often mistake for a clean result rather than a wrong profile.

Process analysis

Processes are the spine of a memory investigation, and the first questions are always the same: what is running, what launched it, and is anything hiding. windows.pslist walks the OS process list, the same view the live task list shows; windows.psscan ignores that list and scans raw memory for process structures directly. The power is in the comparison: a process in psscan but not pslist has been unlinked from the OS list, deliberately hidden by a rootkit, and that divergence is one of the highest-value findings in all of memory forensics because it points straight at active concealment. psscan also recovers terminated processes whose structures have not yet been overwritten, so it can show you what ran and exited before you captured. windows.pstree renders parentage so an implausible chain (services.exe spawning cmd.exe) jumps out, and windows.cmdline gives the full launch command, where encoded PowerShell and tell-tale arguments live.

Process injection

Injection hides malicious code inside a legitimate process, so the process name, its signature, and the file on disk are all innocent, which is precisely why it defeats disk forensics and most allowlisting. windows.malfind is the workhorse here: it flags memory regions that are executable and writable (RWX) and not backed by any file on disk, which is the structural signature of injected or reflectively-loaded code, because normal executable code is mapped read-only from a file, not written into private memory at runtime. malfind produces false positives (some legitimate JIT compilers use RWX), so the judgment is context: a RWX region with an MZ or PE header inside a process that has no reason to hold executable private memory, a browser, an Office app, the print spooler, is the lead worth dumping and analyzing. Hollowing is the subtler cousin: the process started legitimately, then had its image replaced, so pslist looks entirely normal and only the memory contents betray it.

Credential theft

LSASS holds the credentials of logged-on users in memory, which is exactly why it is the most-targeted process on a Windows host: dump LSASS and you walk away with hashes and sometimes plaintext for everyone logged on. Memory forensics works the other side of that attack. windows.hashdump, windows.lsadump, and windows.cachedump recover the credential material from the image, so you can establish exactly what an attacker who dumped LSASS would have obtained, scope which accounts must be considered compromised, and, by checking for injection or suspicious handles into LSASS, confirm whether the dump actually happened. The accounts you recover here define the blast radius of the incident.

Fileless malware and network

Fileless malware never writes its payload to disk: it runs from a script engine, a reflective load, or living-off-the-land tooling, so disk forensics finds nothing and memory is the only witness. The investigation chains process to network: find the script-engine or LOLBin process, read its command line, then map its connections. windows.netscan recovers the network connections from memory, including those the live tools were tricked into hiding.

Persistence and kernel rootkits

Persistence and kernel compromise are where memory forensics goes deepest. Registry hives are in memory too, so windows.registry.printkey reads autostart keys from the image. Kernel rootkits, the hardest threat to find anywhere else, are found by examining the structures they tamper with: windows.callbacks, windows.modules and windows.driverscan, and the interrupt tables. A driver in driverscan but not in the loaded-modules list is hidden, the kernel-level equivalent of the hidden process.

Linux memory

Linux memory forensics follows the same logic with the linux.* plugins, and it matters most on exactly the hosts where disk forensics is hardest: long-running servers an attacker has had time to clean. Acquire with AVML (a static binary needing no kernel headers) or LiME, identify with linux.banner, then the familiar moves: process listing and scanning to find the unlinked process, syscall-table hook detection for the kernel rootkit, and bash-history recovery straight from RAM, which routinely survives a .bash_history the attacker wiped on disk. That last one alone has broken open investigations where every on-disk trace was gone.

Quick lookup