Windowsログから見えてくること：Sysmonとイベントコードを活用した脅威ハンティング

Splunkのハンティングシリーズブログを読んでいただいていれば、多くの脅威ハンティング技法で使われるデータソースがネットワークに集中していることにお気づきかもしれません。実はまだ、あの「大物」ハンティングツールを取り上げていないのです。そう、皆さんご存じのMicrosoft Sysmonです。今こそSysmonについてお話ししましょう！

この記事では、Sysmonを使ってエンドポイントで脅威ハンティングを行う方法をご紹介します。Windowsログを使ったハンティングの出発点となる重要なイベントコードをいくつか取り上げます。すべてのイベントコードを網羅しているわけではありませんが、これらを覚えておけば仮説を立ててエンドポイントでハンティングを始めるには十分です。以下のように、盛りだくさんの記事となっています。

• Sysmonログがハンティングにおいて重要な理由
• 調査すべき一般的な(またはそれほど一般的でない)イベントコード
• 実践的なチュートリアル

(この記事は「Splunkで脅威ハンティング」シリーズの一部であり、初稿はJohn Stonerと共同執筆されました。お客様に最大限の価値を提供できるよう、その内容を最近更新しました。)

WindowsとSplunk

Splunkのセキュリティチームはエンドポイントデータの収集にはSysmonを愛用しています(Sysmonの使い勝手が良すぎて、手作業でセキュリティ運用をしていた時代に戻りたくなりそうなメンバーもいるくらいです)。 

Sysmonは常備ツールに加える価値が十分にあります。Sysmonイベントを収集すれば、世界が広がって、Windowsシステムが何をしているかが手に取るようにわかります！

SplunkでWindowsマシンを調査すると誰でも思うことですが、Windowsはちょっと「おしゃべり」です。でもSplunkなら、ユニバーサルフォワーダーを使ってイベントログを取り込めるだけでなく、Splunk Add-On for Microsoft Sysmonと組み合わせて以下の情報を収集できます。

• Sysmonデータ
• レジストリ情報
  
• パフォーマンス監視情報 

この柔軟性のおかげで、アナリストはさまざまな角度からハンティングができます。ではさっそくエンドポイントに移動し、Sysmonを使ってイベントコードを調べてみましょう。 

エンドポイント監視の重要性

エンドポイント監視のメリットについては、これまであちこちで紹介してきました。たとえば、James Brodskyが毎年.confでエンドポイントセキュリティについてあまりに熱く語るので、その話題に絞ったワークショップを開催したくらいです。そして、この「Splunkでハンティング」シリーズでは、Sysmonを取り上げます。さらに、Shannon Davisは、SplunkbaseからダウンロードできるPSTree for Splunkというツールを使ってSysmonプロセスの親子関係を調べる方法を紹介しています。

以上のことからわかるのは、エンドポイント監視は重要であるということです！Sysmonは便利です。特にイベントコード1(プロセスの作成)を監視すると、システム上で起動されたプログラムを把握できます。ここまではご理解いただけると思います。 

そうなると、次の疑問はこれでしょう。

Microsoft Sysmonとは何なのか？

Sysmonは「System monitor」の略で、検出のための技術です。セキュリティツールといえば脅威の阻止や防止もできるのが一般的ですが、Sysmonではそれはできません。しかし、何が起きているかを把握するという点において、Sysmonは非常に優秀でコスト効果の高いツールです(SysmonはMicrosoft社のWebサイトから直接ダウンロードできます)。

Mark Russinovich氏が率いるSysinternals社は、Windows用の優れたユーティリティやツールを数多く開発してきました。2014年に登場したSysmonは、同社がMicrosoft社に買収された後のSysinternalsチームによる成果です。Sysmonは、Windowsシステム上で何が起きているかを詳細に教えてくれます。たとえば、以下のことがわかります。

• プロセスの開始/終了日時
• プロセスを呼び出した親コマンド
  
• その他たくさん！

これだけでも魅力的ですが、ほかにも、ホストからのネットワーク接続やシステムのさまざまな状態など、Windowsイベントログだけではわからない詳しい情報が手に入ります。

効率的にハンティングを行うためのSysmonの設定

Sysmonの詳しい設定については本が1冊書けるくらいの説明が必要なので、ここでは脅威ハンティングに関係する設定に絞って説明します。ここまでの説明で、「ワークステーションがしていることをすべてログに記録しないといけないのか」と思っている人もいるでしょう。そういうことではありません。少しのチューニングでSysmonから重要な情報を引き出すことができます。 

まずすべきは、収集する情報を指定する監視テンプレートの設定です。こうしたテンプレートはすでに数多く公開されています。  まずお勧めなのが、GitHubからダウンロードできるSwiftOnSecurity氏によるSysmonテンプレートです。ぜひ活用してください。

「テンプレートは便利だけど、生成されるイベントが多すぎて大変そう。その場合はどうすればいい？」と思っている人もいるでしょう。 

そこで次にご紹介するのが、TransAlta社の事例です。TransAlta社は、.conf2017で講演を行い、Sysmonイベントをフィルタリングして、1日に生成されるログをワークステーション1台あたり10MBに抑えながら、有益な情報を獲得する方法を紹介してくれました(詳しくは、MP4形式のビデオまたはPDFをご覧ください)。

ご覧いただいたら、Sysmonについて詳しく見ていきましょう。

Windowsログでの脅威ハンティングで重要なイベントコード

最初に言っておきますが、Windowsが生成するデータの量は膨大です。うんざりするほどです。まずどこで何を探すべきかを決めておくことが重要です。この記事では、Windowsログでハンティングすべきイベントコードをすべて列挙することはしません(ここでは取り上げませんが、注意すべきイベントコードについてはRyan Kovarによるブログ記事「敵の存在を暴く」(英語)を参照してください)。 

ここで良いお知らせです。ハンティングと検出に役立つイベントコードについては、米国国家安全保障局(NSA)をはじめ、多くの機関、エキスパート、研究者が精力的に調べて公開してくれています。  攻撃者や攻撃ツールの中には、痕跡の検出が難しいものもあります。それでも、攻撃者がWindowsに侵入してWindowsネイティブのバイナリを悪用し始めると、こうしたイベントコードが想像以上に役立つことがあります。

Splunkbaseからダウンロードできる無料App、Windows Event Code Security Analysis for Splunkを使えば、上記の専門家が推奨するイベントコード(計13種類)をSplunkに取り込んで、ルックアップテーブルで表示できます。それを見れば、どの情報を収集し、どの情報を除外すべきかについて、賢明な判断ができます。 

専門家の大半が推奨するイベントコードは収集する価値があるでしょう。しかし、推奨する専門家が非常に少ない場合は、それほど重要でないかもしれません。

では、多くの専門家が推奨するイベントコードをいくつかご紹介します。これらは、ハンティングの出発点としてうってつけであり、脅威に関する仮説を立てるヒントになるはずです。

Windowsイベントコード4688：新しいプロセスの作成

最初に取り上げるイベントコードは4688です。最も重要なイベントコードと言っても過言ではないでしょう。Windowsのイベントコード4688は、新しいプロセスが作成されたことを示していますが、実際にはそれ以上の意味を持ち、ユーザーによって開始されたプロセス(またはプログラム)だけでなく別のプロセスから呼び出されて作成されたプロセスもすべてこのイベントIDで記録されます。 

たとえば、Windows PCがウイルスやマルウェアに感染したときは、イベントコード4688を探すと、そのマルウェアによって生成されたプロセスがわかります。ハンティングの観点では、「めったに実行されないプロセスが開始された場合は悪質なアクティビティの可能性がある」と仮定できるため、そのプロセスは調査対象になるでしょう。Splunkでは、次のように指定してWindowsデータをサーチします。

sourcetype="wineventlog:security"EventCode=4688
| stats count, values(Creator_Process_Name) as Creator_Process_Name by New_Process_Name
| table New_Process_Name, count, Creator_Process_Name
| sort count

このサーチでは、新しく作成されたプロセスとともに、その親プロセスのIDが返されます(親プロセスによって作成された場合)。なぜこの情報が重要なのかというと、同じ親プロセスによって作成された子プロセスには常に、生成元プロセスとしてその親プロセスのIDが記録されるためです。この情報は、作成された悪質なプロセスをすべて見つけ出して感染を除去するときに役立ちます。 

このサーチの結果をさらに絞り込むなら、以下の動作を示すプロセスを対象にするとよいでしょう。  

• 通常とは異なる場所から開始されている(C:\windows\system32やC:\Program Files以外)
  
• 特定のホストだけで動作している  

マシンでめったに実行されないプロセスを見つけることで、貴重な情報が得られます。

イベントコード4688を最大限に活用する方法については、こちらの記事(英語)をご覧ください。

イベントコード4738：ユーザーアカウントの変更

次にご紹介するイベントコードは4738です。これは私の個人的なお気に入りの1つで、ユーザーアカウントが変更されたことを示します。このイベントは、ユーザーアカウントに何らかの変更があると必ず記録され、特に、アカウントがドメイン内または個々のWindowsマシンで管理者権限を与えられている場合に重要です。 

私は、このイベントを追跡して、アカウント変更の前後2分間に何が起きたかを調べます。攻撃者(外部のハッカーまたは組織内の関係者)はよく、悪質な活動をする際に、ユーザーアカウントの権限を昇格させようとします。 

ヒント：サーチコマンドを角かっこで囲むと「サーチ内サーチ」を実行できます。これを使って、サーチ対象のイベントを「EventCode=4738」に絞り込み、コンテキストとして、その前後2分間に発生したイベントを追加することができます。

そのサーチ例を次に示します。

index=wineventlog
	[search index=wineventlog sourcetype=WinEventLog* EventCode=4738
	| eval earliest=_time-120
	| eval latest=_time+120
	| fields host, earliest, latest]
| table host, sourcetype, EventCode, Message

イベントコード4624：ログイン成功

イベントコード4624は、アカウントがWindows環境へのログインに成功したときに生成されます。この情報を使って、ユーザーがログインする日時や場所に関する基準を作成できます。 

Splunkでその基準を利用して、通常のログインから乖離した外れ値を監視すれば、悪質な侵入やアカウントの乗っ取りを検出できる可能性があります。また、イベントコード4624では、ネットワークやローカルなど、ログオンのタイプも記録されます。この情報を使用すれば、日時だけでなくログオンのタイプもフィルタリングの基準として、ネットワーク内での外れ値を検出できます。

そのサーチ例を次に示します。

sourcetype="wineventlog:security" EventCode=4624 
 | eventstats avg("_time") as avg stdev("_time") as stdev 
 | eval lowerBound=(avg-stdev*exact(2)), upperBound=(avg+stdev*exact(2))
 | eval isOutlier=if('_time' < lowerBound OR '_time' > upperBound, 1, 0)
 | table _time, isOutlier, body

このサーチでは、次の図のようなイベントリストが生成され、統計的に外れ値であるかどうかが示されます。

イベントコード1102：監査ログの消去

私は約30年間この仕事をしていますが、サービスのトラブルシューティングのためにWindowsマシンのイベントログを消去したことは1度しかないと記憶しています。イベントコード1102は、管理者または管理権限を持つアカウントがWindowsで監査ログを消去したときに生成されます。めったに起こることではないので、このイベントが発生したときは、陰で悪質なアクティビティが行われている可能性があります。 

このイベントをSIEM (つまりSplunk Enterprise Security)で「重大」イベントに指定することはすでに推奨していますが、ハンティングの対象にする価値もあります。重要な点として、WindowsサーバーをSplunkで監視していれば、イベントが消去されてもSplunkにすべてのログが保存されているため、心配無用です。

場合によっては重要なWindowsイベントコード

ここからは、「それほど重要でない」イベントコードを見ていきましょう。私はこれらを「B面」と呼びたいと思います。意味がわからないという方もいらっしゃるかもしれませんが、アルバムやカセットテープのB面にすばらしい曲、場合によってはA面を超える作品が入っていたりすることを憶えている方もいらっしゃるでしょう。実際、検出ルールでこれらのイベントコードの一部を使えば、作業をさらに自動化できることもあるのです！

この記事の執筆時点で、Sysmonのイベントコードは1～26まであります(エラーを示す255は除きます)。話が長くなるのでここでは一部のコードだけを取り上げますが、重要なのは、Sysmonイベントを最大限に活用するには事前の設定が必要であるという点です。詳細は省きますが、便利なテンプレート(SwiftOnSecurity氏が公開している設定)やSplunk Add-On for Microsoft Sysmonを使えば簡単です。 

イベントコード1：プロセスの作成

イベントコード1 (プロセスの作成)は、別のブログ記事で説明しているので詳細は省きますが、簡単に言うと、実行されているプロセスとその実行元を手掛かりにシステムで何が起きているかを確認したいときにまず調べるべきイベントです。重宝するコードなので、よく理解し、よく活用して、そのすばらしさを皆に伝えましょう。

イベントコード22：DNSクエリー

DNSクエリーの実行を示すWindowsイベントコード22は、特定のホストによって特定のイメージとともに実行されたDNSクエリーの大筋を理解するために非常に便利なイベントです。ここで言う「イメージ」は、プロセスとそのID、パス、GUIDを示すものと思ってください。イベントコード22では、クエリーと結果の両方が記録されます。 

次の例では、Bud StollのシステムでMicrosoft Edgeを使ってwww.blogger.comをルックアップし、その応答でIPアドレスを取得しています。この例のトラフィックは良性ですが、不審なホストでのイメージであれば、ドメインへのクエリーを調べることで有益な情報が得られる可能性があります。

source="xmlwineventlog:microsoft-windows-sysmon/operational"  EventCode=22 
EventDescription="DNS Query" host="bstoll-l" Image="C:\\Program Files 
(x86)\\Microsoft\\Edge\\Application\\msedge.exe" QueryName="www.blogger.com"

イベントコード23：アーカイブされたファイルの削除、イベントコード26：ファイルの削除

ファイルが削除されアーカイブされたことを示すイベントコード23は、攻撃者による破壊行為や証拠隠滅を検出するために役立ちます。ファイルが削除されログに記録されたことを示すイベントコード26も同様ですが、イベントコード23ではさらに、ファイルがアーカイブディレクトリに保存されます。これによりディレクトリのサイズが非常に大きくなる可能性があるため、有用性を維持したままサイズを抑えるように工夫して設定を行う必要があります。  

いずれにしても、イベントコード23と26を組み合わせることで、以下のようなプロセスの詳細がわかります。

• 削除されたファイル
• 操作が行われたホスト
  
• 削除日時

次の例では、Microsoft Excel内からExcelスプレッドシートへのリンクを削除しています。この操作は明らかに良性ですが、このイベントをサーチして悪質なアクティビティを探し出すこともできます。 

source="xmlwineventlog:microsoft-windows-sysmon/operational"  
EventDescription="File Delete archived" Image="C:\\Program Files (x86)\\Microsoft 
Office\\root\\Office16\\EXCEL.EXE"

イベントコード19～21

WMIイベントは、イベントコード19～21として記録され、フィルターやコンシューマーの作成を調べるために役立ちます。 

WMIは「Windows Management Interface」の略で、すべてのWindowsシステムで使用され、スクリプトで操作できます。そのため、攻撃者に悪用されやすい技術でもあります。実際、MITRE ATT&CKでは、Windows Management Instrumentationを攻撃技法として扱っています。

イベントコード17：パイプの作成

パイプの作成を示すイベントコード17は、ラテラルムーブメント(横展開)の検出に役立ちます。イメージ情報としてパイプ名も示されます(「イメージ」が何を指すかわかってきたでしょうか？)。 

パイプはWindows環境内で広く使われるため、このイベントコードだけでは悪質なアクティビティと断定できません。そのため、脅威ハンティングではさらなる調査が必要です。具体的には、現在のハンティングについてより詳しいコンテキストを提供する別のイベントを調べます。

イベントコード11：ファイルの作成

システム上で作成されたファイルを確認したい場合は、イベントコード11を調べるのが良い方法の1つです。監視するディレクトリやファイルタイプによってはこのイベントコードが大量に生成されるため、監視対象をよく考えて絞り込むことが大切です。このイベントでは以下のことがわかります。

• イメージ
  
• ターゲットファイルの名前と完全パス 

次の例では、setup.exeという名前のプロセスを実行した結果作成されたファイルとそのパスを調べています。

source="xmlwineventlog:microsoft-windows-sysmon/operational"  EventCode=11 
host=ghoppy-l process_name=setup.exe | table file_create_time file_path process_name host | sort _time

イベントコード13：レジストリ値の設定

最後にご紹介するのは、レジストリ値の設定を示すイベントコード13です。システム上で何らかのアクティビティが発生したときに、レジストリの設定が追加、削除、変更されることはよくあります。これらの操作が行われると大量のイベントが生成され、確認には手間がかかりますが、実行されたアクティビティに関する以下のような豊富な情報を入手できます。

• USBキーの挿入
  
• スケジュールされたタスク
  
• サービスの変更
• その他

ほかにも便利なSysmonイベントはたくさんありますが、イベントコードの話はこのくらいにしておきましょう。  

実践的なチュートリアル：Sysmonでの脅威ハンティング 

ではハンティングに出かけましょう！実際の環境を想定してSysmonで脅威ハンティングを行います。まずは、Sysmonで収集された情報を確認しましょう。 

これからご紹介するサーチをサンプルデータでお試しになりたい場合は、GitHubに用意されているBOTSv3データセットをご利用いただけます。ただし、以下のサーチはすべて、こちらから入手できるBOTSv1データセットを使ってテストされています。

ステップ1：データを収集する

次の例では、実行可能ファイル「3791.exe」がディレクトリ「c:\inetpub\wwwroot\joomla」から実行されたことがわかります。「EventDescription」フィールドの値である「プロセスの作成」イベントは、Sysmonで収集される多数のイベントの1つに過ぎませんが、このイベントは有用な情報の宝庫で、ハンティングに非常に役立ちます。 

イベントの情報を見ていくと、親コマンドラインを示すフィールド(ParentCommandLine)があることがわかります。その値は「cmd.exe /c "3791.exe 2>&1"」で、cmd.exeが3791.exeの親プロセスであることがわかります。

• この「プロセスの作成」イベントで収集される重要情報には、MD5、SHA1、SHA256、IMPHASHといったハッシュもあります。
  
• ほかにも重要な情報として、イベントの収集元ホスト、このプロセスと親プロセスのIDの収集元ディレクトリなどもあります。

Sysmonで収集された情報を確認したので、それらをハンティングで活用しましょう。

ステップ2：収集したデータをハンティングで活用する

ハンティングで、ワークステーション上に「121214.tmp」というファイルが見つかりました。このファイルの詳細を確認し、関連する他のプロセスがあるかどうかを調査する必要があります。まずは、次のようなシンプルなサーチを実行します。

index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational CommandLine=*121214.tmp* 

| table CommandLine

コマンドラインに「121214.tmp」が含まれるすべてのインスタンスが表示されます。ここから興味深い事実がいくつかわかります。たとえば、このプロセスが終了されたことや、cmd.exeの実行を受けて121214.tmpが実行されたことなどです。

ハンティングでは、実行されたコマンドだけでなく、そのコンテキストも調べることがよくあります。実行されたコマンドを確認し、それを親プロセスと関連付けて、実行されたプロセスとその前後に何があったかを調べるサーチは次のようになります。

index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational 121214.tmp CommandLine=* 
 | table _time CommandLine ProcessId ParentProcessId ParentCommandLine 
 | reverse
 | sort _time, ParentCommandLine

この場合、プロセスID (ProcessId)と親プロセスID (ParentProcessId)、および関連するコマンドライン(CommandLine)と親コマンドライン(ParentCommandLine)の値を調べ、それらを関連付けることで、ファイルを追跡できます。このステップをさらに進めて、親プロセスIDと一致する他のプロセスIDをサーチし、その関係を調査することもできます。

ここでは、実行された一連のプロセスから、121214.tmpはtaskkillコマンドによって終了され、ループバックアドレスにpingが実行されていることがわかります。さらに、121214.tmpが最初に登場する親コマンドラインはwscript.exeで、このプロセスはBob Smithのローミングプロファイルディレクトリから20429.vbsファイルを呼び出していることもわかります。  wscript.exeは正規のWindowsアプリケーションで、VBScriptファイルを実行するために使用されます。

ステップ3：ハンティングを調整する

Sysmonでこのログを記録しているため、サーチを変更して、親プロセスまたはプロセスのIDが3968のときのコマンドラインと親コマンドラインを調べるのも簡単です。

index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational (ProcessId=3968 OR ParentProcessId=3968) CommandLine=*
| table _time CommandLine ProcessId ParentProcessId ParentCommandLine
| reverse

これで、cmd.exeから直接実行されたVBScriptを確認できます。必要に応じて、さらに深堀りして調査していくことができます。

ステップ4：ハンティングを運用化する

最後のステップは、ハンティングの運用化です。同じ操作を繰り返してハンティングするのは時間と労力の無駄です(アインシュタイン博士が揶揄したように、同じことを繰り返し行って、違う結果を期待しますか？)。代わりに、良い方法が見つかったら、それを運用化して、インシデント対応チームにアラートを送信することをお勧めします。

前述の例でいうと、「異常に長い」と言ってよさそうなコマンドライン文字列を発見したので、今後、こうしたイベントが見つかったときはアラートを送信しましょう。このブログシリーズですでに詳しくご紹介したevalコマンドを使って、次のようなサーチを作成できます。

index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational CommandLine=*
| eval lenCL=len(CommandLine)
| where lenCL>1000
| table _time CommandLine ProcessId ParentProcessId ParentCommandLine lenCL
| sort - lenCL

このサーチでは、CommandLineフィールドの長さを計算し、1,000文字を超えるものだけを抽出しています。固定の値を使用する以外に、statsコマンドを使って標準偏差を割り出し、それを基準にすることもできます。返されたイベントをインシデント対応チームに送信して、調査および対応してもらうことができます。

Sysmonを始めましょう

Microsoft Sysmonでできることはほかにもまだたくさんありますが、この記事ではこのくらいにしておきましょう。ぜひSysmonをインストールしてハンティングでご活用ください。

Splunkはセキュリティチームをいつでも支援いたします。

このブログはこちらの英語ブログの翻訳、藤盛 秀憲によるレビューです。