analyzing-memory-images

分析内存映像

某些工件只存在于内存中——注入的代码、解密后的载荷、凭据材料，以及已退出进程的网络连接。磁盘取证会漏掉所有这些内容。关键在于趁映像尚未丢失时获取它，然后按正确顺序提出恰当的问题。

适用场景

• 你有内存转储（原始格式、LiME、EWF、崩溃转储或 VM 快照）需要分析
• 正在调查遭到入侵的主机，需要查找仅存在于 RAM 中的工件
• 查找注入代码、进程空洞化或反射式 DLL 加载
• 提取凭据材料——哈希、Kerberos 票据、缓存凭据
• 从某一时刻的捕获中识别网络连接和侦听端口
• 检测内核级 Rootkit——SSDT 钩子、DKOM、隐藏驱动程序

不适用场景

• 更广泛的事件响应方法论——使用 responding-to-incidents
• 你获取的是磁盘映像，而不是 RAM 捕获——使用 analyzing-disk-images
• 实时/分流 Windows 主机的磁盘工件——使用 investigating-windows-endpoints
• 分析已知的磁盘恶意软件样本——使用 analyzing-malware
• 根据内存分析结果编写检测规则——使用 engineering-detections

获取

在实时系统上执行任何其他操作之前，先获取内存。你在主机上运行的每条命令都会改变内存中的内容。先制作映像，再进行分流。

# Linux — LiME (kernel module, minimal footprint)
sudo insmod lime-$(uname -r).ko "path=/evidence/mem.lime format=lime"
# Alternative: AVML (no kernel module needed, userspace)
sudo ./avml /evidence/mem.lime

# Windows — WinPMem (signed driver)
winpmem_mini_x64.exe mem.raw
# Alternative: DumpIt (single executable, click-to-run for non-technical staff)
DumpIt.exe /OUTPUT mem.raw /QUIET

# macOS — osxpmem is dead (Rekall archived, last release 2017, Intel-only, and
# blocked by SIP/kext restrictions on Big Sur+ and all Apple Silicon). Full-RAM
# capture on a modern Mac needs commercial tooling with Apple entitlements
# (e.g. Volexity Surge Collect); otherwise take process-scoped dumps and
# record that physical memory was not obtainable. See responding-to-incidents.

# VM snapshots — no agent needed
# VMware:   .vmem file alongside the .vmx (suspend the VM first for consistency)
# Hyper-V:  checkpoint creates .bin and .vsv in the snapshot directory
# KVM/QEMU: virsh dump <domain> mem.raw --memory-only
# VirtualBox: VBoxManage debugvm <name> dumpvmcore --filename mem.elf

# Crash dumps — partial but sometimes all you have
# Windows:  %SystemRoot%\MEMORY.DMP (complete dump), or minidumps
# Linux:    /var/crash/, kdump output, /proc/kcore (live, pseudo-file)

**获取后立即计算哈希。**记录 SHA-256、源主机、时间戳（UTC）、采集工具及版本，以及分析人员姓名。如果映像将用于法律或监管程序，从此时起就要维护保管链。

Volatility 3 工作流

先了解基本情况，再顺着证据调查。不要盲目运行所有插件——每个问题都有相应的插件可以解答。

初步了解

# Identify the OS profile and confirm the image is valid
vol -f mem.raw windows.info
vol -f mem.lime linux.bash
vol -f mem.raw banners.Banners    # fallback for unknown images

windows.info 会提供 OS 版本、内部版本号和内核基址。如果此插件运行失败，映像可能已损坏、格式不正确，或者需要自定义符号表。对于 Linux，你需要匹配的 ISF（中间符号格式）文件——根据确切内核版本的内核调试符号生成该文件。

进程分析

# Process listing — what was running
vol -f mem.raw windows.pslist     # walks the ActiveProcessLinks list
vol -f mem.raw windows.psscan     # scans for EPROCESS structures
                                          # (finds hidden/unlinked processes)
vol -f mem.raw windows.pstree     # parent-child relationships

# Compare pslist vs psscan: processes in psscan but not pslist were
# unlinked from the active list — this is DKOM or a terminated process
# that has not been fully cleaned up. Either is worth investigating.

进程列表中需要关注的内容：

• 父进程异常的进程（svchost.exe 的父进程不是 services.exe）
• 单实例进程存在多个实例（lsass.exe、csrss.exe）
• 名称拼写错误的进程（scvhost.exe、lssas.exe）
• 以 SYSTEM 身份运行的异常进程
• 创建时间集中在疑似遭到入侵时间段附近的进程

# DLL listing — what each process loaded
vol -f mem.raw windows.dlllist --pid <PID>
# Look for DLLs loaded from unusual paths (Temp, AppData, user-writable dirs)

# Handles — files, registry keys, mutexes, events
vol -f mem.raw windows.handles --pid <PID>
# Mutexes are especially useful: malware families often use characteristic
# mutex names to prevent re-infection

注入代码检测

内存分析的价值在此处得以体现。基于磁盘的取证无法看到从未写入文件的代码。

# VAD-based detection — finds memory regions with suspicious protections
vol -f mem.raw windows.malfind
# Reports regions that are:
#   - Committed, private memory with PAGE_EXECUTE_READWRITE
#   - Containing a PE header (MZ magic) in a region not backed by a file
#   - Tagged as VadS (private) rather than VadF (file-mapped)

# Dump suspicious regions for further analysis
vol -f mem.raw windows.malfind --dump --pid <PID>

解读 malfind 结果：

• 并非每个 RWX 区域都是恶意的——JIT 编译器（.NET CLR、Java、Chrome V8）也会正常分配可执行内存。请根据进程名称筛除这些情况。
• 未映射区域中存在 PE 标头（MZ + "This program"）属于高可信度证据。
• 分阶段载荷中常见不带 PE 标头的 Shellcode——请在区域开头查找 0xFC（cld 指令）、0x60（pushad），或 call + pop 序列。

空洞化进程检测：

# Compare on-disk PE headers with in-memory PE headers
vol -f mem.raw windows.pslist --dump   # dump process executables
# Then compare each dumped image against the on-disk original:
#   - Different PE header = process hollowing
#   - SizeOfImage mismatch = section unmapping/remapping
#   - Entry point outside the main module = hijacked execution

# Look for processes where the PEB ImageBaseAddress does not match the
# VAD entry for the main executable — a sign of hollowing or replacement

凭据提取

内存中包含磁盘取证无法恢复的凭据形式——明文密码（Windows 10 1607 之前版本中启用了 WDigest 时）、NTLM 哈希、Kerberos 票据和缓存的域凭据。

# SAM hashes (local accounts)
vol -f mem.raw windows.hashdump

# LSA secrets (service account passwords, auto-logon credentials, VPN)
vol -f mem.raw windows.lsadump

# Cached domain credentials (mscash2 format — crackable but slow)
vol -f mem.raw windows.cachedump

# For Kerberos tickets, dump lsass.exe memory and use mimikatz/pypykatz:
vol -f mem.raw windows.memmap --pid <lsass_pid> --dump
pypykatz lsa minidump <dumped_lsass_file>
# Yields: NTLM hashes, Kerberos TGTs and service tickets, WDigest
# plaintext (if enabled), DPAPI master keys

**每发现一项凭据，影响范围就会扩大。**每个哈希或票据都代表攻击者可能利用的一条横向移动路径。在 responding-to-incidents 期间进行范围界定时，应将这些信息纳入考虑。

网络工件

# Active and recently closed connections, listening ports
vol -f mem.raw windows.netscan
# Fields: protocol, local/remote address:port, state, PID, owner process

# DNS cache: Volatility 3 has no built-in Windows DNS-cache plugin. Recover
# resolved names from process memory instead, or use a third-party plugin.
vol -f mem.raw windows.memmap --pid <PID> --dump && strings -a pid.*.dmp | grep -iE '\.(com|net|org|ru|cn)\b'

# Linux equivalent
vol -f mem.lime linux.sockstat

需要关注的内容：

• 意外进程连接外部 IP（尤其是 svchost.exe、rundll32.exe、regsvr32.exe）
• 监听不常见端口号的端口——后门通常会绑定高位端口
• 来自 pslist 中已不再出现的进程的连接（已终止的 C2 通道只在内存中可见）
• 立即将远程 IP 与威胁情报源进行比对

命令历史记录和控制台输出

# Command-line arguments for every process
vol -f mem.raw windows.cmdline
# Reveals encoded PowerShell commands, lateral movement tool arguments,
# reconnaissance commands, and data staging operations

# Console input/output buffers (cmd.exe sessions)
vol -f mem.raw windows.consoles
# Can recover full command history and output even after the window is closed

# Linux shell history from memory (survives history -c)
vol -f mem.lime linux.bash

编码后的 PowerShell 很常见。解码 -EncodedCommand 参数：

echo "<base64_string>" | base64 -d | iconv -f UTF-16LE -t UTF-8

根据内存构建时间线

结合进程创建时间、网络连接和句柄时间戳，构建仅基于内存的时间线。这条时间线能够捕获从未触及磁盘的事件。

UTC Timestamp        | Artifact        | Detail                          | PID
2026-07-10 02:14:02  | Process create  | cmd.exe via explorer.exe        | 4812
2026-07-10 02:14:08  | Process create  | powershell.exe via cmd.exe      | 5104
2026-07-10 02:14:09  | Network conn    | 5104 -> 203.0.113.50:443 EST   | 5104
2026-07-10 02:14:15  | Process create  | rundll32.exe (no DLL in cmdline)| 6220
2026-07-10 02:14:15  | malfind hit     | RWX region with PE header       | 6220
2026-07-10 02:14:22  | Network conn    | 6220 -> 198.51.100.10:8443 EST | 6220

将其与 responding-to-incidents 中的磁盘和日志时间线合并，以填补缺口。内存能告诉你运行过什么；磁盘能告诉你保留了什么；日志能告诉你记录了什么。这三者单独来看都不完整。

Rootkit 检测

内核模式 Rootkit 会修改操作系统结构，以隐藏进程、文件、注册表项和网络连接。内存分析是主要的检测方法，因为 Rootkit 无法在原始内存映像中隐藏自己。

# SSDT hooking — System Service Descriptor Table
vol -f mem.raw windows.ssdt
# Entries pointing outside ntoskrnl.exe or win32k.sys are hooked

# Driver and module enumeration
vol -f mem.raw windows.driverscan    # scan for DRIVER_OBJECT
vol -f mem.raw windows.modules       # loaded kernel modules
vol -f mem.raw windows.modscan       # scan for unlinked modules
# Modules in modscan but not modules = hidden drivers

# Callbacks — rootkits register notify routines to intercept operations
vol -f mem.raw windows.callbacks

# IDT — Interrupt Descriptor Table modifications. Volatility 3 ships this for
# Linux only (linux.check_idt); there is no windows.idt. On Windows, IDT hooking
# is largely a pre-PatchGuard (x86) technique — check SSDT and callbacks above.
vol -f mem.lime linux.check_idt
# Handlers pointing to addresses outside known kernel modules are suspicious

DKOM（直接内核对象操纵）：

• 进程取消链接：从 ActiveProcessLinks 中移除 EPROCESS
• 通过比较 pslist（遍历列表）与 psscan（从内存中提取），即可检测
• 同样的原理也适用于线程、驱动程序和其他内核对象

Linux 专项分析

# Process listing
vol -f mem.lime linux.pslist
vol -f mem.lime linux.pstree
vol -f mem.lime linux.psaux         # with command-line arguments

# Shell history recovered from process memory
vol -f mem.lime linux.bash

# ELF binaries in memory — find injected shared objects
vol -f mem.lime linux.elfs

# Syscall table integrity — detect syscall hooking
vol -f mem.lime linux.check_syscall
# Entries not pointing to the expected kernel text range are hooked

# Loaded kernel modules and hidden modules
vol -f mem.lime linux.lsmod
vol -f mem.lime linux.hidden_modules

# Open files and network connections
vol -f mem.lime linux.lsof
vol -f mem.lime linux.sockstat

# Mounted filesystems and their types
vol -f mem.lime linux.mountinfo

**Linux 符号表：**与 Windows 不同，Linux 没有固定的内核结构。你必须提供与内核版本完全匹配的 ISF 文件。使用内核的调试符号（包含 DWARF 信息的 vmlinux）通过 dwarf2json 生成该文件。没有正确的符号，Volatility 将无法运行，或产生毫无意义的输出。

字符串和 YARA 扫描

当你不知道要找什么，或需要在整个映像中验证某个假设时，可以使用这些方法。

# YARA rules against the full image
vol -f mem.raw yarascan.YaraScan --yara-file rules.yar
# Scoping to a specific process:
vol -f mem.raw yarascan.YaraScan --yara-file rules.yar --pid <PID>

# Strings extraction — raw approach, still useful
strings -a -t d mem.raw > strings_ascii.txt
strings -a -t d -e l mem.raw > strings_unicode.txt
# Search for IPs, URLs, commands, known malware strings

# bulk_extractor — automated structured-data carving
bulk_extractor -o be_output mem.raw
# Produces: emails, URLs, credit card numbers, domain names, IP addresses,
# JSON/XML fragments, and other structured data, each in a separate file
# Use the histogram files (url_histogram.txt, domain_histogram.txt) first —
# stacking by frequency surfaces C2 domains and unusual patterns

**用于内存分析的 YARA 规则应不同于基于文件的规则。**磁盘上的打包或加密载荷会在内存中解密，因此应针对解包后的形式编写规则。还应针对只在运行时出现的字符串：互斥锁名称、C2 URL、API 解析字符串以及解密后的配置块。

应当摒弃的借口

• *“磁盘映像就够了。”*磁盘取证无法发现注入代码、仅驻留内存的载荷、解密后的配置，或从未写入磁盘的凭据。内存是不同的证据来源，并非冗余证据。
• *“内存转储太大，无法高效分析。”*从有针对性的插件开始——pslist、malfind、netscan、cmdline——而不是转储全部字符串。五个插件能回答的问题，比在 64 GB 原始数据中 grep 得到的更多。
• *“我们可以直接重新制作映像，然后继续。”*重新制作映像会毁掉易失性证据的唯一副本。如果你需要知道攻击者做了什么，就需要内存。
• *“malfind 标记了它，所以它就是恶意的。”*malfind 报告的是可疑的内存保护属性，并不能确认恶意软件。JIT 引擎、.NET 程序集和某些安全工具都会生成合法的 RWX 区域。每个命中结果都要验证。
• *“我们没有正确的 Volatility 配置文件。”*对于 Linux，可根据目标内核的调试符号构建 ISF。对于 Windows，Volatility 3 会自动检测大多数版本。配置文件不受支持是可以解决的问题，不是跳过内存分析的理由。
• *“系统已经重启，所以内存证据都没了。”*检查崩溃转储、休眠文件（hiberfil.sys）、页面文件（pagefile.sys）和 VM 快照。这些文件包含部分内存内容，而且常被忽略。
• *“字符串输出太嘈杂，没有用。”*使用 bulk_extractor 直方图、YARA 规则，或通过 grep 查找特定指标。原始字符串是最后的手段，而不是第一步。

参考资料

• responding-to-incidents — 更全面的事件响应方法和证据处理
• analyzing-malware — 对从内存中提取的样本进行深入分析
• engineering-detections — 根据在内存中发现的 TTP 编写规则
• hunting-threats — 使用内存分析中发现的指标主动搜寻威胁