【解説】AWS CloudTrail を使ったインシデント調査・対応ガイド パート1 を読み解く

AWS 公式ブログで、AWS の Security Incident Response Team（SIRT）が実際に使っている調査の考え方をまとめたガイドが公開されました。

• 元記事：AWS CloudTrail を使ったインシデント調査・対応ガイド – パート 1（AWS ブログ）
• 英語原文：Incident response guide for AWS CloudTrail investigations – Part 1
• 日本語版公開日：2026年10月15日（英語原文は2026年9月3日）

「CloudTrail は有効にしているけれど、いざ何か起きたときにどこを見ればいいのか分からない」という方にとって、非常に実践的な内容です。本記事では、元記事のポイントを整理しつつ、現場で使うための補足を加えて解説します。

この記事で分かること

• インシデント調査で頻出する用語（偵察・ラテラルムーブメント・永続化など）
• シナリオ1：クロスアカウントロール経由での S3 データ削除（ランサムウェア関連の疑い）
• シナリオ2：MFA なしのコンソール認証情報を悪用した、CloudFormation + CloudShell による暗号通貨マイニング
• それぞれの「CloudTrail のどのフィールドを見るか」「何を問うか」「どう防ぐか」

前提：まず押さえておきたい用語

元記事では冒頭で用語の定義が整理されています。調査レポートや社内共有で頻出するので、ざっくり把握しておくと読みやすくなります。

SSRF や IMDSv1 といった用語も定義されていますが、これらは主にパート2のシナリオで登場します。IMDSv1 自体が危険なのではなく、「SSRF に弱いアプリが乗っていると、メタデータ経由で認証情報を抜かれ得る」という整理になっている点は押さえておきたいところです。

シナリオ1：クロスアカウントロール経由の S3 データ削除

何が起きたか

SOC に「customer-important-data バケットから複数オブジェクトが削除された」というアラートが届きます。一見すると「誰が消したかを確認すれば終わり」の案件ですが、掘り下げるとクロスアカウントのロールを悪用した計画的な攻撃だった、というストーリーです。

攻撃の流れは以下のとおりです。

1. 信頼された別アカウントから CrossAccountS3Access ロールを AssumeRole
2. ListBuckets でバケット一覧を取得（偵察）
3. 標的バケット内のオブジェクトを一覧表示
4. 価値の高いファイルをコピー（持ち出し）
5. 約14分の空白の後、13秒間で3ファイルを削除（財務レポート・顧客 PII・本番 DB バックアップ）

調査のポイント①：セッション名を疑う

AssumeRole 時にはセッション名を自由に付けられます。今回の攻撃者は dev-migration-script のような、いかにも開発作業っぽい名前を使っていました。

企業環境ではクロスアカウントアクセスもスクリプト実行も日常的なので、こうした名前は運用ノイズに紛れやすいのが厄介な点です。元記事では、この名前を送信元 IP や過去のデプロイ記録と照らし合わせ、「そんな移行プロジェクトは存在しない」と確認できたことが最初の突破口になっています。

💡 補足：元記事内では、CloudTrail のログ例ではセッション名が threat-actor-session、S3 アクセスログ例では dev-migration-script と表記されています。元記事でも注記されている通り、説明用の表記揺れなので同一セッションとして読んでください。

調査のポイント②：CloudTrail で見るべきフィールド

なお、オブジェクト単位の削除（DeleteObject）は CloudTrail ではデータイベント扱いのため、データイベントを有効にしていないと CloudTrail には記録されません。元記事でも S3 サーバーアクセスログを併用して削除を裏付けています。「管理イベントだけ有効」の環境は意外と多いので、自社の設定を一度確認しておくことをおすすめします。

調査のポイント③：タイミングから「人かスクリプトか」を判断する

• 削除が6〜7秒間隔で規則正しく実行されている
• ユーザーエージェントは Linux 上の AWS CLI
• バケット全削除ではなく、重要な3ファイルだけを狙い撃ち

ここから、「事前に標的を選定し、スクリプトで一気に実行した」と推測できます。偵察と削除の間の14分間に同セッションのイベントが無いことも、「その間に攻撃計画を練っていた」という読みを補強しています。

手作業の侵入とスクリプトによる攻撃では、封じ込めのスピード感や想定すべき再発パターンが変わるため、この見極めは重要です。

調査の優先順位の付け方

元記事では、優先順位を次の3軸で考えるとしています。

1. 封じ込めの緊急性：攻撃者はまだアクセスできる状態か
2. 規制・ビジネス影響：機密データが漏えい・持ち出しされたか
3. 影響範囲：他のリソースやアカウントに広がり得るか

具体的には「ロールへのアクセスをどう得たのか（信頼ポリシーと変更履歴、両アカウントの認証イベント）」「削除前にコピーされていないか（GetObject / CopyObject）」「なぜそのファイルが狙われたのか」を問いとして立てています。特に PII が含まれる場合は、法令上の通知義務の判断にも直結します。

対応チェックリスト（要約）

• そのクロスアカウントアクセスに正当なビジネス上の理由があるか
• ロールがどう引き受けられたかを示す認証イベントの特定
• このロールで S3 以外に触れられるリソースの洗い出し
• 成功イベント以前の失敗試行・偵察の有無
• 信頼関係がいつ作られ、最後にアクセスレビューされたのはいつか
• 削除データのバックアップの所在
• 同様の行動を検知するルールの検討

予防の観点（筆者補足）

元記事の教訓を、具体的な設定に落とすと以下のようになります。

• クロスアカウントロールの最小権限化：s3:* のような広い権限を付けない。信頼ポリシーで sts:ExternalId や送信元条件を絞る
• S3 バージョニング／Object Lock：削除されても復元できる状態にしておく。バックアップを同じバケット・同じ権限で守らない
• データイベントの記録：重要バケットだけでも S3 データイベントを有効化
• IAM Access Analyzer：外部アカウントに共有されているロールやリソースを定期的に棚卸し

参考：S3 Object Lock（AWS ドキュメント） / IAM Access Analyzer（AWS ドキュメント）

シナリオ2：CloudFormation + CloudShell による暗号通貨マイニング

何が起きたか

きっかけはセキュリティアラートではなく、財務チームが気付いた us-east-1 の EC2 料金の急増です。調べると、誰も作った覚えのない CRYPTO という名前の CloudFormation スタックが見つかり、本番 VPC 内でマイニング用 EC2 が動いていました。

攻撃の流れは以下のとおりです。

1. MFA で保護されていないコンソール認証情報を入手
2. マネジメントコンソールにサインイン
3. us-east-1 に CloudFormation スタック CRYPTO を作成
4. スタックがパブリックサブネットにマイニング用 EC2 をデプロイ
5. コンピューティングリソースを消費し続ける

調査のポイント①：CreateStack イベントから読み取れること

元記事では、CreateStack の CloudTrail レコードを題材に「ここから何が読み取れるか」をクイズ形式で問いかけています。注目フィールドは以下の通りです。

調査のポイント②：「コンソールなのに CLI」の意味

このシナリオで一番面白いのがここです。

• sessionCredentialFromConsole: true → コンソールにサインインしたセッション
• userAgent に exec-env/CloudShell → 実際の操作はブラウザ内の CloudShell から CLI で実行

つまり攻撃者は、コンソールの画面をポチポチ操作したのではなく、サインイン直後に CloudShell を起動し、用意済みのスクリプトを流したということです。セッション開始からスタック作成まで約50秒という速さもそれを裏付けています。

この手口だと、自動化のスピードを得つつ、「長期アクセスキーの不審な利用」を見張る従来型の監視には引っかかりにくくなります。「アクセスキーの監視だけしていれば安心」ではない、というのが大きな示唆です。

調査の進め方（3フェーズ）

元記事では調査を3段階に分け、前の結果を次に活かす進め方を紹介しています。

1. コンソールセッションのタイムライン再構築
   同じセッションで CloudTrail を絞り込み、スタック作成の前後に偵察・他リージョンでの活動・IAM ユーザーやアクセスキー作成（永続化）がないかを確認。マイニング以外の行動があれば、別の目的も疑う。
2. スタックが実際に何を作ったかを確認
   テンプレートからインスタンスタイプ、セキュリティグループ、カスタム AMI やユーザーデータ、スタック独自の IAM ロールの有無を調べる。テンプレート自体が証拠であり、S3 にホストされていればアップロード時刻から準備時期も追える。
3. ビジネス影響と影響範囲の算出
   稼働時間 × 単価でコストを算出。本番 DB などへのネットワーク経路、マイニングプールへの通信、他リージョン・他アカウントに類似スタックがないかを確認。マイニングプール以外への外向き通信があれば、データ持ち出しとの「二刀流」も疑う。

対応チェックリスト（要約）

• なぜ MFA が必須になっていなかったのか
• 認証情報がどこから漏れたのか、成功前にサインイン失敗はなかったか
• 同セッション中の他のアクティビティ
• スタックが作ったリソース、その稼働期間とコスト
• 類似名・不審なスタックの横断検索
• インスタンスからの内部・外部への通信（特にマイニングプール）
• 新規 IAM ユーザー／ロール、追加アクセスキー、既存権限やポリシーの変更有無

予防の観点（筆者補足）

• MFA の必須化：元記事でも、今回の攻撃全体を可能にしたのは MFA の欠如だと明言されています。IAM Identity Center への移行や、SCP・IAM ポリシーで MFA を条件にする運用も検討を
• コスト監視＝セキュリティ監視：AWS Cost Anomaly Detection で異常な請求増を早期に通知
• Amazon GuardDuty：EC2 からマイニングプール関連ドメイン・IP への通信など、暗号通貨マイニング系の検出結果を提供（検出結果タイプ一覧）
• 未使用リージョンの制限：SCP で使わないリージョンを拒否すると、「監視の薄いリージョンで動く」防御回避を封じやすくなる
• CloudShell の利用制御：業務上不要なら IAM ポリシーで CloudShell の利用を制限する

実践Tips：Athena で調査クエリを書くなら

元記事にはクエリ例は載っていませんが、CloudTrail ログを Athena でテーブル化している場合、今回の観点は以下のように確認できます（テーブル名・列名は環境に合わせて調整してください）。

特定セッション（ロール + セッション名）の行動をすべて時系列で出す

SELECT eventtime, eventsource, eventname, awsregion,
       sourceipaddress, useragent, errorcode
FROM cloudtrail_logs
WHERE useridentity.arn LIKE '%assumed-role/CrossAccountS3Access/%'
  AND eventtime BETWEEN '2025-01-20T14:00:00Z' AND '2025-01-20T15:30:00Z'
ORDER BY eventtime;

MFA なしのコンソールセッションで実行された CreateStack を探す

SELECT eventtime, useridentity.arn, awsregion, useragent,
       json_extract_scalar(requestparameters, '$.stackName') AS stack_name
FROM cloudtrail_logs
WHERE eventsource = 'cloudformation.amazonaws.com'
  AND eventname = 'CreateStack'
  AND useridentity.sessioncontext.attributes.mfaauthenticated = 'false'
ORDER BY eventtime DESC;

同じ送信元 IP からの行動を横断検索する

SELECT eventtime, useridentity.arn, eventsource, eventname, awsregion
FROM cloudtrail_logs
WHERE sourceipaddress = '203.0.113.47'
ORDER BY eventtime;

参考：Athena で CloudTrail ログをクエリする（AWS ドキュメント）

2つのシナリオから見える共通原則

元記事の結論は、「何が起きたか」だけでなく「どのように・なぜ起きたか」まで突き止めて初めて、封じ込めと再発防止ができるというものです。

個人的に特に実務で効くと感じたのは次の3点です。

1. 名前は信用しない、でも手がかりにはする：セッション名やスタック名は攻撃者が自由に付けられる。正規っぽい名前は偽装の、露骨な名前は油断の痕跡になり得る
2. userAgent とセッション属性はセットで見る：「コンソール由来なのに CLI 実行」のような矛盾が、手口の解明につながる
3. コストとセキュリティを分けない：請求アラートの受け手がセキュリティチームにも連携される体制づくりが大事

パート2の予告

パート2では、Web アプリの SSRF 脆弱性から IMDSv1 経由で認証情報が盗まれ、リージョンをまたいで Amazon Bedrock が悪用されるシナリオが扱われる予定です。ルートユーザーと「root という名前の IAM ユーザー」の見分け方、ロール名の模倣、HIDDEN_DUE_TO_SECURITY_REASONS というユーザー名表示のトリックなど、さらに踏み込んだ調査テクニックも紹介されるとのことです。こちらも解説記事を書く予定です。

まとめ

• CloudTrail は「有効にするだけ」では不十分。どのフィールドをどう読むかを事前に知っておくことが、インシデント時の調査スピードを決める
• userIdentity（特に arn・セッション名・mfaAuthenticated）、sourceIPAddress、userAgent、sessionCredentialFromConsole、eventTime は真っ先に見るべきフィールド
• S3 データイベントや Athena でのクエリ環境など、調査に必要な土台は平時に整えておくのが重要

インシデント対応の初動に関わる方は、ぜひ元記事のログ注釈付きの解説も合わせて読んでみてください。

本記事は、AWS 公式ブログ「AWS CloudTrail を使ったインシデント調査・対応ガイド – パート 1」（2026年10月15日公開の日本語版）をもとに整理し、筆者の補足を加えたものです。AWS の機能や設定項目は変更される可能性があるため、実際の設定時は必ず公式ドキュメントをご確認ください。

参考情報

• AWS CloudTrail を使ったインシデント調査・対応ガイド – パート 1（AWS ブログ）
• Incident response guide for AWS CloudTrail investigations – Part 1（AWS Security Blog）
• AWS CloudTrail を使ったインシデント調査・対応ガイド – パート 2（AWS ブログ）
• Athena で CloudTrail ログをクエリする（AWS ドキュメント）
• S3 Object Lock（AWS ドキュメント）
• IAM Access Analyzer（AWS ドキュメント）
• AWS Cost Anomaly Detection（AWS ドキュメント）
• GuardDuty の検出結果タイプ（AWS ドキュメント）