CyberStrikeAI FortiGate侵害600台、Cloudflare WAF常時検知、RFC 9849 ECH標準化、VMware Aria KEV登録

CyberStrikeAI、AIオーケストレーションで600台のFortiGateを侵害

ツールの構造

CyberStrikeAIはGo言語で書かれたオープンソースの攻撃セキュリティツールで、GitHubで公開されている。100以上のセキュリティツールを統合し、それらをAIでオーケストレーションする設計になっている。主な機能は脆弱性スキャン、攻撃チェーン分析、知識検索、結果の可視化だ。

攻撃者は商用AI APIをオフェンシブなワークフローに直接統合している。今回のキャンペーン（一連の攻撃活動）ではAnthropicのClaudeとDeepSeekという2つの生成AIサービスが使われており、脆弱なアプライアンスのスキャン、攻撃手順の選択・生成、結果の分析をAIで自動化していた。攻撃者側のLLM活用は検索補助やコード生成に留まらず、攻撃ワークフロー全体のオーケストレーションに達している。

開発者はEd1s0nZというエイリアスを使う中国系の人物。中国国家安全省とのつながりが指摘される民間セキュリティベンダー「KnownSec 404」との接点が確認されており、研究者らは中国政府との何らかの関係があると評価している。

キャンペーンの規模

Team Cymruが公開したレポートによると、2026年1月20日から2月26日にかけて、55ヶ国600台以上のFortinet FortiGateアプライアンスが侵害された。21のユニークなIPアドレスが特定されており、インフラは主に中国・シンガポール・香港に集中、米国・日本・スイスにも一部が分散している。

特定のセクターへの集中は報告されておらず、スキャン・侵害対象の選定はオポチュニスティック（無差別的）なものと見られる。

攻撃の流れ

flowchart TD
    A[CyberStrikeAI<br/>Go製OSSツール] --> B[Claude / DeepSeek API<br/>でスキャン対象を選定]
    B --> C[FortiGate脆弱性<br/>を自動スキャン]
    C --> D[攻撃チェーンを<br/>AIが生成・実行]
    D --> E[55ヶ国 600台以上<br/>のFortiGateを侵害]
    E --> F[21のC2 IPアドレス<br/>中国・シンガポール・香港中心]

使われた脆弱性

記事時点では、CyberStrikeAIが具体的にどのCVEをターゲットにしたかの詳細は開示されていない。FortiGate製品については過去にCVE-2024-21762（SSL-VPN任意コード実行）やCVE-2024-55591（認証バイパス）が活発に悪用されており、パッチ未適用のまま公開されている機器が多数残存していることが背景にある。

CyberStrikeAIはGitHubでOSSとして公開されているため、追加の攻撃者がこのツールを用いた攻撃活動を展開することも想定される。

FortiGate運用組織の対処

FortiGateのファームウェアを最新版に更新する
管理インターフェースへのインターネット直接露出を排除する
FortinetのセキュリティアドバイザリとKEVリストを定期確認し、パッチ優先度を判断する

Cloudflare Attack Signature Detectionによる WAF常時検知

WAFを導入した組織が必ずぶつかる問題がある。ルールをblockモードにすると正規トラフィックが壊れる可能性があり、logモードにすると攻撃が素通りするという二択だ。

Cloudflareが2026年3月に発表したAttack Signature Detectionは、この構造的トレードオフを「常時実行・遅延判断」という設計で解消しようとするものだ。

従来WAFの問題

従来のWAFは、ルールが判定する→何らかのアクションを取る、という直列の処理をする。ルールがblockを出した時点で他のルール評価は止まる。このため運用者には「どのルールがどう判定したか全体像を把握したままブロックする」という選択肢がなかった。

新しいアプリケーションをCloudflare背後に置いた場合、セキュリティチームは通常こういう流れをたどる。まずlogモードで稼働させ、何週間もかけてログを確認し、誤検知になりそうなルールを除外してからblockモードに切り替える。手作業で、遅く、ミスが起きやすい。

検知と遮断の分離

flowchart LR
    A[リクエスト受信] --> B[700+シグネチャ<br/>常時評価]
    B --> C{blockルール<br/>設定あり?}
    C -- なし --> D[メタデータ付与のみ<br/>非同期処理]
    C -- あり --> E[インライン判定<br/>block/allow]
    D --> F[オリジンへ転送]
    E -- allow --> F
    E -- block --> G[リクエスト遮断]
    D --> H[Security Analytics<br/>に蓄積]

新しいAttack Signature Detectionは「always-on」で動作する。Cloudflareを通過するすべてのリクエストに対して、700以上のシグネチャルールが常時実行され、マッチした結果がリクエストのメタデータとして付与される。

この時点では何もブロックしない。検知と遮断が完全に分離されている。

付与されるフィールドは3つだ。

フィールド	内容
`cf.waf.signature.request.confidence`	マッチしたシグネチャの信頼度スコアの集計
`cf.waf.signature.request.categories`	マッチした攻撃カテゴリの集計（SQLi、XSS、RCEなど）
`cf.waf.signature.request.ref`	マッチしたシグネチャのRef IDリスト（最大10件）

これらのフィールドはSecurity AnalyticsのダッシュボードでもEdge Rules Engineでも参照できる。「このシグネチャが過去24時間で何回ヒットしたか」を分析してから、「このシグネチャに合致したらblockにする」というルールを後から作れる。

レイテンシへの影響

「全リクエストにシグネチャを全件実行したらレイテンシが跳ね上がるのでは」という疑問は自然だ。

Cloudflareの説明では、blockingルールが設定されていない間は、検知処理をリクエストのオリジン送信後に非同期で実行できる設計になっている。リクエストを待たせる必要がないため、ルールを作っていない段階ではレイテンシへの影響はないとしている。blockingルールを設定した場合は、そのルールに関わる検知がインラインに戻り、若干のレイテンシが発生しうる。

シグネチャの信頼度

Attack Signature Detectionのシグネチャにはconfidenceフィールドがある。High / Mediumの2段階だ。

Highは誤検知が出にくいシグネチャで、既存のManaged Rulesetのデフォルト設定と同等の挙動を想定している。特定CVEのペイロード（攻撃コード本体）のように、正規トラフィックと明確に区別できるものが該当する。

Mediumは攻撃検知力は高いが誤検知リスクもあるシグネチャだ。HTMLの入力を許容するCMSやサポートシステムでは、ユーザーが送信した正規のHTMLがXSSシグネチャにヒットすることがある。Analytics上でMediumシグネチャの発火パターンを確認してから、スコープを絞った例外ルールを作る使い方を想定している。

Full-Transaction Detection（開発中）

開発中のFull-Transaction Detectionは、この検知・遮断分離をさらに拡張する。

既存のWAFはリクエストだけを見て判断する。Full-Transaction DetectionはHTTPトランザクション全体、つまりリクエストとレスポンスを相関させて解析する。

これにより従来は見えなかった脅威を検出できると説明している。

反射型SQLインジェクション（リクエスト単体では怪しくないが、レスポンスにDBの痕跡が現れる）
微妙なデータ漏洩パターン（レスポンスに含まれる情報から推定）
レスポンスを見て初めて分かる危険な設定ミス

誤検知率の低減も期待されている。リクエスト単体の解析だとグレーゾーンのシグネチャが多いが、レスポンスの内容と合わせることで「実際に危険な動作をしているかどうか」の判断精度が上がる。現在はEarly Accessの登録受付中だ。

RFC 9849 TLS Encrypted Client HelloによるSNI漏洩の解消

TLS 1.3はハンドシェイクの大部分を暗号化しているが、ひとつ大きな穴が残っていた。ClientHelloメッセージだ。ここにはSNI（Server Name Indication）拡張が含まれ、クライアントがどのドメインに接続しようとしているかが経路上の観察者に丸見えになる。

RFC 9849「TLS Encrypted Client Hello（ECH）」は、このClientHelloを暗号化することでSNI漏洩を解消するIETF標準だ。2026年初頭に正式公開された。

なぜSNIが問題なのか

TLS 1.3はサーバー証明書を含むハンドシェイクの大部分を暗号化する。しかしClientHelloは、サーバーがどの証明書を選ぶかを決める前に送信されるため、暗号化できない構造的制約があった。

SNIは「このTLS接続がprivate.example.orgに向かっている」という情報を平文で送信する。ネットワーク経路上にいるISP、CDN、あるいは検閲機関は、通信内容は読めなくてもどのサービスと通信しているかを把握できる。

HTTPSが普及しても「どのサイトにアクセスしているか」は監視できるという問題は、TLS 1.3が登場した後もずっと残り続けていた。

ECHの動作原理

ECHは「ClientHelloInner」と「ClientHelloOuter」に分割する設計で解決する。

flowchart TD
    A[クライアント] --> B[DNSでECHConfig<br/>公開鍵を取得]
    B --> C[ClientHelloInnerを生成<br/>本当の接続先を含む]
    C --> D[HPKEで暗号化して<br/>ClientHelloOuterに格納]
    D --> E[ネットワーク観察者には<br/>CDNドメインしか見えない]
    E --> F[サーバーが復号して<br/>実際のオリジンへ接続]

ClientHelloInnerが本来の接続先（private.example.orgなど）の情報を含む。これをHPKE（Hybrid Public Key Encryption）でサーバーの公開鍵を使って暗号化し、ClientHelloOuterにカプセル化する。

外から見えるのはClientHelloOuterだけで、そこには本当の接続先ではなく「public name」（CDNなどのプロバイダードメイン）しか含まれない。ネットワーク観察者には「Cloudflareに接続した」とは分かっても「Cloudflare背後のどのオリジンに繋いだか」は分からなくなる。

サーバーの公開鍵はDNSのHTTPSリソースレコード（ECHConfig）経由で配布される。クライアントはDNS応答から公開鍵を取得し、ClientHelloを暗号化してから接続する。

2つのトポロジー

RFCはECHの展開を2つのモードで定義している。

Shared Mode（単体サーバー型）は、接続を終端するサーバーが複数のドメインを収容するケースだ。Cloudflare上でホストされる複数のサービスが同一IPアドレスを共有するイメージに近い。サーバーは自分宛の暗号化されたClientHelloを直接復号できる。

Split Mode（分割型）は、クライアント向けサーバー（Client-Facing Server）とバックエンドサーバーが分かれるケースだ。Client-Facing Serverが暗号化されたClientHelloを受け取るが、どのバックエンドに転送するかは復号してから判断する。バックエンドとの実際のTLS接続はバックエンドが終端するため、プロキシサーバーでさえ実際の接続先を把握できない。

「目立たない」設計

ECHの重要な設計原則のひとつが “Do Not Stick Out”（目立たない）だ。

ECHを使っているクライアントと使っていないクライアントが、ネットワーク観察者から同じに見えることを目指している。ECHを使うことが検出できると、その検出を利用してECH通信をブロックする検閲が成立してしまうからだ。

これを支援するのがGREASE（Generate Random Extensions And Sustain Extensibility）メカニズムだ。ECHに未対応のクライアントも、ランダムなECH拡張を送るようにすることで、実際にECHを使っているかどうかの区別をつけにくくする。

セキュリティ上の注意点

ECHはSNI漏洩を解消するが、それだけではプライバシーは完結しない。

クライアントのDNSクエリが平文であれば、「どのドメインを解決しようとしたか」はやはり観察可能だ。RFC 9849はこの点を明確に指摘しており、DNS over HTTPS（DoH）やDNS over TLS（DoT）などの暗号化DNSと組み合わせることで初めてSNIとDNSの両方を隠せるとしている。

また、サーバーIPアドレスから接続先を推定することも依然可能なケースがある。ECHの保護が有効なのは、多くのオリジンが同一のCDNやリバースプロキシを経由して配信されているような環境だ。

実装状況

ChromeはECHサポートをChrome 117（2023年）の頃から段階的に導入しており、現在は標準で有効だ。FirefoxもECHをサポートしている。サーバー側はCloudflareなどの主要CDNがECHConfig配信に対応済みだ。

RFC 9849の正式公開により、実装の標準的な参照仕様が確定した。ドラフト段階では細部の変更があったが、これで実装のinteroperabilityが明確になる。

CVE-2026-22719: VMware Aria Operations、未認証コマンドインジェクションがKEV登録

脆弱性の概要

CISAは2026年3月3日、VMware Aria OperationsのコマンドインジェクションCVE-2026-22719をKnown Exploited Vulnerabilities（KEV）カタログに追加した。CVSSスコアは8.1（High）。

Broadcomのアドバイザリには「認証されていない悪意ある攻撃者が、サポート支援製品マイグレーション実行中にVMware Aria Operations上で任意のコマンドを実行し、リモートコード実行につながる可能性がある」と記されている。攻撃ベクターはネットワーク経由・認証不要で、特権昇格なしにRCEに至るパスが存在する。

Broadcom側は「野生での悪用報告を把握しているが、独自には確認できていない」と述べているが、CISAはKEVへの追加判断を下した。

影響を受ける製品

製品	修正バージョン
VMware Aria Operations 8.x	8.18.6
VMware Cloud Foundation 9.x.x.x（vSphere Foundation含む）	9.0.2.0

VMware Aria Operations（旧称vRealize Operations）は組織のハイブリッドクラウド全体を統括する管理レイヤーに位置する。侵害された場合の影響範囲はインフラ全体に及ぶ可能性がある。

パッチとワークアラウンド

Broadcomは2026年2月24日にパッチをリリース済み。即時適用が難しい組織向けにシェルスクリプトを使った一時的なワークアラウンドも提供されている。

CISAのBinding Operational Directive（BOD）22-01により、連邦民間機関（FCEB）は2026年3月24日までの修正が義務付けられた。民間組織にも速やかなパッチ適用が推奨されている。

マイグレーション操作中というトリガー条件

この脆弱性が発火するのは「サポート支援製品マイグレーション実行中」というトリガー条件がある点が特徴的だ。大規模なインフラ移行・アップグレード作業と攻撃機会が重なるシナリオで、移行作業を控えている環境は特に注意が必要になる。パッチ未適用の環境では、マイグレーション操作を一時停止するか、ワークアラウンドを適用するまで該当機能を無効化することを検討する。

参照: