15章

2 SRUMの解析

ネットワーク・アクティビティ調査の着眼点

サイバー攻撃によるインシデント対応では、発生原因・影響範囲・被害状況を把握するため、次のようなネットワーク・アクティビティの調査が重要になります。

• 不審なプロセスによる通信
  • 正規のインストールフォルダ以外から実行ファイルが起動されたプロセスによる通信
  • 業務内容からは考えにくい大量データのアウトバウンド通信
  • 永続化されたマルウェアとC&Cサーバーとの通信などによく見られる定期的な通信
• 正規プロセスによる異常な通信（量・時間帯）
  • PowerShell、CertUtil、BITSなど、侵入先の標準ツールを使った攻撃（LOLBas、LOLBin）による通信
  • Windows エクスプローラーなど、正規アプリケーションにインジェクションされた不正プロセスによる通信

これらがリアルタイムで行われている攻撃であれば、netstatコマンド、Wireshark等のパケットキャプチャツール、通信機器によるパケットキャプチャなどで、観測が可能でしょう。

一方、インシデント対応においては、検知した時点ですでに被害発生が顕在化しているなど、過去に行われた通信の調査が必要となるケースが多いことも現実です。特に、インシデントの発生原因を調査する場合には、過去のネットワーク・アクティビティが欠かせないもののひとつとなるでしょう。

ここでは、過去のネットワーク・アクティビティ調査にフォーカスし、昨今のデジタルフォレンジックにおいて活用されているWindowsのアーティファクト、SRUMを紹介します。

SRUM（System Resource Usage Monitor）の概要

Windows OSを対象としたデジタルフォレンジックのネットワーク・アクティビティ調査では、「SRUM（System Resource Usage Monitor）」と呼ばれるシステムの統計情報が活用されています。この機能は、Windows 8 以降のWindows OSに実装されています。

SRUMの統計情報は、タスクマネージャーの「アプリの履歴」タブに表示される、プロセスごとのCPU時間、ネットワーク通信量などの算出にも使われています。

• タスクマネージャー「アプリの履歴」表示例

タスクマネージャーに表示される情報は一部のアプリと統計情報のみですが、実際のSRUM データベースには多くの情報が記録されています。SRUMのデータベースは、ESEDB形式と呼ばれるMicrosoft社独自のフォーマットで記録されます。このデータベースは、次の単一のファイルに保存されています。

• C:\Windows\System32\sru\SRUDB.dat

SRUMデータベースに記録されるネットワーク・アクティビティは、一定時間ごとのプロセス別の通信量サマリーの形式で保存されています。これをパースしてリスト化することで、不審な通信を行っているプロセスの実行ファイルや、悪用されたWindows標準ツールの特定に有効です。また、侵害が確認された時間帯における外部への通信量を算出するなど、情報流出の有無や被害規模の推定に活用することができます。

SRUMによるネットワーク・アクティビティの調査方法

SRUMデータベースは、通常の論理コピー（コピー＆ペースト操作、copyコマンド等）による保全が可能ですが、操作ミスの抑止や完全性を担保するために、フォレンジック用保全ツールの使用を推奨します。SRUMはCDIR-Cでも保全対象になっており、収集したSRUMのアーティファクトは、保全フォルダ内の「SRUM」サブフォルダに保存されます。

• CDIR-Cによる保全例（「SRUM」サブフォルダ）

SRUMデータベースをパースするツールは複数存在します。CDIR-Aでは、SRUMのネットワーク・アクティビティにターゲットを絞ったパースツールである「NetworkUsageView（NirSoft）」をバンドルしています。

なお、NetworkUsageViewをライブフォレンジックで使用する場合には、稼働中のSRUMデータベースをパースすることが可能です。

次の図は、PC利用中に常時Google ChromeによるWebアクセスを行っていたPCから取得したSRUMのパース例です。パース結果からわかるように、ほぼ1時間ごとに送受信量のサマリー（Bytes Sent、Bytes Received）が記録されています。なお、この例では夜間帯（19:37以後、翌朝まで）のデータがありません。これは、システムがシャットダウンされていたり、システム稼働中であっても通信量がゼロだったためと考えられます。

• NetworkUsageViewによるSRUMネットワーク・アクティビティのパース例

  ※ 常時通信していたGoogle Chromeの統計情報を抽出

このように、SRUMのネットワーク・アクティビティはサマリー情報ですので、通信先の個別のホスト名やIPアドレスは記録されません。Windowsの標準機能においては、SRUM以外のアーティファクトをみても、過去の通信先情報が記録されている可能性はあまり期待できません。ファイアウォール、プロキシサーバ、各種通信制御装置や監視装置などの通信ログも併せて調査しましょう。

また、NetworkUsageView をCLIで実行することにより、パース結果をCSVファイルへ出力することができます（GUI画面からCSVへの保存も可能）。GUI上でパース結果の並べ替えや検索の機能も提供されていますが、インシデント調査の多くはSRUMのネットワーク・アクティビティをさまざまな切り口で分析する必要があります。提供されているGUIの機能では限界がありますので、パース結果はCSVファイルへ出力して分析することを推奨します。

• CLIでのCSVファイル出力例

NetworkUsageView.exe /LoadFrom 2 /ExternalFilename "(保全したSRUDB.datファイル)" /scomma "（出力するCSVファイル名）"

• 出力されたCSVファイルの例（アプリケーション名：BITS のみにフィルターし、タイムスタンプを昇順ソート）　

  ※一部の列（項目）の表示順は、デフォルトのものから変更しています

出力項目は次の通りです。

• Record ID: SRUDB.dat 内のレコード番号
• Timestamp : 集計対象日時 (分単位)
• App Name: アプリケーション/サービスの名前（Windows標準機能以外のアプリケーションは、実行ファイルのフルパスを表示）
• App Description: アプリケーション/サービスの説明
• Bytes Sent: 送信したバイト数
• Bytes Received: 受信したバイト数
• App ID: アプリケーションごとに割り当てられる一意のID
• User Name: SID に紐づくユーザ名 （ライブフォレンジック時のみ表示）
• User SID: 該当の SID 情報
• Network Adapter: データの送受信に用いられたネットワークアダプタ名 （ライブフォレンジック時のみ表示）
  

NetworkUsageView の具体的な使用方法は、後続のHands-on-2で紹介します。

なお、SRUMからネットワーク・アクティビティ以外の統計情報を含めてパースしたい場合は、SANS社インストラクターのMark Baggett氏が無償提供するパースツール「srumｰdump」を推奨します。

ネットワーク・アクティビティ分析の事例

実際に発生したインシデントにおいて、SRUMデータベースからパースしたネットワーク・アクティビティを分析した事例を紹介します（一部の情報はマスクしています）。

インシデントのタイムライン

• 20xx年9月3日 17:14:27
  • Maldoc（Word文書）を開いたことにより、PowerShellスクリプトが実行され、マルウェア「Emotet」がダウンロードされる。
    
• 20xx年9月3日 17:14:36
  • Emotetが、実行ファイル「C:\Users\（ユーザー名）\AppData\Local\framedyn\fsutil.exe」として永続化される。
    
• 時刻不明（上記に近接した時刻と考えられる）
  • Emotetにより、別のマルウェア「Zloader」がダウンロードされる。
  • Zloaderは、Windows正規プログラム「msiexec.exe」のプロセスに不正コードをインジェクトして、C&Cサーバーとの通信や情報窃取などの攻撃活動を開始する（Zloaderの実行ファイル自体は通信や攻撃活動を行わない）。

ネットワーク・アクティビティの分析

前述のインシデントにおいて、ネットワーク・アクティビティを分析する際の着眼点は次のようなものになるでしょう。

• PowerShellによる通信（Emotetのダウンロード）
• Emotet実行ファイル（fsutil.exe）による通信（Zloaderのダウンロード）
• 不正コードがインジェクトされたmsiexec.exeによる通信（C&Cサーバーとの通信、窃取情報送信）

実際にこのインシデントが発生したPCのSRUMデータベースをパースした結果（抜粋）は、次のとおりでした。

SRUMは、ほぼ1時間ごとのサマリーが記録されるので、17:11ころから18:11までの、約１時間における通信量サマリーとして分析を行います。

PowerShellについては、前後のデータをみても記録がなく、この時間帯のみ通信が発生していました。「Bytes Sent」よりも「Bytes Received」の通信量が圧倒的に多いため、「Emotet」実行ファイルのダウンロードを行った際のものと推定できます。さらに、「Byte Received」が3MB前後と、観測されているEmotetファイルサイズ（500KB前後）の数倍ですので、他のファイルもダウンロードされている可能性が考えられます。

Emotetの実行ファイルであるfsutil.exeの通信をみると、これも「Bytes Sent」より「Bytes Received」の通信量が多いため、ファイルのダウンロードが行われたと推定されます。発生当時に観測されていた攻撃キャンペーンの手口を考慮すると、EmotetがZloaderをダウンロードをしたものと考えられます。また、fsutil.exeのファイルパスをみると、ユーザープロファイルのAppDataフォルダ配下になっており、これはマルウェアが潜むフォルダの特徴の一つです。他にもこのようなファイルパスから起動されて通信している実行ファイルがないか、確認すべきでしょう。

Zloaderがインジェクトされた正規プログラムmsiexec.exeは、本来はコマンドプロンプトからアプリのインストーラ（.msi）を起動するものです。通常は使用頻度が低く、通信が発生する可能性もあまり考えられないため、明らかに不審な通信量です。実際、この前後の時間帯に通信を行った記録はありませんでした。「Bytes Sent」が約5MBになっており、相当量の情報が外部に送信された可能性があります。複数のファイルが圧縮されて送信されるケースも多いため、この間に作成された圧縮ファイルの有無などを、NTFSなどのアーティファクトから調査すべきでしょう。

（参考）株式会社ラック：分析レポート：Emotetの裏で動くバンキングマルウェア「Zloader」に注意

• https://www.lac.co.jp/lacwatch/people/20201106_002321.html

このように、SRUMデータベースのパース結果から、毎1時間内に起こった事象を推定できます。他のアーティファクトやログなどから取得したタイムスタンプ等との照合により、より深く精密に事案全体が把握できるでしょう。SRUMデータベースの保全とネットワーク・アクティビティ調査の有用性を理解した上で、インシデント対応の調査項目として必須化することを推奨します。