活用編(検知ルールの設定 & 調査ダッシュボードの作成)
- 前々回の概要編はこちら
- 前回の導入編はこちら
- まずはSecurity EssentialからEDRログソース用の検知ルールを設定し、アラート発砲
- 検知後は、sysmonログを使った調査ダッシュボードを活用します
検知ルール(サーチ条件)の設定
- 今回、sysmon活用の検知ルールとしてこちらの記事のSecurity Essentailルール(異常に長いCLIコマンドの検索)を利用しますので下記参考の上、設定してみてください
- (本来であれば擬似的な攻撃ツールの利用方法を元に検知するのが望ましいですが、手法を載せるのは昨今の情勢上難しいため、ごめんなさい)
sysmonログを使った調査ダッシュボードを活用
- アラートを受け取ったら、「原因調査」と「影響範囲の確認」ダッシュボードを用意しましょう
- 少しでもビジュアライズをよくして見やすくするために以下Appをインストールします。
- Force Directed App For Splunk
- 参考ダッシュボードxmlはこちらにて公開
設定手順
ダッシュボードの使い方(TIPS)
- アラートメールを受け取ったら、ダッシュボードを開く。
-
時間、ホスト、プロセス名をセットしてEnter
- 期間は、アラート発生前の数時間とプロセス名は部分一致でいいので必ずセット。でないと検索が遅くなります。
「sysmon相関図v2」の使い方
- ボタンを押してもドリルダウンサーチはしません。俯瞰的にプロセスの親子関係、通信先を確認します。
- この例の場合
- 親プロセスがwscript.exeで子プロセスがpowershell.exe
- poweshell.exeが接続に行った通信先が192.168.246.xxxとfe80:~の3つであることがわかります
「不審なプロセスID(ProcessId)をクリック」の使い方
「Sysmonログによる影響範囲調査」の使い方
-
この例の場合、powershell実行の後に、systeminfoやtaskの作成などの横展開活動を行うコマンドが記録されていることがわかります。
まとめ
- sysmonを収集していると、不審なプロセスを検知し、プロセスの発生原因を特定できるケースがある
- 攻撃の手口の複雑さによっては、ここまでわかりやすく見えないケースも多々あると思います。
- とはいえ、専門EDR製品を買えない場合は無償のsysmonログをとっておくだけでも原因調査、影響調査に有効です。
おまけのTIPS集
- ダッシュボードパネル内のSPLにて環境依存で沢山でるプロセスがあればノイズフィルタすることを推奨します
例
NOT process=*amazon*exe NOT process=hogehoge.exe
- 転送されるトラフィックやデータサイズは?
- 1台のPCあたり5-10MB/dayです。世界では40万PCから収集しているユーザーもいるので、エンドポイントに大量のUFを配る方法や転送トラフィックの圧縮などいろいろなTIPSがありますが、詳しくはまたの機会に。
- sysmon以外にもwindowsから追加でログ収集したくなった
- 一度UFをPCに配っている人は、あとからいつでもログ収集の対象を増やすことが簡単です。powershell operationのログなども追加取得を推奨します。