セキュリティソフト「PC Tools Internet Security」が使っていたWindowsカーネルドライバ「PCTCore64.sys」に、アクセス制御の不備（CVE-2026-8501）が公表されました。問題は「自社がこの製品を使っているか」だけではありません。正規に署名された脆弱なドライバを攻撃者が自分で持ち込んで悪用する「BYOVD（Bring Your Own Vulnerable Driver）」という手口があり、未導入の組織にとっても他人事ではないからです。本記事では、何が起きたのかと、情シスが今押さえるべき現実的な備えを整理します。
この記事でわかること
- PCTCore64.sysの脆弱性（CVE-2026-8501）の概要と影響
- 「BYOVD」とは何か、なぜ自社未導入でも危険なのか
- EDRや認証情報を狙う具体的なリスク
- Microsoftの脆弱なドライバブロックリストなど、すぐ着手できる対策
何が起きたのか
2026年6月、米CERT/CC（VU#158530）とJPCERT/CCのJVN（JVNVU#90461576）が、Windowsカーネルドライバ「PCTCore64.sys」に不適切なアクセス制御の脆弱性があると公表しました。このドライバは、かつて販売されていたセキュリティ製品「PC Tools Internet Security」が用いていたものです。
具体的には、ドライバが公開するデバイスインターフェース \\.\PCTCoreDriver に適切なセキュリティ記述子（アクセス制御）が設定されておらず、一般権限のユーザーモードプロセスからでも特権的なIOCTLコマンドを呼び出せてしまうのが問題の核心です。本来であれば IoCreateDeviceSecure やSDDLによる保護をかけるべき箇所が、無防備になっていたかたちです。
注意すべきは、PC Tools Internet Securityはすでに開発・サポートが終了した製品で、修正パッチの提供は期待できないという点です。報告はセキュリティ研究者のTzachi Hazan氏らによるもので、Microsoftは「自社は影響を受けない（Not Affected）」、現在の権利元であるSymantec/Broadcom側の対応状況は「不明（Unknown）」とされています（CERT/CC公表時点）。
脆弱性の概要
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-8501 |
| 識別子 | VU#158530（CERT/CC）／ JVNVU#90461576（JVN） |
| 対象 | PC Tools Internet Security が用いるカーネルドライバ PCTCore64.sys |
| 脆弱性の種類 | 不適切なアクセス制御（IOCTLインターフェースの保護不備） |
| 深刻度 | CVSS基本値 7.8（High／ローカル攻撃）※公開脆弱性データベースでの評価 |
| 公表日 | 2026年6月1日（CERT/CC）／ 6月2日（JVN） |
| ベンダー対応 | 製品は開発終了。Microsoft＝影響なし／Symantec＝対応状況不明 |
※CVSS基本値はサードパーティの脆弱性データベースに基づく参考値です。CERT/CCのアドバイザリ本文には固定値の記載がないため、最終判断は一次情報をご確認ください。
BYOVDとは？なぜ自社が未導入でも危険なのか
BYOVD（Bring Your Own Vulnerable Driver）とは、攻撃者が「正規に署名された脆弱なドライバ」を標的の端末に自分で持ち込み、そのドライバの欠陥を突いてカーネル権限の操作を行う攻撃手法です。
ここが本件の肝です。PCTCore64.sysは正規のデジタル署名を持つため、Windowsの標準的なドライバ署名チェックを通過します。つまり攻撃者は、すでに何らかの方法で端末に侵入したあと、この脆弱なドライバ単体を持ち込んでインストールし、足場を一気に強化できるのです。自社がPC Tools製品を一度も入れたことがなくても、攻撃の「部品」として外部から運び込まれるため、リスクと無縁ではありません。
BYOVDは近年、ランサムウェア攻撃グループがEDR（エンドポイント検知・対応）を無効化する常套手段として悪用しており、決して理論上の話ではありません。EDRそのものの役割についてはEDRとは？仕組みとEPP・XDRの違いもあわせてご覧ください。
想定されるリスク
CERT/CCは、この脆弱性を悪用したローカル攻撃者が次のような特権操作を実行し得るとしています。
- 認証情報の窃取：lsass.exeプロセスから資格情報を抜き取る
- 保護プロセス（PPL）の強制終了：本来は保護されているはずのセキュリティ関連プロセスを止める。EDR/アンチウイルスの無効化に直結する
- ハンドルの列挙・横取り：システム全体のハンドル操作、別プロセスのハンドル奪取
- サービス妨害（DoS）：システムを不安定化させる
特に「EDRを黙らせてからランサムウェアを展開する」という流れは、被害を一気に拡大させます。検知の最後の砦が外される前提で多層防御を考える必要があります。
現場目線の課題
正直なところ、こうした「過去に入れたソフトの残骸ドライバ」や「外部から持ち込まれる単体ドライバ」を、限られた人員ですべて把握するのは至難の業です。資産管理台帳に載っているアプリは追えても、アンインストール後に取り残されたドライバファイルや、攻撃者がその場で落とすファイルまでは見えにくいのが実情でしょう。
しかもPCTCore64.sysのように開発終了済みの製品は、ベンダーからの修正を待てません。「パッチを当てて終わり」という普段の脆弱性対応の型が通じないため、パッチではなく“ブロック（実行させない）”で守るという発想の切り替えが要ります。ここに、いつものパッチ運用とは違う難しさがあります。
情シスはどうすべきか
本件のように個別パッチが出ない脆弱なドライバには、Windows標準のしくみで「読み込ませない」対策が有効です。CERT/CCも次のような緩和策を挙げています。
- Microsoft 脆弱なドライバ ブロックリストを有効化する（既知の悪用可能ドライバの読み込みをOSがブロック）
- HVCI（メモリ整合性／ハイパーバイザーで保護されたコード整合性）を有効化する
- WDAC（Windows Defender Application Control）でドライバ・アプリの許可制を敷く
- Credential Guardでlsass内の資格情報を分離・保護する
- 該当ドライバが端末に残っていないか棚卸しし、あれば削除する
- 管理者権限を最小化し、一般ユーザーが任意のドライバを導入できないようにする
これらは本件単体への対処にとどまらず、ゼロトラストの考え方に沿った端末側の地固めにもなります。「侵入された後」を前提に、認証情報とEDRをどう守り抜くかという視点が重要です。
また、組織全体の底上げには公的機関の指針が役立ちます。中小規模の体制であれば、まずはIPA「中小企業の情報セキュリティ対策ガイドライン」で運用の型を確認するのが近道です。万一EDRを無効化されランサムウェア被害に至った場合の復旧力という観点では、バックアップの3-2-1ルールのような基本の備えも合わせて見直しておきたいところです。最終的には、怪しいファイルを実行させない地道なユーザー教育・啓発が効いてきます。
まとめ
- PCTCore64.sys（CVE-2026-8501）はアクセス制御不備の脆弱性。製品は開発終了済みで、修正パッチは期待できない。
- 正規署名ドライバを持ち込む「BYOVD」の踏み台になり得るため、当該製品が未導入でも油断は禁物。lsassからの認証情報窃取やEDR無効化につながる。
- 対策はパッチではなく“ブロック”が基本。Microsoft脆弱なドライバブロックリスト・HVCI・WDAC・Credential Guardを有効化し、管理者権限を絞る。
