brick5k/Imperial-Cloud-Security-Lab

GitHub: brick5k/Imperial-Cloud-Security-Lab

一个基于 AWS 的云安全实验环境,通过 Terraform 自动化部署,完整模拟内部威胁攻击链并演示从检测到补救的事件响应全流程。

Stars: 0 | Forks: 0

# Imperial Cloud 安全实验室 - 内部威胁检测与响应 ## 概述 本项目是一个实战 AWS 云安全实验室,旨在模拟真实的内部威胁场景。该项目的目标不仅是部署云基础设施,而是贯穿整个安全生命周期: 1. 使用 Terraform 构建 AWS 环境 2. 配置日志记录和检测机制 3. 模拟恶意的内部人员活动 4. 使用 CloudTrail 调查该活动 5. 应用补救措施以遏制威胁 我创建这个项目是为了展示与云安全分析师角色直接相关的实用云安全技能,包括 AWS IAM 安全、日志记录、检测、调查和事件响应。 ## 项目目标 本实验室的主要目标是: - 使用 Terraform 构建 AWS 基础设施 - 创建基于 IAM 的真实内部威胁场景 - 生成可疑的命令行活动 - 在 CloudTrail 中审查日志 - 使用 GuardDuty 验证安全可见性 - 执行事件响应补救 ## 使用的技术 - AWS IAM - AWS EC2 - AWS VPC - AWS S3 - AWS CloudTrail - AWS GuardDuty - Terraform - AWS CLI - GitHub ## 环境概述 本实验室环境包括: - 一个名为 `Death-Star-VPC` 的自定义 VPC - 一个名为 `death-star-instance` 的 EC2 实例 - 一个名为 `imperial-cloudtrail` 的 CloudTrail 跟踪 - 一个用于存储日志的 S3 存储桶 - 用于威胁检测的 GuardDuty - 多个用于模拟环境中不同角色的 IAM 用户 实验室中的 IAM 用户: - `rogue-moff` — 内部威胁 / 权限过高的用户 - `rebel-hacker` — 由 rogue-moff 创建的恶意后门账户 - `stormtrooper-user` — 普通的低权限用户 - `Terraform-User` — 用于部署实验室的自动化账户 ## 步骤 1 - Terraform 初始化 我首先在项目目录中初始化 Terraform,以便 Terraform 能够下载 AWS provider 并为部署准备环境。 此步骤确认了 Terraform 已正确安装,并且项目目录已正确配置。 ![Terraform Init](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/6ed6371c05152145.png) ## 步骤 2 - 部署 EC2 实例 初始化 Terraform 后,我部署了将作为云实验室环境一部分的 EC2 实例。该实例被命名为 `death-star-instance`。 此截图显示 EC2 实例已在 AWS 中成功运行,确认基础设施部署按预期工作。 ![EC2 Instance](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/487420fa79152146.png) ## 步骤 3 - 创建权限过高的内部账户 我创建了 `rogue-moff` IAM 用户来模拟内部威胁。该用户被故意赋予了提升的权限,以便其能够执行危险的 IAM 操作,例如创建用户、附加策略和生成访问密钥。 此截图显示 `rogue-moff` 拥有管理权限,这是攻击场景的核心。 ![Rogue Moff Admin Permissions](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/6be83311a1152147.png) ## 步骤 4 - 建立基线正常用户 我还创建了一个名为 `stormtrooper-user` 的普通 IAM 用户,该用户没有任何提升的权限。该用户作为标准低权限账户应有的基线示例。 这种对比有助于突显为什么 `rogue-moff` 存在风险。 ![Stormtrooper User](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/e46933e671152148.png) ## 步骤 5 - Terraform 自动化账户 为了将基础设施部署与攻击模拟分开,我使用了一个 `Terraform-User` 账户进行自动化。该用户代表用于通过基础设施即代码部署环境的受信任账户。 这表明环境并非完全通过手动点击控制台构建的,而是使用了自动化。 ![Terraform User](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/bc0f85e852152149.png) ## 步骤 6 - 启用 CloudTrail 日志记录 启用 CloudTrail 是为了捕获整个 AWS 账户中的管理事件。这是实验室的关键部分,因为 CloudTrail 是调查攻击者行为的主要真实来源。 此截图显示 `imperial-cloudtrail` 跟踪已启用并处于活动配置状态。 ![CloudTrail Enabled](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/9ecfd4832b152150.png) ## 步骤 7 - GuardDuty 检测 GuardDuty 也作为实验室的一部分被启用,以提供托管威胁检测。虽然 GuardDuty 在此项目中并未对每一个可疑的 IAM 操作发出警报,但它仍然生成了与 root 凭证使用相关的发现。 这是一个重要的结论,因为它反映了一个现实世界的教训:安全团队不应仅仅依赖单一检测工具。 ![GuardDuty Finding](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/a2747a8ec1152152.png) ## 步骤 8 - S3 日志存储 CloudTrail 日志存储在 S3 存储桶中,以便集中保留事件供调查使用。这展示了环境中使用的日志记录管道。 ![S3 Log Bucket](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/52e5c8e342152154.png) ## 步骤 9 - VPC 部署 该项目还包括自定义网络组件。此截图显示了实验室中部署的 VPC。 通过超越单纯的 IAM 并增加云网络基础设施,这为环境增加了更多真实感。 ![Death Star VPC](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/c121b4c198152217.png) ## 步骤 10 - VPC 资源映射 此截图展示了更广泛的 VPC 架构,包括子网和支持网络资源。 这有助于记录环境布局,并表明该项目包含了架构规划,而不仅仅是安全监控。 ![VPC Architecture](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/79e4a19197152220.png) ## 步骤 11 - 内部威胁创建后门账户 为了模拟恶意的内部人员行为,我使用 AWS CLI 中的 `rogue-moff` 账户创建了一个名为 `rebel-hacker` 的后门账户,分配了强大的权限,并生成了凭证。 此截图非常重要,因为它展示了从命令行执行的攻击,这比仅仅使用 AWS 控制台更加真实。 ![Privilege Escalation via CLI](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/93e161227e152221.png) ### 为什么这很重要 这模拟了三种主要的攻击者行为: - 账户创建 - 权限提升 - 通过访问密钥实现持久化 ## 步骤 12 - 攻击者枚举 IAM 用户 创建后门账户后,我使用 `rebel-hacker` 账户从命令行枚举 IAM 用户。 这模拟了攻击者试图映射环境并识别其他用户(包括特权账户和自动化账户)的行为。 ![User Enumeration](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/049e2f89e2152222.png) ## 步骤 13 - 攻击者枚举 IAM 角色 攻击者工作流程的下一步是 IAM 角色枚举。这是一个现实的后续行动,因为攻击者在获得访问权限后通常会寻找权限提升路径或高价值目标。 ![Role Enumeration](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/44a5545952152223.png) ## 步骤 14 - CloudTrail 调查攻击者活动 在生成攻击者活动之后,我在 CloudTrail 中调查了 `rebel-hacker` 账户。此截图显示了捕获到的可疑 API 操作序列,包括身份检查和枚举活动。 这是项目中最重要的截图之一,因为它展示了云安全分析师将如何使用审计日志验证可疑活动。 ![CloudTrail Rogue User Activity](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/38f69e7070152224.png) ### 观察到的事件 - `GetCallerIdentity` - `ListUsers` - `ListRoles` - `DescribeInstances` 这些行为与初始访问后的侦察行为一致。 ## 步骤 15 - CloudTrail 调查权限提升 我还审查了与 `rogue-moff` 账户相关的 CloudTrail 事件。此截图显示了攻击的早期阶段,在该阶段内部威胁账户创建了后门用户,附加了管理权限并创建了访问密钥。 ![CloudTrail Privilege Escalation](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/b098e8986c152225.png) ### 观察到的事件 - `CreateUser` - `AttachUserPolicy` - `CreateAccessKey` 这完成了初始攻击链,并清楚地记录了权限提升过程。 ## 步骤 16 - 事件响应与补救 在调查了恶意活动之后,我通过创建并附加拒绝策略来禁用恶意内部账户,从而应用了补救措施。 这代表了事件响应过程的遏制阶段。我没有信任受损用户,而是选择阻止该账户的所有操作。 ![Incident Response Disable Policy](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/84df289c3e152226.png) ### 补救目标 - 遏制威胁 - 阻止额外操作 - 展示真实的事件响应行为 ## 步骤 17 - 事件响应验证 在将拒绝策略应用于 `rogue-moff` 账户后,我使用 AWS CloudTrail 验证了补救措施。在真实的事件响应过程中,此步骤对于确认遏制措施已成功执行并记录在案非常重要。 我针对 **root** 用户筛选了 CloudTrail 日志,以审查在补救期间采取的管理操作。事件日志显示拒绝策略已应用,并记录了为保护受损账户而采取的其他管理操作。 此次验证确认恶意账户已被成功遏制,并且所有补救步骤均已妥善记录。 ![CloudTrail Remediation Event Log Part 1](https://raw.githubusercontent.com/brick5k/Imperial-Cloud-Security-Lab/main/screenshots/17-event-log.png) ![CloudTrail Remediation Event Log Part 2](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/44f83a3b1e152258.png) ### 观察到的事件 - PutUserPolicy - ListAccessKeys - ListAttachedUserPolicies - ListUserPolicies - GetAccountSummary ### 验证目标 - 确认补救措施成功 - 验证恶意账户的遏制情况 - 记录事件响应活动 - 保留审计轨迹以供调查 ## 完整攻击时间线 本项目遵循以下顺序: 1. Terraform 环境初始化 2. AWS 环境部署 3. 权限过高的内部账户建立 4. CloudTrail 和 GuardDuty 启用 5. 内部人员 (`rogue-moff`) 创建了 `rebel-hacker` 6. 内部人员被授予管理权限 7. 内部人员创建访问密钥以实现持久化 8. 后门账户执行侦察 9. 审查 CloudTrail 日志以获取证据 10. root/受信管理员账户应用拒绝策略以遏制威胁 ## 关键安全教训 本实验室强化了几个重要的云安全概念: ### 最小权限原则至关重要 `rogue-moff` 账户被故意赋予了过高权限。这展示了过多的 IAM 权限可能带来多大的危险。 ### CloudTrail 至关重要 即使 GuardDuty 没有对每一步都发出警报,CloudTrail 仍然保留了攻击者行为的完整序列。 ### 实验室中的 CLI 活动极具价值 从命令行生成活动使模拟更加真实,并有助于为调查创建更有力的证据。 ### 事件响应不仅仅是检测 该项目并未止步于识别可疑活动。它还包括了遏制和补救,这使得实验室更加完整和真实。 ## 展示的技能 本项目展示了对以下方面的经验: - AWS IAM 安全 - 权限提升场景 - 云侦察行为 - CloudTrail 日志调查 - GuardDuty 监控 - 事件响应遏制 - 使用 Terraform 的基础设施即代码 - AWS CLI 攻击模拟 - 云安全文档编写 ## Terraform 代码 用于部署此环境的 Terraform 配置包含在: [Terraform/main.tf](Terraform/Main.tf)
标签:AWS, AWS CLI, CloudTrail, DPI, EC2, ECS, GuardDuty, IaC, IAM安全, S3, SecOps, Terraform, VPC, 云基础设施, 云安全架构, 内部威胁检测, 安全实验室, 安全模拟, 安全运营, 扫描框架, 网络安全, 网络安全审计, 隐私保护