Hitansh1601/AWS-cloud-threat-detection-auto-response
GitHub: Hitansh1601/AWS-cloud-threat-detection-auto-response
该项目实现了一套云原生的 AWS SOAR 流水线，通过 GuardDuty 检测威胁并由 EventBridge 触发 Lambda 自动修复 IAM 配置错误和 S3 数据外泄事件。
Stars: 1 | Forks: 0
# AWS 云威胁检测与自动化响应系统
[](https://aws.amazon.com)
[](https://aws.amazon.com/guardduty)
[](https://aws.amazon.com/lambda)
[]()
[](https://attack.mitre.org)
[-2ea44f?style=flat-square)]()
## 目录
- [架构概述](#architecture-overview)
- [攻击场景](#attack-scenario)
- [使用的 AWS 服务](#aws-services-used)
- [MITRE ATT&CK 映射](#mitre-attck-mapping)
- [环境配置 — 基础设施](#setup--infrastructure)
- [环境配置 — 日志层](#setup--logging-layer)
- [环境配置 — 编排与响应](#setup--orchestration-and-response)
- [攻击模拟证据](#attack-simulation-evidence)
- [检测证据](#detection-evidence)
- [自动化响应 — Lambda 代码](#automated-response--lambda-code)
- [流水线触发证明](#proof-the-pipeline-fired)
- [经验教训](#lessons-learned)
- [未来改进](#future-improvements)
## 架构概述
**完整的 SOAR pipeline —— 检测、告警和修复，全程自动化：**
```
┌─────────────────────────────────────────────────────────────────────┐
│ AWS ap-south-1 (Mumbai) │
│ │
│ EC2: sec-lab-victim │
│ ├── IAM Role: EC2-S3-Insecure-Role (AmazonS3FullAccess) │
│ └── Attack: aws s3 cp s3://sec-lab-data/ ./ --recursive │
│ ↓ │
│ CloudTrail (sec-lab-trail) ── every API call logged │
│ VPC Flow Logs (/vpc/flowlogs) ── network traffic logged │
│ ↓ │
│ AWS GuardDuty ── ML analysis of CloudTrail + Flow Logs │
│ 3 Low-severity findings generated │
│ ↓ │
│ EventBridge Rule: guardduty-threat-rule │
│ ┌────────────────────┬──────────────────────────┐ │
│ ↓ ↓ │ │
│ SNS: cloud-threat-alerts Lambda: auto-remediate-ec2 │ │
│ Email alert < 60s Detach IAM role │ │
│ Block S3 public access │ │
│ MTTR: < 30 seconds │ │
└─────────────────────────────────────────────────────────────────────┘
```
## 攻击场景
**配置缺陷：** EC2 实例 `sec-lab-victim` 挂载了附加 `AmazonS3FullAccess` 权限的 IAM 角色 `EC2-S3-Insecure-Role` —— 这直接违反了最小权限原则。
**攻击向量：** EC2 实例通过实例元数据服务 (IMDS) 在 `169.254.169.254` 自动获取 IAM 角色凭证。无需显式访问密钥 —— 过度授权的角色已预加载。
**目标存储桶 `sec-lab-data` 中的敏感文件：**
- `password.txt.txt` — 12 字节 — 模拟凭证文件
- `exployee.txt.txt` — 12 字节 — 模拟员工数据文件
攻击分两个会话执行（2026 年 4 月 9 日和 4 月 10 日），以生成充足的 CloudTrail 数据量供 GuardDuty 进行 ML 分析。
## 使用的 AWS 服务
|# |服务 |资源名称 |用途 |
|--|-----------------|---------------------|-----------------------------------------------------------|
|1 |**EC2** |sec-lab-victim |受害实例 — Ubuntu 22.04, t2.micro, 挂载了 IAM 角色 |
|2 |**S3** |sec-lab-data |包含模拟敏感文件的目标存储桶 |
|3 |**IAM** |EC2-S3-Insecure-Role |故意过度授权 — `AmazonS3FullAccess` |
|4 |**GuardDuty** |ap-south-1 detector |消耗 CloudTrail + VPC Flow Logs 的 ML 威胁检测 |
|5 |**CloudTrail** |sec-lab-trail |API 审计 — 记录每一个 S3 GetObject/ListBucket |
|6 |**VPC Flow Logs**|/vpc/flowlogs |发送至 CloudWatch 的网络流量取证 |
|7 |**CloudWatch** |sec-lab-dashboard |Lambda 调用，NetworkOut 激增，CPU 指标 |
|8 |**EventBridge** |guardduty-threat-rule|SOAR 编排 — 将发现结果路由至 Lambda + SNS |
|9 |**SNS** |cloud-threat-alerts |向安全团队发送实时电子邮件告警 |
|10|**Lambda** |auto-remediate-ec2 |自动化修复 — Python 3.12 |
## MITRE ATT&CK 映射
|阶段 |技术 ID |技术 |证据 |
|---------------|-------------|------------------------------|------------------------------------------------------------------|
|Discovery |**T1619** |Cloud Storage Object Discovery|`aws s3 ls` 通过被攻陷的 IAM 角色列出了所有存储桶 |
|Collection |**T1530** |Data from Cloud Storage |`aws s3 cp` 下载了两个敏感文件 |
|Exfiltration |**T1537** |Transfer Data to Cloud Account|从 `s3://sec-lab-data` 递归下载到 EC2 本地存储 |
|Initial Access |**T1078.004**|Valid Accounts: Cloud Accounts|通过 IMDS 获取 IAM 角色凭证 — 无需被盗密钥 |
|Defense Evasion|**T1562.008**|Disable Cloud Logs |GuardDuty 发现：CloudTrail 跟踪 `sec-lab-trail` 被禁用 |
## 环境配置 — 基础设施
### EC2 受害实例
通过 AWS 控制台启动的 EC2 实例：
- **名称：** sec-lab-victim
- **AMI：** Ubuntu 22.04 LTS (ap-south-1)
- **实例类型：** t2.micro (Free Tier)
- **密钥对：** victim1.pem (RSA, .pem 格式)
- **安全组：** launch-wizard-4
- **自动分配公有 IP：** 已启用
**启动期间的网络设置：**
*VPC: vpc-0b6ac720727d088e6 (默认, 172.31.0.0/16) — 启用自动分配公有 IP — 创建了安全组 launch-wizard-4*
**确认 SSH 访问：**
*ubuntu@ip-172-31-13-162 shell 提示符 — Ubuntu 登录横幅显示 IPv4 172.31.13.162 — 可通过 SSH 访问 EC2 实例*
**在受害实例上安装了 AWS CLI：**
*sudo ./aws/install → “You can now run: /usr/local/bin/aws –version” — AWS CLI v2 已在受害实例上准备就绪*
### IAM 角色 — 故意配置缺陷
```
{
"RoleName": "EC2-S3-Insecure-Role",
"TrustedEntity": "ec2.amazonaws.com",
"AttachedPolicy": "arn:aws:iam::aws:policy/AmazonS3FullAccess",
"Note": "Intentionally over-permissive — for security demonstration only"
}
```
在攻击模拟之前，此不安全的角色已附加到 EC2 实例上。这正是真实云入侵事件中常见的配置缺陷 —— 开发人员为了“方便”而将宽泛的 S3 策略附加到 EC2 实例上。
完整策略文档请参阅 [`iam/ec2-insecure-policy.json`](iam/ec2-insecure-policy.json)。
## 环境配置 — 日志层
### CloudTrail Trail
Trail `sec-lab-trail` 配置如下：
- 新的 S3 日志存储桶（SSE-KMS 加密）
- 启用日志文件验证
- 管理事件、数据事件 (S3) 和网络活动事件均已启用
**已选择的日志事件类型：**
*管理事件 ✓，数据事件 ✓，Insights 事件 ☐，网络活动事件 ✓ — 全面的 API 覆盖范围*
### VPC Flow Logs
VPC Flow Logs 被配置为发送至 CloudWatch Logs 组 `/vpc/flowlogs`。
## 环境配置 — 编排与响应
### EventBridge Rule
规则名称：`guardduty-threat-rule`，位于 `default` 事件总线上。
匹配任何 GuardDuty 发现结果的事件模式：
```
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"]
}
```
**规则创建 — 配置选项卡：**
*EventBridge 规则创建 — 配置选项卡：Event bus = default，Activation = Active 开关已开启*
**事件源选择：**
*EventBridge 规则构建器：AWS SERVICE EVENTS 面板（来自 200 多个服务的事件，包括通过 CloudTrail 的事件）和 CUSTOM EVENTS 面板*
**最终流水线图（带有两个目标的规则 `guardduty-threat-rule`）：**
*增强型构建器视图：GuardDuty Finding → Event pattern (Filter) → Lambda function: auto-remediate-ec2 + SNS topic: cloud-threat-alerts*
### Lambda Function
Lambda 函数 `auto-remediate-ec2` 部署在 ap-south-1，运行环境为 Python 3.12，由 EventBridge 在 GuardDuty 产生发现结果时触发。
## 攻击模拟证据
### 会话 1 — 初始攻击（2026 年 4 月 9 日）
**首次尝试未使用 IAM 角色凭证（失败），随后使用 IMDS 凭证（成功）：**
```
ubuntu@ip-172-31-13-162:~$ aws s3 ls
# ERROR: 无法找到 credentials
ubuntu@ip-172-31-13-162:~$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# 返回 role name — credentials 可通过 IMDS 获取
ubuntu@ip-172-31-13-162:~$ aws s3 ls
2026-04-09 16:31:26 aws-cloudtrail-logs-[REDACTED]-717fe3c1
2026-04-09 19:04:57 sec-lab-data ← TARGET BUCKET FOUND
ubuntu@ip-172-31-13-162:~$ aws s3 cp s3://sec-lab-data ./ --recursive
download: s3://sec-lab-data/exployee.txt.txt to ./exployee.txt.txt
download: s3://sec-lab-data/password.txt.txt to ./password.txt.txt
```
### 会话 2 — 重复攻击（2026 年 4 月 10 日）
```
ubuntu@ip-172-31-13-162:~$ aws s3 ls
# 列出所有 S3 buckets，包括 sec-lab-data
ubuntu@ip-172-31-13-162:~$ aws s3 cp s3://sec-lab-data ./ --recursive
download: s3://sec-lab-data/exployee.txt.txt to ./exployee.txt.txt
download: s3://sec-lab-data/password.txt.txt to ./password.txt.txt
# 最后一次登录来自 13.233.177.5 — CloudTrail 记录了 source IP
```
### 确认攻击者可见的存储桶内容
```
ubuntu@ip-172-31-13-162:~$ aws s3 ls s3://sec-lab-data
2026-04-10 01:16:12 12 exployee.txt.txt
2026-04-10 01:16:16 12 password.txt.txt
ubuntu@ip-172-31-13-162:~$ aws s3 cp s3://sec-lab-data/password.txt.txt .
# 两个文件已通过过度宽松的 IAM role 成功下载
```
## 检测证据
### GuardDuty 发现结果
GuardDuty 分析了 CloudTrail 日志和 VPC Flow Logs，并生成了 **3 个低严重性发现结果**：
**生成的发现结果：**
|发现结果 |严重性 |描述 |
|--------------------------------------|--------|--------------------------------------------------|
|IAMUser/InstanceCredentialExfiltration|Low |API `GetInstanceProfile` 使用 root 凭证调用 |
|Policy/IAMUser/RootCredentialUsage |Low |API `ListNotificationHubs` 使用 root 凭证调用 |
|Stealth/S3/CloudTrail.LogDisabled |Low |CloudTrail trail `sec-lab-trail` 被禁用 |
### CloudTrail 事件历史记录
来自攻击的每一个 API 调用都被完整记录在 CloudTrail 中，并带有完整的取证上下文：
*CloudTrail 事件历史记录（50+ 事件）：SendSSHPublicKey (4月10日 07:52, 用户: root, EC2 实例 i-0ea5574a6ce2ada66), StartLogging, CreateTrail, PutEventSelectors — 包含基础设施设置和攻击活动的完整取证时间线*
## 自动化响应 — Lambda 代码
```
import boto3
import json
def lambda_handler(event, context):
"""
Triggered by EventBridge on GuardDuty findings.
Actions:
1. Detach insecure IAM role from all EC2 instances
2. Block all public access to the sensitive S3 bucket
"""
print(f"GuardDuty finding received: {json.dumps(event)}")
# ── Step 1: Detach IAM role from EC2 ──────────────────────────
ec2 = boto3.client('ec2', region_name='ap-south-1')
associations = ec2.describe_iam_instance_profile_associations()
for assoc in associations['IamInstanceProfileAssociations']:
if assoc['State'] == 'associated':
ec2.disassociate_iam_instance_profile(
AssociationId=assoc['AssociationId']
)
print(f"[REMEDIATED] IAM role removed from: {assoc['InstanceId']}")
# ── Step 2: Block S3 public access ────────────────────────────
s3 = boto3.client('s3', region_name='ap-south-1')
s3.put_public_access_block(
Bucket='sec-lab-data',
PublicAccessBlockConfiguration={
'BlockPublicAcls': True,
'IgnorePublicAcls': True,
'BlockPublicPolicy': True,
'RestrictPublicBuckets': True
}
)
print("[REMEDIATED] S3 public access blocked")
return {
'status': 'Remediation complete',
'actions': ['iam_role_detached', 's3_access_blocked'],
'mttr': '< 30 seconds'
}
```
完整函数：[`lambda/auto-remediate-ec2.py`](lambda/auto-remediate-ec2.py)
**Lambda 执行后：**
- EC2 丢失其 IAM 角色 — 后续的 `aws s3 ls` 返回 `NoCredentials`
- S3 存储桶阻止所有公共访问 — 无法进行外部数据外泄
- 执行情况记录在 CloudWatch 中，包含完整的事件输入和修复输出
## 流水线触发证明
CloudWatch `sec-lab-dashboard` 提供了完整流水线已执行的客观证据：
|指标 |值 |含义 |
|---------------------------|-------------------------|------------------------------------------------------------------|
|**Lambda Invocations** |**1** |在 GuardDuty 发现后，EventBridge 精确触发了一次 Lambda |
|**NetworkOut spike** |**13:00 时 145.5k 字节** |S3 数据外泄 — 两个文件被同时下载 |
|**CPUUtilization spike** |**13:00 时 14.9%** |攻击模拟会话期间 EC2 的处理活动 |
|**ec2-network-spike alarm**|**OK** |CloudWatch 告警确认已捕获该网络事件 |
**完整仪表盘视图同时捕获于：**
### SNS 电子邮件告警
AWS SNS 将 GuardDuty 的发现结果作为原始 JSON 件发送到了配置的地址。该邮件于 11:37 到达（大约在 13:00 攻击发生后的 15 分钟，反映了 GuardDuty 的处理延迟）。
**邮件内容包括：**
```
{
"detail-type": "GuardDuty Finding",
"source": "aws.guardduty",
"account": "[REDACTED]",
"time": "2026-04-10T06:07:07Z",
"region": "ap-south-1",
"detail": {
"resource": {
"accessKeyDetails": {
"accessKeyId": "[REDACTED]",
"userName": "Root",
"userType": "Root"
}
}
}
}
```
## 关键指标摘要
|指标 |值 |
|----------------------------|--------------------------------------------------|
|集成的 AWS 服务 |**10** |
|生成的 GuardDuty 发现结果 |**3 个低严重性** — 来自真实 API 调用的真实发现 |
|Lambda 调用次数 |**1**（已在 CloudWatch `sec-lab-dashboard` 中确认）|
|自动化 MTTR |**< 30 秒** |
|捕获的 CloudTrail 事件 |**50+** |
|外泄的 S3 文件 |**2** (exployee.txt.txt + password.txt.txt) |
|执行的攻击会话 |**2** (2026 年 4 月 9 日 + 4 月 10 日) |
|区域 |**ap-south-1 (Mumbai)** |
## 经验教训
**1. GuardDuty 有 10-15 分钟的处理延迟 —— 需提前规划。** GuardDuty 会定期批量分析 CloudTrail 事件，而非实时分析。自动化的 Lambda 响应在发现结果发布后的 30 秒内触发 —— 瓶颈在于检测延迟，而非响应速度。
**2. IMDS 是攻击向量，而不是被盗凭证。** EC2 实例没有配置显式的 AWS 访问密钥。角色凭证通过 `http://169.254.169.254/latest/meta-data/iam/security-credentials/` 自动下发。EC2 上过度授权的 IAM 角色相当于预装好的攻击能力。
**3. CloudTrail 是取证的基础。** 每一次 `aws s3 ls`、每一次 `aws s3 cp`、每一次 `GetObject` 都记录了调用者身份、源 IP、时间戳和资源。如果在攻击前未启用 CloudTrail，GuardDuty 将没有数据源可供分析。
**4. EventBridge 是没有平台成本的 SOAR。** 单个 EventBridge 规则将一种事件类型路由到两个目标（SNS + Lambda），这取代了原本可能需要专用 SOAR 平台才能完成的工作。可视化的构建器使得路由逻辑可审计且透明。
**5. Lambda 调用 = 客观证据。** CloudWatch 指标 `Invocations: 1` 是 EventBridge 在 GuardDuty 触发后调用 Lambda 的证据。如果没有 CloudWatch 监控，就无法确认自动化响应是否真正执行了。
**6. 低严重性发现依然重要。** 所有三个 GuardDuty 发现均为低严重性。在管理良好的 AWS 账户中，“使用 root 凭证调用 GetInstanceProfile”是一个有意义的信号 —— root API 的使用几乎不应该发生。
## 未来改进
- [ ] 添加 Terraform/CloudFormation IaC，实现一条命令的可重复部署
- [ ] 扩展 Lambda 功能，在分离 IAM 角色之前对 EC2 内存进行快照（取证保留）
- [ ] 启用 GuardDuty Malware Protection，以便在被攻陷后对 EC2 文件系统进行扫描
- [ ] 集成 AWS Security Hub 进行集中的发现结果管理
- [ ] 添加 Amazon Macie，以在任何攻击发生前自动对 S3 存储桶内容进行分类
- [ ] 启用 GuardDuty S3 Protection 以检测异常的 S3 访问模式
- [ ] 使用 AWS Organizations 构建多账户环境，以测试跨账户攻击场景
## 安全提示
## 展示技能
`AWS GuardDuty` `AWS Lambda (Python 3.12)` `Amazon EventBridge` `AWS CloudTrail`
`VPC Flow Logs` `Amazon CloudWatch` `Amazon SNS` `IAM Security`
`Principle of Least Privilege` `SOAR Pipeline Design` `Cloud Incident Response`
`Automated Remediation` `Cloud Forensics` `MITRE ATT&CK (Cloud)`
`Detection Engineering` `EC2 Security` `S3 Security` `IMDS Attack Vectors`
*由 [Hitansh Waghela](https://linkedin.com/in/hitansh-waghela-99554a274) 构建 — 计算机工程，孟买大学*
*[GitHub](https://github.com/Hitansh1601) · [TryHackMe](https://tryhackme.com/p/hitansh1601) · [whitansh@gmail.com](mailto:whitansh@gmail.com)*
标签：AMSI绕过, AWS, DPI, PB级数据处理, SOAR, 威胁检测, 安全运维, 数据泄露, 漏洞利用检测, 漏洞探索, 自动化响应, 逆向工具