ページの先頭です
IIJではセキュリティブランド「wizSafe」を2016年に立ち上げてから、今年で10周年を迎えます。
これまで、お客様が安全にインターネットを利用できる社会の実現を目指し、一貫して活動を続けてきました。その1つがwizSafe Security Signal(注1)を通じた、ブログ形式での定期的なセキュリティに関する情報の発信です。その他にも、IIJサービスのセキュリティログを集約している情報分析基盤(注2)を活用しながら、日々収集している脅威情報と組み合わせた多角的なセキュリティ分析に取り組んでいます。
本稿では、1.2節で2025年に発生した主要なセキュリティトピックをカレンダー形式で振り返ります。続く1.3節では、2025年に急速な広がりを見せた攻撃手法の「ClickFix」を取り上げます。そして1.4節では、急増する脆弱性の効率的な対処において重要性を増している脆弱性の評価指標と、それに関するSOCの取り組みを紹介します。
2025年に話題となった主要なセキュリティに関する出来事の中から、SOCが注目したものを表-1と表-2にまとめます。
表-1 セキュリティトピックカレンダー(1月〜5月)
| 月 | 概要 |
|---|---|
| 1月 | 年始に相次いだDDoS攻撃 通信事業者、金融機関、天気予報メディアといった複数の企業が、自社のサービスを利用しにくい事象が生じたことを公表した。 いずれの事象もDDoS攻撃が原因と見られている。 |
| 2月 | モバイル通信事業者に対する不正アクセス モバイル通信事業者は、第三者が不正に入手したIDやパスワードを用いて回線の契約とモバイル通信サービスを利用する事案があったことを公表した。本事案に関連して、中高生を含む10名以上の逮捕者が出ている。 |
| 3月 | 金融機関を装ったボイスフィッシング詐欺 金融機関を装ったボイスフィッシング詐欺により、複数の企業が不正送金の被害を受けていたことが報道された。自動音声ガイダンスを用いた電話が企業にかけられ、案内に従って操作を行った後にインターネットバンキングの偽サイトへ誘導されたと見られる。また、12月には警察庁が同様のボイスフィッシングによる不正送金被害が再発・急増している旨の注意喚起を行っている。 |
| 4月 | 証券会社のインターネット取引サービスに対する不正アクセス 金融庁は、証券会社のインターネット取引サービスにおいて不正アクセス及び不正取引の被害が急増しているとして注意喚起を行った。不正アクセスには、実在する証券会社のWebサイトを装ったフィッシングサイトなどで窃取した顧客情報が用いられているとのこと。また、同事案では関わった人物の特定にまで至った一部のケースにおいて逮捕者も出ている。 |
| 4月 | CVE(共通脆弱性識別子)プログラムが契約終了の危機に直面 MITREがCVEプログラムの理事会に宛てた内部文書のリークにより、米国政府とのCVEプログラムに関する契約が4月16日に終了することが明らかとなった。しかし、翌4月17日には一転してCISA(米国サイバーセキュリティ・社会基盤安全保障庁)が契約を延長したことを公表している。 |
| 4月 | 株式会社インターネットイニシアティブにおける顧客情報漏えい事件 株式会社インターネットイニシアティブは、法人向けに提供するメールセキュリティサービス「IIJセキュアMXサービス」において、不正アクセスによって顧客情報の一部が外部に漏えいしたことを公表した。不正アクセスの原因は、同サービスで利用していた第三者製のソフトウェアの未知の脆弱性を悪用したゼロデイ攻撃によるもの。本事案に関して、同社は総務省から行政指導を受けている。 |
| 5月 | 偽基地局によるスミッシング事案 総務省は、一部の都市部において不法無線局の疑いのある無線機器(いわゆる偽基地局)からの携帯電話サービスへの混信事案が発生しているとして注意喚起を行った。本事案により、携帯電話が一時的に圏外となったり、フィッシング詐欺などを含む不審なSMSを受信するといった事象が生じたとのこと。 |
| 5月 | NIST(米国国立標準技術研究所)がLEVを提案するホワイトペーパーを公開 NISTは、新たな脆弱性の評価指標としてLEV(Likely Exploited Vulnerabilities)を提案するホワイトペーパーを公開した。LEVは、EPSS(Exploit Prediction Scoring System)やKEV(Known Exploited Vulnerabilities catalog)といった既存の指標が抱える弱点を補完することを目的としている。 |
| 5月 | Lumma Stealerに関連するドメインが国際共同作戦により押収 Microsoft社やEuropol (欧州刑事警察機構)を含む複数の企業及び法執行機関が、Lumma Stealerの活動を阻害する国際共同作戦を実施したことを公表した。Lumma StealerはMalware as a Service(MaaS)モデルで販売される情報窃取型のマルウェアとして知られている。 |
| 5月 | 能動的サイバー防御に関する法律が公布 「サイバー対処能力強化法」及び「サイバー対処能力強化法整備法」が公布された。同法律は、官民連携の強化、通信情報の利用、アクセス・無害化措置を軸とした能動的サイバー防御の実現を目的としている。これにより、サイバー攻撃による重大な危害を防止するために、警察や自衛隊が攻撃に関連するサーバへアクセスして無害化する措置が可能となる。施行は2027年末までに段階的に進む予定となっている。 |
| 5月 | Europolによる国際共同作戦「Operation Endgame」 Europolは、国際共同作戦「Operation Endgame」において、ランサムウェア攻撃に使用されるマルウェア配布インフラを無効化したことを公表した。5月19日から22日にかけて実施された作戦では、約300台のサーバと650のドメインが無効化され、350万ユーロ相当の暗号資産が押収された。また、Operation Endgameでは11月10日から13 日にかけて実施された作戦でも情報窃取型マルウェアのRhadamanthys、リモートアクセスツールのVenomRAT及びボットネットのElysiumに関連するインフラを無効化している。 |
表-2 セキュリティトピックカレンダー(6月〜12月)
| 月 | 概要 |
|---|---|
| 6月 | NetScaler ADC及びNetScaler Gatewayの脆弱性「CitrixBleed 2」 Cloud Software Group社はNetScaler ADC及びNetScaler Gatewayに存在する複数の脆弱性(CVE-2025-5349、CVE-2025-6543、CVE-2025-5777)を公表した。この中でCVE-2025-5777は2023年に見つかった脆弱性(CVE-2023-4966)、通称CitrixBleedとの類似性からCitrixBleed 2という通称で呼ばれるようになる。CitrixBleed 2は実際に悪用が確認されたことで7月にはKEVに追加されている。 |
| 7月 | NISC(内閣サイバーセキュリティセンター)がNCO(国家サイバー統括室)へ改組 NISCがNCOへと改組された。NCOは、サイバー安全保障分野の政策を一元的に総合調整することで、能動的サイバー防御を含む取組を実現・促進する役割を担うことになる。組織の改組は2022年12月に閣議決定された国家安全保障戦略において決まっていた。 |
| 7月 | オンプレミスのMicrosoft SharePoint Serverの脆弱性「ToolShell」 Microsoft社は、同社が提供するオンプレミスのSharePoint Serverに複数の脆弱性(CVE-2025 - 4970 4、CVE-2025 - 49706、CVE-2025 - 53770、CVE-2025-53771)が存在することを公表した。見つかった脆弱性を組み合わせた攻撃はToolShellという通称で呼ばれている。CVE-2025-53771を除く脆弱性は実際に悪用が確認されておりKEVに追加されている。 |
| 7月 | Europolによる共同捜査「Eastwood」 Europolは、親ロシアのハクティビスト集団「NoName057(16)」に対する国際共同捜査を実施したことを公表した。Eurojust(欧州司法機構)や12カ国の法執行機関が参加した共同捜査は「Eastwood」と名付けられている。捜査により、100台以上のコンピュータから構成されるインフラの停止や複数名への逮捕状発行(うち2名は既に逮捕)などの成果を挙げたとされる。 |
| 8月 | FeliCaの脆弱性と情報セキュリティ早期警戒パートナーシップガイドライン ソニー株式会社は、同社の非接触ICカード技術「FeliCa」のICチップのうち、2017年以前に出荷された一部において、データの読み取りや改ざんが可能となる脆弱性が存在することを公表した。この脆弱性は、報道により情報セキュリティ早期警戒パートナーシップガイドラインが想定する公表プロセスを経ずに情報が公開された。本事案に関連して、経産省やIPAが脆弱性情報をガイドラインに則って取り扱うよう要請している。 |
| 9月 | 飲料メーカグループにおけるランサムウェア被害 飲料メーカグループは、ランサムウェアの感染によりシステム障害と情報流出が生じたことを公表した。これにより、国内グループ各社の受注・出荷業務とお客様相談室などのコールセンター業務が停止する影響が生じた。 |
| 10月 | NCOがDDoS事案及びランサムウェア事案におけるインシデント報告の共通様式を公開 NCOは、サイバー攻撃を受けた被害組織が実施する官公署へのインシデント報告に関して、DDoS攻撃事案及びランサムウェア事案で使用できる共通様式や記載例を公開した(注3)。インシデント報告様式の統一は、サイバー攻撃による被害報告件数の増加を背景として、被害組織の報告負担軽減と政府の対応迅速化を目的としている。これにより、被害組織の報告負担が極めて大きいことが課題となっていたDDoS攻撃事案とランサムウェア事案について10月1日から共通様式を用いた官公署への報告が可能となった。 |
| 10月 | Windows 10のサポートが終了 Microsoft社は、Windows 10のサポートを終了した。これにより、当該OS向けのソフトウェア更新プログラムやセキュリティ修正プログラム、テクニカルサポートは提供されなくなる。移行が間に合わない環境では、ESU(拡張セキュリティ更新)プログラムを利用することにより期間限定でセキュリティ修正プログラムの提供を受けられる。 |
| 10月 | オフィス向け用品などの通信販売を手掛ける小売業者におけるランサムウェア被害 オフィス向け用品などの通信販売を手掛ける国内の小売業者は、ランサムウェアの感染によりシステム障害と情報流出が生じたことを公表した。本事案では社内・物流システムと外部クラウドサービスの問い合わせ管理システムが侵害を受けたとみられる。物流センターの入出荷業務に関するシステムに障害が生じたことで、同社の通販サイトのほか他社向けの物流受託サービスも停止するなど影響が波及した。 |
| 11月 | 報道機関におけるチャットツールへの不正ログイン被害 報道機関は、チャットツール「Slack」への不正ログインにより社員や取引先などの情報が流出した疑いがあることを公表した。社員の個人保有のパソコンがマルウェアに感染したことが原因で、窃取された認証情報を元に不正ログインが生じたとみられる。 |
| 12月 | RSC(React Server Components)の脆弱性「React2Shell」 Meta社は、RSCに認証不要でリモートコード実行が可能となる脆弱性(CVE- 2025- 55182)が存在することを公表した。この脆弱性はReact 2Shell という通称で呼ばれており、実際に悪用が確認されたとしてKEVに追加されている。 |
| 12月 | EmEditorのWebサイト改ざんによるマルウェア配布事案 Emurasoft社は、テキストエディタEmEditorのWebサイトが改ざんされていたことを公表した。改ざんにより、ユーザはマルウェアのローダが含まれる偽のインストーラをダウンロードするよう誘導されていたとのこと。また、改ざんは複数回にわたって生じており、それぞれ影響が生じた期間や偽のインストーラへの導線などが異なるとされる。 |
2025年、「ClickFix」と呼ばれる手法を用いた攻撃が急速に広がり、セキュリティ業界で大きな話題となりました。この手法は、SNSやニュース番組でも取り上げられ、社会的にも注目を集めました。
ClickFixは、ユーザの操作を巧みに誘導し、ユーザ自身にコマンドを実行させるソーシャルエンジニアリング型の攻撃です。代表的な手口として、Webサイト上でCAPTCHA認証(人間であることを確認するためのテスト)を模した画面を表示し、そこに記載された指示に従わせることで、「ファイル名を指定して実行」ダイアログからPowerShellを起動し、マルウェアをダウンロードするコマンドを実行させるというものがあります。
この手法は、2024年3月にClearFakeと呼ばれるマルウェア配布キャンペーンで初めて確認されました。当該キャンペーンでは、偽のエラーメッセージを表示し、エラーを修正(fix)するための手順と偽って、コマンドを実行させようとする手口が用いられました。具体的には、まず「Copy」とラベル付けされたボタンをクリックさせて、悪意のあるコマンドをクリップボードにコピーさせます。その後、コピーされたコマンドをWindowsPowerShellで実行させることで、マルウェアをダウンロードさせるという流れになっていました。この手口は、Proofpointが2024年6月に公開したレポート(注4)で「ClickFix」と命名され、その呼称が広く定着しました。
ClickFixはユーザ自身にコマンドを実行させる手法であるため、セキュリティ製品による検出を回避しやすいという特徴があります。また、ClickFixを埋め込んだサイトを容易に作成できるフィッシングキットも公開されるなど、攻撃者にとって利用しやすい環境が整備されていきました。このような背景もあり、ClickFixを用いた攻撃は拡大し、Lumma Stealer配布キャンペーン(注5)やAPTグループLazarusによる攻撃(注6)などにも利用されました。こうした動きは検出数にも表れており、ESETのレポート(注7)では、2024年下半期から2025年上半期にかけて検出件数が517%も増加したと報告されています。
IIJのSOCにおいてもClickFixを用いた攻撃を検出しています。以下では、実際に検出した具体的な事例を紹介し、ClickFixの攻撃パターンを2つ解説します。
最初に紹介するのはClickFixの最も一般的な攻撃パターンとなっているものです。今回検出したサイトはフリーマーケットサイトを装ったもので、検索エンジン経由でアクセスされていました。このサイトにアクセスすると、偽のCAPTCHA画面が表示されます(図-1)。ここで「私はロボットではありません」のチェックボックスをクリックすると、コマンドがクリップボードにコピーされ、次の画面(図-2)に遷移します。この画面には、コピーしたコマンドを実行させる手順が記載されています。具体的には、Windowsキー+Rで「ファイル名を指定して実行」ダイアログを開き、Ctrlキー+Vでコマンドを貼り付け、Enter キーで実行するように指示されています。これに従うと、図-3 のコマンドが実行され、Windows Installerを利用して指定されたURLからマルウェアを含むMSIファイルが取得され、インストールされます。

図-3 クリップボードにコピーされるコマンド(ClickFix)
今回取り上げた画面は日本語表記となっていますが、これは図-4のように攻撃者が偽のCAPTCHA画面で表示される文言を日本語を含めた複数の言語で用意しており、使用する言語を閲覧者のブラウザの言語設定に合わせて自動的に切り替える仕組みとなっているためです。
図-4 指示用文言の言語切り替えの実装部分(一部抜粋)
次に紹介するのは、ClickFixの派生であるFileFixと呼ばれる手法を用いた攻撃です。FileFixは、コマンドを実行させる際に「ファイル名を指定して実行」ダイアログではなく、ファイルエクスプローラを利用する手法です。ファイルエクスプローラは「ファイル名を指定して実行」ダイアログに比べ、日常的に利用される機能であり、攻撃者はユーザに操作の違和感を抱かせないようにしていると考えられます。
今回検出したものは日本国内のサイト起因で発生していました。まず前述のClickFixのパターンと同様に偽のCAPTCHA画面が表示され、ユーザがチェックボックスをクリックすると図-5の画面に遷移します。ここで指示されている内容が前述のものとは異なります。最初に、「Open File Explorer」と書かれたボタンをクリックさせ、ファイルエクスプローラを開かせます。このタイミングで図-6のコマンドがコピーされます。次に、Ctrlキー+Lでアドレスバーにフォーカスを移動させ、Ctrlキー+Vでコマンドを貼り付け、Enterキーで実行させます。この操作を行うと、PowerShellコマンドが実行され、指定されたURLからローダが取得されます。その後、ローダによりマルウェアがダウンロードされ、実行されます。
今回検出した事例では、実行のハードルを更に下げるため、攻撃者はコマンドの後ろに余分なスペースを多数含むコメントを挿入していました。これにより、図-7のようにアドレスバー上ではコマンド部分が隠され、Enterキーを押すように促すコメント部分のみが表示されます。
図-7 アドレスバー上でのコマンドの表示
今回取り上げたもの以外にも、ClickFixを応用した手法は複数報告されています。例えば、ショートカットキーをmacOSやLinuxのものに置き換え、Windows以外のOSのユーザを標的とするケースも確認されています(注8)(注9)。 また、2025年11月には、偽のWindows Updateの画面をフルスクリーンで表示し、アップデート手順を装ってマルウェアをダウンロードさせようとするJackFixという手法も報告されています(注10)。ClickFixへの経路としても、今回紹介したWebブラウジング経由のものだけでなく、メールに添付されたリンクやファイルを介して誘導するものも確認されています。
いずれの手法にも共通するのは、ユーザを巧みに誘導し、本人の自覚がないままコマンド実行を含む操作を行わせようとする点です。コマンド実行をさせるために、攻撃者は通常の手順では求められない操作を要求してきます。そのため、普段のWebサイトからの指示では見られない操作や手順を求められた場合には、実行する前に一度手を止め、その操作が正規の手順として用いられているものであるかを確認することが重要です。
組織的に行う対策としては、コマンド実行環境の利用制限や、不審な通信や端末の挙動の監視が挙げられます。例えば、業務上PowerShellを利用しないWindows端末については、グループポリシーを用いてPowerShellの利用を制限することで、攻撃者の指示に従ってしまった場合でも、PowerShellを利用したコマンド実行であれば防止できる可能性が高まります。また、業務上コマンド実行環境の制限が難しい端末がある場合や追加の対策を行いたい場合には、コマンド実行に伴う不審な通信や端末の挙動をEDRなどで監視することで、異常を早期に検知し、被害拡大を防ぐための迅速な初動対応につなげることができます。
近年、公開される脆弱性の数が急増し、すべての脆弱性に対処することが難しくなっています。加えて、CVSSをはじめとする評価に必要な情報を公開しているNVDにおいて、評価の遅延といった問題が顕在化し、従来使用されているCVSSのような指標に依存した脆弱性対応には限界が生じています。こうした背景から、どのように脆弱性対応の優先付けを効率的に行うのかが重要な課題となっており、様々な脆弱性の評価指標が提案されています。本節の議論を円滑に進めるため、まず主要な脆弱性の評価指標の目的や概要を次項で解説します。
脆弱性の評価指標とは、脆弱性がもたらすリスクの程度を、深刻度・悪用可能性・影響範囲などの観点から定義された基準に基づいて数値や段階で表現し、対応判断や優先度付けを行うための指標です。今回紹介する脆弱性の評価指標は、公開された脆弱性を一意に識別するための識別子であるCVE-IDごとにスコアなどが与えられる仕組みとなっています。
CVSS(Common Vulnerability Scoring System)は、情報システムの脆弱性の深刻度を、特定のベンダーや製品に依存せず、客観的かつ定量的に評価するためのオープンな業界標準として策定されました。CVSSは、脆弱性の評価項目が定められた共通の基準(Metrics)によって評価し、情報システムの脆弱性の深刻度を数値化するシステムです。CVSSは深刻度を0.0から10.0の数値で示し、数値が高い程深刻度が高いことを示します。また、スコアに応じてCritical・Highなどのような深刻度のレベル分けができ、どの脆弱性から優先的に対応すべきかの指標の1つとなりえます。CVSSに関する情報は、CVE-IDをアサインする権利を持ったベンダーがスコアを付け、NIST(米国国立標準技術研究所)が評価し、提供されています。2005年にバージョン1.0が公開されて以降、多くの組織では、脆弱性対応の優先順位付けの判断材料としてCVSSを用いてきました。例として、クレジットカード情報を安全に取り扱うために策定されたセキュリティ基準であるPCI DSS(Payment Card Industry Data Security Standard)では、CVSSのスコアが4.0以上の脆弱性について解決する必要があります(注11)。しかし、CVSSは脆弱性のリスクではなく、脆弱性そのものの深刻度を表す指標のため、CVSSのスコアを単独で対応の優先順位付けに使用するのは推奨されていません(注12)。また、CVSSのスコアのみを活用した対応の優先順位付けを行うと非効率になる可能性がいくつかの研究で指摘されています。例えば、CVSSスコアが高いという理由のみで脆弱性対応を行うことは、ランダムに脆弱性を選択して対応するのと同等だと報告している研究があります(注13)。更に、近年の脆弱性の傾向からスコア7.0以上(深刻度がHigh以上)に分類される脆弱性の割合が高いため、CVSSスコアのみを活用した対応の優先順位付けを行った場合、対応数が多くなってしまう可能性もあります。図-8は、NVDが公開している情報を元に独自に集計したものであり、2025年に発行された脆弱性48,185 件のうちの22,184件(46.0%)がスコア7.0以上となっており、脆弱性数も年々増加していることが分かります(注14)。そのため、例えば、「CVSSのスコアが7.0以上(深刻度がHigh以上)であれば脆弱性対応の対象とする」というような運用であれば、多数の脆弱性を同時に対象とすることとなり、対応の優先順位付けやトリアージに要する負担が大きくなる可能性があります。加えて、脆弱性数も年々増加傾向にあるので、この運用の場合、今後も対応の対象となる脆弱性が増加すると推測できます。
図-8 年度別の脆弱性の総数と深刻度の割合を表した帯グラフ
KEV(Known Exploited Vulnerabilities catalog)は、サイバーセキュリティコミュニティやネットワーク防御担当者の利益や、組織が適切に脆弱性を管理することを目的として作成されました(注15)。KEVとは、実際に攻撃で悪用されていることが確認された脆弱性の一覧のことで、CISA(米国サイバーセキュリティ・社会基盤安全保障庁)が公開・管理しています。通常の脆弱性情報は非常に多岐にわたり、すべての脆弱性に優先順位を付けて対処することは現実的ではありません。KEVは、その膨大な脆弱性の中から「既に悪用が確認されている」という最も緊急性の高い情報を選別し、組織が優先的に対処すべき脆弱性を明確にするための重要な指標となっており、多くの組織が脆弱性管理に利用しています。しかし、実際に悪用が確認された脆弱性の中の数パーセントしかKEVに掲載されていないというCisco社の報告があり、網羅性に不安があります(注16)。例えば、Sky社が提供する企業向けのクライアント運用管理ソフトウェア「SKYSEA Client View」の脆弱性「CVE-2016-7836」は、2016年12月22日時点でこの脆弱性を悪用した攻撃活動が報告されていましたが、KEVに追加されたのは2025年10月14日でした(注17)。
EPSS(Exploit Prediction Scoring System)は、脆弱性が実際に悪用される可能性という未来の脅威を予測するために作成されました。EPSSとは、「今後30日以内に、その脆弱性が実際にサイバー攻撃によって悪用される確率」を予測するための評価システムのことです。世界各地の政府機関・民間企業・教育機関などのCSIRTがメンバーとして参画しているFIRSTという団体が開発・管理しています。FIRSTは、機械学習を用いて算出した今後30日以内に脆弱性が悪用される確率を示すEPSS のスコアや、EPSSのスコアを順位へ変換したパーセンタイルを提供しています。EPSSの論文によると、EPSSではCVSS Metricsの項目や公開されている攻撃コード、外部センサーネットワークで観測した悪用通信の有無の情報など、様々な情報を活用しています(表-3)。CVSS Metricsの項目や公開されている攻撃コード、KEVといったCVEについて言及しているリストやサイトなどの情報は、モデルの入力で利用されているとのことです。更に、悪用通信の有無の情報は、表-3にlabels と書かれていることから、推論時のモデルの入力ではなく学習時の教師データとして目的変数に使用しており、Fortinet やGreyNoiseなどの外部センサーネットワークを情報源としています。また、EPSSのスコアとパーセンタイルは毎日再計算され、最新の脆弱性関連情報が反映されるため、数値が日々変動します。EPSSのスコアを算出する機械学習モデルの再学習や特徴量の増加などによるバージョン更新が不定期でされており、直近では2025年3月にEPSSのバージョン3からバージョン4への変更が行われています。
表-3 EPSSが使用している情報源 出典:Jacobs et al. (2023), Table 1.(注18)
EPSSのスコアの変動の例として、AI開発ツール「Langflow」のバージョン1.3.0未満に含まれる脆弱性「CVE-2025-3248」のEPSSのスコアの推移を可視化したグラフを図-9に示します。横軸は日付、縦軸はEPSSのスコアの場合は機械学習を用いて算出した今後30日以内に脆弱性が悪用される確率、パーセンタイルの場合は該当の脆弱性よりもEPSSのスコアが低い脆弱性が占める割合を示しており、赤い破線はKEVに追加された日付を示しています。本節では、このように時間経過に伴うEPSS のスコアの変化を示した図を「EPSSのスコアの変動グラフ」と呼びます。
図-9 Langflowの脆弱性
「CVE-2025-3248」のEPSSのスコアとパーセンタイルの推移
CVEが発行された当初はスコアが低いですが、数日後にスコアが急激に伸びており、約1ヵ月後にKEVに追加されています。EPSSを活用した運用では、基本的にEPSSのスコアについて閾値を定め、その閾値を超えた脆弱性についてどう対応するかを決定する形になるので、例えば「EPSSのスコアが0.6以上であれば脆弱性対応」という運用であれば、KEVに追加される日より前にCVE-2025-3248を対応できます。このように、EPSSは脆弱性対応の優先付けの判断材料の1つになりえる指標と考えられます。
しかし、EPSS導入と活用に関する事例が公式にまとめられておらず、脆弱性対応を決定するスコアの閾値は組織ごとに設定する必要があり、どこに線を引くかは組織次第で、明確な基準がありません(注19)。例えば、CVSSなら深刻度がHigh以上の脆弱性、KEVならリストに追加された脆弱性というように基準を立てやすいですが、EPSSのスコアを活用する場合は0 〜1のどこかに値を設ける必要があります。更に、その設定した値がどの程度信頼できるかの判断も組織ごとに考慮する必要があります。また、EPSSのスコアは機械学習モデルで算出しており、機械学習に使用するデータセットや学習済みモデル、ソースコードの公開もされていないため、算出されたスコアの説明可能性がほとんどありません(注20)。そのため、スコアが高い、または低い理由を特定することはできず、原因を推測することしかできません。
LEV(Likely Exploited Vulnerabilities)は、従来のKEV(悪用された事実)やEPSS(将来の予測)を補完することを目的に策定されました。KEVは前述のようにすべての悪用された脆弱性が記載されているわけではなく、KEVのみでは対応漏れがある可能性があります。また、EPSSは将来悪用される確率を示しており、過去に悪用されたかどうかの情報は含みません。LEVとは、過去に悪用された可能性を定量的に推定する評価システムで、2025年にNISTが提案した新しい指標です。LEVは、過去のEPSSのスコアを積算し、「脆弱性が過去に悪用された確率」を推定します。これにより、特定の時点のスコアを基に判定するEPSSとは異なる時間軸の情報を得ることができ、EPSSでは拾いにくい「中程度のスコアが継続していた脆弱性」なども累積的に評価されます。その結果、KEVに掲載されていない脆弱性を補足できる可能性があり、対応漏れを減らす観点で補完的に活用し得る指標と考えられます。しかし、LEVのスコアは過去のEPSSスコアに大きく依存するため、EPSSの予測誤差や過小評価・過大評価が存在する場合、それらの誤差がLEVにも累積して反映される可能性があります。
SSVC(Stakeholder-Specific Vulnerability Categorization) は、組織の脆弱性に対する対応行動を標準化・透明化することを目的に策定されました。SSVCとは、組織が自身の状況とリスク許容度に基づいて、脆弱性への対応を迅速かつ効率的に決定するための意思決定ツリーフレームワークのことです。これまでの(KEVを除く)脆弱性の評価指標が何らかの脅威度を数値化していたのに対し、SSVCでは、特定の組織(ステークホルダー)ごとに脆弱性の対応方針を導くための決定木が用意されており、決定木の分岐点ごとに評価してたどっていくことで「脆弱性への対応方針」を導くことができます。しかし、決定木の分岐点となっているMission ImpactやSafety Impactを判断するには組織固有の情報が必要で、評価者の資産・構成管理情報の理解度によって対応方針の判定が変わってしまう可能性があります(注21)。この判断を正確に行うためには資産・構成管理情報を把握しておく必要があり、評価者ごとに判定の揺れが起きにくくしなければなりません。
これまで脆弱性の評価指標の特徴と違いを整理しましたが、以下では、それらを踏まえてIIJのSOCが脆弱性の評価指標の活用を検討するに至った背景について述べます。
新しい脆弱性が公開される前後のタイミングで悪用が始まるケースが増えています。VulnCheckの分析によれば、最新の2025年上半期において、実際に悪用が確認された脆弱性のうち32.1%がCVE公開当日またはその前に悪用されており、2024年と比較して8.5ポイント増加しています(注22)。これは、公開後の迅速な攻撃に加えて、公開前から既に攻撃が行われている可能性を示唆します。こうした状況では、SOCは新規公開された脆弱性の情報を常に把握する必要があります。そうでなければ、SOCのお客様のネットワークやシステムに対するリアルタイム監視の中で、新たな脆弱性の攻撃の兆候を見逃してしまうリスクが高まります。
しかし、現実には、毎日のように多数の脆弱性が公開されており、それらすべてに追従するのは現実的ではありません。本来SOCが優先的に把握したいのは、悪用される可能性が高い脆弱性や既に悪用が確認されている脆弱性など、攻撃リスクが高く、お客様の環境に重大な影響を与える可能性があるものです。しかし、どの脆弱性を優先的に見るかの選定は、調査者の経験に依存しがちで、属人的で安定性に欠けるという課題がありました。こうした背景から、攻撃リスクの高い脆弱性を調査者に依存せず安定的に選定するために、新たな脆弱性の評価指標の活用を検討することにしました。その中でも特に注目したのはEPSSです。
EPSSは、脆弱性が今後悪用される確率を予測する仕組みであり、脅威の早期把握に寄与する可能性があります。EPSSを活用することで攻撃者が動き出す前に脆弱性を把握するという、より能動的な脆弱性情報の把握ができるのではないかという期待があり、EPSSを中心とした評価指標の活用の検討を進めることにしました。
前項で述べたとおり、IIJのSOCではEPSSを中心とした評価指標の活用を検討しました。本項では、EPSSの活用方法を検討した際に明らかになったEPSSの利点と課題について、様々な脆弱性の事例を用いて紹介します。
まず、EPSSの良い点として、検証を通して、EPSSのスコアの絶対値が高い脆弱性やスコアが上昇している脆弱性が、攻撃コードの公開などの悪用リスクに関連する事象と相関していることが多いことを確認しました。これらの相関は、脆弱性が実際に悪用される可能性を示すシグナルとなりえるため、SOCアナリストが優先的に把握すべき対象を絞り込む際の判断材料として有用です。
ここで、なぜEPSSのスコアの絶対値や上昇値に注目するのかを説明します。ここで言うEPSSのスコアの上昇値は、EPSSのスコアが最初に計算された日からどれだけ上昇したかを示す変化量を指します。EPSSスコアの絶対値と上昇値は、EPSSスコアの定義に基づき、以下のような意味になります。
このため、スコアの高さや上昇傾向を確認することで、悪用される可能性が高い脆弱性をKEVへの追加前のタイミングで特定できると考えられます。ここでは、2025年に公開された脆弱性を多数分析した結果から早期に特定できそうな事例を紹介します。
例えば、Erlang/OTPのSSH実装に存在するリモートコード実行の脆弱性「CVE-2025-32433」のEPSSのスコアの変動グラフを図-10に示します。また、悪用通信が確認された日を青の破線、Proof-of-Concept(PoC)の公開日を紫の破線で示しています。
この脆弱性の公開当初である4月18日以降からスコアが若干上昇していますが、同時期にPoCが公開されており、これによってスコアが上昇していたと考えられます(注23)。更に、5月に入ってからスコアが急激に上昇しています。この上昇と同じタイミングで悪用通信が観測されたことをPalo Alto Networks社が報告しています(注24)。前述のとおり、EPSSは悪用通信の観測情報をモデルの入力としていないことから、機械学習モデルが有効に働きEPSSのスコアリングにうまく反映できたと考えることができます。この脆弱性がKEVに追加された時期は、悪用通信の観測からある程度経過した6月9日であり、EPSSを活用することで悪用される可能性が高いことをKEVへの追加前に特定できると考えられます。
図-10 Erlang/OTPの脆弱性
「CVE-2025-32433」のEPSSのスコアとパーセンタイルの推移
また、Next.jsのミドルウェアにおける認可バイパスの脆弱性「CVE-2025-29927」のEPSSのスコアの変動グラフを図-11 に示します。
この脆弱性の公開当初である3月24日頃からスコアが急激に上昇していますが、同時期にPoCが公開されており、これによってスコアが伸びていると考えられます(注25)。更に同日にCensys社が悪用通信の観測を報告しており、こちらもEPSSのスコアリングがうまくいっているように見えます(注26)。この脆弱性はKEVに追加されておらず、EPSSを活用することで悪用される可能性が高いことを特定できる脆弱性の1つと言えます。
図-11 Next.jsの脆弱性
「CVE-2025-29927」のEPSSのスコアとパーセンタイルの推移
以上の具体例のように、スコアの絶対値が高い・スコアが上昇している脆弱性は、悪用リスクに関連する事象と相関する可能性が高いです。そのため、スコアの絶対値や上昇値を基に脆弱性を特定するルールを作成すれば、攻撃リスクの高い脆弱性を早期に把握できます。
一方で、課題もあります。例えば、悪用報告がされた時期で、スコアの上昇がほとんど見られず、スコアも低い脆弱性が存在します。具体例として、Trend Micro Apex OneのOSコマンドインジェクションの脆弱性「CVE-2025-54948」のEPSSのスコアの変動グラフを図-12に示します。
この脆弱性は8月6日にTrend Micro社より悪用報告がされていますが、このタイミングでスコアは上昇せず、KEVに追加されたタイミングで上昇しています(注27)。EPSSは、悪用報告をモデルの入力として利用する仕組みではないため、仕様上スコアが連動しませんが、この脆弱性のように実際に悪用が確認されている状況でもスコアが変動しないケースがあります。また、KEVに追加されたタイミングでスコアが上昇する特徴は、前述のErlang/ OTPの脆弱性と同様であり、KEVへの追加がEPSSのスコアの上昇にある程度寄与していることが考えられます。そのため、スコアの上昇が見られない脆弱性の場合は、KEVと併用することで、より精度の高いリスク評価が可能になります。ただし、KEVへの追加が遅い場合もありますので、注意が必要です。
図-12 Trend Micro Apex Oneの脆弱性
「CVE-2025-54948」のEPSSのスコアとパーセンタイルの推移
特に、IPAによれば、日本製品に存在する脆弱性については脅威情報の不足により、算出されるEPSSのスコアが低くなってしまう懸念があるとのことです(注28)。例として、Active! mailのスタックベースのバッファオーバーフローの脆弱性「CVE-2025- 42599」のEPSSのスコアの変動グラフを図-13に示します。
この脆弱性について、4月18日に開発元の企業が悪用を確認した旨を公表しましたが、このタイミングでスコアは上昇しませんでした(注29)。推測ですが、日本製品に存在する脆弱性のEPSSのスコアが上昇しない原因として、日本で多く利用されている製品の脆弱性の場合は、EPSSが情報提供を受けているグローバルな外部センサーネットワークで観測されにくく、EPSSのモデルの学習に使用される教師データに反映されにくい可能性があることが挙げられます。
図-13 Active! mailの脆弱性
「CVE-2025-42599」のEPSSのスコアとパーセンタイルの推移
これまで説明してきた事例以外にも、モデル変更による影響も考慮する必要があります。EPSSはバージョン3からバージョン4へのモデル変更で精度が向上しましたが、固定の閾値で脆弱性を特定する場合、モデル変更時に閾値を調整する必要があります。モデル変更の影響を把握するには、開発者の情報発信の確認や、検証用のスコアデータをある程度の期間収集する必要があります。
本節では、EPSSを脆弱性対応の評価指標として活用できるかを検討する過程で明らかになった利点と課題について、複数の脆弱性の事例を基に確認しました。
まず、EPSSの有用な点として、スコアの絶対値が高い脆弱性や、スコアが上昇している脆弱性は、悪用リスクに関連する事象と相関する可能性が高いことが挙げられます。このため、EPSSのスコアやその変化を継続的に監視することで、将来的に悪用される可能性の高い脆弱性を把握しやすくなる点は、脆弱性対応において大きな利点と言えます。
一方で、課題も存在します。脆弱性の悪用報告があるが、スコアが上昇しない脆弱性が存在する点です。特に、日本など特定の地域で主に利用されている製品については、実際に悪用が確認されていてもスコアが上昇しない場合があることを確認しました。また、前述のEPSSの説明のとおり、スコアの閾値の設定は組織ごとに設定する必要があり、その設定した値がどの程度信頼できるかの判断もする必要があります。それに加えて、EPSSはバージョンアップのたびにモデルが更新され、スコアの分布や傾向が変化する可能性があるため、閾値を決めること自体が課題となる場合があります。
以上を踏まえると、EPSSは、組織内における脆弱性対応の優先順位付けに役立つ有効な指標です。ただし、把握すべき製品の脆弱性が正しくEPSSに反映されないこともありますので、セキュリティベンダーが発信する脆弱性に関するレポートや、SNSなどを通じて日本など特定地域での悪用情報を収集し、複数の情報を組み合わせて判断することが重要です。また、EPSSは単体では判断が難しい場面もあるため、従来から利用されているCVSS やKEVといった指標と併せて活用することが望ましいです。
本稿では、2025年のセキュリティトピックを振り返り、SOCの観測情報や取り組みを紹介しました。
1.2節のセキュリティサマリでは、ランサムウェアを始めとする不正アクセスやフィッシング詐欺によって深刻な被害が生じていることが分かります。また、能動的サイバー防御に関する法案が成立したことで、それに関する動きが本格化した1年でもありました。
1.3節では、ソーシャルエンジニアリング型の攻撃手法であるClickFixについてSOCでの観測事例と併せて紹介しました。ClickFixでは、ユーザの操作を巧みに誘導することでユーザ自身に悪性のコマンドを実行させます。数多くの派生型と共に盛んに悪用されていることから今後も注意と対策が必要です。
1.4節では、主要な脆弱性の評価指標とSOCにおける活用の取り組みを紹介しました。今回はEPSSに焦点を当てて検討を進めたところ、一定の有効性を確認すると共に今後の活用における課題も明らかとなっています。
SOCでは引き続きセキュリティ分析から得られた情報をwizSafe Security SignalやIIRなどを通じて発信していきます。今後もセキュリティ対策や業務に役立てていただければ幸いです。
執筆者プロフィール

小林 智史 (こばやし さとし)
IIJ ネットワークサービス事業本部 セキュリティ本部 セキュリティオペレーション部 データ分析課

宮岡 真平 (みやおか しんぺい)
IIJ ネットワークサービス事業本部 セキュリティ本部 セキュリティオペレーション部 データ分析課

阿部 航大 (あべ こうた)
IIJ ネットワークサービス事業本部 セキュリティ本部 セキュリティオペレーション部 データ分析課
ページの終わりです