云环境入侵全链路取证分析与证据拼接

云环境入侵全链路取证分析与证据拼接

勒索软件、Web 应用、钓鱼邮件、供应链投毒、内网横向移动全链路分析已经覆盖了五种常见入侵场景。但随着企业大规模上云，一种全新的入侵路径正在成为主流——云环境入侵。

2026 年，全球数字取证市场预计将达到 182 亿美元，复合年增长率 12.2%，其中云取证是增长最快的细分领域。根据 SecuredIntel 的分析，当一家《财富》500 强公司遭受数据泄露时，攻击者的足迹很少只停留在单台服务器上——它们分布在三个云服务商、两个 SaaS 平台、容器化微服务和临时无服务器函数中，每个组件遵循不同的保留策略、加密标准和司法管辖区。这就是现代云取证面临的挑战。

根据 Sygnia 2025 年的云安全事件响应最佳实践指南，94% 的企业在迁移到云后报告了更强的安全性，但更强不等于不可攻破。云环境中的单一配置错误、暴露的 API 或被盗用的凭据，可能在仪表盘上出现第一条警报之前就被利用。

本文以云环境入侵为场景，串联多个取证维度的检查结果，深度分析如何从分散的证据中拼接出完整的攻击链。

0x01 云环境入侵的本质与威胁模型

1.1 云环境与传统环境的本质区别

传统数字取证基于物理硬件：调查人员可以直接访问服务器、硬盘、内存。但在云环境中，这种直接访问被虚拟化基础设施、共享责任模型和分布式数据存储所取代。

根据 Wiz 的云取证分析文章，云环境由以下组件构成，每个组件都是潜在的攻击面，且需要不同的安全措施：

组件攻击面取证特征
虚拟机（VM）操作系统漏洞、凭据泄露快照、内存转储、控制平面日志
容器镜像漏洞、配置错误Kubernetes 审计日志、容器运行时事件
Serverless 函数权限过大、事件注入调用日志、执行上下文、IAM 角色
VPC/网络安全组错误、ACL 配置VPC Flow Logs、NSG 流日志
IAM/身份凭据泄露、策略过宽控制平面审计日志、角色假设链
存储（S3/Blob）公开访问、加密缺失访问日志、策略变更日志
编排平台（K8s）RBAC 错误、容器逃逸Kubernetes 审计日志、etcd 快照

1.2 云环境入侵的攻击链模型

根据 SANS FOR509 课程框架和 Sygnia 的云 IR 方法论，云环境入侵通常遵循以下攻击链：

凭据获取 → 控制平面侦察 → 权限提升 → 横向移动 → 数据窃取/资源滥用 → 日志清理

与传统环境的关键区别：

阶段传统环境云环境
初始访问钓鱼、漏洞利用凭据泄露、配置错误、API 密钥暴露
侦察内网扫描、AD 枚举Describe*/List* API 调用
权限提升本地提权、令牌操纵IAM 策略修改、角色链假设
横向移动PsExec、WMI、RDP跨账户角色假设、跨服务访问
数据外泄网络连接、USBS3 下载、跨区域复制
日志清理wevtutil clCloudTrail 停用、日志删除

1.3 云环境入侵的取证来源总览

根据 Sherlock Forensics 和 SANS FOR509 的总结，云环境取证的核心数据源包括三大云平台的审计日志：

云平台主要日志源安全服务
AWSCloudTrail、VPC Flow Logs、S3 Access LogsGuardDuty、Security Hub、Detective
AzureActivity Logs、Sign-in Logs、NSG Flow LogsMicrosoft Defender、Sentinel
GCPAdmin Activity Logs、Data Access Logs、VPC Flow LogsSecurity Command Center、Chronicle

0x02 阶段一：凭据获取

攻击目标

获取云环境的初始访问凭据——AWS Access Key、Azure Service Principal、GCP Service Account Key 等。

取证来源

  • 0x02/浏览器相关检查：钓鱼网站访问记录
  • 0x02/系统日志检查：钓鱼邮件投递记录
  • 0x02/重点文件检查：配置文件中的凭据泄露

典型证据

场景 A：钓鱼窃取凭据

0x02/浏览器相关检查：
  - 用户访问了 http://aws-login.phish.com（仿冒 AWS 控制台）
  - 下载了 "credentials.csv" 文件
  - 时间：2026-06-15 09:00:00

0x02/系统日志检查：
  - 4624 事件：攻击者从 198.51.100.23 登录 GitHub
  - 时间：2026-06-15 09:05:00

场景 B：代码仓库泄露凭据

0x02/重点文件检查：
  - 开发人员本地环境变量中包含 AWS_ACCESS_KEY_ID
  - git push 时未清理 .env 文件
  - 凭据被推送到公开 GitHub 仓库
  - 时间：2026-06-14 14:00:00

0x02/系统进程检查：
  - TruffleHog 扫描发现凭据泄露
  - GitHub Dependabot 告警

场景 C：S3 桶公开访问

0x02/流量检查：
  - 攻击者使用 S3Scanner 扫描公开 S3 桶
  - 扫描结果发现 3 个公开可读的桶
  - 桶名：company-backups、staging-data、dev-configs
  - 时间：2026-06-15 09:30:00

0x02/系统日志检查：
  - CloudTrail 事件：AnonymousRequest 访问 S3 桶
  - 事件名：GetObject
  - 桶名：company-backups
  - 时间：2026-06-15 09:31:00

分析要点

  • 云环境的初始访问通常不涉及操作系统层面的漏洞利用，而是凭据层面的问题
  • 需要追踪凭据从泄露到被使用的完整链条
  • 公开的代码仓库、配置文件、环境变量是最常见的凭据泄露途径

0x03 阶段二：控制平面侦察

攻击目标

了解云环境的资源分布、IAM 结构、服务配置，寻找高价值目标。

取证来源

  • AWS CloudTrail：Describe*/List* API 调用
  • Azure Activity Logs：资源枚举操作
  • GCP Admin Activity Logs：IAM 和资源查询

典型证据

AWS CloudTrail 侦察序列：

CloudTrail 事件序列：
  2026-06-15T10:00:00Z  DescribeRegions          → 枚举所有可用区域
  2026-06-15T10:00:05Z  DescribeInstances        → 枚举 EC2 实例
  2026-06-15T10:00:10Z  ListBuckets              → 枚举 S3 桶
  2026-06-15T10:00:15Z  ListRoles                → 枚举 IAM 角色
  2026-06-15T10:00:20Z  ListUsers                → 枚举 IAM 用户
  2026-06-15T10:00:25Z  ListAttachedUserPolicies → 枚举用户策略
  2026-06-15T10:00:30Z  GetCallerIdentity        → 确认当前身份
  2026-06-15T10:00:35Z  ListPolicies             → 枚举所有 IAM 策略

Azure Activity Logs 侦察序列：

Azure Activity Log 事件序列：
  2026-06-15T10:00:00Z  Microsoft.Resources/subscriptions/resourceGroups/read
  2026-06-15T10:00:05Z  Microsoft.Compute/virtualMachines/read
  2026-06-15T10:00:10Z  Microsoft.Storage/storageAccounts/read
  2026-06-15T10:00:15Z  Microsoft.Authorization/roleAssignments/read
  2026-06-15T10:00:20Z  Microsoft.ManagedIdentity/userAssignedIdentities/read

分析要点

  • 控制平面侦察的典型特征是短时间内大量 Describe*/List* API 调用
  • 正常管理员通常不会在 30 秒内执行 8 个枚举操作
  • 需要关注 Describe*/List* 操作的频率和时间分布
  • GuardDuty 会将异常的 API 调用模式标记为 “Recon:IAMUser/CloudTrailLoggingEnabled” 等发现

检测方法

-- AWS Athena 查询：检测短时间内大量 Describe*/List* 调用
SELECT useridentity.principalid, COUNT(*) as api_calls, 
       MIN(eventtime) as first_call, MAX(eventtime) as last_call,
       ARRAY_AGG(DISTINCT eventname) as api_names
FROM cloudtrail_logs
WHERE eventname LIKE 'Describe%' OR eventname LIKE 'List%'
AND eventtime > CURRENT_TIMESTAMP - INTERVAL '24' HOUR
GROUP BY useridentity.principalid
HAVING COUNT(*) > 50
ORDER BY api_calls DESC

0x04 阶段三：权限提升

攻击目标

获取更高权限的 IAM 角色或用户，为后续横向移动和数据窃取做准备。

取证来源

  • AWS CloudTrail：IAM 策略修改事件
  • Azure Activity Logs：RBAC 角色分配变更
  • GCP Admin Activity Logs：IAM 策略绑定变更

典型证据

AWS IAM 权限提升：

CloudTrail 事件序列：
  2026-06-15T10:05:00Z  CreateUser                    → 创建新用户
  2026-06-15T10:05:05Z  AttachUserPolicy              → 附加 AdministratorAccess 策略
  2026-06-15T10:05:10Z  CreateAccessKey               → 为新用户创建 Access Key
  2026-06-15T10:05:15Z  CreateLoginProfile            → 启用控制台登录

Azure RBAC 权限提升：

Azure Activity Log 事件：
  2026-06-15T10:05:00Z  Microsoft.Authorization/roleAssignments/write
  - 赋予 "Owner" 角色给新创建的 Service Principal
  - 作用域：/subscriptions/xxx/resourceGroups/production

GCP IAM 权限提升：

GCP Audit Log 事件：
  2026-06-15T10:05:00Z  iam.members.setIamPolicy
  - 将 serviceAccountKey.admin 角色绑定到攻击者控制的服务账户

权限提升的常见路径

路径AWSAzureGCP
创建新管理员CreateUser + AttachUserPolicy创建 SP + 赋予 Owner创建 SA + 绑定 Owner
角色链假设sts:AssumeRole 多级跳转管理身份权限提升服务账户密钥轮换
策略修改PutUserPolicy / AttachRolePolicyRBAC 角色分配setIamPolicy
利用服务账户利用 EC2 实例角色利用 VM 托管身份利用 GCE 服务账户

分析要点

  • IAM 策略修改是权限提升的强信号
  • 需要追踪从低权限到高权限的完整路径
  • 跨账户角色假设链（AssumeRole chaining）是常见的横向移动方式
  • 最终目标通常是 Domain Admin 或云平台 Owner 级别权限

0x05 阶段四：横向移动与持久化

攻击目标

在云环境中横向移动，建立持久化访问。

取证来源

  • AWS CloudTrail：AssumeRole、CreateFunction、RunInstances
  • Azure Activity Logs：Role Assignment、VM 创建
  • GCP Audit Log：Service Account Key 创建、VM 实例创建

典型证据

AWS 跨账户横向移动：

CloudTrail 事件序列：
  2026-06-15T11:00:00Z  AssumeRole → 目标账户：prod-account
  2026-06-15T11:00:05Z  AssumeRole → 目标账户：data-account
  2026-06-15T11:00:10Z  CreateAccessKey → 在 prod-account 创建新 Access Key
  2026-06-15T11:00:15Z  RunInstances → 启动加密挖矿 EC2 实例

Azure 横向移动：

Azure Activity Log 事件：
  2026-06-15T11:00:00Z  Microsoft.Storage/storageAccounts/listKeys
  - 获取存储账户密钥
  2026-06-15T11:00:05Z  Microsoft.Compute/virtualMachines/write
  - 创建新 VM
  2026-06-15T11:00:10Z  Microsoft.Network/networkSecurityGroups/write
  - 修改安全组规则，开放管理端口

持久化机制

持久化方式AWSAzureGCP
创建后门用户CreateUser + CreateAccessKey创建 SP + 赋予权限创建 SA + 绑定角色
修改启动配置User Data 注入脚本VM 扩展修改启动脚本修改
创建计划任务Lambda 定时触发器Azure AutomationCloud Scheduler
修改服务配置ECS/EKS 任务定义修改App Service 配置修改Cloud Run 配置修改
创建后门函数Lambda 函数 + API GatewayAzure FunctionCloud Function

分析要点

  • 云环境的横向移动通常不涉及网络层面的端口扫描，而是通过 IAM 角色假设实现
  • 跨账户角色假设链是 AWS 环境中最常见的横向移动方式
  • 需要追踪每个账户中的 IAM 操作，构建完整的移动路径
  • 持久化机制通常涉及创建新的 IAM 用户或修改现有配置

0x06 阶段五：数据窃取与资源滥用

攻击目标

窃取敏感数据或滥用云资源（如加密挖矿）。

取证来源

  • AWS CloudTrail + S3 Access Logs + VPC Flow Logs
  • Azure Activity Logs + Storage Analytics Logs
  • GCP Admin Activity Logs + VPC Flow Logs

典型证据

数据窃取：

CloudTrail 事件：
  2026-06-15T12:00:00Z  GetObject → 桶名：sensitive-data-backup
  2026-06-15T12:00:05Z  GetObject → 桶名：customer-records
  2026-06-15T12:00:10Z  GetObject → 桶名：financial-reports

S3 Access Logs：
  2026-06-15T12:00:00Z  198.51.100.23  GET  sensitive-data-backup/db-backup.sql.gz
  2026-06-15T12:00:05Z  198.51.100.23  GET  customer-records/customers.csv

VPC Flow Logs：
  2026-06-15T12:00:00Z  10.0.0.55  →  198.51.100.23  TCP/443  ACCEPT  1048576
  2026-06-15T12:00:05Z  10.0.0.55  →  198.51.100.23  TCP/443  ACCEPT  2097152

资源滥用（加密挖矿）：

CloudTrail 事件：
  2026-06-15T12:30:00Z  RunInstances
  - 实例类型：p3.8xlarge（GPU 实例）
  - 镜像 ID：ami-0abcdef1234567890
  - 数量：10

GuardDuty Finding：
  - 发现类型：UnauthorizedAccess:EC2/TorIPCaller
  - 严重程度：High
  - 资源：i-0abcdef1234567890

分析要点

  • 数据窃取通常涉及大量 GetObject API 调用
  • 需要检查 S3 Access Logs 确认被访问的具体对象
  • VPC Flow Logs 可以确认数据是否实际外传
  • 加密挖矿通常会创建 GPU 实例，GuardDuty 会标记此类行为

0x07 阶段六：日志清理与反取证

攻击目标

清理入侵痕迹，阻止调查。

典型证据

AWS CloudTrail 停用：

CloudTrail 事件：
  2026-06-15T13:00:00Z  StopLogging → 停用 CloudTrail 日志记录
  2026-06-15T13:00:05Z  DeleteTrail → 删除 CloudTrail 配置

GuardDuty Finding：
  - 发现类型：Stealth:IAMUser/CloudTrailLoggingDisabled
  - 严重程度：High

Azure 日志清理：

Azure Activity Log 事件：
  2026-06-15T13:00:00Z  Microsoft.Insights/diagnosticSettings/write
  - 修改诊断设置，禁用日志收集

分析要点

  • CloudTrail 停用本身就是一个强攻击指标（GuardDuty 会自动检测）
  • 需要从集中日志平台（如 S3 版本化桶）获取原始日志
  • 日志清理时间点通常在数据窃取或资源滥用之后
  • 需要检查日志是否已备份到不可变存储

0x08 证据拼接：构建完整的云环境入侵时间线

时间阶段证据来源事件结论
09:00:00凭据获取浏览器检查访问钓鱼网站用户凭据被窃取
09:30:00侦察CloudTrailS3Scanner 扫描公开桶被发现
09:31:00侦察CloudTrailAnonymousRequest GetObject数据被访问
10:00:00侦察CloudTrailDescribe*/List* 调用环境被侦察
10:05:00提权CloudTrailCreateUser + AttachUserPolicy管理员权限获取
11:00:00横向移动CloudTrailAssumeRole 跨账户横向移动开始
12:00:00数据窃取CloudTrail/S3 LogsGetObject 大量数据数据被窃取
12:30:00资源滥用CloudTrailRunInstances p3.8xlarge加密挖矿启动
13:00:00反取证CloudTrailStopLogging + DeleteTrail日志被清理

0x09 容器环境取证的特殊挑战

9.1 容器的临时性问题

根据 Aqua Security 的分析，容器的平均生命周期只有几小时，Serverless 函数更短（AWS Lambda 每次执行最多 15 分钟）。这意味着：

  • 容器关闭后，写入容器文件系统的所有数据都会被删除
  • Pod 被终止后，内存中的凭据和运行时数据都会丢失
  • 唯一持久化的证据是编排平台的日志和云控制平面日志

9.2 Kubernetes 取证的关键数据源

数据源内容保留策略
Kubernetes Audit LogsAPI 服务器的所有操作需要预先配置
kubelet Logs节点级别的容器事件需要日志聚合
Container Runtime Logs容器的标准输出/错误需要日志驱动
Cloud Audit Logs云平台的控制平面操作通常默认保留
VPC Flow LogsPod 网络流量需要启用

9.3 容器取证实战方法

方法一：实时容器镜像捕获

# 在容器被终止前捕获镜像
kubectl debug -it <pod-name> --image=busybox --target=<container-name>
# 或者使用 crictl
crictl pull <image>
crictl inspect <container-id>

方法二：Kubernetes 审计日志分析

# 分析审计日志中的异常命令执行
kubectl get audit --field-selector verb=create,resource=exec

方法三：节点快照

# 对运行可疑容器的节点创建磁盘快照
gcloud compute disks snapshot <node-disk> --zone=<zone>
aws ec2 create-snapshot --volume-id <volume-id>

9.4 Tesla Kubernetes 入侵案例

2018 年 Tesla 的 Kubernetes 控制台被入侵事件是容器安全的经典案例：

  • 攻击者通过暴露的 Kubernetes 管理控制台获得初始访问
  • 在容器中部署了加密挖矿恶意软件
  • 攻击持续了约 6 个月才被发现
  • 取证分析的关键证据来自容器运行时日志和网络流量日志

0x10 云环境取证的特殊挑战

10.1 物理访问的终结

在传统环境中，调查人员可以直接访问物理硬件。但在云环境中，这种直接访问被虚拟化基础设施所取代。你无法镜像一个你不拥有的硬盘。云服务商控制底层硬件，调查人员能访问什么完全取决于提供商的法律响应流程和共享责任模型。

10.2 临时基础设施的挥发性问题

容器在几秒钟内启动和销毁，Serverless 函数不留持久运行时。这些临时架构在工作负载终止时就会销毁取证 Artifact。

10.3 跨司法管辖区的法律障碍

GDPR、HIPAA 和本地数据主权法律创造了调查人员无法合法检索存储在外国云区域的证据的情况——即使有有效的搜查令。提前建立法律协调协议至关重要。

10.4 日志保留策略的差异

不同云服务商、不同服务的日志保留策略不同：

日志类型默认保留期建议保留期
AWS CloudTrail90 天12+ 个月
Azure Activity Logs90 天12+ 个月
GCP Audit Logs400 天12+ 个月
VPC Flow Logs取决于配置12+ 个月
S3 Access Logs无默认永久

10.5 凭证验证与完整性保障

每个取证快照必须在收集时进行哈希验证，并在每个传输点重新验证。没有这一点，对方律师可以质疑整个证据集。

0x11 云环境取证的最佳实践

11.1 事前准备

  • 启用不可变审计日志（CloudTrail、Azure Monitor、GCP Audit Logs）
  • 配置日志保留期为 12 个月以上
  • 预先授权 API 令牌用于证据提取
  • 在运行手册中定义明确的云服务商升级联系人

11.2 事件响应

  • 第一步：隔离受影响的资源（限制 IAM 角色、网络隔离）
  • 第二步：创建受影响资源的快照（EC2、S3、容器镜像）
  • 第三步：导出审计日志到不可变存储
  • 第四步：分析日志，构建攻击时间线

11.3 调查方法

  • 使用 Athena（AWS）、Log Analytics（Azure）、BigQuery（GCP）进行大规模日志查询
  • 关联多个日志源，构建完整的攻击链
  • 使用威胁情报平台验证 IP、域名的恶意性

0x12 公开资料与分析借鉴

1. SANS FOR509: Enterprise Cloud Forensics and Incident Response

SANS 的 FOR509 课程提供了最全面的云取证教育框架：

  • 覆盖 AWS、Azure、GCP 三大云平台
  • 包含 23 个动手实验和多云入侵综合实验
  • 2025 年更新增加了 Kubernetes、M365、Google Workspace 覆盖
  • 学员将学习如何利用云原生工具和资源进行取证

最值得借鉴的一点是：云取证不是传统取证加上云层，而是一个完全不同的学科，需要专门的技能、工具和法律框架。

公开来源：

2. Sygnia: Incident Response to Cloud Security Incidents

Sygnia 的云安全事件响应最佳实践指南提供了企业级的 IR 框架：

  • 五个阶段：准备、检测、遏制、恢复、事后学习
  • 每个云平台的具体操作指南
  • IAM 取证的核心地位：大多数云入侵都依赖身份滥用

最值得借鉴的一点是：在 AWS 中，几秒钟内隔离 EC2 实例或限制 IAM 角色；在 Azure 中，隔离受损 VM 同时允许未受影响的工作负载运行；在 GCP 中，快照 Kubernetes 节点并撤销服务账户密钥。

公开来源：

3. SecuredIntel: Cloud Forensics in 2026

SecuredIntel 的文章详细说明了云取证的独特挑战：

  • 物理访问的终结：无法镜像不拥有的硬盘
  • 临时基础设施的挥发性：容器在秒级生命周期内销毁证据
  • 跨司法管辖区的法律障碍：GDPR、HIPAA、数据主权法律
  • 云取证就绪性：事后准备不如事前规划

最值得借鉴的一点是：将云取证就绪性作为主动计划而非被动应对的组织，将始终能恢复更好的证据、降低法律风险并更快结案。

公开来源：

4. Wiz: AWS Threat Hunting Best Practices

Wiz 的 AWS 威胁狩猎最佳实践提供了实操级别的指导：

  • CloudTrail 是所有 AWS API 调用的审计日志
  • VPC Flow Logs 提供网络流量可见性
  • GuardDuty 提供托管威胁检测
  • 使用 Athena 查询大规模 CloudTrail 日志

最值得借鉴的一点是：CloudTrail 中一个账户的 GuardDuty 发现可能连接到另一个账户中的可疑网络流量和第三个账户中的 IAM 角色修改。你需要将这些事件拼接起来才能看到完整的攻击链。

公开来源：

5. Medium: Investigating a Compromised AWS Environment

D Satheesh Kumar 的文章提供了一个真实的 AWS 取证案例（CyberDefenders S3CredentialsHunt 实验室）：

  • 仅使用 Linux 机器和 jq JSON 解析器完成取证
  • 从原始 CloudTrail 日志中重建攻击者活动
  • 发现了 IAM 操作、S3 访问、EC2 操作、STS 角色假设、CloudTrail 配置更改
  • 攻击者最终禁用了 CloudTrail 日志记录

最值得借鉴的一点是：即使攻击者试图隐藏痕迹，控制平面遥测（CloudTrail）通常保留足够的证据来重建完整的攻击生命周期。

公开来源：

6. Aqua Security: Cloud Native Forensics

Aqua Security 的文章详细说明了云原生环境的取证挑战：

  • 容器的临时性使得传统取证工具无法使用
  • 攻击者通常不攻击容器本身，而是利用基础设施窃取计算资源或逃逸到主机
  • 云提供商原生日志通常只捕获控制平面和操作系统日志，不包含应用日志
  • DTA（深度威胁分析）可以在构建时和事后分析容器镜像

最值得借鉴的一点是：如果攻击者利用了云原生应用，等到攻击被识别时，容器和 Pod 可能已经不存在，使得事件响应和取证比以往任何时候都更具挑战性。

公开来源：

0x13 和其他分析篇怎样联动

本文是云环境入侵场景的综合分析，联动了以下专题：

  • 勒索软件入侵全链路取证分析与证据拼接：勒索软件可能从云环境开始
  • 内网横向移动全链路取证分析与证据拼接：云环境横向移动与传统环境的对比
  • 钓鱼邮件入侵全链路取证分析与证据拼接：钓鱼是云凭据泄露的主要途径
  • 供应链投毒全链路取证分析与证据拼接：CI/CD 管道与云环境的交叉
  • Web应用入侵全链路取证分析与证据拼接：Web 应用通常部署在云环境中
  • 系统日志检查结果证据强度分层与事件链构建分析：云日志的证据强度分层

0x14 总结

云环境入侵取证分析的关键，不是"套用传统取证方法"，而是：

  • 理解云环境与传统环境的本质区别
  • 掌握三大云平台的审计日志源和分析方法
  • 从凭据获取开始，覆盖完整攻击链
  • 识别容器和 Serverless 环境的特殊取证挑战
  • 构建跨账户、跨区域、跨平台的完整攻击时间线

当你能从 CloudTrail、Azure Activity Logs、GCP Audit Logs、VPC Flow Logs、Kubernetes Audit Logs 中读出凭据泄露、权限提升、横向移动、数据窃取、日志清理等信号，并将 AWS、Azure、GCP 的证据拼接成一条完整的攻击链时，0x03 的"取证分析"才真正从"传统环境取证"升级为"云原生全链路取证分析"。