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 を含むすべての保護プランを有効にします。

# 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 は検出結果を、Critical、High、Medium、Low の 4 つの重大度レベルに分類します。各検出結果の種類は ThreatPurpose:ResourceType/ThreatName という形式に従います。Extended Threat Detection は、複数のイベントを時間軸に沿って関連付けた攻撃シーケンスの検出結果を生成します。

主な検出結果のカテゴリ：

• Recon：ポートスキャン、API の列挙（例：Recon:EC2/PortProbeUnprotectedPort）
• UnauthorizedAccess：認証情報の不正使用、通常とは異なる場所からのコンソールログイン
• CryptoCurrency：インスタンス上で検出されたマイニング活動（例：CryptoCurrency:EC2/BitcoinTool.B）
• Impact：リソースの乗っ取り、データ破壊の試み
• AttackSequence：初期アクセスからラテラルムーブメント、影響に至る複数段階の攻撃を関連付けたもの（重大度 Critical）

ステップ 4：EventBridge で自動対応を構築する

GuardDuty の検出結果を Lambda 関数にルーティングする EventBridge ルールを作成し、侵害された 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：Extended Threat Detection の攻撃シーケンスを調査する

EC2、ECS、EKS にまたがる複数のシグナルを関連付けた、重大度 Critical の攻撃シーケンスの検出結果を確認します。これらの検出結果は、侵害された認証情報による初期アクセスに続き、永続化、ラテラルムーブメント、暗号資産のマイニングへと進むような、複数段階の攻撃を示します。

# 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」の攻撃シーケンスの検出結果を生成します
ランタイムモニタリング	EC2 インスタンス、ECS タスク、EKS ポッドにセキュリティエージェントをデプロイし、OS レベルでランタイムの脅威を検出する保護プランです
検出結果の重大度	4 段階（Low、Medium、High、Critical）の分類です。Critical は、即時対応が必要な、確認済みの多段階攻撃を示します
マルウェア保護	不審な EC2 の挙動をきっかけに実行される、オンデマンドおよび自動の EBS ボリュームスキャンです。エージェントをインストールせずにマルウェアを検出します
委任管理者	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 タスクを対象とする、重大度が High の 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 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