Internet Infrastructure Review（IIR）Vol.46
2020年3月26日

2. フォーカス・リサーチ（1）

Windowsのメモリイメージ取得の注意点

2.1 Windowsにおけるメモリイメージ取得

本レポートVol.45では、Linuxにおけるフォレンジック向けメモリイメージ取得について解説しました（注1）。今回はWindowsのメモリイメージ取得について解説します。

Windowsでシステム全体のメモリイメージを取得するには、表-1にあるようなツールを使用します。取得したメモリイメージの解析には、Volatility Framework*（注2） やRekall Memory Forensic Framework（注3）を使用します。

表-1 メモリイメージ取得ツールの例

拡大する

しかし、Windowsのバージョンアップに伴い、セキュリティやシステムパフォーマンス向上のため、メモリ管理の仕組みが変更される場合があります。従って、メモリイメージの取得や解析に使用するツールも新しい仕様に合ったものを使う必要があります。本稿では、単にメモリイメージを取得するツールを紹介するのではなく、メモリイメージの取得時や解析時に注意すべき点について解説します。また、個々のプロセスダンプを確実に取得する方法も提案します。

2.2 メモリイメージ取得及び解析時の注意点

今回は、ページングファイル、メモリ圧縮、Virtual Secure Modeの3つの機能について、対応方法を解説します。ページングファイルはWindows 10より前のバージョンから存在していましたが、その他の機能は、Windows 10がリリースされた後のアップデートで追加された機能です。

ページングファイル

Windowsはページアウトするプロセスの仮想メモリのページを、C:¥pagefile.sysというページングファイルに保存します。図-1はWindows 10 1809のメモリイメージからVolatilityのprocdumpプラグインでnotepad.exeを抽出しようとした結果です。この時点ではnotepad.exeが起動直後であったため、プロセスのダンプに成功しています。一方、図-2は同じ環境でメモリ使用率が高くなった後のメモリイメージから、notepad.exeをダンプしようとした結果ですが、ページアウトによってプロセスダンプが失敗しています。なお、図-1、図-2で解析に使用したメモリイメージはVMware Workstationのメモリスナップショットです。本稿の執筆にあたり、ある程度意図した状態のメモリイメージを容易に取得するために使用しました。

拡大する

図-1 Volatility procdumpの成功例

拡大する

図-2 Volatility procdumpの失敗例

pagefile.sysを取得しても、メモリイメージ解析ツールが対応していなければ意味がありません。Rekallはメモリイメージとpagefile.sysを併せて透過的に1つのメモリイメージとして解析することができます。図-2の状態の直後に図-3のコマンドによりWinPmemでメモリイメージとpagefile.sysを取得し、Rekallのprocdumpプラグインを使って、それらのファイルからnotepad.exeをプロセスダンプすることができました（図-4）。ファイルの先頭部分を確認すると、MZヘッダであることが分かります（procdumpプラグインは指定したプロセスをPEフォーマットでダンプします）。

一方、Volatility 2は、Rekallのようにpagefile.sysを解析することはできません。しかし、現在開発中のVolatility 3に関するOSDFCon 2019での発表資料（注4）には、ページングファイルと後述するメモリ圧縮に対応することを示唆する記述があるため、今後はVolatilityでもページングファイルを使用した解析が可能になると思われます。

なお、図-3で使用したWinPmemはバージョン2.1 post4です。本稿執筆時（2020年2月）のWinPmemの最新バージョンは3.3 rc3ですが、これで生成したaff4ファイルをRekallで解析しようとすると、図-6のエラーが発生します。関連するソースコードをすべて調査したわけではありませんが、このエラーは、WinPmem 3.3 rc2以降の保存データのデフォルト圧縮フォーマットがdeflateに変更され、Rekallがそれに未対応であることが原因のようです（WinPmem 2.xのデフォルトはzlibでした）。WinPmemの「-c」オプションで圧縮フォーマットを指定できますが、zlibを指定しても同様のエラーで解析することはできませんでした。なお、WinPmem 3.3 rc1以前のWinPmem 3.xもzlibがデフォルトの圧縮フォーマットですが、これらのバージョンでページングファイルを含むaff4ファイルを生成し、Rekallで解析した場合、上記とは異なるエラーが発生します（ページングファイルを含まないaff4ファイルは解析できます）。

図-6 RekallはWinPmem 3.xで取得したaff4ファイルの解析時にエラーが発生する

従って、解析ツールとしてRekallを選択する場合、WinPmem 2.1 post4を使用する方が解析時に問題が起きにくいメモリイメージを作成することができます。しかし、WinPmem 2.xは開発が終了していること、Windows 10環境では強制終了してしまう場合があること、また、後述するVirtual Secure Modeに対応していないこともあり、使用はお勧めできません。なお、Rekallも2017年12月以降、新しいバージョンがリリースされておらず、事実上の開発停止状態にあります。

今後、VolatilityやRekallの開発が進めば、WinPmem 3.xで生成したaff4ファイルも解析できるようになることが期待できますので、それまではWinPmem 3.xでメモリイメージとページングファイルを取得し、図-7のようにエクスポートして解析するのがベターな対応でしょう。エクスポートしたメモリイメージはRAWフォーマットなので、VolatilityとRekallのどちらでも解析することができます。

図-7 WinPmem 3.xで作成したaff4ファイルからメモリイメージをエクスポート

メモリ圧縮

メモリ圧縮のデータが含まれたメモリイメージの解析には、当然ながら、それに対応した解析ツールが必要になります。残念ながら、現状のVolatility 2やRekallでは各OSのメモリ圧縮のデータを他のメモリページと併せて、透過的に解析することはできません。

しかし、FireEye社のOmar Sardar氏とDimiter Andonov氏がSANS DFIR Summit Austin 2019（注5）及びBlackHat USA 2019（注6）で、Windows 10のメモリ圧縮に対応したVolatility（注7）とRekall（注8）の実装を発表しました。

なお、両実装ともWindows 10 1607から1809までしかサポートしていませんので、Windows 10 1903以降のメモリイメージを解析することはできません。本稿執筆時点で、発表の成果が開発元のソースコードに取り込まれる様子はありませんが、上記したようにVolatilityは新しいバージョンで対応する予定があるようです。

図-9と図-10は、それぞれオリジナルのVolatilityとメモリ圧縮に対応したVolatilityのhashdumpプラグインの実行結果です。hashdumpプラグインはメモリに読み込まれたレジストリハイブから、ユーザのパスワードハッシュを取得します。ユーザパスワードのハッシュがメモリ圧縮に保存されているため、オリジナルのVolatilityでは実行結果に何も出力されていませんが、メモリ圧縮に対応したVolatilityではハッシュが出力されています。

図-9 オリジナルのVolatilityのhashdumpプラグインの実行結果

図-10 メモリ圧縮対応Volatilityのhashdumpプラグインの実行結果

Virtual Secure Mode

どのメモリイメージ解析ツールを使うべきか

ここまでに解説したメモリイメージ解析ツールが対応しているデータの種類を表-2にまとめました。この中で開発が継続されているのはVolatility 2のみであるため、基本的にこれを使用することをお勧めします。ただし、Windows 10 1809以前のメモリイメージを解析する場合は、メモリ圧縮対応版Volatilityを使用する方がよいでしょう。

ページングファイルも解析したい場合、Rekallを使う必要がありますが、開発が停止しており、また、WinPmem 3.xとの互換性の問題もあるため積極的に使う場面はあまりないと思われます。残念ながら、あらゆるケースに対応できるツールは現状ありません。しかし、Volatility 3がリリースされれば、この状況は改善されると思われます。

表-2 メモリイメージ解析ツール比較

拡大する

2.3 プロセスを確実にダンプする

ここまで、メモリイメージを取得する際の注意点とその対策を解説してきました。しかし、このような対策を行っても、整合性のとれたメモリイメージの取得は難しいのが現状です。解析対象ホストが仮想マシンであれば、スナップショットを取ることで、その時点の完全な状態のメモリイメージを取得することができます。しかし、ライブシステムのメモリイメージを取得する場合、その最中にも様々なプロセスが動作しているため、メモリ中のデータ変更やページアウトなどが発生します。このため、メモリイメージを解析しても、プロセスのメモリ内容の整合性がとれていない可能性があります。

図-12は図-1でダンプしたファイル（左側）と図-4でダンプしたファイル（右側）の.textセクションを比較しているところです。図-5で示したように、RekallでダンプしたファイルのMZヘッダは正しく抽出されましたが、両ファイルの.textセクションを比較するとRekallでダンプしたファイルではデータが0x00になってしまっていることが分かります（図-12の赤い領域）。上記のとおり、このような状態は致し方ないのですが、プロセスを解析する際に障害となる可能性があります。このような場合、ユーザランドよりプロセスを個別にダンプすることで整合性のとれたプロセスダンプを取得することができます（プロセスダンプの際にメモリアクセスが誘発されページアウトしているページがOSによりページインされるため、プロセスの仮想メモリのページをすべて取得することができます）。

プロセスダンプを行うためのツールはいくつかありますが、代表的なツールはWindows Sysinternals ProcDump（注9）です。VolatilityやRekallにも、同じ名前のプラグインがありますが、それらとは異なります。また、VolatilityとRekallのprocdumpはPEフォーマットのファイルを出力しますが、Sysinternals ProcDumpはクラッシュダンプフォーマットのファイルを出力します。

拡大する

図-12 プロセスダンプの差異

図-13のように実行すると、プロセスIDが4596のプロセスをダンプすることができます。プロセスIDの代わりにプロセス名を指定することもできます。また、プロセスが使用するすべてのメモリをダンプする「-ma」オプションも指定すると良いでしょう。生成されたクラッシュダンプはWinDbg（注10）（注11）などのツールで読み込むことが可能です。図-14は、図-4の後にProcDumpで生成したクラッシュダンプをWinDbgで読み込んだスクリーンショットです。Rekallのprocdumpで欠けていたコードも含まれていることが分かります（図-14中の赤枠）。このように、ProcDumpを使用すれば、確実にプロセスダンプできます。

図-13 ProcDumpコマンドでプロセスをダンプする

拡大する

図-14 WinDbgでプロセスダンプを確認

2.4 プロセスダンプのスクリプト化とアーティファクト保全の順番

PowerShellなどでスクリプトを作成すれば、容易にすべてのプロセスに対してProcDumpを実行することができます。ただし、すべてのプロセスをダンプすると数十GB以上の容量になります。データ保全先の容量に余裕がある場合は問題ありませんが、容量が小さなUSBメモリや外付けSSDに保全する場合はダンプを取得した後に7-Zip（注12）などで随時、圧縮を行う方が良いでしょう。また、ファイル圧縮時に一時ファイルが作られますので、それらが調査対象のディスクに書き込まれないよう、圧縮コマンドのオプションなどで指定する必要があります。7-Zipの場合、「-w」オプションで作業フォルダを指定できますので、アーティファクトを保全するディスクを指定すると良いでしょう。

ProcDumpを実行する際、SystemやRegistryなどの保護されたプロセスはスキップするようにします（プロセスダンプしようとしてもエラーになります）。また、このようなスクリプトは様々な環境で動作しなければならないため、WindowsにデフォルトでインストールされているPowerShellやバッチファイルで作成することが多いと思いますが、注意が必要な点があります。

PowerShlellのプロンプト（powershell.exe）やコマンドプロンプト（cmd.exe）を起動すると、コンソールウィンドウホスト（conhost.exe）も起動します。ProcDumpを実行するPowerShellスクリプトやバッチファイルを起動したプロンプトに対応するconhost.exeをダンプしようとすると、ProcDumpの処理が停止してしまいます。これは、ProcDumpがプロセスダンプを行う際、該当のプロセスをサスペンドさせることが原因です。conhost.exeはコンソールの入出力バッファや表示などを処理するプロセスであるため、このプロセスをサスペンドすることで、それを利用しているProcDumpも停止してしまいます（図-15）。必要であればWinPmemなどで取得したメモリイメージで、conhost.exeを解析することが可能です。

スクリプトを実行すると環境によっては数百回以上、プロセスダンプとファイル圧縮を行うことになります。従って、フォレンジックの観点から考えると、一例として、図-16の順番でアーティファクトの保全を図るのが良いと考えられます。

2.5 まとめ

今回はWindowsでメモリイメージの取得と解析を行う際の注意点を解説しました。また、メモリイメージ取得時の整合性を補完する観点でプロセスダンプにも触れました。メモリフォレンジック関連の記事では、WinPmemなどを使ってメモリイメージを取得することで保全を完了とするものが多いですが、それだけでは十分ではない場合があることを理解いただけたのではないかと思います。ただし、すべてのプロセスのダンプと圧縮には時間がかかりますので、インシデント対応時の状況やポリシーに応じて、実施の可否を検討する必要があります。

1. （注1）Internet Infrastructure Review（IIR） Vol.45 2章フォーカス・リサーチ Linuxのフォレンジック向けメモリイメージ取得（https://www.iij.ad.jp/dev/report/iir/045/02.html）。
2. （注2）The Volatility Foundation（https://www.volatilityfoundation.org/）。
3. （注3）Rekall Forensics（http://www.rekall-forensic.com/）。
4. （注4）Volatility 3 Public Beta: The Insider's Preview（https://www.osdfcon.org/events_2019/volatility-3-public-beta-the-insiders-preview/）。
5. （注5）SANS DFIR Summit 2019（https://www.sans.org/event/digital-forensics-summit-2019/summit-agenda）。
6. （注6）Paging All Windows Geeks ? Finding Evil in Windows 10 Compressed Memory（https://www.blackhat.com/us-19/briefings/schedule/#paging-all-windows-geeks--finding-evil-in-windows--compressed-memory-15582）。
7. （注7）win10_volatility（https://github.com/fireeye/win10_volatility）。
8. （注8）win10_rekall （https://github.com/fireeye/win10_rekall）。
9. （注9）ProcDump - Windows Sysinternals（https://docs.microsoft.com/en-us/sysinternals/downloads/procdump）。
10. （注10）Download Debugging Tools for Windows - WinDbg（https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools）。
11. （注11）Debugging Using WinDbg Preview（https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-using-windbg-preview）。
12. （注12）7-Zip（https://www.7-zip.org/）。

2. フォーカス・リサーチ（1） Windowsのメモリイメージ取得の注意点

• 2.1 Windowsにおけるメモリイメージ取得
• 2.2 メモリイメージ取得及び解析時の注意点
• 2.3 プロセスを確実にダンプする
• 2.4 プロセスダンプのスクリプト化とアーティファクト保全の順番
• 2.5 まとめ