Atlas-ghostshell/GuardDuty-CloudTrail-Threat-Detection-IR

# GuardDuty-CloudTrail-威胁检测-IR ## 概述 第 11 周的内容是证明某个控制措施存在且配置正确——审计一个存储桶，读取一个密钥策略，确认已启用加密。第 12 周则是完全不同类型的工作。它以一个控制措施已经失效为前提，提出了一个更难的问题：仅凭一个 GuardDuty finding，你能否准确还原发生的一切，在不破坏证据的情况下对其进行遏制，并留下有理有据的记录来闭环？这种转变——从审计配置到还原事件——正是本周的核心主题，并体现在这里的每份 runbook 中。 有三个 finding 构成了这个仓库的基础，刻意选择它们是为了说明这*并非*同一主题的简单变体。一个是被盗的 IAM 凭证完全脱离了 AWS 的网络。一个是没有任何恶意 IP 的机器学习异常。还有一个是 GPU 实例静默解析了某个矿池域名。每一个都迫使使用不同的关联字段、不同的数据源，而且——在某一个案例中——对本能的第一反应进行了彻底的反转。接下来的内容是将这三者联系起来的关联方法论，以及由此产出的三份含有完整证据的 runbook。 ## 架构 — 检测到证据的流水线 ``` ┌─────────────────────────┐ │ Amazon GuardDuty │ │ (ML + Threat Intel) │ └────────────┬────────────┘ │ finding.service.action.actionType │ determines correlation path ▼ ┌────────────────────────┼────────────────────────┐ │ │ │ ▼ ▼ ▼ AWS_API_CALL DNS_REQUEST (S3 data events + │ │ ML baseline) ▼ ▼ ▼ ┌─────────────┐ ┌───────────────┐ ┌──────────────────┐ │ CloudTrail │ │ VPC DNS Query │ │ CloudTrail S3 │ │ Mgmt Events │ │ Logs │ │ Data Events │ └──────┬──────┘ └───────┬───────┘ └────────┬──────────┘ │ │ │ │ ▼ │ │ ┌───────────────┐ │ │ │ VPC Flow Logs │ │ │ │ (connection │ │ │ │ confirmation)│ │ │ └───────┬───────┘ │ │ │ │ ▼ ▼ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Preserve → Contain → Investigate → │ │ Remediate → Recover → Document │ └──────────────────────────────────────────────────────────────┘ ``` ## 已部署的服务 ### Amazon GuardDuty | 组件 | 配置 | |---|---| | 探测器 | 单个探测器，us-east-1 | | 保护计划 | 启用 S3 Protection（Exfiltration:S3 finding 所必需） | | Finding 生成 | 实时 finding（Runbook 1）+ AWS 示例 finding（Runbook 2 和 3，通过 `create-sample-findings` 生成） | ### Amazon CloudTrail 管理事件用于关联源自 `AWS_API_CALL` 的 finding；S3 数据事件用于独立验证基于异常的 finding，以对比 GuardDuty 自身的结论。 ### VPC DNS 查询日志记录 & VPC Flow Logs 两个独立的、分别启用的日志源——任何一个都无法替代另一个，而且 GuardDuty 本身检测底层活动也并不要求必须启用它们。本周，当它们的启用日期晚于 finding 的 `EventFirstSeen` 时，两者都成为了盲区，这成为了本仓库中反复出现且被记录在案的控制缺口。  ## 实时证据 — 三个 Finding，三种调查姿态 ### Finding 1 — UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS 一个 EC2 实例角色的临时 STS 凭证被完全用于 AWS 网络之外——这是始于实例元数据服务（IMDS）的被盗凭证链的典型特征。该 finding 携带的是一个 `ASIA` 前缀的访问密钥，而不是长期有效的密钥，这立即使得情况变得棘手：标准的 `iam update-access-key` 遏制命令不适用于会话 token，使用它们只会产生虚假的安全感，而不是实际的遏制效果。 ``` Finding ID: fecf49a7f93096a1ebef48fcc8f380b8 Severity: 8 (HIGH) Principal: atlas-admin-ec2-role (AssumedRole) Actor IP: 102.0.31.100 — Nairobi, Kenya (Airtel Kenya) API Called: iam:ListUsers Error Code: (blank — call succeeded) ```  **完整 IR Runbook：** 针对此 finding 的完整且含有详尽证据的应急响应 runbook ——涵盖从保留到恢复，每一步都包含准确的命令和理由——可在此处获取：[IR Runbook — IAM 凭证外泄](screenshots/IR_Runbook_UnauthorizedAccess_IAMUser_InstanceCredentialExfiltration.pdf) 这里的遏制措施使用的是直接附加到角色上的、基于 `TokenIssueTime` 条件的 Deny 策略，而不是密钥禁用命令——这是用于撤销活动会话而非静态凭证的正确机制。根本原因追溯到源实例上允许使用 IMDSv1，通过在实例和整个账号范围内强制执行 IMDSv2 来修复。 ### Finding 2 — Exfiltration:S3/AnomalousBehavior 没有恶意 IP。没有已知的恶意特征。这个 finding 纯粹是基于机器学习基线偏差触发的——某个 IAM 身份的 S3 活动严重偏离了其自身的历史画像，从而触发了 GuardDuty 的异常检测模型。缺乏一个明确的“是的，这是恶意的”信号，正是这个 finding的核心所在，它迫使采用一种截然不同的调查姿态：runbook 在执行任何不可逆的修复步骤之前，必须先*确认意图*。 ``` Finding ID: e5532205a85841c793fd8d3835e341b9 Severity: 8 (HIGH) UserType: IAMUser (long-lived credential, not an assumed role) Error Code: AccessDenied (on the recorded call — other anomalous calls in the same finding were NOT all denied) ```  **完整 IR Runbook：** 针对此 finding 的完整且含有详尽证据的应急响应 runbook——包括双路径修复决策树——可在此处获取：[IR Runbook — S3 异常行为](screenshots/IR_Runbook_Exfiltration_S3_AnomalousBehavior.pdf) 此处的遏制措施是刻意设计为可逆的——一个仅作用于单一主体和存储桶的紧急 Deny 存储桶策略，而不是全账号范围的锁定——因为与 Finding 1 不同，目前还不能确定这就是恶意行为。根据调查（Investigate）实际发现的情况，runbook 会分支进入两条完整的修复路径。 ### Finding 3 — CryptoCurrency:EC2/BitcoinTool.B!DNS 一个 GPU 加速的 `p2.xlarge` 实例解析了一个域名，并且该域名被 AWS 威胁情报独立确认与加密货币挖矿池基础设施有关。这是三个 finding 中唯一一个受损的*资产*是计算资源本身，而不是凭证或数据存储的案例——仅此一点就完全重写了其遏制理念。 ``` Finding ID: eb04c83b414147e984a5181d2b0d5550 Severity: 8 (HIGH) Instance Type: p2.xlarge (GPU-accelerated — not incidental) Action Type: DNS_REQUEST Blocked: false (the query resolved successfully) ```  **完整 IR Runbook：** 针对此 finding 的完整且含有详尽证据的应急响应 runbook——包括实时易失性证据捕获以及 NACL+SG 遏制推理——可在此处获取：[IR Runbook — CryptoCurrency EC2 DNS](screenshots/IR_Runbook_CryptoCurrency_EC2_BitcoinTool.pdf) 本能的第一反应——停止实例——是错误的。停止或终止实例会破坏实时的进程表、活动的网络连接和 GPU 利用率数据，而这些正是此处的实际证据。因此，遏制措施转而使用隔离安全组*加上*一条 NACL 拒绝规则，因为仅更改安全组并不会中断已经建立的连接——这是一个直接对照 AWS 官方网络文档确认过的盲区，而不是凭空假设的。 ## 完整关联模型 ``` ┌────────────────┬──────────────────┬───────────────────┬────────────────────────┐ │ Finding's │ Correlation │ What's │ Correct Containment │ │ ActionType │ Data Source │ Compromised │ Mechanism │ ├────────────────┼──────────────────┼───────────────────┼────────────────────────┤ │ AWS_API_CALL │ CloudTrail │ Identity / │ Key disable (AKIA) or │ │ │ Mgmt Events │ credential │ TokenIssueTime Deny │ │ │ │ │ policy (ASIA session) │ ├────────────────┼──────────────────┼───────────────────┼────────────────────────┤ │ DNS_REQUEST │ VPC DNS Query │ Compute / │ Quarantine SG + NACL │ │ │ Logs → then │ instance │ deny (SG alone does NOT │ │ │ VPC Flow Logs │ │ cut an established │ │ │ │ │ connection) │ ├────────────────┼──────────────────┼───────────────────┼────────────────────────┤ │ (ML anomaly, │ CloudTrail S3 │ Data / access │ Reversible bucket-level │ │ no fixed │ Data Events │ pattern │ Deny — intent unproven │ │ action type) │ │ │ until Investigate closes │ └────────────────┴──────────────────┴───────────────────┴────────────────────────┘ Network-layer controls (SG / NACL / WAF) protect resources inside the VPC. Identity-layer controls (IAM policy conditions / key state) protect the control plane. A finding's ActionType tells you which side you're on before you touch anything. ``` ## 核心概念锚点 - **Action 类型决定了数据源，而不是反过来** — `AWS_API_CALL` → CloudTrail，`DNS_REQUEST` → VPC DNS 查询日志，`NETWORK_CONNECTION` → VPC Flow Logs。出于习惯在处理源自 DNS 的 finding 时去查看 CloudTrail，会浪费调查中最具时效性的第一步。 - **安全组的更改不会追溯中断已建立的连接。** 连接跟踪机制意味着，在移除允许规则后，现有会话可以持续数分钟——或者对于已建立的 TCP 连接，甚至可长达五天。NACL 是无状态的，会立即切断连接。任何需要保证切断活动会话的遏制步骤都需要这两层防护，缺一不可。 - **STS 会话凭证（`ASIA` 前缀）和长期有效的 IAM 密钥（`AKIA` 前缀）需要完全不同的遏制命令。** 禁用一个根本不是静态密钥的凭证，只会营造出已遏制的假象，而实际上没有任何实质效果。 - **GuardDuty 自身的检测通常独立于响应人员为了佐证而求助于的日志源。** S3 Protection、DNS 威胁关联和网络连接 finding 都依赖于 AWS 内部的遥测数据，无论账号自身的 CloudTrail/Flow Logs/DNS 查询日志记录是否启用，这些数据都存在——但*你自己的*、可独立查询的证据链完全取决于你何时开启了这些日志记录。三个独立的服务，本周却在它们身上得到了同一个教训。 - **严重性和置信度是两个相互独立的维度。** 较低置信度的 finding 依然要在其完整的基于严重程度的 SLA 内进行调查——置信度影响的是拥挤队列中的优先级排序，而不是决定这项工作是否要进行。 ## 使用的 AWS 服务 - **Amazon GuardDuty** — 跨身份、网络和 DNS 遥测数据的威胁检测；本仓库中所有三个 finding 的来源 - **AWS CloudTrail** — 管理事件和 S3 数据事件记录；三个 finding 中有两个的主要关联来源 - **VPC DNS 查询日志记录 (Route 53 Resolver)** — 用于加密货币挖矿 finding 的 DNS 层关联 - **VPC Flow Logs** — 网络层连接确认，用于验证 DNS 解析是否转化为了实际建立的会话 - **AWS Systems Manager Session Manager** — 用于在不停用网络状态的情况下，对疑似受损的实例进行实时易失性证据捕获 - **IAM** — 通过基于 `TokenIssueTime` 条件的 Deny 策略进行会话撤销；在所有三个 finding 中执行最小权限修复 ## AWS 云安全路线图的一部分 | 周 | 主题 | 状态 | |---|---|---| | 1–9 | 从基础到 IAM 权限提升 | 已完成 | | 10 | 网络安全 — WAF, Shield, VPC Flow Logs | 已完成 | | 11 | 数据保护 — KMS, S3 审计, Macie, Secrets 轮换 | 已完成 | | **12** | **威胁检测与 IR — GuardDuty + CloudTrail 关联，事件时间线，遏制手册** | **本仓库** | | 13 | 云漏洞评估 — Inspector, CSPM 概念, CIS AWS Benchmarks, Config 规则 | 即将推出 | *Geoffrey Muriuki Mwangi · [github.com/Atlas-Ghostshell](https://github.com/Atlas-Ghostshell) · [LinkedIn](https://linkedin.com/in/geoffrey-mwangi)*

标签：AMSI绕过, AWS, DPI, GuardDuty, 威胁检测, 库, 应急响应, 数字取证, 自动化脚本, 速率限制