とりあえずログ見てもらえますか？ 1

はじめに • 本発表は個人の見解であり、所属組織を代表するものではありません • 本発表内容の利用等により何らかの損害が発生したとしても発表者は一切責任 を負いかねます。自己責任でのご利用とさせてください • 本資料中で紹介する事例は実際の事件・事故とは一切関係ありません 2

話すこと 前半はログ分析とインシデント対応について、ざっくりお話しします 後半はサンプルログを使ったログ分析事例を紹介します 1. インシデント対応の流れ 2. ログ分析のタイミング 3. ログ分析の進め方 4. 実際にやってみる 3

インシデント対応の流れ 準備 識別 封じ込め 復旧 根絶 教訓/改善 Incident Handler‘s Handbook (SANS) https://www.sans.org/white-papers/33901/ インシデント対応は大きく次のフェーズに分けられる 同時並行で進めたり、前のフェーズに戻ったりしながら対応していくケースがほとんど どのフェーズにいるのか見失って行き当たりばったりな対応になると悲惨… →現在地と目的を確認しながら進めることが大切 4

ログ分析のタイミング Q. じゃあ、ログ分析ってどのフェーズでやるの？ 準備： ログ保存ポリシーの策定、検出ルールのチューニングなど 識別： 異常なイベントの検出、イベントの重大度判断など 封じ込め/根絶： 影響範囲の特定、原因究明、被害拡大の抑止など 復旧： ログの継続監視、正常時のログとの比較など 教訓/改善： レポートの作成、分析手法の改善、検出ルールの改善など A. 全部 5

ログ分析の進め方 6 ログを用意する フィールド抽出 分析・調査 分析結果の報告 分析観点・目的設定 ログソースの設定を適切に行い、分析対象のログを取得する 保存ポリシー（場所、期間等）を決めておくとGood インシデント対応時のログ分析の目的を設定する ATT&CKなどのフレームワークを活用することも ログから分析に必要な項目（フィールド）を抽出する #事前にログフォーマットを把握しておくとスムーズ 分析観点・目的に沿ってログ分析を行う 必要に応じて公開情報などを調査することも 一連の分析結果をまとめて報告する #結果が出ないと延々と分析しがち… 報告のタイミングを事前に決めておくといいかも 目的とアウトプット（報告）を意識しながら進める

ログを用意する インシデント対応時にログ分析を行うためには事前準備が必要 分析対象となるログを用意するためのポイントについてざっくりまとめる 7 ファイアウォール、 プロキシ、メールGWなど 資産管理ツール、 イベントログなど Webサーバ、 DNSサーバ、VPNなど 保管対象ログの選定 ログソースによって記録される情報はさまざま。 「UTM製品のアラートログは保存していたけどトラフィックログがなくて詳細調査ができない」といったこと が起きないように、インシデント発生後の調査を想定して保管対象ログを選定することが重要 ログの保存場所/期間 保存場所： ログソース自体、ログサーバ、ログ分析基盤など （ログを取得する手間などから初動、調査期間に影響を与えるケースも） 保存期間： 数日～数年まで幅広い。組織のポリシーに沿って決めることがベター （初期設定ではログが保存されなかったり、数日で無くなるケースもある）

ログは用意したけど… 8 ログを用意する 実際、インシデントが起きたわけでもないし… いきなり目的設定しろって言われても厳しい… 分析観点・目的設定 良い感じにまとまった資料とか、練習用のコンテンツとか、、 そんな感じの都合の良い感じの、、、

あります！ Log Analysis Training（JPCERT/CC） https://jpcertcc.github.io/log-analysis-training/ 9 ハンズオン形式でログ分析手法を学べる • ツールを使用したイベントログの抽出 • Windowsクライアントのイベントログの調査 • Proxyログの調査 ←これ使います • 侵入端末の特定 • Active Directoryログの調査 しかも日本語の解説資料まで用意されている

プロキシログを分析してみる Hands-on 4のaccess.log（Webプロキシログ）を使って実際に調査を行います。 今回はログ分析エンジンとしてSumoLogicを使いました。 10 access.log ファイルアップロード https://github.com/JPCERTCC/log-analysis-training/tree/master/Hands-on/Handson4 Sumo Logic クラウド型のログ分析エンジン ログ取込量ベースの料金体系（今回はFree版を利用） 有料版だと地理情報、脅威インテリジェンスなど色々使える機能が増える模様

被害組織 目的を設定する 11 Hands-on 4 端末Aが攻撃者に侵入されたことで、組織内の複数の端末が侵害された。 現在確認されている通信先情報をもとに横展開の有無を調査する。 端末A（Win10_64JP_09） 192.168.16.109 端末B（Win7_64JP_01） 192.168.16.101 端末C（Win7_64JP_03） 192.168.16.103 侵害 侵害 C2サーバ • news-landsbbc[.]co • anews-web[.]co

フィールド抽出 12 【サンプルログ】 192.168.16.112 - - [07/Nov/2021:19:12:17 +0900] "CONNECT www.facebook.com:443 HTTP/1.0" 200 1071 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko" TCP_MISS:DIRECT ログから分析対象の項目（フィールド）を抽出します 抽出対象項目 フィールド名 抽出例 送信元IPアドレス src_ip 192.168.16.112 HTTPメソッド method CONNECT URL url www.facebook.com FQDN fqdn www.facebook.com 宛先ポート dst_port 443 ステータスコード status_code 200 リファラー referer - User-Agent useragent Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

フィールド抽出 13 parse "* * * [*] ¥"* * *¥" * * ¥"*¥" ¥"*¥" " as src_ip,tmp1,tmp2,tmp3,method,url,http_version,status_code,res_size,referer,useragent | parse regex field=url "^(?:https?://)?(?[¥w¥-¥.]+?)(?::(?¥d{1,5}))?(?/.*?)?$" nodrop SumoLogicでは、以下のようなParseクエリを書くことで各フィールドを抽出できます

プロキシログの分析観点 14 項目 分析例 POSTリクエスト FQDNごとにPOSTメソッドを用いた通信回数を集計、特殊なイベントがないか確認 where method == “POST” | count by fqdn 定期的な通信 1時間ごとに各FQDN単位でのイベント数を集計、定期的に通信が行われている対象を確認 timeslice 1h | formatDate(_timeslice, "MM-dd hh:mm") as event_time | count by event_time,fqdn | transpose row fqdn column event_time 業務時間外の通信 業務時間外に発生した通信を検索し、不審な通信が発生していないか確認 timeslice 1h | num(formatDate(_timeslice, "hh")) as hour | where !(hour >= 9 and hour <= 18) | count by _timeslice,fqdn 特殊なUser-Agent 送信元IPアドレス、User-Agentごとのイベント数を集計し不審な通信の有無を確認 （普段使っていないブラウザから通信が行われているケースなども要注意） count by src_ip,useragent | sort by src_ip Refererのない通信 リファラーのない通信を検索し、不審な通信の有無を確認（必要に応じてフィルタを追加する） where referer == "-" and method != "CONNECT" EXEファイルのダウンロード EXEファイルのダウンロードが疑われるURLを検索し、内容を確認する where url matches “*.exe” 特殊なポートへの通信 宛先ポートごとにイベント数を集計し、利用頻度が低いポートへの通信状況を確認する count by dst_port | sort by _count IoCの検索 既知のIoCを検索する where fqdn == “example.com”

ログの検索/集計 15 • EXEファイルのダウンロード • 定期的な通信 侵害された端末のプロキシログから侵害の痕跡を調査してみると、 既知のIoC以外の不審な通信先（biosnews[.]info）が見つかる

ログの検索/集計 16 IoCを利用して未確認の感染端末の有無を調査する プロキシログ上では、新たな感染端末は確認されなかった 被害組織 端末A（Win10_64JP_09） 192.168.16.109 端末B（Win7_64JP_01） 192.168.16.101 端末C（Win7_64JP_03） 192.168.16.103 侵害 侵害 C2サーバ • news-landsbbc[.]co • anews-web[.]co • biosnews[.]info 同じように侵害された端末でも、ログが記録されていないケースがあるため この時点では「他に感染端末はない」と断言できるわけではない（報告の仕方を気を付ける）

インシデントが一段落したら… 17 一連のインシデント対応を振り返り、改善できるポイントを確認します。 まずは特にログ分析に限定せずざっくばらんに議論を進め、まとめの段階で各課題をどの役割 の中で改善していくと良いのか決めていくと良いと思います。 あのログの保存場所が最初から分かっていれば… この条件でアラートを鳴らせば同じ事象にいち早く気付ける！ XXさんも同じ調査してたの！？ ログ検索時間がボトルネック… この観点も調査項目に追加しよう

まとめ インシデント対応・ログ分析は「事前準備」が大切 インシデント対応時は現在地（どのフェーズにいるのか）を見失わないように →定期的にチーム内の認識を合わせておくことも重要 ログ分析は目的とアウトプット（報告）を意識しながら進める 準備段階である程度の分析観点・手法を決めておくと初動が大きく変わる →オペレーションの固定化/自動化にもつながりやすい →「とりあえずログ見てもらえますか？（タイトル回収）」と言われても慌てず対応できるように 教育用コンテンツを活用してスキルアップ • Log Analysis Training (JPCERT/CC) https://jpcertcc.github.io/log-analysis-training/ • CyberDefenders Splunkを使ったログ分析のチャレンジがある（Boss Of The SOC v1～v3） https://cyberdefenders.org/blueteam-ctf-challenges/ 18