2021年3月5日

NECサイバーセキュリティ戦略本部セキュリティ技術センターのmuu(ハンドルネーム)です。
今回は、セキュリティインシデントの調査におけるログの解析方法について学ぶことができる”Log Analysis Training”(https://jpcertcc.github.io/log-analysis-training/)のハンズオンから、「プロキシログの調査」を紹介します。

Log Analysis Trainingとは

“Log Analysis Training”は、JPCERT/CCが公開しているセキュリティインシデント調査におけるログ解析方法について学ぶことができるコンテンツです。調査対象となる情報には、主にWindowsイベントログやプロキシログがあります。本コンテンツは、Internet Week 2016、2017、2018、2019にて実施されたトレーニング資料を編集したものとなっています。
標的型攻撃やネットワーク侵入後の攻撃パターンについて学ぶことができる座学パートと、実際にログを使いながらインシデント発生時のログの調査方法を学ぶことができるハンズオンパートが用意されています。
インシデント調査に関わる初級者を対象としているため、基礎から学びたい方には非常に取り組みやすいコンテンツだと思います。
なお、トレーニング資料はこちら(https://github.com/JPCERTCC/log-analysis-training)からダウンロードすることが可能です。

ハンズオン「プロキシログの調査」

ハンズオンパートは1から7までの学習コンテンツが用意されています。1から順番に進めていくことで、発生したインシデントの全貌がわかる仕組みになっています。本記事では、このうち、ハンズオン4「プロキシログの調査」を紹介します。公式サイト上にハンズオンの解説資料が掲載されていますが、調査の観点や手順を少し掘り下げて解説していきます。

ハンズオン4「プロキシログの調査」の概要は以下です。

目的
　プロキシログを使ってその他の感染端末がないかを調査する

問題

調査対象

調査に使用するログ
　access.log(プロキシログ)

今回のハンズオンで調査に使用するログは、プロキシサーバ「Squid」のログです。Squidは代表的なプロキシサーバの1つです。リバースプロキシや透過プロキシとしても使用することが可能です。

0. 準備(ログフォーマットの確認)

まずはaccess.logの中身を確認していきます。

Squidではログのフォーマット(http://www.squid-cache.org/Doc/config/logformat/)が複数用意されており、自由に変更することができます。今回のログの形式から、「combined」というログのフォーマットで定義されていることがわかります。
この後のログの調査で理解が進むよう、ログの各項目を整理しておきます。

Q1　Win10_64JP_09に感染したマルウェアの通信先ドメイン名を特定してください

1. アクセス先URLの確認

まず、マルウェアの主なファイル形式である実行ファイル(.exe)の送受信に関する通信のログがあるか確認します。

事前情報としてすでにマルウェアの通信先と判明している「anews-web.co」「news-landsbbc.co」の他に、「biosnews.info」も実行ファイルと通信を行っていることがわかりました。

2. アクセス数の確認

一般的に、マルウェアはターゲットのマシンに感染後、C2サーバ(Command&Controlサーバ)と通信を行い攻撃者から指令を受けます。よって、本問題ではC2サーバとの通信と思われるログを探していきます。マルウェアはC2サーバと定期的に通信していると想定し、まずはアクセス数の多いドメインを調べます。

access.logの中には正規のwebサイトとの通信ログも含まれているので、それらを除外してアクセス数の多いドメインを確認すると、「biosnews.info」へのアクセスが多いことがわかります。
そこで、「biosnews.info」のログを確認していきます。

アクセスの日時を確認すると、約3秒間隔で定期的にアクセスしていることがわかります。
また、Squidのログフォーマットを参照することで、これらのアクセスがリファラ情報を持っていないことがわかります。通常、マルウェアは通信を行う時リファラ情報を持っていないことが多いため、マルウェアによる通信である可能性が高いと考えられます。

3. ユーザエージェントの確認

その他にC2サーバとの通信のログを見分ける観点として、ユーザエージェントの確認があげられます。正常な通信のログのユーザエージェントと比較し、正常通信とは異なる特殊なユーザエージェントを使用している場合は、マルウェアである可能性があります。そこで、「biosnews.info」がマルウェアの通信先である可能性の確度をさらに高めるため、ユーザエージェントを確認してみます。

まず、ログ全体のユーザエージェントを確認します。

続いて、「biosnews.info」のログのユーザエージェントを確認します。

ユーザエージェント「Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)」は、ログ全体で検索したときと、アクセス先「biosnews.info」のログに絞って検索した時で出現数が一致するため、このユーザエージェントが「biosnews.info」との通信のみに使われていることがわかりました。

以上の情報から、「biosnews.info」はC2サーバである確度は高そうだと考えられます。

よって、Win10_64JP_09に感染したマルウェアの通信先ドメイン名として新たに判明したのは
biosnews.info
となります。

Q2　Win10_64JP_09以外の端末で不正な通信を行っている端末はありますか？ある場合は、端末を特定してください

4. 他端末の通信の確認

事前情報とQ1より、マルウェアの通信先ドメインは「news-landsbbc.co」、「anews-web.co」、「biosnews.info」の3つであるとわかりました。これらのドメインと他の端末が通信を行っていないか確認していきます。

192.168.16.109(Win10_64JP_09)以外では、192.168.16.101(Win7_64JP_01)が攻撃ツールのダウンロード元である「anews-web.co」と通信していることが確認できます。

よって、答えは
192.168.16.101(Win7_64JP_01)
となります。

なお、192.168.16.101(Win7_64JP_01)もマルウェアに感染していた場合、Q1と同様に不正な通信がログに多く残るはずですが、今回は残っていません。解説資料によると、ハンズオン環境ではプロキシを通過していなくても外部にアクセスできるようになっていたため、プロキシログには残っていなかったとのことです。実際のインシデント調査においても、調査対象とするログが全ての通信を現しているとは限りません。ログに残らない別の通信方法やルートで“すりぬける”ようなアクセスの可能性もあることを念頭に調査を進める必要があります。

ハンズオン4「プロキシログの調査」Q1、Q2を通じて、C2サーバへの通信と他の端末への不正な通信を行っていることを確認することができました。

おわりに

本記事では、セキュリティインシデントが発生した際のログ解析方法を学ぶことができるLog Analysis Trainingから、ハンズオン「プロキシログの調査」を紹介しました。本コンテンツでは座学でネットワーク侵入後の攻撃の流れを学んだあとに、ハンズオンで実際にログを調査しながら攻撃の痕跡をたどることができます。ログ調査の観点や進め方など、基礎的な内容を学ぶことができるため、ログ解析初級者の方でも楽しみながら学ぶことができると思いました。ご興味のある方は、ぜひ挑戦してみてください。

参考情報

Log Analysis Training
https://jpcertcc.github.io/log-analysis-training/

JPCERTCC/log-analysis-training
https://github.com/JPCERTCC/log-analysis-training

Squid configuration directive logformat
http://www.squid-cache.org/Doc/config/logformat/

執筆者の他の記事を読む