VBS エンクレーブの悪用による回避型マルウェアの作成

仮想化ベースのセキュリティ（VBS）は、最近の最も魅力的なセキュリティの進歩の 1 つです。OS の重要なコンポーネントを隔離する機能により、Microsoft は Credential Guard や Hypervisor-Protected Code Integrity（HVCI）などの機能を使用して、大幅なセキュリティ向上を実現しました。

VBSによって実現される、見落とされがちな機能の1つが、VBSエンクレーブです。これは、プロセスの領域を分離し、他のプロセス、プロセス自体、さらにはカーネルにアクセスできないようにする技術です。 

VBS エンクレーブにはさまざまなセキュリティアプリケーションが含まれており、Microsoftはそれらを使用していくつかの注目すべきサービスを実装しています。これには、物議を醸しているリコール機能も含まれています。。さらに、Microsoft は VBS エンクレーブのサードパーティ開発をサポートし、積極的に導入を推進しています。

エンクレーブはシステムのセキュリティを確保するのに役立ちますが、攻撃者にとっても非常に魅力的です。エンクレーブ内で実行されるマルウェアは、メモリーベースの検知やフォレンジックでは発見されない可能性があります。

私たちは VBS エンクレーブを調査し、それが悪意のある目的でどのように使用される可能性があるかを理解することを目指しました。このブログ記事では、その主な調査結果について詳しく説明します。また、これまでに文書化されていない VBS エンクレーブの動作を調査し、攻撃者がその内部で悪性コードを実行するために利用するシナリオを説明し、「エンクレーブマルウェア」が使用できるさまざまな手法を検証することで、VBS エンクレーブについて詳しく説明していきます。

また、Mirageについても紹介します。Mirageは、「脆弱なエンクレーブの持ち込み」と呼ばれる新しいアプローチに基づくメモリ回避手法です。攻撃者は正当なエンクレーブの古い、脆弱性のあるバージョンを使用して、このようなステルスな回避技術をどのように実装するのか、詳しく説明します。

Windows は従来、プロセッサー・リング・レベルによって、ユーザーアプリケーションによる OS の改ざんを防いでいました。このハードウェアの機能では、OS とユーザーアプリケーションを分離できます。カーネルは ring0 で動作し、ring3 ユーザー・モード・アプリケーションから分離されます。このアプローチの問題は、攻撃者に OS を侵害するための比較的簡単なパスを提供してしまうことです。これが Kernel Exploit です。

Windows カーネルは非常に広範な攻撃面を公開しています。カーネル自体が公開するさまざまなサービスと同様に、膨大な数のサードパーティ製ドライバーによって、Kernel Exploit と思われるものが絶えず発生しています。このような脆弱性を悪用するプログラムを使用することで、攻撃者は OS のあらゆる側面を制御できる可能性があります。ユーザー/カーネル モードの境界は不十分であることが証明されました。

このギャップを埋めるために、Microsoft は仮想信頼レベル（VTL）の形で OS にセキュリティの境界を追加しました。VTL 権限はメモリーアクセスに基づいています。各信頼レベルにより、その下で実行されているエンティティにはそれぞれ異なる物理メモリーへのアクセス権限が与えられます。これらの権限により、下位の VTL は上位の VTL のメモリーにはアクセスできなくなります。

従来のプロセッサー・リング・アーキテクチャと同様に、VTL は OS を VTL0 から（最大で）VTL16 までのさまざまな実行「モード」に分離します。ring0 の権限が最も高いプロセッサーリングとは異なり、上位の VTL ほど権限は高くなります。

Windows は現在、VTL0 と VTL1 の 2 つ（VTL2 も使用されますが、このブログ記事では扱いません）の主要な信頼レベルを使用しています。VTL0 は、カーネルやユーザーモードのアプリケーションなど、従来の OS コンポーネントを実行するために使用されます。VTL1 は VTL0 よりも権限が高く、セキュアカーネルモードと隔離ユーザーモードという2つの新しい実行モードを作成します。

セキュア カーネル モードとは、ring0 VTL1 実行モードを指します。このモードは、セキュアカーネルを実行するために使用されます。カーネルが VTL1 で動作するため、通常のカーネルより権限が高くなっています。これらの権限を使用して、セキュアカーネルは通常のカーネルにポリシーを適用し、機密性の高いメモリー領域へのアクセスを制限することができます。

前述したように、カーネルは大きな攻撃面を公開しており、侵害されやすくなっています。カーネルからいくつかの権限を削除し、その権限をセキュアカーネルに付与することで、カーネル侵害の影響を軽減することができます。

理論的には、セキュアカーネルの侵害によって攻撃者がシステムを完全に侵害する可能性もありますが、このシナリオははるかに可能性が低くなります。なぜなら、セキュアカーネルは非常に限定的であり、サードパーティ製のドライバーをサポートしていないため、攻撃面が大幅に減少しているからです。

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

エンクレーブモジュールは小さな「計算ユニット」として機能することを目的としており、システムとのやり取りやシステムへの影響は非常に限られています。そのため、エンクレーブモジュールは最小限の API セットしか使用できず、ほとんどのOSコンポーネントにアクセスできません。

エンクレーブ内で使用可能な API は、VTL1 にロードされた専用ライブラリからインポートされます。たとえば、通常のプロセスは ntdll.dll ライブラリに依存してOSからサービスを要求しますが、エンクレーブモジュールは vertdll.dll を使用します。これは、Syscall を介してセキュアカーネルと通信するために使用される「代替」ntdll です。

エンクレーブマルウェアの概念は、攻撃者にとって極めて魅力的です。それには次の 2 つの大きな利点があります。

1. 隔離されたメモリー領域で実行される：エンクレーブのアドレス空間は、VTL0 で実行されているもの（EDR や分析ツールなど）にはアクセスできないため、検知が非常に複雑になります。

2. 追跡不能な API コール：エンクレーブ内からの API コールは EDR には検知されません。EDR は、システムライブラリ内にフックを配置してユーザーモードで API を監視し、ドライバーを使用してカーネル内のアクティビティを監視します。エンクレーブからトリガーされた API コールは、VTL1 から実行され、これらの「フック」された VTL0 コンポーネントを経由しないため、これらの手法では検出できません。

図 4 に、この利点を示します。Windows API を呼び出す通常のプロセスは、NTDLL 内部のフックまたはカーネル自体を介して監視できます。しかし、エンクレーブモジュールは VTL1 常駐vertdllを通過し、セキュアカーネルへの呼び出しを実行します。どちらも EDR にはアクセスできません。

この可能性を認識し、私たちはエンクレーブマルウェアの概念を調査することにしました。この目的のためにエンクレーブを活用するためには、次の 2 つの疑問に答える必要があります。

1. 攻撃者はエンクレーブ内でどのようにして悪性コードを実行するのか
2. エンクレーブ内で実行に成功した攻撃者はどのような手法を使用するのか

前述したように、エンクレーブモジュールは、Microsoft が発行した証明書を使用して署名されている必要があります。つまり、エンクレーブ内で独自のコードを実行できるのは、エンクレーブモジュールによって承認されたエンティティだけです。それにもかかわらず、攻撃者にはいくつかの選択肢があります。

まず、攻撃者は OS の脆弱性を利用することができます。その一例が、CVE-2024-49706です。Alex Ionescu 氏（Winsider Seminars & Solutions 在籍）によって発見されました。この脆弱性により、攻撃者は署名されていないモジュールをエンクレーブにロードできる可能性があります。この脆弱性は Microsoft によって修正されましたが、将来的に、意欲的な攻撃者が同様のバグを発見する可能性があります。

2つ目の簡単なアプローチは、正当な署名を取得することです。これは、Microsoftが Trusted Signing プラットフォームを通じてエンクレーブ署名をサードパーティに公開しているため可能です。決して簡単ではありませんが、高度な攻撃者が Trusted Signing エンティティへのアクセス権を取得し、独自のエンクレーブに署名できることもあります。

私たちは、これら 2 つのオプションに加えて、攻撃者が VBS エンクレーブ内でコードを実行できるようにする、デバッグ可能なエンクレーブモジュールの悪用と脆弱なエンクレーブの悪用の 2 つの追加テクニックについても詳しく調査しました。

攻撃者の視点から見た明らかな問題は、これが両刃の剣であることです。攻撃者がエンクレーブメモリーにアクセスできるのと同様に、EDR もアクセスできるからです。とはいえ、これには API 監視を回避できるという利点があります。エンクレーブモジュールによって実行される API コールは依然として VTL1 DLL とセキュアカーネルを経由し、EDR の可視性が制限されます。

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

私たちは、VirusTotal などの情報源を使用して、デバッグ可能な署名付きエンクレーブモジュールを特定しようとしましたが、執筆時点ではうまくいっていません。しかし、十分に時間が経ち、エンクレーブテクノロジーが普及してくれば、最終的に何らかのモジュールが流出するのは間違いないでしょう。

エンクレーブ内で ACG をバイパスし、未署名コードをそのコードにロードする方法は見つかりませんでした。理論的には、完全な ROP 攻撃が可能であり、攻撃者が VTL1 で任意の API を呼び出すことができる可能性がありますが、この方向は追求していません。それでも、脆弱なエンクレーブに対応する別の興味深いアプリケーションを特定することができました。これについては、この記事の後半で説明します。

エンクレーブには悪意のあるアクティビティが発生する可能性が多く、動機のある攻撃者であればそれを起動することも可能であると理解したうえで、次に取り組んだ問題は、この種のマルウェアにどのような手法が利用可能かということでした。

最も簡単なのは、エンクレーブを本来の使用目的に従うことです。エンクレーブが攻撃者から機密データを保護できるのと同様に、攻撃者は自身の「秘密」を VTL0 エンティティから隠して使用することができます。

これは、ペイロードを EDR の範囲外に保存したり、暗号化キーをアナリストから隠したり、機密性の高いマルウェア設定をメモリーダンプから除外したりするなど、多くのシナリオで役立ちます。

より高度なオプションに関しては、従来のマルウェア技術の多くは、エンクレーブ内では実装できません。エンクレーブはシステム API の限られたサブセットしか使用できないため、ファイル、レジストリ、ネットワーク、その他のプロセスなどの主要な OS コンポーネントとは相互作用できません。

それにもかかわらず、エンクレーブ内で実行可能な技術はいくつか存在し、IUM で動作することによる利点を活かすことができます。

VTL0 ユーザー・モード・メモリーにアクセスすることで、さまざまな有用な技術を実装できます。悪意のあるエンクレーブをターゲットプロセスにロードすることで、こっそりと機密情報を監視して盗むことも、プロセス内の値を修正して、その動作を変更することもできます。

エンクレーブを使用してこれらの手法を実装することには大きな利点があります。前述のように、エンクレーブから API をトリガーすることで、EDR の監視を回避できます。これらの手法のメモリーアクセスはエンクレーブによって実行されるため、検出されないままの可能性があります。

ユーザー・モード・プロセスを「代わりに動作」させることで、エンクレーブは通常は不可能な方法でシステムに間接的にアクセスできます。たとえば、エンクレーブは、ファイルからの読み取り、ソケットの作成などを行う VTL0 ルーチンをトリガーすることができます。

ただし、この方法でユーザー・モード・コードを実行しても回避の面での利点はありません。コードは他のユーザー・モード・コードと同様に実行されるため、EDR に検出される可能性があります。

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

この脆弱性は、攻撃者に 2 つの機能を提供します（図 16）。

1. エンクレーブ内の任意の書き込み：攻撃者はSealSettingsを呼び出して任意のデータを暗号化し、次にUnsealSettingsを呼び出して、エンクレーブ内の宛先アドレスを指すことができます。これにより、元のデータがエンクレーブメモリーに書き込まれます。

2. エンクレーブ内の任意の読み取り：攻撃者は、送信元バッファーポインターとしてエンクレーブ内のアドレスを提供しながら、SealSettingsを呼び出すことができます。これにより、エンクレーブはエンクレーブメモリーからデータを暗号化し、攻撃者が制御する場所に書き込みます。攻撃者は、その後UnsealSettingsを呼び出してこのデータを復号化し、エンクレーブから任意のデータを読み取ることができます。

現在、エンクレーブは非常に限られた数のアプリケーションでのみ使用されています。より広く採用されるようになったとしても、任意のプロセスではなく、特定のプロセスによってのみロードされるでしょう。たとえば、calc.exe が VBS エンクレーブをロードすることはないでしょう。

このため、異常なエンクレーブを使用することで検知される可能性が大きく高まります。防御者は、VBS エンクレーブの既知の合法的な使用のベースラインを構築し、それからの逸脱をフラグすることで、これを活用する必要があります。エンクレーブの使用は、エンクレーブ API を監視し、ロードされたエンクレーブ DLL を検知するという 2 つの方法で識別できます。

次の API は、ホストプロセスによって VBS エンクレーブを管理するために使用され、ロードされていることを示している可能性があります。

• CreateEnclave
• LoadEnclaveImageW
• InitializeEnclave
• CallEnclave
• DeleteEnclave
• TerminateEnclave

エンクレーブの異常な使用を検知する別の方法としては、エンクレーブによって一般的に使用される環境 DLL（Vertdll.dll と ucrtbase_enclave.dll）のロードを検知する方法があります。これらの DLL はエンクレーブ以外では使用できないため、プロセスでエンクレーブが使用される可能性が高いことを示します。

VBS エンクレーブは、開発者がアプリケーションの機密性の高いセクションを保護するための優れたツールを提供しますが、これまでに示したように、脅威アクターがマルウェアを「保護」するために使用することもできます。この概念はほとんど理論上のものですが、将来、高度な脅威アクターが悪意のある目的で VBS エンクレーブを使用し始める可能性は確かに存在します。