关于 detecting-cloud-threats-with-guardduty
面向 AWS 安全团队的 GuardDuty 威胁检测技能,涵盖多账户保护、告警分析及自动响应,并可将发现汇总到 Security Hub 或 SIEM。
主要功能
- 01启用 GuardDuty 保护计划
- 02集中管理多账户发现
- 03分析威胁类型与严重级别
- 04通过 EventBridge 自动响应
- 05关联 Security Hub 与 SIEM
适用场景
- 01为 AWS 账户配置持续威胁检测
- 02调查凭证滥用或数据外传告警
- 03自动隔离受感染的 EC2 实例
- 04排查容器工作负载攻击序列
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ mukul975/ anthropic-cybersecurity-skills --skill detecting-cloud-threats-with-guardduty安装后在 Claude Code 中输入/detecting-cloud-threats-with-guardduty确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
LICENSEreferences/api-reference.mdscripts/agent.py详细介绍
使用 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 保护、EKS 审计日志监控、运行时监控、恶意软件防护、RDS 登录活动以及 Lambda 网络活动监控。
# Enable GuardDuty as organization delegated administrator
aws guardduty create-detector \
--enable \
--finding-publishing-frequency FIFTEEN_MINUTES \
--data-sources '{
"S3Logs": {"Enable": true},
"Kubernetes": {"AuditLogs": {"Enable": true}},
"MalwareProtection": {"ScanEc2InstanceWithFindings": {"EbsVolumes": true}}
}'
# Enable Runtime Monitoring for EC2 and ECS
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"}
]}
]'
# Designate delegated admin for multi-account
aws guardduty enable-organization-admin-account \
--admin-account-id 111122223333
步骤 2:配置多账户聚合
自动注册所有组织成员账户,并配置将发现结果导出到集中式 S3 存储桶,以便保留和接入 SIEM。
# Auto-enable GuardDuty for all org members
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"}
]'
# Configure finding export to 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 将发现结果分为四个严重级别:严重、高、中、低。每种发现结果类型都遵循 ThreatPurpose:ResourceType/ThreatName 格式。扩展威胁检测会生成攻击序列发现结果,将跨时间的多个事件关联起来。
主要发现结果类别:
- Recon:端口扫描、API 枚举(例如 Recon:EC2/PortProbeUnprotectedPort)
- UnauthorizedAccess:凭证滥用、来自异常位置的控制台登录
- CryptoCurrency:在实例上检测到挖矿活动(例如 CryptoCurrency:EC2/BitcoinTool.B)
- Impact:资源劫持、数据破坏尝试
- AttackSequence:将初始访问、横向移动到影响关联起来的多阶段攻击(严重级别)
步骤 4:使用 EventBridge 构建自动化响应
创建 EventBridge 规则,将 GuardDuty 发现结果路由到 Lambda 函数,以执行自动化遏制操作,例如隔离受入侵的 EC2 实例、吊销 IAM 凭证或阻止恶意 IP 地址。
# EventBridge rule for high/critical GuardDuty findings
aws events put-rule \
--name GuardDutyHighSeverity \
--event-pattern '{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [{"numeric": [">=", 7]}]
}
}'
# Target Lambda function for auto-remediation
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')
# Create isolation security group (no inbound/outbound rules)
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
)
# Replace all security groups with isolation group
ec2.modify_instance_attribute(
InstanceId=instance_id,
Groups=[isolation_sg['GroupId']]
)
# Tag instance for investigation
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 中的多个信号关联起来。这些发现结果代表多阶段攻击,例如通过受损凭证进行初始访问,随后进行持久化、横向移动和加密货币挖矿。
# List critical attack sequence findings
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"]}
}
}'
# Get full finding details with attack sequence timeline
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 平台,以实现长期保留和跨源关联。
# Verify GuardDuty integration with Security Hub
aws securityhub get-enabled-standards
# Enable Amazon Security Lake with GuardDuty as a source
aws securitylake create-data-lake \
--configurations '[{
"region": "us-east-1",
"lifecycleConfiguration": {
"expiration": {"days": 365}
}
}]'
关键概念
| 术语 | 定义 |
|---|---|
| 扩展威胁检测 | GuardDuty 功能,通过关联跨越时间的多个信号来检测多阶段攻击,生成 Critical 严重级别的攻击序列发现 |
| 运行时监控 | 保护计划,将安全 Agent 部署到 EC2 实例、ECS 任务和 EKS Pod,以在操作系统级别检测运行时威胁 |
| 发现严重级别 | 四级分类(Low、Medium、High、Critical),其中 Critical 表示已确认的多阶段攻击,需要立即响应 |
| 恶意软件防护 | 由可疑 EC2 行为触发的按需和自动 EBS 卷扫描,无需安装 Agent 即可检测恶意软件 |
| 委派管理员 | 被指定管理 AWS Organization 中所有账户的 GuardDuty 的组织成员账户 |
| 抑制规则 | 自动归档符合特定条件的发现的过滤器,以减少已知良性活动产生的噪音 |
| 威胁情报 | 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 发现,严重级别为 High。运行时监控检测到容器内执行了挖矿二进制文件。
处理方法:
- 查看发现详情,识别 ECS 集群、任务定义和容器镜像
- 立即停止受影响的 ECS 任务,并在 ECR 中隔离容器镜像
- 检查 CloudTrail 中的 ecs:RegisterTaskDefinition 和 ecs:RunTask 调用,以识别谁部署了恶意镜像
- 使用 ECR 增强扫描扫描 Docker 镜像,以识别嵌入的挖矿二进制文件
- 审查用于推送镜像的 IAM 凭证,并撤销已泄露的访问权限
- 审查 ECR 镜像扫描策略,以阻止具有已知挖矿签名的镜像
陷阱:停止任务而不保留容器镜像会丢失取证证据。未能追溯到 RegisterTaskDefinition API 调用会遗漏初始入侵媒介。
输出格式
GuardDuty Threat Detection Summary
====================================
Account: 123456789012 (production)
Region: us-east-1
Period: 2025-02-01 to 2025-02-23
CRITICAL FINDINGS (Immediate Action Required):
[CRIT-001] AttackSequence:EC2/CompromisedInstanceGroup
- Instances: i-0abc123def, i-0def456abc
- Attack Chain: Credential theft -> Persistence -> Crypto mining
- First Signal: 2025-02-15T08:23:00Z
- Duration: 4 hours across 3 stages
- Status: Auto-isolated via Lambda
HIGH FINDINGS:
[HIGH-001] UnauthorizedAccess:IAMUser/MaliciousIPCaller
- Principal: arn:aws:iam::123456789012:user/ci-deploy
- Source IP: 198.51.100.42 (Tor exit node)
- API Calls: 47 calls to ec2:RunInstances
- Status: Access key deactivated
[HIGH-002] CryptoCurrency:Runtime/BitcoinTool.B
- Resource: ECS Task arn:aws:ecs:us-east-1:123456789012:task/cluster/task-id
- Image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/app:v2.1
- Process: /tmp/.hidden/xmrig --pool stratum+tcp://pool.example.com:3333
- Status: Task stopped, image quarantined
STATISTICS:
Total Findings: 23
Critical: 1 | High: 3 | Medium: 8 | Low: 11
Auto-Remediated: 4
Pending Investigation: 2