📌 結論:EC2の「社員証」が盗まれて外部で悪用されている!
EC2インスタンスに付与されたIAMロールの一時的な認証情報(セッショントークン)が、
本来のEC2インスタンス以外の場所からAWSのAPIを呼び出すのに使用されました。
これは認証情報が漏洩し、攻撃者に悪用されている可能性を示す重大なアラートです。
何が起きた?
EC2の認証情報が
外部から使用された
なぜ危険?
攻撃者がAWSリソースに
不正アクセス可能
最優先アクション
IAMロールの
セッション即時無効化
再発防止
IMDSv2の強制と
最小権限の原則
📋 2種類のアラートを理解する
🏢 高級マンションの「社員証盗難事件」で理解する!
🎭 シナリオ:あなたは高級マンションの管理人
あなたが管理するマンション(AWSアカウント)には、各部屋(EC2インスタンス)があります。
各部屋の住人は専用の社員証(IAMロール認証情報)を持っていて、
この社員証で共用施設(S3、RDS、他のAWSサービス)にアクセスできます。
🎯 攻撃の流れ
🔓 SSRF攻撃による認証情報の窃取
⚠️ IMDSv1では、単純なGETリクエストで認証情報が取得できてしまう!
🏢 マンションのたとえで言うと...
正常な状態:社員証は各部屋の中でしか使えない(認証情報はEC2内でのみ使用)
異常な状態:泥棒が社員証をコピーして、マンション外から共用施設を使っている!
GuardDutyは「この社員証、本来の部屋(EC2)じゃない場所から使われてるぞ!」と警報を鳴らしました。
🔐 IMDSv1 vs IMDSv2 - なぜv2が重要か
🛠️ インシデント対応の5ステップ
🔴 認証情報の無効化
被害拡大を即座に止める
🟠 インスタンス隔離
侵害された環境を隔離
🔵 被害範囲の調査
CloudTrailで不正操作を特定
🟢 復旧と再発防止
根本原因の解決と対策実装
- ✓ GuardDutyの検出結果から該当のIAMロール名を特定
- ✓ 該当ロールに「過去のセッションを無効化」するインラインポリシーを追加
- ✓ これにより、既存の認証情報は即座に無効化される
- ✓ 隔離用セキュリティグループを適用(全通信を拒否)
- ✓ ⚠️ インスタンスは停止・終了しない(フォレンジック調査のため)
- ✓ EBSスナップショットを取得して証拠を保全
- ✓ GuardDutyの検出結果から不正なIPアドレスを確認
- ✓ CloudTrailで該当IAMロールのすべてのAPI呼び出しを調査
- ✓ 新規作成されたリソース(IAMユーザー、アクセスキー等)がないか確認
- ✓ S3バケットへのアクセス、データ漏洩の有無を確認
- ✓ EC2インスタンスのアプリケーションログを確認
- ✓ SSRF脆弱性(ユーザー入力をURLに使用している箇所)を調査
- ✓ IMDSへのアクセスログ(169.254.169.254)を確認
- ✓ RCE(リモートコード実行)の痕跡がないか確認
- ✓ 新しいEC2インスタンスを作成(侵害されたインスタンスは破棄)
- ✓ IMDSv2を強制適用
- ✓ IAMロールの権限を最小権限に見直し
- ✓ 脆弱性のあったアプリケーションを修正
🤖 EventBridge + Lambda による自動対応
⚡ Lambda関数(Python)- 自動対応
📡 EventBridgeルール
📦 IMDSv2強制のCloudFormationテンプレート
✅ インシデント対応チェックリスト
🔴 初動対応(0-15分)
- GuardDutyの検出結果を確認
- IAMロール名を特定
- セッション無効化ポリシーを適用
- EC2インスタンスを隔離
- 関係者に通知
🔵 調査(15-60分)
- CloudTrailでAPI呼び出しを調査
- 不正なリソース作成がないか確認
- S3アクセスログを確認
- 侵入経路を特定
- EBSスナップショットを取得
🟢 復旧(1-24時間)
- 新しいEC2インスタンスを作成
- IMDSv2を強制適用
- アプリケーションの脆弱性を修正
- IAMロールの権限を見直し
- 侵害されたインスタンスを終了
🟣 再発防止(継続)
- SCPでIMDSv2を組織全体で強制
- 自動対応Lambdaを設定
- インシデント報告書を作成
- チームに教訓を共有
- 定期的なセキュリティ監査を計画
🛡️ 多層防御による再発防止
(守られている!)
IMDSv2の強制
- HttpTokens=requiredを設定
- HttpPutResponseHopLimit=1でコンテナ保護
- 既存インスタンスも順次移行
- 起動テンプレートでデフォルト化
最小権限の原則
- IAMロールに必要最小限の権限のみ
- ワイルドカード(*)の使用を避ける
- リソースレベルの制限を設定
- 定期的な権限の棚卸し
SCPによる組織統制
- IMDSv1でのインスタンス起動を禁止
- 全アカウントに一括適用
- 例外管理のプロセスを整備
- コンプライアンスの自動化
継続的な監視
- GuardDutyアラートの自動通知
- Config Rulesでコンプライアンス監視
- Security Hubで一元管理
- 定期的なセキュリティ監査
❓ よくある質問
✅ VPN/Direct Connect経由:オンプレミスから正規にアクセスしている場合
✅ NAT Gateway経由:別のVPCのEC2からNAT経由でアクセスしている場合
✅ プロキシサーバー経由:正規のプロキシを使用している場合
✅ AWS Lambda:EC2の認証情報を正規に使用するLambda
判断のポイント:
1. 発信元IPアドレスは既知のものか?
2. 実行されたAPIは正常な業務に関連するか?
3. 時間帯は通常の業務時間内か?
⚠️ ただし、誤検知の判断は慎重に行い、まずは対応を優先してください。
EC2のIAMロールが発行する一時的な認証情報(STSトークン)は、最大12時間有効です。
EC2インスタンスの状態に関係なく、有効期限が切れるまで使用可能です。
正しい対処:
1. IAMロールに「セッション無効化ポリシー」を追加
2. これにより、ポリシー追加前に発行された全セッションが無効化される
3. その上でEC2を隔離・調査
🔴 .OutsideAWS(重大度: 8.0)
認証情報がAWS外部(インターネット上の攻撃者サーバー等)から使用されています。
これは明らかな攻撃であり、認証情報が完全に漏洩していることを意味します。
🟠 .InsideAWS(重大度: 7.5)
認証情報が別のAWSアカウントやリージョンから使用されています。
攻撃者が別のAWSアカウントを持っている場合や、侵害された別のEC2を踏み台にしている可能性があります。
いずれにせよ、即座に対応が必要です。
確認が必要なケース:
• 古いAWS SDK(2019年以前のバージョン)を使用している場合
• IMDSに直接curlでアクセスしているスクリプトがある場合
• コンテナ環境でホップ数制限の影響を受ける場合
移行手順:
1. まず「optional」モードでIMDSv2を有効化
2. CloudWatchでIMDSv1アクセスを監視(MetadataNoToken メトリクス)
3. IMDSv1へのアクセスがなくなったら「required」に変更
AWS SDKは自動的にIMDSv2を使用するため、通常は問題が発生しません。
🎓 まとめ
アラートの意味
EC2の認証情報が
外部から悪用されている
最優先対応
IAMロールの
セッション即時無効化
調査のポイント
CloudTrailで
不正API呼び出しを確認
根本対策
IMDSv2の強制で
SSRF攻撃を防止
組織統制
SCPで組織全体に
IMDSv2を強制