新たに報告されたWindowsの攻撃手法「Bring Your Own Trusted Caller(BYOTC)」は、従来型のメモリ破壊系の脆弱性を悪用することなく、ドライバーレベルの認可制御を回避できることを示しています。
この手法では、特権を持つカーネルドライバーそのものを直接攻撃するのではなく、そのドライバーがすでに信頼している正規のユーザーモードアプリケーションを侵害・悪用します。
この手法は、よく知られているBring Your Own Vulnerable Driver(BYOVD)モデルを発展させたものです。BYOVD攻撃では、脅威アクターが正規に署名されているものの脆弱性のあるドライバーをロードし、カーネルレベルの機能を取得します。
Microsoftの脆弱なドライバーのブロックリストや、コミュニティが管理するLOLDriversデータベースは、脆弱性が判明している、あるいは悪意ある目的で悪用されていることが知られているドライバーを追跡することで、こうしたリスクの低減を図っています。
セキュリティ製品、アンチマルウェア製品、検査系ツール、自己防御機構を持つドライバーは、通常のユーザーモードソフトウェアでは利用できないプロセスの終了や保護されたハンドルへのアクセスなどの操作を、正規の目的で必要とする場合があります。
ベンダー各社は、こうした機能をすべてのプロセスに公開するのではなく、署名済みまたは検証済みのクライアントアプリケーションからの要求のみを許可することが一般的です。
しかし、このアプローチには重大な第二の境界線が生まれます。署名済みの実行ファイルは、そのプロセスを起動したファイルの出所を証明するものであって、実行中のプロセスがベンダーの排他的な制御下に置かれ続けていることを証明するものではないのです。
管理者権限を持つ攻撃者がDLLを注入したり、保持しているプロセスハンドルを介してメモリを操作したり、信頼されたプロセス生成チェーンを乗っ取ったりできる場合、ドライバーは一見正規に見えるものの実際には悪意あるコマンドを、そうした呼び出し元から受け入れてしまう可能性があります。
実質的に、BYOTCは信頼済みクライアントをユーザー/カーネル境界における「混乱した代理人(confused deputy)」に変えてしまいます。カーネルドライバーは要求が承認済みプロセスから来ていることを正しく検証しますが、そのプロセス自体はもはや信頼できる状態ではないのです。
その一例が、Malwarebytes Chameleonに関連するコンポーネントであるmbamchameleon.sysです。これはマルウェアによる妨害への耐性を高めるために設計されています。
このドライバーはIOCTL 0x222024を公開しており、これは最終的に、敵対的なプロセスを停止させるための正規機能であるZwTerminateProcessを呼び出せるものでした。
2026年9月に公表された調査によると、このドライバーはまずIOCTL 0x222008を通じて、呼び出し元のイメージがMalwarebytesによって署名されているかどうかに基づき、プロセスを信頼済みとして登録できるようにしていました。
管理者権限を持つ攻撃者は、正規に署名されたMBAM.exeを起動し、そのプロセスにコードを注入した上でドライバーに登録し、Microsoft DefenderのMsMpEng.exeのようなセキュリティプロセスに対して特権を持つ終了操作を呼び出すことが可能でした。
問題は、不正な形式のIOCTLやドライバーのメモリ安全性に関するバグではありませんでした。起動後も署名済みプロセスが信頼できる状態のままであるという前提そのものが問題だったのです。
Xushengの研究者らによると、BYOTCは別の問題を突いています。それは、意図的に実装された特権ドライバー機能が、ユーザーモードの信頼モデルによって十分に保護されていないという点です。
BYOTCアタック、Windowsクライアントを悪用
Malwarebytes Chameleonは正規の保護コンポーネントですが、攻撃者がそのクライアントプロセスを制御できてしまうと、この信頼関係自体が危険なものに変わります。
さらに高度なBYOTCの事例として、System InformerのSystemInformer.sysドライバーに影響を及ぼしたものがあります。
System Informerは、実行ファイルの検証、モジュールロードの監視、デバッガ検出、保護されたプロセスハンドル、そして安全なプロセス生成履歴など、クライアントに対して複数の整合性チェックを適用しています。
最も機密性の高いプロセス終了メッセージについては、クライアントがMAXIMUM整合性レベルに達している必要があります。
しかし、Windowsのプロセス生成の仕組みには厄介な例外が存在します。それは、子プロセスを生成した親プロセスが強力な初期化用ハンドルを保持し続けるという点です。
権限昇格した悪意ある親プロセスは、正規のSystem Informerプロセスを生成し、PROCESS_VM_OPERATIONやPROCESS_VM_WRITEといった権限を保持したまま、初期化中の子プロセスを改変し、それを使って新たな、一見信頼できるように見えるプロセスチェーンを構築することが可能でした。
つまり、この脆弱性は単純なコード注入にとどまるものではありませんでした。子プロセスが、その初期化を依然として制御している親エンティティよりも高い信頼レベルを得てしまうという、信頼のエスカレーションに関する欠陥だったのです。
System Informerは、Windowsが保護するサービス基盤にその安全な生成チェーンを固定させることで、この問題に対処しました。
修正後の設計では、Windowsが保護するTCB(Trusted Computing Base)プロセスであるservices.exe経由で起動される一時的なサービスを、より高い整合性レベルを持つクライアントを生成するための信頼済みルートとして使用しています。
System Informerのドライバーアーキテクチャは、以前からユーザーモードのバイナリを検証し、未署名モジュールのロードを制限していますが、この事例は、特権を持つクライアント・ドライバー間通信を守るためにどれほど深いレベルの保護が必要かを物語っています。
BYOTCは、EDR、アンチウイルス、アンチチート、エンドポイント管理、システム検査系の製品に特に関連の深い問題です。
これらのツールは往々にして強力なカーネル操作を公開しつつ、誰がそれを呼び出せるかの判断をユーザーモードのコンポーネントに委ねています。
防御側は、信頼済みクライアントに対してコード注入やデバッグが可能かどうか、攻撃者が制御する親プロセスによって起動されうるかどうか、あるいは継承されたプロセスハンドルを通じて改変されうるかどうかをテストすべきです。
また、信頼の取り消しが恒久的なものになるようにすることも重要です。信頼できないモジュール、デバッガ、改ざんの兆候が一度検出された場合、その条件が消えたからといってプロセスが特権的な地位を自動的に取り戻すことがあってはなりません。
最も強固な設計は、署名者チェックやベンダー管理下のプロセス状態のみに依存するのではなく、Protected Process Light(PPL)のようなWindowsが強制する保護機構に信頼済みクライアントを固定するものです。
とはいえ、PPLを特殊な保護サービスモデル以外で導入するのは依然として容易ではありません。
結局のところBYOTCは、Windowsドライバーのセキュリティにおけるある種の盲点を浮き彫りにしています。署名済みの実行ファイルであると認識することと、その背後にあるプロセスの実行時の整合性が保たれていることとは、決して同じではないのです。
★ 7つのメトリックゲート型AI SOC導入フェーズを学ぶ – 無料AI SOC導入プレイブック2026をダウンロード。
翻訳元: https://gbhackers.com/byotc-attack-abuses-windows-clients/
