一枚泄露的 AWS 访问密钥在 72 小时内扩散成多账户失守

1 第一枚密钥出现后，调查面对的是一组不断分叉、不断重新启动的攻击波

在同一个被观察到的秒内，属于四个 AWS 账户的四枚不同访问密钥从同一源 IP、以同一用户代理发出活动。调查在这里不再像一条按顺序推进的入侵链，而是一场竞速：一个身份已经分裂成多条活动泳道，多账户同时出现调用；如果响应人员仍只盯着第一枚密钥，看到的已经是历史，而其他分支仍在继续。

要解释这四条泳道怎样出现，故事必须倒回一套互联网应用。Sygnia 在 2026 年 6 月 29 日发布的详细调查说明，该应用的一处弱点暴露了一枚长期 AWS 访问密钥。攻击者据此确认主体与权限，枚举可达服务并继续寻找秘密。每一枚新密钥都带来新的身份与授权上下文，有时还进入另一个账户，于是发现、收集、持久化、数据访问和影响动作从新的起点再次展开。

这轮扩张从初始访问到广泛云环境失守约用了 72 小时，却没有依赖未公开零日或新型恶意软件。AWS API、应用数据库、ECS 与 EC2 工作负载、GitHub 与 Bitbucket runner、S3 对象、Secrets Manager、SSM Parameter Store、部署脚本、基础设施模板和容器镜像被串成同一张身份—秘密网络。数据层出现数百条不同 SQL、跨越数十个数据库；其他位置则留下快速适配脚本、结构化制品和多路任务上下文。

Sygnia 将这些行为评估为与 AI 辅助或 agentic 工作流一致。证据支持自动化编排、脚本生成、环境理解和任务管理显著提高了操作速度；公开材料没有提供一个可以证明“无人监督自治系统独立完成全部入侵”的技术记录。本报告保留观测与分析的边界，把重心放在可复核的云事件。

“约 72 小时”描述的是从初始访问到广泛失守的大致跨度，不是留给防守方的倒计时，也不表示活动在第 72 小时结束。真正决定性的窗口往往只有几分钟：一个身份读出秘密，子身份随即开始活动。第一枚密钥因此不是孤立 IOC，而是身份依赖树的根；即使它被禁用或从日志中沉默，已经派生的会话、凭据和账户分支仍须继续追踪。处置必须一边冻结身份扩张，一边补齐证据。

下文因此始终沿状态变化推进：应用中的秘密变成 AWS 身份；该身份触达更多秘密承载面；其中一些秘密成为新身份；新身份又改动访问关系、工作负载、部署制品、应用用户、数据与服务可用性。每一步都要回答什么证据证明这次转换、仍有哪些未知、哪个动作真正关掉路径。这比把同一批事实拆成通用云攻击清单更能解释事件。

1.1 公开报告给出了行为链与取证统计，也留下了必须诚实标注的空白

报告没有公开客户身份、互联网应用名称、具体漏洞编号、AWS 账户号、访问密钥值、源 IP、完整 user-agent、RDS 表名与逐条时间线。SOSEC 因此不制作未经披露的 IOC，不把入口归到某个 CVE，也不臆测受害行业。读者可以复核公开事实与 AWS 机制，无法从本文恢复客户敏感字段。

“观察到”用于 Sygnia 明确列出的动作：秘密来源、IAM 持久化、反向 shell、部署与 IaC 修改、应用高权用户、RDS 查询、S3/ECS/ACL/SQS 影响，以及同秒四密钥活动。“分析判断”则用于 AI 辅助、任务编排和“操作记忆”。两类结论在文中始终分开呈现。

“约 72 小时”不等于每个动作都有公开的秒级时间。文中的阶段只说明依赖关系；受影响组织需要用 CloudTrail、身份提供商、代码托管、CI/CD、数据库审计与终端遥测恢复精确 UTC 顺序。后文引用 AWS 与平台文档解释服务机制，不把通用防御建议冒充为该客户已经部署或缺失的控制。

证据边界直接改变影响表述。“某个主体有权读取秘密”是能力结论；“它调用了读取 API”是访问事件；“返回值随后被使用”还需要目标平台的认证或活动记录。这几句话对应不同的影响层级。响应团队面对可信暴露应立即轮换，不必等待后续使用；但面向公众或监管方描述数据影响时，必须区分权限、尝试、成功响应、返回记录与确认传输。

公开材料没有给出的内容，不能用一个看似合理的产品名补齐；这些空白本身就是结论的一部分。应用、脆弱组件、源码路径、release 与 fix 均未披露，因此本报告可以精确指出暴露信任边界和云端控制动作，却不能诚实地编造 vulnerable function 或 patched version。本章后面的独立定位板块会明确写出这项缺失，并用受影响组织可以验证的操作坐标替代虚构的源码细节。

2 入口是一枚来自互联网应用的长期 AWS 密钥，它把应用漏洞直接转换成云 API 身份

公开报告只说明互联网应用弱点导致访问密钥暴露。关键转换发生在应用边界之外：攻击者取得的不是一次网页会话，而是一对可以向 AWS API 签名的长期凭据。密钥对应的 IAM 用户或其他长期身份拥有哪些策略，决定了攻击者最先能看见哪片云资源。

调查从首次 API 活动建立基线：eventTime、eventSource、eventName、awsRegion、sourceIPAddress、userAgent、userIdentity、accessKeyId、请求参数、响应元素、错误码与请求 ID。CloudTrail 事件中的访问密钥 ID 是关联键；与之配对的秘密访问密钥属于认证材料，不应出现在日志里。

同一枚访问密钥可能被应用长期正常使用。异常判断需要比较历史源网段、服务组合、区域、调用速率、错误枚举、首次访问资源与时间分布。一个从陌生地址发出的 GetCallerIdentity 或权限探测只是一条线索；连续的资源枚举和秘密读取，才把它推入一条完整的入侵链。

入口修复不能止于删除网页上的字符串。先禁用或删除泄露密钥、撤销可能取得的会话、为应用建立新身份，再确认旧密钥是否存在于镜像层、环境变量、构建日志、错误页、缓存、对象存储、数据库和备份。每一份副本都可能再次成为起点。

长期方向是让 AWS 工作负载使用角色与短期凭据，让外部 CI 通过 OIDC 获取受限会话，并从应用配置中移除静态访问密钥。短期凭据仍可能被窃取，但有效期、会话标签、audience、subject 与策略条件能明显缩短重放窗口，也让身份来源更容易分辨。

访问密钥 ID 是 CloudTrail 与 IAM 报告里的关联标识，秘密访问密钥则是认证材料；后者不应进入工单、聊天、查询或截图。确需比对时，应在受控流程中计算单向指纹，只把标识和比对结果写入案件记录。把长期密钥设为失活，只能阻止它继续签名，无法自动撤销已经签发的 STS 会话、工作负载身份或外部令牌，因此每条派生凭据都要单独登记和关闭。

根因关闭还要回答：凭据为什么能从应用中被取回？公开材料没有说明原因究竟是响应泄露、任意文件读取、命令执行、调试输出、备份暴露还是部署错误。受影响方只能回到自己的环境，固定实际发布版本、路由、任务、配置修订和秘密注入路径，保存脆弱状态，并在修复后用未认证或低权限请求做负向验证。新凭据应等到权限收窄、信任机制调整和可信部署完成后再发放，同时确认日志、诊断、备份和镜像层不会再次复制它。

2.1 每一枚新凭据都会重新启动发现、身份转换与并行攻击波

云入侵的第一轮通常围绕身份建立地图。sts:GetCallerIdentity 可以确认账户和主体；IAM、Organizations、EC2、ECS、S3、RDS、Secrets Manager、SSM 与代码部署服务的只读 API 展示可见资源。即使部分请求被拒，错误本身也帮助推断权限边界和资源存在性。

有效权限不是某一张 IAM 策略的文本。身份策略、资源策略、权限边界、服务控制策略、会话策略、角色信任与显式拒绝共同作用。调查要从实际 CloudTrail 调用和完整授权上下文重建可用能力，不能只看被盗用户所附策略的名称。

攻击者寻找的“下一枚身份”可能藏在 Secrets Manager、Parameter Store、容器环境、实例用户数据、应用配置、数据库记录、代码仓库、runner 环境、S3 文件或实例元数据里。任何一个位置的读取权，都可能把当前账户里的访问继续延伸到另一个账户、SaaS 平台或生产部署系统。

组织应预先维护一张“身份—秘密—资源”关系图：哪个工作负载能读取哪些秘密，这些秘密可以登录哪个账户或平台，获得的新身份又能改动哪些部署和数据。它不必预知所有攻击路径，首先要能回答一枚密钥泄露后还需要连带轮换什么，而不是等到事件发生再逐个猜测。

检测规则也围绕这三个问题设计。来自陌生来源的身份确认、权限枚举、跨区域资源列表、秘密服务访问和 runner 配置读取若在短时间内接连出现，比任何单个 API 的全局阈值更有意义。每枚新访问密钥首次出现时，都应重新建立行为基线，并寻找与它相邻的高价值身份。

Sygnia 把这些活动称为一波又一波的攻击，而不是一条“入口—横向—目标”的直线。一枚密钥仍在活动时，另一份身份已经开始枚举新的权限范围，有时甚至身处另一个账户；runner 令牌可以打开源码和部署系统，数据库凭据则把活动带入数据层。凭据越多，同时展开的攻击支线越多，也越考验分散在不同平台上的日志能否及时汇合。

这种模式让逐主机视角失效：账户 A 的 secret 可能进入 CI，部署到账户 B，再由新工作负载角色抵达账户 C。调查单位必须是完整身份族，沿 secret 读取、角色承担、runner 作业、部署、数据库登录和网络连接展开；各平台共用案件 ID、UTC 时间与父子关系，直到不再出现新的账户、平台或信任边。

响应队列要为每枚凭据记录四个时间：最早可能暴露、首次观察到读取、首次观察到使用，以及最晚可能有效；同时关联签发方、父级证据、权限、消费者、会话时长、负责人和验证结果。优先级由权限与传播潜力共同决定：能修改生产工作流的低权限仓库令牌，可能比已隔离账户里的管理员密钥更危险；能读出第三方令牌的数据库密码，也可能继续长出新的分支。

AccessDenied 只说明一次请求在特定上下文中失败，不能证明换一个区域、资源策略、会话或角色后仍会失败。拒绝事件要与后续授权变更和成功调用连接起来。关闭条件也必须落实到各自的签发端：AWS 密钥在 IAM 中失活，GitHub PAT 在 GitHub 撤销，SSH 密钥从所有信任位置移除，数据库密码则还要终止旧会话并迁移消费者。一个笼统的“已轮换”，无法代表这些路径都已经关闭。

3 秘密不是一个保险箱里的同类对象，而是散落在运行时、流水线、对象、数据库和托管服务中的关系网

Sygnia 列出的秘密来源覆盖 ECS 与 EC2 环境变量、GitHub 与 Bitbucket runner 环境、S3 明文对象、应用数据库、AWS Secrets Manager 和 SSM Parameter Store。这些位置由不同团队维护，却可能保存同一枚生产 API 密钥、数据库密码、个人访问令牌或跨账户 AWS 访问密钥。

秘密发现应同时保存“存放位置”和“可用目标”。一个名为 PROD_TOKEN 的值只有在验证其发行方、权限、作用域、最后使用和轮换责任后才进入影响图。切勿在分析工单复制明文；保存秘密对象 ARN、版本、哈希指纹、读取主体与关联服务。

读取记录与使用记录要连接。CloudTrail 可以显示某主体调用 GetSecretValue 或 GetParameter，后续 GitHub、Bitbucket、数据库、AWS 账户或外部 API 日志可能显示令牌被使用。读取本身足以触发轮换；使用证据用于扩大影响与确认时间。

同一份秘密被多处保存，会让轮换变得棘手。一枚凭据可能同时存在于 Secrets Manager、runner secret、ECS 任务定义、Helm values、S3 备份和应用表中。只更新“正式”密码库，旧副本仍可能继续有效。处置清单要从凭据签发端确认全部活动版本和会话，而不能只改一个存储位置。

长期治理用短期身份替代可替代的静态秘密，用自动轮换处理必须保留的数据库与第三方凭据，并持续扫描代码、镜像、对象、日志与数据库中的明文。发现结果应回流到所有者和删除流程，避免扫描器只生成永不收敛的告警。

可执行的秘密清单要覆盖完整生命周期：签发方、权威副本、可读取主体、所有落地副本、消费者、派生会话、替换方式和旧值退出条件。它还要区分确认读取、位于已失守进程中的可信暴露，以及仅有权限可达三种状态；三者都可能触发轮换，但不能被写成同一种影响事实。

加密只能阻止没有解密权的主体，无法保护本来就有 KMS 权限的被盗应用角色。轮换前还要记录消费者的失败行为：旧值缓存到何时、是否需要重启、失败会不会锁定账户或阻塞队列，以及健康检查、回退上限和观察窗口。这样才能快速失活凭据，又不把未知消费者变成新的中断。

3.1 ECS 与 EC2 运行时同时暴露启动秘密、角色、文件和执行通道

AWS 支持在 ECS task definition 中引用 Secrets Manager 或 Parameter Store，将值注入容器环境。官方文档明确说明，容器启动后收到的是初始值；秘密随后轮换，运行中的容器不会自动取得新值，需要强制新部署或启动新任务。这一生命周期直接影响事件处置。

能在容器内执行命令、读取进程环境、访问诊断端点、获取 task definition 或影响启动脚本的主体，可能接触注入值。环境变量还可能进入崩溃报告、调试输出、子进程、APM 配置与错误日志。调查要检查运行时与日志平台，而不仅是秘密服务的读取事件。

轮换顺序是先在签发端生成新值并限制旧值，再更新 Secrets Manager、Parameter Store 与应用配置，创建新的任务定义修订并强制部署，确认所有旧任务停止，最后吊销旧凭据。若直接吊销，关键服务可能中断；若只更新秘密，旧任务仍会继续携带泄露值。

CloudTrail 中的任务定义修改、服务更新、任务启停、exec 会话和秘密 API，能够拼成一条时间链。把任务 ARN、任务定义修订、集群、服务、执行角色、任务角色与容器镜像摘要放进调查表，才能判断哪些任务曾经携带旧值。

更成熟的应用会在运行时通过受限角色按需取得秘密，只做短时缓存，避免秘密长期留在环境变量中；这需要同时处理可用性和调用成本。无论采用哪种模式，任务角色都只应读取本服务需要的具体 ARN，再用资源策略、KMS 和网络端点进一步收窄。

EC2 工作负载可能从 systemd 环境文件、shell profile、用户数据、容器编排、应用配置、进程环境或实例元数据获得凭据。取得主机执行能力后，攻击者可以横跨这些位置。Sygnia 报告记录了对 EC2 环境变量的秘密收集，也记录了在 EC2 建立反向 shell 的持久化。

实例角色提供短期凭据，避免静态密钥，却仍要求保护元数据服务与主机边界。强制使用 IMDSv2、限制跳数、收窄角色权限，并阻止不需要的容器访问元数据。若攻击者已经在实例上以应用身份运行，角色允许的 API 就是它当下拥有的云权限。

调查要保存实例 ID、AMI、启动模板、实例配置文件、安全组、子网、用户数据哈希、磁盘快照、进程树、登录、计划任务、systemd unit、authorized_keys、容器清单与网络连接。只轮换云密钥，不会删除主机上的 shell、服务或被修改的脚本。

广泛失守的运行时应优先从可信 AMI 与经过复核的 IaC 重建。不能立即替换的生产系统先隔离，保存易失证据，撤销角色会话，并对启动链做差异分析。新环境使用的源码提交、runner、依赖、基础镜像摘要、镜像仓库、启动模板、任务定义、秘密和部署身份，要么早于失守，要么经过独立重建；一块“看起来干净”的旧磁盘或可变标签，不能成为可信起点。

ECS 秘密注入的历史功能边界也要写进环境记录：Fargate 平台从 1.3.0 起支持注入完整秘密，Linux Fargate 从 1.4.0 起支持选择 JSON 键或版本；ECS on EC2 历史上分别至少需要 agent 1.22.0 与 1.37.0。这些不是本案的受影响版本，调查必须采集事件发生时实际使用且受支持的平台与 agent。无论处于哪个分支，正在运行的任务都不会因为秘密存储更新而自动刷新。

轮换时应列出任务 ARN 和启动时间，启动新的任务定义修订，在健康容量建立后停止旧任务，再验证退役凭据已经失效。停止一个任务并不能隔离 ECS 服务，因为调度器可能立即补齐期望容量；普通滚动发布、CodeDeploy 蓝绿发布和外部控制器也各有自己的部署路径。ECS Exec 无法在既有任务上事后开启，事件前未启用时只能记为证据缺口。

IMDSv2、跳数限制和网络控制能减少元数据窃取，却不能阻止已经以任务角色或实例角色运行的代码调用其合法 API。它们必须与按服务拆分的最小权限角色、出网控制和首次出现 API 检测结合；若继续运行已经威胁数据完整性，应先隔离，再如实记录因此失去的易失证据。

3.2 CI runner 集中保存源代码、部署令牌和云身份，一次环境读取可以跨过组织边界

Sygnia 观察到攻击者从 GitHub 与 Bitbucket runner 环境中收集秘密。Runner 为构建和部署读取仓库、包注册表、云账户、签名系统和生产凭据；自托管 runner 还可能保留工作目录、缓存、Docker socket、SSH agent 与跨作业状态，使一条低权限流水线变成高价值跳板。

事件响应应立即冻结受影响 runner 的新作业，保存 runner ID、镜像、主机、版本、注册令牌、作业记录、工作目录和网络日志。随后撤销 runner 注册与相关会话，轮换它接触过的 PAT、部署密钥、OIDC 信任、云角色、镜像仓库令牌、签名密钥与 webhook 秘密。

仓库调查要覆盖分支、标签、提交、工作流、流水线配置、runner 脚本、依赖锁、子模块、发布制品、容器镜像与 IaC。Sygnia 记录了“pentest”“red team”等措辞，以及虚构 CEO 授权的痕迹；名称本身不能提供授权，所有变更都必须回到真实批准人、工单、签名和允许时段。

GitHub Actions 访问 AWS 时应优先使用 OIDC，信任策略精确限制仓库、分支或受保护环境、受众与可承担角色；Bitbucket 使用等价的短期联合身份能力。长期 AWS 密钥不应进入仓库秘密。生产部署 runner 要与普通 CI 分离，使用一次性环境，并在作业后销毁。

恢复发布前，应由独立可信的 runner 从复核过的提交重新构建，生成 SBOM、制品摘要和签名。不要把入侵期间已有的镜像重新贴上“干净”标签：镜像里的启动脚本、入口点、分层和依赖，都可能携带绕过常规代码审查的修改。

仓库调查必须重建“谁有权让什么代码运行”，不能只比较默认分支。攻击者可以创建分支、修改工作流、执行它、取走临时凭据，再删除分支，让生产源码表面看起来毫无变化。因此要保存组织与仓库审计、工作流运行、环境批准、runner 分配、制品上传、包发布、正式发布、部署密钥、webhook 投递和分支保护变更，并把每次运行连接到精确的提交 SHA，以及批准或触发它的身份。

自托管 runner 的持久化可能藏在平台审计面以下：作业可以修改系统服务、计划任务、Docker 守护进程、凭据助手、缓存或 runner 程序本身，让后续合法作业继续执行攻击代码。移除 runner 只会停止调度，不会清理主机。保存证据后，应撤销注册和相关凭据，隔离主机并从可信镜像重建；不能给同一块磁盘换个令牌后重新注册。

OIDC 只有在签发方、受众、仓库或工作区，以及部署环境等 subject 条件被精确约束时，才真正优于静态密钥。GitHub 的 environment subject 通常不会同时携带分支，因此分支和标签还要由环境保护规则控制；Bitbucket 也需按实际令牌固定仓库和部署环境。收紧信任只能阻止新会话，已经由 AssumeRoleWithWebIdentity 签发的凭据仍须撤销或显式拒绝，取得它们的 runner 与工作流也要重建。

一枚有效签名，洗不掉已经失守的签名者。事件窗口内的签名、依赖锁、Action、可复用工作流、容器基础镜像、插件、子模块和远程脚本都要复核；随后在独立 runner、固定依赖和受控网络下生成新的 SBOM、摘要与签名。在来源重新可信以前，准入控制应阻断旧摘要和未知摘要。

3.3 S3、托管秘密服务与数据库把秘密发现转换成数据访问和控制

报告确认攻击者在 S3 对象中搜索明文秘密，并通过拒绝访问展示影响能力。对象存储常被用于配置备份、日志导出、数据库快照、部署包、环境文件和人工交接。Bucket 私有只限制外部匿名访问，无法阻止拥有 GetObject 的被盗云身份。

S3 调查同时需要管理事件和数据事件。默认 CloudTrail 管理日志不足以回答每个对象是否被读取；关键存储桶应启用对象级数据事件或 CloudTrail Lake 事件数据存储，并用存储桶、对象键、versionId、主体、accessKeyId、sourceIPAddress 与请求 ID 关联。服务访问日志可以补充，但字段和时效不同。

对秘密扫描结果，应保存存储桶 ARN、对象键、版本、ETag 或哈希、最后修改时间、加密密钥、读取主体和凭据用途，不要在中央工单里复制对象内容。启用版本控制时，还要检查旧版本和删除标记；轮换当前文件，不会清除历史版本中的有效凭据。

攻击者设置拒绝访问可能通过 bucket policy、access point、对象 ACL、KMS key policy、组织级控制或相关网络路径实现。恢复前保存策略旧值与变更事件，再从可信基线恢复。直接覆盖可能丢失证明，也可能遗漏另一层显式拒绝。

长期措施包括禁止公共访问、最小化对象读取、按数据域拆 bucket、使用 KMS 与受限 key policy、对象级检测、Macie 或等价数据发现，以及删除明文凭据。加密静态对象保护介质和访问路径，拥有合法解密权限的被盗身份仍能读取，身份边界必须同时收紧。

Secrets Manager 与 SSM Parameter Store 提供集中存储、KMS 加密、版本和 CloudTrail 记录。攻击者若拥有列表与读取权限，可以快速枚举名称并提取多个系统的凭据。Sygnia 在两种服务都观察到秘密收集，说明“已经放进密码库”只完成了存储治理的一半。

调查要检索 ListSecrets、DescribeSecret、GetSecretValue、PutSecretValue、资源策略与轮换变更；Parameter Store 侧则检索 DescribeParameters、GetParameter(s)、路径查询、标签和策略修改。所有记录按 accessKeyId、会话签发方、源 IP、用户代理、区域和时间关联。

秘密名称本身可能泄露环境、系统和用途，列表权限也应最小化。角色只读取精确 ARN 或严格 path，并用标签、账户、VPC endpoint 与资源策略条件约束。管理与读取分离，普通工作负载无权修改 secret policy、rotation lambda 或 KMS 权限。

一旦确认读取，按值的发行方吊销旧凭据，再生成新版本。然后逐一重启或重新部署消费者，验证新版本使用，监控旧值是否继续出现。轮换 AWS access key、数据库用户、第三方 API、OAuth token 和证书的方式不同，统一工单仍需保留各自完成证据。

对每份秘密建立消费者清单和最后读取基线。一个长期无人读取的秘密可能是遗留风险；一批秘密突然被新主体从新区域读取，则具有很高优先级。自动轮换必须配有失败告警和旧版本回收，不能让“轮换已开启”成为未经验证的状态标签。

Sygnia 报告称攻击者针对数十个数据库运行数百条独特 SQL，访问用户、交易与其他敏感记录。这个规模体现了任务并行和快速适配，也说明云控制面日志不足以完整描述影响：数据库认证、审计、查询、代理和网络流量必须进入同一时间线。

先识别每次连接使用的数据库用户、来源工作负载、目标 RDS 实例或集群、端点、时间、TLS、认证方式和会话。若查询经过应用或跳板转发，CloudTrail 只会记录基础设施 API，SQL 来源可能显示为合法应用主机；这时需要主机与应用日志，才能还原上游访问密钥。

查询审查按 schema/table、操作类型、返回行、错误、执行时间与导出行为聚类。大量 SELECT 可以是枚举或收集；DDL、用户创建、权限授予、trigger、function、event scheduler 与扩展变更可能形成持久化。保存原始审计日志并限制其中的敏感数据传播。

处置包括撤销泄露数据库凭据和会话、限制网络来源、检查用户与授权、验证参数组与审计配置、旋转应用消费者、重建可疑代理或跳板，并评估读取数据的合规影响。单纯改密码不会撤回已经导出的记录。

长期使用每个服务独立数据库身份、短期 IAM 数据库认证或托管轮换、只读与写入分离、行列级最小权限、网络分段和可靠审计。查询异常检测以应用基线为依据，关注新来源、跨 schema 广度、枚举式错误和短时大量独特语句。

S3 范围结论必须先固定日志覆盖。GetObject 属于默认不记录的数据事件，Event history 也不包含它；事件发生时的 selector 若只覆盖部分存储桶、前缀或读写类别，未覆盖对象只能标为未知。对象版本和访问策略还是两条不同的时间线，需同时保存版本 ID、删除标记、策略、ACL、访问点、KMS 授权和复制状态；事后扩展日志，无法补回过去的读取。

托管秘密的轮换，只有在签发方、副本、消费者和会话全部一致后才算完成。Secrets Manager 的 AWSPENDING 与 AWSPREVIOUS 只是版本状态，不证明旧凭据已经失效；Parameter Store 的版本、标签和到期设置，也不能代替真实数据库、SaaS 或云平台签发方撤销凭据。正确顺序是替换真实凭据，更新并刷新消费者，验证新认证，使旧值和旧会话失效，再持续监控旧值是否仍被使用。

数据库影响要分层证明：认证日志证明会话建立，审计记录证明语句到达，查询状态说明成功或失败，引擎或应用证据估计返回行数，网络或导出遥测才支持传输判断。面对数百条语句，既要规范化字面量，避免夸大“不同查询”的数量，也要受控保留原始语句，用来判断查询条件和列范围。轮换密码后还需终止连接池中的旧会话，并覆盖只读节点、代理、复制副本、Data API、分析副本和后台作业；合法应用身份已经被滥用时，单靠网络白名单无法完成隔离。

4 同一秒、同一来源、同一客户端指纹下的四账户密钥，是编排速度最清晰的一条证据

单个 API 调用无法证明使用 AI。Sygnia 的强信号来自组合：四枚属于四个 AWS 账户的访问密钥在同一个观察秒内，从相同 source IP 与 user-agent 发生活动。人可以启动并行脚本，传统自动化也能做到；这条记录首先证明集中编排和并发。

把事件按 accessKeyId 分组，再比较 eventTime 精度、源 IP、用户代理、区域、API 类型、请求 ID 和会话上下文，可以区分同一工具并发、代理汇聚、NAT 出口和正常企业自动化。关键是把异常活动与获准作业、角色和时间窗口对照。

若四个账户平时就由同一安全扫描器或基础设施平台管理，同秒同源可能是基线。因此调查还依赖这些 key 的来源、前后动作、秘密读取、持久化和数据访问。事件上下文让并行性成为攻击证据，而非孤立的统计巧合。

对检测工程，规则不必写“AI 攻击”。更可靠的名称是“多账户多身份同源高并发云枚举/敏感动作”。聚合同一组织内短窗口的 accessKeyId 数、账户数、敏感 API 类别与新颖度，排除登记自动化，命中后立即展开身份族。

这条信号也说明日志必须跨账户集中。各账户单独看只见一枚 key 的若干调用，组织级 CloudTrail、Security Lake 或 SIEM 才能在一秒内把四条泳道放到一起。集中化需要稳定账户标识、统一时间和足够低的摄取延迟。

四条记录要从原始事件复现，逐一保留 timestamp、account、access-key ID、event/request ID、来源、user-agent、API、region 与 identity type，并确认摄取过程没有取整时间或改写字段。同源可能来自 VPN、NAT 或代理，相同 user-agent 也可能只是共享 SDK；只有它们与新凭据血缘、相似 API 顺序和同步状态变化一起出现，推断才变强。合法自动化应按身份、范围、时间与行为登记，不能只靠 IP 白名单排除。

并发同时量出了响应窗口：若密钥 B 在密钥 A 的告警被接手前已经开始敏感枚举，检测和交接延迟就超过了凭据转换速度；若 B 在 A 失活后才出现，则要追查旧会话、存储副本或隔离前已经形成的路径。同秒四枚只是样本，公开的密钥跳转图还把 89 枚密钥按推定用途分为验证或跳转 23、发现或扫描 26、ECS 或容器执行 24、载荷或 SQL 适配 6、Redshift 轮询 1 和其他 9，亚分钟窗口内最多有六条工作线并行。数字说明响应方要关联的有状态活动数量，不代表 89 个账户或 89 个独立操作者。

中央分析必须安全地连接身份记录：访问密钥 ID 要结合真实签发方解释，临时会话有不同标识，assumed-role ARN 还包含调用方可以自行填写的会话名。应规范化账户与分区，保留完整主体 ID，沿会话签发方连接，并允许 CloudTrail 延迟到达；否则按友好名称分组或粗暴去重，会把真正的并发关系抹掉。

4.1 AI 辅助判断来自速度、并发、工具适配、任务记忆和制品语言的合并评估

调查人员观察到快速覆盖多种云与应用表面、重复执行完整检查清单、为新资源生成或调整脚本、跨密钥维护任务上下文、并行调用，以及结构化自记录制品。这些特征共同支持工具化与 AI 辅助参与，远强于从一段流畅注释猜测作者。

所谓“操作记忆”，体现在每枚密钥对应的账户、权限、已完成动作、可访问资源和后续任务都被持续管理。切换密钥没有让操作丢失上下文，反而形成并行工作队列。LLM agent、常规编排器、人工团队或混合系统都可以提供这种能力；公开证据能更直接地证明这种结果形态，而不是背后的具体实现。

报告中的“pentest”“red team”和虚构 CEO 授权措辞可能用于误导调查，也可能用于向生成式工具包装授权背景。仅凭名称无法确定目的。安全团队应把它作为搜索与关联线索，授权验证仍依赖真实工单、签名提交、批准人和时间范围。

证据分为三层：直接观察到的云与应用事件；这些事件支持的集中自动化与并行编排；Sygnia 对 AI 辅助或 agentic 工作流的分析判断。这样既保留事件的新特征，也不会把分析语言误当成取证字段。

快速适配可以用具体证据检验：把每份脚本或查询集，与它前一刻刚发现的资源、数据结构、错误和权限进行比较。工具若随环境改变名称、区域、分页方式、服务选择或 SQL 结构，足以证明它在适配，却仍不能说明适配由人工还是模型完成。来源要结合文件时间、提交历史、执行记录、注释、本地状态和周边操作行为重建，制品中的措辞只能提供辅助权重。

公开材料还给出一条把适配能力与应用机制连在一起的线索：Sygnia 描述了攻击者对 SQS 队列、脆弱 worker、载荷注入点，以及管理集群的部署文件之间关系的分析。这已经超出通用云资产枚举，说明攻击者把发现的应用结构转化成一条从排队任务走向代码执行和部署控制的路径。公开报告没有识别客户组件，也没有给出脆弱代码，因此确切函数仍然未知；这条关系却解释了为什么消息、运行时、部署和数据证据必须一起重建。

公开的恶意提交图片把制品措辞落到了具体机制上：一个宣称获得授权的“渗透测试”步骤，尝试收集云凭据、生产秘密和实例元数据，将环境材料编码后送往被遮盖的外部目的地，并用容错 shell 行为避免作业中断。一次 CI 变更由此同时包含了授权话术、秘密收集、元数据访问和向外传输。即使去掉全部 AI 标签，凭据暴露、身份扩张、秘密收集、持久化、数据访问、影响与恢复仍构成完整案件；AI 判断只解释它为何如此迅速、又为何能够并行协调。

4.2 持久访问同时铺进 IAM 身份与运行时 shell

Sygnia 观察到攻击者创建或尝试创建 IAM 用户和额外访问密钥。身份从这里发生不可逆转折：初始 key 即使失活，新用户、新 key、角色会话或跨账户信任仍可独立继续调用 API。调查因此不能以入口密钥最后一次出现为终点，而要沿 CreateUser、CreateAccessKey、策略、用户组、角色、信任、登录配置和 MFA 变化寻找所有后代。

分支不一定表现为新 user。给现有身份增加第二枚 key、扩大 trust principal、切换默认策略版本、加入高权 group 或改变权限边界，都能在熟悉名称下面增加新路径。每个变化要连接创建主体、时间、来源、权限来源、最后使用、访问资源及继续创建的对象；CloudTrail、IAM 凭据报告、策略历史、Access Advisor 与 Config 快照共同恢复这张关系图。

报告还记录了 EC2 与 ECS 中的反向 shell。网络连接只是可见结果，真正的启动点可能藏在 systemd、cron、入口脚本、sidecar、任务定义、用户数据或部署流水线。ECS 证据固定集群、服务、任务 ARN、修订、镜像摘要、角色和部署时间；EC2 则固定 AMI、启动模板、磁盘、实例配置文件、用户数据、进程与网络。目标地址离线，只说明眼前连接中断，不能说明这些启动路径已经消失。

身份和运行时两张图必须相互连接。一个 shell 读取的新凭据可能创建 IAM 对象，一个被改过的角色或资源策略又能让下一批工作负载取得会话；删掉进程或用户都可能只剪掉树梢。可信快照与写事件用来重算用户、key、角色、信任、身份提供商、权限边界、策略版本及关键资源策略，运行时则比较镜像、启动链、网络和部署来源。

范围由此明确：任何能独立认证、刷新会话或在下一次启动时重新执行的分支，都已经脱离首枚 key 的生命周期。只有它的签发关系、执行来源和后代对象都回到可信状态，入口 key 的失活才真正收束这一支。

4.3 部署制品与应用身份把持久化藏到了 IAM 清理之外

Sygnia 发现持久化分散在基础设施模板、部署脚本、容器镜像、云存储和 webhook 重定向中。这些修改可能等到下一次流水线、扩容、故障切换、灾备或人工部署才执行；当前实例看起来平静，并不能排除一份休眠制品已经获得未来的执行权。

证据要覆盖代码托管、批准、签名、runner、镜像仓库和部署平台：事件窗口内的提交、分支、标签、拉取请求、工作流、webhook、部署密钥、镜像推送、清单，以及 IaC 计划和应用记录都进入同一时间线。提交信息里的“pentest”或“已授权”只是待核对文本，真实授权仍来自批准人、工单、签名与允许时段。

镜像按摘要、分层、入口点、软件包、启动脚本与 SBOM 比较，可变标签不能证明身份；IaC 则做语义差异，排除格式噪声后检查主体、权限、网络出口、启动命令、外部 URL、加密、日志和保护标志。Webhook 还要结合外部平台审计，因为 URL、签名秘密和投递历史可能完全不出现在 CloudTrail。

报告记录的高权限应用用户构成另一类独立分支。它们可能存于业务数据库或身份服务，登录、提权、MFA、密码重置、API token、OAuth client、邀请和会话证据都在应用侧；如果只清查 AWS IAM，攻击者仍可能通过看似正常的管理入口导出数据、创建集成或再次触发云端部署。

部署来源和应用身份共同说明了为什么事件不能在“云密钥已删”处结束。可信性必须沿提交、批准、runner、依赖、构建、摘要、签名、部署与运行资源连续成立，同时把应用管理员创建的用户、令牌、webhook、导出任务和云集成全部视为后代。任何一环仍由事件窗口内的身份或制品控制，分叉就仍然活着。

4.4 以勒索为目的的攻击把可逆云配置变成施压筹码

Sygnia 将攻击目标明确描述为经济利益驱动：取得足够的云基础设施控制权，把它转化为勒索筹码。在没有传统本地勒索软件加密器直接对应物的云环境里，攻击者主要用可逆动作展示这种控制力：拒绝 S3 访问，将 ECS service 或 container 的 maximum capacity 降至零，创建阻断流量的网络 ACL 规则，以及 purge SQS queue。

“可逆”描述配置能被恢复，不代表数据和业务没有损失。SQS purge 会永久删除当时可见消息，ECS 停止可能导致请求失败和状态丢失，ACL 阻断会中断依赖，S3 拒绝可能阻塞备份与恢复。每个动作都要评估下游一致性与补偿。

调查要保存变更前后配置、CloudTrail 事件、主体、accessKeyId、请求参数、来源、用户代理和请求 ID。自动伸缩还要同时检查服务期望容量、Application Auto Scaling 的可伸缩目标、上下限和策略；只恢复一个值，可能很快被另一控制器再次覆盖。

恢复顺序是先阻断攻击身份，再从可信配置恢复。若先改回容量，而泄露密钥仍然有效，攻击者可以立即重复操作。网络与 IAM 隔离、会话撤销、密钥轮换、策略恢复和服务重启，必须纳入同一个指挥序列。

预防控制可对关键队列 purge、生产 service 缩零、安全边界 ACL、bucket policy 与 KMS policy 建立审批、告警和显式 deny。Break-glass role 单独保管并测试恢复。配置备份必须存放在攻击身份无法修改的账户或不可变位置。

用于狩猎的 API 名称只能视为可能的控制位置，不能写成 Sygnia 未公开原始事件里的既定事实。ECS 影响可能涉及 UpdateService 或 Application Auto Scaling 目标；网络阻断可能涉及网络 ACL 条目的创建或替换；存储桶拒绝可能位于桶、访问点、ACL 或 KMS 策略；队列影响则围绕 PurgeQueue。调查应检索完整的服务变更族和最终状态，不能从业务描述擅自反推唯一的方法名。

SQS 清空尤其紧急：恢复权限或重建队列，都找不回已经删除的可用消息和处理中消息，最长约 60 秒的处理窗口还可能吞掉新消息。应保存队列 URL 与 ARN、死信队列和 redrive 配置、生产者、消费者、检查点与清空事件，必要时暂停生产者。死信队列不是源队列的备份；恢复必须依赖独立账本或业务事件做幂等重放与对账，并明确无法恢复的损失窗口。

ECS 恢复要同时检查期望容量、可伸缩目标、定时扩缩容、部署配置、容量提供者和外部控制器；网络恢复要把 ACL 与路由、安全组、防火墙、负载均衡器和主机规则放在一起比较；S3 则要先保存策略、ACL、访问点、公共访问阻断、KMS 与 VPC 端点策略，再恢复最小的可信差异。三者都应在攻击身份被阻断后，用金丝雀实例或指定恢复主体验证，不能直接覆盖当前状态。

每条影响分支最终都要由业务结果关闭：队列要对账消息与交易，ECS 要验证容量、健康、请求和状态，网络路径要双向验证依赖，S3 要确认授权应用可以读取正确版本且访问范围没有扩大。API 返回“配置修改成功”，只是恢复的起点。

5 CloudTrail 的一条事件只有放回身份、会话、资源和后续调用中才成为证据链

核心字段包括 eventVersion、userIdentity、eventTime、eventSource、eventName、awsRegion、sourceIPAddress、userAgent、requestParameters、responseElements、requestID、eventID、readOnly、资源与错误。不同服务可能省略或截断字段，解析器要保留原始 JSON。

userIdentity 区分 IAM 用户、assumed role、AWS 服务、联合身份与根账户。对临时会话，沿 sessionContext.sessionIssuer、principalId、ARN、会话名、MFA 与来源身份回到签发主体；对长期密钥，则由 accessKeyId 直接关联多账户事件。

sourceIPAddress 可能是代理、AWS 服务、NAT 或 VPC endpoint；userAgent 可被伪造，也可能被 SDK 统一。它们适合聚类，不能单独归因。与凭据、API 序列、批准自动化和网络日志合并后，同源同客户端指纹的意义才稳定。

管理事件无法覆盖所有数据访问。S3 对象、Lambda、数据库 SQL、代码托管、CI runner 和应用用户，需要各自的数据事件或平台日志。组织应在事件发生前明确：哪些关键资产开启细粒度记录，日志保留多久，集中到哪个隔离账户，以及多久以后可以查询。

为每条调查事件生成规范键：账户、区域、eventID、requestID、主体、访问密钥或会话、资源、来源和时间。原始事件保留不动，只在派生表中做规范化。这样多团队可以共享连接字段，也不会把某个 SIEM 的展示名称误当成 AWS 原始事实。

解释 CloudTrail 结构时，要同时考虑事件版本与类别；字段缺失可能是本来不适用、服务未提供，或被大小限制截断。应保存原始记录、投递对象及其哈希和解析器版本。管理事件、数据事件、网络活动事件与数据库审计回答的是不同问题，Event history 也不能替代组织级投递日志。每次查询都要记录类别、selector、区域、资源、保留期、时间窗、查询文本和结果哈希。

时间模型要保留原始时间戳、换算后的 UTC、时钟偏差和查询余量。同一时间戳的记录不能按显示行序强行排序，需要结合请求 ID、会话签发、资源版本、进程祖先关系和首次使用来建立因果。“未观察到”还必须附带覆盖声明：例如某个 S3 存储桶或前缀若没有覆盖全时段的读取数据事件、健康投递和完整保留，结论只能是“在可用证据中未发现”，随后明确盲区。

5.1 证据链沿每一轮凭据扩张，从应用入口一直追到业务结果

证据链从互联网应用的请求、路由、版本、实例和密钥暴露位置开始，接到该 accessKeyId 在 AWS 的首次使用；随后只在出现新事实时增加层级：秘密读取与新身份首次使用、IAM 或运行时持久化、部署与应用身份变化，以及 RDS、S3、ECS、ACL、SQS 等数据或业务结果。

节点使用稳定案件 ID：AWS 身份保存账户、分区、主体 ID、ARN、会话、签发方与有效期；对象保存 ARN、键和版本；制品保存提交或摘要。每条边带来源、时间和置信，明确区分“有权读取”“确认读取”“已经签发”“已经部署”与仅凭时间、来源得到的分析关联。

图既从入口向下寻找影响半径，也从数据库、部署角色和其他关键资产向上寻找祖先。缺边意味着日志所有者和下一项查询，不代表可以用合理想象补齐；若旧值在记录的失效时间以后仍成功认证，矛盾本身就重新打开分支，要求检查活动版本、会话、时钟和签发方。

这张图把不可逆转折画了出来：一旦子身份在另一个平台首次成功使用，它就获得独立时间线，父 key 的沉默不能替它作结。此后的时限、检测和验收都沿这些泳道推进；把入口 key 当成唯一对象，会把仍在活动的分支误写成已经结束。

5.2 隔离、轮换、重建与恢复必须按同一顺序协同推进

控制顺序已经明确；到了执行阶段，难点变成不同分支如何同时推进而不互相破坏。证据团队保存日志、快照、进程、任务、配置和制品，控制团队按既定手册处理身份与网络；两边共享变更 ID，并记录执行者、时间、旧值、新值和验证结果。

局部先后由实时风险决定。正在删除数据的身份优先被截断；已完成网络隔离、又保存唯一 shell 证据的工作负载可以在短暂采集后替换。应急显式拒绝只针对失守主体、签发时段、不可信路径或破坏性动作，并豁免独立响应身份，以免把日志和恢复能力一起封住。

身份图为每条分支维护七个状态：签发源、子会话、CI、运行时、消费者、可信制品和旧路径。它们分别标为完成、在途、例外或未知；某个平台显示绿色，不能替另一个平台结案。宽范围控制还要有经测试的回退路线，业务例外则写明精确资源、负责人、短失效时间与额外监控。

分支验收同时看技术与业务结果：旧认证与刷新路径失败，替代运行时通过完整性和健康检查，未经批准的制品无法发布，队列完成对账，数据库完成身份、查询和数据核验。控制面 API 返回成功，只证明请求被接受；攻击路径与服务结果都关闭，才证明这条身份分叉真正收敛。

5.3 身份、时间与并发把一枚密钥展开成可查询的凭据家族

长期 access key 调用 AssumeRole 后会得到另一个 access key ID，后续 userIdentity.type 也变成 AssumedRole。只检索入口 key，会在这条边界上看见活动突然“消失”；真正发生的是身份换了标识，并在新的会话期限里继续。

每条角色承担关系都保存请求者、目标角色 ARN、来源身份、external ID 条件、会话策略、标签、时长、源 IP 和返回的临时 key。调用者可自行填写的会话名只能用于检索，主体 ID、签发事件和 sessionContext.sessionIssuer 才能证明父子关系。

有些分叉并不直接经过一条 AssumeRole：任务定义、实例配置文件、信任策略或 CI OIDC 工作流被修改以后，合法服务会替攻击者发行新会话。此时父边是配置写入，子边才是服务签发；身份事件与资源版本必须放在同一图里。

“签发源已禁用”和“全部派生会话及刷新路径已结束”是两个不同时间。只有签发时间、最长时长和签发方已知，且任务、实例、CI 或联合身份无法再刷新时，会话到期才具有关闭意义；会话表因此同时记录发行、最后使用、终止或到期、临时拒绝与信任修复。

5.4 配置、运行时、流水线和数据证据共同证明环境改过什么、恢复了什么

CloudTrail 的 requestParameters 可能省略大字段，响应也未必包含最终状态；配置判断因此使用事件前可信值、事件中攻击者或不确定值、批准后恢复值三方比较。AWS Config、服务版本、IaC 状态、资源标签和独立导出补足 API 记录，避免从方法名直接猜业务影响。

比较落到真正改变行为的版本：IAM 策略与信任、key、安全组与 NACL、路由、ECS 任务修订、启动模板、Lambda 哈希、S3 与 KMS 策略、SQS redrive、webhook、日志 selector 和安全服务。Config 覆盖不足或历史缺失时，从日志、备份、制品和资源负责人交叉恢复，并把无法复原的区间留在结论中。

防守动作必须与攻击者变化分开。独立响应角色、会话标签和变更 ID 记录每次应急操作的旧值、新值、时间与原因；共享管理员或无标签脚本会把两条时间线混在一起。日志、Config、GuardDuty、Security Hub、保留期、KMS 与告警路由则单独保护，因为它们决定其余结论能有多高置信。

恢复后的漂移监控比较语义而非字节：策略重排可能等价，一个通配符却会扩大权限。IaC 与实际资源重新收敛以后，主体、动作、资源、条件、网络路径、可执行内容、摘要与安全覆盖持续受检；手工例外带负责人、原因、到期与补偿观察，不能悄悄成为下一份可信基线。

6 前六十分钟的目标是阻止第二枚密钥继续生长，同时保住最易失的证据

确认告警后立即建立事件指挥，明确云身份、网络、CI/CD、取证、数据库、应用和业务负责人。第一张种子记录只写已知事实：密钥 ID、主体、账户、来源、首次与最后活动、当前调用，以及它已经连接出的子身份；指挥命令另写范围、负责人、例外、持续时间、回退与验证，不能与调查结论混在一起。

组织级 CloudTrail、IAM 凭据报告、Config 快照、应用部署与日志、runner 作业、仓库审计、数据库会话和 ECS/EC2 清单同步进入独立安全账户。易失任务、实例、进程和网络状态在风险允许时先采集；所有团队使用同一 UTC 窗口、案件 ID、原生标识和证据位置，并按上一节的既定处置顺序执行控制。

六十分钟节点不追求完整叙事，只回答攻击动量：还有多少未知身份能够认证，多少可疑工作负载能够出网，流水线能否发布，签发方能否继续生成会话，破坏性动作是否仍可到达。输出同时列出入口、活跃身份与账户、正在发生的敏感动作、证据盲区、业务影响和下一个决策点。

6.1 一到六小时要把入口密钥变成完整身份族，并让高价值轮换与隔离开始落地

跨账户和区域查询把 STS、IAM、托管秘密、S3、EC2、ECS、RDS、网络、日志与部署事件接到所有种子上。活动按 key 与会话分泳道，标记首次秘密读取、子身份首次使用、持久化、数据动作和影响；来源与 user-agent 只在排除登记自动化后参与聚类，避免共享出口替身份关系作证。

账本按外部可用性、权限、生产用途、签名或部署权和数据触达排序。六小时节点直接显示每条高价值分支的七项状态：签发源、子会话、CI、运行时、消费者、可信制品和旧路径分别完成、在途、例外还是未知。

节点报告为每个账户、平台和关键资产列日志覆盖、最后活动、数据层级、当前控制、业务状态、负责人和下一项证据。只要未知身份仍能认证、出网、发布、创建身份或查询数据，攻击动量就没有被压住；法律与合规只接收确认读取、成功查询及其证据限制，不把理论权限写成既成影响。

6.2 六到二十四小时开始从“阻断活动”转向“证明哪些信任仍然成立”

范围矩阵在账户、身份、秘密、工作负载、仓库、runner、制品、数据库和应用用户之间双向检查：从每个失守身份向下寻找资源与后代，也从关键资产向上寻找主体、资源策略、网络路径、部署机制和凭据。尚未覆盖的平台必须保留负责人和完成时间，不能从摘要里消失。

数据集分别记录技术可达、成功查询或读取、已返回进程、已经传输或被其他方式使用四个层级；配置和制品则比较事件前可信状态、事件中状态与恢复状态。旧 key、旧会话、未知摘要、异常 SQL 或新 webhook 只要再次成功，就重新打开对应分支，时间进入第二天并不会自动降低它的风险。

二十四小时报告列事实、置信、盲区、剩余活跃分支、业务状态与可信恢复进度，并写明哪些新事实会改变重大决策，例如签名身份失守、原本不可达的生产账户被承担、出现第二入口，或关键对象没有数据事件。AI 辅助仍是速度背景，隔离和恢复范围由身份、资源与数据证据决定。

6.3 二十四到七十二小时的任务是收敛残留持久化，并让恢复环境拥有新的可证明基线

每条身份分支到此进入四种状态之一：签发源失活且所有子会话与刷新路径关闭；在限时业务例外和补偿控制下仍有效；有证据证明相关时段始终不可达；或尚未解决但已有负责人、隔离和期限。“不再出现”不是第五种状态，因为活动可能暂停，日志也可能不完整。

制品同样分成阻断集合与可信集合。前者包含事件窗口内或来源未知的镜像、软件包、runner、模板、脚本、提交和签名；后者固定经过复核的源码、构建环境、依赖、签名身份、摘要和部署记录。账户、联合身份、角色、用户、策略、信任、资源策略与高权应用用户则同恢复基线逐一比较，陌生对象必须补齐来源或退出环境。

七十二小时只是与攻击扩张速度对照的响应基准，不是自动结案点。数据影响、第三方协调、长期重建与法律工作可以继续；但任何未参与早期响应的人，都应能从一条身份、制品、数据库或影响记录回放到它的范围、当前状态和关闭证据。依赖口头记忆的“已恢复”不具备可复核性。

7 检测矩阵把每个攻击波拆成可组合信号，避免寻找一个不存在的“AI 攻击特征”

身份发现信号包括新来源的 GetCallerIdentity、跨区域列表、IAM 或 Organizations 枚举和密集拒绝；秘密收集表现为短窗口内横跨 Secrets Manager、SSM、S3、runner、数据库与工作负载环境的访问；身份扩张则落在 AssumeRole、新 user、新 key、信任和策略写入。检测器先识别这些原子事件，再按父会话、资源与时间连接分叉。

持久化信号覆盖 EC2/ECS 命令与出网、任务或启动模板、未知镜像、启动机制、工作流、webhook、部署脚本和应用管理员；数据与影响信号覆盖新来源 SQL、对象读取、S3 或 KMS 拒绝、ECS 缩零、NACL 阻断、SQS 清空及日志或备份变化。每次状态修改尽量保留旧值与新值。

编排分析在短窗口里统计 key、账户、敏感 API、来源、客户端和重复动作序列，优先考虑身份关系与状态变化，而不是请求总量。稳定备份角色的大量读取可能低于一枚新 key 读取部署秘密并创建高权身份；同源同客户端也只有在排除登记自动化、共享 NAT 与代理后才增加权重，规则名称不直接宣称 AI。

误报排除依赖专用角色、固定流水线、已知仓库、受限 API、批准变更和可预测计划的完整上下文，不能只维护 IP 白名单。账户停止投递、selector 漏掉关键存储桶、数据库或 runner 审计积压、安全账户无法解密日志，同样应作为覆盖故障告警。

告警自动补充有效权限、key 年龄和最后使用、账户负责人、资源重要性、相邻秘密读取、子会话与批准变更。低置信度自动化只执行可逆、窄范围、保全证据的控制，并用独立响应身份记录前后状态、幂等与回退；大范围或破坏性操作仍需明确批准。

7.1 检测与身份护栏让每次凭据转换都可见、可被立即截断

根账户和日常 IAM user 不保留长期 key；员工使用联合身份或 IAM Identity Center，工作负载使用角色，CI 使用 OIDC。管理会话要求强 MFA、受管设备或可信网络，并按任务设定期限；生产、预生产、CI 与运维身份彼此分离。

策略从实际访问生成最小权限，并用资源 ARN、区域、标签、来源 VPC、组织和会话属性收紧条件。部署角色不能任意读 secret，secret 读取角色不能修改 IAM，日志角色不能管理工作负载；iam:PassRole、信任修改、策略版本、服务部署和资源策略也纳入委托边界。

身份架构本身应显示来源：人工联合身份、CI OIDC、工作负载角色和应急管理使用不同角色族、sourceIdentity 与会话标签。Access Analyzer、凭据报告、最后访问和关系图持续发现外部信任、共享身份、旧 key 与未使用权限，结果以权限真正减少而不是报告数量衡量。

秘密治理只衡量实际落地的副本、无人负责的消费者、长期有效期、环境变量注入和仓库或对象发现，目标是副本更少、有效期更短、消费者可见。第三方静态凭据无法消除时集中保管，限制来源与权限，并尽量通过隔离代理把内部调用重新变成短期身份。

护栏拒绝也必须可见。创建 key、削弱日志、清空队列或把生产容量归零的失败请求应生成包含主体和变更上下文的案件；SCP、权限、告警和应急恢复一起设计并演练，避免一条静默拒绝既封住救援路径，又让另一条攻击路径无人知晓。

7.2 演练与指标检验团队能否在一小时内截断攻击波

场景从生产应用 key 在陌生来源出现开始：十分钟后出现托管 secret 读取，二十分钟后出现第二账户 key，三十分钟后出现 runner 变化与 RDS 查询，四十分钟后 ECS 容量归零。第二身份出现的那一刻就是考题：团队是否立即承认故事已经分叉，并把查询与指挥范围扩到新平台。

沙箱账户生成真实但无害的 CloudTrail 事件，用来测中央摄取、查询和告警延迟；同时注入 S3 数据事件缺口、时钟偏差、共享 NAT、未知消费者、被改过的 IaC 和业务拒绝暂停发布。事件指挥要在证据不完整时说明置信、权限阈值、例外与补偿控制。

指标并列记录攻击者转换时间与防守者响应时间：从秘密读取到子身份首次使用，再到发现该身份、拒绝其活动并查找后代。节点还包括跨账户范围、可信金丝雀、数据分层判断和证据包完成；指标的意义是暴露哪一处日志、权限、自动化、所有权或决策链慢于身份分叉。

复盘把每个未达目标交给具体负责人和复测日期。“提高可见性”不是动作；为指定存储桶开启读取数据事件、集中指定账户、设定数据库审计保留并验证保存查询，才是可验收改进。下一次演练先检查这些措施是否真的缩短了相同时间段。

8 服务负责人收到事件通知后，应在三十分钟内交付一份可执行的身份与数据清单

三十分钟交付物不是现场重写架构文档，而是服务目录里已经维护、收到通知后只需确认现状的最小可靠包。如果四条身份泳道正在活动，负责人还要第一次登录控制台寻找资源，组织已经把速度优势交给了攻击者。

以 ECS 上的支付 API 为例，身份记录写明生产账户、任务与执行角色 ARN、任务定义修订、OIDC 部署角色、最长会话时间、精确可达的 Secrets Manager 与 S3 资源，以及人工负责人和独立响应角色。“服务使用 IAM”无法回答一枚 key 能否继续变成数据库或部署身份。

秘密记录保存 ARN、版本阶段、真实签发方、目标数据库用户或外部 API、消费者、启动注入方式和旧会话结束条件，不含明文；制品记录固定源码分支、工作流、runner、依赖、摘要、签名、IaC、部署控制器与最后可信提交。未知消费者或构建环节必须带查询、临时限制、负责人和期限。

数据记录列出 RDS、S3、SQS、缓存、分析副本与外部处理方的分类、审计、selector、保留、查询人、正常身份、备份或重放和业务对账。缺少 SQL 或对象级日志时，限制与替代证据同记录出现，不能在摘要里被“暂无异常”抹去。

这些记录形成一条可执行依赖链：角色指向 secret，secret 指向外部身份，工作流指向部署权，制品指向运行资源，数据图指向业务影响；每一行都有主备负责人、值班路径、升级权限，以及经过非生产演练的响应工作流链接。扁平资产表无法在常规负责人缺席时支撑分叉事件。

1. 交付身份表。列出生产、预生产、CI 与运维的精确 ARN、账户、策略、凭据来源、会话时长和负责人。
2. 交付秘密与消费者表。列出每份秘密的标识、签发方、消费者、重启要求、轮换顺序和旧会话处理。
3. 交付可信制品链。固定仓库、受保护分支、工作流、runner、镜像摘要、签名、IaC 与最后可信提交。
4. 交付数据与日志范围。说明 RDS、S3、SQS 和外部数据的审计、保留、分类、查询人与恢复方式。
5. 交付经演练的处置入口。链接批准工作流、所需权限、批准人、业务影响、回退和验证记录。

只有事件团队任选一行都能执行下一步，而不必再追问标识是什么、权限在哪里、成功怎样验证，服务负责人的交接才算完成。前置内容应控制在几页易读页面内，并链接到更深层证据；A4 打印时也不能把长标识压成难辨的小字。密集的机器导出可以放在后面，前几页首先是一张可执行的操作地图。

8.1 最终证据包应能独立重放范围、恢复与运营闭环

证据目录包括入口应用日志与版本、CloudTrail 原始事件和查询、身份关系图、凭据报告、Config 历史、secret 账本、runner 与代码审计、制品摘要和签名、运行时取证、数据库审计、网络记录及全部防守变更。

每份文件记录来源、采集者、时间、时区、工具、哈希、访问控制与处理历史；派生表链接原始 eventID / requestID，图中的边能回到日志。分享副本脱敏，原件留在受控证据库；无法重放的结论只能补证或降低置信。

复核先从一条已经分叉的身份开始，沿父级事件追到首次使用、权限、持久化或数据动作，再核对签发方、最后使用、当前状态和刷新路径；另取一条部署变化，从提交、runner、依赖、摘要、签名追到部署与运行资源。两条样本共同验证身份关系和制品来源是否真正闭合。

影响分支同时检查控制面、数据面和业务层。SQS 清空等不可逆结果只能通过重放、对账和明确接受残余损失来关闭；仍未知的部分写明缺失来源、替代证据、补偿控制、负责人和重开条件，安静仪表盘不能替代结论。

真正的结案指标，是身份树停止生长：旧身份和未知身份不能认证，失守签发方不能再产生替代身份，不可信流水线不能发布，可疑工作负载不能刷新角色或出网，休眠制品不能部署，未知高权应用用户与资源信任也已消失。四账户同秒活动解释了分叉速度，AI 辅助解释了编排背景；最终能够交付的，仍是任何独立读者都能从第一枚 key 追到每条关闭分支的证据。