This chapter covers memory forensics and volatile data acquisition, a critical skill for incident response and the CS0-003 exam. Memory forensics allows analysts to capture and analyze the state of a running system, revealing malware, rootkits, and evidence of compromise that would be lost on shutdown. Approximately 10-15% of exam questions touch on this area, focusing on acquisition order, tools, and analysis of key artifacts like processes, network connections, and registry hives.
Jump to a section
Memory forensics is like a crash scene investigator arriving at a car accident. The investigator cannot stop the flow of traffic (the running system) but must preserve the scene exactly as it is before any cars are towed away (data lost). The investigator photographs every detail, collects skid marks (memory artifacts), and interviews witnesses (processes) before the scene is cleared. Just as the investigator must work quickly because rain (volatility) will wash away tire marks and blood (data), the forensic analyst must capture volatile memory before the system is powered down or crashes. The investigator uses a kit: gloves (write-blocker), camera (acquisition tool), and evidence bags (storage). Similarly, the analyst uses tools like FTK Imager or LiME to capture RAM, then analyzes with Volatility to find malware, passwords, or network connections. If the investigator waits too long, critical evidence disappears—the same is true for memory: data like network connections, running processes, and encryption keys vanish when power is lost. The investigator's report (forensic analysis) must detail every step to be admissible in court, just as the analyst must maintain chain of custody and use verified tools to ensure evidence integrity.
What is Memory Forensics and Why Does It Exist?
Memory forensics is the process of capturing the contents of a computer's volatile memory (RAM) and analyzing it for forensic evidence. Unlike disk forensics, which examines persistent storage, memory forensics deals with data that disappears when the system is powered off. This includes running processes, open network connections, loaded kernel modules, encryption keys, and malware that exists only in memory (fileless malware). The primary reason for its existence is that many sophisticated attacks leave no trace on disk—they operate entirely in memory to evade traditional antivirus and forensic tools.
The Order of Volatility
The first principle of memory forensics is the Order of Volatility (OOV). The analyst must capture data from the most volatile to the least volatile to minimize data loss. The standard OOV is:
CPU registers and cache
Routing table, ARP cache, process table, kernel statistics
Memory (RAM)
Temporary file systems
Disk
Remote logging and monitoring data
For the CS0-003 exam, you must know that the first thing to capture is the contents of RAM, followed by network state and running processes. Never pull the plug on a compromised system—instead, perform a live acquisition.
Memory Acquisition Methods
Memory acquisition can be performed locally or remotely. Common tools include: - FTK Imager (Windows): GUI tool that creates a .mem file. It can also capture pagefile.sys. - WinPmem (Windows): Open-source kernel driver that dumps RAM. - LiME (Linux): Loadable kernel module that dumps RAM to a file or over the network. - Mac Memory Reader (macOS): Acquires memory on Intel-based Macs. - F-Response (cross-platform): Allows remote memory acquisition over iSCSI.
When capturing, ensure the tool does not alter the system state. Use write-blockers for disk, but memory acquisition inherently modifies some memory (e.g., the tool's driver loads into kernel space). Document this impact.
Memory Analysis with Volatility
Volatility is the de facto standard for memory analysis. It is an open-source Python framework that supports multiple memory images from different operating systems. Key commands include:
- volatility -f image.dump imageinfo — Determines the OS profile (e.g., Win7SP1x64).
- volatility -f image.dump --profile=Win7SP1x64 pslist — Lists running processes.
- volatility -f image.dump --profile=Win7SP1x64 netscan — Lists network connections (Windows 8+).
- volatility -f image.dump --profile=Win7SP1x64 malfind — Scans for hidden or injected code.
Key Artifacts in Memory
#### Processes - pslist: Shows processes from the kernel's process list. Malware can hide by unlinking from this list. - psscan: Uses pool tag scanning to find processes even if unlinked. Compare with pslist to detect hidden processes. - psxview: Cross-references multiple sources to detect rootkits.
#### Network Connections - netscan (Windows 8+): Lists TCP/UDP endpoints, including those from hidden processes. - sockets and sockscan (older Windows): Show listening sockets. - connections and comscan: Show established connections.
#### Kernel Objects and Drivers - modules: Lists loaded kernel modules (drivers). - modscan: Scans for hidden drivers. - devicetree: Shows device tree—useful for detecting rootkits that hook IRP.
#### Registry Hives
- hivelist: Lists registry hives in memory (e.g., SYSTEM, SAM, SECURITY).
- printkey: Dumps registry keys, e.g., volatility -f image.dump --profile=Win7SP1x64 printkey -K "Microsoft\Windows\CurrentVersion\Run".
- userassist: Tracks user activity via UserAssist keys.
#### Malware Indicators - malfind: Identifies memory regions with suspicious permissions (e.g., PAGE_EXECUTE_READWRITE) and potential shellcode. - apihooks: Detects API hooks (e.g., inline hooks in ntdll.dll). - ldrmodules: Detects DLL hiding by comparing loaded DLL lists.
Fileless Malware and Memory-Only Threats
Fileless malware resides only in memory. Examples include: - PowerShell scripts executed from the command line. - WMI persistence: WMI event subscriptions that run scripts. - Registry-only malware: Stored in registry run keys but never written to disk as a file.
Detection requires memory analysis because there is no disk artifact. Use cmdline to view command-line arguments, consoles to capture console input/output, and malfind for injected code.
Legal and Chain of Custody
Memory evidence is fragile. Document every step:
Use cryptographic hashes (MD5, SHA1, SHA256) of the captured image.
Store on write-protected media.
Use tools with known integrity (e.g., Volatility is court-tested).
Be prepared to testify about acquisition methodology.
Common Pitfalls
Pulling the plug: Destroys volatile evidence. Always perform live acquisition if possible.
Using untrusted tools: The acquisition tool itself could be compromised. Use trusted, verified binaries.
Insufficient RAM: Large systems (e.g., servers with 64GB RAM) require significant storage and time to capture.
Encrypted memory: Full disk encryption (e.g., BitLocker) encrypts the pagefile. Capture memory before the system is locked or hibernated.
Integration with Other Forensics
Memory forensics complements disk forensics. For example, a memory dump may reveal a process that has injected code; the corresponding disk image can be searched for the original executable. Similarly, network logs can corroborate connections found in memory. Always correlate multiple sources.
Identify the Incident and Preserve Volatile Data
Upon detecting a security incident, the first step is to preserve volatile data. This includes memory, network connections, and running processes. Do not shut down the system. Instead, initiate live acquisition. Document the system time, logged-in users, and active network connections using built-in tools (e.g., netstat -ano on Windows, ss -tulpn on Linux). This step is crucial because any delay increases the chance that evidence is lost due to normal system operation or attacker cleanup.
Acquire Memory Using a Trusted Tool
Use a forensic memory acquisition tool appropriate for the OS. On Windows, run FTK Imager (or WinPmem) as Administrator to create a .mem file. On Linux, load the LiME kernel module: insmod lime.ko path=/evidence/mem.dump format=raw. On macOS, use Mac Memory Reader. Ensure the output is written to a separate storage device to avoid overwriting evidence. Record the SHA256 hash of the output file immediately. The acquisition process itself modifies a small amount of memory (the tool's driver), so document this.
Capture Network State and Running Processes
Before the memory dump is analyzed, capture the current network state and process list. On Windows, use netstat -anob > network.txt and tasklist /v > processes.txt. On Linux, use ss -tulpn and ps aux. Also capture ARP cache (arp -a) and routing table (route print or netstat -r). These artifacts are volatile and may change during acquisition. Compare with memory analysis later to detect discrepancies (e.g., hidden processes).
Verify the Integrity of the Acquired Image
After acquisition, verify the integrity of the memory image by comparing its hash with the hash computed during acquisition. Use sha256sum or similar. If the hashes match, the image is intact. Store the image on write-protected media and maintain chain of custody documentation. This step is critical for admissibility in legal proceedings.
Analyze the Memory Image with Volatility
Use Volatility to analyze the memory dump. First, determine the OS profile with imageinfo. Then run pslist and psscan to identify processes, netscan for network connections, and malfind for injected code. Cross-reference results with the live capture to detect hidden processes. Document all findings with screenshots and timestamps. Look for indicators of compromise (IOCs) such as unusual process names, connections to known bad IPs, or suspicious memory regions.
In an enterprise environment, memory forensics is often used during incident response to investigate advanced persistent threats (APTs) and ransomware attacks. For example, a company detects unusual outbound network traffic from a server. The incident response team performs a live memory acquisition of the server using FTK Imager over a remote session (e.g., via RDP). The memory dump reveals a hidden process that is communicating with a command-and-control (C2) server. Analysis with Volatility's netscan shows the C2 IP, and malfind identifies injected shellcode. The team then uses the memory dump to extract the decryption key for ransomware that was active in memory but had not yet encrypted the disk.
Another scenario involves a user reporting a slow computer. The IT team suspects malware but antivirus shows nothing. A memory dump using WinPmem reveals a PowerShell script running from a registry key (fileless malware). The script is extracting credentials from memory and sending them to an external server. The memory analysis allows the team to identify the attacker's infrastructure and remediate without reinstalling the OS.
In a large-scale deployment, performance considerations include the time to acquire memory (e.g., 10-15 minutes for 16GB RAM over a 1Gbps link) and storage requirements (RAM dump is equal to the system's RAM size). Best practice is to have a dedicated forensic workstation with ample storage and a pre-configured acquisition toolkit. Misconfiguration, such as using an outdated version of Volatility or incorrect profile, can lead to missed evidence. For example, using a Windows 7 profile on a Windows 10 image will fail to parse correctly. Always verify the profile with imageinfo before analysis.
The CS0-003 exam tests memory forensics under Objective 3.3 (Given a scenario, perform forensic analysis). Specific sub-objectives include: - 3.3.1: Order of Volatility - 3.3.2: Memory acquisition tools and techniques - 3.3.3: Analysis of memory artifacts (processes, network connections, registry) - 3.3.4: Detecting rootkits and hidden processes
Common wrong answers: 1. "Always pull the plug first" – This is wrong because it destroys volatile evidence. The correct approach is live acquisition. 2. "Use dd to acquire memory" – dd is for disk, not memory. Memory requires specialized tools like LiME or WinPmem. 3. "Memory analysis can recover deleted files from disk" – No, memory analysis only captures what is in RAM. Deleted files are on disk. 4. "Volatility profiles are interchangeable" – Wrong; the profile must match the exact OS version and architecture.
Specific numbers and terms:
- The default pagefile size in Windows is 1.5 times RAM (but exam may ask about pagefile.sys in memory context).
- Volatility command imageinfo determines the profile.
- psxview is used to detect hidden processes.
- malfind looks for PAGE_EXECUTE_READWRITE memory regions.
Edge cases: - Memory acquisition on a system with full disk encryption: you must capture memory before the system locks (e.g., BitLocker PIN entry). - 32-bit vs 64-bit: profiles differ; a 64-bit OS requires a 64-bit profile. - Linux memory acquisition: LiME must be compiled for the specific kernel version.
Elimination strategy: For any question about volatile data, the answer that involves capturing RAM first is usually correct. If a question asks about detecting fileless malware, look for answers involving memory analysis (not disk).
The Order of Volatility dictates that RAM is captured before disk or network state.
Use trusted acquisition tools like FTK Imager (Windows) or LiME (Linux).
Volatility requires the correct OS profile; run imageinfo first.
pslist shows processes from kernel list; psscan finds hidden processes.
netscan lists network connections in Windows 8+ memory dumps.
malfind detects memory regions with PAGE_EXECUTE_READWRITE permissions.
Fileless malware leaves no disk artifact; must be detected in memory.
Always hash the memory image immediately after acquisition for integrity.
These come up on the exam all the time. Here's how to tell them apart.
Live Acquisition (e.g., FTK Imager, LiME)
Captures full RAM while system is running.
Minimal system impact; preserves network connections.
Requires trusted tool and administrative privileges.
Output is a raw or .mem file.
Allows analysis of live artifacts like encryption keys.
Crash Dump (e.g., Windows Blue Screen)
Captures only a partial memory dump on system crash.
System is halted; network connections are lost.
Automatically generated by OS; no special tool needed.
Output is a .dmp file (e.g., MEMORY.DMP).
Limited to debugging; not ideal for forensic analysis.
Mistake
Memory forensics is only useful for malware analysis.
Correct
Memory forensics also recovers encryption keys, passwords, network connections, registry data, and user activity. It is essential for any incident response.
Mistake
You can use any disk imaging tool to capture RAM.
Correct
Disk imaging tools like dd read from block devices, not from /dev/mem (which requires special permissions and is often disabled). Memory requires dedicated tools that interface with the kernel.
Mistake
Pulling the plug is the safest way to preserve evidence.
Correct
Pulling the plug destroys volatile memory and may cause data corruption. The correct procedure is to perform a live acquisition with a trusted tool.
Mistake
Memory analysis can recover all data that was ever in RAM.
Correct
Memory analysis captures a snapshot at a point in time. Data that was overwritten or paged out to disk is not recoverable from the RAM dump alone.
Mistake
Volatility can analyze any memory dump without configuration.
Correct
Volatility requires the correct OS profile. Using the wrong profile leads to errors or incorrect output. Always run imageinfo first.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Order of Volatility (OOV) is the sequence in which evidence should be collected based on how quickly it can be lost. The most volatile data (CPU registers, cache) is collected first, followed by memory, network state, and finally disk. It is important because volatile data disappears when the system is powered off or changes rapidly. Following the OOV ensures maximum evidence preservation. For the exam, remember that memory is acquired before disk.
LiME (Linux Memory Extractor) is the most common tool. It is a loadable kernel module that dumps RAM to a file or over the network. Usage: insmod lime.ko path=/tmp/mem.dump format=raw. Other tools include fmem (kernel module) and avml (Acquire Volatile Memory for Linux). Always compile the module for the exact kernel version.
Use Volatility's psscan to scan for process objects by pool tag, which can find processes unlinked from the active process list. Then compare with pslist. Also use psxview to cross-reference multiple sources (e.g., process list, thread list, session list). Discrepancies indicate hidden processes, often malware.
Fileless malware operates entirely in memory without writing files to disk. It may use PowerShell scripts, WMI, or registry run keys. Detection requires memory analysis: look for suspicious PowerShell processes with cmdline, injected code via malfind, or unusual network connections. Disk scans will miss it.
Yes. Encryption keys used by applications (e.g., BitLocker, TrueCrypt) reside in memory while the system is running. Tools like Volatility's memdump can extract process memory, and key finders (e.g., aeskeyfind) can locate AES keys. This is useful for decrypting drives or communications.
A raw memory dump is a bit-for-bit copy of RAM, typically with no header. Crash dumps (e.g., Windows .dmp files) contain metadata and may be compressed or include only certain pages. Volatility can analyze raw dumps directly; crash dumps may require conversion or specific plugins. Raw dumps are preferred for forensics.
Compute a cryptographic hash (SHA256) of the image immediately after acquisition, using a trusted tool. Store the image on write-protected media. Document the hash in the chain of custody. Before analysis, recompute the hash and compare. If they match, the image has not been tampered with.
You've just covered Memory Forensics and Volatile Data — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?