Volatility: pulling credentials and injected code from memory

The evidence that evaporates

Turn off a computer and the assumption is that whatever it was doing vanishes. The passwords a user typed, the encryption keys unlocking their disk, the malware quietly running inside a trusted process: all gone the instant the power drops. That assumption is wrong, and the gap between it and reality is where a whole discipline lives. In 2008 a team led by J. Alex Halderman at Princeton showed just how wrong. In their paper Lest We Remember: Cold Boot Attacks on Encryption Keys, presented at the USENIX Security Symposium, they demonstrated that dynamic RAM does not forget its contents the moment it loses power. At room temperature the data fades over seconds. Chill the chips with a can of upside-down compressed-air duster, which sprays out at roughly minus 50 degrees Celsius, and the contents can survive for minutes. Cool them further and it stretches to hours. During that window an attacker can yank the memory modules out, drop them into another machine, and read what was there, including the keys protecting BitLocker, FileVault, dm-crypt, and TrueCrypt. That physical fragility is the flip side of a much larger truth: while a computer runs, its memory is the most honest witness it has. Everything a program does has to pass through RAM. Secrets that are encrypted on disk sit decrypted in memory so the CPU can use them. Malware that never writes a file to disk still has to exist somewhere, and that somewhere is memory. Which is exactly why an open-source tool called Volatility became one of the most important instruments in digital forensics.

From academic prototype to standard tool

Volatility did not start as a product. It started as research. In the mid-2000s Aaron Walters, Nick Petroni, and colleagues built FATKit, the Forensic Analysis ToolKit, a modular framework for pulling structure out of raw volatile memory. It was presented at the Digital Forensic Research Workshop, the field's academic gathering. FATKit begat a tool called Volatools, which the authors released at the BlackHat DC conference in 2007. Later that year the project was renamed and version 1.1.1 of Volatility shipped as free, open-source Python, according to the Volatility Foundation's own timeline. The trajectory from there tracks the growth of the whole field. Version 2.0 arrived in January 2011. Over the next few years the tool learned to read 64-bit Windows, then Linux, then macOS and Android. In 2014 four of the project's core people, Michael Hale Ligh, Andrew Case, Jamie Levy, and Aaron Walters, published The Art of Memory Forensics, a 900-page brick of a book that is still the canonical text. In February 2021 the team shipped Volatility 3, a complete rewrite in Python 3. By May 2025 the newer version reached feature parity and the older 2.x line was deprecated. The framework is maintained by the Volatility Foundation, a nonprofit that Walters and Petroni cofounded and which was granted 501(c)(3) status in 2014, as the Foundation describes. The whole thing runs under an open license, which matters more than it sounds: forensic evidence sometimes ends up in court, and an open tool whose logic anyone can inspect is easier to defend than a black box.

How Volatility reads a corpse of RAM

A memory dump is not a tidy filesystem. It is a flat, multi-gigabyte blob of bytes: the literal contents of physical RAM at the instant it was captured. There are no filenames, no folders, no labels. Making sense of it means reconstructing, from the outside, the data structures the operating system was using on the inside. Every OS keeps lists of what it is doing. Windows tracks running processes in a doubly linked list of structures called EPROCESS. It maps each process's virtual memory using a tree of Virtual Address Descriptors, or VADs, which record which ranges of memory a process has claimed and what permissions each range carries. It translates virtual addresses to physical ones through page tables. Volatility's job is to find these structures in the blob and walk them, the same way the kernel would, but from a frozen snapshot rather than a live system. Older versions did this using "profiles," hand-built descriptions of how a given Windows build laid out its structures. Volatility 3 replaced that with symbol tables generated from Microsoft's own debugging symbols, so the tool can often figure out the exact OS build on its own. On top of that sits a library of plugins, each answering one question. pslist walks the process list. pstree shows the parent-child relationships between processes, which is how you notice that cmd.exe was spawned by a Word document. netscan recovers network connections. cmdline recovers the exact command line each process was launched with. The design is deliberately extensible, and the Foundation runs an annual plugin contest that has produced much of the tool's more exotic capability. The reason all this beats simply reading a hard drive is that disks lie by omission. A sophisticated intruder can avoid writing anything to disk at all. Memory cannot be avoided, because the CPU can only execute what is loaded into it.

Finding code that was never on disk

The signature move of modern intrusions is to run malicious code inside a process that is supposed to be trustworthy. The techniques have names. In process hollowing, an attacker starts a legitimate program in a suspended state, scoops out its real code, replaces it with a payload, and lets it run wearing the victim's identity. In reflective DLL injection, a malicious library is loaded straight from memory without ever calling the normal Windows loader, which means it never touches disk and sidesteps most application allow-listing, as Microsoft's security researchers have documented. There are others: APC injection, thread hijacking, and direct system calls that skip the monitored APIs entirely, catalogued in Palo Alto Networks' breakdown of process injection. All of these leave the same tell. Injected code has to live in a region of memory that is both writable, so the payload can be placed there, and executable, so it can run. Legitimate software almost never needs both at once. Normal program code is loaded from a file on disk, marked executable and read-only. Data regions are writable but not executable. A chunk of memory that is writable, executable, and not backed by any file is the classic fingerprint of injected shellcode. Volatility's malfind plugin hunts for exactly this. It walks each process's VAD tree looking for private, unbacked regions carrying execute-plus-write permissions, then inspects the bytes it finds, flagging telltale signs like an MZ header (the two-byte marker that begins every Windows executable) sitting where no executable should be, per the Volatility 3 documentation. It is careful about false positives, ignoring regions that are entirely zeroed or paged out. It is not magic: malfind will miss a DLL that was injected through the normal LoadLibrary path, because that DLL is not hidden and shows up in an ordinary module listing instead. But for the runtime-only tricks that define fileless malware, it is often the fastest way to find the needle. This is the point that trips people up. The common belief is that "fileless" malware is invisible. It is invisible to tools that only look at disk. To a tool that looks at memory it can be loud, because the very thing that makes it fileless, living entirely in RAM, is what puts it squarely in the one place memory forensics is designed to search.

Pulling passwords out of the air

Detecting injected code is half the story. The other half is credentials, and here memory is a treasure chest. On Windows, authentication runs through a process called the Local Security Authority Subsystem Service, or LSASS. When you log in, LSASS holds the material needed to prove who you are so you do not have to retype your password for every action. Depending on configuration, that can include NTLM password hashes, Kerberos tickets, and in some cases secrets that can be reversed to plaintext. Whoever can read LSASS memory can often impersonate every user who has logged into that machine. This is MITRE ATT&CK technique T1003.001, and the catalog of groups that use it reads like a who's who of state-sponsored intrusion: APT28, APT41, Sandworm, HAFNIUM. The best-known tool for this is Mimikatz, written by Benjamin Delpy, whose sekurlsa module extracts credentials directly from LSASS. Attackers often pair it with entirely legitimate utilities. Microsoft's own signed ProcDump can snapshot LSASS to a file that antivirus tends to ignore because the tool is trusted, and a built-in Windows library, comsvcs.dll, can be coaxed into doing the same with one command. The dump is then carried off and mined elsewhere. Volatility approaches the same target from the forensic side. Its hashdump and lsadump plugins reconstruct password hashes and LSA secrets from a captured image, and community plugins have wrapped Mimikatz's logic so an analyst can run the equivalent extraction against a dead memory file rather than a live machine. The distinction matters: an incident responder is not trying to break in. They are trying to answer, after the fact, whether an intruder could have harvested these credentials, and which ones. A dump captured during the incident can settle that question definitively. The reach of this is not academic. The 2017 NotPetya attack, which caused damages later estimated in the billions of dollars, embedded a customized version of Mimikatz to scrape credentials from memory and spread laterally across corporate networks. The malware's own credential-stealing component lived in memory, and memory is where its behavior can be reconstructed.

The cold boot problem, and physical access

Everything above assumes you can get a copy of memory in the first place. On a running machine you own, that is a software problem: tools like WinPmem on Windows or the LiME kernel module on Linux walk physical memory a page at a time and write it out. But the Halderman cold boot work pointed at a stranger route, one that does not need cooperation from the operating system at all. Because DRAM holds its charge briefly after power is cut, an attacker with physical access can reboot a locked machine into a tiny program that dumps RAM before the old contents decay, or in the extreme version, freeze the modules, move them to a machine they control, and read them there. The decay is not random noise. Bits tend to fade toward a predictable ground state at a measurable rate, which means even a partly-decayed image can be error-corrected back to a usable encryption key. That is what let the Princeton team defeat full-disk encryption products that were, by every other measure, doing their job. The disk was encrypted. The key was just sitting in RAM, because it had to be for the disk to be readable. The lesson generalized. A laptop that is merely locked, or asleep with the screen off, is usually still holding its disk-encryption key in memory. Only a fully powered-off machine, or one using hardware that encrypts memory itself, closes that window. It is the reason security-conscious guidance tells people crossing hostile borders to shut laptops all the way down rather than just closing the lid.

Where it breaks down

None of this is a solved, one-click process, and it is getting harder in ways worth understanding. The first problem is that capturing memory takes time, and a running system does not hold still while you do it. Acquisition tools copy RAM page by page, and by the time they reach the last page the first pages may be stale. The result is a subtle corruption the field calls page smearing: page tables that point at physical pages whose contents changed mid-capture. A 2025 study quantifying inconsistencies in memory dumps found that these artifacts are common enough to matter, and that in bad cases Volatility cannot parse the snapshot at all. A memory image is not a photograph of a single instant. It is more like a long-exposure shot of a moving scene, and the analyst has to account for the blur. The second problem is that defenders have started encrypting the very secrets memory forensics relies on. Microsoft's Credential Guard, documented on Microsoft Learn, uses virtualization-based security to move credential material out of ordinary LSASS memory and into an isolated process, LsaIso.exe, that runs at a separate trust level the main OS cannot read even with administrator rights. Where it is enabled, dumping LSASS yields encrypted blobs rather than usable hashes. It is not absolute; researchers have shown techniques to work around it, and it does not cover cleartext passwords typed at logon in every case. But it changes the economics. Faced with Credential Guard, attackers tend to abandon memory scraping and pivot to other approaches like abusing Kerberos tickets. Which is the honest picture. Memory forensics is not an oracle. It is an arms race, and both sides read the same research.

What to watch

The direction of travel is toward memory that is opaque even to the machine holding it. "Confidential computing," now offered by every major cloud provider, encrypts a virtual machine's RAM with a key the host hardware never exposes, so that even the cloud operator cannot read a tenant's memory. Consumer hardware is moving the same way, with more secrets pushed into isolated enclaves and dedicated security chips rather than general-purpose RAM. If that becomes the default, the cold boot attack loses its teeth and so, partly, does the forensic technique built on the same physics. The intruder's injected code still has to run somewhere, and that somewhere is still memory, but the analyst may increasingly find that the most interesting bytes are encrypted with a key locked inside silicon they cannot touch. The question the next decade will answer is whether memory stays the honest witness it has been since 2007, or whether both the attacker's secrets and the investigator's evidence disappear together into hardware neither of them can open. Watch which one the encryption protects.

Sources

1. J. Alex Halderman et al., Lest We Remember: Cold Boot Attacks on Encryption Keys, USENIX Security Symposium, 2008.
2. The Volatility Foundation, Volatility Timeline, accessed 2026.
3. The Volatility Foundation, The Volatility Framework, accessed 2026.
4. AAron Walters et al., Volatools: Integrating Volatile Memory Forensics into the Digital Investigation Process, BlackHat DC, 2007.
5. Michael Hale Ligh, Andrew Case, Jamie Levy, AAron Walters, The Art of Memory Forensics, Wiley, 2014.
6. The Volatility Foundation, Volatility 3 malfind plugin documentation, accessed 2026.
7. MITRE, ATT&CK Technique T1003.001: OS Credential Dumping: LSASS Memory, accessed 2026.
8. Microsoft Security Blog, Detecting reflective DLL loading with Windows Defender ATP, 2017.
9. Palo Alto Networks, Process Injection Explained: Techniques, Evasion, and Defense, accessed 2026.
10. Microsoft Learn, Credential Guard overview, accessed 2026.
11. A Comprehensive Quantification of Inconsistencies in Memory Dumps, arXiv preprint, 2025.
12. ThreatDown, Credential Dumping: How ransomware gangs steal login data and how to detect it, accessed 2026.