メモリフォレンジックCTF「MemLabs」Lab2のWriteUp: NECセキュリティブログ

Tweet
Share

2020年7月10日

NEC サイバーセキュリティ戦略本部セキュリティ技術センターの山﨑です。前回の記事[1]では、メモリフォレンジックに特化したCTFであるMemLabs new window [2] Lab1のWriteUpを書きました。掲載から数ヶ月経った後も、記事を参考にしながらチャレンジしてくれた方もいたようです。今回はLab2（レベル：Easy、flag：3つ）です。山﨑調べでは、Lab2のWriteUpはインターネットを探しても見つかりませんでした。途中で挫折した方も、これから始める方も、ぜひ本記事を参考にチャレンジしてみてください。

1. 初動調査

今回も、Kali linux上でオープンソースのメモリフォレンジックツールであるvolatilityを使います。はじめに初動調査として、解析を進めるために必要なメモリダンプのプロファイル特定、詳細な調査の必要がある箇所を列挙するために行ったことを記載します。

1.1. プロファイルの特定

メモリのレイアウトはプロファイル（OSの種類、bit、バージョンなど）によって異なるため、正しい解析を行うために、対象のメモリダンプが取得されたプロファイルを特定するところから始めます。以下のコマンドで出力された結果から、[Suggested Profile(s)]行を確認します。

# volatility -f MemoryDump_Lab2.raw imageinfo

この行には、メモリダンプを取得したプロファイルの候補が表示されます。候補はいくつかありますが、以降の解析は一番左の”Win7SP1x64”として進めます。

1.2. 起動プロセスの調査

メモリダンプ取得時に動いていたプロセスを確認するためにpstreeプラグインを使います。プロセスの親子関係はPid（Process id）、PPid（Parent Process id）からでも判断できますが、pstreeプラグインの出力はName列にある「.」の数で視覚的にプロセスの親子関係を確認することができます。

# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 pstree

Windowsの標準プロセス以外だと、cmd.exe、chrome.exe、KeePass.exe、notepad.exeが気になります。

1.3. プロセスを起動したコマンドラインの調査

各プロセスがどのようなコマンドラインで起動したかを確認するためにcmdlineプラグインを使用します。

# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 cmdline

KeePass.exeがHidden.kdbxにアクセスしています。名前からして怪しいです。

2. Flag発見までの流れと周辺知識

次に、3つのflagを発見した流れと、その周辺知識について記載します。前回同様Flag獲得の直前までの流れです（解き方は一例として捉えて下さい）。

2.1. 一つ目のflag発見までの流れ

ここでは、KeePass.exe（Pid：3008）に着目します。初動調査で発見したHidden.kdbxファイルの取得を目指します。まずはHidden.kdbxファイルの物理オフセットを特定するためにfilescanプラグインを使用します。

# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 filescan | grep Hidden.kdbx

Hidden.kdbxが存在する物理オフセットが0x000000003fb112a0と特定できました。dumpfilesプラグインでファイルを取得します。-Dオプションで保存先のディレクトリ（今回はカレントディレクトリ）、-Qオプションで物理オフセットを指定しています。

# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 dumpfiles -D . -Q 0x000000003fb112a0

分かりやすくするため、取得したファイルをリネーム後（file.None.0xfffffa8001593ba0.dat→ Hidden.kdbx）、別途インストールしたKeepass2でこのファイルを開いてみますが、Master Passwordが求められ、先へ進めません。

# keepass2 Hidden.kdbx

Lab1では、memdumpプラグインを使用してプロセスのメモリダンプを取得し、そのダンプデータに対する可読可能文字列の調査からパスワードのヒントが埋め込まれていたことを思い出しました。同様に、KeePass.exe（Pid：3008）のメモリダンプを取得し、可読可能文字列からパスワード取得のヒントとなる情報を探してみます。

# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 memdump -p 3008 -D .

# strings 3008.dmp | grep -i pass

”Password.png”という怪しいファイルが見つかりました。filescan、dumpfilesプラグインでこのファイルを抽出し、ファイルを開いてみます。

# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 filescan | grep Password.png
# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 dumpfiles -D . -Q 0x000000003fce1c70
# mv file.None.0xfffffa8000d06e10.dat Password.png
# eog Password.png

ファイルを開くと、右下の方に小さくパスワードが書かれていました。
このパスワードを使ってHidden.kdbxの中に入ると、[Recycle Bin]の中に”Flag”というユーザが見つかります。UI上では確認できませんが、右クリック→[Copy Password]を選択することで2つ目のflagが取得できました。

2.2. 二つ目のflag発見までの流れ

chrome.exe（Pid：2296）に着目します。chrome.exeはGoogle Chromeブラウザのプロセスです。ブラウザを使ってどこかにアクセスしていたことが予想できます。Chromeにはユーザのブックマークや拡張機能、サイト毎に保存しているパスワードなど、様々な情報が保存されているフォルダがあります。そのフォルダ内にある、Historyという名前のデータベースファイルにはユーザのアクセス履歴などが保存されています。アクセス履歴からflag獲得のヒントが得られることを期待し、Historyファイルを取得します。

# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 filescan | grep History
# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 dumpfiles -D . -Q 0x000000003fcfb1d0

2つのファイル（.datと.vacb）が取得できましたが、データ本体は拡張子がdatの方です。取得したファイルをリネームします。ファイルタイプもSQLiteのファイルであることが確認できます。

# mv file.None.0xfffffa8000efd1d0.dat History
# file History

データベースファイルにアクセスし、テーブル名を確認後、urlsテーブルからデータの抽出を行います。

# sqlite3 History
sqlite> .table
sqlite> select * from urls;

Facebook（7行目）や本CTF作者のブログ（8、9行目）へのアクセス履歴が確認できます。32行目を見ると、オンラインストレージサービスのMEGAの履歴が残っています。ここにアクセスしてみると、Important.zipというファイルが見つかりました。

ダウンロード後、解凍を試みるもパスワードが求められます。出力結果の[Comment]を見ると、パスワードはLab1の3つ目のflagのSHA1ハッシュ値とのことです。（Lab1に取り組んだことがない方は、前回記事[1]を参照してください。）

# 7z x Important.zip

Lab1のflagのSHA1ハッシュ値を出します。

# echo –n “flag{Lab1_3つ目の_flag}”

echoコマンドはデフォルトで改行を出力するため、文字列のハッシュ値を求めるためには改行を含めない-nオプションを指定する必要があります。”6045”で始まるハッシュ値がzipファイルのパスワードです。解凍したファイルを開くとflagゲットです。

（参考）Google Chromeのユーザデータフォルダについて

上述のとおり、Google Chromeにはユーザのブックマークや拡張機能、サイト毎に保存しているパスワードなど様々な情報が保存されているフォルダがあります。Windowsの場合は以下のフォルダです。

C:¥Users¥ユーザ名¥AppData¥Local¥Google¥Chrome¥User Data¥Default

Googleアカウントでログインしてブラウザを使用している方は、別端末でも同一のアカウントでログインすることで各種設定が同期できます。一方、Googleアカウントでログインせず使用している場合は、このDefaultフォルダを別端末の同じ場所にコピーすることで同じ設定でブラウザを使用することができます。このフォルダのバックアップを取っておけば、稀にある（筆者は1度経験した）Chromeのブックマーク喪失が起きても復旧可能です。

サイバー攻撃に絡めてみると、ターゲット端末への侵入に成功した攻撃者は、ユーザの趣味・嗜好を調べるためにブラウザのアクセス履歴などを調べる可能性があります。それだけではなく、このような情報をソーシャルエンジニアリングに活用されることも考えられます。攻撃フレームワークの一つであるmetasploit-frameworkでは、ブラウザの履歴を取得するモジュールも存在します new window [3]。

2.3. 三つ目のflag発見までの流れ

初動調査が不十分だったのか、どのプロセスに着目してもflagにたどり着けなかったため、コマンドリファレンス new window [4]で紹介されているプラグインを片っ端から実行しました（非効率でしたが、様々なvolatilityのプラグインを知ることができました）。プロセスの環境変数を表示するenvarsプラグインを使用した結果、flagが見つかりました。

# volatility -f MemoryDump_Lab2.raw --profile=Win7SP1x64 envars

“NEW_TMP”という名前の環境変数の値に、base64エンコードされた文字列があります。これをデコードすると、一つ目のflagがゲットできます。

（参考）プロセス毎の環境変数確認方法

Windowsで環境変数を調べる方法は私が把握している限り、以下の3つがあります。

[システムのプロパティ]→[環境変数]より確認
”set”コマンド（コマンドプロンプト）
”Get-ChildItem env:”コマンド（PowerShell）

上記のいずれの方法を使って分かることは、ユーザ環境変数、システム環境変数の一覧で、プロセスの環境変数は分かりません。プロセス毎の環境変数を知るためには、Windowsの場合、Windows SysinternalsのProcess Explorer new window [5]が利用できます。
※Process Explorerの使い方：調査したいプロセスで右クリック→[Properties]→[Environment]

Linuxの場合では、以下にPid毎のプロセス情報が格納されています。
・/proc/<Pid>/

各Pid配下にある、environからプロセスの環境変数が確認できます。Webサイトやyoutubeなどにも参考になる情報がありますので、詳細はそちらを参照してください。

3. おわりに

MemLabs Lab2のWriteUpを書きました。CTFは単に問題を解くだけでなく、それに関連・派生した内容をさらに調査することで周辺知識の獲得につながります。今回、”（参考）”として記載した内容の一部は、flag取得後に個人的に調査した内容です。このような調査の積み重ねが知識・スキルの幅を広げていくきっかけになると考えています。