AWS CloudTrail を使ったインシデント調査・対応ガイド – パート 2

本ブログは 2026 年 9 月 3 日に公開された AWS Blog “Incident response guide for AWS CloudTrail investigations – Part 2” を翻訳したものです。

本ガイドのパート 1 では、よくある 2 つのインシデントシナリオを検証しました。1 つ目はランサムウェアの影響を伴う、クロスアカウントでの Amazon Simple Storage Service (Amazon S3) のデータ削除、2 つ目は漏洩した AWS マネジメントコンソールの認証情報を使用して AWS CloudFormation 経由でデプロイされた暗号通貨マイニングです。また、インシデント対応の主要な用語と、AWS CloudTrail イベントを分析するための調査フレームワークも紹介しました。

パート 2 となる今回は、より複雑なマルチステージ攻撃を取り上げます。具体的には、ウェブアプリケーションの脆弱性を起点に、認証情報の窃取、さらには複数の AWS リージョンにまたがる Amazon Bedrock サービスへの不正アクセスへと被害が連鎖的に拡大する仕組みを解説します。あわせて、追加の調査手法と、セキュリティポスチャを向上させるための強化手順についても説明します。

このシナリオでは、ウェブアプリケーションの脆弱性が、Amazon Bedrock サービスを標的とするマルチリージョンのイベントへと連鎖的に拡大する仕組みを検証します。脅威アクターは、サーバーサイドリクエストフォージェリ (SSRF) を介して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスメタデータサービスバージョン 1 (IMDSv1) を悪用し、さらにリージョンをまたいでピボットして Amazon Bedrock にアクセスしました。この調査では、脅威アクターがこうした複数の手法をどのように組み合わせたのかを明らかにします。

セキュリティチームに複数のアラートが届きます。us-east-1 リージョンでの AWS Identity and Access Management (IAM) オペレーションの失敗、多要素認証 (MFA) を使用しないコンソールサインインの成功、そして us-east-2 からの異常な Amazon Bedrock API コールです。一見すると、これらは異なるサービスやリージョンで発生した無関係なイベントに見えるかもしれません。しかし、AWS の Security Incident Response Team (SIRT) が突き止めたとおり、これらはウェブアプリケーションの脆弱性に端を発し、組織の AI インフラストラクチャへの不正アクセスに至った、周到に仕組まれた一連のイベントでした。

図 1 のアーキテクチャは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと AWS サービスの間の信頼関係を悪用したマルチステージ攻撃を示しています。脅威アクターは、webdev IAM ロールがアタッチされた EC2 インスタンス上で動作するウェブアプリケーションに、SSRF の脆弱性を発見しました。脅威アクターは権限を直接昇格させようとはせず、この足がかりを利用して IMDSv1 エンドポイントにアクセスし、webdev ロールに発行された一時的な認証情報を取得しました。IMDSv1 は、セッショントークンを含まない基本的なリクエストにも認証情報を返すため、SSRF の欠陥さえあれば認証情報を窃取できます。こうして取得された認証情報が、その後のすべての攻撃のピボットポイントとなりました。攻撃は 5 つの段階で進行しました。図 1 では各段階に番号を付けているため、最初のウェブリクエストから、リージョンをまたいだ Amazon Bedrock のアクティビティまでの流れをたどることができます。

1. 初期アクセス: 脅威アクターは、ウェブアプリケーションの SSRF の脆弱性を悪用し、インスタンスからサーバーサイドリクエストを送信させました。
2. 認証情報の窃取: それらのリクエストが IMDSv1 エンドポイントに到達し、webdev ロールの一時的な認証情報が返されました。
3. 権限のテスト: 脅威アクターは、窃取した認証情報を使用して IAM オペレーションを試み、ロールで実行できる操作の範囲を探りました。
4. サービスのピボット: IAM アクションが拒否されると、脅威アクターは、ロールでアクセス可能なサービスである Amazon Bedrock に標的を移しました。
5. リージョンホッピング: 脅威アクターは、オペレーションを us-east-1 から us-east-2 に移しました。リージョン固有のモニタリングとアクセスコントロールを回避するためとみられます。

図 1: シナリオ 3 のアーキテクチャ

このセクションでは、攻撃の始まりから終わりまでを記録した CloudTrail の証拠を順に見ていきます。以下の 4 つのイベントは、それぞれ前述の 1 つ以上の段階に対応しています。これらを合わせて見ることで、脅威アクターが窃取した認証情報を足がかりに、Amazon Bedrock の実際の悪用へと進んだ経緯をたどることができます。各イベントについて、CloudTrail ログレコードの該当部分を示し、調査で特に重要なフィールドを強調表示します。また、強調表示した各フィールドから何がわかるのかを説明するフォレンジック凡例も掲載します。

取り上げるイベントは次のとおりです。

1. 権限範囲の探索 (15:53:49 UTC): us-east-1 で失敗した CreateUser コール。侵害されたロールと、認証情報の取得元が IMDSv1 であることがわかります。
2. コンソールアクセスの確立 (15:59:29 UTC): MFA を使用しないコンソールサインインの成功。プログラムによるアクセスから対話型アクセスへのピボットがわかります。
3. Amazon Bedrock サービスの偵察 (17:20:00 UTC): us-east-2 での ListFoundationModels コール。リージョンホッピングと AI サービスへの移行がわかります。
4. モデルの悪用 (17:25:48 UTC): Converse コールによる Amazon Nova Pro モデルの呼び出し。不正使用が裏付けられます。

各イベントを読む際は、フィールドがどのように段階どうしをつないでいるかに注目してください。同じ webdev ロール、同じ送信元 IP アドレス、そして繰り返し現れる ec2RoleDelivery の値が、一見別々のイベントを 1 つの攻撃チェーンとして結び付ける手がかりになります。

イベント 1: 権限範囲の探索 (15:53:49 UTC): 最初の不審なアクティビティは、us-east-1 での CreateUser API コールの失敗として現れました。CloudTrail ログには、AssumedRole セッションが adm1n という名前の IAM ユーザーを作成しようとし、AccessDenied エラーを受け取ったことが記録されています。webdev ロールは userIdentity フィールドで確認できます。また、readOnly は false (書き込みオペレーションの試行を示す) で、ユーザーエージェントは Windows 上の AWS コマンドラインインターフェイス (AWS CLI) となっています。このことから、窃取された認証情報を使用したプログラムによるアクセスであると考えられます。

{
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAFINDANEXAMPLE:i-0123456789abcdef0",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0",
    "sessionContext": {
      "sessionIssuer": { "type": "Role", "userName": "webdev" },  ◄── ❶ 侵害された EC2 ロール
                                                     ‾‾‾‾‾‾‾‾
      "attributes": { "mfaAuthenticated": "false" }
    },
    "ec2RoleDelivery": "1.0"  ◄── ❷ IMDSv1 の使用を確認 (SSRF による悪用経路)
                       ‾‾‾‾‾
  },
  "eventTime": "2025-09-22T15:53:49Z",
  "eventSource": "iam.amazonaws.com",
  "readOnly": false,
  "eventName": "CreateUser",  ◄── ❸ 意図: 永続的なバックドアの確立
               ‾‾‾‾‾‾‾‾‾‾‾‾
  "userAgent": "aws-cli/2.17.48 ua/2.0 os/windows#10 ...",
  "errorCode": "AccessDenied",  ◄── ❺ ポリシーによる阻止 (最小権限が機能)
               ‾‾‾‾‾‾‾‾‾‾‾‾‾‾
  "errorMessage": "User: arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/...
    is not authorized to perform: iam:CreateUser
    on resource: arn:aws:iam::XXXXXXXXXXXX:user/adm1n..."  ◄── ❹ 類似名 (i ではなく 1)
                                                ‾‾‾‾‾
}

───────────────────────────────────────────────────────────────────
  フォレンジック凡例
───────────────────────────────────────────────────────────────────
  ❶ userName: "webdev"         → 侵害された EC2 ロールのコンテキストを確認
  ❷ ec2RoleDelivery: "1.0"    → IMDSv1 経由で取得された認証情報 (SSRF による攻撃経路)
  ❸ eventName: "CreateUser"   → 攻撃者が IAM による永続化を試行
  ❹ target user: "adm1n"      → admin を装ったタイポスクワッティング (文字の i ではなく数字の 1)
  ❺ errorCode: "AccessDenied" → 攻撃者が権限の範囲を探索したが、阻止された
───────────────────────────────────────────────────────────────────

イベント 2: コンソールアクセスの確立 (15:59:29 UTC): その 6 分後、脅威アクターは同じ認証情報を使用して AWS マネジメントコンソールへのサインインに成功しました。ConsoleLogin イベントには MFA が使用されなかったこと (MFAUsed: No) が記録されており、送信元 IP (75.3.231.105) は攻撃元を特定する手がかりになります。ユーザーエージェントからは、Windows 10 上の Chrome ブラウザが使われたことがわかります。

{
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAFINDANEXAMPLE:i-0123456789abcdef0",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0",
    "sessionContext": { "attributes": { "mfaAuthenticated": "false" } }
  },
  "eventTime": "2025-09-22T15:59:29Z",
  "eventSource": "signin.amazonaws.com",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 	 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Edg/140.0.0.0",

  "eventName": "ConsoleLogin",  ◄── ❶ 対話型のコンソールアクセスにピボット
               ‾‾‾‾‾‾‾‾‾‾‾‾‾‾
  "awsRegion": "us-east-1",
  "sourceIPAddress": "75.3.231.105",
  "responseElements": { "ConsoleLogin": "Success" },◄── ❷ 乗っ取った認証情報でのログインに成功
                                        ‾‾‾‾‾‾‾‾‾
  "additionalEventData": { "MobileVersion": "No", "MFAUsed": "No" },◄── ❸ MFA チャレンジなし
                                                             ‾‾‾‾
  "eventType": "AwsConsoleSignIn"  ◄── ❹ コンソールサインイン (API コールではない)
               ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
}
───────────────────────────────────────────────────────────────────
フォレンジック凡例
───────────────────────────────────────────────────────────────────
❶ eventName: "ConsoleLogin"→ 攻撃者がプログラムによるアクセスから、画面で操作するコンソールアクセスにピボット
❷ ConsoleLogin: "Success"→ 乗っ取った認証情報によるログインの認証に成功
❸ MFAUsed: "No" → 重大なギャップ: MFA が強制されておらず、ピボットを許した
❹ eventType: "AwsConsoleSignIn"   → 通常の API コールと区別できる
───────────────────────────────────────────────────────────────────

イベント 3: Amazon Bedrock サービスの偵察 (17:20:00 UTC): 約 2 時間後、脅威アクターは Amazon Bedrock にピボットし、us-east-2 で ListFoundationModels API コールを実行しました。このイベントからは、いくつかのパターンが読み取れます。us-east-1 から us-east-2 へのリージョンの変更 (防御回避の可能性)、IAM から AI サービスへの移行、readOnly: true (変更ではなく偵察)、そして sessionCredentialFromConsole: "true" です。最後の値は、このコールが IMDSv1 から新たに取得した認証情報ではなく、イベント 2 で確立されたコンソールセッションによるものであることを示しています。

 {
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0"
  },
  "eventTime": "2025-09-22T17:20:00Z",
  "eventSource": "bedrock.amazonaws.com",  ◄── ❶ クラウドの AI サービスにピボット
               ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
  "eventName": "ListFoundationModels",  ◄── ❷ AI モデルの偵察
               ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
  "awsRegion": "us-east-2",  ◄── ❸ リージョンホッピング (回避手法)
               ‾‾‾‾‾‾‾‾‾‾‾
  "sourceIPAddress": "75.3.231.105",
  "readOnly": true,
  "tlsDetails": {
    "clientProvidedHostHeader": "bedrock.us-east-2.amazonaws.com"  ◄── ❹ 別のリージョンを意図的に標的化
                               ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
  },
  "sessionCredentialFromConsole": "true"
}

───────────────────────────────────────────────────────────────────
  フォレンジック凡例
───────────────────────────────────────────────────────────────────
❶ eventSource: "bedrock.amazonaws.com"→ 攻撃者が IAM からマネージド AI サービスにピボット
❷ eventName: "ListFoundationModels"→ 偵察: 利用可能な AI モデルを列挙
❸ awsRegion: "us-east-2"→ us-east-1 からのリージョンホッピング (防御回避)
❹ clientProvidedHostHeader: "bedrock.us-east-2..."  → 別のリージョンのエンドポイントを意図的に標的にしたことを確認
───────────────────────────────────────────────────────────────────

イベント 4: モデルの悪用 (17:25:48 UTC): 偵察コールから 5 分後、脅威アクターは列挙の段階から実際の悪用へと移り、us-east-2 で Converse API を介して Amazon Nova Pro モデルを呼び出しました。additionalEventData フィールドには、不正使用の量が入力トークン 944 個、出力トークン 126 個として記録されています。このことから、脅威アクターがモデルにプロンプトを送信し、レスポンスを受け取ることに成功したことが確認できます。

 {
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0"
  },
  "eventTime": "2025-09-22T17:25:48Z",
  "eventSource": "bedrock.amazonaws.com",
  "eventName": "Converse",  ◄── ❶ 実際のモデル呼び出し (偵察 → 悪用)
               ‾‾‾‾‾‾‾‾‾‾
  "awsRegion": "us-east-2",
  "requestParameters": {
    "modelId": "amazon.nova-pro-v1:0",  ◄── ❷ 悪用されている特定のモデル
               ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
    "inferenceConfig": { "maxTokens": 1024 }
  },
  "responseElements": null,
  "additionalEventData": { "inputTokens": 944, "outputTokens": 126 }  ◄── ❸ 不正使用量の定量化
                           ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
}

───────────────────────────────────────────────────────────────────
  フォレンジック凡例
───────────────────────────────────────────────────────────────────
❶ eventName: "Converse"                → 攻撃者が偵察から実際の悪用に移行
❷ modelId: "amazon.nova-pro-v1:0"      → 悪用されている基盤モデルを特定
❸ inputTokens: 944, outputTokens: 126  → 不正使用量を定量化 (金銭的コストとデータ流出のリスク)
───────────────────────────────────────────────────────────────────

このシナリオのイベントログを確認するうえで、調査の大部分を担うのは一部のフィールドです。各フィールドから何がわかり、なぜ重要なのかを理解することで、個々のログレコードを結び付け、一貫した攻撃の経緯としてとらえられるようになります。

まず、userIdentity フィールドは、実行主体を特定するための出発点です。このシナリオでは、このフィールドのセッション名に EC2 インスタンス ID が含まれていたため、窃取された認証情報の出どころを、人間のユーザーではなく侵害された特定のインスタンスまでさかのぼることができました。ロールを引き受けて取得したセッションを見つけたときは、このフィールドから、あらゆる調査で最初に問うべき「これは誰の認証情報で、どこから来たのか?」という疑問への答えが得られます。

次に、readOnly フィールドからは、アクションの背後にある意図がわかります。値が true の場合は偵察を意味します。脅威アクターが利用可能なモデルを列挙するために使用した ListFoundationModels コールがその例です。一方、false の場合は、何かを変更または使用しようとする試みを意味します。CreateUser コールや Converse の呼び出しがこれに該当します。このフィールドでイベントを並べ替えると、脅威アクターによる情報収集と、実際に影響を及ぼしたアクションをすばやく切り分けることができます。

また、awsRegion フィールドは見落としがちですが、このシナリオでは脅威アクターの回避戦略を明らかにする手がかりとなりました。us-east-1 から us-east-2 への移動は偶然ではありません。脅威アクターがリージョン間を移動するのは、モニタリング、アラート、アクセスコントロールの設定がリージョンごとにばらついていることが多いためです。このフィールドを監視することで、検出体制が最も手厚い場所から意図的に離れたアクティビティを見つけやすくなります。

最後に、userIdentity.invokedBy フィールドは、ユーザーや窃取された認証情報ではなく、AWS のサービスがお客様に代わってリクエストを行ったことを示します。CloudTrail がこのフィールドに値を設定するのは、サービスリンクロール、サービスロール、転送アクセスセッションなどを通じて、呼び出し元が AWS のサービスである場合に限られます。このシナリオのイベントにこのフィールドが含まれていないのは、脅威アクターが窃取した webdev の認証情報で Amazon Bedrock を直接呼び出したためです。このフィールドがないこと自体が有益な情報であり、リクエストが正当なサービス主導のワークフローからではなく、プリンシパル自身から直接送信されたことを裏付けています。エージェントベースのものや、サービスと統合されたものなど、Amazon Bedrock のワークロードが普及するにつれて、このフィールドを確認することが、想定どおりのサービスのアクティビティと、脅威アクターが認証情報を使用して直接実行したアクティビティを見分けるうえで重要になります。

SSRF から認証情報の窃取、そして Amazon Bedrock サービスの悪用に至るまでの攻撃チェーン全体を把握した後、調査はより難しい問いへと移りました。各段階で実際にどのような損害が発生したのか、そして再発を防ぐには何が必要なのか? この作業は、次の優先事項に沿って進めました。

1 つ目は、認証情報の出どころと、影響が及んだ範囲を突き止めることでした。脅威アクターが webdev ロールの有効な認証情報を持っていたことは明らかでしたが、より重要なのは、なぜウェブアプリケーションのロールがそもそも Amazon Bedrock にアクセスできたのかという点でした。お客様からは、この権限を付与する業務上の理由はないとの確認が得られたため、その権限が意図的に付与されたものなのか、単なる見落としによるものなのかを明らかにし、同じロールがアタッチされている他の EC2 インスタンスを洗い出す必要がありました。侵害されたインスタンスが 1 つなら 1 件のインシデントですが、過剰な権限を持つ同じロールがアタッチされたインスタンスのフリートは、今後はるかに大きな問題を引き起こしかねません。

次に、脅威アクターが Amazon Bedrock に不正にアクセスした後に何をしたのかを把握しようとしました。偵察と実際の使用とでは影響が大きく異なるため、どの基盤モデルにアクセスされたのか、それらが実際に呼び出されたのか、列挙されただけなのかを追跡しました。この区別は被害範囲の特定に欠かせないうえ、データ流出を懸念すべきかどうかの判断材料にもなります。通常とは異なるモデルの使用、想定外のプロンプト量、正当なワークロードでは見られない出力パターンは、偵察がより深刻な事態に発展したことを示すシグナルです。

リージョンホッピングについても、独立した調査項目として扱いました。us-east-1 から us-east-2 への移動はほぼ確実に意図的なものであり、調査では、脅威アクターがそれによって何を得たのかを解明することに重点を置きました。具体的には、2 つのリージョンを比較して、「us-east-2 のモニタリングとアクセスコントロールは us-east-1 よりも手薄だったのか、そして脅威アクターはセカンダリリージョンに入った後、他に何にアクセスしたのか?」という点を確認しました。リージョン間でコントロールに一貫性がないことは、アクティビティが検出をすり抜ける最も一般的な原因の 1 つです。

これらすべてをつなぎ合わせるのがタイムラインです。タイムラインを見ると、脅威アクターがいかにすばやく攻撃チェーンを進めたかがわかります。

1. 15:53:49: IAM オペレーションの失敗 (us-east-1)
2. 15:59:29: コンソールログインの成功 (us-east-1)
3. 17:20:00: Amazon Bedrock の偵察 (us-east-2)
4. 17:25:48: 実際のモデル呼び出し (Converse コール) (us-east-2)

これらのイベントをとおして認証情報を追跡すると、残りの経緯も見えてきます。IMDSv1 から脅威アクターに webdev ロールの一時的な認証情報が渡り、その後のすべてのイベントに同じロールが現れています。つまり、認証情報は差し替えられることなく使い回されていたということです。この一連の流れのどの時点でも MFA は要求されておらず、この 1 つのギャップが原因で、窃取された 1 つの認証情報が 2 時間にわたり、2 つのリージョン、性質のまったく異なる 2 つのサービスで有効であり続けました。

以下のチェックリストは、インシデントの封じ込め、脆弱性の修復、AI サービスが不正使用された範囲の評価に必要なアクションをまとめたものです。各項目には、確認すべき場所と、どのような兆候に着目すべきかを記載しているため、インシデント対応中の切迫した状況でも活用できます。

1. 侵入口の封じ込めと修復
   1. 外部へのリクエストを送信したウェブアプリケーションの機能を特定し (典型的な原因は、URL フェッチャー、Webhook コールバック、PDF や画像のレンダラー、リンクプレビュー生成機能です)、その機能から http://169.254.169.254 にアクセスできることを確認します。
   2. アプリケーションの他の部分にも同じパターンがないかを監査します。検証されていない URL パラメータが 1 つ見つかった場合、たいていは他にも存在するためです。
   3. 影響を受けたインスタンスとフリート全体に対して aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1 を実行し、IMDSv2 を強制します。--http-tokens を required に設定すると、呼び出し元が PUT リクエストで取得したセッショントークンを提示した場合にのみ認証情報が返されるようになります。基本的な SSRF では、この操作は行えません。また、ホップ制限を 1 に設定すると、メタデータのレスポンスがインスタンス内にとどまるため、コンテナやプロキシなど 1 ホップ余分に離れた場所からのリクエストにはレスポンスが届きません。
2. Amazon Bedrock の使用範囲の特定
   1. IAM ポリシーと関連するリソースベースのポリシーを確認し、webdev ロールがアクセスできた基盤モデルを洗い出します。これにより、実際に呼び出された 1 つのモデルだけでなく、このロールを通じて悪用されるおそれがあったモデル全体を把握できます。
   2. モデルに送信された内容と、モデルから返された内容を特定します。CloudTrail には Converse コールとトークン数が記録されますが、入力プロンプトとモデルのレスポンスをキャプチャできるのは Amazon Bedrock のモデル呼び出しのログ記録だけです。この機能が有効になっていた場合は、該当セッションのログエントリを取得します。有効になっていなかった場合は、プロンプトとレスポンスの内容を復元できないことを記録したうえで、直ちに有効にします。
   3. それらのプロンプトとレスポンスの内容に基づいて、コンプライアンス上のリスクを洗い出します。規制対象データ (個人を特定できる情報 (PII)、保護対象保健情報 (PHI)、カード会員データなど) がモデルを通じて不正に処理された場合は、通知義務が生じる可能性があります。
3. より広範な侵害と永続化の確認
   1. Amazon Bedrock に限らず、すべてのリージョンとサービスを対象に CloudTrail をクエリし、webdev ロールのセッションに関連するすべてのイベントを抽出して、同じ認証情報を使って他に何にアクセスしたかを確認します。
   2. CloudTrail のタイムスタンプを、送信元 IP 75.3.231.105 に関する VPC フローログやアプリケーションログと突き合わせ、各 API コールの前後にあったネットワークレベルの状況を把握します。
   3. 一時的な認証情報の有効期限を超えて永続化しようとした形跡を示す、そのセッションからの IAM 書き込みイベント (CreateUser、CreateRole、CreateAccessKey、AttachRolePolicy) を検索します。失敗した adm1n の CreateUser コールが既知の出発点です。同様の操作が成功していないことを確認してください。
4. 継続中または未発見の影響の監視
   1. CloudWatch と請求データで Amazon Bedrock の使用状況を確認し、通常のワークロードパターンから外れた呼び出しの急増や想定外のトークン消費がないかを調べます。
   2. 呼び出しログを調べ、モデルを通じて機密データが処理または抽出された兆候がないかを確認します。
   3. 同じログで、モデルの指示を上書きしたり、システムプロンプトを抽出したりしようとする入力、つまりプロンプトインジェクションの試みがないかを確認します。

このシナリオは、複数のセキュリティコントロールが欠けている場合に、1 つのアプリケーションの脆弱性が広範な不正アクセスへと連鎖的に拡大することを示しています。以下では、防御上の主なギャップと、強化の優先事項を取り上げます。

• ワークロードロールへの IAM 最小権限の適用: ウェブアプリケーションのワークロードに使用される webdev ロールが、複数のリージョンで Amazon Bedrock にアクセスできることに業務上の正当な理由はなく、お客様も調査の中でこれを確認しました。EC2 インスタンスロールには最小権限の原則を適用し、アプリケーションが必要とするサービスとアクションのみに権限を絞り込みます。AWS IAM Access Analyzer を使用して未使用の許可を特定し、ポリシーを先回りして厳格化してください。過剰な権限を持つロールがあると、1 つのアプリケーションの脆弱性が、無関係なサービスにまで及ぶ広範なラテラルムーブメントにつながってしまいます。
• IMDSv1 と IMDSv2 の比較: 組織は直ちに IMDSv2 に切り替え、クラウドインフラストラクチャ全体で IMDSv1 を無効にする必要があります。ログの ec2RoleDelivery: "1.0" フィールドは、IMDSv1 が使用されたことを明確に示しています。IMDSv1 では、認証トークンなしで認証情報を取得できます。このアーキテクチャ上の弱点があると、SSRF による認証情報の窃取はきわめて容易になります。外部へのリクエストを送信できるウェブアプリケーションの欠陥さえあれば、追加の認証なしでロールの一時的な認証情報を読み取れるためです。IMDSv2 に移行すると、ローカルのセッションベースのトークンが必須となるため、このアタックサーフェスが縮小し、脅威アクターによる悪用チェーンを効果的に断ち切ることができます。このシナリオでは、IMDSv2 さえ導入されていれば、攻撃を最初の段階で阻止できたはずです。
• リージョンを利用した防御回避は計画的な攻撃者の兆候: Amazon Bedrock にアクセスするために us-east-1 から us-east-2 に移動したのは、偶然ではありません。脅威アクターがリージョン間を移動するのは、モニタリング、アラート、アクセスコントロールの設定がリージョンごとにばらついていることが多く、セカンダリリージョンでのアクティビティは気付かれにくいためです。このようなリージョンをまたいだ移動は、場当たり的なアクセスではなく、自らの活動を隠すオペレーショナルセキュリティを意識した攻撃者であることを示す指標です。こうした移動を確認した場合は、調査の優先度を引き上げるべきです。積極的に使用していないリージョンも含め、すべてのリージョンで一貫した検出範囲を確保することを基本要件としてください。
• インターフェイスの切り替えと権限範囲の探索から見える脅威アクターの手口: この一連のイベントからは、AWS のインターフェイスを自在に使い分け、本格的に行動する前に境界を探ることに長けた脅威アクターの姿が浮かび上がります。失敗した CreateUser の試行は、窃取した認証情報で何ができるかを把握するための体系的な探索でした。そして IAM アクションが拒否されると、脅威アクターはロールが実際にアクセスできるサービスへとピボットしました。AWS CLI を使用したプログラムによるアクセスと、コンソールへの対話型アクセスを併用していることも、同様の適応力の表れです。探索、適応、ピボットというこのパターンを理解しておけば、対応者は個々のイベントにその都度反応するのではなく、次の動きを予測できるようになります。
• AI サービスには CloudTrail だけでは得られない可視性が必要: Amazon Bedrock をはじめとする AI サービスは価値の高い標的ですが、CloudTrail だけでは全体像を把握できません。CloudTrail には、誰が Amazon Bedrock を呼び出したか、その呼び出しが成功したかどうかは記録されますが、何を質問し、何が回答されたかは記録されません。コンプライアンス監査のためにプロンプトとレスポンスをすべてキャプチャするには、Amazon Bedrock のモデル呼び出しのログ記録を有効にします。エージェントベースのワークロードの場合は、AWS Distro for OpenTelemetry (ADOT) 上に構築された Amazon Bedrock AgentCore Observability を使用すると、ツールの実行順序やレイテンシーを示すセッションレベルのトレースを取得できます。Amazon GuardDuty AI Protection の有効化もあわせて検討してください。この機能は、Amazon Bedrock に関連する CloudTrail のアクティビティを分析し、異常な呼び出し、コストハーベスティング (リソースの不正利用によるコスト発生)、プロンプトインジェクションの試みを検出します。CloudTrail、モデル呼び出しのログ記録、エージェントのテレメトリという 3 つのシグナルを相関分析することで、調査担当者は全体像を把握できます。実装のガイダンスについては、「Monitoring and Auditing AI Workloads on AWS」を参照してください。

このシナリオで紹介した攻撃パターン以外にも、脅威アクターは防御側を混乱させ、正当なアクティビティに紛れ込むために、さまざまな回避手法を用います。調査担当者はこうした手法を把握しておく必要があります。AWS がお客様とのインシデント対応で特によく確認している 3 つの手法は次のとおりです。

• ルートユーザーと root という名前の IAM ユーザーの比較: AWS アカウントを初めて作成すると、アカウント内のすべての AWS サービスとリソースに完全にアクセスできる単一のサインインアイデンティティが作成されます。このアイデンティティを AWS アカウントのルートユーザーと呼びます。過去の調査では、脅威アクターが AWS アカウント内に root という名前の IAM ユーザーを作成していたケースもありました。両者の違いは、CloudTrail ログレコードの userIdentity 要素にある type フィールドで確認できます。このフィールドは、そのログレコードに記録されたユーザーの種類を示します。
• ロール名とユーザー名の模倣: 脅威アクターは、AWS 用に予約されている名前に似せた IAM ユーザーやロールを作成することで、防御回避を図ります。例えば、サービスリンクロールの AWSServiceRoleForSupport は、AWS サポートに直接リンクされた固有の IAM ロールです。脅威アクターは、AWSServiceRoIeforSupport という名前のロールを作成し (大文字の I が、小文字の l の代わりに Role 内で使われている点に注意してください)、このロールによるアクションを AWS サポートが実行したものだとお客様に誤認させようとしたことがあります。
• HIDDEN_DUE_TO_SECURITY_REASONS という名前のユーザー: userName フィールドには、記録されたイベントが誤ったユーザー名の入力によるコンソールサインインの失敗である場合、HIDDEN_DUE_TO_SECURITY_REASONS という文字列が入ります。この場合、入力されたテキストに機密情報が含まれている可能性があるため、CloudTrail はその内容を記録しません。ところが、脅威アクターはこの文字列を実際のユーザー名として使用し、名前がマスクされているだけだと調査担当者に思い込ませようとしたことがあります。この手法には通常、対応する CreateUser または CreateRole の CloudTrail イベントが伴います。

CloudTrail のイベントフィールドを活用することで、セキュリティチームは意図しないアクセス権を持つアイデンティティの特定、脅威アクターのアクションの追跡、影響を受けたリソースの修復を行うことができます。userIdentity、eventName、sourceIPAddress などのフィールドを理解すれば、インシデント調査と脅威検出の精度が向上します。包括的なログ記録の有効化、Amazon Athena による分析、ログの保護、対応の自動化といったベストプラクティスを実践することで、CloudTrail を堅牢なフォレンジックおよびインシデント対応ツールとして活用できます。

AWS 環境で不正なアクティビティが疑われる場合は、AWS Security Incident Response をご利用いただけます。このサービスは、Amazon GuardDuty や、AWS Security Hub を通じて統合されたサードパーティーのセキュリティツールからの検出結果を継続的にモニタリングおよびトリアージし、アラートを自動的にフィルタリングして、関連性の高いイベントを優先的に表示します。プロアクティブなトリアージに加えて、お客様はこのサービスからセキュリティケースを作成することもできます。作成したケースは、社内で対応することも、SIRT のサポートを受けることもできます。SIRT はセキュリティ専門家で構成される専任チームで、インシデントのライフサイクル全体を通じて、調査、封じ込め、復旧を常時支援します。

AWS 環境の保護と調査能力の強化に役立つ詳細なガイダンスについては、以下のリソースを参照してください。

• AWS Security Best Practices
• The Agentic AI Security Scoping Matrix: A framework for securing autonomous AI systems
• CloudTrail イベントについて理解する
• AWS セキュリティインシデント対応ガイド

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。