killvxk 使用 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。
# 启用 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 接入。
# 为所有组织成员自动启用 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 地址。
# 针对高危/严重 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 示例：
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 多个信号的严重级别攻击序列发现。这些发现代表多阶段攻击，例如通过被入侵凭据初始访问，继而持久化、横向移动和挖矿。
# 列出严重攻击序列发现
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 平台，用于长期留存和跨来源关联分析。
# 验证 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 检测到容器内执行了挖矿程序。
方法：
- 查看发现详情以确定 ECS 集群、任务定义和容器镜像
- 立即停止受影响的 ECS 任务，并在 ECR 中隔离容器镜像
- 检查 CloudTrail 中的 ecs:RegisterTaskDefinition 和 ecs:RunTask 调用，以识别是谁部署了恶意镜像
- 使用 ECR 增强扫描对 Docker 镜像进行扫描，以识别嵌入的挖矿程序
- 检查用于推送镜像的 IAM 凭据，并撤销被入侵的访问权限
- 更新 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