detecting-cloud-threats-with-guardduty

# 使用 GuardDuty 检测云威胁

## 适用场景

- 为新建或现有 AWS 账户建立持续威胁检测时
- 调查与被入侵实例、凭据滥用或数据泄露相关的 GuardDuty 发现时
- 构建由 GuardDuty 发现触发的自动化事件响应手册时
- 将威胁检测范围扩展至运行在 EKS、ECS 或 Fargate 上的容器工作负载时
- 为附加到可疑 EC2 实例的 EBS 卷启用恶意软件扫描时

**不适用于**：Azure 或 GCP 的威胁检测（请参阅 securing-azure-with-microsoft-defender 或 auditing-gcp-security-posture）、静态代码分析，或合规态势监控（请参阅 implementing-aws-security-hub）。

## 前置条件

- 具有 GuardDuty 管理员权限（guardduty:*）的 AWS 账户
- 启用 AWS CloudTrail、VPC Flow Logs 和 DNS 查询日志（GuardDuty 自动使用这些数据源）
- 若需跨多账户环境部署 GuardDuty，须配置 AWS Organizations
- 配置 EventBridge 和 Lambda 用于自动化响应工作流

## 工作流程

### 步骤 1：启用 GuardDuty 及保护计划

使用委派管理员账户在组织层面激活 GuardDuty，并启用所有保护计划，包括 S3 Protection、EKS Audit Log Monitoring、Runtime Monitoring、Malware Protection、RDS Login Activity 和 Lambda Network Activity Monitoring。

```bash
# 启用 GuardDuty 作为组织委派管理员
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES \
  --data-sources '{
    "S3Logs": {"Enable": true},
    "Kubernetes": {"AuditLogs": {"Enable": true}},
    "MalwareProtection": {"ScanEc2InstanceWithFindings": {"EbsVolumes": true}}
  }'

# 为 EC2 和 ECS 启用 Runtime Monitoring
aws guardduty update-detector \
  --detector-id <detector-id> \
  --features '[
    {"Name": "RUNTIME_MONITORING", "Status": "ENABLED",
     "AdditionalConfiguration": [
       {"Name": "ECS_FARGATE_AGENT_MANAGEMENT", "Status": "ENABLED"},
       {"Name": "EC2_AGENT_MANAGEMENT", "Status": "ENABLED"}
     ]}
  ]'

# 为多账户环境指定委派管理员
aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333
```

### 步骤 2：配置多账户聚合

自动注册所有组织成员账户，并将发现导出至中央 S3 存储桶，用于数据留存和 SIEM 接入。

```bash
# 为所有组织成员自动启用 GuardDuty
aws guardduty update-organization-configuration \
  --detector-id <detector-id> \
  --auto-enable-organization-members ALL \
  --features '[
    {"Name": "S3_DATA_EVENTS", "AutoEnable": "ALL"},
    {"Name": "EKS_AUDIT_LOGS", "AutoEnable": "ALL"},
    {"Name": "RUNTIME_MONITORING", "AutoEnable": "ALL"}
  ]'

# 配置将发现导出至 S3
aws guardduty create-publishing-destination \
  --detector-id <detector-id> \
  --destination-type S3 \
  --destination-properties '{
    "DestinationArn": "arn:aws:s3:::guardduty-findings-centralized",
    "KmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/key-id"
  }'
```

### 步骤 3：解读发现类型和严重级别

GuardDuty 将发现分为四个严重级别：严重（Critical）、高（High）、中（Medium）和低（Low）。每种发现类型遵循 ThreatPurpose:ResourceType/ThreatName 格式。扩展威胁检测（Extended Threat Detection）生成跨时间关联多个事件的攻击序列发现。

主要发现类别：
- **Recon（侦察）**：端口扫描、API 枚举（例如 Recon:EC2/PortProbeUnprotectedPort）
- **UnauthorizedAccess（未授权访问）**：凭据滥用、来自异常位置的控制台登录
- **CryptoCurrency（加密货币）**：实例上检测到挖矿活动（例如 CryptoCurrency:EC2/BitcoinTool.B）
- **Impact（影响）**：资源劫持、数据销毁企图
- **AttackSequence（攻击序列）**：关联从初始访问到横向移动再到影响的多阶段攻击（严重级别）

### 步骤 4：使用 EventBridge 构建自动化响应

创建 EventBridge 规则，将 GuardDuty 发现路由至 Lambda 函数执行自动遏制操作，例如隔离被入侵的 EC2 实例、撤销 IAM 凭据或封锁恶意 IP 地址。

```bash
# 针对高危/严重 GuardDuty 发现创建 EventBridge 规则
aws events put-rule \
  --name GuardDutyHighSeverity \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {
      "severity": [{"numeric": [">=", 7]}]
    }
  }'

# 设置自动修复 Lambda 函数为目标
aws events put-targets \
  --rule GuardDutyHighSeverity \
  --targets '[{
    "Id": "AutoRemediateTarget",
    "Arn": "arn:aws:lambda:us-east-1:123456789012:function/guardduty-auto-remediate"
  }]'
```

隔离被入侵 EC2 实例的自动修复 Lambda 示例：

```python
import boto3

def lambda_handler(event, context):
    finding = event['detail']
    finding_type = finding['type']
    severity = finding['severity']

    if finding_type.startswith('UnauthorizedAccess:EC2') and severity >= 7:
        instance_id = finding['resource']['instanceDetails']['instanceId']
        ec2 = boto3.client('ec2')

        # 创建隔离安全组（无入站/出站规则）
        vpc_id = finding['resource']['instanceDetails']['networkInterfaces'][0]['vpcId']
        isolation_sg = ec2.create_security_group(
            GroupName=f'isolation-{instance_id}',
            Description='GuardDuty auto-isolation',
            VpcId=vpc_id
        )

        # 将所有安全组替换为隔离安全组
        ec2.modify_instance_attribute(
            InstanceId=instance_id,
            Groups=[isolation_sg['GroupId']]
        )

        # 为实例添加标签以便调查
        ec2.create_tags(
            Resources=[instance_id],
            Tags=[{'Key': 'SecurityStatus', 'Value': 'ISOLATED'},
                  {'Key': 'GuardDutyFinding', 'Value': finding_type}]
        )

        return {'status': 'isolated', 'instance': instance_id}
```

### 步骤 5：调查扩展威胁检测攻击序列

审查关联 EC2、ECS 和 EKS 多个信号的严重级别攻击序列发现。这些发现代表多阶段攻击，例如通过被入侵凭据初始访问，继而持久化、横向移动和挖矿。

```bash
# 列出严重攻击序列发现
aws guardduty list-findings \
  --detector-id <detector-id> \
  --finding-criteria '{
    "Criterion": {
      "severity": {"Gte": 9},
      "type": {"Eq": ["AttackSequence:EC2/CompromisedInstanceGroup",
                       "AttackSequence:ECS/CompromisedCluster",
                       "AttackSequence:EKS/CompromisedCluster"]}
    }
  }'

# 获取包含攻击序列时间线的完整发现详情
aws guardduty get-findings \
  --detector-id <detector-id> \
  --finding-ids <finding-id>
```

### 步骤 6：与 Security Hub 和 SIEM 集成

将 GuardDuty 发现转发至 AWS Security Hub 进行集中聚合，并通过 S3 导出或 Amazon Security Lake 传送至外部 SIEM 平台，用于长期留存和跨来源关联分析。

```bash
# 验证 GuardDuty 与 Security Hub 的集成
aws securityhub get-enabled-standards

# 启用 Amazon Security Lake 并将 GuardDuty 设为数据源
aws securitylake create-data-lake \
  --configurations '[{
    "region": "us-east-1",
    "lifecycleConfiguration": {
      "expiration": {"days": 365}
    }
  }]'
```

## 核心概念

| 术语 | 定义 |
|------|------|
| 扩展威胁检测（Extended Threat Detection） | GuardDuty 功能，跨时间关联多个信号以检测多阶段攻击，生成严重级别的攻击序列发现 |
| Runtime Monitoring（运行时监控） | 在 EC2 实例、ECS 任务和 EKS Pod 上部署安全 Agent，在操作系统层面检测运行时威胁的保护计划 |
| 发现严重级别（Finding Severity） | 四级分类（低、中、高、严重），严重级别表示需要立即响应的已确认多阶段攻击 |
| Malware Protection（恶意软件保护） | 由可疑 EC2 行为触发的按需和自动 EBS 卷扫描，无需安装 Agent 即可检测恶意软件 |
| 委派管理员（Delegated Administrator） | 被指定管理 AWS 组织内所有账户 GuardDuty 的组织成员账户 |
| 抑制规则（Suppression Rule） | 自动归档匹配特定条件的发现的过滤器，用于减少已知无害活动产生的噪音 |
| 威胁情报（Threat Intelligence） | GuardDuty 用于识别与已知恶意基础设施通信的 IP 信誉列表和域名威胁订阅源 |

## 工具与系统

- **Amazon GuardDuty**：核心威胁检测服务，分析 CloudTrail、VPC Flow Logs、DNS 日志和运行时遥测数据
- **Amazon EventBridge**：无服务器事件总线，将 GuardDuty 发现路由至自动化响应目标
- **AWS Security Hub**：集中式安全发现聚合平台，支持自动化修复工作流
- **Amazon Security Lake**：基于 OCSF 规范的数据湖，用于长期安全日志留存和跨服务关联分析
- **Amazon Detective**：基于图形的调查服务，可视化 GuardDuty 发现、资源和 API 活动之间的关系

## 常见场景

### 场景：在 ECS 集群上检测到加密货币挖矿

**场景背景**：GuardDuty 生成针对 ECS Fargate 任务的 CryptoCurrency:Runtime/BitcoinTool.B 高危发现。Runtime Monitoring 检测到容器内执行了挖矿程序。

**方法**：
1. 查看发现详情以确定 ECS 集群、任务定义和容器镜像
2. 立即停止受影响的 ECS 任务，并在 ECR 中隔离容器镜像
3. 检查 CloudTrail 中的 ecs:RegisterTaskDefinition 和 ecs:RunTask 调用，以识别是谁部署了恶意镜像
4. 使用 ECR 增强扫描对 Docker 镜像进行扫描，以识别嵌入的挖矿程序
5. 检查用于推送镜像的 IAM 凭据，并撤销被入侵的访问权限
6. 更新 ECR 镜像扫描策略，阻止包含已知挖矿签名的镜像

**常见陷阱**：在未保留容器镜像的情况下停止任务会丢失取证证据。未能追溯到 RegisterTaskDefinition API 调用则会遗漏初始入侵向量。

## 输出格式

```
GuardDuty 威胁检测摘要
====================================
账户: 123456789012（生产环境）
区域: us-east-1
时间段: 2025-02-01 至 2025-02-23

严重发现（需立即处置）:
[CRIT-001] AttackSequence:EC2/CompromisedInstanceGroup
  - 实例: i-0abc123def, i-0def456abc
  - 攻击链: 凭据窃取 -> 持久化 -> 加密货币挖矿
  - 首次信号: 2025-02-15T08:23:00Z
  - 持续时间: 跨 3 个阶段约 4 小时
  - 状态: 已通过 Lambda 自动隔离

高危发现:
[HIGH-001] UnauthorizedAccess:IAMUser/MaliciousIPCaller
  - 主体: arn:aws:iam::123456789012:user/ci-deploy
  - 来源 IP: 198.51.100.42（Tor 出口节点）
  - API 调用: 向 ec2:RunInstances 发起 47 次调用
  - 状态: 访问密钥已停用

[HIGH-002] CryptoCurrency:Runtime/BitcoinTool.B
  - 资源: ECS 任务 arn:aws:ecs:us-east-1:123456789012:task/cluster/task-id
  - 镜像: 123456789012.dkr.ecr.us-east-1.amazonaws.com/app:v2.1
  - 进程: /tmp/.hidden/xmrig --pool stratum+tcp://pool.example.com:3333
  - 状态: 任务已停止，镜像已隔离

统计数据:
  总发现数: 23
  严重: 1 | 高: 3 | 中: 8 | 低: 11
  自动修复: 4
  待调查: 2
```