Cybereason GSOC（Global Security Operations Center）では、影響力のある脅威に関する情報をお客様に提供するために、サイバーリーズン脅威分析レポートを発行しています。同レポートは、影響力のある脅威に関する情報をまとめた上で、それらの脅威から身を守るための実践的な推奨事項を提供するものです。

本レポートでは、Cybereason GSOCによるPlugXマルウェアファミリーの調査結果を示します。PlugXマルウェアファミリーは、APT27などのアジアのAPTグループがよく利用するモジュール型のリモートアクセスツール（RAT）/トロイの木馬です。このマルウェアはバックドア機能を備えており、多くの悪意ある「プラグイン」を通じて環境を完全に制御します。

また本レポートでは、PlugX Loaderの概要を紹介するほか、2012年から2022年までに観測された複数のサンプル（合計6つ）における変化を示します。

重要なポイント

• 3つのコンポーネントから構成されたマルウェア：このマルウェアは、キャンペーンごとに配布方法が異なる場合があります（配布フォーマットが自己解凍型であるかどうかなど）。しかし、PlugXローダーは常に、正規の実行ファイル、悪意のあるモジュール、そして悪意あるペイロードという3つの主要コンポーネントで構成されています。このマルウェアは10年以上前から存在していますが、マルウェアのフォーマットは変わっていません。
• セキュリティ回避に特化した手法：PlugX Loaderは、DLLサイドローディング手法を利用してセキュリティを回避することで知られています。しかし、このマルウェアは、さらなる回避手法を搭載しています。これにより、PlugXのペイロード配置成功確率が高まります。
• 検知と防止：Cybereason Defense プラットフォームは、PlugXマルウェアを効果的に検知した上で実行防止します。

はじめに

PlugXは、ポストエクスプロイト攻撃を行うモジュール型のRATであり、中でもデータ抜き取り、キーストローク取得、バックドアなどの多機能性で知られています。このマルウェアに関する最初の出版物や研究論文が発表されたのは、2012年にまでさかのぼります。

しかし、Trend Microによると、このマルウェアは、2008年から存在していたとのことです。PlugXは、2012年になってその名を広く知られるようになりましたが、実はアジア圏ではそれ以前に活発な活動を行っていたのです。

これは、PlugXマルウェアの作者が中国政府と関係があり、当時のマルウェアオペレーターがアジア諸国にいたことが原因だと考えられます。その後、このマルウェアは、過去10年以上にわたってアクティブな状態を維持しており、多くの脅威アクターにより利用され続けています。このマルウェアは、長年にわたって何度も更新されており、今後しばらくは消えてなくなることはなさそうです。

PlugXは、当初から主に政府機関や各種の政治団体などの公共部門に対して使用されてきました。さらに、高度な脅威アクターは、注目度の高い民間組織を標的にするためにこのマルウェアを多用しています。たとえば、2016年6月、日本の大手旅行代理店は、793万人のユーザーのプライバシーデータが流出したことを発表しましたが、その後、このデータ流出はPlugXの仕業であったことがTrellixにより確認されています。また、このマルウェアはアジア諸国以外でも活用されており、ベラルーシやロシアの軍事・航空宇宙関連企業を標的としていたことが確認されています。これは、PlugXのマルウェアオペレーターが市場や標的を拡大していることを示す指標であると考えられます。最近では、ロシア-ウクライナ紛争で発生したウクライナ人難民を支援するヨーロッパの政府機関を標的として、このマルウェアが使用されました。

Palo Alto NetworksのUnit 42によると、PlugX loaderは通常、フィッシングメール経由で配信されますが、ProxyLogonなどの脆弱性を突いて配信されることもあるようです。このマルウェアは、多くの場合、.zip、.rar、または自己解凍型RAR（SFX）のようなアーカイブ形式のファイルとして配信されます。

本マルウェアは、このようなアーカイブされたファイルフォーマットの内部に、次の3つの主要ファイルを含んでいます。

• 正規の実行可能ファイル
• 悪意あるモジュール
• 悪意あるペイロード

このマルウェアは、DLLサイドローディングという手法を用いてAcrobat ReaderやMicrosoftのバイナリのような正規の実行ファイルに悪意のあるDLLを読み込ませます。。DLLサイドローディングの利点は、マルウェアが悪意あるモジュールを読み込ませることにより、正規の実行ファイルを乗っ取り、偽装できることです。DLLサイドローディングを使うと、セキュリティツールを回避できるだけでなく、マルウェア開発者にとってPlugXペイロードを読み込ませる正規実行ファイルの選択肢が広がります。

▲図1：PlugXの感染フロー

DLLサイドローディングは、このマルウェアが備えている多くの回避方法のうちの1つであり、この分析ではその詳細について説明しています。

テクニカル分析

このテクニカル分析では、PlugX loaderの展開方法を取り上げます。特に「PlugX loaderの分析」のセクションでは、下記に示すサンプルのSHA-256を持つ 3つのファイルを取り上げます。これらのファイルは、2012年に書かれたこの記事で紹介されたものです。

このマルウェアはDLLサイドローディング手法を利用することで、正規の実行ファイル（Nv.exe）に悪意あるモジュール（NvSmartMax.dll）を読み込ませた後、実際のPlugXペイロードの準備のために、もう1つの悪意あるペイロード（Nv.mp3）を読み込ませます。

「比較分析」のセクションでは、異なるPlugX loaderのサンプルを比較することで、PlugX loaderの導入方法がいかに変化してきたかを示します。
 

PlugX Loaderの分析

このセクションでは、DLLサイドローダーとしてNv.exeを使用する場合のPlugX loaderの配置を説明します。このセクションは、PlugXペイロードがメモリにロードされるまでの流れを取り上げます。

▲図2：PlugX Loaderの概要

■OS日時のチェック
正規の実行ファイルNv.exeが最初に実行され、PlugX loaderのモジュールであるNvSmartMax.dllをサイドローディングすると、同モジュールはまずGetSystemTimeメソッドを使ってOSの日時をチェックし、下記の式を使って計算します。
Result =（（OS_Year * 100）+ OS_Month ）* 100 + OS_Date

この計算式の結果は16進数であり、この16進数の値が2012-01-01に相当する16進数値「0x1330225」と比較されます。この方法によりNvSmartMax.dllは、OSの日付と時刻が2012-01-01より後であるかどうかを確認できます。OSの日付と時刻が2012-01-01よりも前である場合、DLLの実行は終了します。このチェックは、マルウェアのリリースに関係し、正式リリース前の利用を禁止するための仕組みだと思われます。

▲図3：OS日時のチェック

■制御フローの操作
OSの日時が2012-01-01より後であることが確認されると、NvSmartMax.dllはNv.exeのEntryPointのアドレスを取得し、VirtualProtect関数を呼び出してEntryPointのページ保護機能を更新する処理を行います。NvSmartMax.dllは、Nv.exeのEntryPointのページ保護をPAGE_EXECUTE_READWRITEに更新し、EntryPoint変更の準備をします。

▲図4：PAGE_EXECUTE_READWRITE

NvSmartMax.dllモジュールは、NvSmartMax.dllのオフセット0x1020の関数にジャンプするように、EntryPointにパッチを適用します。このマルウェアは、静的解析を回避するための難読化手法として、制御フローの操作を利用しているように見えます。

▲図5：Nv.exeのEntryPoint（パッチ適用後）

制御フローがNv.exeのEntryPointに入ると、実行はNvSmartMax.dll内のパッチされたアドレスへとジャンプします。ターゲット関数において、マルウェアは下記のステップを試みることにより、Nv.mp3をロードする準備をします。

1. OSの日時を再度確認する。ただし、この確認では2012年であることを確認する。
2. マルウェアファイルを用意する。
3. メモリを割り当てる。
4. 割り当てたメモリにNv.mp3を読み込む。
5. ページ保護をPAGE_EXECUTE_READに更新する。
6. Nv.mp3にあるコードを実行する

▲図6：ペイロードのファイル名を準備する

▲図 7：ペイロード用のメモリを割り当て、同メモリにファイルを読み込む
 
■InInitializationOrderModuleList
制御フローがNv.mp3のメモリ領域にアクセスすると、その後、プロセス環境ブロック（PEB）内のInInitializationOrderModuleListから、ロードされたモジュール 「kernel32.dll」のベースアドレスを動的に取得します。

PEBは、オペレーティングシステム（OS）が内部で利用するプロセス情報を格納したデータ構造体です。PEBは、NtGlobalFlagチェックなど解析を回避する手法によく利用されますが、必要なモジュール情報を取得するためにも利用されます。PEBのオフセット0x0Cには、ロードされたモジュール情報を格納するPEB_LDR_DATA構造体が配置されています。この構造体は、InLoadOrderModuleList、InMemoryOrderModuleList、およびInInitializationOrderModuleListという3つのメンバーを持ちます。

▲図8：PEB_LDR_DATA からロードされたモジュールを取得

Nv.mp3内にあるコードは、ロードされた全てのモジュールを初期化順にリストしたInInitializationOrderModuleListを取得します。このリストには、実行ファイルそのものは含まれておらず、モジュール名のリストのみが含まれています。

▲図9：InitializationOrderModuleListのダイアグラム

Nv.mp3は、各モジュールBaseDllNameの中からkernel32.dllを検索し、特定するとそのモジュールのBaseAddressを取得します。
kernel32.dllのBaseAddressが取得されると、Nv.mp3は関数GetProcAddressのアドレスを取得し、関数LoadLibraryA、VirtualAlloc、VirtualFree、ExitThreadをStackString方式と思われる方式でロードします。

▲図10：StackStringライブラリ

kernel32.dllから関数のアドレスが全てロードされると、Nv.mp3は、前工程にて以前に関数GetProcAddressで取得した関数LoadLibraryAを使用して、モジュールntdll.dllをロードします。その後Nv.mp3は、ntdll.dllから関数RtlDecompressBufferおよびmemcpyをロードします。
Plugxペイロードの解凍
Nv.mp3に位置するコードは、ペイロード内のオフセット0x1529に保存されている117KBのRC4暗号化文字列の復号を進めます。復号された文字列はPEファイルの圧縮版であり、LZ解凍形式で関数RtlDecompressBufferを実行します。

▲図11：RtlDecompressBuffer関数のパラメータ

▲図12：解凍されたBuffer

解凍されたPEファイルはPlugXそのものですが、ここで、制御フローは解凍されたペイロードにすぐ移るわけではありません。Nv.mp3は”PLUG”の文字列を反転させた”GULP”シグネチャをのVirtualAllocがPAGE_EXECUTE_READWRITE保護で新しく割り当てたメモリに配置します。その後、Nv.mp3は関数memcpyを使って、各セクションの.text、.rdata、.data、.relocをあらかじめ確保されたメモリに割り当てます。
最後に、Nv.mp3は、解凍したPEファイルに記載されているimportテーブルからLoadLibraryAとGetProcAddressを使って、必要なライブラリや関数を動的にロードします。この準備が完了すると、Nv.mp3はPlugXペイロードのエントリポイントへと移動します。

▲図13：PlugXペイロードのヘッダー

■PlugX Loaderのフローチャート
下記のフローチャートは、PlugX Loaderの流れをまとめたものです。

▲図14：PlugX Loaderのフローチャート
 

比較分析

この比較分析では、下記の表に示す6つの検体を分析します。これらの検体は、過去に様々な報告書のあらゆる分析において観測されたものです。参照用に各検体（実行ファイル、モジュール、ペイロード）には、コードネームに接頭辞 px_を付け、外部情報源による観測された該当年を付加しています。

各サンプルは、PlugXローダーの構成と実装に基づいて比較されます。これには次の動作や特徴が含まれます。

• OS日時のチェックによりマルウェアのリリース日を制御する。
• アンチ分析を実現するために、実行ファイル内の命令にパッチを適用することにより、制御フローを操作する。
• PEB_LDR_DATA構造体を利用して、ペイロード内のモジュールkernel32.dllのベースアドレスを動的に取得する。
• アンチ分析（分析を困難にすること）を実現するために、ペイロード内のコードを難読化する。
• PlugXペイロードの解凍準備とペイロードのフォーマットを行う。

■OS日時
前節で説明したように、PlugXローダーはOSの日付が特定の値より後かどうかをチェックします。この動作は、6つのサンプルリストのうち、3つのサンプルで確認されています。

サンプルpx_2012とpx_2014では、日付と時刻のチェックが2回行われます。

1. 命令へのパッチ適用機能を実行する前に日付（date）をチェックする。
2. PlugXローダーのペイロードファイルを割り当てる前に、年（year）をチェックする。

一方、サンプルpx_2019では、2018年の日時チェックしか行いません。

また、このマルウェアにはバージョン管理が存在しているようで、px_2019の日付が2018年であるという日時の確認から、そのことが伺えます。
■制御フローの操作

サンプルでは、JMP命令によるパッチ適用により制御フローを操作していますが、サンプルpx_2019とpx_2022では、PUSH命令とRET命令でパッチを適用しています。PUSH命令は関連する関数のアドレスをスタックに「プッシュ」し、RET命令はプッシュされたアドレスに制御フローを移動させます。

サンプルpx_2014とpx_2021は、制御フローを操作するための命令にパッチを適用していません。これは、正規の実行ファイルから呼び出される、正規のDLLの正規のエクスポート関数名を利用します。

■PEB_LDR_DATA

サンプルpx_2021では、InitializationOrderModuleList以外に、InMemoryOrderModuleListを利用しています。InMemoryOrderModuleListは、ロードされたモジュールをメモリ上の配置に従ってリストします。InInitializationOrderModuleListとの違いは、InMemoryOrderModuleListが実行ファイルをリストに含んでいる点です。

■ペイロードの難読化

動的に読み込む必要がある関数におけるStackStringの利用は、すべてのサンプルを通じて一貫しているように見えます。しかし、px_2019、px_2021、px_2022では、1文字ずつStackに配置するように、若干ですが更新されています。

▲図15：VirtualProtectをフェッチ

サンプルpx_2014とpx_2015には、コードの難読化も追加されています。これは、PlugXペイロードを準備する関数に対する暗号化です。この関数は、このペイロードの主要コンポーネントであり、アンチ分析の追加レイヤーとなります。

▲図16：px_2015におけるコードの難読化

■解凍とペイロードの導入

PlugXペイロードの解凍は全サンプル間で一貫しており、LZ圧縮されたデータが復号されます。しかし、サンプルpx_2015とpx_2021の解凍されたペイロードは、完全なPEファイル形式ではありませんでした。これには従来のPEシグネチャが欠落しているため、「MZ…このプログラムはDOSモードでは実行できません（MZ…This program cannot be run in DOS mode）」のようなエラーメッセージが出力されます。ただし、PlugXローダーが新しいメモリ領域に必要なセクションを割り当てるために必要となる、関連するセクション情報はまだそのまま残っていました。
 
このアップデートでは、PEヘッダーの一部が削除されただけでした。しかし、このヘッダーには、コードが機能するために必要な情報が含まれていました。このアップデートが原因で、アナリストは、解凍されたペイロードをダンプし、さらなる解析を行うことができなくなりました。これは、当該ファイルが適切なPEフォーマットでないためです。
サンプルpx_2015、px_2021、px_2022は、解凍されたペイロードがPAGE_EXECUTE_READWRITEメモリ領域に割り当てられると、異なるヘッダーを持つようになりました。

• px_2015: XV – 15を表すローマ数字。
• px_2021: ROHT – “THOR”の逆さ読み。
• px_2022: .PE – Portable Executable（可搬的実行可能ファイル）の略。

ヘッダーの違いは、PlugXのバージョンアップの証拠でもあります。

■コアな導入方法は全サンプル間で一貫している
サンプルを比較すると、細部にわずかな違いがいくつかありますが、このマルウェアの導入方法については、過去10年間大きなアップデートはないようです。

大きなアップデートはありませんでしたが、このマルウェアローダーはバージョン管理されているようです。これは、OSの日時チェックや、実際のPlugXを導入する際のペイロードヘッダーの違いからも明らかです。

また、導入方法に関する大きなアップデートがないのは、DLLサイドローディング手法が使われているためだと思われます。DLLサイドローディング手法自体は、PlugXをサイドローディングする正規の実行ファイルに関して、脅威アクターにさまざまな選択肢を提供します。この回避手法は、すでにさまざまな組み合わせを生み出しているため、導入方法に関するアップデートは不要と判断されたのでしょう。
 

PlugXマルウェアの検知と実行防止

■Cybereason Defense プラットフォーム
Cybereason Defense プラットフォームを使うことで、多層的な防御を通じてPlugXによる感染を検知して実行防止できます。同プラットフォームは、マルウェアを検知してブロックするための、脅威インテリジェンス、機械学習（ML）、次世代アンチウイルス（NGAV）機能を完備しています。

▲図17：Cybereason Defense プラットフォーム は、脅威インテリジェンスに基づきMalOpを作成する
 
■Cybereason GSOC MDRの推奨事項
Cybereason GSOCは次のことを推奨しています。

• Cybereason NGAVのSignature(シグネチャ)モードとArtificial Intelligence（AI）モードの両方を有効にし、同機能の検知（Detect）モードと実行防止（Prevent）モードを有効にすること。
• 外部ソース（電子メールやWebブラウジングなど）から得たファイルの取り扱いに注意すること。
• Cybereasonで脅威ハンティングを行うこと。Cybereason MDRチームは、特定の脅威を検知するためのカスタムハンティングクエリをお客様に提供しています。Cybereason Defense プラットフォームを使った脅威ハンティングやCybereason MDRサービスの詳細については、こちらからお問い合わせください。

PlugXマルウェアの痕跡情報（IOC）

実行ファイル	SHA-256 hash: EAAA7899B37A3B04DCD02AD6D51E83E035BE535F129773621EF0F399A2A98EE3
	SHA-256 hash: 3D64E638F961B922398E2EFAF75504DA007E41EA979F213F8EB4F83E00EFEEBB
	SHA-256 hash: 4B23F8683E184757E8119C8C68063F547F194E1ABD758DCBD4DACF70E3908FC1
	SHA-256 hash: B2B93C7C4AC82623F74B14FE73F2C3F8E58E3306CC903C5AE71BC355CB5BD069
	SHA-256 hash: 96876D24284FF4E4155A78C043C8802421136AFBC202033BF5E80D1053E3833F
	SHA-256 hash: ACDC4987B74FDF7A32DFF87D56C43DF08CCE071B493858E3CE32FCF8D6372837
	SHA-256 hash: 9FB33E460CA1654FCC555A6F040288617D9E2EFE626F611B77522606C724B59B
	SHA-256 hash: 6914E9DE21F5CCE3F5C1457127122C13494ED82E6E2D95A8200A46BDB4CD7075
	SHA-256 hash: 9FFFB3894B008D5A54343CCF8395A47ACFE953394FFFE2C58550E444FF20EC47
	SHA-256 hash: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F
	SHA-256 hash: 6CD5079A69D9A68029E37F2680F44B7BA71C2B1EECF4894C2A8B293D5F768F10
	SHA-256 hash: 37B3FB9AA12277F355BBB334C82B41E4155836CF3A1B83E543CE53DA9D429E2F

 

MITREとの対応

実行	パーシステンス	防御回避	検出	収集	Command & Control（C2）
コマンドおよびスクリプティングインタプリタ	ブートまたはログオン時の自動起動実行	ファイルや情報の難読化解除/復号化	ファイルとディレクトリの検出	入力キャプチャ	アプリケーション層の制御
ネイティブAPI	システムプロセスの作成または改変	アーティファクトの隠蔽	ネットワーク共有の検出	画面キャプチャ	チャネルの暗号化
		乗っ取りの実行フロー	プロセスの検出		侵入ツールの転送
		マスカレーディング	クエリレジストリ		非アプリケーション層プロトコル
		レジストリの変更	システムネットワーク接続の検出		Webサービス
		ファイルや情報の難読化
		信頼されている開発者向けユーティリティのプロキシ実行
		仮想化/サンドボックスの回避

オペレーション中心のアプローチとは〜振る舞いの痕跡（IOB）を活用して早期検知と予測的対応を実現する〜

今日のセキュリティモデルでは、関連性のないアラートが無限に生成されます。その大半は誤検知であるか、より大きな攻撃シーケンスの一部に過ぎません。

このホワイトペーパーでは、早期検知のためのIOC（Indicators of Compromise）の価値の低下、IOCを表現するための拡張可能な共通言語の確立によるIOCの定義と運用、SolarWindsの攻撃に基づくIOB（Indicators of Behavior）の活用に関するケーススタディなどについて深く掘り下げて解説しています。
https://www.cybereason.co.jp/product-documents/white-paper/9109/