Windowsには、デフォルトでネットワーク履歴などを保存するアーティファクトがある。
表題のように、ネットワークリソースについてはもとより、そのほかにもいろいろな情報が保持されていて、フォレンジック調査において有用だ。
今回はこのアーティファクト「SRUM」について紹介してみる。
SRUMとは
SRUMの概要
Windowsのリソースに関する履歴を保存するアーティファクトのこと。
ここでいうリソースとは、
- ネットワーク
- HDD
- CPU
- 電源
などをいう。
SRUMアーティファクト自体はdatファイルとなっており、ESE形式のデータベース。
このファイル内に各リソースごとのテーブルがあるというスタイルになっている。
ただ、一度ESEのViewerで見てみるとよくわかるが、テーブル名が謎のGUIDとなっており（GUID自体は解読されているものの）なんだか調査しづらいので、解析時にはツールでパースするのがオススメ。
SRUMから何がわかるのか
SRUMからは多くのことがわかる。
代表として以下のものがある。
- ネットワーク経由での送信バイト数、受信バイト数、接続時間、使用したネットワークインターフェース
- アプリケーションの起動時間や起動したユーザ
- バックグラウンドでの読み込み・書き込みバイト数
- フォアグラウンドでの読み込み・書き込みバイト数
- 使用電力
- プッシュ通知の日時や通知種別
このほかにもあるので、実際に触ってみると面白いかもしれない。
SRUMの活用方法
SRUMの解析では、上に挙げた情報をプロセス毎に抽出できる。（電力だけは無理）
そのため、実際のインシデントレスポンスでは
- 不審プロセスによる外部通信の量はどのくらいか
- 読込みや書き込みが以上に多いプロセスはないか
- バックグラウンドで大量に情報を読み込んだプロセスがないか
といった観点から調査を行うこともできる。（とはいっても実際にやるとこれはかなり大変だが）
これだけ聞くと、「素晴らしいアーティファクトじゃないか！」となるが、１点だけ残念なことがある。
結構ザックリしているのだ。
どういうことかというと、このDBはプロセスの活動があるたびに更新されるものではなく、一定時間情報を取りためて後からまるごとコミットする方式をとっていることが原因となっている。
このコミット方式により、DB内に記録される発生日時は、通信や読み書きが発生した時間ではなく、DBにコミットされた時間になってしまうのだ。（だいたい20～30分おき、長いと1時間おきにコミット）
さらに追い打ちをかけるように、通信量など定量的データは１つのデータ列としてまとめコミットされるという欠点もある。
えっどういうこと？となるかもしれないので、具体例を挙げてみる。
例えば、13:30～14:00に10回に分けてそれぞれ10KBを送信したプロセスがあり、14:05にDBにコミットしたとする。
これがまとめコミットにより、DB上では「14:05に10KB送信した」となってしまうのだ。
これでは、一定時間内の通信総量を把握することはできるが、個別の通信の状況までは追うことはできない。
ということ。
こういうところちょっと使いづらかったりする。
とはいえ、EDRが入っていなかったりプロキシがないなど、後から通信を追跡できない環境であった場合、限定的であっても通信データがわかるというのは、調査においてはものすごい価値がある。
こんな感じなので、SRUMはなんというか、致命的な弱点を持った超優秀アーティファクトのようなイメージか。
アーティファクトの保存場所
SRUMのdatファイルは以下のパスにある。
C:\Windows\System32\SRU\SRUDB.datまた、解析には追加でレジストリのSoftwareハイブを使用することがある。
Softwareハイブには、ネットワークインターフェースの情報が含まれているためである。
SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\ExtensionsNetworkUsageViewでの解析方法
NetworkUsageViewの概要
これはNirsoftが提供しているフリーツール。
端末上で実行するだけで、SRUMとSoftwareハイブを組み合わせて解析してくれるので楽ちん。
セキュリティベンダーの提供するツールなので信頼性も高い。
ツールのインストール方法
窓の社で配信されている。
下のリンクからダウンロードできる。
ダウンロードが完了すれば、後は実行するだけ。
特別な環境づくりも必要ない。
解析の実施
多くの人はとりあえず実行して以下のように怒られることだろう。
実行には管理者権限が必要なので、再実行する。
管理者権限で実行するとすぐに解析結果が表示される。
上の画面から右のほうにスクロールしていくと、送受信バイトなどがでてくる。
どうでもいいが、項目をダブルクリックすればこういう結果画面がでる。
Nirsoftはなぜかこういうスタイルがお好きのよう。
NetworkUsageViewについてはこのくらいで。
SrumECmdでの解析方法
SrumECmdの概要
皆さんお待ちかね！
サイバーセキュリティ業界で知らぬ者のいない有名ディベロッパー「Eric Zimmerman」。
SrumECmdはEric製のツール。
コマンドラインで実行するスタイルだが、使い勝手もよく、情報量も多い。
ツールのインストール方法
いつものこのサイトからダウンロードする。
exe形式のツールなので、特に環境づくりは必要ない。
解析の実施
ダウンロードした後は、コマンドプロンプト（管理者権限）から実行する。
-dオプションでSRUMのデフォルトディレクトリを指定。さらに–csvで出力先を指定。
今回は省略したが、大事なものとして-rオプションがあり、これはSoftwareハイブを指定する。
ちょっと検証不足だが、おそらくDirtyハイブでは正確性が下がるので、LogをマージしてCleanにする必要があるのだろう。
とはいっても、ネットワークインターフェースの情報(L2Profileなど）の調査が不要であれば、わざわざハイブを整える手間をかける必要もない。
解析が完了すると、指定したフォルダにcsvファイルができている。
これらのうち、「NetworkUsages」を開いてみると以下のように、実行履歴などがわかる。右のほうには実行ユーザが載っている。
そして、右のほうにスライドさせると、送受信データ量がわかる。これがSRUMのミソデータのひとつとなってくる。
また、「AppResourceuseInfo」を開くとこのようになっている。
そして、右にスライドすると、バックグラウンド・フォアグラウンドごとのHDDリソース使用量がある。
残りのcsvについては紙面文字数の都合から割愛。
興味があればお手元でやってみてくだされ。
SrumECmdの解析実施例については以上。
解析おまけ：ブラウザから送信したデータのSRUMへの反映確認
本当はもっときちんと調査すべきだろうが、本当にSRUMにリソースが載るのか簡易検証してみた。
まず、以下のようなテキストファイルを用意。中身はAがたくさん入っているだけ。
サイズは40MB程度。
そしてEdgeを起動し、どっとうｐろだ.orgにアップロード。
ちなみにEdgeは普段全く使っておらず、この日はこれが初起動。
アップロード以外の操作は行っていない。
おおよそ１時間後、NetworkUsageViewを起動すると、Edgeでの通信が記録されているのを確認。
右のほうにスクロールすると、40MB超の送信バイト数が記録されている。
サイズがかなり大きいので、オーバーヘッドが増えたのかな。
（このあたりはいずれ検証しても面白そう）
というように、ブラウザからのファイルを送信した場合、ちゃんとSRUMに記録されている。
SRUMに関する個人的感想
アーティファクトの有用性
SRUMは、事業会社のセキュリティ担当にとってけっこう有用なアーティファクトになる。
そういう組織の多くでは、インシデントレスポンスの目的が情報漏洩有無の確認になっていて、その判断基準に「送信データ量」を用いているところも多い。
SRUMは（時間があいまいという難点はあるが）、それなりの精度で送受信量を記録してくれているので、そういった判断基準と非常にマッチするアーティファクトだ。
EDRを導入している組織で、アーティファクトを解析ラボまで安全に吸い上げられる機能が備わっていれば、調査手順に加えることを考えてもいいかもしれない。（とはいっても、EDR製品の機能で解析できるのならそれでいいが）
どちらのツールを使って解析するか
上で紹介したNetworkUsageViewとSrumECmdについてだが、個人的にはSrumECmdを推したい。
NetworkUsageViewはライブでの使用時にアーティファクトの自動収集を行ってくれるというメリットがあるが、どうも表示される情報量が少なく、やはり解析結果の網羅性という点でSrumECmdのほうが優れている。
もちろん、フォレンジック調査の背景や目的によって必要な情報量は変わるのでNetworkUsageviewで事足ることもあるだろうが、基本的に大は小をかねている。
SrumECmdのほうがいろいろとありがたい。
あと、紹介した２つ意外にも有名なものとしてSRUM_DUMPという人気ツールがある。
扱いやすいインターフェース、高機能なアウトプット、ライブフォレンジックであれば全自動で解析完了などと優れた特徴を持っているので、いずれ気が向いたら紹介するかもしれない。
まとめ
今回はSRUMの解析について書いた。
データ送受信量を保存するアーティファクトなので、EDRを導入していない組織にとっては重宝するかもしれない。
コメント