## 1 はじめに この記事では、多くのWindowsカーネルモードドライバが、開発されたハードウェアなしでユーザーモードからどのように操作できるかについての技術的な分析を提供します。この作業は、ドライバ指向の脆弱性研究と、個々の発見の悪用可能性を評価する必要性によって動機付けられました。これらの発見は、しばしばハードウェアによって到達可能性が制限されるコードに影響を与えます。ここで提示される方法論は、特定のWindowsカーネルモードドライバの脆弱性が、ドライバが開発されたハードウェアが存在しない場合でも、到達可能であり、したがって潜在的に悪用可能かどうかを判断するのに役立つはずです。 読者は、特にデバイスオブジェクトに関する基本的なWindowsドライバの知識を持っていることを前提としています。この記事の残りは、読者がすでに導入記事で説明されている概念に精通していることを前提として書かれています：[Anatomy of Access: Windows Device Objects from a Security Perspective](https://atos.net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective)。 導入記事と同様に、このリソースは特定のバグクラスに焦点を当てるのではなく、攻撃対象領域、そしてある程度はWindows Plug and Playアーキテクチャに焦点を当てています。 ここで実証されるすべてのテストは、**Windows 11 23H2** (winver 10.0.22631.3007) で実施されました。 >このような最新の脅威研究や脆弱性アドバイザリについては、[**Atos Cyber Shield** blogs](https://atos.net/en/lp/cybershield#subscription-form) を購読してください。 ## 2 カーネルモードドライバの攻撃的価値 明白なローカル権限昇格の可能性に加えて、脆弱なドライバはBYOVD攻撃でしばしば悪用されます。これは、攻撃者がEDRコンポーネントなどのシステム防御を妨害するために利用する、ポストエクスプロイテーション技術です。 ドライバの脆弱性がBYOVD攻撃の有力な候補となるかどうかを決定する主な基準は2つあります。 1. エクスプロイトが、改ざん耐性の高いセキュリティコンポーネントに意味のある破壊をもたらすこと。例としては、任意のメモリ読み書きアクセス、任意のコード実行、または任意のリソースの乱用（例：ファイルのオーバーライト、ハンドルのクローズ、プロセスの終了）を許可するカーネルレベルの脆弱性が挙げられます。 2. そのエクスプロイト可能性が、特定のハードウェアの存在のような稀なシステム条件に依存しないこと。 BYOVDスタイルの攻撃は何年にもわたって十分に文書化されており、このトピックに関する多数の公開レポートや研究論文（例：[https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf)、[https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/](https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/)、[https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants](https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants)) がありますが、ドライバの脆弱性の到達可能性におけるハードウェアゲーティングの役割を具体的に調査したものは none です。 ## 3 デバイスオブジェクトの作成と保守 - 一般的なパターン このリソースで提供される分析は、デバイスオブジェクトが最も実行可能な攻撃ベクトルであるため、デバイスオブジェクトを中心に構成されています。しかし、ここで実証される技術は、IRPを介してだけでなく、一般的にユーザーランドからのドライバコードの到達可能性に実質的に影響を与えます。 デバイスオブジェクトを介してドライバを攻撃する際の最も一般的な障害は次のとおりです。 1. デバイスオブジェクトが作成されない。 2. デバイスオブジェクトにアクセス可能であっても、ドライバの内部状態が脆弱な動作の実行を許可しない。 これらのシナリオはどちらも、対応する物理ハードウェアなしでシステムに展開されたデバイスドライバを扱う場合に非常に一般的です。 記事の残りの部分では、[デバイススタックとデバイスノード](https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/device-nodes-and-device-stacks)についてしばしば言及します。デバイススタックについては、[導入記事](https://atos.net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective)でかなり広くカバーしました。デバイスノードとデバイススタックは同じものではありませんが、すべてのデバイスノードが正確に1つのデバイススタックを持つため、これらの用語はしばしば互換的に使用されます。 ### 3.1 ドライバロード時の無条件作成 多くのドライバ、特に非PnPドライバは、`DriverEntry`関数内から直接、または`DriverEntry`から始まる直接呼び出しチェーンで呼び出される他の関数からデバイスオブジェクトを作成します。 [**Multidev_WDM demo driver**](https://github.com/Atos-TRC/Atos-TRC-public-samples-and-code/windows-kernel-mode/kernel/multidev_WDM/) はこのパターンを例示しています。`DriverEntry`でデバイス作成がすぐに呼び出されていることがわかります。  `DriverEntry`から直接呼び出されるCDO作成 ドライバは、ドライバがアンロードされる（ドライバがアンロードされている）ときに呼び出される`DriverUnload`から`IoDeleteDevice`を呼び出すことでデバイスオブジェクトを削除しますが、これは`DriverUnload`が呼び出されたときにのみ発生します。  `DriverUnload`からのCDOクリーンアップ このように構築されたドライバは、次の2つのステップのみで構成される簡単なデプロイメント後に操作できます。 1. ドライバのサービスエントリを作成します。 sc.exe create SampleDrv type= kernel start= demand binPath= System32\drivers\SampleDrv.sys * サービス（ドライバがロードされる）を開始します。 sc.exe start SampleDrv [https://loldrivers.io/](https://loldrivers.io/) からランダムに選択されたドライバを見ると、そのデプロイメントコマンドがこのパターンに一致していることがわかります。  LOLドライバ - zam64.sys デプロイメント しかし、ほとんどのデバイスドライバは、この記事の次のセクションで見るように、このカテゴリには該当しません。 ### 3.2 条件付きデバイス作成と保守 多くの場合、ドライバの初期化ルーチンは追加のチェックを実行します。例えば、セキュリティソフトウェアのカーネルモードコンポーネント（**EDR**、アンチウイルス、監視、強化認証など）は、通常の製品デプロイメント中に作成および初期化される製品固有のレジストリキーとエントリをチェックする傾向があります。 実際のデバイスドライバ（物理ハードウェアを駆動するために作成されたもの）は、そのハードウェアが存在する場合にのみデバイスオブジェクトを作成する傾向があります。それがない場合、ドライバは次のいずれかを行います。 * デバイスオブジェクトをまったく作成しようとしない。 * `IoDeleteDevice`を呼び出すことで、作成後すぐにデバイスオブジェクトを削除する。 このロジックがどのように実装されているかに焦点を当て、特にBYOVDの観点から、ユーザーランドからのみ操作すること（物理/ハイパーバイザーアクセスなし）で、それを評価し、どのように回避できるかを見てみましょう。 ちなみに、デバイスオブジェクトが最初に作成され、その後すぐに削除される2番目のシナリオは、デバイスオブジェクトが存在する短い時間枠があるため、競合状態と見なすことができる状況を作成します。 ### 3.3 PnPコールバックはPnPドライバ初期化ロジックの主な場所 PnP互換ドライバ（デバイスの大部分を構成する）では、