脆弱性があるかどうかを確認するために、エクスプロイトを実行する必要はありません

脆弱性管理の基盤となっていたタイムラインは、いつの間にか消え去ってしまった。何十年もの間、防御側は、脆弱性が公表されてから、実際にそれを攻撃に利用されるまでの間に数週間から数ヶ月の猶予があることを当てにできていた。

2つの要因が、そのタイムラグを一気に縮めてしまった。

第一に、その膨大な量です。新たな脆弱性はかつてない速さで蓄積されており、2026年上半期だけで、2024年以前のどの1年間よりも多くのCVEが記録され、およそ7.4分に1件という驚くべきペースで発生しています。 

二つ目はスピードだ。先日の記事でも触れたように、AIは残っていた余裕を瞬く間に消し去ってしまった。 今日では、セキュリティアドバイザリを実用的なエクスプロイトに変えるのに、熟練した技術や根気強い努力はもはや必要とされません。数万件のCVEを対象にエクスプロイト化までの時間を追跡する「ゼロデイ・クロック」によると、2026年のエクスプロイト化までの中央値は1日を大幅に下回っており、わずか数年前の数週間という水準から大幅に短縮されています。

セキュリティチームにとって残念なことに、防御策の進化はそのスピードにはほど遠く、文字通り分単位で増え続ける未修正の脆弱性のバックログを、パッチ適用だけで解消できるチームは存在しません。しかし、件数の多さは問題の一部に過ぎませんでした。それらのCVEのうち、実際に実環境で攻撃に利用されたのはわずか数パーセントに過ぎなかったのです。

その結果、攻撃者が自由に行動し、防御側がそれを阻止できないまま放置される期間がますます長くなっている。この問題をさらに深刻にしているのは、実際に被害をもたらす可能性のあるごく少数の脅威と、決して被害をもたらさない数万もの脅威とを区別する「証拠」の有無である。

リスクは、攻撃できない場所に潜んでいる 

四半期に1回ではなく継続的にペネトレーションテストを実施すれば、その期間は確かに短縮されますが、そこには明確な限界があります。自動化されたペネトレーションテストツールによって使用される実稼働中のエクスプロイトは、安全に実行できる場所、かつ利用可能なエクスプロイトがすでに存在する場所でのみ実行可能です。ほとんどの企業において、これは実際の攻撃対象領域のわずか10～15％しかカバーしていません。 

しかし、従来の自動化ペネトレーションテストツールでは、残りの部分は検証されません。公開されているエクスプロイトがない脆弱性、実際の攻撃に耐えられないほど機密性が高く規制対象やエアギャップが施されたシステム、そして防御ツールが追いつく前に攻撃者がすでに悪用し始めている、新たに公開されたばかりのバグなどがそれにあたります。

しかし、悪用可能性を検証するために、公開済みのエクスプロイトや、リスクを冒すには重要すぎるシステムへの実機攻撃は必要ありません。物理環境であれ仮想環境であれ、チェーンの強度は最も弱いリンクによって決まります。どのリンクが破綻するかを確認するために、チェーン全体をロードする必要はありません。Picus Platformは、エクスプロイトの有無にかかわらず、いずれの場合でも悪用可能性を検証します。

この検証のギャップこそが、CISOたちが予算を「パッチ適用速度」から「検証」へとシフトさせている理由であり、当社の最新ガイドでは、取締役会に対してこれを説得するための具体的な数値データとともに、その根拠を詳細に解説しています。以下のリンクからガイドを入手してください。

エクスプロイトではなく、チェーンを検証せよ

ここで、状況のバランスを真に是正し始めるポイントがあります。実際にエクスプロイトを実行することなく、それが自社に対して有効かどうかを証明できるのです。

あらゆるエクスプロイトは、相互に依存する一連のステップで構成されています。初期実行、防御回避、権限昇格、認証情報の窃取、横方向の移動などです。攻撃者は、必要な各ステップを成功させる必要がありますが、ステップが成功するのは、あなたの環境がそれを許容する場合に限られます。

脆弱性を、その悪用に依存する各ステップに紐付け、実際に展開している防御策に対してそれぞれをテストします。必要なステップが、あなたの防御策を突破する実行可能な経路を持たない場合、攻撃チェーンは完了できず、たとえ脆弱性が依然として存在していても、その資産に対するエクスプロイトは失敗します。 その逆もまた真です。必要な各ステップがすべて成功する場合、その脆弱性は実際に悪用可能であり、その判断は単なる推測ではなく、証拠に基づいて裏付けることができます。

これはロケット工学の論理と同じです。エンジニアは、打ち上げを試みる前に、エンジン、燃料システム、熱シールドを一つずつ検証します。そして、重要なコンポーネントのテストに失敗すれば、打ち上げのリスクを負うことなく、その機体が飛行できないことを把握できるのです。

実例：Nightmare-Eclipse

新たに公開された脆弱性の事例は、たった1人がWindowsのゼロデイ攻撃コードを公開し、犯罪者コミュニティがそれを拾い上げた瞬間に、具体的な脅威となります。 Nightmare-Eclipseではまさにそのような事態が発生しました。エクスプロイトコードは1週間以内にGitHub上で公開されましたが、実際にマルウェアを自社のドメインコントローラーに対して実行し、侵入が可能かどうかを確認するようなテストに、誰も進んで参加しようとはしないでしょう。

この具体的なタイムラインを振り返ることで、「攻撃を実行するのではなく、攻撃の連鎖を立証すること」が、どのパッチを優先すべきかを判断する上でなぜこれほど効果的な方法であるかが、最も明確に示されます。

Nightmare-Eclipse（別名：Chaotic Eclipse、Dead Eclipse）は、ランサムウェア集団でも国家支援グループでもありません。入手可能なあらゆる証拠から判断すると、これはWindowsの内部構造に精通しており、マイクロソフトに対して個人的な恨みを抱く、ある1人のセキュリティ研究者によるものです。 

2026年4月初旬から、この攻撃者は一連のWindowsゼロデイエクスプロイトを、調整されていない形で公開し始めました。これらは統一されたタイムラインがなく、ほとんどの場合、公開時にCVE番号もパッチも存在しませんでした。 

公開されたもののうち3つは、単一の独立した「権限昇格およびシステム盲目化」プレイブックとして組み合わさっている。

• BlueHammer： Windows Defenderのレースコンディションを悪用し、特権ファイルの読み取りを通じてローカル 特権昇格を行う。EICARベイトファイルがDefenderを修復ワークフローに誘導し、ボリュームシャドウコピーのスナップショットが生成されることで、SAM、SYSTEM、SECURITYハイブが一時的に露出する。 BlueHammerは、Cloud Filesのコールバックと機会を捉えたロックを利用してそのレースコンディションに勝利し、ハイブを読み取り、ローカルのNTLMハッシュをダンプし、SYSTEM権限へ昇格します。

• RedSun： 同じプリミティブセットを 、特権ファイル書き込みに転用したものです。SAMハイブを読み取る代わりに、RedSunはSYSTEMレベルの書き込みをC:WindowsSystem32にリダイレクトし、TieringEngineService.exeを攻撃者のバイナリで上書きした後、Storage Tiers Management COMオブジェクトをトリガーして、SYSTEM権限でそれを実行させます。

• UnDefend：Defenderを 無力化するツールです 。Defenderのシグネチャファイル（mpavbase.vdm、mpavbase.lkg）をロックし、定義ファイルの更新をブロックし、サービスの再起動時にシグネチャベースが再読み込みされるのを阻止します。その一方で、EDRコンソールには正常かつ最新のステータスが報告されます。 

これらを組み合わせて実行すると、特権の障壁がなくなり、自身の健全性について虚偽の情報を報告するセキュリティスタックを持つマシンが完成します。 

動作の再現：TTPチェーンの構築

侵入を安全なテストに変えるには、各攻撃者の行動を、実際のエキスプロイトを実行することなく、Picusが実行および測定できる個別のアクションに変換する必要があります。

このチェーンはいくつかのアクションで構成されていますが、その大部分を担うのは以下の3つです：

1. 新しいサービス「Evilsvc」を作成する（実行）。BlueHammerによる権限昇格は、 CreateServiceを使用して一時的な Windows サービスを登録し、ペイロードを SYSTEM 権限で実行させることで完了します。エミュレートされたアクションでは、悪意のあるものを起動することなく、その最終的な実行ステップの代わりとなる無害なテストサービスをインストールします。

2. ボリュームシャドウコピー（VSS）を介してSAMハイブをダンプする（資格情報へのアクセス）。これがBlueHammerの中核となるプリミティブです。攻撃者は、稼働中でロックされたレジストリに直接アクセスする代わりに、Defenderによって作成されたシャドウコピーからSAM、SYSTEM、SECURITYの各ハイブを読み取り、オフラインでNTLMハッシュを復号します。 このエミュレートされたアクションは、VSS ベースのハイブアクセスを再現しており、まさに資格情報窃取対策が検知すべき動作そのものです。

3. Windows Defender サービスを無効化（防御回避）。実際の攻撃チェーンでは、UnDefend は Defender の更新をブロックし、シグネチャベースの再読み込みを阻止しますが、その間もコンソールには正常な状態であると偽って報告し続けます。 Picusはこのステップを検証するためにそのマルウェアを必要としません。Windows Defenderサービスを安全に停止させるThreat Libraryアクション「unDefender」を使用してこの手法をエミュレートし、どのツールが回避を試みても、改ざん防止機能が機能するかどうかをテストします。

実稼働環境の制御対象に対してこれらの手順を順次実行することで、完全な攻撃チェーン（SYSTEM権限へのアクセス、認証情報の窃取、および無効化されたDefender）が実際に環境で成功するか、あるいは防御策のいずれかが先にこれを阻止するかが判明します。

これにより、実際に攻撃チェーンが完結し、その判断に至るところを優先的にパッチ適用や強化の対象とすることができ、実環境でテストできないシステムであっても、エクスプロイトを1つも実行することなくその判断を下すことができます。当社のTTPチェーンに関する2ページの資料では、CVE IDから防御可能な判断に至るまで、このプロセスをステップバイステップで解説しており、2つ目の実例も掲載されています。以下のリンクから資料を入手してください。

攻撃対象領域全体を網羅し、その有効性を証明し続ける 

実環境でのエクスプロイトとTTPチェーンは、決して競合する手法ではなく、互いに相補的に機能します。

最も堅牢なプログラムでは、この両方を実行し、環境が変化するたびに再実行します。なぜなら、先月チェーンを断ち切った制御措置が、次の構成変更を乗り切れない可能性があるからです。エクスプロイト可能性は、一度チェックボックスにチェックを入れるだけで済むものではなく、継続的に問いかけ続けるべき問題なのです。

これが、Picusが閉じるループです。エクスプロイトが存在し、その実行が安全である場合、自律型ペネトレーションテストは実際のチェーンを起動させ、入手可能な最も強力な証拠を提示します。 それが不可能な場合、つまり制限された資産、エアギャップが施された資産、ビジネス上重要な資産、あるいは今朝公開されたばかりでまだ武器化されていないCVEに対しては、TTPチェーン分析が推論によってエクスプロイト可能性を証明します。

その後、侵害・攻撃シミュレーションがすべての判定結果を再確認するため、前四半期の「許容」が、今四半期の侵害へと密かに変化することは決してありません。

その結果、単一のプラットフォームから、オンデマンドで「今、ここで実際に何が悪用可能か？」という答えが得られます。 

まだバックログに残っているケースを考えてみてください。まだパッチが適用されていない次回の「Nightmare-Eclipse」リリース、攻撃対象にすることのないエアギャップ環境、数時間前に公開されたアドバイザリなどです。

デモをご予約いただき、Picusがお客様の独自の環境に対して、実際のエクスプロイトやTTPチェーンを用いてテストを行う様子をご覧ください。

Picus Softwareによる提供・執筆。