Amazon Web Services ブログ
AWS CloudTrail を使ったインシデント調査・対応ガイド – パート 1
本ブログは 2026 年 9 月 3 日に公開された AWS Blog “Incident response guide for AWS CloudTrail investigations – Part 1” を翻訳したものです。
AWS CloudTrail ログには、AWS 環境で疑わしいアクティビティを調査するために必要な証拠が含まれています。ただし、どのフィールドが重要で、それをどう解釈すべきかを理解しているかどうかで、分析が表面的なもので終わるか、インシデントの全容を解明できるかが変わります。このガイドでは、実際のシナリオに沿って CloudTrail イベントを分析し、クロスアカウントの不正アクセス、暗号通貨マイニング、AI サービスの悪用を明らかにする方法を説明します。AWS の Security Incident Response Team (SIRT) が脅威への対処に使用している調査手法と、お客様の調査に適用できる実践的な方法論を紹介します。
各シナリオには次の内容が含まれます。
- イベントの進行を示すアーキテクチャ図
- 重要なフィールドを強調した注釈付きの CloudTrail ログ
- 確認すべき具体的な質問を含む調査フレームワーク
- 教訓と予防策
このガイドは、セキュリティ運用、クラウドエンジニアリング、コンプライアンスの担当者や組織のリーダー層に、基本的な CloudTrail クエリにとどまらず、包括的なセキュリティ分析を行うために必要な調査の考え方を提供します。
インシデント対応の用語定義
このガイドでは、インシデント対応や脅威インテリジェンスで一般的に使用される用語が随所に登場します。セキュリティ運用、クラウドエンジニアリング、コンプライアンスの担当者や組織のリーダー層など、さまざまなバックグラウンドを持つ読者にとって理解しやすいよう、主要な用語の定義を以下に示します。
- 偵察 (Reconnaissance): 脅威アクターが行動を起こす前に、何が利用可能かを把握するために標的環境の情報を収集する初期段階です (例えば、Amazon Simple Storage Service (Amazon S3) バケットの一覧表示や利用可能なリソースの閲覧)。
- 列挙 (Enumeration): 潜在的な標的やアクセス経路を特定するために、環境内の特定のリソース、ユーザー、設定を体系的に洗い出すことです。
- ラテラルムーブメント (Lateral movement): 脅威アクターがアクセスを拡大するために、同じ環境内であるリソースから別のリソースへと移動することです (例えば、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスから AI サービスへのピボット)。
- 権限昇格 (Privilege escalation): 管理者ユーザーの作成や AWS Identity and Access Management (IAM) ポリシーの変更を試みるなど、最初に取得したものより上位の権限を得ようとすることです。
- 防御回避 (Defense evasion): 監視が手薄な可能性のある別の AWS リージョンで活動したり、不正なリソースに正規のものに見える名前を付けたりするなど、検出を逃れるための手法です。
- 永続化 (Persistence): 元の侵入口が閉じられても脅威アクターが再び戻ってこられるよう、環境への継続的なアクセスを確立することです (例えば、新しい IAM ユーザーやアクセスキーの作成)。
- 認証情報の窃取 (Credential harvesting): 正規のユーザーやロールになりすますために、認証情報 (パスワード、アクセスキー、一時トークン) を盗むことです。
- サーバーサイドリクエストフォージェリ (SSRF): 不正なユーザーがサーバーをだまし、自身に代わってリクエストを送信させるウェブアプリケーションの攻撃手法です。Amazon EC2 インスタンスメタデータサービス (IMDS) エンドポイントなどの内部サービスへのアクセスによく使われます。詳細については、「Understanding SSRF」を参照してください。
- IMDSv1 (インスタンスメタデータサービス v1): Amazon EC2 インスタンスメタデータサービスバージョン 1 (IMDSv1) は、インスタンス上で実行されているアプリケーションに一時的な認証情報を提供します。IMDSv1 自体が本質的に安全でないわけではありません。しかし、問題のあるアプリケーション (例えば、SSRF の影響を受けやすいもの) がインスタンス上で実行されている場合、不正なユーザーはそのアプリケーションを利用してメタデータエンドポイントに到達し、認証情報を取得できます。IMDSv2 では、セッションベースの認証トークンを必須とすることで、このリスクを軽減しています。
- 侵害の痕跡 (IOC): 不正なアクティビティが発生したことを示唆する、観測可能なアーティファクト (IP アドレス、ユーザーエージェント、セッション名、リソース名) です。
- データの持ち出し (Exfiltration): 削除前にファイルをコピーするなど、環境の外部へデータを不正に転送することです。
- イベントチェーン (Event chain): 脅威アクターが初期アクセスから目的の達成までにたどる一連のステップです。各ステップが次のステップへの足がかりとなります。
- ピボット (Pivot): セキュリティイベントの最中に、ある手法、サービス、リージョンから別のものへ切り替えることです。最初のアプローチがブロックされた後や、検出を回避するために行われることがよくあります。
シナリオ 1: ランサムウェアとの関連が疑われるクロスアカウントでの S3 データ削除
AWS ではクロスアカウントアクセスが必要になる場合がありますが、設定を誤るとセキュリティリスクが生じます。このシナリオでは、セキュリティオペレーションセンターが、customer-important-data S3 バケットから複数のオブジェクトが削除されたという自動アラートを受け取りました。初期対応は単純に思えます。CloudTrail ログを確認し、誰がオブジェクトを削除したのかを特定し、それが承認された操作かどうかを判断すればよいからです。しかし、AWS の SIRT がさらに調査を進めると、単純な不正削除に見えたものが、実はランサムウェアとの関連が疑われるクロスアカウントのインシデントであることが判明しました。CloudTrail の分析では、パターンを見抜き、コンテキストを理解し、脅威アクターの視点で考えることが求められます。
シナリオのアーキテクチャ
図 1 は、信頼されたアカウントからアクセスし、S3 バケットのオブジェクトを削除するまでのアーキテクチャを示しています。流れは次のとおりです。
- 脅威アクターが、信頼されたアカウントから
CrossAccountS3Accessロールを引き受けます。 - 標的を特定するために S3 バケットを一覧表示します (ListBuckets API コール)。
- 標的のバケット内のオブジェクトを一覧表示し、内容を把握します。
- スクリプトを使用して、13 秒以内に 3 つのファイルを削除します。
- 各削除で HTTP 204 (成功) ステータスコードが返されます。
図 1: シナリオ 1 のアーキテクチャ
偵察フェーズ
調査ではまず CloudTrail ログを確認しました。その結果、不正なアクティビティは、多くのアナリストが日常的な操作として見過ごしてしまいそうなものから始まっていたことがわかりました。14:31:22 UTC に、引き受けたロールを通じて実行された ListBuckets API コールです。CloudTrail エントリには、dev-migration-script という名前のセッションが記録されており、CrossAccountS3Access ロールが使用されていました (直後の CloudTrail ログ例では、セッション名が threat-actor-session と表記されています)。
エンタープライズ環境ではクロスアカウントアクセスは一般的であり、セッション名には通常、正規の事業部門が反映されます。攻撃者はなりすまし (マスカレード) の手法を多用し、一般的な開発タスクや自動化スクリプトを思わせる名前をセッションに付けることで、日常の運用ノイズに紛れ込もうとします。しかし、このセッション名を外部の送信元 IP や過去のデプロイログと照合したところ、そのような移行プロジェクトは承認されていなかったことが確認されました。これは脅威アクターによる明らかな検出回避の試みであり、不正アクセスを示す最初の兆候でした。その 3 秒後には、バケット内のオブジェクトを一覧表示する GET リクエストがログに記録されていました。これは典型的な偵察行動です。脅威アクターは、引き受けた同じロールと同じ IP アドレスを使用して、利用可能な標的を洗い出していました。次のログの arn と eventName から読み取れるこのパターンにより、脅威アクターが情報を収集し、標的を評価し、攻撃の段取りを計画していたことがわかりました。
体系的な削除
14:31:25 UTC に偵察を終えた脅威アクターは、その後 14 分間沈黙し、14:45:12 UTC に最初の削除を実行しました。この間、脅威アクターは列挙したばかりのオブジェクトの一覧を確認し、最も価値の高い標的 (財務データ、個人を特定できる情報 (PII)、データベースバックアップ) を選び、準備が整い次第すばやく実行できるよう自動削除スクリプトを用意していたと考えられます。この準備期間の存在は、いくつかの要因から推測できます。14 分間にこのセッションからの CloudTrail イベントが他に記録されていないこと、その後の削除が 6～7 秒という正確な間隔で行われており、スクリプトによる実行が示唆されること、そして、バケット内のすべてを一括削除するのではなく、ビジネス上最も重要な 3 つのファイルが標的として選ばれていたことです。このように標的を選別し、スクリプトで実行するアプローチから、脅威アクターが一覧表示のフェーズで収集した偵察データを基に、実行前に標的を絞った攻撃計画を立てていたことがわかります。脅威アクターは 13 秒以内 (14:45:12～14:45:25 UTC) に、customer-important-data バケットから 3 つのファイルを削除しました。財務レポート (q4-2024.xlsx、14:45:12)、顧客の PII データベース (pii-database.csv、14:45:18)、本番データベースのバックアップ (prod-database-backup.sql、14:45:25) です。いずれの削除でも HTTP 204 ステータスコードが返されていました。Amazon S3 アクセスログからも、これらの DELETE オペレーションが成功しており、すべて同じセッションから実行されたことが確認できます。
タイミングとアクセスパターンの分析
13 秒という削除の時間枠は偶然ではありませんでした。ユーザーエージェント文字列からは Linux 上で AWS コマンドラインインターフェイス (AWS CLI) が使用されていたことがわかり、正確なタイミングからは、手動操作ではなくスクリプトによる実行であることが示唆されました。これは、標的が事前に選定され、検出される機会を最小限に抑えるために削除が自動実行されていたことを示していました。
送信元 IP がイベント全体で一貫していたため、同じ送信元からの他の疑わしいアクティビティを検索し、脅威インテリジェンスフィードと照合して、ラテラルムーブメントの試みと疑われる操作を特定できました。
また、CrossAccountS3Access ロールに広範な Amazon S3 権限が付与されていたことから、最小権限が実践されていたか、定期的なアクセスレビューが行われていたか、そしてこれほど広範なクロスアカウント権限にビジネス上の正当性があったのか、という疑問が浮かび上がりました。
調査の優先順位
設定ミスのあるクロスアカウントアクセスが悪用されてデータが削除されたことが確認できたため、次のステップは調査の優先順位付けです。インシデント対応では、優先順位は 3 つの要素で決まります。脅威アクターがまだアクセス可能な状態にあるかどうか (封じ込めの緊急性)、機密データが漏えいしたり持ち出されたりしたかどうか (規制上およびビジネス上の影響)、そして攻撃が他のリソースやアカウントに広がる可能性があるかどうか (影響範囲) です。これらの要素に基づいて、次の問いを立てて調査を進めました。
- 脅威アクターはどのようにして
CrossAccountS3Accessロールへのアクセスを得たのか? ロールの信頼ポリシーと最近の変更、信頼する側と信頼される側の両アカウントにおける認証イベント、同じ時間帯に同じロールを使用していた他のセッションを調べました。 - ファイルは削除前にコピーされたか? 削除前に同じオブジェクトに対して実行された
GetObjectオペレーション、偵察フェーズ中の異常なネットワークトラフィックパターン、データ窃取を示す可能性のあるCopyObjectアクティビティを検索しました。 - オブジェクトに特別な重要性があったか? これらのオブジェクトがなぜ重要だったのかを理解することで、ビジネスへの影響に基づいて復旧作業の優先順位を決め、PII の漏えいに伴う規制上の通知要件を評価し、バックアップの喪失によるビジネスへの影響の全容を把握できました。
対応チェックリスト
クロスアカウントでの削除の範囲を特定した後は、次のステップを実施することで、漏れのない対応と再発防止につなげることができます。
- このクロスアカウントアクセスのビジネス上の目的が正当なものかどうかを判断する
- ロールがどのように引き受けられたかを示す認証イベントを特定する
- このロールが Amazon S3 以外にアクセスできる可能性のある AWS リソースを特定する
- 成功したイベントの前に、失敗した試行や偵察アクティビティがないか確認する
- このクロスアカウントの信頼関係がいつ作成されたかを特定する
- このロールのアクセスレビューが最後にいつ実施されたかを特定する
- 削除されたデータのバックアップコピーを探す
- 今後同様のアクティビティを捕捉するための検出ルールを決定する
重要なポイント
このシナリオからは、クロスアカウントのインシデント調査全般に当てはまるいくつかの原則が見えてきます。セッション名に含まれる不自然な識別子から、脅威アクターの意図や運用セキュリティの不備が明らかになることはよくあります。ListBuckets から標的を絞った削除へと進む流れは、脅威アクターが計画的に行動していることを示しています。認証情報が漏えいすると信頼関係そのものが不正アクセスの経路になるため、クロスアカウントアクセスは特に入念に精査する必要があります。特定のファイルがなぜ重要なのかを理解することは、対応作業の優先順位付けと実際の影響の評価に役立ちます。正確なタイミングと一貫した技術的シグネチャは、多くの場合、スクリプトによるイベントであることを示しており、手動による侵入とは異なる対応戦略が求められます。
シナリオ 2: コンソールの認証情報を使用した CloudFormation による暗号通貨マイニング
このシナリオでは、財務チームが AWS コストの予期しない急増、特に us-east-1 リージョンにおける Amazon EC2 のコンピューティング料金の急増に気付きます。ここでは、脅威アクターが正規のコンソールアクセスを悪用し、AWS CloudFormation を使って暗号通貨マイニング環境をデプロイする手口と、調査担当者がリソースの乗っ取りイベントの範囲を明らかにする方法を見ていきます。調査を進めると、CRYPTO という名前の CloudFormation スタックが見つかりました。作成の記録がなく、作成されたことも把握していないスタックです。このスタックには、本番環境の Amazon Virtual Private Cloud (Amazon VPC) で実行され、大量のコンピューティングリソースを消費している EC2 インスタンスが含まれていました。直ちにセキュリティ調査が必要な状況です。
アーキテクチャとシーケンス
図 2 は、脅威アクターが認証情報を取得してからマイニングを開始するまでの流れを示しています。手順は次のとおりです。
- 脅威アクターが、多要素認証 (MFA) で保護されていないコンソールの認証情報 (ユーザー名とパスワード) を取得します。
- AWS マネジメントコンソールにアクセスします。
- us-east-1 に CloudFormation スタック
CRYPTOを作成します。 - スタックが、暗号通貨マイニング用に設定された EC2 インスタンスをパブリックサブネットにデプロイします。
- マイニング用インスタンスがコンピューティングリソースの消費を開始します。
図 2: シナリオ 2 のアーキテクチャ
以下は、不正な CreateStack アクションの CloudTrail イベントレコードです (一部の情報は伏せています)。このレコードから、次の情報を読み取れるか試してみてください。
- 作成された CloudFormation スタックの名前
- CloudFormation スタックの Amazon リソースネーム (ARN)
- 認証情報が MFA で保護されていたかどうか
- 脅威アクターがアクションを AWS マネジメントコンソールで実行したのか、それとも AWS CLI やスクリプトを使ってプログラムで実行したのか
認証とアクセスの分析
CloudTrail イベントレコードには、このシナリオの問いに答えるためのフィールドが含まれています。
スタックの概要
CloudTrail イベントから、デプロイされたスタックについて次の詳細を確認できます。
- スタック名:
CRYPTOは暗号通貨関連のアクティビティを示す指標です - スタック ARN:
arn:aws:cloudformation:us-east-1:XXXXXXXXXXXX:stack/CRYPTO/2102e190-98a8-11f0-bcea-1209335b107 - リージョン: us-east-1 (サービスをすぐに利用できるため、脅威アクターがよく選ぶリージョン)
認証とセッションコンテキストの分析
セッションのメタデータを調べると、脅威アクターがどのように認証し、環境にアクセスしたかがわかります。
- MFA ステータス:
"mfaAuthenticated": "false"は、セッションで MFA による認証がまったく行われていなかったことを示しています。 - アクセス方法:
"sessionCredentialFromConsole": "true"は、アクセスがコンソール経由で行われたことを意味します。 - ユーザーコンテキスト:
AssumedRoleとしてWSParticipantRoleを使用しています。セッションは 2025-09-23T18:06:22Z に作成されました (スタック作成の約 50 秒前)。
高度なフォレンジックの知見 (CloudShell ピボット)
sessionCredentialFromConsole: true フィールドは、このアクセスが、外部からプログラムで使用される API キーではなく、AWS コンソールから行われたことを示しており、注目すべき重要なポイントです。興味深いことに、セッションはコンソールから開始されていたものの、userAgent フィールドを見ると、実行環境は exec-env/CloudShell でした。つまり、脅威アクターは CloudFormation のユーザーインターフェイスを手作業でクリック操作したのではなく、サインイン後すぐに AWS CloudShell を起動し、事前に用意したデプロイスクリプトを実行していたのです。これにより、脅威アクターは自動化によるスピードを確保しつつ、従来の静的 API キーの監視をすり抜けることができました。mfaAuthenticated: false フィールドは、セキュリティコントロールに不備があったことを示しています。特に機密データや本番ワークロードを扱う環境では、コンソールアクセスに MFA を必須にする必要があります。
調査の優先順位
不正なスタックの存在が確認できたため、調査ではタイムライン全体と影響範囲の把握に重点を置きました。調査は 3 つのフェーズに分け、前のフェーズで得た結果を基に次のフェーズを進めました。
コンソールセッションのタイムラインを再構築する
セッションは 18:06:22Z に開始され、スタックはわずか 50 秒後の 18:07:12Z に作成されています。この速さから、脅威アクターは環境を手作業で探索したのではなく、スクリプトを用意して臨んでいたことがわかります。しかし、その前後に何が起きたのかも把握する必要がありました。セッション期間全体を対象に、同じセッショントークンで CloudTrail をフィルタリングすることで、脅威アクターがスタックのデプロイ前に偵察を行っていたか、同じセッション中に他のサービスやリージョンにアクセスしていたか、マイニング環境のデプロイの前後に永続化 (IAM ユーザーやアクセスキーの作成など) を試みていたかを特定できました。CloudFormation のデプロイ以外のアクションが見つかった場合、暗号通貨マイニング以外にも副次的な目的があった可能性があります。
スタックが実際にデプロイしたものを調べる
スタック名だけでは、影響の全容はわかりません。どのようなリソースが作成され、どのように設定されていたかを把握するには、CloudFormation テンプレートを調べる必要がありました。具体的には、EC2 インスタンスタイプを特定しました。サイズの大きいインスタンスほど、コストが高く、マイニングで得られる暗号通貨の量も増える可能性があります。また、セキュリティグループのルールを確認し、これらのインスタンスから内部リソースへどのようなネットワークアクセスが可能だったかを判断しました。加えて、起動時にマイニングソフトウェアを取得するカスタム AMI やユーザーデータスクリプトがテンプレートに含まれていないか、さらなるラテラルムーブメントに利用できる権限を持つ IAM ロールをスタックが独自に作成していないかも調べました。テンプレートそのものが証拠になります。テンプレートが Amazon S3 でホストされていた場合は、そのアップロードイベントから、脅威アクターが最初にツールを配置した時期を特定できます。
ビジネスへの影響を算出し、影響範囲を特定する
最後に、被害を定量化し、今回の事象が単独のものか、より広範な侵害の一部なのかを判断する必要がありました。インスタンスの稼働時間にインスタンスタイプごとの料金を掛けてコンピューティングコストの総額を算出し、マイニング用インスタンスから本番データベースや内部サービスへのネットワーク経路があったかを確認し、既知のマイニングプールの IP アドレスへの接続がないかアウトバウンドトラフィックのログを調べ、他のリージョンやアカウント全体で類似のスタックや命名パターンを検索しました。マイニングプール以外へのアウトバウンド接続があった場合、インスタンスが、暗号通貨を生成しながらデータを持ち出すという二重の目的で使われていた可能性があります。
対応チェックリスト
次のチェックリストは、インシデントを封じ込め、影響を評価し、セキュリティ上の不備を解消するために必要な主なアクションをまとめたものです。
- このセキュリティ上重要な操作で MFA が必須になっていなかった理由を特定する
- 脅威アクターが有効なコンソール認証情報をどのように入手したかを調査する
- 今回のアクセスが成功する前に、サインインの失敗がないか確認する
- このコンソールセッション中に他のアクティビティが発生していないか確認する
- CloudFormation スタックによって作成されたリソースを探す
- それらのリソースがどのくらいの期間稼働し、コストが発生しているかを特定する
- 環境内に類似した名前のスタックや疑わしいスタックが他にないか探す
- これらのインスタンスから内部リソースへどのようなネットワークアクセスが可能かを確認する
- これらのインスタンスがどのようなアウトバウンド接続を行っているかを特定する
- 暗号通貨のマイニングプールへの接続を探す
- IAM ユーザーやロールが作成されていないか確認する
- 追加のアクセスキーが生成されていないか確認する
- 脅威アクターが既存の権限やポリシーを変更したかどうかを確認する
重要なポイント
このシナリオは、認証情報の適切な管理や監視コントロールが、リソースの乗っ取りという脅威とどのようにかかわるかを示しています。
- IAM ユーザーに MFA を適用すれば、コンソールでの認証情報の悪用を防止できます。今回は MFA が使用されていなかったことが、一連の攻撃すべてを可能にしました。セキュリティのベストプラクティスとして、本番環境へのコンソールアクセスには MFA を必須にする必要があります。
- リソースの名前が手がかりになることがあります。
CRYPTOというあからさまな命名は、脅威アクターの自信の表れか、運用セキュリティの不備のどちらかを示唆しており、いずれも別の理由で懸念すべき点です。 - コスト監視はセキュリティ監視でもあります。請求額の異常な急増は、リソースの乗っ取りイベントの早期の兆候である可能性があります。
- コンソールでのアクティビティはプログラムによるアクティビティとはパターンが異なり、それに応じた調査アプローチが必要です。両者を見分ける出発点となるのが
sessionCredentialFromConsoleフィールドです。
まとめ
このパート 1 では、CloudTrail の分析によってセキュリティインシデントの全容を明らかにできることを、2 つの実際のシナリオを通じて紹介しました。シナリオ 1 では、一見日常的なクロスアカウントのロールの引き受けが、ランサムウェアとの関連が疑われる、標的を絞ったデータ削除につながった経緯を示しました。あわせて、セッション名、タイミングのパターン、送信元 IP の相関分析が、調査担当者によるイベントチェーンの解明にどう役立つかも説明しました。シナリオ 2 では、盗まれたコンソール認証情報を使って CloudShell 経由で暗号通貨マイニング環境がデプロイされた経緯を確認し、セキュリティコントロールとしての MFA の適用とコスト監視が果たす重要な役割を取り上げました。どちらのシナリオからも、効果的な CloudTrail の調査は「何が起きたか」を特定するだけでは終わらない、という基本原則がわかります。差し迫った脅威を封じ込め、その脅威を招いたセキュリティ上の不備を解消するには、「どのように」そして「なぜ」起きたのかを理解する必要があります。
このガイドのパート 2 では、ウェブアプリケーションの脆弱性が、AI サービスを標的としたマルチリージョンのイベントへとどのように連鎖していくかを見ていきます。SSRF、IMDSv1 を悪用した認証情報の窃取、クロスリージョンのピボットを組み合わせて Amazon Bedrock にアクセスする手口です。また、ルートユーザーと root という名前の IAM ユーザーの区別、ロール名を模倣する手口、HIDDEN_DUE_TO_SECURITY_REASONS というユーザー名を使ったトリックといった重要な調査手法に加え、重要なセキュリティ強化 (ハードニング) の手順や、クラウドフォレンジックの能力を高めるために役立つ追加のリソースについても説明します。
本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。