KEVIntelのCEOを務めるRyan Dewhurst氏が、CISAのカタログにまだ掲載されていない悪用事例をチームがどのように確認しているかを説明します。同氏は、脆弱性が一般公開フィードに載る前に、グローバルなハニーポットセンサーネットワーク、AIによるトリアージ、そしてラボでの人間による検証を経る流れを紹介しています。
同氏はまた、BOD 26-04に基づくCISAの3日間のパッチ適用期限、なぜ仮想パッチが時間稼ぎになるのか、そしてAI生成の概念実証(PoC)コードが証拠をいかに混乱させるかについても語っています。さらに、インシデント報告、ハニーポットでの検知、スキャン、PoCに関する情報が、防御側の確信度をどの程度動かすべきかをランク付けしています。
CISAのカタログは連邦機関に修復期限を課しているため、エントリーの追加は技術的な行為であると同時に政策的な行為でもあります。民間セクターのセキュリティ専門家は、こうした圧力のもとで作成されたリストをどう読み解くべきでしょうか。
民間セクターにとって、CISA KEVは権威ある悪用シグナルの情報源です。しかし、これをKEVの完全かつ決定的なリストとみなすべきではありません。CISAが比較的大きな組織であり、それが対応速度に影響しうること、そして米連邦機関寄りのバイアスがかかっていることも無視できません。
CISAが2026年6月10日に発行した最近のBOD 26-04「リスクに基づくセキュリティアップデートの優先順位付けに関する実施ガイダンス」により、連邦機関は自動化可能でインターネットに接する資産に影響を及ぼす、現に悪用されているKEVについて、対応期限がわずか3日間となりました。
この新しい指令は、組織がリスクの高いKEVを最優先すべきだという事実を改めて裏付けています。現在、1日あたり平均で約200件のCVEが公開されており、この数は年々増加しています。特にAIの台頭がそれに拍車をかけています。すべての脆弱性、あるいは緊急度・重要度の高い脆弱性だけであっても、すべてにパッチを当てるのは事実上不可能です。
わずか3日間で脆弱性にパッチを当てるというのは、かなり野心的な目標です。パッチ管理は多くの関係者を経る必要があり、通常は変更管理チームが担当します。組織に効果的な資産管理体制が整っていない場合、そもそもどのような資産を保有し、誰が管理責任者なのかを把握するだけでも、時間のかかる作業になることがあります。
組織に必要なのは、もっと多くの時間です。しかし攻撃者はそれを待ってくれません。攻撃者がAIを使ってパッチをリバースエンジニアリングし、記録的な速さで脆弱性を武器化する動きは、ますます加速していることが確認されています。
この問題への一つの解決策が仮想パッチです。これは通常、組織が脆弱なデバイスにパッチを適用するまでの間、攻撃をブロックするために設計されたWAFルールを指します。例えば、最近ではWordPress CoreのRCEチェーンへの露出を減らすため、プロバイダーがこれを効果的に活用している事例を確認しています。ただし、仮想パッチはあくまで長期的な解決策ではなく、完璧なものでもありません。本来のパッチ適用が完了するまでの時間稼ぎとしてのみ用いるべきです。
ベンダーには、悪用の主張を誇張する理由も、逆に抑え込む理由もあります。現時点で、その圧力はどちらの方向により強く働いていると見ていますか。そして、そのツケは誰が払うことになるのでしょうか。
これは本当にベンダー次第です。脆弱性のリスクを誇張するベンダーもいれば、逆に軽視しようとするベンダーも見てきました。例えば、軽視する側の例としては、ベンダーが「この脆弱性は認証済みの場合にのみ悪用可能だ」と主張していたにもかかわらず、詳しく調べてみると実際には匿名の未認証ユーザーでも悪用可能だった、というケースがありました。あるいは、「この脆弱性は実際には悪用されていない」と主張しながら、そのアドバイザリにインシデント由来のIoC(侵害指標)を含めているケースもあります。これは大きな危険信号です。
最終的にそのツケを払うのは、そのベンダーの顧客です。やがて詳細は明らかになるのが通常ですが、その間にも攻撃者はこの混乱を最大限に利用し、顧客は後手に回って対応を迫られることになります。
これまで追いかけた中で最も説得力のあった誤検知(実際の悪用に見えて実はノイズだった事例)は何ですか。そこから何を学びましたか。
これはかなり頻繁に見られる現象です。多くの「研究者」は、限られた脆弱性情報をLLMに渡し、PoCを生成するよう求めます。AIは与えられた限られた情報の中で最善を尽くしてPoCを作成しますが、実際にはその脆弱性を悪用できるコードにはなっておらず、研究者を納得させられる程度にそれらしく見えるだけ、というケースがよくあります。これが一つの脆弱性につき何十回も起こることさえあり、何が「AIスロップ(質の低いAI生成物)」で何が本物の動作する攻撃コードなのかを見分けるのが難しくなっています。
最近では、Fortinet FortiSandboxのOSコマンドインジェクション脆弱性であるCVE-2026-25089で、まさにこうした事例を目にしました。
例えば、私たちのセンサーが新種の悪用を検知して私たちに通知しても、それが「AIスロップ」なのかそうでないのかを判断するには、時間をかけて調査し、脆弱性の再現を試みる必要があります。
そして、攻撃者側のテレメトリだけからそれを見分けるのは、時に非常に困難です。PoCは正しい標的ソフトウェアや正しい脆弱なエンドポイントを使用していることが多いためです。
多くの場合、わかりやすい手がかりは技術的な詳細そのものよりも、PoCのドキュメントの書き方に表れます。それはAIが書いたものなのか。それとも信頼できる研究者によるものなのか。その人物は過去に虚偽のPoCを公開したことがあるのか、それとも豊富な経験と良い評判を持つベテラン研究者なのか。
これらは見分けやすい兆候ではありますが、最終的な決め手となるのは、あくまで脆弱性を技術的に再現できるかどうかです。
ハニーポットでの検知、インターネット全体を対象としたスキャン、PoCに関する情報、インシデント報告。これらを、防御側の確信度をどの程度動かすべきかという観点でランク付けし、過剰に信頼されがちなものを一つ挙げてください。
1. インシデント報告
これは非常に有用です。防御側が攻撃緩和に活用できる技術的詳細、攻撃者の手口、IoCが豊富に含まれていることが多いためです。しかしその裏を返せば、それはすでに実際の悪用が進行中であることを意味します。
2. ハニーポットでの検知
私たちのハニーポットセンサーで検知された悪用が、正真正銘の悪用(KEV)であると検証された場合、これは防御側にとって最優先事項とすべきです。攻撃者はその脆弱性を積極的に狙い、インターネット上の実際のデバイスを悪用しようとしています。次に狙われるのはあなたかもしれません。
3. インターネット全体を対象としたスキャン
これは「スキャン」が何を指すかによります。インターネット全体を対象とした能動的なプロービングデータには、一定の利点があります。例えば、悪用が発生する前にプローブが急増するのをよく目にします。
また、標的を絞った悪用が行われた後に、インターネット全体を対象とした大規模な悪用が続くこともよくあります。悪用は当初、脆弱なソフトウェアに対するごくわずかな試行という、非常に的を絞った形で始まることが多いのですが、しばらくすると攻撃者がインターネット上のあらゆるデバイスを無差別にスキャンし始める様子が見られるようになります。
4. PoCに関する情報
これは過剰に信頼されがちなものです。PoCに関する情報は有用な場合もあります。しかし先述の通り、何を信用すべきかについては慎重を期す必要があります。Nuclei、Nessus、Metasploitといった既存のスキャナーから出されたPoCは、概して信頼できます。一方で、GitHubにAI生成のPoCを投稿しているだけの見知らぬ人物による情報は、割り引いて受け止めるべきです。
KEVIntelは、CISAのカタログには一度も掲載されなかった、悪用済みの数百件のCVEをこれまでにフラグ立てしてきました。そうしたギャップを発見した際、自分たちの判断が正しく、政府側のリストが遅れているだけだと、どのように確信するのでしょうか。
本稿執筆時点で、私たちは現在CISA KEVカタログに含まれていないCVEを1,000件以上追加しています。新たな既知悪用脆弱性(KEV)を検知する方法は、独自のグローバルなハニーポットセンサーネットワークを活用することに加え、ベンダーのアドバイザリや研究者のブログといった信頼できるオンライン情報源を監視することです。
私たちは、自分たちのセンサーネットワークを通じて悪用を確認することで、その判断の正しさを担保しています。
私たちはセンサーを、オーストラリア、カナダ、欧州、米国、中東など、世界中のさまざまな国や地域に展開しています。可能な限り、私たちのセンサーはインターネット上に設置された実際のアプリケーションやデバイスであり、攻撃者がそれらをどのように攻撃してくるかを記録しています。
センサーが新種の攻撃を検知すると、まず第一段階として、AIを用いてそれが既知の脆弱性なのか、未知の脆弱性なのか、それとも単なるランダムなインターネットプロービングなのかを判定します。適切なプロンプトとガードレールがあれば、最先端のAIモデルはこの作業を非常に高い精度でこなせるようになっています。
そのAIによる結果は、次に人間のセキュリティ研究者に渡され、AIの判定内容を手作業で検証します。これは既知のPoCと一致するか、CVEの帰属付けは正しいか、この攻撃はラボ環境で再現できるか、といった点を確認します。
最終的に、セキュリティ研究者がその攻撃を真の悪用事例であると確信した段階で、攻撃者のテレメトリから検知ルールが作成され、過去および今後のすべての攻撃データが私たちのKEVIntelプラットフォームへと転送される仕組みになっています。
また、悪用が非常に的を絞ったもの、例えば特定のソフトウェアベンダーの顧客一社だけを狙ったものである場合、そのベンダー自身が侵害指標(IoC)とともに公表することがよくあります。こうしたケースでは、私たち自身のセンサーではまだ攻撃を検知していなくても、証拠が十分であり、かつ信頼できる情報源から得られたものであれば、その脆弱性を公開KEVフィードに追加し、自社センサーでの悪用状況を継続的に監視します。
翻訳元: https://www.helpnetsecurity.com/2026/07/30/ryan-dewhurst-kevintel-known-exploited-vulnerabilities/
