はじめに
難読化やパッキングなどの手法を使って、実行時にのみ本体を展開するマルウェアは、従来の静的解析だけでは中身を把握することが困難です。特に.NET系のマルウェアでは、ファイルレスで挙動するケースも多く、実際に動作させてメモリ上の情報を取得する手法が求められます。
そこで本記事では、実行中のプロセスからメモリダンプを取得し、マルウェアの本体を明らかにする動的解析手法について、実際の解析例を基に解説します。
マルウェア解析は専門的な技術を必要とする作業であり、適切な環境でのみ行うことを推奨します。誤った手法で解析を試みると、システムやデータに深刻な影響を及ぼす可能性があります。十分な準備と専門的なアドバイスを得た上で、マルウェア解析を行うことをお勧めします。
今回の解析で行うこと
- System Informerを用いたマルウェアのメモリダンプ取得
- Pe-bearを用いたPEファイルのセクションヘッダー修復
- DnSpyを用いたマルウェアのソースコード分析
解析で重要なポイント
- 動的に展開されるマルウェア本体をメモリから抽出する
- 難読化やパッキングによって静的解析を回避しているマルウェアは、実行時のプロセスメモリ上にしか復元済みの状態を持ちません。そのため、「どのタイミングで」「どのプロセスから」メモリを取得するかが、解析の成否を分ける重要なポイントとなります。
- ダンプファイルを実行可能な状態に整える
- メモリダンプから抽出した実行ファイルはそのままでは壊れていたり、不完全なことが多いため、PE-bearなどのツールでセクションヘッダーやエントリーポイントを修復する技術が求められます。この工程が正確でないと、後続の解析に支障が発生するため、重要なポイントとなります。
最終的な目標
実行中のプロセスからマルウェア本体をメモリダンプとして抽出し、必要な修復を加えた状態で、DnSpyを用いて.NETコードなどが正しく復元できているかを確認することを目指します。
解析するマルウェア
今回の解析対象であるマルウェア「AsyncRAT」は、リモートアクセス型トロイの木馬（RAT：Remote Access Trojan）の一種で、主にWindows環境を標的とした.NETベースのマルウェアです。本来は正規のオープンソース・リモート管理ツールとしてGitHub上で公開されていましたが、現在では悪用されるケースが非常に多く、セキュリティ分野においては典型的なRATの代表例として広く知られています。
ちなみに解析に用いるマルウェアはMalwareBazaarというマルウェアのサンプルを収集、共有、分析するためのオンラインプラットフォームからダウンロードしています。
【超超重要!!】今回解析するマルウェアは、実際に犯罪で使用されているものです。そのため、ダウンロードや実行を行う際は、必ずサンドボックス環境内で作業してください。また、この作業を行うことで発生したいかなる損害や問題についても、すべて自己責任で対処してください。
私の環境ではFLARE-VMを構築してます。
それでは、早速やっていきましょう！！
System Informerを用いたマルウェアのメモリダンプ
メモリダンプの取得には、System Informerというツールを使用して、実行中のマルウェアから、復元済み状態の実行ファイルをダンプします。
System Informerとは、Windows向けの高度なシステム監視ツールであり、もともとは「Process Hacker」として知られていたオープンソースプロジェクトから派生したものです。プロセスやサービス、ドライバ、ネットワーク接続など、システム全体の詳細な情報を表示・管理できる機能を備えています。
この先の作業ではマルウェアを動作させる必要があります。そのため、実行する際は 必ずサンドボックス環境内で行ってください。 安全な環境で解析を進めることで、感染や予期しない影響を防ぐことができます。
System Informerを実行した状態で、マルウェアを実行します。
上記のように、System Informerのプロセス一覧には、実行中のマルウェアが表示されます。
マルウェアを実行後、数秒待機すると、05c.exe という親プロセスから、aspnet_compiler.exe という子プロセスが生成されていることが確認できます。
このようなプロセスの生成や切り替え、親子関係の操作は、多くの高度なマルウェアに共通する特徴のひとつです。
そのため aspnet_compiler.exe プロセスに着目していきます。aspnet_compiler.exe プロセスをダブルクリックし、.NET assemblies タブを選択します。
すると、aspnet_compiler.exe プロセスでロードされている .NET モジュールの一覧が表示されます。
一覧を確認すると、System System.Core System.Xmlなどの標準的なアセンブリに加え、vik という不審なモジュールが読み込まれていることがわかります。
さらに、この vik モジュールの Native Image Path が不明であることから、メモリ上で動的に生成またはロードされている可能性が高く、ディスク上にファイルとしては存在しないと考えられます。
このような特性は、.NET 環境におけるファイルレスマルウェア（Fileless Malware）による攻撃の典型的な兆候といえます。
続いて、メモリにロードされているモジュールのベースアドレスを確認します。Modules タブを選択します。
上記のように、現在ロードされているすべてのモジュール（DLLやEXE）の詳細情報が一覧で表示されます。
aspnet_compiler.exe のベースアドレスは 0x400000 であることが確認できます。
WindowsのPE（Portable Executable）フォーマットにおいては、実行ファイルのデフォルトのロードアドレスが 0x400000 に設定されており、このアドレスから始まるメモリ領域には、実際にプロセスが実行しているコード本体が配置されています。
つまり、マルウェア解析を行う際には、この 0x400000 をベースアドレスとするモジュールをメモリダンプすることで、マルウェアの主要なコード部分を取得できる可能性が高いといえます。
このモジュールのメモリダンプをしていきます、Memory タブを選択します。
メモリダンプ（Memory Dump）とは、コンピュータのメインメモリ（RAM）の内容をそのままファイルとして出力・保存する処理やそのファイルのことを指します。
対象プロセスの仮想アドレス空間上にマップされている各メモリ領域（メモリブロック）の情報を一覧で表示されます。
ベースアドレスが 0x400000 のメモリ領域には、RWX（読み取り・書き込み・実行）属性が設定されており、読み書きおよび実行がすべて可能な状態であることが確認できます。
本来、この領域には RX（読み取り・実行）のみを許可するのが一般的であり、RWX のような属性はセキュリティ上のリスクを伴うため、通常の正規ソフトウェアではほとんど見られません。
特に、復元後のマルウェアにおいては、RWX 属性のメモリ領域に展開されるケースが多く確認されます。これは、自己展開型のパッカーや自己書き換え型コード、コードインジェクション、あるいは JIT コンパイルによって動的に生成されるシェルコード（JIT Shellcode）などが用いられる際に見られる挙動であり、マルウェア特有の不審な兆候として判断されるポイントの一つです。
この 0x400000 のメモリ領域を右クリックし、表示されるメニューから Save を選択します。保存時にはファイル名をわかりやすい名前に変更しておくとよいでしょう。
（例: dump_aspnet_compiler_0x400000.bin など)
先ほど保存したダンプファイルの中身を確認するために、DnSpyを使用します。
DnSpyを起動したら、ダンプファイルをウィンドウ内にドラッグ＆ドロップします。
上記のように、ダンプファイル phacker_0x40000.bin からはPEファイルが出力されていますが、本来表示されるはずのアセンブリ内の型（クラスや構造体など）は確認できません。
これは、.NETアセンブリとして正しく認識されるために必要なセクションヘッダーの情報が欠落しており、ツール上で正常に読み込むことができないためです。その結果、アセンブリ構造の解析が困難な状態となっています。
次は、セクションヘッダーを修復し、構造情報を整えていきます。
実行ファイルには、プログラムを構成するさまざまな要素が詰め込まれています。セクションヘッダーは、主にPE形式（Windowsバイナリ）やELF形式（Linuxバイナリ）などの実行ファイルに含まれる情報の一部であり、各セクションの内容や配置を管理する「目次」または「地図」のような役割を果たします。
Pe-bearを用いたセクションヘッダーの修復
セクションヘッダーの修復では、Pe-bearというツールを用いてマルウェアの実行ファイルを正しく解析可能な状態に整えます。
PE-bear（Portable Executable bear）とは、Windowsの実行ファイルフォーマットであるPEファイル（.exe、.dllなど）を可視化・解析するためのGUIツールです。主にマルウェア解析やバイナリの構造調査に活用されます。
PE-bearを起動したら、ダンプファイルをウィンドウ内にドラック&ドロップし、Section Hdrs タブを選択します。
上記のように、.text .rsrc .relocといった各セクションおよびそのアドレス情報が表示されます。
それぞれのセクションについて
-
.textセクション- 実行可能なコードが格納されている領域で、マルウェアの本体ともいえる部分です。オフセットやサイズ情報が不正だと、逆コンパイル時に関数が読み取れなくなります。
-
.rsrcセクション- アイコン、ダイアログ、文字列などのリソースが格納されている領域です。特に、難読化の手法としてここに暗号化された本体コードを埋め込んでおき、実行時に展開するケースが多く見られます。
-
.relocセクション- 実行時アドレスの再配置情報（Relocation Table）を保持する領域です。再配置が必要なPEファイルでこのセクションが不正または欠落していると、実行やロードに失敗する可能性があります。
さらに、左下の Raw グラフと右下の Virtual グラフは、PEファイルにおけるセクションの物理配置（ファイル上）と論理配置（メモリ上）を視覚的に示しています。
Raw (Raw Offse) は「ファイル上でこのセクションはどこにあるか、どれくらいのサイズか」を示します。
Virtual (Virtual Address) は「このセクションが実行時にメモリ上のどこに存在し、どのくらいの領域を占めるか」を示します。
通常の実行ファイルは、.text や .rsrc などの各セクションがディスク上ではファイル内のオフセット（Rawアドレス）に従って配置されており、それに対応するセクションヘッダーも整合しています。
一方、メモリダンプから得られる実行ファイルは、仮想アドレスに従ってセクションが並んでいるため、復元した際にセクションヘッダーの情報と一致しない場合があります。
ズレを修復するには、仮想アドレスに基づいて各セクションのファイルオフセットを再構築します。あるいは、仮想アドレスに合わせてセクションヘッダーを修復する方法もあります。
各セクションの仮想アドレスに合わせて各セクションの Raw アドレスを書き換えていきます。Raw Address 項目をクリックし、アドレスを入力します。
入力ができたら左側にある Section → .test → EP = xxx を右クリックし、表示されるメニューから Save を選択します。
セクションヘッダーの修復が完了したら、再びDnSpyを使用してダンプファイルの中身を確認します。
DnSpyを用いたマルウェアのソースコード分析
DnSpyを起動し、セクションヘッダーを修復したダンプファイルをウィンドウ内にドラッグ＆ドロップします。
セクションヘッダー修復前には表示されていなかったアセンブリ内の型（クラスや構造体など）や、System Informer の .NET assemblies タブで確認されていた vik モジュールが、修復後には正常に表示されるようになっていることが確認できます。
さらに vik.exe を右クリックし、表示されるメニューから Go To Entry Point を選択すると・・
サンドボックス回避を目的とした処理コードが記述されており、AsyncRATで頻繁に用いられる実装と非常に類似していることが確認できます。
まとめ
本記事では、マルウェア解析の一連の流れとして、System Informerを用いたメモリダンプの取得、PE-bearによるPEファイルのセクションヘッダー修復、そしてDnSpyによるマルウェアコードの分析手法をご紹介しました。
これらの解析ステップを通じて、難読化されたマルウェアの実態に迫り、その挙動や構造を明らかにすることが可能となります。特にメモリ上の挙動観察や手動によるPE構造修復は、一般的なアンチウイルスでは見抜けないマルウェアの本質を捉えるうえで極めて有効です。
今後のマルウェア解析やインシデント対応において、ぜひ参考にしていただければと思います！