インシデント発生時に電源を入れたままにすべきか問題

はじめに

とあるセキュリティインシデントにおいて、サーバを電源ケーブルごと引き抜いたという対応が行われ、X（Twitter）ではこの対応について賛否両論が見られました。このうち電源を入れたままにすべきという人の意見には、「マルウェアの中にはシャットダウンすることで自分自身を削除し、感染痕跡を削除するものがある」「メモリを調査すべきなのでシャットダウンすべきではない」のような意見が見られました。

本記事では実際にメモリからどのような情報がわかるか、そしてメモリダンプを解析することの有用性と課題について記載します。

メモリフォレンジック

セキュリティインシデントにおいてはフォレンジック調査が行われる場合があります。フォレンジック調査には、HDDやSSDのようなストレージを調査対象とするディスクフォレンジック、パケットキャプチャやNetFlow、ProxyやFWのログのような通信を対象とするネットワークフォレンジック、そして今回取り上げるメモリフォレンジックがあります。

一般的にメモリフォレンジックは他の調査手法では調査が難しいプロセスやネットワーク接続の状態を調査することが可能です。

メモリフォレンジックの流れ

メモリフォレンジックも他の調査手法と基本的には変わりません。データを保全し、そのデータを調査します。メモリの場合はメモリダンプを行い、専用のツールで調査するのが一般的です。

Windowsのメモリフォレンジック

メモリダンプの方法

過去にFTK Imagerを用いた詳細な手順を記載していますので、こちらをご参照ください。他にもDumpITやRam Captureというツールもあります。どちらも簡単な操作でメモリダンプを取得できます。

なお、仮想マシンの場合はサスペンドすることでVolatility3で調査可能なメモリダンプを取得することができます。VMwareの場合、.vmssと.vmemの2つのファイルが必要です。

メモリダンプの調査

本記事ではVolatility3を使います。

使用方法は一例として以下のような記事で紹介されています。

また以下の書籍もあります。こちらは大変よくまとまっておりおすすめです。

ではディスクフォレンジックでは確認が難しい痕跡の例を見ていきましょう。

プロセスの親子関係を表示するwindows.pstreeの実行例が以下です。

また、終了したプロセスも表示できるpsscanもあります。psscanの場合、マルウェアによって通常のプロセス一覧には表示されないプロセス¹も確認できます。

そしてネットワーク接続の状態を確認することも可能です。この出力はnetstatコマンドの結果と似ていますが、PIDやプロセス名まで出力されるのが特徴です。

他にもハンドルや特権の表示やメモリダンプからファイルを取り出すなどの操作が可能です。さらにマルウェアによってコードインジェクションされたプロセスを確認するmalfind²もあります。これらはディスクフォレンジックで調査することができなかったり、困難だったりする情報です。メモリが取得できるのであれば取得した方が良いでしょう。

Linuxのメモリフォレンジック

Linuxのメモリダンプ

LiMEを使うことでメモリダンプを取得可能です。ただしLiMEは現在積極的にメンテナンスされていないとのことでした。仮想マシンであればサスペンドで代替できます。

必要なパッケージを追加した後、LiMEをmakeします。

apt install linux-headers-6.1.0-21-amd64 gcc
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src/
make

本検証ではmakeまで成功していますが、insmodコマンドが成功せず、解決できなかったため、仮想マシンのサスペンドにより代替しています。

# insmod lime-6.1.0-21-amd64.ko "test.mem format=mem format=lime"
insmod: ERROR: could not insert module lime-6.1.0-21-amd64.ko: Invalid parameters

Linuxのメモリ調査

以下のIIJさんのリンクにもあるとおり、Voalatility3ではカーネルバージョンごとにプロファイルを作成する必要があります。この点が非常にやっかいで、調査対象が数台であればともかく、数十台になるとプロファイルを作成するのが困難になります。

今回はDebianを新規にインストールしたものを使用してプロファイルを作成、メモリダンプの調査を行います。

デバッグシンボルが含まれるカーネルをダウンロードします。必ず調査対象のカーネルバージョンと一致するものを指定します。

apt install linux-image-6.1.0-21-amd64-dbg

上記ファイルは以下に保存されます。
/usr/lib/debug/vmlinux-6.1.0-21-amd64

dwarf2jsonのビルドを行うためにgolangをインストールします。

apt install golang

私の環境ではgitがインストールされていなかったため、インストールします。

apt install git

ソースコードをダウンロードしてコンパイルします。

git clone https://github.com/volatilityfoundation/dwarf2json.git
cd dwarf2json
go build

これでdwarf2jsonが使えるようになりました。

デバッグカーネルを元にプロファイルを作成します。この作業には私の環境（仮想マシンのメモリを16GB、CPUコア数を8まで増やした状態）で2分程度かかりました。

./dwarf2json linux --elf /usr/lib/debug/vmlinux-6.1.0-21-amd64 > output.json

作成したJSONファイルをVolatility3の-sオプションで指定します。
私の場合は仮想マシンのサスペンドファイルと同じフォルダに置いているため、「.」を指定しています。

vol -s . -f Debian-1fbfd5c7.vmem linux.pslist

以下の通りプロセスの一覧が表示できました。

残念ながらlinux.pstreeは私の環境では動作しませんでした。
Windowsではnetscanだったネットワーク接続の表示はlinux.sockstatになります。

また、Windowsと同様にmalfindも利用可能です。ただし私の環境ではコードインジェクションされたプロセスがないのか、表示されませんでした。

メモリを取得することの有用性と課題

ここまで検証したとおり、メモリを取得することで様々な情報が取得でき、セキュリティインシデントの原因や影響の調査に役立つことが期待できます。一方で、メモリはその性質上、長期間データが保存されず、シャットダウンや再起動によって簡単にデータが消失します。仮にシャットダウンや再起動が行われなかったとしても、プロセスの終了によってもデータが消失する可能性があります。このためセキュリティインシデント発覚後、できるだけ早期に取得することが望ましいと言えます。

最初に述べた電源を入れたままにすべきかどうかについては、メモリを取得できるなら取得した方が良く、その場合はより多くの情報が得られる可能性があるといえます。またメモリにしか存在しないマルウェア（ファイルレスマルウェア）もあります。
ではメモリがないとセキュリティインシデントの調査ができないかというとそんなことはありません。フォレンジック調査というのはそもそも不完全なデータを元に調査することが多く、個人的な経験からもメモリダンプがないと手も足も出ないというケースはほぼありません。そもそも調査開始時点でシャットダウンされているというケースは非常に多いです。

ここまでフォレンジック調査の観点から述べてきましたが、インシデントレスポンスという観点で考えた時に、電源を切るという選択肢は決して間違っていないとも思います。ランサムウェアがすでに動作しているというケースでは、すべてのファイルが暗号化される前に電源を落としてしまうことで一部のデータを守るという判断はあり得ます。（気づいたときには手遅れというケースも多いですが）
また、攻撃者がまだ攻撃を継続しているという場合は、通常であればネットワークを切断して締め出すことが可能ですが、電源を落とすことで証拠隠滅をさせないという判断もあり得ます。

まとめ

本記事ではメモリダンプからどのような情報が得られるかについて述べました。
また、電源を入れたままにすべきか、それとも電源を落とすべきかについては以下の点を考慮する必要があると考えられます。どちらも一長一短であり、セキュリティインシデントの内容、状況、ビジネスへの影響などを総合的に考慮する必要があると考えます。
・電源を入れたままメモリダンプを取得することにより、より多くの情報が得られ、セキュリティインシデントの調査に有用となる可能性がある
・メモリダンプの取得は可能な限り早急に行った方が良い
・電源を落とすことにより、ランサムウェアによる暗号化を途中で止められる可能性がある
・電源を落とすことにより、攻撃者による証拠隠滅を防げる可能性がある
・メモリダンプがなくてもフォレンジック調査は十分可能である
※上記考慮点は一例であり、状況次第で他にも考えられます。

1. DKOMと呼ばれる手法がルートキットによって使われる。
   https://en.wikipedia.org/wiki/Direct_kernel_object_manipulation ↩

2. malfindという名前からマルウェアを探す機能と誤解されがちだが、正確にはコードインジェクションされたプロセスの表示です。正規のプログラムでもコードインジェクションされる場合があるため、malfindで表示されるプログラムがすべてマルウェアによって侵害されているわけではありません。またたびたび誤検知も発生します。 ↩