受入侵主机易失性证据采集实战：RFC 3227 顺序、内存转储与链式监管完整指南（Anthropic-Cybersecurity-Skills）

受入侵主机易失性证据采集实战：RFC 3227 顺序、内存转储与链式监管完整指南（Anthropic-Cybersecurity-Skills）

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读：本文围绕 Anthropic-Cybersecurity-Skills 仓库中的collecting-volatile-evidence-from-compromised-host技能展开，系统讲解在主机被入侵后、隔离与修复之前，如何按照 RFC 3227 定义的易失性顺序（order of volatility）采集内存、网络连接、运行进程与系统状态等关键证据，并以完整的采集报告模板、链式监管（chain of custody）文档与自动化脚本沉淀实战成果。读完本文，你将掌握从现场准备、七步采集工作流、证据哈希校验到报告与清单生成的端到端方法，能够直接用于无文件恶意软件调查、C2 会话取证、内鬼数据窃取与司法证据保全等场景。

一、技能概览：什么时候该用、需要准备什么

该技能位于 skills/collecting-volatile-evidence-from-compromised-host/SKILL.md，属于 incident-response（应急响应）子域，共映射到 5 条 MITRE ATT&CK 技术：T1059.001（PowerShell）、T1057（进程发现）、T1049（系统网络连接发现）、T1003.001（LSASS 凭据转储）、T1543.003（Windows 服务创建），以及 NIST CSF 2.0 的 RS.MA-01、RS.MA-02、RS.AN-03、RC.RP-01 四个控制项。

触发条件（When to Use）

• 安全事件已确认，且已定位到受入侵主机；
• 在系统隔离、关机或修复之前执行（易失性数据一旦关机即永久丢失）；
• 怀疑存在内存驻留恶意软件（无文件攻击、fileless attacks）；
• 需要捕获网络连接、运行进程和系统状态以支撑根因分析；
• 可能进入法律程序，需要保全可采信的取证证据；
• 事件调查需要依赖易失性数据进行根因分析。

前置条件（Prerequisites）

• 放在 USB 或网络共享上的取证采集工具包（可信工具，绝不能用受入侵系统上的工具）；
• WinPmem / LiME 用于内存获取；
• 写保护器或取证工作站用于磁盘镜像；
• 链式监管记录表格；
• 具备完整性校验能力的证据安全存储；
• 采集授权（内鬼案件需要法律/HR 批准）。

二、核心概念：按易失性顺序采集

技能定义了 7 个贯穿始终的关键概念：

RFC 3227 易失性顺序参照表

references/api-reference.md 给出了完整的优先级排序：

理解这张表是整场取证的灵魂：采集顺序一旦颠倒，最关键的证据可能在你还没动手时就消失了。这也是为什么内存采集必须排在最前面。

三、七步采集工作流：从现场准备到链式监管

Step 1：准备采集环境

# 挂载取证 USB 工具箱（绝不在受入侵系统上安装工具） # 校验工具箱完整性 sha256sum /mnt/forensic_usb/tools/* > /tmp/toolkit_hashes.txt diff /mnt/forensic_usb/tools/known_good_hashes.txt /tmp/toolkit_hashes.txt # 创建带时间戳的证据输出目录 EVIDENCE_DIR="/mnt/evidence/$(hostname)_$(date +%Y%m%d_%H%M%S)" mkdir -p "$EVIDENCE_DIR" echo "Collection started: $(date -u)" > "$EVIDENCE_DIR/collection_log.txt" echo "Collector: $(whoami)" >> "$EVIDENCE_DIR/collection_log.txt" echo "System: $(hostname)" >> "$EVIDENCE_DIR/collection_log.txt"

要点：先校验工具包的哈希与已知良好值是否一致，再建立带主机名和时间戳的证据目录，并把采集开始时间、采集人、主机名写入 collection_log.txt，为后续时间线和链式监管打底。

Step 2：采集系统内存（易失性最高，最先采集）

# Windows - WinPmem 内存获取 winpmem_mini_x64.exe "$EVIDENCE_DIR\memdump_$(hostname).raw" # Linux - LiME 内核模块获取内存 insmod /mnt/forensic_usb/lime.ko "path=$EVIDENCE_DIR/memdump_$(hostname).lime format=lime" # Linux - 备选方案：通过 /proc/kcore dd if=/proc/kcore of="$EVIDENCE_DIR/kcore_dump.raw" bs=1M # macOS - osxpmem osxpmem -o "$EVIDENCE_DIR/memdump_$(hostname).aff4" # 立即对内存转储做哈希 sha256sum "$EVIDENCE_DIR/memdump_"* > "$EVIDENCE_DIR/memory_hash.sha256"

内存转储是整场采集的最高优先级动作。无文件攻击的恶意脚本、内存驻留的后门、横向移动用的认证令牌都可能只存在于 RAM 中。注意工具必须从外部介质运行（LiME 通过insmod加载内核模块，WinPmem 直接执行 exe），采集完成后立即生成 SHA256 哈希。

Step 3：采集网络状态

# 活动网络连接 # Windows netstat -anob > "$EVIDENCE_DIR/netstat_connections.txt" 2>&1 Get-NetTCPConnection | Export-Csv "$EVIDENCE_DIR/tcp_connections.csv" -NoTypeInformation Get-NetUDPEndpoint | Export-Csv "$EVIDENCE_DIR/udp_endpoints.csv" -NoTypeInformation # Linux ss -tulnp > "$EVIDENCE_DIR/socket_stats.txt" netstat -anp > "$EVIDENCE_DIR/netstat_all.txt" 2>/dev/null cat /proc/net/tcp > "$EVIDENCE_DIR/proc_net_tcp.txt" cat /proc/net/udp > "$EVIDENCE_DIR/proc_net_udp.txt" # ARP 缓存 arp -a > "$EVIDENCE_DIR/arp_cache.txt" # 路由表 route print > "$EVIDENCE_DIR/routing_table.txt" # Windows ip route show > "$EVIDENCE_DIR/routing_table.txt" # Linux # DNS 缓存 ipconfig /displaydns > "$EVIDENCE_DIR/dns_cache.txt" # Windows # Linux: 因解析器而异，可查 systemd-resolve 或 nscd systemd-resolve --statistics > "$EVIDENCE_DIR/dns_stats.txt" 2>/dev/null # 活动防火墙规则 netsh advfirewall show allprofiles > "$EVIDENCE_DIR/firewall_rules.txt" # Windows iptables -L -n -v > "$EVIDENCE_DIR/iptables_rules.txt" # Linux

网络状态以秒到分钟为单位变化，是仅次于内存的高易失数据。netstat -anob中的-b参数能显示每个连接关联的进程，对识别 C2 通信进程至关重要；同时抓取/proc/net/tcp与/proc/net/udp作为底层原始数据，便于后续交叉验证。

Step 4：采集运行进程

# Windows - 详细进程列表 tasklist /V /FO CSV > "$EVIDENCE_DIR/process_list_verbose.csv" wmic process list full > "$EVIDENCE_DIR/wmic_process_full.txt" Get-Process | Select-Object Id,ProcessName,Path,StartTime,CPU,WorkingSet | Export-Csv "$EVIDENCE_DIR/ps_processes.csv" -NoTypeInformation # Windows - 带命令行和父进程的进程信息 wmic process get ProcessId,Name,CommandLine,ParentProcessId,ExecutablePath /FORMAT:CSV > \ "$EVIDENCE_DIR/process_commandlines.csv" # Linux - 完整进程树 ps auxwwf > "$EVIDENCE_DIR/process_tree.txt" ps -eo pid,ppid,user,args --forest > "$EVIDENCE_DIR/process_forest.txt" cat /proc/*/cmdline 2>/dev/null | tr '\0' ' ' > "$EVIDENCE_DIR/proc_cmdline_all.txt" # 进程加载的模块/DLL # Windows listdlls.exe -accepteula > "$EVIDENCE_DIR/loaded_dlls.txt" # Linux for pid in $(ls /proc/ | grep -E '^[0-9]+$'); do echo "=== PID $pid ===" >> "$EVIDENCE_DIR/proc_maps.txt" cat "/proc/$pid/maps" 2>/dev/null >> "$EVIDENCE_DIR/proc_maps.txt" done # 打开的文件句柄 handle.exe -accepteula > "$EVIDENCE_DIR/open_handles.txt" # Windows (Sysinternals) lsof > "$EVIDENCE_DIR/open_files.txt" # Linux

进程数据是判断恶意行为的核心证据：带命令行与父进程 ID（PPID）的进程列表能揭示进程注入与提权链条（例如 PowerShell 由 Word 或 Outlook 拉起的经典钓鱼/宏攻击链路），/proc/*/cmdline使用tr '\0' ' '将 NUL 分隔符转为空格以便阅读。

Step 5：采集登录用户与会话

# Windows query user > "$EVIDENCE_DIR/logged_in_users.txt" query session > "$EVIDENCE_DIR/active_sessions.txt" net session > "$EVIDENCE_DIR/net_sessions.txt" 2>&1 net use > "$EVIDENCE_DIR/mapped_drives.txt" 2>&1 # Linux who > "$EVIDENCE_DIR/who_output.txt" w > "$EVIDENCE_DIR/w_output.txt" last -50 > "$EVIDENCE_DIR/last_logins.txt" lastlog > "$EVIDENCE_DIR/lastlog.txt" cat /var/log/auth.log | tail -200 > "$EVIDENCE_DIR/recent_auth.txt" 2>/dev/null

w命令能同时显示登录用户及其来源 IP 和当前活动，配合net session/net use可掌握攻击者建立的外部会话与内鬼映射的网络驱动器——这些都是内鬼窃取数据场景的关键证据。

Step 6：采集系统配置状态

# 系统时间（对时间线构建至关重要） date -u > "$EVIDENCE_DIR/system_time_utc.txt" w32tm /query /status > "$EVIDENCE_DIR/ntp_status.txt" # Windows ntpq -p > "$EVIDENCE_DIR/ntp_status.txt" # Linux # 环境变量 set > "$EVIDENCE_DIR/environment_vars.txt" # Windows env > "$EVIDENCE_DIR/environment_vars.txt" # Linux # 计划任务 / Cron 任务 schtasks /query /fo CSV /v > "$EVIDENCE_DIR/scheduled_tasks.csv" # Windows crontab -l > "$EVIDENCE_DIR/crontab_current.txt" 2>/dev/null # Linux ls -la /etc/cron.* > "$EVIDENCE_DIR/cron_dirs.txt" 2>/dev/null # 服务 sc queryex type=service state=all > "$EVIDENCE_DIR/services_all.txt" # Windows systemctl list-units --type=service --all > "$EVIDENCE_DIR/systemd_services.txt" # Linux # Windows 注册表 - 关键自启动位置 reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" "$EVIDENCE_DIR/reg_run_hklm.reg" /y reg export "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" "$EVIDENCE_DIR/reg_run_hkcu.reg" /y reg export "HKLM\SYSTEM\CurrentControlSet\Services" "$EVIDENCE_DIR/reg_services.reg" /y

系统时间偏移（与 UTC 的差值）直接影响后续时间线分析的准确性，必须单独记录；计划任务、自启动注册表项和服务是恶意软件持久化（对应 ATT&CK T1543.003）的最常见载体，需要完整导出。

Step 7：为所有证据哈希并记录链式监管

# 为所有已采集证据生成 SHA256 哈希 cd "$EVIDENCE_DIR" sha256sum * > evidence_manifest.sha256 # 创建链式监管记录 cat > "$EVIDENCE_DIR/chain_of_custody.txt" << EOF CHAIN OF CUSTODY RECORD ======================== Case ID: IR-YYYY-NNN Collection Date: $(date -u) Collected By: $(whoami) System: $(hostname) System IP: $(hostname -I 2>/dev/null || ipconfig | grep IPv4) Collection Method: Live forensic collection via trusted USB toolkit Evidence Items: $(ls -la "$EVIDENCE_DIR/" | grep -v chain_of_custody) SHA256 Manifest: evidence_manifest.sha256 Transfer: [TO BE COMPLETED] Storage Location: [TO BE COMPLETED] EOF

采集的最后一步是完整性固化：对所有证据文件生成统一的 SHA256 清单，并生成链式监管记录，明确标注 Case ID、采集时间、采集人、主机、证据项列表、传输与存储位置（后两项留待后续填写）。

四、平台采集清单：Windows 与 Linux 对照

references/workflows.md 为两个平台提供了可直接打勾的采集清单：

Windows 采集清单

[ ] 内存: WinPmem/Magnet RAM Capture [ ] 进程: tasklist /V, wmic process, Get-Process [ ] 网络: netstat -anob, Get-NetTCPConnection [ ] 用户: query user, net session [ ] 注册表: Run keys, Services, Startup [ ] 服务: sc queryex, Get-Service [ ] 计划任务: schtasks /query [ ] DNS 缓存: ipconfig /displaydns [ ] ARP: arp -a [ ] 防火墙: netsh advfirewall [ ] 事件日志: wevtutil (Security, System, Application) [ ] Prefetch: %SystemRoot%\Prefetch\* [ ] 时间: w32tm /query /status

Linux 采集清单

[ ] 内存: LiME 内核模块或 /proc/kcore [ ] 进程: ps auxwwf, /proc/*/cmdline, /proc/*/maps [ ] 网络: ss -tulnp, /proc/net/tcp, /proc/net/udp [ ] 用户: who, w, last [ ] Cron: crontab -l, /etc/cron.* [ ] 服务: systemctl list-units [ ] DNS: systemd-resolve, /etc/resolv.conf [ ] ARP: ip neigh [ ] 防火墙: iptables -L -n -v, nftables [ ] 日志: /var/log/auth.log, /var/log/syslog [ ] 打开文件: lsof [ ] 时间: timedatectl [ ] 已加载模块: lsmod

五、采集报告模板：把现场证据固化成可审计的文档

技能自带的报告模板位于 skills/collecting-volatile-evidence-from-compromised-host/assets/template.md，是采集结束后将全部结果归档的标准文档骨架，包含以下核心区块：

5.1 案件信息（Case Information）

授权来源需明确填写（应急响应计划 / 法律保全 / HR 批准），内鬼案件中 HR 审批是合法采集的前提。

5.2 采集汇总（Collection Summary）

每类证据的状态要如实标注为 Collected / Failed / Skipped，失败的类别必须能在采集日志中找到原因。

5.3 证据清单（Evidence Manifest）

5.4 链式监管（Chain of Custody）

链式监管表记录证据从采集、转移、校验到分析访问的每一次流转，每个动作都要有人、有时间（UTC）、有备注。

5.5 系统时间校验（System Time Verification）

5.6 采集期间的重要发现（Notable Findings）

记录采集过程中发现的任何可疑进程、连接或痕迹（如隐藏进程、异常外连、可疑的自启动项）。

5.7 采集工具信息（Collection Tool Information）

每个工具都要记录版本、来源和哈希，以证明工具链的可信性。

5.8 采集人认证声明（Collector Certification）

我证明上述证据是使用符合取证规范的方法、通过外部可信工具采集的，所有证据均在采集完成后立即进行了哈希。

六、自动化采集：源码级实现与运行方式

技能自带两个可直接运行的 Python 脚本，将上述手工流程自动化。

6.1 跨平台采集器 process.py

skills/collecting-volatile-evidence-from-compromised-host/scripts/process.py 基于psutil实现了一个完整的EvidenceCollector类，按易失性顺序自动采集网络连接、ARP 表、DNS 缓存、路由表、运行进程、打开文件、登录用户、系统信息、服务、计划任务与环境变量，并对每个证据文件即时计算 SHA256、写入证据清单（evidence_manifest.json、sha256_manifest.txt）和采集日志（collection_log.json）。

用法：

pip install psutil python3 process.py --case-id IR-2026-001 --output-dir ./evidence_collection

关键设计点（均可从源码核实）：

• 输出目录自动按主机名_UTC时间戳命名（process.py 中__init__的output_dir拼接逻辑），避免覆盖历史采集；
• 采集开始时记录 case ID、主机、平台、采集人四条元信息到日志，天然形成链式监管的开端；
• _save_evidence/_save_evidence_csv在每次写入后立即计算 SHA256（_hash_file分块读取，每块 8192 字节），并登记文件名、类别、大小与采集时间；
• collect_network_connections通过psutil.net_connections(kind="all")关联每个连接的 PID 与进程名；collect_running_processes抓取 pid/ppid/用户名/命令行/可执行路径/创建时间/CPU/内存/线程数/连接数等 12 个字段；
• 平台差异在脚本内自动处理：ARP 在 Windows 用arp -a、Linux 用ip neigh；路由表用route print或ip route show；服务用sc queryex或systemctl list-units。

6.2 轻量采集代理 agent.py

skills/collecting-volatile-evidence-from-compromised-host/scripts/agent.py 是一个更轻量的命令行代理，通过VOLATILITY_ORDER常量硬编码了 10 级采集优先级（内存 → 网络连接 → 运行进程 → 打开文件 → 网络配置 → 路由表 → ARP 缓存 → DNS 缓存 → 登录用户 → 计划任务），每个来源同时给出 Linux 与 Windows 的工具命令：

VOLATILITY_ORDER = [ {"priority": 1, "source": "memory", "description": "Physical memory (RAM) dump", "tool_linux": "avml", "tool_windows": "winpmem_mini_x64.exe"}, {"priority": 2, "source": "network_connections", "description": "Active network connections", "tool_linux": "ss -tunap", "tool_windows": "netstat -anob"}, ... ]

运行方式（默认输出到~/volatile_evidence_时间戳，也可传参数指定目录）：

python3 agent.py /mnt/evidence/output_dir

其设计要点：内存采集在代理中默认标记为skipped并在清单中注明"需要提权与专用工具"，避免误用；每个证据文件写入时带上采集时间戳、执行命令与退出码头注释；脚本结束时输出结构化 JSON 摘要（artifacts_collected数量）。注意两个脚本都只是自动化采集与记账，真正的内存转储仍须用 WinPmem/LiME 等专用工具手工完成——这也是process.py提供--skip-memory参数的原因。

七、证据完整性与链式监管的硬性要求

references/workflows.md 对完整性与监管提出了明确的操作协议：

哈希协议

1. 每个采集的文件在创建后立即哈希；
2. 最低使用 SHA256——法律案件优先 SHA512；
3. 哈希清单存于独立文件；
4. 任何转移前后都要校验哈希；
5. 哈希结果必须纳入链式监管文档。

校验命令：

# 哈希全部文件 sha256sum /evidence/*.txt > /evidence/checksums.sha256 # 之后校验 sha256sum -c /evidence/checksums.sha256

链式监管要求

1. 记录每份证据的采集人；
2. 记录精确的采集时间（UTC）；
3. 记录采集方法与工具版本；
4. 记录证据的任何转移；
5. 记录存储位置与访问控制；
6. 记录对副本（绝不对原件）执行的分析。

八、典型应用场景

1. 无文件恶意软件攻击：基于 PowerShell、磁盘上无文件的攻击。内存转储是关键证据，其中包含恶意脚本本体。
2. 活跃 C2 会话：攻击者保持实时连接。网络连接与进程数据可揭示 C2 基础设施。
3. 内鬼数据窃取：员工复制文件。进程列表、映射驱动器和网络连接可显示外传行为。
4. 被入侵的 Web 服务器：检测到 Web Shell。内存中可能还包含尚未写入磁盘的额外后门。
5. 横向移动进行中：攻击者在系统间移动。内存中的认证令牌与网络会话可揭示攻击范围。

九、必须规避的常见陷阱

1. 从受入侵系统磁盘上运行工具；
2. 忘记立即对证据做哈希；
3. 不记录系统时间与 UTC 的偏移；
4. 在受入侵系统上安装采集工具；
5. 在内存采集前重启系统；
6. 通过浏览文件系统改变了文件时间戳；
7. 未实时记录采集步骤；
8. 未经授权采集证据。

十、标准与框架依据

references/standards.md 列出了支撑本技能的行业标准体系：

• RFC 3227：定义数字证据易失性顺序（寄存器/缓存 → 路由表/ARP/进程表/内核统计/内存 → 临时文件系统 → 磁盘 → 远程日志 → 物理配置/拓扑 → 归档介质），核心原则是尽量减少数据改动、记录所有动作、使用可信工具；
• NIST SP 800-86：取证技术集成指南，强调通过规范采集保全数据完整性，过程分为 Collection / Examination / Analysis / Reporting；
• NIST SP 800-61 Rev.3：证据处理要求，对应 Respond 功能中的 RS.AN-03（通过分析确定事件范围）；
• ACPO 数字证据良好实践指南：原则一为"任何操作都不得改变设备数据"，原则三要求对证据应用的所有流程保留审计轨迹；
• ISO/IEC 27037：数字证据识别、收集、获取与保全指南，强调证据处理人员的胜任能力；
• SWGDE 计算机取证最佳实践：涵盖证据获取、检验与报告标准及质量保证要求。

在 MITRE ATT&CK 数据源视角下，本技能采集的证据类型可映射为：Process（DS0009，进程创建与命令行）、Network Traffic（DS0029，连接创建与流量）、File（DS0022，打开句柄与临时文件）、Windows Registry（DS0024，自启动项）、Logon Session（DS0028，活跃用户会话）、Module（DS0011，加载的 DLL/共享对象）。

十一、产出物清单

完成整套流程后，应交付以下证据产出物：

• 内存转储文件（.raw或.lime格式）及其 SHA256 哈希；
• 网络状态采集（连接、ARP、DNS、路由）；
• 带命令行与父进程的进程列表；
• 用户会话与认证数据；
• 系统配置快照；
• 含 SHA256 校验和的证据清单（evidence manifest）；
• 链式监管文档（chain of custody）。

这些产出物与 assets/template.md 报告模板配合使用，即可形成一份从现场采集到司法举证均可追溯的完整案件卷宗。需要特别强调的是：本技能描述的是对已授权环境的取证与应急响应流程，务必确认具备采集授权（IR 计划、法律保全或 HR 批准）后再执行。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills