脆弱性を検証するのに、エクスプロイトを実行する必要はない

脆弱性管理の前提となってきたタイムラインは、静かに姿を消しました。これまで数十年間、防御側は脆弱性が公開されてから実際に攻撃として悪用されるまでに、数週間から数か月の猶予があると見込んでいました。

その猶予は、2つの要因によって一気に失われました。

1つ目は単純な件数の急増です。新たな脆弱性はかつてないペースで積み上がっており、2026年上半期だけで、2024年以前のどの年間合計をも上回るCVEが公表されました。これは驚くべきことに、約7.4分に1件という頻度に相当します。

2つ目は速度です。AIによって、残されていた猶予も瞬く間に消え去りました。これは先日の記事でも触れた通りです。今日では、注意喚起情報を実際に動作するエクスプロイトに変えるのに、熟練した根気強い作業はもはや必要ありません。数万件のCVEにわたって悪用までの所要時間を追跡している「Zero Day Clock」によると、2026年の中央値は1日を大きく下回っており、わずか数年前には数週間かかっていたのとは対照的です。

セキュリティチームにとって残念なことに、防御側の対応はそれほどのスピードで進化しておらず、文字通り毎分増え続ける未対応案件の山をパッチだけで解消できるチームは存在しません。しかし、件数の急増は問題の一部に過ぎません。実際に野放しの攻撃へと発展したCVEは、そのうちのごくわずか、1%にも満たない割合にとどまっているのです。

その結果生まれるのが、攻撃者が自由に行動できる一方で防御側には手の打ちようがない、拡大し続ける時間の空白です。これをさらに悪化させているのが「証明」の問題です。すなわち、実際に自分たちに対して悪用され得るごく一握りの脅威を、決して悪用されることのない数万件の脅威から選り分けるという課題です。

リスクは、攻撃を仕掛けられない場所に潜んでいる

ペネトレーションテストを四半期に一度ではなく継続的に実施すれば、この空白は確かに狭まります。しかし、それには超えられない限界があります。自動化されたペネトレーションテストツールが使う実際のエクスプロイトは、安全に実行できる場所、かつ使用可能なエクスプロイトが既に存在する場所でしか実行できません。ほとんどの企業では、これは実際の攻撃対象領域のわずか10~15%をカバーするに過ぎません。

残りの部分は、従来の自動ペネトレーションテストツールでは検証されないままになります。公開エクスプロイトが存在しない脆弱性、実際の攻撃に耐えられないほど機微な規制対象システムや隔離環境、そして防御側のツールがまだ追いついていないうちに攻撃者がすでに悪用し始めている、公開されたばかりのバグなどです。

しかし、悪用可能性を証明するのに、公開エクスプロイトや、リスクを冒せないほど重要なシステムへの実弾攻撃は必要ありません。物理的な鎖であれ仮想的な鎖であれ、鎖の強さは最も弱い環で決まります。そして、どの環が壊れるかを知るために、鎖全体に負荷をかける必要はないのです。Picus Platformは、エクスプロイトの有無にかかわらず、いずれの方法でも悪用可能性を証明します。

このカバレッジの隙間こそ、CISO(最高情報セキュリティ責任者)たちがパッチ適用の速度から検証(バリデーション)へと予算配分をシフトしている理由です。最新のガイドでは、取締役会に説明できる数字とともに、その全体像を解説しています。下記からダウンロードできます。

証明すべきは「連鎖」であって「エクスプロイト」ではない

ここからが、この構図を正当な形で立て直す部分です。エクスプロイトが自分たちに対して有効かどうかは、実際に引き金を引かなくても証明できます。

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

脆弱性を、その悪用が依存するステップに対応付け、実際に導入している防御機構に対して各ステップを検証します。必要なステップのいずれかに、既存の制御機構を突破する現実的な経路がなければ、連鎖は成立せず、脆弱性自体は存在していてもそのアセットに対するエクスプロイトは失敗に終わります。逆もまた真です。必要なすべてのステップが成功するのであれば、その脆弱性は実際に悪用可能であり、勘ではなく証拠に基づいてその判断を裏付けることができます。

これはロケット工学の論理と同じです。エンジニアは、打ち上げを試みる前に、エンジン、燃料系統、耐熱シールドを一つひとつ個別に検証します。そして、重要な部品が試験に失敗すれば、実際に打ち上げのリスクを冒すことなく、その機体が飛べないと分かるのです。

実例で見る:Nightmare-Eclipse

公開されたばかりのバグをめぐる事例は、一人の人物がWindowsのゼロデイ脆弱性を次々と公開し、それを犯罪者のエコシステムが取り込んだ瞬間に、一気に現実味を帯びます。これはまさにNightmare-Eclipseで起きたことです。エクスプロイトコードは1週間以内にGitHub上で公開されましたが、実際にそのマルウェアを自社のドメインコントローラーに対して実行し、悪用が成功するかどうかを確かめるようなテストは、誰も引き受けるべきではありません。

この一連の経緯を振り返ることは、パッチ適用の優先順位を決める上で、エクスプロイトを実際に発射するのではなく連鎖を証明するというアプローチがいかに効果的かを示す、最も分かりやすい例です。

Nightmare-Eclipse(別名Chaotic Eclipse、Dead Eclipse)は、ランサムウェア集団でも国家支援型のグループでもありません。判明している限りの証拠から見る限り、Windows内部構造に精通し、Microsoftに個人的な恨みを抱く1人のセキュリティ研究者による犯行です。

2026年4月上旬から、この人物は一連のWindowsゼロデイエクスプロイトを、統一されたスケジュールのないバラバラの形で公開してきました。ほとんどの場合、CVE番号も公開時点でのパッチも存在していません。

このうち3件の公開情報は組み合わさることで、権限昇格とセキュリティ機能の無効化を一体として実現する、単独で完結する攻撃手順を構成します。

• BlueHammer: 権限のあるファイル読み取りを通じたローカル権限昇格で、Windows Defenderのレースコンディションを悪用します。EICARのおとりファイルによってDefenderを修復ワークフローへと誘導し、ボリュームシャドウコピーのスナップショットを作成させることで、SAM・SYSTEM・SECURITYの各ハイブを一時的に露出させます。BlueHammerはCloud Filesのコールバックと日和見ロックを利用してこのレースに勝利し、ハイブを読み取ってローカルのNTLMハッシュをダンプし、SYSTEM権限へと昇格します。

• RedSun: BlueHammerと同じプリミティブを反転させ、権限のあるファイル書き込みとして利用します。SAMハイブを読み取る代わりに、RedSunはSYSTEM権限での書き込みをC:\Windows\System32へとリダイレクトし、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. ボリュームシャドウコピー経由でのSAMハイブのダンプ(認証情報アクセス)。 これがBlueHammerの中核となるプリミティブです。ロックされた稼働中のレジストリに直接触れる代わりに、攻撃者はDefenderが作成したシャドウコピーからSAM・SYSTEM・SECURITYの各ハイブを読み取り、オフラインでNTLMハッシュを復号します。エミュレートされたアクションは、このVSSを利用したハイブアクセスを再現します。これは、認証情報窃取対策の制御機構がまさに検知すべき挙動です。

3. Windows Defenderサービスの無効化(防御回避)。 実際の攻撃連鎖では、UnDefendがDefenderの更新をブロックし、シグネチャベースの再読み込みを阻止する一方、コンソールには欺瞞的に正常なステータスを報告します。Picusはこのステップを検証するのに、そのマルウェア自体を必要としません。Threat LibraryのアクションであるunDefenderを用いてこの手法をエミュレートし、Windows Defenderサービスを安全に停止させることで、どのツールによる回避であっても、改ざん防止機能が持ちこたえるかどうかを検証します。

これらのステップを実際の制御機構に対して順番に実行することで、SYSTEM権限の取得、認証情報の窃取、そしてDefenderの無効化という連鎖全体が、自社の環境で実際に成功するのか、それとも防御機構のいずれかが最初にそれを阻止するのかが分かります。

このアプローチにより、実際に連鎖が成立し得る箇所を優先してパッチ適用や堅牢化を行うことができ、しかも一度もエクスプロイトを発射することなくその判断に至れます。これは、実際にテストできないシステムについても同様です。私たちのTTPチェーンに関する2ページ資料では、CVE番号から根拠のある判断に至るまでのこの手順を、別の実例とともに詳しく解説しています。下記からダウンロードできます。

攻撃対象領域全体をカバーし、証明し続ける

実エクスプロイトによる検証とTTPチェーンは、決して競合する手法ではありません。両者は補完し合う関係にあります。

最も優れたプログラムは、この両方を実施し、環境が変化するたびに繰り返します。先月連鎖を阻止していた制御機構が、次の構成変更後も同じように機能するとは限らないからです。悪用可能性とは、一度きりのチェック項目ではなく、継続的に問い続けるべき問いなのです。

これこそ、Picusが埋めるループです。エクスプロイトが存在し、それを発射しても安全な場合には、Autonomous Pentestingが実際の攻撃連鎖を実行し、最も強力な証拠を提供します。それが難しい場合、すなわち制限された環境、隔離環境、事業上重要なアセット、あるいはまだ武器化されていない今朝公開されたばかりのCVEについては、TTPチェーンが推論によって悪用可能性を証明します。

その後、Breach and Attack Simulationがあらゆる判定結果を再検証するため、前四半期に「許容」と判断したものが、今四半期に気づかぬうちに侵害へと変わることはありません。

その結果得られるのは、単一のプラットフォームによる、オンデマンドの一つの答えです。「ここで今、実際に悪用可能なものは何か?」

未対応案件の山の中に、今もまだ残っている案件を思い浮かべてください。パッチがまだ存在しないNightmare-Eclipseの次の公開情報、決して実弾を撃ち込むことのない隔離環境、そして数時間前に届いたばかりの注意喚起情報などです。

デモを予約し、Picusが実際のエクスプロイトとTTPチェーンを使って自社固有の環境をテストする様子をご覧ください。