# ゼロデイ攻撃とは

修正パッチの提供前に脆弱性を悪用する攻撃です。パッチがない期間に組織が行う緩和、露出の削減、検知と、パッチ公開後の侵害調査を解説します。

## ゼロデイ攻撃とは

ゼロデイ攻撃は、提供元の修正パッチがまだない脆弱性を悪用する攻撃です。脆弱性は、[不正アクセスなどの攻撃を受けると本来の機能や性能を損なう原因になり得る、ソフトウェアやWebアプリケーションの問題箇所](https://www.ipa.go.jp/security/todokede/vuln/uketsuke.html)です。攻撃者は修正前の弱点を悪用して機器やシステムに侵入し、情報の窃取や[ランサムウェアの展開](https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review)の足場にすることがあります。

脆弱性の公表とパッチの公開は同時とは限らず、Googleの脅威分析チームGTIG（Google Threat Intelligence Group）は、公表の後でも[パッチの公開前に攻撃で悪用された脆弱性](https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review)をゼロデイとして集計しています。

典型は社外から社内に接続するVPN（Virtual Private Network）機器です。2025年1月に公表されたIvanti社のVPN製品の脆弱性CVE-2025-0282は、[公表前の2024年12月下旬から国内で悪用され、被害が複数確認されています](https://www.jpcert.or.jp/at/2025/at250001.html)。[修正の公開時点で、一部の組織はすでに侵入されていました](https://www.jpcert.or.jp/at/2025/at250001.html)。

たとえば、錠前の欠陥をメーカーより先に泥棒が発見し、合鍵を作成している状態です。パッチの公開後に開始される悪用は[Nデイ](https://cloud.google.com/blog/topics/threat-intelligence/time-to-exploit-trends-2023)と呼ばれ、悪用より先にパッチを適用すれば、その脆弱性を悪用する攻撃を防止できます。ゼロデイ攻撃は、適用するパッチがない期間に発生する点が異なります。

![パッチの公開前の悪用がゼロデイ攻撃、パッチの公開後に開始される悪用がNデイ攻撃です](https://media.marketing.kdotdev-tunnel.org/glossary-zero-day-4270c738be2152446a7ccf4760fde4b172a5a2d23832dff5b48afbde1f7d4d9f.png)

## パッチの適用だけではゼロデイ攻撃に対処できない理由

パッチの準備前に脆弱性が公表されると、[パッチの公開まで数日、数週間、あるいは数か月かかることがあります](https://doi.org/10.6028/NIST.SP.800-40r4)。その間はパッチの適用以外の手段で対処し、被害の可能性を低減します。

2025年に悪用されたゼロデイは、GTIGが追跡した範囲で[90件あり、48%は企業向けの製品の脆弱性](https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review)でした。企業向けの製品を利用する組織も、ゼロデイの標的に含まれます。

![GTIGの集計では、2025年のゼロデイ90件のうち企業向け製品の脆弱性が48%、その他が52%です](https://media.marketing.kdotdev-tunnel.org/glossary-zero-day-fd2749003f093a05384a53e77a3070b8335eafaeba76f2f7d7a9af2027d189bc.png)

標的になりやすいのは、インターネットと社内ネットワークの間に設置するVPN機器やファイアウォールなどのエッジ機器です。[2024年に悪用された企業向け製品のゼロデイのうち、6割超はセキュリティ製品とネットワーク製品の脆弱性でした](https://cloud.google.com/blog/topics/threat-intelligence/2024-zero-day-trends)。

GTIGは、[大半のエッジ機器にはEDR（Endpoint Detection and Response）がなく、防御側の死角になり得る](https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review)と指摘しています。EDRはパソコンやサーバーで不審な動作を検知する仕組みです。

## 自社への影響の有無を判別する条件

ゼロデイの報道があったときは、まず次の点で自社への影響の有無を判定します。

- その製品とバージョンを、機器として、または自社開発のシステムの構成要素として利用している

利用していなければ対象外です。利用している場合は、露出と悪用の状況で対応の重さを分けます。

- その機器や画面がインターネットから到達できるなら、パッチの公開前でも対処を開始する
- ブラウザやメールソフトのように、外部から受け取ったWebページやファイルを処理する製品は、インターネットから到達できなくても同じ扱いにする。例えばChromeのゼロデイCVE-2025-6554は、[細工したHTMLページを開かせて悪用されました](https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2025-065/)
- さらに、悪用にログインが不要で外部から直接操作できるか、悪用が確認されていれば優先する
- インターネットから到達できない機器も対象から外さず、社内から接続できる範囲を確認する

![利用していなければ対象外で、利用していれば外部からの到達か外部のファイルの処理の有無と、ログイン不要か悪用確認済みかで対応の重さが分かれます](https://media.marketing.kdotdev-tunnel.org/glossary-zero-day-f1047182cd2205120f0559e60c5a64f94d3bb3085a0457936e8864efed6a7a14.png)

悪用の有無は、[KEV（Known Exploited Vulnerabilities）カタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)、[JPCERT/CC（JPCERTコーディネーションセンター）の注意喚起](https://www.jpcert.or.jp/at/2026.html)、提供元の告知で確認できます。KEVカタログは米国のCISA（Cybersecurity and Infrastructure Security Agency）が公開しています。

自社開発のWebアプリケーションが利用するオープンソースのライブラリは、機器の一覧では判別できません。システムごとのライブラリと版の一覧である[SBOM（Software Bill of Materials）](https://www.cisa.gov/sbom)を作成しておくと、該当の有無を確認できます。

自社開発のシステムを持つ組織では、開発の担当者がSBOMを作成しておきます。開発を外部に委託している場合は、委託先に作成を依頼します。

ブラウザやスマートフォンのように自動更新される製品は、修正版が配布されていれば、全台に適用されたかを確認します。悪用が確認されたゼロデイでは、更新の前に悪用された可能性も残るため、更新で完了とせず、不審な動作がなかったかも確認します。修正版が未配布の間は、他の製品と同じ条件で判定します。

## パッチの公開前に実施するゼロデイ攻撃への対策

### 緩和でパッチの公開までの時間を確保する

緩和は、機能の停止や通信相手の限定によって悪用を困難にする一時的な措置です。NIST（National Institute of Standards and Technology）は、[機能の停止や他の資産からの隔離を、緩和の手段として列挙しています](https://doi.org/10.6028/NIST.SP.800-40r4)。提供元が回避策を公開していれば、業務への影響を確認したうえで、自社でまずそれを適用します。

機器を停止すると、その機器を経由する業務も停止します。例えばVPN機器なら在宅勤務や拠点からの接続が停止するため、停止を決定した組織の側で、代替の接続手段の用意と利用者への連絡が必要です。

### インターネットへの露出を削減する

どの製品でゼロデイが発見されるかは事前に予測しにくいため、攻撃者が到達できる箇所を平時に削減しておきます。CISAは、[インターネットから到達できる資産を把握し、不要な接続口を閉鎖し、必要な接続口を保護する](https://www.cisa.gov/resources-tools/resources/exposure-reduction)よう推奨しています。管理画面への接続を社内からに限定する措置が該当します。

### ログを機器の外に保存して異常を検知する

エッジ機器のログを機器の外に保存し、通常と異なる時間帯の接続や管理者アカウントの不審な操作を検知できるようにします。Ivanti製品の別の脆弱性CVE-2025-22457では、JPCERT/CCが[ログ出力の停止や外部サーバーへのログ転送の停止を、攻撃の痕跡である可能性が高い事象として列挙しています](https://www.jpcert.or.jp/at/2025/at250008.html)。ログが機器の中にしかないと、攻撃者にログを消去されたりログ出力を停止されたりした場合に、被害の有無を確認する主要な手がかりが消失します。

### 提供元の脆弱性情報の更新が終了するまで確認する

情報は公表後も更新されます。CVE-2025-22457は2025年4月に公表され、[2月の修正時点では製品の不具合と判定され、再評価で、外部から機器を任意に操作できるリモートコード実行につながる可能性があると判明しました](https://www.jpcert.or.jp/at/2025/at250008.html)。提供元の告知、JPCERT/CCの注意喚起、[IPA（独立行政法人情報処理推進機構）の重要なセキュリティ情報](https://www.ipa.go.jp/security/announce/alert.html)は、パッチの適用後も、その脆弱性の情報の更新が終了するまで確認します。

![露出の削減は機器の手前、緩和は機器、ログの転送は機器の外で機能し、提供元の情報の確認は担当者が別に実施します](https://media.marketing.kdotdev-tunnel.org/glossary-zero-day-5cbc735d345d957fa1c549626d250c5a458fd901e50684275e2f99137dbd09ad.png)

## ゼロデイ攻撃に備えて平時に整備する一覧と体制

- 公開機器の一覧: 製品名、版、インターネットから到達できる範囲（管理画面を含む）、ログの転送先、確認の担当者を記載する
- 情報の確認: 担当者が週に1回、KEVカタログとJPCERT/CCの注意喚起に、公開機器の一覧に記載した製品が載っていないかを確認する。報道があればその日に確認する。SBOMに記載したライブラリは、開発の担当者が脆弱性のデータベースや依存関係を調べるツールで確認する
- 停止の判断: 機器の停止の可否は、その機器を利用する業務の責任者が決定する。代替の接続手段と利用者への連絡方法も用意しておく
- 夜間と休日: 当日中に停止の可否を判断できる体制がなければ、自社から提供元の保守窓口か外部の監視サービスに依頼し、連絡と一次対応の範囲を双方で合意しておく

![平時の準備を担当者と業務の責任者と夜間休日の一次対応先の3者で分担します](https://media.marketing.kdotdev-tunnel.org/glossary-zero-day-ec08ea531e0f9ba8401f88057d7b888267cfb955705121910642418d1975700b.png)

いずれも、従業員数十人から数百人で、情報システムの担当者が他の業務と兼任している組織を想定した経験上の目安で、機器の台数と停止できる時間によって異なります。

## パッチ公開後の侵害調査

パッチは脆弱性を修正するだけで、公開前に侵入した攻撃者や、攻撃者が設置したマルウェアなどの不正なプログラムを除去しません。[公表前から悪用が発生していることがある](https://www.jpcert.or.jp/at/2025/at250001.html)ため、パッチの適用と併せて、侵害の有無の調査を実施します。

JPCERT/CCはCVE-2025-0282について[対策の実施とともに侵害の有無を確認する調査を推奨しています](https://www.jpcert.or.jp/at/2025/at250001.html)。

改ざんを確認する提供元のツールも、攻撃者が手を加えると侵害を正しく示さないことがあります。例えばIvanti製品では、そのツールの[出力結果が攻撃者に改ざんされ、侵害されていても正常終了と表示されたことがあります](https://www.jpcert.or.jp/at/2025/at250008.html)。ツールの結果だけで安全と判断せず、機器の外に保存したログに不審な接続や操作がないかも確認します。

調査後も侵害の可能性を否定できなければ、機器に不正なプログラムが残存し、保存されていた認証情報も攻撃者に取得されているおそれがあります。CISAはCVE-2025-22457について、[機器の初期化と、証明書、鍵、パスワードの失効と再発行](https://www.cisa.gov/cisa-mitigation-instructions-cve-2025-22457)を示しています。そのため機器の初期化や再構築、認証情報の再発行が必要になることがあり、外部の専門家に調査を依頼すればその費用も発生します。

![パッチの適用後も改ざん確認ツールと機器の外のログで侵害の有無を確認します](https://media.marketing.kdotdev-tunnel.org/glossary-zero-day-a0aa320100e9cac5afd1d8917423a02b7318e50db8e31eeb3373672f3b6a7047.png)

なお、サポートが終了した製品には、そもそも[パッチが提供されません](https://doi.org/10.6028/NIST.SP.800-40r4)。JPCERT/CCは、[Ivanti製品のサポートが終了したバージョンの利用者に、停止と移行、移行後のネットワーク隔離を速やかに計画するよう求めています](https://www.jpcert.or.jp/at/2025/at250008.html)。

## 自社が対象と判明したときの対応の重さと期限の目安

自社が対象と判明したときの対応を、露出と悪用の状況で区分します。

| 状況 | パッチの公開前 | パッチの公開後 |
|---|---|---|
| インターネットから到達でき、ログイン不要か悪用が確認されている | 当日中に緩和か機能の停止を判断 | 数日以内に適用し、侵害の有無を調査 |
| インターネットから到達できるが、悪用は未確認でログインが必要 | 数日以内に回避策を適用し、ログの監視を強化 | 1週間程度で適用 |
| 社内からだけ到達できる | 数日以内に接続できる範囲を確認 | 数週間以内に適用 |
| 利用していない | 対象外 | なし |
| 自動更新で修正済み | 全台への適用を確認 | 悪用が確認されていれば、更新前の不審な動作の有無も確認 |

この表の期限は経験上の目安です。悪用が確認されたエッジ機器は公表の時点で侵入済みの可能性があるため、最も短くしています。社内からだけ到達できる機器も、上の表の対象から除外しません。VPN機器などのエッジ機器が侵害されると、多くの構成では攻撃者がその機器を経由して社内ネットワークに侵入し、社内の機器にも到達できるためです。

![露出と悪用の状況が重いほどパッチの公開前と公開後の対応の期限が短くなります](https://media.marketing.kdotdev-tunnel.org/glossary-zero-day-9a4f42479b237196689ec2d1057ceacda39efc0b16ac4458176aee948b28af7b.png)

## よくある誤解

### 脆弱性の公表後の攻撃はゼロデイ攻撃ではない

NISTの用語集は[未知の脆弱性を悪用する攻撃](https://csrc.nist.gov/glossary/term/zero_day_attack)と定義していますが、[GTIGの集計](https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review)は公表後でもパッチの公開前の悪用をゼロデイに含めます。公表とパッチの提供は同時とは限らないため、公表の時点で利用している製品と版ごとにパッチの有無を確認します。

### ゼロデイ攻撃は国家規模の攻撃者に限られ一般企業には関係ない

2025年には[金銭目的とみられる攻撃者によるゼロデイの悪用も9件あり、そのうち2件はランサムウェアの展開に発展しました](https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review)。VPN機器のように多くの組織が同じ製品を利用する機器では、1つの脆弱性で多数の組織を同時に攻撃できるため、企業の規模に関係なく標的になるおそれがあります。

公開機器の一覧とログの外部転送は、ゼロデイが報道されたその日に自社への影響と被害の有無を判定できるよう、平時に整備します。報道のたびに業務を停止せず、利用している製品の露出の有無で対応の重さを区分します。