SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-mem-forensics

re-mem-forensics

Data & analytics

View repository

Updated 10-15 21:34

About this skill

Memory forensics (Volatility 3)

When to use / when not to use

  • Use: when you have a .raw/.mem/.core memory dump for forensics (process list, network connections, injection detection, credential hashes); analysis of memory remnants of malicious samples; incident response investigation
  • Use: when forensics requires a traceable timeline (sequence of process/network/registry events, together with timeliner)
  • Don't use: when there is no dump yet—first acquire one according to [[re-memdump]] (dumping takes priority by default, see the "direct read vs dump" decision table in [[re-analyze/platform-tips]])
  • Don't use: for real-time interactive debugging (that is the job of [[re-gdb]] / [[re-x64dbg]]); for static analysis of file systems/registry (that is [[re-binary-core]] / host forensics tools)

Tool preparation

This skill only reads dump files and does not run samples; anything involving dynamic confirmation is forwarded to [[re-sandbox]] (the default-highest-priority principle of sandboxing, see [[re-analyze/platform-tips]]).

volatility3 —— the main workhorse for memory forensics (Python 3.8+)

  • All platforms: pip install volatility3(the command is vol); the official requirement is Python 3.8+(as stated in the README), and as actually tested in 2026, 2.28.0 can be installed on Python 3.14 and plugins load normally—first python3 --version to confirm; if the version does not match, use pyenv/venv to create a corresponding environment and then install
  • Windows/WSL: same pip approach as above (a Windows dump can be analyzed inside WSL, see the WSL branch in [[re-analyze/platform-tips]])
  • Verify: vol -h；vol -f dump.raw windows.info can output image information without reporting symbol errors
  • Symbol files (ISF):the acquisition mechanisms for Windows and Linux/macOS are completely different; do not conflate them
    • Windows: based on the target kernel PDB's GUID/age , look for the ISF under symbols/windows/ ;when not found, automatically download the PDB from the Microsoft symbol server and convert it to ISF—this is the only side that "can be automatically obtained online" (it fails if the network is restricted)
    • Linux / macOS: relies on the kernel banner for exact matching ISF (the banner is encoded inside the ISF;the file name does not matter). Acquisition routes: ① community prebuilt packages (ISF collections organized by distribution/architecture/kernel) ② build it yourself—dwarf2json（requires a kernel with debug symbols) or btf2json(using vmlinuz 's BTF + System.map，does not require a full debug kernel）
    • First run banners to get the kernel banner, then find or build the corresponding ISF according to the banner;isfinfo to view the recognized symbol tables; when the banner does not match, use -vvv to confirm
    • Offline/restricted environment:--offline + a preset symbol directory, otherwise plugins report MissingSymbol-type errors
  • Dependency additions: credential-type plugins (hashdump/lsadump/cachedump) require pycryptodome, and yarascan requires yara-python—as actually tested in 2026, when 2.28.0 lacks these two dependencies the corresponding plugins fail to load (vol --help they are simply missing from pip install pycryptodome yara-python ); after installing, retry with

7zip (optional, to extract .7z compressed dumps)

  • Linux: apt install p7zip-full / dnf install p7zip-plugins / pacman -S 7zip
  • macOS: brew install p7zip
  • Windows: install 7-Zip from the official website
  • Verify: 7z --help

Toolkit supplements (by platform)

  • For Windows dumps, it is recommended to also prepare Sysinternals (use procdump/DumpIt to acquire the dump, see the Windows branch of [[re-analyze/platform-tips]])
  • Deep extraction vol -f dump.raw windows.dumpfiles Analyze suspicious objects found using [[re-ghidra]] / [[re-ida]]

Procedure

Execute in order, archive each step's output (path + sha256 + timestamp, forensic requirements).

  1. Confirm dump source and architecture：

    file dump.raw          # 确认是内存转储（MEMORY_IMAGE 头 / crash dump），不是别的文件
vol -f dump.raw windows.info    # Windows 镜像信息；Linux/macOS 无 info 插件——直接跑对应平台插件验证（如 linux.pslist / mac.pslist，符号表就位才正常输出）
    • Choose the platform prefix based on the dump source: for Windows use windows.*, for macOS use mac.*, for Linux use linux.*; volatility3 automatically identifies the profile (simpler than vol2's manual profile selection), but the first run requires downloading the corresponding symbol files (see Tool Preparation)
    • Input formats: raw image (primary format), LiME (the lime layer is automatically identified), Windows crash dump (crash layer); VMware .vmem (vol's built-in vmware layer is automatically identified, can be used directly with -f); hibernation file (hiberfil.sys) has no built-in layer—first convert to raw or process with specialized tools
    • Process-level dumps (gcore in [[re-memdump]] is a single-process ELF core, not a full-machine image) cannot be parsed by Volatility—review with gdb/eu-stack (see [[re-memdump]] step 3); this skill only handles full-machine images

  2. Process list：

    vol -f dump.raw windows.pslist            # 常规进程列表（含 PID/PPID/时间戳）
vol -f dump.raw windows.psscan            # 池扫描，能发现已终止/隐藏进程
vol -f dump.raw windows.pstree            # 进程树，看父子关系异常（如 IE 生成了 cmd）
    • Note suspicious PIDs: parent process mismatch (browser spawning powershell), common whitelist process names/path anomalies (svchost.exe not in C:\Windows\System32）
    • For terminated processes use psscan, don't just trust pslist
    • Supplementary plugins:windows.cmdline to view process command lines (obfuscated powershell -enc arguments),windows.svcscan service list (abnormal services are often persistence),windows.sessions session and desktop attribution

  3. Network connections：

    vol -f dump.raw windows.netscan           # 网络连接/监听（TCP/UDP，含已关闭连接）
vol -f dump.raw windows.netstat           # 备用：通过流表/相关对象推断
    • Record: local/remote IP:port, owning process PID, connection state; abnormal outbound connections (high ports other than 53/80/443, overseas IPs) are C2 clues, add to the IOC list (links to [[re-ioc]])

  4. Injection/anomaly detection：

    vol -f dump.raw windows.dlllist -p <pid>  # 进程模块列表，看路径异常（%TEMP%、AD 区）
vol -f dump.raw windows.malfind           # 扫描隐藏/注入的可执行内存（MEM_COMMIT + PAGE_EXECUTE_READWRITE 等）
vol -f dump.raw windows.hollowprocesses   # 进程镂空检测（替代合法性）
    • After a malfind hit, --dump export the suspicious region (vol -f dump.raw windows.malfind --dump --pid <pid>), store the extracted object's sha256, then move to [[re-binary-core]] for deep static analysis
    • malfind has false positives (see Pitfall 3)—cross-confirm using dlllist paths and executable page permissions

  5. Credential clues and suspicious object extraction：

    vol -f dump.raw windows.registry.hashdump     # 本地账户 NT/LM 哈希（改自 SAM + SYSTEM hive、boot key）
vol -f dump.raw windows.registry.lsadump      # LSA secrets（SECURITY hive）
vol -f dump.raw windows.registry.cachedump    # 域缓存凭据 MS-CACHEv2（SECURITY hive 的 NL$KM 密钥）
# 旧写法 windows.hashdump / windows.lsadump / windows.cachedump 是弃用别名（v2.27 标记 2026-09-25 移除）
    • Credential sources must be recorded as two separate sets, don't uniformly write \"LSASS memory\": the above three plugins are all registry-hive derived(hashdump ← SAM + SYSTEM, lsadump/cachedump ← SECURITY)—the provenance in the report should be written as registry-hive-derived; extracting credentials from LSASS process memoryisanother path(process dump + corresponding tools), the two have different evidence sources
    • A hit is evidence of credential leakage, record source and timestamp; offline cracking is delegated to password tools such as hashcat/john, this skill does not crack
    • Extract suspicious objects:windows.dumpfiles(specified file) or malfind/pslist --dump（vol -f dump.raw windows.pslist --dump --pid <pid> export process memory); compute sha256 for each object and archive
    • File object pool scanning:vol -f dump.raw windows.filescan | grep -i <关键词> find deleted/suspicious file objects, after a hit windows.dumpfiles extract (with windows.svcscan/windows.amcache Cross-confirmation)
    • Direct YARA rule scan:vol -f dump.raw yarascan.YaraScan --yara-file <规则.yar> Scan kernel memory (for in-process VAD scanning use windows.vadyarascan.VadYaraScan --yara-file <规则.yar> --pid <pid>; both require yara-python) — apply [[re-ioc]] rules directly to the dump
    • Forensic timeline (if needed):vol -r csv -f dump.raw timeliner Generate an event timeline (timeliner is a top-level plugin, without the windows. prefix;-r/--renderer is a vol-level option, placed before the plugin name;-r csv is the CSV renderer), for reference by reports and [[re-ioc]]

Cross-domain federation

  • [[re-forensics]]: Step 2 of this gateway workflow — this skill is the memory forensics stage
  • [[re-memdump]]: Source of dump artifacts (default dump first, see [[re-analyze/platform-tips]]); this skill only analyzes, does not acquire
  • [[re-malware]]: The deep analysis path references this skill — after behavior analysis, check memory remnants (injection/memory payloads/credentials)
  • [[re-ti]]: Extracted hashes/domains/IPs are converted into intelligence queries; credentials and injected objects go into the [[re-ioc]] IOC list
  • [[re-ioc]]: Credential hashes, network connections, and suspicious objects are summarized into IOCs and report evidence sections
  • [[re-binary-core]]: Static deep dive on suspicious objects extracted by malfind/dumpfiles
  • Reference the [[re-analyze/platform-tips]] "direct read vs dump" decision table (default dump first) and the Linux memory dump extreme segment (vsyscall/vdso filtering)

Common pitfalls and traps

  • Symbol table mismatch → parsing is all wrong: Symptom —vol reports Missing Symbol / the parsed process list is obviously absurd (system processes missing, addresses all 0); Cause — volatility3 automatically selects a profile, butthe symbol table (ISF) must exactly match the target: Windows uses PDB GUID/age (can be automatically retrieved from the Microsoft symbol server when missing),Linux/macOS must match the kernel banner and there is no automatic retrieval— rely on community prebuilt packages or build your own with dwarf2json(requires a debug kernel)/btf2json(vmlinuz BTF + System.map); Countermeasure — first use banners to get the kernel banner; on the Windows side, when the network is available, just run windows.info to trigger the PDB download, and in restricted environments use --offline + a preconfigured symbol directory;on the Linux/macOS side, you must first find or build the corresponding ISF according to the banner, and when the banner does not match, switch versions or build, but do not repeatedly retry the same one
  • Incomplete dump (vsyscall segment contamination) → analysis bias: Symptom — malfind hits a large number of "injections" at 0xffffffffff6xxxxx addresses, or extracted objects are all aligned garbage; Cause — during dumping, [vsyscall]/[vdso]/[vvar]was not filtered according to maps (see the [[re-analyze/platform-tips]] Linux memory dump extreme segment), so garbage pages were mixed in; Countermeasure — filter the extreme segment during the dump acquisition stage; during analysis, skip 0xffffffffff6xxxxx by address range, and do not treat garbage pages as evidence
  • malfind false positives → false positives: Symptom —windows.malfind hits a large number of private executable pages, but dlllist shows no abnormal modules and the extracted objects cannot run; Cause — normal RWX pages from loaders/garbage collectors/JITs are also judged "abnormal"; malfind only looks at memory attributes, not execution semantics; Countermeasure — use the dlllist path, hollow detection, and actual decompilation of extracted objects ([[re-binary-core]]) for triple cross-confirmation before drawing a conclusion
  • Trusting only pslist misses terminated processes: Symptom — pslist is clean but network/file behavior points to a PID that has disappeared; Cause — the process has been terminated, and the regular list does not include it; Countermeasure — additionally run windows.psscan(pool scan to find residual objects); forensic requirements should be as complete as possible.
  • Forensic report lacks a timeline: Symptom — the report has only conclusions without event ordering ("when injection happened, when the outbound connection happened"); Cause — no timeline evidence was generated; Countermeasure — use vol -r csv -f dump.raw timeliner(top-level plugin, without the windows. prefix;-r/--renderer is a vol-level option, located before the plugin name) to generate a CSV timeline, archiving process/network/credential events by time, as the evidence section of the [[re-ioc]] report
  • In-memory function patch-type bypass → all regular plugins clean: Symptom — malfind/dlllist are all clean, but the sample's ETW/AMSI is clearly suppressed (missing logs/no response to scanning); Cause — the bypass is not injecting new code, but rewriting the function headers of already-loaded modules (e.g., the first 4 bytes of EtwEventWrite patched to ret 14、AmsiScanBuffer the first 3 bytes changed to return 0、send jumping at the start to anonymous private memory), producing no new executable pages and not changing page permissions, so malfind is unaware; Countermeasure — run the built-in windows.etwpatch(detects ETW patching techniques, included since vol3 2.28), or dump the in-memory module and compare the function header bytes against the original on-disk DLL
  • Sleep obfuscation → payload "disappears" from the dump: Symptom — the implant cannot be found in the dump (no injected pages, no dropped files), yet behavioral analysis confirms the C2 implant is running; Cause — Ekko/Foliage-type sleep obfuscation flips VAD permissions to PAGE_NOACCESS/PAGE_READWRITE during sleep and encrypts the contents, restoring execution only at the moment of waking; Countermeasure — use vadinfo to find sections with flipped permissions/NOACCESS, restore the encrypted pages during sleep using the rotating key, or combine with [[re-emulation]] to emulate execution at the wake point and capture the plaintext
  • BitLocker FVEK can be recovered from RAM (the main version lacks this plugin): Symptom — an encrypted disk image plus memory dump are obtained but there is no password, and data extraction stalls; Cause — the full volume encryption key (FVEK) remains in RAM while the system is running (not securely erased), but the main version of Volatility 3 has no built-in plugin; Countermeasure — use the community volatility3-bitlocker plugin, run windows.bitlocker.BitlockerFVEKScan（--tags FVEc Cngb) to extract the FVEK, then use dislocker -k to mount and decrypt; when the v3 plugin errors on old kernel structures, fall back to Volatility 2 + breppo/Volatility-BitLocker
  • Plugin list lacks credential/YARA-type entries: Symptom —vol --help does not contain windows.registry.hashdump/lsadump/cachedump or yarascan; Cause — missing pycryptodome / yara-python dependencies, and plugins that fail to load are silently skipped (observed with 2.28.0 in 2026 testing); Countermeasure —pip install pycryptodome yara-python then rerun vol --help to confirm the entries appear, then run the corresponding plugins
  • Running commands with old plugin names → command does not exist or is about to become invalid: Symptom — according to old materials, writing windows.hashdump runs but warns, or one day directly reports that the plugin cannot be found; Cause — volatility3's plugin paths are continuously being reorganized (registry-type plugins have been moved into windows.registry.*, old names are retained as deprecated aliases and marked with removal dates, e.g., windows.hashdump marked for removal on 2026-09-25); Countermeasure —use the current path(see step 3), and record the version used in the report; note the distinction between "source directorychanged" and "command-line invocation namechanged"—the two are not necessarily in sync (e.g., the malfind source code is under windows/malware/ , butthe call name is still windows.malfind）