@port139 Blog

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

プログラムの通信履歴を残す

皆さんの組織では、マルウェア感染したWindows PCが(組織内の)何処と通信したか?、を追跡できるログを取っていますでしょうか?

先日のプログラム実行履歴についてTwitterで呟いたところ「次のトピックはSysmonですねw」と Haruyama さんから突っ込みをいただいたので、Sysmon を利用したプログラムの通信履歴保存についてです(笑)

プログラムの実行履歴はWindowsの監査機能を利用する事でセキュリティログに記録する事ができますが、プログラムが何処と通信したかは記録されていません。

いわゆる標的型攻撃、APT攻撃と呼ばれる攻撃では、マルウェア感染した機器を踏み台として、組織内の広い範囲への侵入や情報の搾取が行われます。

この為、被害範囲が広がっているのかを確認するには、マルウェア感染した端末が、何処と通信を行っていたのか?が重要な手がかりになります。

プログラムが何処と通信したかがログに記録されていれば、被害範囲を特定する時間やコストを小さくする事が出来るはずです。(被害範囲を迅速に特定できれば、復旧にかかる時間を短くする事ができ、全体コストを抑えられます)

プログラムの通信履歴を残す方法は幾つか案があるかと思われますが、マイクロソフト社が提供しているSysmon を利用すると比較的簡単にイベントログに通信履歴を残す事ができます。

Sysmon v3.0
https://technet.microsoft.com/ja-jp/sysinternals/dn798348

Sysmon を利用すると、プロセスの実行履歴、ドライバのロード時にデジタル署名とハッシュ値を記録する、ネットワーク通信の記録などが可能になります。

プロセスの実行履歴、ファイル作成日時の変更、ドライバロードに関する記録なども残せますが、これら全てを記録していくとログが膨大になり、正直ノイズだらけになります。

 ノイズが多いログは、調査時に“時間とコスト増加”の原因になります。不要なログは取得しないのが一番です。断捨離が必要になりますので、Sysmonの設定ファイルを利用して、ネットワークの通信履歴以外は取得しないようにフィルタします。

まずは、Sysmonのインストールを行います。コマンドラインから操作する必要がありますが、以下のコマンドを実行します。

Sysmon.exe -i -n

ライセンスの確認ダイアログが表示されますので、確認してください。

インストール時に -n オプションを指定することで、ネットワークのログも取られるようになります。(後から設定ファイルでも変更できます)

現在の状況を確認するには、以下のコマンドを実行します。「Network connection: enabled」となっていることを確認できます。

>Sysmon.exe -c

Sysinternals Sysmon v3.00 - System activity monitor
Copyright (C) 2014-2015 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Current configuration:
- Service name: Sysmon
- Driver name: SysmonDrv
- HashingAlgorithms: SHA1
- Network connection: enabled
- Image loading: disabled

No rules installed

 

この状態でどの様なログが出力されるかは、イベントビューアで確認する事ができます。

イベントビューアを起動し、「アプリケーションとサービス ログ」を開きます。新たな項目として、Microsoft⇒Windows⇒Sysmon があるはずです。

 

次に、設定ファイルを作成します。例えば、ネットワークの履歴だけ取得する場合には以下のような設定ファイルを作成します。(Hostnameの部分はインストールするコンピュータのホスト名を記入しておきます)

<Sysmon schemaversion="2.0">
<HashAlgorithms>md5</HashAlgorithms>
<EventFiltering>
<ProcessCreate onmatch="include" />
<ProcessTerminate onmatch="include" />
<FileCreateTime onmatch="include" />
<ImageLoad onmatch="include" />
<CreateRemoteThread onmatch="include" />
<DriverLoad onmatch="include" />
<NetworkConnect onmatch="include">
<SourceHostname>Hostname</SourceHostname>
<DestinationHostname>Hostname</DestinationHostname>
</NetworkConnect>
</EventFiltering>
</Sysmon>

この設定ファイルを作成しておき、-c オプションの引数として指定します。(インデントがうまくいけてないのと、Webから貼り付けるとうまくいかないケースがあるかもしれません)

>Sysmon.exe -c sysmon_conf.xml

Sysinternals Sysmon v3.00 - System activity monitor
Copyright (C) 2014-2015 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Loading configuration file with schema version 2.00
Configuration file successfully applied
Configuration updated.

 設定ファイルが有効になっているかは以下のコマンドで確認できます。

>Sysmon.exe -c

Sysinternals Sysmon v3.00 - System activity monitor
Copyright (C) 2014-2015 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Current configuration:
- Service name: Sysmon
- Driver name: SysmonDrv
- HashingAlgorithms: MD5
- Network connection: enabled
- Image loading: disabled

Rule configuration (version 1.00):
- ProcessCreate onmnatch: include
- ProcessTerminate onmnatch: include
- FileCreateTime onmnatch: include
- ImageLoad onmnatch: include
- CreateRemoteThread onmnatch: include
- DriverLoad onmnatch: include
- NetworkConnect onmnatch: include
SourceHostname filter: is value: 'Hostname'
DestinationHostname filter: is value: 'Hostname'

 この設定ファイルの例では、ネットワークの項目で Include を指定し、SourceHostname か DestinationHostname のいずれかが自分宛てである場合にログを残すようにしています。

ただ、これでもまだノイズとなるレコードは出ると思いますので、更にフィルタできると良いのですが、Include で IS NOT を併用しても手元ではうまくフィルタできませんでした。

この例では Include をデフォルト指定にしていますが、Exclude をデフォルトにして、ノイズを落とすような条件を設定する方が結果的には良い場合もあるかと思います。

特に定期的に127.0.0.1 宛ての通信が出るなど、無駄なレコードがある場合には Exclude として条件を構築した方がすっきりする印象があります。

最後に忘れずに、sysmon のログサイズを増やしてください。デフォルトでは 65536 KB になっているかと思いますが、環境によっては全然足りないかと思います。

手元のPCでは、5MB/day という感じですので、 一ヶ月約150MB、3カ月程度は遡れるようにしたいとすれば450MB~500MBにサイズを増やしておく必要があります。

クライアントPCであれば500MB程度を消費してもそれほど空き領域を圧迫するということは無いと思われます。

逆にサーバで通信の履歴を取得するのはかなり困難が予想されますので、事前にテストしてから判断いただく必要があると思われます。

サーバ側では、ファイルへのアクセス履歴などを検討した方が標的型攻撃による被害を想定した場合には現実的かもしれません。プロセスの通信履歴を残したとしても、その通信でどのファイルをC&Cへ送ったのか?という事は追跡できませんので、どの様なファイルにアクセスしたか、流出した可能性があるのか?を追跡するには、別途ファイルアクセスの履歴が残されている必要があります。

 

<お願い>

皆さんのご協力があって、目標金額に達したようです!!ありがとうございました!!