署名済みの脆弱なドライバでEDRを止めるBYOVD攻撃の仕組みと対策

BYOVD(Bring Your Own Vulnerable Driver)は、正規の証明書で署名されているものの脆弱性を抱えたカーネルドライバを、攻撃者が侵入先の端末へ持ち込んで読み込ませる手口です。カーネルで動くドライバの機能を足がかりにして、EDRやウイルス対策ソフトを停止させたり、カーネル権限でコードを実行したりします。近年のランサムウェア攻撃では、暗号化の直前に防御製品を無効化する段階で繰り返し使われています。対象読者は、Windows端末の管理やSOCでエンドポイント防御にあたる実務担当者です。記述はMITRE ATT&CKとMicrosoft公式ドキュメント、CISAのアドバイザリ、Cisco TalosとESET、Check Point Researchの調査報告にもとづき、事実は執筆時点(2026年9月26日)で確認できた範囲に限ります。攻撃の再現手順や悪用コードは扱いません。ドライバの挙動や検知ルールの動作確認は、自組織が管理する、または管理者から明確な許可を得た検証環境でのみ行ってください。許可のない端末で脆弱なドライバを読み込ませたり防御製品を停止させたりする行為は、不正アクセス禁止法や不正指令電磁的記録に関する罪など関連法令に抵触するおそれがあります。

カーネルドライバが狙われる理由#

Windowsのカーネルドライバは、OSの中核と同じ最高権限のモードで動きます。EDRやウイルス対策ソフトも自社のドライバをカーネルに置き、プロセスの生成やファイル操作を監視しています。ユーザーモードで動くマルウェアは、管理者権限を得ても、カーネル側で動く防御製品を正面から止めることは難しい設計になっています。そこで攻撃者は、自分もカーネル側の足場を得ようとします。

ところが、自作の不正なドライバをそのまま読み込ませることは簡単ではありません。Microsoftのドライバ署名ポリシーによれば、Windows 10 バージョン1607以降は、Microsoftのハードウェア開発者向けポータルで署名されていない新しいカーネルモードドライバを読み込まない仕組みになっています。一方で、2015年7月29日より前に発行された証明書で署名された旧来の相互署名ドライバなど、互換性のために読み込みが許される例外も残されています。

Microsoft Learnのドライバ署名ポリシーは、Windows 10 バージョン1607以降はポータルで署名されていない新規のカーネルモードドライバを読み込まないとしたうえで、以前のバージョンからのアップグレード環境、Secure Bootが無効な環境、2015年7月29日より前に発行された証明書による署名の場合には、相互署名ドライバが引き続き許可されると説明しています。

この結果、攻撃者にとっては「自分で署名を得る」よりも「すでに正規の署名を持ち、しかも脆弱なドライバを探して持ち込む」ほうが現実的な選択肢になります。これがBYOVDの出発点です。

BYOVDが成立する仕組み#

BYOVDで悪用されるドライバの多くは、ハードウェアの制御ツールやシステムユーティリティ、セキュリティ製品などが本来の目的で配布しているものです。問題になるのは、ドライバがユーザーモードのプログラムから命令を受け取る窓口を備え、その窓口に呼び出し元の検証が欠けている場合です。たとえば任意のプロセスを終了させる機能や、カーネルメモリを読み書きする機能を、誰からの要求でも実行してしまうドライバが該当します。

攻撃者は管理者権限を得た端末へこのドライバを置き、サービスとして登録して読み込ませます。ドライバ自体は正規の署名を持つため、署名の確認だけでは異常と判定されません。そのうえでマルウェアがドライバの窓口へ命令を送り、カーネルの権限でEDRのプロセスを終了させたり、防御製品がカーネルに登録した監視の仕組みを外したりします。ドライバの脆弱性を使ってEDRを停止させる専用ツールは「EDRキラー」と呼ばれ、ランサムウェアの攻撃者が暗号化の前段で使う道具として定着しています。

MITRE ATT&CKのT1068は、攻撃者が署名済みの脆弱なドライバを侵害済みの端末に持ち込み、その脆弱性を突いてカーネルモードでコードを実行することがあり、この手法がBring Your Own Vulnerable Driver(BYOVD)と呼ばれることがあると記載しています。持ち込み方としては、初期侵入時に配送するファイルに含める方法や、侵入後に外部から転送する方法が挙げられています。

ここで押さえておきたいのは、ドライバの読み込みそのものに管理者相当の権限が必要だという点です。MicrosoftのASRルールの説明も、十分な権限を持つローカルのアプリが脆弱な署名済みドライバを悪用してカーネルへアクセスできると表現しています。ドライバを持ち込んで読み込ませる段階に管理者権限が要るため、BYOVDは入口ではなく、すでに管理者権限を奪われた後の防御回避の段階で使われる手口です。一方で、読み込まれた後のドライバの脆弱性は、権限の低いプログラムから悪用できる場合があります。正規のソフトウェアが導入した脆弱なドライバがもともと端末にあれば、持ち込みの段階を経ずに悪用される可能性もあります。

OSに標準で入っている正規のツールを悪用する環境寄生型攻撃とは、外部から署名済みのファイルを持ち込む点で性質が異なります。両者はランサムウェアの侵入後の段階で組み合わせて使われることが多いため、検知の設計はあわせて考えると整理しやすくなります。

ランサムウェアで確認されている利用例#

BYOVDは研究上の概念ではなく、実際のランサムウェア攻撃で使われていることが一次情報で確認できます。

CISAがFBIなどと共同で2025年3月に公開したMedusaランサムウェアのアドバイザリ(AA25-071A)は、Medusaの攻撃者が一部の事例で、脆弱なドライバや署名済みのドライバを使ってEDRツールを強制終了させたり削除したりしようとしたと記載しています。

CISAのアドバイザリAA25-071Aは、技術的詳細のうち検知回避を扱う部分で「In some instances, Medusa actors attempted to use vulnerable or signed drivers to kill or delete endpoint detection and response (EDR) tools」と記載しています。

Cisco Talosは2025年12月9日、DeadLockランサムウェアの攻撃で使われたBYOVDのローダーを分析しています。この報告によれば、攻撃者はBaiduのウイルス対策製品に含まれるドライバBdApiUtil.sys(CVE-2024-51324)を別名に偽装して持ち込み、ローダーが稼働中のプロセスから対象のウイルス対策製品やEDRを探し出し、ドライバを経由してそれらのプロセスを終了させていました。

Cisco Talosは、DeadLockランサムウェアの攻撃者がBaidu Antivirusのドライバ(CVE-2024-51324)を悪用するローダーを用い、ウイルス対策製品やEDRのプロセスを特定して終了させていたと報告しています。

MITRE ATT&CKのT1068にも具体例が記録されています。Embargoランサムウェアの攻撃者はMS4Killerと呼ばれるツールで脆弱なドライバを端末へ送り込み、証明書が失効済みのドライバprobmon.sysを悪用したとされています。

規模感を示す調査として、ESETは2026年3月19日に公開した分析で、実際の攻撃で使われたEDRキラーを90種類近く確認し、そのうち54種類がBYOVD型で、合計35種類の脆弱なドライバを悪用していたと報告しています。同じ分析は、個別のブロックや署名の失効だけでは止めきれない例として、他社の調査を引いています。一つはCheck Point Researchが2025年2月に公表した調査で、攻撃者がドライバTruesight.sysの旧版2.0.2を一部改変し、有効な署名を保ったまま2,500を超える亜種を作っていたと報告されています。もう一つはHuntressが2026年2月に分析した侵害事例で、証明書が期限切れで明示的に失効されていたにもかかわらず、ドライバEnPortv.sysが悪用されたとESETは紹介しています。ESETがEDRキラーの利用を確認したグループとしては、Qilin、Akira、Medusa、DragonForce、LockBit、DeadLock、Embargoなどが挙げられています。ただしこの一覧はEDRキラー全般の利用を示すもので、すべてがBYOVD型とは限りません。

ESETは、90種類近いEDRキラーのうち54種類がBYOVDを使い、35種類の脆弱なドライバを悪用していたと報告しています。そのうえで、悪用されやすいドライバの読み込みを止めることは有効かつ必要な防御だが、それだけに頼るべきではないと述べています。

Check Point Researchは、攻撃者がTruesight.sysの旧版2.0.2の特定の部分を改変してハッシュ値の異なる亜種を作り、署名を有効なまま保っていたとし、有効な署名を持つ亜種を2,500以上検出したと報告しています。

BYOVDはランサムウェア攻撃全体の一部分にすぎません。初期侵入の経路を断ち、暗号化されても復旧できる備えを整える対策と組み合わせて考えます。

Microsoftが提供する防御機能#

Windowsには、脆弱なドライバの持ち込みと読み込みを止めるための機能が複数用意されています。それぞれ止める段階が違うため、役割を分けて理解しておくと設定の抜けを防げます。

脆弱ドライバブロックリスト#

Microsoftの脆弱ドライバブロックリストは、カーネルでの権限昇格に悪用できる既知の脆弱性を持つドライバ、マルウェアやその署名に使われた証明書、悪意はなくてもWindowsのセキュリティモデルを迂回できる挙動を持つドライバを対象に、読み込みを拒否する仕組みです。Microsoft Learnによれば、Windows 11 2022 Update以降はすべての端末で既定で有効になっており、Windowsセキュリティのアプリから確認できます。メモリ整合性、スマートアプリコントロール、Sモードのいずれかが有効な場合にも強制されます(Windows Server 2016を除く)。

Microsoft Learnは、ブロックリストは四半期ごとに更新され、月例のWindows更新でも配信されると説明しています。あわせて、記事内とダウンロード提供のブロックリストは、OSに含まれWindows Updateで配信される版よりも多くの既知の脆弱なドライバを含むのが通常であり、互換性を保つために一部のブロックを保留することがあるとも明記しています。

同じページでMicrosoftは、ブロックリストがすべての脆弱なドライバを確実に止めるものではないと注記し、可能な限り明示的な許可リストの方式を推奨しています。既定で有効だからといって安心せず、どの版のリストが自組織の端末に適用されているかを把握しておく必要があります。

メモリ整合性(HVCI)#

メモリ整合性は、仮想化ベースのセキュリティ(VBS)の機能の一つで、ハイパーバイザーで分離された環境の中でカーネルモードのコード整合性を検証します。Microsoftは脆弱なドライバへの対策として、まずメモリ整合性またはSモードの有効化を推奨しています。多くの新しいWindows 11端末では既定で有効ですが、古い端末やアップグレードした端末では無効のまま運用されていることがあります。一部のアプリやドライバはメモリ整合性と互換性がなく、有効化の際に不具合や起動失敗につながる場合があるため、機種ごとに検証してから展開します。

Microsoft Learnは、メモリ整合性がVBSの分離環境でカーネルモードのコード整合性を実行し、カーネルを悪用しようとするマルウェアへの保護を強めると説明しています。同時に、一部のアプリやドライバが非互換で、まれにブルースクリーンを伴う起動失敗が起こりうると注意を促しています。

App Control for BusinessとASRルール#

メモリ整合性を有効にできない端末では、MicrosoftはApp Control for Business(旧WDAC)の既存ポリシーの中で推奨ブロックリストを適用する方法を示しています。ダウンロード提供のブロックリストには監査版と強制版があり、まず監査モードで既存の業務ソフトが止まらないかを確認してから強制版へ移るよう求めています。このポリシーはAllow Allのルールを含み、指定したドライバを拒否するためのものです。単体で適用しても、未許可のアプリやドライバ全般を止める許可リストにはなりません。明示的な許可リストを適用する既存ポリシーと統合する場合は、Allow Allのルールを外してから統合するようMicrosoftは案内しています。ポリシーを適用しても、すでに動作中のドライバは再起動するまで止まらない点にも注意が要ります。

Microsoft Defender for EndpointのASRルール「Block abuse of exploited vulnerable signed drivers」(GUID 56a863a9-875e-4185-98a7-b882c64b5ce5)は、アプリが脆弱な署名済みドライバを端末に保存する動きを止めます。ただしMicrosoftは、このルールが端末上にすでに存在するドライバの読み込みは止めないと明記しており、ブロックリストやApp Controlとの併用を前提にしています。

Microsoft LearnのASRルールリファレンスは、このルールが脆弱な署名済みドライバの保存を防ぐ一方、既存ドライバの読み込みは防がないと説明し、追加の保護としてApp Control for BusinessとMicrosoftの脆弱ドライバブロックリストを挙げています。高度なハンティングではAsrVulnerableSignedDriverAuditedとAsrVulnerableSignedDriverBlockedという動作種別で記録されます。

App Controlによる許可リストは、DLLの読み込みを悪用する手口への対策としても使われます。ポリシー設計を一度に済ませたい場合は、あわせて確認しておくと効率的です。

LOLDriversなどの参照先#

Microsoftのブロックリストを補う情報源として、コミュニティが運営するLOLDrivers(Living Off The Land Drivers)があります。悪用が報告された脆弱なドライバや悪意あるドライバを一覧化し、ハッシュ値や根拠となる情報、検知ルールを公開しているカタログです。自組織の端末に同じハッシュのドライバが存在しないかを照合したり、検知ルールの作成の手がかりにしたりする用途で使えます。

ただし、LOLDriversに載っているドライバのすべてが自組織で不要とは限りません。ハードウェアの管理ツールなどが正当な目的で同じドライバを使っている場合があるため、照合で見つかったものは業務上の必要性を確認してから、更新版への置き換えや削除、ブロック対象への追加を判断します。業務で使うドライバに脆弱性が見つかった場合は、配布元の修正版を確認し、Microsoftのドライバ提出窓口の案内に沿って扱いを相談できます。

検知の着眼点#

ブロックが効かなかった場合に備えて、BYOVDの前後で現れる痕跡を捉える仕組みを用意します。

• ドライバの読み込みの記録: Sysmonを導入している環境では、イベントID 6(Driver loaded)でドライバの読み込みと署名情報を記録できます。普段その端末で見かけないドライバや、ユーザーが書き込めるフォルダから読み込まれたドライバを重点的に確認します。
• ドライバ型サービスの新規作成: 管理者権限で新しいカーネルドライバのサービスが登録される動きは、正規のソフトウェア導入以外ではまれです。導入作業の予定と照合できる形で記録を残します。
• コード整合性のイベント: App Controlのポリシーを監査モードで運用すると、ブロックされるはずだったドライバがCodeIntegrityのログにイベントID 3076として、強制モードで止めた場合は3077として記録されます。監査の段階で既知の脆弱なドライバが出てくれば、それ自体が調査の起点になります。
• ASRルールの記録: Defender for Endpointの高度なハンティングで、脆弱なドライバの保存が監査またはブロックされた記録を確認します。
• 防御製品の停止: EDRのエージェントが予告なく停止した、管理サーバーとの通信が途絶えた、といった状態は、BYOVDが成功した後に見える数少ない兆候です。端末側の検知が消えても管理側で気づけるよう、エージェントの死活監視をアラートに組み込みます。

Microsoft Learnは、イベントID 3076を監査モードのポリシーで「強制していればブロックされていた」ことを示す主要なイベント、3077を強制モードのポリシーでファイルがブロックされたことを示す主要なイベントとして説明しています。

組織の対策チェックリスト#

脆弱なドライバを持ち込んで読み込ませるには管理者権限が要るため、権限を奪われにくくすることがそのまま成立条件を狭めます。ドライバ対策とあわせて、権限設計を見直す機会にしてください。

導入を進める順序#

すべての機能を一度に強制すると、業務で使うドライバが止まって端末が使えなくなる危険があります。影響を見ながら段階的に進めます。

まとめ#

BYOVDは、正規の署名という信頼の仕組みを逆手に取り、侵入後にカーネルの権限で防御製品を止める手口です。Cisco TalosやESETの報告が示すとおり、ランサムウェアの攻撃者が暗号化の前段で使う例が相次いでいます。対策は、脆弱ドライバブロックリストとメモリ整合性を土台に、App ControlとASRルールで持ち込みと読み込みの両方を塞ぎ、ブロックをすり抜けた場合に備えてドライバの読み込みやEDRの停止を検知する構成が基本になります。ブロックリストが万能ではないことをMicrosoft自身が認めている以上、予防と検知を重ね、そもそも管理者権限を奪われにくくする取り組みと組み合わせて運用することが現実的な向き合い方です。