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

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

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

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

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

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

さらに、 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 にロードされた専用ライブラリからインポートされます。たとえば、通常のプロセスは OS にサービスを要求する際に ntdll.dll ライブラリを使用しますが、エンクレーブモジュールは vertdll.dll を使用します。これは、syscalls を介してセキュアカーネルと通信するために使用される「代替」 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 の脆弱性を利用することができます。この一例は、Alex Ionescu 氏（Winsider Seminars&Solutions 在籍）が発見した CVE-2024-49706でした。これにより、攻撃者は署名されていないモジュールをエンクレーブにロードできます。この脆弱性は Microsoft によって修正されましたが、将来的に、意欲的な攻撃者が同様のバグを発見する可能性があります。

もう 1 つの簡単なアプローチは、正当な署名を取得することです。これは、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

異常なエンクレーブの使用を検知するもう 1 つのオプションは、それらによって一般的に使用される環境 DLL（ Vertdll.dll と ucrtbase_enclave.dllにエクスポートされます。これらの DLL はエンクレーブ以外では使用できないため、プロセスでエンクレーブが使用される可能性が高いことを示します。

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