AbdurRahman-cybersec/aws-cloudtrail-breach-investigation

# 🔒 AWS 安全实验室：云中漏洞     ## 📝 概述 本仓库记录了我完成 [PwnedLabs.io](https://pwnedlabs.io/) 提供的 **"Breach in the Cloud"** 安全实验室的情况。通过这次实操练习，我对 AWS CloudTrail 日志进行了取证分析，以调查模拟的安全漏洞、追踪攻击路径并验证数据窃取行为。 **实验室链接：** [Breach in the Cloud - PwnedLabs](https://pwnedlabs.io/labs/breach-in-the-cloud)  *截图：PwnedLabs 实验室界面* ## 🎯 实验室信息 | **属性** | **详情** | |---------------|-------------| | **实验室名称** | Breach in the Cloud | | **平台** | PwnedLabs | | **难度** | Beginner | | **关注领域** | AWS CloudTrail 分析, IAM 安全, S3 枚举 | | **场景** | Huge Logistics 检测到异常的 AWS 活动 | | **事件 ID** | INCIDENT-3252 | ## 🎓 学习目标 通过本次实验，我掌握了以下实用技能： - ✅ **CloudTrail 日志分析** - 分析 AWS CloudTrail 日志以发现可疑活动模式 - ✅ **IAM 安全调查** - 识别被入侵的 IAM 用户和角色 - ✅ **权限提升检测** - 追踪 AssumeRole 权限提升攻击 - ✅ **S3 安全** - 调查 S3 存储桶枚举和数据窃取 - ✅ **攻击路径验证** - 复现攻击者步骤以确认入侵方法 ## 🔍 执行摘要 ### 事件概况 Huge Logistics 安全团队于 **2023 年 8 月 26 日** 在其 AWS 账户中检测到异常活动。通过对 CloudTrail 日志的系统分析，我确认了一起成功的安全入侵事件，涉及： - **被入侵账户：** `temp-user` (IAM 用户) - **攻击来源：** 84.32.71.19 (UAB Cherry Servers, 芝加哥) - **攻击持续时间：** 45 分钟 (20:35 - 21:20 UTC) - **被窃取数据：** 来自 S3 存储桶的 2,232 字节 - **关键漏洞：** 角色授权未启用 MFA ### 攻击时间线 ``` 20:35 UTC → Initial Access (GetCallerIdentity) 20:50 UTC → Failed S3 Access (13 errors) 20:50-20:55 UTC → Massive Enumeration (450 errors) 21:00 UTC → Privilege Escalation (AssumeRole successful) 21:20 UTC → Data Exfiltration (S3 GetObject) ``` ## 📊 调查过程 ### 阶段 1：初步日志分析 **目标：** 识别 CloudTrail 日志中的可疑用户名 ``` grep -r userName | sort -u ``` **发现：** 发现不符合内部命名规范的可疑用户名 `temp-user`。  *截图：显示可疑 temp-user 账户的终端输出* ### 阶段 2：时间线分析 #### 2.1 首次接触 (20:35 UTC) **日志文件：** `107513503799_CloudTrail_us-east-1_20230826T2035Z_PjmwM7E4hZ6897Aq.json` **关键细节：** - **操作：** `GetCallerIdentity` (AWS STS) - **用户：** `temp-user` - **来源 IP：** 84.32.71.19 - **用户代理：** `aws-cli/1.27.74 Python/3.10.6 Linux/5.15.90.1-microsoft-standard-WSL2` - **位置：** 芝加哥, 伊利诺伊州 (UAB Cherry Servers)  *截图：显示初始 GetCallerIdentity 调用的 CloudTrail 日志* **分析：** `GetCallerIdentity` 操作的功能类似于 `whoami` 命令，允许攻击者确认其访问级别。该 IP 地址追溯到 Huge Logistics 未使用的 VPS 提供商——这是一个重大警示信号。  *截图：显示 UAB Cherry Servers 的 IP 地理位置* #### 2.2 初始侦察失败 (20:50 UTC) **日志文件：** `107513503799_CloudTrail_us-east-1_20230826T2050Z_iUtQqYPskB20yZqT.json` **发现：** - 尝试对 S3 存储桶 `emergency-data-recovery` 执行 `ListObjects` - **结果：** 拒绝访问 (13 条错误消息) ``` grep errorMessage 107513503799_CloudTrail_us-east-1_20230826T2050Z_iUtQqYPskB20yZqT.json ```  *截图：S3 存储桶的拒绝访问错误* #### 2.3 激进枚举攻击 (20:50-20:55 UTC) **日志文件：** - `107513503799_CloudTrail_us-east-1_20230826T2050Z_iUtQqYPskB20yZqT.json` - `107513503799_CloudTrail_us-east-1_20230826T2055Z_W0F5uypAbGttUgSn.json` **攻击特征：** ``` # 统计每个日志文件中的错误 grep errorMessage *T2050Z*.json | wc -l # 输出：13 grep errorMessage *T2055Z*.json | wc -l # 输出：450 ``` **拒绝访问错误总数：** **463**  *截图：显示 450 个拒绝访问错误的终端* **尝试的 IAM API 操作：** - `iam:ListAccountAliases` - `iam:ListInstanceProfiles` - `iam:ListUsers` - `datapipeline:ListPipelines` - `organizations:ListAccounts` - `route53:ListHealthChecks` - 以及更多...  *截图：部分失败的枚举尝试* **意义：** 几分钟内单个用户产生 450 个拒绝访问错误是自动化枚举的典型指标。合法用户永远不会产生这种模式。 #### 2.4 权限提升成功 (21:00 UTC) **日志文件：** `107513503799_CloudTrail_us-east-1_20230826T2100Z_APB7fBUnHmiWjHtg.json` **🚨 关键发现：** 此日志文件中没有错误消息！ ``` grep errorMessage *T2100Z*.json # 无结果 - 所有操作成功 ``` **成功操作：** `AssumeRole` 至 `AdminRole` ``` { "eventName": "AssumeRole", "requestParameters": { "roleArn": "arn:aws:iam::107513503799:role/AdminRole", "roleSessionName": "MySession" }, "responseElements": { "credentials": { "accessKeyId": "ASIARSCCN4A3VHM46DJU", ... } } } ```  *截图：显示成功 AssumeRole 的 CloudTrail 日志* **安全缺口：** `AdminRole` **没有 MFA 要求**，允许仅凭被盗凭证进行权限提升。  *截图：显示 mfaAuthenticated: false 的角色* #### 2.5 数据窃取 (21:20 UTC) **日志文件：** `107513503799_CloudTrail_us-east-1_20230826T2120Z_UCUhsJa0zoFY3ZO0.json` 凭借提升的 `AdminRole` 权限，攻击者执行了： 1. **ListObjects** - 列出 `emergency-data-recovery` 存储桶的内容 2. **GetObject** - 下载 `emergency.txt` (2,232 字节)  *截图：显示 ListObjects 和 GetObject 操作的 CloudTrail 查看器* **窃取详情：** ``` { "eventName": "GetObject", "requestParameters": { "bucketName": "emergency-data-recovery", "key": "emergency.txt" }, "additionalEventData": { "bytesTransferredOut": 2232 } } ``` ## 🔬 攻击路径验证 为了验证入侵情况，我使用提供的凭证复现了攻击者的步骤： ### 步骤 1：确认身份 ``` aws sts get-caller-identity ```  *截图：确认 temp-user 身份* ### 步骤 2：检查 IAM 策略 ``` aws iam list-user-policies --user-name temp-user ``` **输出：** 名为 `test-temp-user` 的策略  *截图：发现内联策略* ### 步骤 3：检查策略详情 ``` aws iam get-user-policy --user-name temp-user --policy-name test-temp-user ``` **关键发现：** 策略允许对 `AdminRole` 执行 `sts:AssumeRole` ``` { "PolicyDocument": { "Statement": [{ "Sid": "VisualEditor0", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::107513503799:role/AdminRole" }] } } ```  *截图：授予 AssumeRole 权限的 IAM 策略* ### 步骤 4：扮演 AdminRole ``` aws sts assume-role \ --role-arn arn:aws:iam::107513503799:role/AdminRole \ --role-session-name MySession ```  *截图：使用临时凭证成功扮演 AdminRole* ### 步骤 5：配置新凭证 ``` export AWS_ACCESS_KEY_ID="ASIARSCCN4A3VHM46DJU" export AWS_SECRET_ACCESS_KEY="..." export AWS_SESSION_TOKEN="..." ``` ### 步骤 6：验证提升的权限 ``` aws sts get-caller-identity ```  *截图：已确认的 AdminRole 上下文* ### 步骤 7：访问 S3 存储桶 ``` aws s3 ls s3://emergency-data-recovery ```  *截图：成功列出 S3 存储桶内容* ### 步骤 8：检索被窃取的数据 ``` aws s3 cp s3://emergency-data-recovery/emergency.txt . aws s3 cp s3://emergency-data-recovery/message.txt . ```  *截图：从被入侵的存储桶下载文件* **检索到的 Flag：** `3eb222cf55522f0f321f1ed5ed9a3663` ## 📈 攻击路径可视化 攻击遵循以下模式： 1. **凭证泄露** → 以 `temp-user` 身份初始访问 2. **IAM 枚举** → 发现 AssumeRole 能力 3. **权限提升** → 扮演 `AdminRole` (无 MFA) 4. **数据访问** → S3 存储桶入侵和文件窃取 ## 🛡️ 已识别的安全漏洞 | **漏洞** | **严重程度** | **描述** | |-------------------|--------------|-----------------| | **凭证泄露** | 🔴 严重 | `temp-user` 账户凭证被泄露，可能通过凭证暴露或网络钓鱼 | | **特权角色无 MFA** | 🔴 严重 | `AdminRole` 允许在无 MFA 的情况下被扮演，仅凭被盗凭证即可实现权限提升 | | **过度许可的 IAM 策略** | 🟠 高 | `temp-user` 拥有授予管理角色 AssumeRole 权限的内联策略——违反了最小权限原则 | | **监控不足** | 🟠 高 | 几分钟内 450+ 次拒绝访问错误未被检测到——没有针对枚举模式的实时告警 | | **命名规范薄弱** | 🟡 中 | `temp-user` 不符合内部标准，使其最初难以被识别为可疑 | ## 💡 建议 ### 立即行动 (第 0 天) 1. **撤销被泄露的凭证** - 立即禁用 `temp-user` 账户 - 轮换所有访问密钥 - 终止所有活动会话 2. **实施 MFA 要求** ```json { "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } } } ``` 向所有特权角色信任策略添加 MFA 条件 3. **启用 S3 保护** - 启用存储桶版本控制 - 启用 MFA 删除 - 审查并限制存储桶策略 ### 短期行动 (第 1 周) 4. **实施实时告警** - 设置 CloudWatch 告警，针对 5 分钟内超过 50 次拒绝访问错误 - 为 AssumeRole 事件设置 SNS 通知 - 启用 AWS GuardDuty 进行自动化威胁检测 5. **审查 IAM 策略** - 审计所有内联策略 - 移除不必要的 AssumeRole 权限 - 实施最小权限访问 6. **凭证管理** - 实施 AWS Secrets Manager - 启用自动凭证轮换 - 强制执行强密码策略 ### 长期改进 (第 1 个月+) 7. **增强监控** - 部署 AWS Security Hub - 集中管理 CloudTrail 日志 - 实施 SIEM 集成 8. **安全培训** - 进行事件响应演练 - 培训团队进行 CloudTrail 分析 - 建立清晰的升级程序 9. **网络分段** - 对敏感操作实施 IP 白名单 - 审查 VPC 配置 - 启用 VPC Flow Logs ## 🧰 使用的工具和命令 ### 日志命令 ``` # 查找 CloudTrail 日志中的所有用户名 grep -r userName | sort -u # 搜索特定用户活动 grep -h -A 10 temp-user .json # 统计错误消息 grep errorMessage .json | wc -l # 搜索特定操作 grep -A 20 AssumeRole .json ``` ### AWS CLI 命令 ``` # 验证身份 aws sts get-caller-identity # 列出用户策略 aws iam list-user-policies --user-name temp-user # 获取策略详情 aws iam get-user-policy --user-name temp-user --policy-name test-temp-user # Assume role aws sts assume-role --role-arn --role-session-name # 列出 S3 bucket aws s3 ls s3://emergency-data-recovery # 从 S3 下载 aws s3 cp s3://emergency-data-recovery/emergency.txt . ``` ## 📚 关键收获 1. **CloudTrail 至关重要**：每个 AWS 操作都会在 CloudTrail 中留下痕迹。适当的日志分析可以揭示完整的攻击链。 2. **模式识别**：450 个拒绝访问错误是一个明显的枚举模式。针对此类模式的自动告警至关重要。 3. **MFA 阻止提升**：即使凭证被盗，特权角色上的 MFA 也能阻止此次攻击。 4. **最小权限原则**：`temp-user` 本不应拥有对 `AdminRole` 的 AssumeRole 权限。 5. **时间就是生命**：攻击耗时 45 分钟。更快的检测和响应本可以防止数据窃取。 ## 🔗 资源 - **实验室平台：** [PwnedLabs.io](https://pwnedlabs.io/) - **实验室链接：** [Breach in the Cloud](https://pwnedlabs.io/labs/breach-in-the-cloud) - **AWS CloudTrail 文档：** [AWS CloudTrail User Guide](https://docs.aws.amazon.com/cloudtrail/) - **AWS IAM 最佳实践：** [IAM Security Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) - **CloudTrail 查看器工具：** [GitHub - AWS CloudTrail Viewer](https://github.com/aws-samples/aws-cloudtrail-analyzer-workshop) ## 🏆 实验室完成  *截图：实验室完成徽章* **完成日期：** 2026 年 3 月 3 日 **Flag：** `3eb222cf55522f0f321f1ed5ed9a3663` ## 📝 备注 该实验室是在 PwnedLabs 提供的受控环境中完成的。所有凭证、IP 地址和 AWS 账户详情均为实验室场景的一部分，目前已不再有效。 ## 🤝 与我联系 如果您觉得这份报告有帮助，或者对 AWS 安全有任何疑问，请随时在 LinkedIn 上与我联系！ [](https://linkedin.com/in/yourprofile) [](https://github.com/yourusername) ## 📄 许可证 本报告仅用于教育目的。所有实验室材料和场景均为 PwnedLabs 所有。 **#AWS #CloudSecurity #CyberSecurity #CloudTrail #IAM #S3Security #ThreatHunting #DFIR #PwnedLabs**

标签：AWS安全, CloudTrail分析, Homebrew安装, IAM安全, PwnedLabs, S3数据泄露, 云渗透测试, 协议分析, 安全实验室, 攻击链分析, 数字取证, 数据渗出, 权限提升, 渗透测试报告, 网页分析工具, 自动化脚本, 足迹分析