EDRログ分析時に気を付けること

NTTセキュリティ・ジャパン SOCアナリスト 林です。

前回、ブログにて「EDRを使った分析の課題とSOCでの取り組みについて」を紹介させていただきました。今回は、EDRログを分析する際の注意点について紹介したいと思います。

SOCでは複数のEDR製品を取り扱っており、全てのアラートに対してこれは悪性な挙動なのか、正規挙動なのか、悪性な挙動だった場合にどういった挙動をしていたのかといった分析をしております。しかし、製品にはそれぞれ異なる仕様や特徴があり、それを知らないと誤った分析を行ってしまう可能性があります。そこで、今回はその中でも特に分析に影響が大きいものをピックアップして、紹介します。

1. アラート画面に表示されるプロセスツリー上のプロセス名が実際とは異なる

EDRでアラート画面を開くとアラートの対象となったプロセス情報が表示されます。そのプロセスIDから親プロセスや子プロセスといった情報が紐づけられてプロセスツリーが構成され、画面に表示されます。しかしながら、このプロセスIDはずっと固定ではありません。プロセスが終了すると、別のプロセスがそのプロセスIDを再利用します。そのため、プロセスIDに紐づけたプロセスツリー情報はしばしばおかしくなることがあります。

以下に実際にあった具体例を紹介します。

図１の左側は、EDRアラート画面に出てくるプロセスツリー、右側は実際に分析して判明したプロセスツリーです。左のEDRアラート画面のツリーを見るとブラウザ経由で何か不審なコマンドが実行されたと思ってしまいますが、実際には右側のよくあるマルウェアEmotet感染のツリーでした。

図 1　プロセスツリー情報の比較①

残念ながら、このような事象はしばしば起こります。それを解決するための対策は難しく、SOCのアナリストは分析する際に、アラート画面に出てきたツリー情報に不審な点があれば、rawログ使って確認していくことで誤った分析を可能なかぎり減らしています。

2. アラート画面に表示されるプロセスツリーが不完全

EDRアラート画面に表示されるプロセスツリーは、EDR製品が取得したプロセス起動ログからプロセスIDや起動時刻などから計算されて、画面に表示されます。この計算には時間がかかる場合があります。つまり、アラートを検知してすぐにその内容を確認するためにアラート画面に表示されるプロセスツリーを見ても、それはまだ計算中の不完全なツリーであるため、誤った判断をしてしまう可能性があります。

以下に実際にあった具体例を紹介します。

図２の左側は、アラート検知直後に確認したEDRアラート画面に出てくるプロセスツリー、右側はアラート検知から約30分後に確認したEDRアラート画面に出てくるプロセスツリーです。

左のアラート検知直後に確認したEDRアラート画面に出てくるプロセスツリーを見るとExcelファイルが開かれたくらいしかわかりませんが、実際に後で確認すると悪性なマクロ実行によりEmotetに感染してしまったと判断することができます。

図 2 プロセスツリー情報の比較②

SOCでは、1つのアラートに対して、分析を1次分析と2次分析という形で分けて対応しており1次分析で見えなかった部分を2次分析でフォローすることで上記のような事象に対処しています。

3. アラート画面に表示されるプロセスツリー上の情報が全てではない

EDRアラート画面に表示されるツリーや表示されているプロセスごとのファイルやレジストリ挙動は、簡単にどのような事象が起きたかを把握するためにとても便利です。しかしながら、その表示が全てではないことを念頭において、分析する必要があります。例えばファイル作成挙動でも実行ファイルの作成挙動はログとして収集されるが、正体が不明なファイル作成挙動はログとして収集されないなどです。製品仕様だけでなく単純にログが取りこぼされていたり、アラート画面では見えないが、rawログには作成ログがあるといった場合もあります。rawログをcsvなどでエクスポートすることで初めて表示される情報もあります。

以下に実際にあった具体例を紹介します。

図３の左側は、アラート画面に表示されたファイル作成挙動、右側は実際にホスト上で確認したファイル作成挙動です。左ではwordファイルを開いたときにマルウェアのローダーだけが作成されたと判断してしまいますが、右に示すように実際にはマルウェアのローダーだけでなく、マルウェアの本体のDLLファイルやマルウェアの設定ファイルも同じフォルダ上に作成されていたというものです。

図 3 ファイル作成挙動の比較

SOCでは、このような事象に対して、EDRログを見るときはなるべくrawログをエクスポートして確認する。マルウェアの挙動をサンドボックスや解析ブログなどと比較しながら分析することでなるべく判断ミスが起きないようにしています。

4. 通信ログの欠損

EDR製品の多くは通信関連のログが製品の仕様上、取得されてないことが多く見受けられます。例えば、UDPを利用した通信ログ、HTTPを利用したときのURI情報などが取得されていないなどです。しかしながら、それとは別にマルウェアのプロセスがC＆Cサーバーへ通信していたにもかからず、EDRのログを見ても通信した形跡がない場合がしばしばあります。このような事象が起こるとEDRログだけで判断するとマルウェアが動いているが、C&Cサーバーへの通信はProxyなどでブロックされたと判断してしまいがちですが、実際にProxyログを見ることでC&Cサーバーへの通信が成功していたということを確認することができます。

5. ログの検索結果がおかしい

EDR製品が取得しているログ数は膨大です。その中から見たいログを検索することがよくあると思います。そのためにEDR製品のコンソール画面にログインして、フリーワード で検索し、結果を取得して判断をすることがありますが、この検索結果がしばしばおかしくなる場合があります。例えば、マルウェアのファイル名を検索したときに、ファイルが実行されたログは検索結果に出力されたが、作成ログがないためどこから感染したのかわからない場合などです。この場合、SOCでは、対象ホストと確認したい時刻を指定した上で、全てのログをcsvなどでエクスポートした後に、そこで検索することでログ見逃しを可能な限り減らすといった対策を行っております。

今回は、EDRログ分析を行う際の注意点を5つ紹介しました。これらは、SOCで比較的多く確認され、かつ分析に大きく影響を与えてしまう可能性があります。どのEDR製品にも起こりうる可能性があり、製品側に原因があるものやログを見ているブラウザなどの利用している環境側に原因がある場合もあります。そういった問題になるべく影響を受けないで判断することができるように、EDRログ分析を行う皆さまのご参考にしていただければ幸いです。