Memory forensics: why RAM matters and what you can find
In short: Memory holds what a computer is doing right now, including evidence that never reaches the disk, such as fileless malware and active network connections. Investigators capture RAM with a trusted tool, hash the image and analyse it with frameworks such as Volatility to find processes, connections and injected code.
Why RAM matters
Disk forensics shows what was stored. Memory forensics shows what was running. Many modern attacks try to stay off the disk: a malicious PowerShell script can be downloaded and run directly in memory, or code can be injected into a legitimate process. Disk scans may find nothing, yet a memory image still holds the evidence.
RAM is also where decrypted data lives. If a laptop uses full-disk encryption, the keys sit in memory while it is unlocked. Passwords typed into apps, open chat windows and clipboard contents can appear too. This is why the order of volatility puts memory near the top of the list.
Capturing memory
Capture happens on a live system, so the tool itself will change a small part of memory. Choose a trusted, tested tool, run it from external media and write the image to external storage. Examples include WinPmem and DumpIt on Windows, and AVML or LiME on Linux. Many EDR platforms can also collect memory remotely.
- Record the time, tool name and version, and the system’s reported time.
- Hash the resulting image and enter it on the chain of custody.
- Also collect the page file and hibernation file from disk, which can hold pages swapped out of RAM.
- For virtual machines, a hypervisor snapshot can capture memory without running anything inside the guest.
What analysis looks like
Volatility 3 is the best-known open-source framework. It reads the image, works out the operating system structures and runs plugins that each answer one question. MemProcFS takes another approach and presents the memory image as a set of folders and files you can browse. Typical first questions in a lab might be run like this:
vol -f memdump.raw windows.info
vol -f memdump.raw windows.pslist
vol -f memdump.raw windows.pstree
vol -f memdump.raw windows.netscan
vol -f memdump.raw windows.cmdline
vol -f memdump.raw windows.malfindWhat you look for:
| Clue | Why it is suspicious |
|---|---|
| Odd parent-child process | Word starting PowerShell, or a system process with the wrong parent |
| Misspelt or misplaced process | A copy of a system program running from a user’s temp folder |
| Encoded command lines | Long Base64 strings passed to a script interpreter |
| Executable memory not backed by a file | A sign of injected code, flagged by tools such as malfind |
| Connections to unknown hosts | Possible command-and-control traffic |
Limits and good habits
Memory analysis is powerful but not magic. Results can be incomplete if the capture was interrupted, the image is from a new operating system build the tool does not yet understand, or malware has hidden structures. Findings like "possible injection" need confirming with other evidence, such as EDR telemetry, event logs and disk artefacts. Treat credentials found in memory with great care: they are sensitive data, and should be reported for resetting, not reused.
Tip: build skills by capturing the memory of your own lab virtual machine, running a harmless program you know about, and finding it with Volatility.
Real-world example: fileless malware on a finance PC
An EDR alert at a fictional accountancy firm flags PowerShell launching from a spreadsheet on a finance PC, but antivirus scans of the disk find nothing. The responder isolates the PC from the network through the EDR console, keeping it powered on, and captures memory with a trusted tool. Analysis with Volatility shows a PowerShell process holding a decoded script and a connection to an unknown server address. The team blocks the address at the firewall, searches other machines for the same behaviour, and rebuilds the PC. Without the memory capture, the firm would have had almost no evidence of what ran.
Practice
Why might memory forensics find malware that a disk scan misses?
Name two things you should do immediately after capturing a memory image.
Microsoft Word is shown as the parent of a PowerShell process. Why is that interesting?
Key takeaways
- RAM shows what was running, including evidence that never reaches disk.
- Capture memory early with a trusted tool and write to external storage.
- Volatility 3 and MemProcFS are widely used analysis frameworks.
- Look for odd process trees, encoded commands, injected code and unknown connections.
- Confirm memory findings with logs, EDR data and disk evidence.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.