breach-forensics

开展数据泄露调查取证

概述

确认发生个人数据泄露后，必须开展全面的取证调查，以确定泄露范围（哪些个人数据和数据主体受到影响）、攻击途径、未授权活动的时间线以及根本原因。调查结果将直接用于《第 33 条》规定的监管机构通知、《第 34 条》规定的数据主体告知，以及泄露事件后的整改计划。本技能提供完整的取证调查工作流程、证据处理程序和分析技术。

证据保全规程

黄金法则：先保全，再分析

确认发生泄露后，首要任务是在易失性证据被覆盖或销毁之前将其保全。必须按易失性从高到低的顺序收集证据：

1. CPU 寄存器和缓存——使用实时内存采集工具（Volatility、WinPmem、LiME）进行采集。
2. 内存（RAM）内容——对受影响系统进行完整内存转储。其中包含运行中的进程、网络连接、加密密钥和恶意软件痕迹，这些信息可能不会留存在磁盘上。
3. 网络连接和路由表——当前活动连接可能揭示命令与控制（C2）基础设施或正在进行的数据窃取活动。
4. 运行中的进程和服务——进程树、已加载的 DLL、打开的文件句柄和用户上下文。
5. 磁盘内容——对受影响系统的存储设备进行取证磁盘映像（逐位副本）。使用物理介质时应使用写保护设备。
6. 日志文件——系统日志、应用程序日志、安全日志、数据库审计日志。优先处理可能轮换或被覆盖的日志。
7. 网络流量捕获——从网络分接器、SPAN 端口或内联捕获点获取的数据包捕获（PCAP）。
8. 外部证据——云服务日志（AWS CloudTrail、Azure Activity Log）、SaaS 审计日志、第三方供应商日志。

取证映像采集

系统类型	工具	方法	哈希校验
Windows 服务	FTK Imager 4.7	将磁盘逐位映像写入外部写保护存储设备	SHA-256 + MD5 双重哈希
Linux 服务	dc3dd	使用 /dev/sda 作为源，将磁盘逐位复制到外部存储设备	SHA-256 哈希，并使用 dcfldd 验证
AWS EC2 实例	AWS CLI + EBS 快照	创建 EBS 快照，然后转换为取证映像	快照导出的 SHA-256
数据库	pg_dump（逻辑导出）+ 磁盘映像	逻辑导出用于数据分析 + 物理磁盘映像用于痕迹恢复	两种输出的 SHA-256
移动设备	Cellebrite UFED / GrayKey	在法律允许的情况下进行物理提取	提取包的 SHA-256
云存储（S3）	使用版本控制的 AWS CLI sync	下载所有对象版本，包括已删除的对象	清单的 SHA-256

证据保管链文档

必须使用正式的证据保管链记录，追踪每项证据从采集、分析到存储的全过程：

证据追踪字段

字段	描述
证据 ID	唯一标识符：SPG-BREACH-2026-003-EV-001
描述	db-prod-eu-west-01（PostgreSQL 主节点）的完整 RAM 转储
采集日期/时间	2026 年 3 月 13 日，15:47 UTC
采集人	Thomas Brenner，CISO，Stellar Payments Group
采集工具	WinPmem 4.0 — 内存采集
采集时的哈希	SHA-256：a3f8b2c1d9e...（完整哈希记录在证据日志中）
存储位置	取证证据库，A 楼，104 室，3 号保险柜，B 架
访问日志	记录所有证据访问情况，包括姓名、日期、时间和用途

证据保管链移交记录

移交编号	日期/时间	移交人	接收人	目的	哈希验证
1	13 March 2026, 16:00 UTC	Thomas Brenner（CISO）	Mandiant IR Analyst（Sarah Mitchell）	取证分析	是 — SHA-256 匹配
2	20 March 2026, 10:00 UTC	Sarah Mitchell（Mandiant）	Thomas Brenner（CISO）	分析后归还	是 — SHA-256 匹配

日志分析方法

工具选择与应用

Splunk Enterprise Security

• 用例：集中式日志关联、时间线重建、行为分析。
• 违规事件调查的关键搜索：
  • 身份验证事件：index=auth sourcetype=okta:log action=authentication.login | stats count by user, result, client.ipAddress, client.geographicalContext.country
  • 数据库查询：index=database sourcetype=postgresql:audit query_type=SELECT table IN (customers, transactions, accounts) | stats count, values(query_text) by user, source_ip
  • 数据外传：index=network sourcetype=pan:traffic dest_zone=untrust bytes_sent>50000000 | stats sum(bytes_sent) by src_ip, dest_ip, app

ELK Stack（Elasticsearch、Logstash、Kibana）

• 用例：大容量日志摄取、全文搜索、访问模式可视化。
• 违规事件调查的关键查询：
  • 异常访问时间：筛选个人数据系统索引中非工作时间（当地时间 07:00 之前或 20:00 之后）的时间戳。
  • 地理异常检测：按地理位置汇总身份验证来源 IP；标记 90 天基线中未出现过的国家/地区。
  • 流量异常：按用户和小时汇总数据访问事件；识别超过 30 天平均值 3 个标准差的峰值。

Wireshark / tshark

• 用例：对往返于遭入侵系统的网络流量进行数据包级分析。
• 违规事件调查的关键筛选器：
  • 识别数据外传：ip.src == 10.0.1.50 && tcp.dstport != 443 && frame.len > 1000（遭入侵主机发出的非 HTTPS 流量）
  • 识别 C2 通信：dns.qry.name contains ".onion" || dns.qry.name contains "dga"（指向可疑域名的 DNS 查询）
  • 重建数据传输：跟踪 TCP 流，从 PCAP 捕获文件中恢复传输的文件内容。

其他工具

工具	用途	应用
Volatility 3	内存取证	分析 RAM 转储，查找恶意软件、注入代码和凭证窃取行为
Autopsy / Sleuth Kit	磁盘取证	恢复已删除文件、分析文件系统时间线、提取痕迹
YARA	恶意软件识别	使用恶意软件特征规则扫描磁盘映像和内存转储
Plaso / log2timeline	创建超级时间线	根据多个证据来源创建统一时间线
Chainsaw	Windows 事件日志分析	使用 Sigma 检测规则快速初步分析 Windows EVTX 日志

范围确定流程

步骤 1：识别所有遭入侵系统

1. 从最初识别出的遭入侵系统入手，通过身份验证日志、网络连接日志和端点检测警报追踪横向移动。
2. 对于识别出的每个系统，通过与数据处理清单（Art. 30 记录）交叉比对，确定其是否存储、处理或传输个人数据。
3. 记录每个遭入侵系统的以下信息：主机名、IP 地址、功能、数据分类、存储的个人数据类别以及估计的数据主体数量。

第 2 步：确定访问的数据

1. 对于每个包含个人数据且遭到入侵的系统，分析访问日志，确定攻击者访问了哪些具体表、文件或记录。
2. 区分“系统遭到入侵”（攻击者能够访问系统）与“数据被访问”（攻击者实际查询或下载了个人数据）。
3. 遵循预防原则：如果日志不足以确定是否访问了特定数据，则假设遭到入侵的系统上的所有数据都可能已被访问。

第 3 步：确定数据外传情况

1. 分析网络流量日志，检查在入侵期间是否有数据从遭到入侵的系统传输到外部目的地。
2. 检查 DNS 日志，查找 DNS 隧道指标（子域名字符串异常长、向异常域名发出的查询量很大）。
3. 检查是否使用了加密通道（VPN、SSH、HTTPS）连接到组织批准的目的地列表中未包含的外部 IP。
4. 检查终端日志，查找传输前压缩、加密或暂存文件的证据。
5. 将调查结果报告为：“已确认数据外传”“未发现数据外传证据（附置信度）”或“无法排除数据外传”。

第 4 步：确定入侵时间线

1. 确定未经授权访问的最早证据（初始入侵日期）。
2. 确定攻击者活动的时间线——采取了哪些行动以及行动时间。
3. 确定入侵何时被发现。
4. 计算潜伏时间（从初始入侵到发现之间的时间）。
5. 记录因日志覆盖缺口而无法重建时间线的时段。

根因分析

将 5 Why 框架应用于数据泄露事件

示例：Stellar Payments Group 勒索软件事件

1. 为什么勒索软件会执行？ 攻击者使用数据库集群上具有管理权限的遭入侵服务帐户部署了勒索软件。
2. 为什么攻击者能获得遭入侵的服务帐户？ 服务帐户凭据来自一封鱼叉式钓鱼邮件。IT 运维工程师于 2026 年 3 月 10 日点击了该邮件，随后安装了窃取凭据的键盘记录器。
3. 为什么钓鱼邮件能够到达工程师？ 该邮件来自一个遭入侵的合法域名，且不含可检测到的恶意载荷（链接指向一个看似合法的登录页面），因此绕过了邮件网关。
4. 为什么服务帐户拥有数据库管理权限？ 该服务帐户最初于 2024 年为迁移项目创建，项目结束后却从未停用。由于服务帐户被排除在审查范围之外，其权限未纳入季度访问审查。
5. 为什么服务帐户被排除在访问审查之外？ 访问审查政策将范围定义为“用户帐户”，未明确涵盖服务帐户、机器帐户或 API 密钥。

根因：访问审查政策存在缺口——服务帐户被排除在定期访问认证之外，且已完成项目遗留的服务帐户仍保有过高权限。

调查报告结构

第 1 节：执行摘要

• 入侵类型和分类
• 未经授权活动的日期范围
• 受影响的数据主体和记录数量
• 根因（一句话）
• 当前状态（已遏制／仍在进行）
• 主要整改建议

第 2 节：调查范围与方法

• 调查目标
• 分析的证据来源
• 使用的工具和技术
• 调查团队成员及职责
• 调查活动时间线

第 3 节：调查发现

• 附有证据引用的详细入侵时间线
• 遭到入侵的系统及受影响的个人数据
• 攻击向量和技术（映射至 MITRE ATT&CK 框架）
• 数据外传评估
• 根因分析

第 4 节：影响评估

• 受影响的数据主体（数量和类别）
• 遭到泄露的个人数据（类别和敏感程度）
• 用于 Art. 33/34 通知目的的风险评估
• 监管风险评估

第 5 节：补救建议

• 立即采取的措施（已采取）
• 短期措施（30 天内）
• 中期措施（90 天内）
• 长期系统性改进

第 6 节：证据清单

• 所有已收集证据的完整清单
• 证据保管链记录
• 哈希验证日志
• 证据保留和处置计划