Catheren/cloud-security-engineering-lab

GitHub: Catheren/cloud-security-engineering-lab

基于多账户 AWS 环境的 IAM 安全实验室,模拟真实凭证泄露攻击链并通过 Python 引擎分析 CloudTrail 日志实现行为检测。

Stars: 0 | Forks: 0

# AWS IAM 安全与云检测实验室 [![AWS](https://img.shields.io/badge/AWS-Multi--Account-FF9900?logo=amazon-aws&logoColor=white)](https://aws.amazon.com/) [![Python](https://img.shields.io/badge/Python-3.12-3776AB?logo=python&logoColor=white)](https://www.python.org/) [![CloudTrail](https://img.shields.io/badge/AWS-CloudTrail-FF9900?logo=amazon-aws&logoColor=white)](https://aws.amazon.com/cloudtrail/) [![MITRE ATT&CK](https://img.shields.io/badge/MITRE-ATT%26CK_Cloud-E31837)](https://attack.mitre.org/matrices/enterprise/cloud/) [![License](https://img.shields.io/badge/License-MIT-blue)](LICENSE) 一个围绕两个核心问题构建的 AWS 安全动手实验室:**基于 IAM 的攻击到底是如何运作的**,以及**你该如何检测它们**? 本项目搭建了一个包含 3 个账户的 AWS 环境(管理账户、安全账户、生产账户),模拟了真实的凭证泄露攻击链,并构建了一个 Python 检测引擎,通过分析 CloudTrail 日志来捕获每个阶段。该实验室不仅记录了构建的内容,还记录了每个决策背后的安全推理——包括那些揭示了系统如何崩溃的错误。 ## 展示内容 | 技能 | 实现方式 | |---|---| | 多账户 AWS 架构 | 包含 3 个账户的环境,在安全账户中进行集中化 CloudTrail 日志记录 | | IAM 安全设计 | 信任策略、最小权限、PassRole 滥用、跨账户 AssumeRole | | 攻击模拟 | 真实的 IAM 凭证泄露链:权限维持 → 提权 → 横向移动 → 防御规避 | | 检测工程 | Python 检测引擎,从 CloudTrail 事件中识别 5 种行为攻击模式 | | 日志分析 | CloudTrail JSON 解析器,提取并规范化与安全相关的字段 | | 事件响应 | 完整的 IR 模拟——IOC 识别、时间线重建、遏制与 remediation | | 安全推理 | 记录每种错误配置实际会导致什么后果的关键经验总结 | ## 环境架构 ``` Management Account │ Organization control plane · SCP management · no workloads │ ├── Security Account │ Centralized CloudTrail logs · Security investigations │ Cross-account AssumeRole → Production │ └── Production Account Simulated workloads · IAM experiments · Attack simulations ``` 安全账户不承载任何工作负载——其唯一目的是实现集中化可见性。CloudTrail 将所有账户的 API 事件聚合到这里。安全账户向生产账户 AssumeRole 以进行调查,绝不反向操作——这种模式确保了长期凭证永远不会跨越账户边界。 完整的设计文档请参见 [`docs/architecture-overview.md`](docs/architecture-overview.md) 和 [`docs/cross-account-access.md`](docs/cross-account-access.md)。 ## 攻击模拟 模拟的攻击者持有承包商账户的被泄露 IAM 凭证。该攻击并未利用 AWS 漏洞——它滥用了合法的 IAM 权限,这是真实云安全事件中最常见的模式。 ``` 1. CreateAccessKey Persistence — long-term access key created │ ▼ 2. AttachUserPolicy Privilege escalation — AdministratorAccess attached (AdministratorAccess) │ ▼ 3. AssumeRole Lateral movement — cross-account role assumption │ ▼ 4. StopLogging Defense evasion — CloudTrail logging disabled ``` 每个步骤都会生成一个 CloudTrail 事件。检测引擎旨在捕获整个序列,而不仅仅是单个事件。 ## 检测引擎 ### parser.py — 日志摄取 摄取原始的 CloudTrail JSON,并提取检测引擎所需的字段: | 字段 | 告知的信息 | |---|---| | `eventName` | 执行了什么操作 | | `eventTime` | 何时执行的 | | `sourceIPAddress` | 来源 IP | | `userIdentity` | 执行者是谁 | | `requestParameters` | 目标资源是什么 | | `errorCode` | 操作是成功还是被拒绝 | ### detections.py — 行为检测 对解析后的事件应用基于行为的规则。单一的 API 调用很少是恶意的——引擎会寻找表明凭证已泄露的序列和组合。 | 规则 | 触发条件 | 严重程度 | |---|---|---| | 提权 | 带有 `AdministratorAccess` 的 `AttachUserPolicy` | 严重 | | 权限维持 | 为任何用户执行 `CreateAccessKey` | 中 | | 横向移动 | 来自不受信任来源的 `AssumeRole` | 高 | | 防御规避 | `StopLogging` 或 `DeleteTrail` | 严重 | | 信息侦察 | 跨多个 IAM 操作的 `AccessDenied` 激增 | 低–中 | **检测输出示例:** ``` [CRITICAL] Privilege Escalation Detected Event: AttachUserPolicy Policy: AdministratorAccess User: contractor-temp [ALERT] Suspicious Role Assumption Event: AssumeRole Source IP: Untrusted ``` 完整的检测文档:[`detections/README.md`](detections/README.md) ## 关键安全经验总结 构建并故意破坏这个环境凸显了一些仅靠文档无法学到的深刻见解。完整的详细说明在 [`labs/IAM Security and multi-account Cloud setup/Key Learnings.md`](labs/IAM%20Security%20and%20multi-account%20Cloud%20setup/Key%20Learnings.md) 中。 **信任策略才是真正的安全边界——而不是权限策略。** 权限策略定义了身份可以做什么。信任策略定义了谁可以*成为*该身份。配置错误的信任策略(`"Principal": "*"`)允许任何人假设角色,而不管其权限有多小。这种区别经常被误解,也经常被利用。 **在打破隔离的攻击中,`iam:PassRole` 是最危险的权限。** PassRole 不直接授予权限——它授予的是将角色分配给你控制的 service 的能力。如果与 Lambda 或 EC2 创建权限结合使用,攻击者可以将管理员角色附加到自己拥有的 service 上,并以提升的权限执行操作。该权限孤立地看似乎无害;其实不然。 **S3 bucket 策略是保障日志记录完整性的安全执行层。** 在 bucket 策略明确允许 CloudTrail service principal、特定操作和限定路径(`AWSLogs/o-xxxxxxxxxx/*`)之前,CloudTrail 无法写入日志。如果没有这些,CloudTrail 会静默失败或仅记录部分日志。S3 bucket 策略不仅仅是访问控制——它是日志完整性强制执行的手段。 **IAM 定义了*可能*发生什么。CloudTrail 显示了*实际*发生了什么。** 两者都是必需的。没有 CloudTrail 的 IAM 为你提供了一个没有审计跟踪的权限模型。没有正确 IAM 的 CloudTrail 为你提供的是不受控访问的日志。两者协同工作。 **账户分离限制了爆炸半径。** 即使生产账户中的 IAM 完全被错误配置,安全账户的日志和控制依然完好无损。账户边界是严格的安全边界,而不是组织文件夹。 ## 运行实验室 ``` git clone https://github.com/Catheren/cloud-security-engineering-lab.git cd cloud-security-engineering-lab # 解析 CloudTrail 日志 python detections/parser.py # 针对已解析的事件运行检测引擎 python detections/detections.py ``` ## 仓库结构 ``` cloud-security-engineering-lab/ detections/ detections.py Behavioral detection engine — 5 IAM attack rules parser.py CloudTrail JSON parser and field normalizer README.md Full detection engineering documentation docs/ architecture-overview.md 3-account architecture and design cross-account-access.md Cross-account IAM access design labs/ IAM Security and multi-account Cloud setup/ IAM security and multi-account setup.md Step-by-step lab walkthrough Key Learnings.md Security insights from building and breaking the environment ``` ## 相关项目 - [`aws-security-posture`](https://github.com/Catheren/aws-security-posture) — 生产级的多账户安全架构,包含 GuardDuty、Security Hub、Config 和 Inspector - [`terraform-security-lab`](https://github.com/Catheren/terraform-security-lab) — IaC 安全扫描 pipeline,在每次 pull request 时强制执行安全门控
标签:AWS, DPI, IAM, PE 加载器, Web报告查看器, 库, 应急响应, 攻击模拟, 检测引擎, 漏洞探索, 逆向工具, 驱动签名利用