Skip to content
CSY204 Week 06 Intermediate

Practice memory analysis before moving to reading resources.

Security Operations

Track your progress through this week's content

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:

  1. Identify the operating system with windows.info
  2. List all processes and identify suspicious entries
  3. Examine process tree for parent-child anomalies
  4. Analyze network connections for C2 indicators
  5. Run malfind to detect injected code
  6. Extract and analyze suspicious memory regions
  7. 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

Start TryHackMe Memory Forensics →

📝 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

Start PicoCTF Forensics →

🛡️ 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.

Part 1: Process Analysis (LO4)

Using a provided memory image, run pslist, pstree, and psscan. Identify: (a) any hidden processes (in psscan but not pslist), (b) processes with suspicious names or paths, (c) unusual parent-child relationships, (d) processes with suspicious command lines.

Deliverable: Process analysis report with annotated suspicious findings and rationale for each flag.

Part 2: Network Connection Analysis (LO4, LO5)

Run netscan and identify: (a) all established connections with process attribution, (b) listening services on non-standard ports, (c) connections to external IP addresses, (d) processes with network activity that shouldn't have it.

Deliverable: Network connection table with suspicious connections highlighted and correlated to processes.

Part 3: Code Injection Detection (LO4)

Run malfind and vadinfo to detect injected code. For each suspicious memory region: (a) document the process and address, (b) note the protection flags, (c) dump the region, (d) analyze with strings to extract indicators.

Deliverable: Code injection analysis with dumped regions and extracted strings/indicators.

Part 4: Credential Extraction (LO4)

Extract credentials using hashdump, lsadump, and cachedump. Document: (a) all extracted hashes (sanitized in report), (b) any cleartext credentials found, (c) implications for the investigation.

Deliverable: Credential report (with hashes redacted) documenting what was extractable and security implications.

Part 5: IOC Development (LO4, LO8)

Based on your analysis, develop a complete IOC package: (a) process names and hashes, (b) network indicators (IPs, ports, domains), (c) file paths, (d) YARA rule for detecting the malware in memory, (e) recommendations for detection.

Deliverable: IOC package suitable for sharing with other analysts or feeding into detection tools.

Week 06 Quiz

Test your understanding of Memory Forensics, Volatility 3, and Process Injection.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz

Checkpoint Questions

  1. Why must memory acquisition occur before system shutdown, and what types of evidence would be lost if this step is skipped?
  2. Explain the difference between windows.pslist and windows.psscan. What does it mean if a process appears in psscan but not pslist?
  3. What does the windows.malfind plugin detect, and what characteristics make a memory region suspicious?
  4. Describe how an attacker might use process injection to evade detection, and how memory forensics reveals this technique.
  5. What credentials can potentially be extracted from Windows memory, and what are the ethical considerations for doing so?
  6. How would you correlate memory forensics findings with disk and log evidence to build a complete picture of a compromise?

Weekly Reflection

Memory forensics reveals what's actually happening on a system, not just what files exist. This week demonstrated how sophisticated attacks that leave no disk artifacts are fully visible in RAM— if captured in time.

Reflect on the following in 200-300 words:

A strong reflection addresses the volatile nature of memory evidence, the cat-and-mouse game between attackers and defenders, and the ethical handling of sensitive data found in memory.

Verified Resources & Videos

← Previous: Week 05 Next: Week 07 →