Opening Framing
Modern malware is designed to evade disk-based detection. Fileless malware executes entirely in memory. Sophisticated threats inject code into legitimate processes. Encryption keys exist only in RAM while data is accessible. The disk tells you what was installed—memory tells you what's actually running and what it's doing right now.
Memory forensics captures and analyzes the contents of RAM, revealing running processes, network connections, loaded modules, injected code, and decrypted data that would be invisible or encrypted on disk. When an attacker uses PowerShell to download and execute malware directly in memory, disk forensics finds nothing—but memory forensics catches everything.
This week covers memory acquisition techniques, the Volatility framework for analysis, process and network investigation, code injection detection, and credential extraction. You'll learn to investigate memory dumps from compromised systems to find what disk analysis misses.
Key insight: Memory is volatile—it disappears when power is lost. Capturing RAM must happen before shutdown, making it a critical first step in incident response.
1) Memory Acquisition
Before analysis, memory must be captured. Various tools and techniques exist for different scenarios:
Memory Acquisition Methods:
Live Acquisition (System Running):
┌─────────────────────────────────────────────────────────┐
│ Method │ Pros │ Cons │
├─────────────────┼─────────────────────┼─────────────────┤
│ Software tool │ Easy, remote capable│ Modifies memory │
│ Hardware (DMA) │ Minimal footprint │ Special hardware│
│ VM snapshot │ Perfect capture │ VMs only │
│ Crash dump │ Built-in │ Not complete │
│ Hibernation │ Already exists │ May be stale │
└─────────────────────────────────────────────────────────┘
Post-Mortem Sources:
- Hibernation file (hiberfil.sys)
- Crash dumps (MEMORY.DMP, minidumps)
- VM snapshots (.vmem, .vmsn)
- Cold boot attack (specialized)
Windows Memory Acquisition:
Windows Acquisition Tools:
WinPMEM (Recommended - Open Source):
> winpmem_mini_x64.exe output.raw
Options:
> winpmem_mini_x64.exe -o output.raw # Specify output
> winpmem_mini_x64.exe --format raw # Raw format
> winpmem_mini_x64.exe -l # Load driver only
DumpIt (Comae - Simple):
> DumpIt.exe
[Prompts for confirmation, creates dump in current directory]
Output: HOSTNAME-YYYYMMDD-HHMMSS.raw
Magnet RAM Capture (Free GUI):
- User-friendly interface
- Progress indication
- Automatic naming
FTK Imager (Free):
- File → Capture Memory
- GUI-based
- Also captures pagefile
Belkasoft RAM Capturer:
- Free, simple interface
- Minimal system footprint
Commercial Options:
- F-Response (enterprise, remote)
- Cyber Triage (automated triage)
- Magnet AXIOM
Best Practices:
1. Run from USB drive (minimize footprint)
2. Output to external drive (not target disk)
3. Hash the capture immediately
4. Document time, method, and tool version
Linux Memory Acquisition:
Linux Acquisition Tools:
LiME (Linux Memory Extractor):
# Compile for target kernel
$ cd LiME/src
$ make
# Load module and capture
$ sudo insmod lime-$(uname -r).ko "path=/tmp/memory.lime format=lime"
Formats:
- lime: LiME native (recommended)
- raw: Raw padded
- padded: Raw with zeros for gaps
AVML (Microsoft - Recommended):
$ sudo ./avml memory.lime
Advantages:
- No kernel module compilation
- Works across kernel versions
- Automatic compression option
/dev/mem and /dev/kmem (Legacy):
$ sudo dd if=/dev/mem of=memory.raw bs=1M
Note: Modern kernels restrict access (CONFIG_STRICT_DEVMEM)
/proc/kcore (Pseudo-file):
$ sudo dd if=/proc/kcore of=memory.raw bs=1M
Note: ELF format, requires conversion
fmem (Kernel Module):
$ sudo insmod fmem.ko
$ sudo dd if=/dev/fmem of=memory.raw bs=1M
Acquisition Considerations:
- Match tool to kernel version
- Test tools before incidents
- Capture to network share if possible
- Consider containerized environments
Virtual Machine Memory:
VM Memory Acquisition:
VMware:
- Suspend VM → creates .vmem file
- Snapshot → creates .vmsn + .vmem
- Location: Same directory as .vmx
$ ls /path/to/vm/
VM-Snapshot1.vmsn
VM-Snapshot1.vmem ← Memory file
VirtualBox:
- Snapshot creates state file
- Use VBoxManage debugvm
$ VBoxManage debugvm "VMName" dumpvmcore --filename memory.elf
Hyper-V:
- Checkpoint creates .bin file
- Or use live acquisition tools inside VM
Cloud Environments:
AWS:
- No direct memory access
- Use in-guest tools (SSM, custom AMI)
Azure:
- No direct memory access
- In-guest acquisition required
GCP:
- No direct memory access
- In-guest acquisition required
Memory Forensics in Cloud:
1. Deploy acquisition tool via automation
2. Stream to cloud storage
3. Analyze offline
4. Consider legal/compliance implications
Key insight: Memory acquisition changes memory (tool loads, runs). Accept this trade-off—the intelligence gained far outweighs the minimal contamination.
2) Volatility 3 Framework
Volatility is the premier open-source memory forensics framework. Version 3 is a complete rewrite with improved architecture:
Volatility 3 Basics:
Installation:
$ pip3 install volatility3
# Or clone from GitHub
$ git clone https://github.com/volatilityfoundation/volatility3.git
$ cd volatility3
$ pip3 install -r requirements.txt
Basic Usage:
$ vol -f memory.raw [plugin]
$ python3 vol.py -f memory.raw [plugin]
Getting Help:
$ vol -h # General help
$ vol -f memory.raw windows.info # OS info
$ vol [plugin] -h # Plugin-specific help
Key Differences from Volatility 2:
- No profile selection (auto-detection)
- Plugin naming: windows.pslist vs pslist
- Python 3 only
- Symbol tables downloaded automatically
- Faster analysis
Essential Plugins - Process Analysis:
Process Listing Plugins:
windows.pslist - Process List (EPROCESS):
$ vol -f memory.raw windows.pslist
PID PPID ImageFileName CreateTime
4 0 System 2024-03-15 09:00:00
424 4 smss.exe 2024-03-15 09:00:01
508 496 csrss.exe 2024-03-15 09:00:02
1234 508 suspicious.exe 2024-03-15 14:30:45
windows.pstree - Process Tree:
$ vol -f memory.raw windows.pstree
* 4 System
** 424 smss.exe
*** 508 csrss.exe
**** 1234 suspicious.exe ← Child of csrss? UNUSUAL!
windows.pslist vs windows.psscan:
- pslist: Walks active process list (attacker can unlink)
- psscan: Scans memory for EPROCESS structures (finds hidden)
$ vol -f memory.raw windows.psscan
[May find processes hidden from pslist]
Comparing Results:
- Process in psscan but not pslist = HIDDEN PROCESS
- Indicates rootkit or DKOM (Direct Kernel Object Manipulation)
windows.cmdline - Command Line Arguments:
$ vol -f memory.raw windows.cmdline
PID Process Args
1234 powershell.exe powershell.exe -enc JABjAGwAaQBlAG4AdA...
↑ Base64 encoded command - SUSPICIOUS
Network Analysis Plugins:
Network Connection Plugins:
windows.netscan - All Network Artifacts:
$ vol -f memory.raw windows.netscan
Offset Proto LocalAddr ForeignAddr State PID
0x1234 TCPv4 192.168.1.100:49234 10.0.0.50:443 ESTABLISHED 1234
0x5678 TCPv4 0.0.0.0:4444 0.0.0.0:0 LISTENING 5678
↑ Suspicious port!
Output Fields:
- Offset: Memory location
- Proto: TCP/UDP, IPv4/IPv6
- LocalAddr: Local IP:Port
- ForeignAddr: Remote IP:Port
- State: Connection state
- PID: Owning process
- Owner: Process name
Investigation Focus:
- ESTABLISHED connections to unknown IPs
- LISTENING on unusual ports (4444, 5555, etc.)
- Connections from unexpected processes
- High port numbers to low ports externally
Correlate with Process:
$ vol -f memory.raw windows.netscan | grep 1234
[Shows all connections for PID 1234]
$ vol -f memory.raw windows.pslist | grep 1234
[Shows process details for correlation]
DLL and Handle Analysis:
DLL Analysis:
windows.dlllist - Loaded DLLs:
$ vol -f memory.raw windows.dlllist --pid 1234
PID Process Base Size Name
1234 malware 0x00400000 0x5000 malware.exe
1234 malware 0x7FFE0000 0x1000 ntdll.dll
1234 malware 0x10000000 0x3000 evil.dll ← Unusual DLL?
Red Flags:
- DLLs loaded from temp directories
- DLLs with random names
- DLLs not in standard Windows paths
- Unsigned DLLs in signed processes
windows.ldrmodules - Detect Unlinked DLLs:
$ vol -f memory.raw windows.ldrmodules --pid 1234
Base InLoad InInit InMem Path
0x00400000 True True True \path\to\exe
0x10000000 False False True \temp\hidden.dll
↑ Not in load list = HIDDEN
Handle Analysis:
windows.handles - Open Handles:
$ vol -f memory.raw windows.handles --pid 1234
PID Handle Type Name
1234 0x4 Process
1234 0x10 File \Device\HarddiskVolume2\secret.txt
1234 0x18 Key \REGISTRY\USER\S-1-5-21...\SOFTWARE
1234 0x20 Mutant Global\EvilMutex
↑ Malware often creates mutexes
Key insight: Volatility's power comes from combining plugins. Process analysis leads to network analysis leads to DLL analysis—follow the evidence trail.
3) Code Injection Detection
Attackers inject malicious code into legitimate processes to evade detection. Memory forensics excels at finding this:
Code Injection Techniques:
Process Hollowing:
1. Create suspended legitimate process
2. Unmap original code
3. Map malicious code
4. Resume execution
Detection: Code doesn't match disk image
DLL Injection:
1. Allocate memory in target process
2. Write DLL path
3. Create remote thread calling LoadLibrary
Detection: Unexpected DLLs, remote threads
Reflective DLL Injection:
1. Allocate memory in target
2. Copy DLL manually (not via LoadLibrary)
3. Execute from memory
Detection: Executable memory not backed by file
Process Doppelgänging:
1. Create transaction
2. Overwrite legitimate file in transaction
3. Create process from transacted file
4. Rollback transaction
Detection: Process image doesn't match disk
Thread Execution Hijacking:
1. Open target thread
2. Suspend thread
3. Modify instruction pointer
4. Resume thread
Detection: Thread start address anomalies
Malfind Plugin:
windows.malfind - Detect Injected Code:
$ vol -f memory.raw windows.malfind
PID Process Start End Protection
1234 svchost.exe 0x10000000 0x10001000 PAGE_EXECUTE_READWRITE
Hexdump:
0x10000000 4d 5a 90 00 03 00 00 00 MZ......
↑ MZ header in non-image memory = INJECTED CODE
What Malfind Detects:
- Memory regions with execute permission
- That are NOT backed by a file on disk
- Containing potential code signatures
Protection Flags (Suspicious):
PAGE_EXECUTE_READWRITE (RWX) - Very suspicious
PAGE_EXECUTE_WRITECOPY - Suspicious
PAGE_EXECUTE_READ - Normal for code
Analysis Steps:
1. Run malfind to identify suspicious regions
2. Dump the memory region
3. Analyze with strings, YARA, or disassembler
Dumping Injected Code:
$ vol -f memory.raw windows.malfind --pid 1234 --dump-dir ./dumps/
[Creates files for each suspicious region]
$ strings dumps/pid.1234.vad.0x10000000.dmp
[Look for indicators]
$ yara -r malware_rules.yar dumps/
VAD Analysis:
Virtual Address Descriptor (VAD) Analysis:
windows.vadinfo - Memory Region Details:
$ vol -f memory.raw windows.vadinfo --pid 1234
Start End Tag Protection PageFile File
0x00400000 0x00410000 Vad PAGE_EXECUTE_READ Yes \path\exe
0x10000000 0x10010000 VadS PAGE_EXECUTE_RWX Yes (None)
↑ RWX + No File = SUSPICIOUS
VAD Tags:
- Vad: Normal allocation
- VadS: Short VAD (small allocation)
- VadF: File-backed VAD
- VadI: Image VAD
windows.vadwalk - Detailed VAD Tree:
$ vol -f memory.raw windows.vadwalk --pid 1234
windows.vadyarascan - YARA Scan VADs:
$ vol -f memory.raw windows.vadyarascan --pid 1234 --yara-rule malware.yar
Process Memory Dump:
windows.memmap - Full Process Memory:
$ vol -f memory.raw windows.memmap --pid 1234 --dump
[Creates full process memory dump for analysis]
Use Cases:
- Extract malware payload
- Recover decrypted data
- Find strings and indicators
- Reverse engineering
Thread Analysis:
Thread Investigation:
windows.thrdscan - All Threads:
$ vol -f memory.raw windows.thrdscan
ETHREAD PID TID Start Tag
0xFFFF8001234 1234 5678 0x7FFE1234 ....
0xFFFF8005678 1234 5679 0x10000000 ....
↑ Start in injected region!
Suspicious Thread Indicators:
- Start address in VAD with no file backing
- Start address in heap region
- Thread in legitimate process with unusual start
windows.threads - Thread Details:
$ vol -f memory.raw windows.threads --pid 1234
Cross-Reference:
1. Find suspicious start address
2. Check if address is in legitimate module
3. If not, likely injected code execution
Key insight: Legitimate code runs from file-backed memory regions. Executable code in non-file-backed regions is almost always injected.
4) Credential Extraction
Memory contains sensitive data including credentials, encryption keys, and decrypted content. Extracting these aids investigation and demonstrates impact:
Windows Credential Locations in Memory:
LSASS (Local Security Authority Subsystem):
- Process: lsass.exe
- Contains:
- NTLM hashes
- Kerberos tickets
- Cleartext passwords (WDigest)
- Domain cached credentials
SAM (Security Account Manager):
- User account hashes
- Can be extracted from memory
LSA Secrets:
- Service account credentials
- VPN passwords
- Cached domain credentials
Mimikatz Targets:
- WDigest: Cleartext passwords (older systems)
- Kerberos: Tickets for pass-the-ticket
- NTLM: Hashes for pass-the-hash
- DPAPI: Data Protection API keys
Volatility Credential Plugins:
Credential Extraction Plugins:
windows.hashdump - SAM Hashes:
$ vol -f memory.raw windows.hashdump
User RID LMHash NTHash
Administrator 500 aad3b435b51404eeaad3b435b51404ee 31d6cfe0d16ae931b73c59d7e0c089c0
Guest 501 aad3b435b51404eeaad3b435b51404ee 31d6cfe0d16ae931b73c59d7e0c089c0
user 1000 aad3b435b51404eeaad3b435b51404ee 8846f7eaee8fb117ad06bdd830b7586c
Crack hashes:
$ hashcat -m 1000 hashes.txt wordlist.txt
windows.lsadump - LSA Secrets:
$ vol -f memory.raw windows.lsadump
Secret Value
DefaultPassword P@ssw0rd123!
DPAPI_SYSTEM [hex blob]
NL$KM [cached domain key]
windows.cachedump - Domain Cached Creds:
$ vol -f memory.raw windows.cachedump
User Domain Hash
domainadmin CORP $DCC2$10240#domainadmin#[hash]
Mimikatz via Volatility:
# Not built-in, but can analyze lsass dump
$ vol -f memory.raw windows.memmap --pid [lsass_pid] --dump
# Then use mimikatz offline:
mimikatz # sekurlsa::minidump lsass.dmp
mimikatz # sekurlsa::logonpasswords
Other Sensitive Data:
Beyond Credentials:
Browser Data in Memory:
- Session cookies
- Form data
- Saved passwords (decrypted)
$ vol -f memory.raw windows.vadyarascan --yara-rules browser_strings.yar
Encryption Keys:
- BitLocker FVEK (Full Volume Encryption Key)
- TrueCrypt/VeraCrypt keys
- SSH private keys (if loaded)
- Application encryption keys
Clipboard Contents:
$ vol -f memory.raw windows.clipboard
[May contain copied passwords, sensitive data]
Command History:
- PowerShell commands
- CMD history
- May contain credentials in commands
$ vol -f memory.raw windows.cmdline
powershell.exe -User admin -Password Secret123
↑ Credential in command line!
Registry in Memory:
$ vol -f memory.raw windows.registry.hivelist
$ vol -f memory.raw windows.registry.printkey --key "SAM\Domains\Account\Users"
Ethical and Legal Considerations:
Credential Extraction Ethics:
Legitimate Uses:
- Incident response (determine compromise scope)
- Demonstrate impact to management
- Identify compromised accounts
- Evidence for legal proceedings
Requirements:
- Proper authorization
- Chain of custody documentation
- Secure handling of extracted credentials
- Need-to-know access
- Proper disposal after investigation
Do NOT:
- Extract credentials without authorization
- Use credentials for unauthorized access
- Share credentials outside investigation
- Retain credentials longer than needed
Documentation:
- Record what was extracted
- Document who had access
- Note when credentials were purged
- Include in final report (sanitized)
Key insight: Memory contains the keys to the kingdom. Handle extracted credentials with extreme care—they're evidence of compromise, not tools for further access.
5) Malware Analysis in Memory
Memory forensics reveals malware behavior that's invisible on disk—running processes, network connections, injected code, and decrypted payloads:
Memory Malware Analysis Workflow:
1. Initial Survey:
$ vol -f memory.raw windows.info # OS details
$ vol -f memory.raw windows.pslist # All processes
$ vol -f memory.raw windows.pstree # Process hierarchy
$ vol -f memory.raw windows.netscan # Network connections
2. Identify Suspicious Processes:
- Unknown process names
- Misspelled system processes (scvhost vs svchost)
- Wrong parent process
- Unusual paths (temp, user folders)
- Network connections to external IPs
3. Deep Dive on Suspicious Process:
$ vol -f memory.raw windows.cmdline --pid [sus_pid]
$ vol -f memory.raw windows.dlllist --pid [sus_pid]
$ vol -f memory.raw windows.handles --pid [sus_pid]
$ vol -f memory.raw windows.malfind --pid [sus_pid]
4. Extract Artifacts:
$ vol -f memory.raw windows.dumpfiles --pid [sus_pid]
$ vol -f memory.raw windows.malfind --pid [sus_pid] --dump-dir ./
5. Indicator Extraction:
$ strings dump.dmp | grep -E "http|https|\.exe|\.dll"
$ yara malware_rules.yar dump.dmp
Common Malware Indicators:
Process-Based Indicators:
Name Masquerading:
- svchost.exe not child of services.exe
- csrss.exe with wrong parent
- lsass.exe from wrong path
- Misspellings: scvhost, lssas, cssrs
Path Anomalies:
- System processes outside C:\Windows\System32
- Executables in temp folders
- Random paths like C:\ProgramData\[random]\
$ vol -f memory.raw windows.pslist
PID PPID Name Path
892 456 svchost.exe C:\Windows\Temp\svchost.exe ← WRONG PATH!
Timing Anomalies:
- System process starting after boot
- Recent start time during incident timeframe
Process Relationships:
- PowerShell spawned by Word/Excel
- cmd.exe spawned by browser
- Unusual service children
$ vol -f memory.raw windows.pstree
** 1234 WINWORD.EXE
*** 5678 cmd.exe ← Word spawning CMD? SUSPICIOUS!
**** 9012 powershell.exe ← And PowerShell!
Network Indicators:
Network-Based Detection:
$ vol -f memory.raw windows.netscan
Suspicious Patterns:
- Connections to non-standard ports (4444, 8080, etc.)
- Beaconing patterns (regular intervals)
- Connections from unexpected processes
- Multiple connections to same external IP
C2 Indicators:
- notepad.exe with network connections
- svchost.exe connecting to external IP
- Any process connecting to known bad IPs
$ vol -f memory.raw windows.netscan | grep -v "Microsoft\|Akamai\|Cloudflare"
[Filter common legitimate connections]
DNS Cache in Memory:
- May reveal resolved C2 domains
- Look for suspicious domain patterns
Listening Services:
Local:4444 LISTENING malware.exe ← Backdoor listener!
YARA Integration:
YARA Scanning in Memory:
windows.yarascan - Full Memory Scan:
$ vol -f memory.raw windows.yarascan --yara-rules malware.yar
YARA Rule Example:
rule Cobalt_Strike_Beacon {
strings:
$s1 = "beacon.dll" ascii
$s2 = "ReflectiveLoader" ascii
$s3 = { 4D 5A 90 00 03 00 00 00 }
condition:
any of them
}
Scanning Specific Process:
$ vol -f memory.raw windows.vadyarascan --pid 1234 --yara-rules rules.yar
Public YARA Rules:
- Yara-Rules Project (GitHub)
- Signature-Base (Neo23x0)
- CISA Malware Analysis Reports
- Vendor threat intelligence
Building Investigation Rules:
rule Suspicious_PowerShell {
strings:
$enc = "-enc" nocase
$bypass = "bypass" nocase
$download = "downloadstring" nocase
condition:
any of them
}
Key insight: Combine process analysis, network analysis, and code injection detection. Malware that hides in one dimension usually exposes itself in another.
Real-World Context
Case Study: Fileless Malware Attack
An organization's EDR detected suspicious PowerShell activity but found no malicious files on disk. Memory acquisition and analysis revealed: PowerShell process with base64-encoded command line downloading and executing code from a remote server. The malware established persistence through WMI subscription (also only visible in memory/WMI namespace). Network connections to C2 infrastructure were identified through netscan. The payload was extracted from memory using malfind and analyzed, revealing a commercial penetration testing framework used maliciously.
Case Study: APT with Process Injection
During incident response, analysts noticed unusual network traffic from svchost.exe. Disk forensics showed nothing unusual. Memory analysis revealed: malfind detected executable code in svchost.exe memory not backed by any file. VAD analysis showed PAGE_EXECUTE_READWRITE regions with MZ headers. Thread analysis found threads starting in injected regions. The injected code was dumped and identified as a nation-state backdoor. Process injection allowed the attacker to hide within a legitimate Windows process.
MITRE ATT&CK Alignment:
Memory Forensics Detects:
Execution:
- T1059.001: PowerShell → cmdline analysis
- T1106: Native API → Thread start addresses
Defense Evasion:
- T1055: Process Injection → malfind, VAD analysis
- T1055.001: DLL Injection → dlllist, ldrmodules
- T1055.012: Process Hollowing → malfind
- T1620: Reflective Code Loading → malfind
- T1027: Obfuscated Files → String/YARA analysis
Credential Access:
- T1003.001: LSASS Memory → hashdump, lsadump
- T1003.004: LSA Secrets → lsadump
- T1003.005: Cached Domain Creds → cachedump
Command and Control:
- T1071: Application Layer Protocol → netscan
- T1095: Non-Application Layer Protocol → netscan
Collection:
- T1115: Clipboard Data → clipboard plugin
- T1005: Data from Local System → Process memory
Memory forensics is often the only way to detect sophisticated attacks using fileless techniques and process injection.
Guided Lab: Memory Analysis Investigation
In this lab, you'll analyze a memory dump from a compromised Windows system to identify malware, extract indicators, and document the compromise.
Lab Environment:
- SIFT Workstation or Linux with Volatility 3
- Practice memory images (Memory Samples repository)
- YARA rules for malware detection
Exercise Steps:
- Identify the operating system with windows.info
- List all processes and identify suspicious entries
- Examine process tree for parent-child anomalies
- Analyze network connections for C2 indicators
- Run malfind to detect injected code
- Extract and analyze suspicious memory regions
- Document indicators of compromise (IOCs)
Reflection Questions:
- What evidence would you have found on disk alone?
- How did the attacker attempt to hide their activity?
- What IOCs can be used for detection across other systems?
Week Outcome Check
By the end of this week, you should be able to:
- Perform memory acquisition on Windows and Linux systems
- Navigate the Volatility 3 framework and plugins
- Analyze processes and identify suspicious entries
- Investigate network connections from memory
- Detect code injection using malfind and VAD analysis
- Extract credentials and sensitive data from memory
- Use YARA rules for malware detection in memory
- Correlate memory findings with disk and log evidence
🎯 Hands-On Labs (Free & Essential)
Practice memory analysis before moving to reading resources.
🎮 TryHackMe: Memory Forensics
What you'll do: Analyze memory dumps with Volatility and extract IOCs.
Why it matters: Memory reveals process activity and injected code.
Time estimate: 2-3 hours
📝 Lab Exercise: Volatility Triage Checklist
Task: Create a triage checklist for processes, network, and injected code.
Deliverable: Checklist with core Volatility commands and notes.
Why it matters: Triage ensures consistent, repeatable memory analysis.
Time estimate: 60-90 minutes
🏁 PicoCTF Practice: Forensics (Memory Artifacts)
What you'll do: Solve challenges involving hidden data and artifact extraction.
Why it matters: Memory findings often require careful artifact handling.
Time estimate: 1-2 hours
🛡️ Lab: Threat Hunting Hypothesis
What you'll do: Draft a hypothesis and identify memory artifacts to validate
it.
Deliverable: Hypothesis + data sources + validation steps.
Why it matters: Hunting turns raw forensics into proactive detection.
Time estimate: 60-90 minutes
💡 Lab Tip: Always capture memory before disk to avoid losing volatile evidence.
🛡️ Threat Hunting with Memory Evidence
Memory evidence enables high-confidence hunts. By starting from known attacker behaviors, you can test hypotheses quickly.
Hunt workflow:
- Define hypothesis (technique, target, time window)
- Identify memory artifacts that prove/disprove
- Validate with Volatility output
- Document false positives and gaps
📚 Building on CSY201: Hunting methods and hypothesis-driven investigations.
Resources
Lab
Complete the following lab exercises to practice memory forensics with Volatility 3. Use provided practice memory images or samples from the Volatility Foundation.