mcpField
D
detecting-cloud-threats-with-guardduty

detecting-cloud-threats-with-guardduty

github.com/mukul975安全35.2k65 次安装8 周前更新
代码仓库

关于 detecting-cloud-threats-with-guardduty

面向 AWS 安全团队的 GuardDuty 威胁检测技能,涵盖多账户保护、告警分析及自动响应,并可将发现汇总到 Security Hub 或 SIEM。

主要功能

  1. 01启用 GuardDuty 保护计划
  2. 02集中管理多账户发现
  3. 03分析威胁类型与严重级别
  4. 04通过 EventBridge 自动响应
  5. 05关联 Security Hub 与 SIEM

适用场景

  1. 01为 AWS 账户配置持续威胁检测
  2. 02调查凭证滥用或数据外传告警
  3. 03自动隔离受感染的 EC2 实例
  4. 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 外,安装时一起下载的参考资料和脚本。

LICENSE
references/
api-reference.md
scripts/
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。运行时监控检测到容器内执行了挖矿二进制文件。

处理方法:

  1. 查看发现详情,识别 ECS 集群、任务定义和容器镜像
  2. 立即停止受影响的 ECS 任务,并在 ECR 中隔离容器镜像
  3. 检查 CloudTrail 中的 ecs:RegisterTaskDefinition 和 ecs:RunTask 调用,以识别谁部署了恶意镜像
  4. 使用 ECR 增强扫描扫描 Docker 镜像,以识别嵌入的挖矿二进制文件
  5. 审查用于推送镜像的 IAM 凭证,并撤销已泄露的访问权限
  6. 审查 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

评论

支持 Markdown