In this module

IR1.5 Volatility 3 — Memory Forensics

90-120 minutes · Module 1 · Free

Operational Objective

The Invisibility Problem: fileless malware, process injection, reflective DLL loading, and in-memory-only implants leave no artifacts on disk. The attacker's Cobalt Strike beacon runs inside a legitimate svchost.exe process. No file was written. No registry key was modified. No Prefetch entry was created. No Amcache record exists. The endpoint forensic artifacts from IR3-IR5 show nothing suspicious because there is nothing on disk to find. The evidence exists only in memory — and Volatility 3 is the tool that finds it. Without memory forensics, the most common commercial attack tooling used in real intrusions is invisible to the investigator.

Deliverable: Volatility 3 installed with Python virtual environment, symbol tables configured, memory acquisition tools ready, validated against a test memory dump, and understood at operational depth — the investigation workflow for memory analysis, what each core plugin reveals, how to distinguish malicious findings from false positives, and how memory forensics integrates with disk-based evidence in a complete investigation.

⏱ Estimated completion: 25 minutes

Volatility 3 — Memory Forensics

The tool that sees what disk forensics cannot

The attacker used process injection. Their code is running inside a legitimate Windows process — no file on disk, no Prefetch entry, no AmCache record. Disk forensics sees a clean system. Memory forensics sees the injected code, the C2 connection, the stolen credentials, and the encryption keys. If your toolkit does not include memory analysis, you are blind to an entire category of attack. Volatility 3 is how you gain that visibility.

Memory forensics analyzes the contents of a system's RAM at a specific point in time. Where disk forensics examines persistent artifacts — files, registry hives, event logs — that survive a reboot, memory forensics examines volatile state: the information that exists only while the system is powered on and disappears permanently when the system shuts down.

# Step 1: Verify Python is installed (3.10+ recommended)
python --version
# If not installed: download from python.org
# During installation, CHECK "Add Python to PATH"

# Step 2: Create a dedicated directory and virtual environment
New-Item -ItemType Directory -Path "C:\IR\Tools\Volatility3" -Force
Set-Location "C:\IR\Tools\Volatility3"
python -m venv venv

# Step 3: Activate the virtual environment
.\venv\Scripts\Activate.ps1
# Prompt changes to (venv) indicating the virtual environment is active

# Step 4: Install Volatility 3
pip install volatility3
# This installs Volatility and all dependencies

# Step 5: Verify the installation
vol --help
# Expected: Volatility 3 Framework version and available commands
# The help output lists all available plugins organized by OS

# Alternative: install from GitHub source (for latest development version)
# git clone https://github.com/volatilityfoundation/volatility3.git
# cd volatility3
# pip install -e .

# Pre-download Windows symbol tables for offline analysis
# Download from: https://downloads.volatilityfoundation.org/volatility3/symbols/windows.zip
# Extract to the symbols directory:
# C:\IR\Tools\Volatility3\venv\Lib\site-packages\volatility3\symbols\

# Verify symbols are available
$symbolPath = "C:\IR\Tools\Volatility3\venv\Lib\site-packages\volatility3\symbols"
$winSymbols = Get-ChildItem $symbolPath -Recurse -Filter "*.json.xz" -ErrorAction SilentlyContinue
Write-Host "Symbol files available: $($winSymbols.Count)" -ForegroundColor $(if ($winSymbols.Count -gt 0) { 'Green' } else { 'Yellow' })
# The symbol pack is 200-400 MB and covers all Windows versions

# Download WinPMem from:
# https://github.com/Velocidex/WinPmem/releases
# Save to C:\IR\Tools\Volatility3\winpmem.exe
# Also copy to the jump bag USB (IR1.8)

# Capture memory from the local system (for testing/validation)
# Run as Administrator
Set-Location "C:\IR\Tools\Volatility3"
.\winpmem.exe "C:\IR\Evidence\TEST_memory.raw"

# Expected behavior:
# WinPMem loads a kernel driver to access physical memory
# Reads all physical RAM pages and writes to the output file
# Duration: 2-10 minutes depending on RAM size and disk speed
# Output size: equals physical RAM (16 GB RAM → 16 GB dump file)
# The dump file is a complete snapshot of RAM at capture time

# Activate the Volatility 3 environment
Set-Location "C:\IR\Tools\Volatility3"
.\venv\Scripts\Activate.ps1

# Identify the memory image
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.info.Info

# Output: OS version, kernel build, system time at capture
# This confirms the dump is valid and Volatility can parse it
# If symbols are needed, they download automatically at this step

# List all processes (equivalent to Task Manager but forensic-grade)
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.pslist.PsList
# Output: PID, PPID, ImageFileName, Offset, Threads, Handles, CreateTime, ExitTime
# Look for: unexpected process names, unusual parent-child relationships,
# processes running from temp directories, processes with exit times (terminated)

# Show the process tree — parent-child hierarchy
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.pstree.PsTree
# The tree view reveals suspicious hierarchies:
# explorer.exe → powershell.exe → cmd.exe (normal admin activity)
# outlook.exe → powershell.exe → cmd.exe (phishing payload execution)
# svchost.exe → cmd.exe (unusual — svchost rarely spawns cmd)

# Scan for hidden processes (rootkit detection)
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.psscan.PsScan
# PsScan searches memory for process structures rather than walking
# the kernel's process linked list. A process that appears in PsScan
# but NOT in PsList has been hidden (unlinked from the list) — this
# is a strong indicator of rootkit activity (T1014)

# Show command-line arguments for every process
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.cmdline.CmdLine
# Reveals the exact commands used to launch each process
# A powershell.exe with "-nop -w hidden -enc <base64>" is
# almost certainly attacker activity — legitimate PowerShell
# rarely uses encoded commands with hidden windows

# List all network connections with owning process
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.netscan.NetScan
# Output: Protocol, LocalAddr:Port, ForeignAddr:Port, State, PID, Owner
#
# Investigation workflow:
# 1. Find connections to unexpected external IPs
# 2. Map each suspicious connection to its owning process (PID)
# 3. Look up that PID in the PsList output
# 4. If the process is svchost.exe connecting to a VPS IP on
#    port 443 — that is likely a C2 channel
# 5. Check the process's parent in PsTree
# 6. Check the process's command line in CmdLine
# 7. Run Malfind against the process to check for injection

# Detect injected code in process memory
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.malfind.Malfind
# Malfind identifies memory regions with suspicious characteristics:
# - PAGE_EXECUTE_READWRITE protection (writable + executable)
# - Not backed by a legitimate file on disk
# - Contains executable code (identified by header bytes)
#
# Output: Process, PID, Start address, Protection, Hexdump
#
# Interpretation (critical — false positives are common):
# - Legitimate causes of RWX memory: .NET JIT compilation,
#   Java JIT, some AV products, GPU drivers, browser JIT
# - Suspicious indicators: MZ header (PE executable), shellcode
#   patterns (NOP sleds, API resolution stubs), large RWX regions
#   in system processes that should not have them
#
# On a clean system, Malfind typically produces 5-20 results,
# most of which are false positives from legitimate applications.
# On a compromised system, additional results from system
# processes (svchost.exe, rundll32.exe) with PE headers or
# shellcode patterns indicate injection.

# Dump the injected memory regions for further analysis
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.malfind.Malfind --dump -o "C:\IR\Output\malfind_dumps"
# The dumped regions can be scanned with YARA rules, submitted
# to VirusTotal, or analyzed with a disassembler to confirm
# whether they contain malicious code

# List all loaded DLLs for a specific suspicious process
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.dlllist.DllList --pid 4532
# Compare against known-good DLL lists for the process type
# An svchost.exe loading a DLL from C:\Users\Public\ is suspicious
# A legitimate svchost.exe loads only system DLLs from System32

# Check for discrepancies in module lists (detect injection)
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.ldrmodules.LdrModules --pid 4532
# LdrModules compares three different module lists maintained by Windows
# A module that appears in one list but not others may be injected
# Output columns: InInit, InLoad, InMem — if any is False for a
# non-system DLL, investigate further

# Extract password hashes from the SAM hive in memory
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.hashdump.Hashdump
# Output: Username:RID:LM_hash:NTLM_hash
# These are the same hashes the attacker would extract with Mimikatz
# If the attacker had access to LSASS, they obtained these credentials
# This informs the containment scope: every account with a recovered
# hash must have its password reset

# List registry hives in memory
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.registry.hivelist.HiveList
# Shows which registry hives were loaded at capture time
# Useful for identifying the SAM, SYSTEM, SOFTWARE hives for
# targeted registry analysis within the memory dump

# Scan process memory with YARA rules
# Requires: pip install yara-python

# Scan all processes for Cobalt Strike beacon signatures
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.yarascan.YaraScan --yara-rules "rule CobaltStrike { strings: $a = { 2e 2f 2e 2f 2e 2c } $b = \"beacon\" nocase condition: any of them }"

# Or use a YARA rule file (more practical for multiple signatures)
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.yarascan.YaraScan --yara-file "C:\IR\Tools\yara\cobalt_strike.yar"

# YARA scanning is the most targeted detection method:
# Malfind identifies suspicious memory regions generically
# YARA scanning matches specific malware signatures within those regions
# Combine both: Malfind for broad detection, YARA for specific identification

Expand for Deeper Context

Modern attacker tooling has made memory forensics essential rather than optional. The most widely used commercial penetration testing and red team frameworks — Cobalt Strike, Sliver, Brute Ratel C4, Havoc — operate primarily in memory. The standard attack pattern is reflective DLL injection (T1055.001): the attacker's implant is loaded directly into the memory space of a legitimate process (svchost.exe, rundll32.exe, explorer.exe) without writing a file to disk. The implant executes in memory, communicates with the attacker's command-and-control server, exfiltrates data, and provides remote access — all without creating any persistent disk artifact that KAPE, EZTools, or event log analysis would detect.

This is not theoretical. The majority of sophisticated intrusions investigated by professional IR firms in 2024-2025 involve memory-resident implants. Ransomware operators use Cobalt Strike beacons for initial access and lateral movement before deploying the encryption payload. APT groups use custom in-memory implants that persist only in RAM. Even commodity malware increasingly uses process injection to evade antivirus and endpoint detection.

The evidence that proves these attacks exists only in memory:

Running processes with their full command lines. The process list shows what was executing at the time of capture. PsList reveals the process hierarchy. PsTree shows parent-child relationships. CmdLine shows the exact arguments. A svchost.exe process with an unusual parent (PowerShell instead of services.exe) or unusual command-line arguments is immediately suspicious — but this information exists only in the live process state.

Active network connections with owning process. NetScan maps every network connection to the process that owns it. A svchost.exe process maintaining an outbound HTTPS connection to an IP address in an unexpected geography — that is the C2 channel. This mapping between process and connection exists only in memory. Disk-based network logs (if they exist) show the connection but often cannot attribute it to a specific process.

Injected code. Malfind identifies memory regions that have suspicious characteristics: memory pages marked as both writable and executable (PAGE_EXECUTE_READWRITE) that were not loaded from a legitimate file on disk. In a normal Windows process, executable code comes from DLLs loaded from disk — those memory pages are read-only and executable, not writable. When Malfind finds writable+executable memory that does not correspond to a legitimate DLL, it has likely found injected malicious code.

Encryption keys and credentials. LSASS (Local Security Authority Subsystem Service) holds cached credentials, Kerberos tickets, and NTLM hashes in memory. The attacker's tools (Mimikatz, Rubeus, pypykatz) extract these from LSASS memory. Volatility 3 can recover the same artifacts — meaning the investigator can determine what credentials the attacker obtained, which informs the scope of the compromise and the containment strategy.

Figure IR1.5a: Disk forensics and memory forensics are complementary, not alternatives. Disk analysis reveals persistent artifacts that survive reboot. Memory analysis reveals volatile state that exists only in RAM. Modern attackers deliberately operate in memory to evade disk-based detection — memory forensics is the only evidence source for these attacks.

---

Volatility 3: the framework

Volatility 3 is the most widely used open-source memory forensics framework. It was created by the Volatility Foundation and is maintained as a community-driven project with contributions from DFIR practitioners worldwide. Volatility 3 is a complete rewrite in Python 3 of the original Volatility Framework (Volatility 2, which used Python 2 and is now end-of-life). The rewrite brought significant improvements in speed, usability, and cross-platform support.

The most important improvement for investigators is the elimination of profiles. Volatility 2 required the investigator to manually identify the exact Windows version and service pack of the memory dump before analysis could begin — selecting from hundreds of profiles, with analysis failing silently if the wrong profile was chosen. Volatility 3 uses ISF (Intermediate Symbol Format) symbol tables that are automatically downloaded from Microsoft's symbol servers based on the memory dump's kernel version. The investigator runs the command; Volatility 3 identifies the OS version and fetches the correct symbols automatically. This removes the most common source of error in memory forensics.

Volatility 3 supports memory dumps from Windows (XP through Windows 11 and Server 2022), Linux, and macOS. It accepts multiple dump formats: raw dumps (.raw, .dd, .mem), Windows crash dumps (.dmp), hibernation files (hiberfil.sys), and EWF compressed images (.E01). The plugin architecture is extensible — the community publishes plugins for new analysis techniques, and investigators can write custom plugins for case-specific analysis.

---

Installation

Volatility 3 requires Python 3.8 or later (Python 3.10+ recommended). Install in a dedicated virtual environment to isolate Volatility's dependencies from the system Python and from other tools.

Symbol tables. Volatility 3 needs symbol tables (PDB files) to interpret the memory structures of the specific Windows build. On first use against a new OS version, Volatility 3 downloads the required symbols from Microsoft's symbol servers automatically. This requires an internet connection during the first analysis of each OS version. After download, symbols are cached locally and reused.

For air-gapped forensic workstations, pre-download the Windows symbol pack:

---

Memory acquisition: capturing the dump

Volatility 3 analyzes memory dumps — it does not capture them. A separate acquisition tool creates the dump file from a live system. Memory acquisition must happen before any containment action that might cause evidence loss (system restart, network isolation that terminates processes, or attacker detection that triggers anti-forensic wipes).

WinPMem — recommended free acquisition tool. Developed by the Velocidex team (the same team that builds Velociraptor). Creates raw memory dumps from live Windows systems. Portable — runs from USB without installation. Requires Administrator privileges because memory acquisition requires kernel-level access.

Alternative acquisition tools:

DumpIt — a single-click memory dumper. Double-click the executable, press Y to confirm, and it creates a dump in the same directory. Useful for non-technical onsite contacts — the simplest possible acquisition workflow.

Belkasoft RAM Capturer — free GUI-based acquisition tool. Provides a graphical interface that shows acquisition progress. Useful when handing the tool to someone who is uncomfortable with command-line tools.

Velociraptor — can trigger memory acquisition on a remote endpoint through the agent (using the Windows.Memory.Acquisition artifact). The dump uploads to the Velociraptor server. This combines remote acquisition with the Velociraptor workflow from IR1.4 — no physical access to the endpoint required.

Defender XDR Live Response — can collect a memory dump from a managed endpoint remotely using the run memorydump command in a Live Response session. The dump downloads through the Defender portal.

The critical rule: capture memory FIRST. Memory is the most volatile evidence source. Every second that passes after detection, memory is being overwritten — processes terminate, network connections close, the attacker may detect investigation activity and wipe their implant. The evidence collection priority from the jump bag checklist (IR1.8) places memory capture before all other collection: Memory → Network connections → KAPE triage → M365 audit export → Full disk image.

---

The investigation workflow: how to analyze a memory dump

Memory analysis in Volatility 3 follows a structured workflow. This is the workflow taught in IR6 and used in every Phase 4 scenario that involves memory evidence.

Step 1: Image identification. Confirm the dump is valid and identify the OS version.

Step 2: Process analysis — what was running.

Step 3: Network analysis — what was communicating.

Step 4: Malware detection — what was injected.

Step 5: DLL and module analysis — what was loaded.

Step 6: Credential extraction — what the attacker obtained.

Step 7: YARA scanning — hunting with signatures.

YARA rules for common attack tools (Cobalt Strike, Sliver, Metasploit, Mimikatz) are publicly available from threat intelligence sources. The Volatility Foundation, SANS, and various IR teams publish rule sets. Download these before the investigation — having YARA rules ready in the jump bag (IR1.8) means you can scan for known threats immediately upon acquiring a memory dump, rather than writing rules during the investigation.

---

The PsList vs PsScan rootkit detection technique

One of the most powerful techniques in memory forensics is comparing the output of PsList and PsScan. These two plugins retrieve process information using fundamentally different methods:

PsList walks the kernel's doubly-linked list of EPROCESS structures. This is the same list that Task Manager uses to display running processes. If an attacker hides a process by unlinking it from this list (a technique called DKOM — Direct Kernel Object Manipulation, T1014), PsList will not show it. The process still exists in memory and still executes, but it is invisible to the standard process enumeration.

PsScan searches memory byte-by-byte for EPROCESS structures by scanning for the characteristic header pattern. This method does not rely on the linked list — it finds every process structure in memory, including those that have been unlinked (hidden) and those that have terminated but whose memory has not yet been reclaimed.

The detection technique: run both plugins and compare. A process that appears in PsScan but not in PsList has been deliberately hidden — this is strong evidence of rootkit activity or advanced attacker tools that use DKOM for concealment. IR6 teaches this comparison technique with worked examples, including how to extract the hidden process for further analysis.

Worked investigation note — adapt for your IR reports:

Finding: Volatility 3 analysis of memory dump from DESKTOP-NGE042 identified PID 6248 (svchost.exe) present in PsScan output but absent from PsList output. The process was created at 2026-03-15 14:33:22 UTC with parent PID 892 (services.exe — expected for svchost). However, NetScan reveals PID 6248 maintains an established HTTPS connection to 203.0.113.47:443. Malfind identifies a 287,744-byte RWX memory region within PID 6248 containing an MZ header — consistent with a reflectively loaded PE executable. YARA scan matches the region against the CobaltStrike4_Beacon signature.

Proves: An injected Cobalt Strike beacon is running within svchost.exe (PID 6248), communicating with C2 infrastructure at 203.0.113.47:443. The process was hidden using DKOM, confirming deliberate concealment by the attacker. Does not prove: How the beacon was delivered, how long the C2 channel has been active, or what data has been exfiltrated through it. Next step: Extract the beacon configuration (sleep time, jitter, C2 URLs, watermark) using CobaltStrikeParser. Check the C2 IP against threat intelligence. Correlate the creation timestamp (14:33:22) with sign-in logs and email events to identify the initial access vector. Hunt across all endpoints with Velociraptor for the same C2 IP in active connections.

---

Alternative memory evidence: hibernation files and crash dumps

Memory evidence is not limited to live captures. Windows creates memory images in other contexts that Volatility 3 can analyze:

Hibernation file (hiberfil.sys). When Windows hibernates (or uses Fast Startup, the default on Windows 10/11), it writes RAM contents to C:\hiberfil.sys in compressed format. This file is a memory image that Volatility 3 can decompress and analyze. If the target system was hibernated or powered down with Fast Startup enabled, hiberfil.sys may contain memory evidence from the most recent session — including running processes, network connections, and injected code that were present at the time of hibernation. KAPE's !SANS_Triage target collects hiberfil.sys automatically.

Crash dumps (MEMORY.DMP). When Windows encounters a critical error (blue screen/BSOD), it writes a memory dump to C:\Windows\MEMORY.DMP (full dump) or C:\Windows\Minidump\ (mini dumps). Full crash dumps contain the same data as a live memory capture and can be analyzed with Volatility 3. If the attacker's activity caused a system crash (kernel exploit, driver manipulation, memory corruption), the crash dump contains evidence of what was in memory when the crash occurred — potentially capturing the attacker's tools in action.

Page file (pagefile.sys). The Windows page file contains memory pages that have been swapped to disk. While not a complete memory dump, it may contain fragments of process memory that include network connection artifacts, command strings, and injected code. Volatility 3 can analyze page files for partial evidence recovery when a live memory capture is not available.

These alternative sources mean that memory evidence may be recoverable even after the system has been rebooted or powered off — a fact that many investigators overlook. KAPE collects hiberfil.sys and pagefile.sys as part of its standard triage, providing memory evidence alongside disk artifacts without requiring a separate memory acquisition step.

---

Troubleshooting

"No suitable symbol table found." Volatility 3 needs to download symbols for the specific Windows build in the memory dump. Ensure the forensic workstation has internet access (or pre-download the symbol pack). Check the symbols directory path. For very new Windows builds, symbols may not yet be available — check the Volatility 3 GitHub issues for updates.

Analysis is extremely slow. Memory analysis is I/O intensive — Volatility reads the entire dump file for each plugin. Use an SSD, not a spinning disk. With 16 GB RAM analyzing a 16 GB dump, the system may swap heavily. 32 GB RAM on the forensic workstation is recommended for analyzing dumps from systems with 16+ GB RAM. Save plugin output to files (vol -f dump.raw windows.pslist > pslist.txt) to avoid re-running slow plugins.

Malfind produces many results on a clean system. This is expected. Modern Windows has many legitimate sources of RWX (read-write-execute) memory: .NET JIT compilation, Java JIT, Windows Defender's real-time scanning engine, GPU drivers, browser JavaScript engines. The investigator's job is not to flag everything Malfind reports — it is to compare the compromised system's results against a known-clean baseline and identify the additional entries. IR6 teaches this comparison technique in depth with worked examples.

"Module not found" for a specific plugin. Some Volatility 3 plugins require additional Python packages (e.g., yara-python for YARA scanning, pycryptodome for encrypted credential extraction). Install missing dependencies: pip install yara-python pycryptodome.

Compliance Myth

"Memory forensics is too advanced for most IR teams and should be left to specialists."

Production reality: Memory forensics is not advanced — it is essential. The perception that it is "advanced" stems from Volatility 2's profile complexity, which Volatility 3 eliminated. Running vol -f dump.raw windows.pslist is no more complex than running PECmd.exe -d prefetch --csv output. The difference is that memory forensics reveals evidence that disk forensics cannot — and without it, the most common commercial attack tooling (Cobalt Strike, Sliver, Brute Ratel) is invisible. An investigation that examines only disk artifacts will miss in-memory implants, miss the C2 connections, miss the injected code, and produce an incomplete conclusion. IR6 teaches memory forensics from first principles — you do not need prior experience. You need a memory dump and Volatility 3.

Compliance Myth

"If we have an EDR deployed, we do not need memory forensics."

Production reality: EDR products detect known attack patterns through behavioral rules and machine learning models. They are excellent at detecting known threats. But they can miss novel implants, customized Cobalt Strike configurations with sleep timers and jitter designed to evade detection, and living-off-the-land techniques that use legitimate Windows processes for malicious purposes. When the EDR does not fire an alert — or when the attacker disables the EDR agent (a documented technique for every major EDR product) — memory forensics provides visibility that is independent of the EDR's detection capability. The EDR sees what its rules are designed to see. Volatility 3 sees what is actually in memory.

Build it: Capture and analyze your first memory dump

Run WinPMem on your forensic workstation to capture a memory dump

Run WinPMem on your forensic workstation to capture a memory dump. Then execute the five-step investigation workflow: (1) windows.info to identify the image, (2) windows.pslist and windows.pstree to understand the process landscape, (3) windows.netscan to identify network connections, (4) windows.malfind to check for code injection, (5) windows.dlllist against your browser process to see its loaded DLLs. On your clean system, you will see legitimate processes, legitimate connections, and potentially some Malfind results from JIT compilation — all normal. The value of this exercise is establishing a baseline: when you analyze a compromised system's memory in IR6, you will recognize what is normal because you have seen it here.

Investigate: Map a process to its network connection

Open your browser and navigate to any website. Run windows.netscan against a fresh memory capture. Find your browser process's PID in the PsList output. Now find that same PID in the NetScan output — you will see the browser's active connections with destination IPs and ports. This is the same technique you will use in IR6 and IR13 to find an attacker's C2 connection: identify the suspicious process, find its PID, look up its network connections, and determine where it is communicating. On your clean system, the connections are to legitimate websites. On a compromised system, the same query reveals the attacker's infrastructure.

Beyond this investigation

The techniques taught in this subsection apply beyond the specific scenario presented here. The same evidence sources, tools, and analytical methods are used across ransomware, BEC, insider threat, and APT investigations — the context changes but the methodology is consistent.

Artifact Output

Volatility 3 operational at depth: You understand why memory forensics is essential for modern IR (fileless attacks, process injection, C2 channels). Volatility 3 is installed in a Python virtual environment with symbols configured. WinPMem is ready for memory acquisition. You have executed the five-step investigation workflow (image info → process analysis → network analysis → malware detection → credential extraction) and established a baseline understanding of clean-system memory. Volatility 3 is ready for deep memory forensics in IR6 and the ransomware (IR13) and APT (IR16) investigation scenarios where in-memory evidence is the critical differentiator.

Next objective → IR1.6 Cloud Investigation Tools — KQL, Purview, Defender XDR

Decision point

Volatility3 analysis of a memory dump shows a process named 'svchost.exe' running from C:\Users\Public\Downloads\. Legitimate svchost.exe runs from C:\Windows\System32\. Is this finding sufficient for the IR report?

It is a finding — but document it precisely. The finding: 'Process svchost.exe (PID XXXX) running from a non-standard path (C:\Users\Public\Downloads\ instead of C:\Windows\System32\). This is consistent with process name masquerading (T1036.005).' Do NOT state 'the attacker ran malware disguised as svchost' — that is interpretation beyond what the evidence shows. The process may be malware, a legitimate tool poorly named, or a testing artifact. The finding states what the evidence SHOWS; the analysis section interprets what it MEANS.

← Previous Next →