仮想化された（非）安全性：攻撃者が VBS エンクレーブを武器化する手法とは

攻撃者は常に、検知されることなくホスト上でマルウェアを配信して実行する新しい方法を模索しています。私たちは、仮想化ベースのセキュリティ（VBS）エンクレーブ内でマルウェアを実行するための新しい手法を調査し、一般的なセキュリティ対策を回避しました。2025 年 8 月 8 日、私はラスベガスで開催されていた DEF CON 33 でこのアタックサーフェスに関するプレゼンテーションを行いました。

Microsoft のセキュリティ実装の一部である VBS は、重要な OS コンポーネントを分離するように設計された仮想環境を構築します。VBS エンクレーブではプロセスの一部領域の隔離が可能になり、他のプロセス、プロセス自体、さらにはカーネルからもアクセスできなくなります。 

VBS エンクレーブはセキュリティを向上させますが、攻撃者にとって魅力的な選択肢になる場合もあります。というのも、エンクレーブ内で実行されているマルウェアは、広く使用されているメモリーベースの検知やフォレンジックでは可視化されない恐れがあるからです。私たちはこの考えを検証し、VBS エンクレーブが悪用されうる手法を何点か発見しました。

VBS エンクレーブの基礎となる仮想信頼レベル（VTL）の概念を理解することが重要です。各信頼レベルにより、その下で実行されているエンティティにはそれぞれ異なる物理メモリーへのアクセス権限が与えられます。下位の VTL は、上位の VTL のメモリーにアクセスすることはできません。 

Windows は現在、VTL0 と VTL1 という 2 つの主要な信頼レベルを使用しています。VTL0 は、通常のカーネルや通常のユーザー実行モードなど、従来の OS コンポーネントを実行するために使用されます。VTL1 は VTL0 よりも権限が高く、セキュア・カーネル・モードと隔離されたユーザーモードという 2 つの新しい実行モードを作成します。

• セキュア・カーネル・モードは、セキュアカーネルを実行するために使用されます。このカーネルは VTL1 で動作するため、通常のカーネルより権限が高くなっています。セキュアカーネルは通常のカーネルにポリシーを適用し、機密性の高いメモリー領域へのアクセスを制限することができます。セキュアカーネルは非常に制限されており、サードパーティ製ドライバーをサポートしていないため、アタックサーフェスが大幅に縮小されます。
• 隔離されたユーザーモードは、セキュアプロセスを実行するために使用されます。これは、VTL1 のメモリー隔離機能を使用する特別なタイプのユーザー・モード・プロセスです。隔離されたユーザーモード内部のメモリーは、通常のカーネルを含め、どの VTL0 コードでもアクセスできません。

VTL0 と VTL1 は、同時に次の 4 つの実行モードを作成します。 

• Ring0 VTL0：通常のカーネルモード
• Ring0 VTL1：セキュア・カーネル・モード
• Ring3 VTL0：通常のユーザーモード
• Ring3 VTL1：隔離されたユーザーモード

VBS エンクレーブでは隔離されたユーザーモード内に存在するユーザー・モード・プロセスに一区画が設置され、ここに「エンクレーブモジュール」と呼ばれる DLL をロードすることができます。これらは、VTL0 で実行されているデータやコードにアクセスできない「信頼できる実行環境」です。これにより、システムを侵害する可能性のある攻撃者から機密性の高い操作を隔離しやすくなります。

VTL1 へのアクセスは制限されているため、DLL をエンクレーブにロードするためには、Microsoft が発行した特別な証明書を使用して適切に署名されている必要があります。このような署名なしでモジュールをロードしようとすると、失敗します。エンクレーブモジュールに署名できるのは信頼できるサードパーティだけですが、これらのモジュールを誰がロードできるかについての制限はありません。署名されている限り、どんなプロセスでも、任意のモジュールをエンクレーブにロードできるのです。

VBS エンクレーブは攻撃者にとって魅力あるものになっていますが、それにはいくつかの理由があります。第 1 に、エンクレーブのアドレス空間には、エンドポイントの検知と対応（EDR）や分析ツールなど VTL0 で実行されているものからはアクセスできません。第 2 に、エンクレーブ内からの API コールは EDR には検知されません。

このことを認識したうえで、攻撃者がエンクレーブ内で悪性コードを実行する方法を調査しました。さらに、攻撃者がマルウェアの実行後にどのような手法を実装できるかを調べました。このブログ記事では、私たちが発見したことを紹介します。

VBS エンクレーブモジュールは、デバッグ可能に設定できます。エンクレーブモジュールは VTL1 で実行されるため、デバッグは通常不可能です。デバッガーがエンクレーブメモリーにアクセスしてデータを取得したり、ブレークポイントを配置したりできないためです。しかし、デバッグ可能なエンクレーブモジュールが実行された場合、このモジュールは VTL1 にロードされていることがわかりました。 

デバッグを有効にするために、セキュアカーネルはデバッグ可能なエンクレーブモジュールに適用されるいくつかの例外を実装しています。デバッグ可能なエンクレーブモジュール内のメモリー権限は、VTL0 プロセスでも変更できます。モジュールで処理されるデータは、簡単に露出できてしまいます。

このため、VBS エンクレーブの核心的な目的である VTL0 からのメモリーの一部隔離が事実上損なわれます。こうした理由から、Microsoft は開発者に対し、デバッグ可能なエンクレーブモジュールをリリースしないよう強く推奨しています。

攻撃者が 1 つでもデバッグ可能な署名済みエンクレーブモジュールを入手した場合、私が DEF CON で説明したいくつかの手順を通じて VTL1 コードを実行できます。これは、攻撃者にとってリスクにもなります。攻撃者がエンクレーブメモリーにアクセスできるのと同様に、EDR もアクセスできるからです。ただし、この攻撃によって API 監視が回避され、EDR ソリューションの可視性が制限される可能性があります。

この手法は、エンクレーブ内で実行することによって得られるいくつかの利点を活かした、ステルス性の高い「semi-VTL1」インプラントの作成に利用されるかもしれません。

私たちは、攻撃者が「脆弱なドライバーの持ち込み（BYOVD）」という手口を応用して VBS エンクレーブ内でマルウェアを実行できるかどうかを調べました。これには、脆弱な署名済みエンクレーブモジュールの発見も含まれます。

その結果、Microsoft Edge で使用されている VBS エンクレーブモジュールの CVE-2023-36880 にたどり着きました。Chrome プラットフォーム・セキュリティ・チームの Alex Gough 氏によって発見されたこの脆弱性は、攻撃者が任意のデータをエンクレーブ内で読み書きすることを可能にします。 

私たちは、読み取り／書き込みプリミティブを悪用して、エンクレーブスタックをリターン指向プログラミング（ROP）チェーンで上書きしようとしました。これにより、最終的にエンクレーブ内でシェルコードを実行できるようになるはずでした。しかしエンクレーブは、任意のコードガード（ACG）を使用して未署名のコードが実行されないよう保護されていることがわかりました。ACG は、実行時に作成されたコードの実行をブロックするように設計されたセキュリティの緩和策です（図）。 

エンクレーブ内で ACG をバイパスし、未署名コードをロードする方法は（現時点では）見つかりませんでしたが、理論的には、完全な ROP 攻撃が可能です。

私たちは、「Mirage」と名付けたメモリースキャン回避技術について検証しました。この名称は、無害な状態と武器化された状態を継続的に切り替えるペイロードを作成する回避技術、Gargoyle から着想を得ています。 

Mirage は、VTL1 と VTL0 メモリー間を移行することで同様の成果を達成しています。この技術は、VTL1 エンクレーブメモリーにシェルコードを保存し、脆弱性を利用して定期的に VTL0 に転送し、実行した後で、VTL0 メモリーからすぐに消去します。

ペイロードはほとんどの時間を VTL1 に隠れて過ごすため、メモリースキャンやダンプに対して耐性があります。休止段階にあるペイロードはステルス性があり、アクセスもできません。また、VTL0 へのシェルコードの書き込みはエンクレーブによって実行され、EDR ツールの範囲外となるため、監視による検知が困難になります。

エンクレーブマルウェアのもう 1 つの興味深い用途は、アンチデバッグです。エンクレーブ内で実行されているコードは、デバッガーを含む VTL0 アプリケーションからアクセスできないため、マルウェアは非常に有利になります。

私たちはいくつかのアプローチを検討しました。エンクレーブによる、プロセスの VTL0 アドレス空間へのアクセスを利用すると、プロセス環境ブロック（PEB）を手動で読み取り、「BeingDebugged」フラグの値を確認することができます。デバッガーが検知された場合、プロセスはエンクレーブで終了できます。

また、プロセッサー・クロック・サイクルを使用して、異なるエンクレーブの呼び出し間の消費時間を測定する時間ベースのデバッグ対策手法についても検討し、大きな遅延が検知された場合はプロセスを終了しました。

デバッグ対策チェックとともにコードの重要な部分をエンクレーブに移動することで、動的分析に十分対抗できるマルウェアを作成できます。正しく実装されている場合、このアプローチは Hyper-V またはセキュアカーネルのデバッグによってのみ無効にできます。

現在、エンクレーブは限られた数のアプリケーションでのみ使用されています。そのため、異常なエンクレーブの使用や悪用によって、検知の可能性が大きく高まります。その可能性を活用するために、防御担当者は次のことに注力できます。

• VBS エンクレーブの既知の合法的な使用のベースラインを設定し、逸脱をフラグする
• エンクレーブ API を監視して異常を検出する
• 新しいプロセスを示す可能性がある、エンクレーブ DLL のロードを監視する
• マイクロセグメンテーションなど、重要なシステムやアプリケーションを分離するために設計されたその他のセキュリティ技術を活用する

VBS エンクレーブは、アプリケーションの機密性の高いセクションを保護するための優れたツールを提供しますが、脅威アクターがマルウェアを「保護」するために使用することもできます。DEF CON のプレゼンテーションで説明したように、エンクレーブ攻撃戦略は、現時点で大部分が理論上のものです。しかし私たちは、優秀な脅威アクターが独自の調査を行い、VBS エンクレーブを悪質な目的で利用するための脆弱性を見つけようとしていることを確信しています。 

重要な最初の一歩として、まずは自社の環境内でのエンクレーブの使用状況を把握し、この進化する脅威に先手を打ちましょう。

私が以前投稿したブログ記事「VBS エンクレーブの悪用による回避型マルウェアの作成」もご覧ください。