responding-to-incidents

响应安全事件

每起安全事件都由两个问题决定：攻击者深入到了什么程度，以及他们是否仍在系统中。其他一切——恶意软件、CVE、根本原因——都是辅助细节。按顺序回答这两个问题，后续响应便会随之展开。

适用场景

• 怀疑或确认主机、账户或云租户遭到入侵
• 分析磁盘镜像、内存捕获或日志集以获取取证证据
• 重建攻击者做了什么以及何时做的
• 确定影响范围并决定如何遏制
• 撰写事后复盘报告，或面向监管机构／客户的安全事件说明

不适用场景

• 深入分析已恢复的样本——使用 analyzing-malware
• 在没有已知安全事件的情况下主动搜索威胁——使用 hunting-threats
• 判断警报是否构成安全事件——使用 triaging-security-alerts；分诊确认真阳性后，才开始响应
• 构建本应发现该事件的检测机制——使用 engineering-detections
• 安全事件发生在 AWS（密钥暴露、CloudTrail/GuardDuty）——使用 investigating-aws-incidents；发生在 Microsoft 365 / Entra 中——使用 investigating-m365-entra
• 需要分析数据包捕获文件——使用 analyzing-network-traffic
• 不涉及安全问题的服务中断——这是安全事件响应技能

转向深度分析技能

特定证据类型有各自的处理技能。本技能负责确定范围和顺序；当某一种工件成为重点时，请使用以下技能。

工件／重点	技能
使用 Volatility 分析 RAM 捕获文件（注入代码、内存中的凭据、已终止进程的连接）	analyzing-memory-images
Microsoft 365 / Entra ID 遭到入侵：没有磁盘或内存证据，只有云日志（UAL、登录记录、OAuth 授权）	investigating-m365-entra
查明攻击者如何在 Linux 主机上维持持久化——系统性检查所有初始化路径	analyzing-linux-persistence

关键顺序

Preparation → Detection & Analysis → Containment → Eradication → Recovery → Lessons Learned
                      ↑__________________|
                    (re-scope after every new finding)

有两条规则经常被违反，也因此造成最大损失：

**先保全证据，再修复。**重启、重装镜像或“顺手清理一下”都会破坏内存、正在运行的进程状态和未刷新的日志。证据一旦消失，你就无法回答范围界定问题，也只能猜测是否已将攻击者清除。

**不要只遏制一部分。**部分遏制会让攻击者知道你已察觉，并给他们时间从你遗漏的部分重新获得访问权限。先确定范围，再一次性全面遏制——除非损害正在持续，此时应先制止损害，并接受相应的取舍。

证据采集

易失性顺序（RFC 3227 §2.1）——按从上到下的顺序采集：

registers, cache
routing table, arp cache, process table, kernel statistics, memory
temporary file systems            ← tmpfs, /dev/shm: staging lives here
disk
remote logging and monitoring data relevant to the system
physical configuration, network topology
archival media

请注意，RFC 将内存、进程表和网络状态归为同一层级，并未规定它们之间的先后顺序。现代实践对此作了进一步细化：应先捕获内存，因为用于枚举进程和套接字的命令会在主机上执行，扰动尚未捕获的内存。不要跳过临时文件系统这一层——/dev/shm 和 tmpfs 是常见的暂存位置，而它们会在某人不可避免地建议重启后消失。

# Memory first, always, on a live suspect host
# Linux
sudo ./avml mem.lime                 # or LiME
# Windows
DumpIt.exe /OUTPUT mem.raw           # or winpmem
# macOS — do NOT reach for osxpmem. Rekall is archived, its last release was
# 2017 and Intel-only, and its kext-based approach is blocked by SIP and
# kext restrictions on Big Sur and later, and on all Apple Silicon. Full-RAM
# capture on a modern Mac realistically needs commercial tooling with the
# required Apple entitlements (e.g. Volexity Surge Collect). If none is
# available, do not stall the response: take process-scoped dumps and a
# comprehensive live-triage collection instead, and record in the incident
# log that full physical memory was not obtainable and why.

# Volatile state before you touch the disk
ps auxwwf; ss -tunap; lsof -n; last -Faiw; w
netstat -anob                        # Windows
Get-NetTCPConnection | Where State -eq Established

# Disk: image, do not analyze in place
sudo dd if=/dev/sda bs=4M conv=noerror,sync status=progress | tee image.dd | sha256sum
sudo ewfacquire /dev/sda             # E01 with built-in hashing, preferred
# Mount read-only, always via a write blocker or loop with `ro`
sudo mount -o ro,noexec,noload,loop image.dd /mnt/evidence

**证据保管链不是事后补做的文书工作。**采集时请记录：

Evidence ID | Source host/serial | Collected by | UTC timestamp | Method/tool+version
SHA-256 at acquisition | SHA-256 at each transfer | Custodian at each handoff | Storage location

立即计算哈希值，每次复制后都进行验证，绝不要在原件上操作。如果该事件可能演变为诉讼或监管事项，应在采集前而非采集后联系法务。

初步采集

对于大多数安全事件，逐台主机创建完整磁盘镜像太慢。应先大规模定向采集，再仅对重要主机制作镜像。

# Windows: KAPE with the SANS triage target set
kape.exe --tsource C: --target !SANS_Triage --tdest E:\out --vhdx host01

# Linux/macOS: UAC or a scripted collection
./uac -p full /evidence/host01

# Cloud/EDR: pull the equivalent via API
# - EDR raw telemetry for the window ±7 days
# - Snapshot the volume before terminating any instance
aws ec2 create-snapshot --volume-id vol-xxx --description "IR-<case> preserve"

按问题分析制品

直接查看能够回答问题的制品，而不是处理所有内容。

问题	Windows	Linux	macOS
执行了什么？	Prefetch、Amcache、ShimCache、SRUM、Sysmon E1	auditd、shell 历史记录、/var/log/*、systemd 日志	ExecPolicy DB、/var/db/、统一日志
是否存在持久化？	Run 键、服务、计划任务、WMI 订阅、启动文件夹	cron、systemd 单元、.bashrc、ld.so.preload、init	LaunchAgents/Daemons、登录项、配置描述文件
是否发生横向移动？	4624 type 3/10、4648、4672、RDP 日志、SMB 共享	auth.log、wtmp、.ssh/authorized_keys、known_hosts	与 Linux 相同，另加 ARD 日志
是否访问凭据？	LSASS 句柄（Sysmon E10）、带有 procdump 的 4688	读取 /etc/shadow、ptrace、sshd 的内存	钥匙串访问日志
是否暂存/外传数据？	回收站、$MFT 时间戳、创建归档、USN 日志	find -newermt、大型临时文件、历史记录中的 tar/zip	同上
访问了哪些文件？	$MFT、$UsnJrnl、LNK、JumpLists、shellbags	atime（如果启用）、auditd	FSEvents
浏览器/下载情况？	历史记录数据库、Zone.Identifier ADS	浏览器配置文件数据库	隔离数据库（LSQuarantine）

# Memory analysis — where "are they still here" usually gets answered
vol -f mem.raw windows.pstree
vol -f mem.raw windows.malfind          # injected RWX regions
vol -f mem.raw windows.netscan
vol -f mem.raw windows.cmdline
vol -f mem.raw linux.bash               # recovered shell history

# Filesystem timeline
fls -r -m / image.dd > body.txt && mactime -b body.txt -d > timeline.csv
log2timeline.py --storage-file plaso.db image.dd && psort.py -o dynamic plaso.db > super.csv

云和身份事件

大多数现代入侵都是通过身份而非恶意软件实施的。不要只检查主机。

# AWS
aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=<user>
# Look for: CreateAccessKey, AttachUserPolicy, AssumeRole chains, ConsoleLogin
# without MFA, GetSecretValue, CreateTrail/StopLogging (anti-forensics)

# Azure / Entra ID
# SigninLogs: impossible travel, legacy auth, unfamiliar device
# AuditLogs: "Add service principal credentials", "Consent to application",
#            "Update conditional access policy", role assignments

# Google Workspace / GCP
# Admin audit: OAuth token grants, mail forwarding rules, delegation changes

攻击者创建的 OAuth 应用、服务主体凭据和邮件转发规则，是云事件中最容易漏掉的持久化方式。在根除过程中，务必明确枚举这些项目。

时间线重建

时间线是所有其他工作都要支撑的交付成果。

• 全程使用 UTC。 在数据导入时统一时间，并记录来源时区。
• 为每一行注明来源制品。 未注明来源的时间线无法辩护，也无法重新推导。
• 区分观察到的事实与推断。 “进程已创建（Sysmon E1）”是观察到的事实；“攻击者从这里转移”是推断。应以不同方式标记。
• 警惕时间戳篡改。 $MFT 的 $STANDARD_INFORMATION 时间戳很容易伪造；$FILE_NAME 则不容易。二者不一致本身就是一项发现。
• 确定最早的入侵证据，然后继续向前追查。 你找到的第一条线索几乎从来都不是最先发生的事件。

UTC Timestamp        | Host    | Event                                  | Source            | O/I
2026-07-12 03:14:02  | WEB01   | POST /upload.aspx 200, 1.2MB, IP x.x.x.x| IIS log           | O
2026-07-12 03:14:40  | WEB01   | w3wp.exe → cmd.exe → whoami            | Sysmon E1         | O
2026-07-12 03:15:05  | WEB01   | Initial access via upload vuln          | correlation       | I

范围界定

在回答以下问题之前不要遏制，否则你遏制的范围可能不正确：

1. 零号患者 — 第一台主机/第一个账户，以及初始访问途径
2. 攻击者可能获取的所有凭据 — 从受感染主机上缓存、输入、存储或可访问的任何凭据都应视为已失陷
3. 这些凭据接触过的所有主机 — 通过身份验证日志追踪横向移动，而不只是查看 EDR 告警
4. 持久化清单 — 按主机和身份分别明确列出
5. 数据暴露情况 — 哪些数据可访问、哪些已被访问、哪些已外传

范围会不断扩大。发现新主机时，应从第 2 步开始重新检查。

遏制与根除

# Contain without destroying evidence
# - Network-isolate via EDR rather than powering off (preserves memory)
# - Revoke sessions and tokens, not just passwords: OAuth grants, refresh
#   tokens, Kerberos TGTs, API keys, SSH keys
# - Disable rather than delete accounts, so the artifacts survive

# Eradication checklist, per compromised identity
#   password reset, MFA re-enrollment, session/token revocation, key rotation
# For AD-wide compromise: krbtgt reset twice, ~10h apart

如果攻击者曾获得 SYSTEM/root 权限，应重装系统，而不是尝试清理。对于一台你并未完全了解的主机，你无法证明植入物已被移除；一旦判断错误，整个调查就得重来。

恢复条件 — 在满足以下条件之前不要恢复：初始访问途径已关闭、已移除所有发现的持久化、已轮换凭据，并已针对观察到的 TTP 建立检测能力。恢复后的系统应在至少一个完整业务周期内以提高的敏感度进行监控。

应当拒绝的借口

• “现在就重装，之后再调查。” 重装意味着终止对该主机的调查。
• “只有一台主机发出警报，所以只影响了一台主机。” 警报反映的是检测覆盖情况，而非攻击者的活动范围。
• “我们重置了密码，账户就安全了。” 刷新令牌、应用密码和现有会话在密码重置后仍然有效。
• “EDR 本该检测到它。” 它并未检测到你现在正在调查的部分。应假设存在盲区，并使用独立的证据来源交叉印证。
• “AV 已经清理了。” AV 会删除文件，但不会清除持久化机制、凭据或第二个植入程序。
• “日志只保留了 7 天，所以我们无从得知。” 在报告中将此说明为范围界定方面的限制。不要把它默认为“第 7 天之前什么都没发生”。
• “等我们确定了再记录下来。” 同期记录就是证据。应明确记录不确定之处，而不是拖延。

交付内容

• 执行摘要 — 以通俗语言说明发生了什么、造成了什么影响以及当前状态
• 时间线 — 使用 UTC，注明来源，区分观察结果与推断
• 范围 — 涉及的主机、账户和数据，并说明纳入与排除各项的依据
• 根本原因 — 初始访问途径以及失效的控制措施
• 已采取的措施 — 遏制、根除和恢复措施，并注明时间戳
• 证据登记表 — 项目、哈希值和保管记录
• 缺口 — 无法确定的内容及其原因（日志保留期限、未部署 EDR 等）
• 建议 — 按优先级排序，每项均对应叙述中指出的具体失效问题

事后复盘应秉持无责原则：分析控制措施和流程的失效，而不是点击链接的人。将个人列为原因的事后复盘，只会让下次事件中的人保持沉默。

ATT&CK 覆盖范围

根据 secskills-core/ttp-index.json 生成——编辑该文件，然后运行 python3 scripts/sync_attack.py --write。在报告中引用前，请根据 当前 ATT&CK 版本重新核实 ID。

持久化（TA0003）

• T1098.001 其他云凭据 — 另请参阅 exploiting-cloud-platforms
• T1098.002 其他电子邮件委派权限

防御规避（TA0005）

• T1070 清除指标
• T1070.001 清除 Windows 事件日志 — 另请参阅 hunting-threats
• T1070.006 修改时间戳
• T1562 削弱防御 — 另请参阅 hunting-threats
• T1562.001 禁用或修改工具 — 另请参阅 hunting-threats

收集（TA0009）

• T1114 收集电子邮件

影响（TA0040）

• T1485 数据销毁
• T1486 加密数据以造成影响 — 另请参阅 analyzing-malware
• T1489 停止服务
• T1490 阻止系统恢复 — 另请参阅 hunting-threats

这些技术的检测内容：engineering-detections。主动搜索：hunting-threats。入侵后响应：responding-to-incidents。

参考资料

• analyzing-malware — 为范围界定和 IOCs 提供依据的样本分析
• hunting-threats — 根据此处发现的 TTPs 主动搜索
• engineering-detections — 填补此次事件暴露出的检测缺口
• NIST SP 800-61r3（事件处理）、SP 800-86（取证技术）、RFC 3227
• 将 Volatility 3、Plaso/log2timeline、KAPE、Velociraptor、TheHive 作为核心工具