君たちはどうWindowsイベントログを調査するか
イベントログ調査のぼんやりメモ。思い出したら追記。
はじめに
主に インシデント対応目線 でのお話。
この手の情報はいろんなサイトに散らばっていていちいち探すのが面倒なので。
1. イベントログ調査とは
イベントログ調査の目的は、怪しいイベントを網羅的に拾い集めることではなく、対象環境で何が起きたのかを把握し、初動対応や追加調査につなげること である。
そのため、最終的にはイベントログだけで結論を出すのではなく、他の証拠と突合しながら 侵害者の行動について仮説を立て、検証していく 視点が重要である。
その前提のもと、以下のことは最低限頭に入れておくこと。
イベントログは完全な記録ではない
Windowsイベントログは、端末上で発生したすべての出来事が記録されているわけではない。 記録する機能があったとしても、デフォルトでは有効になっていない物もまぁまぁ多い。監査ポリシー 依存。
記録設定が有効になっていたとしても、イベントログには容量上限がある。設定によっては古いイベントから順に上書きされる。
侵害者によってログが削除されてしまう場合もある。ランサムウェア事案などでは削除が自動化されているケースもあり、攻撃後に一通りログが削除されているケースも珍しくない。
ログの改ざん可能性も完全に排除はできない。EVTX には整合性確認のためのチェックサム機構があるものの、暗号学的な改ざん防止機構ではない。 ただし、単純なログ削除と比べて手間がかかるため、実際のインシデントで遭遇する機会はあまりない。
ログは失われる前に保全する
あなたがこの記事を読んでいる間にも、新しいイベントが記録され、古いイベントは上書きされている。
特に、調査において有用なログである Securityログ は上書きが早く、数日分残っていれば良い方、1～2時間分しか残っていないこともある。(ログオン失敗で埋め尽くされてたりね)。迷っている暇があったらまず保全。
また、保全後にはそれぞれのログがどの期間残っているかを一覧にしておいたり、ログの保存設定がどうなっていたかを書き留めておくとよい。
大量のログからノイズを減らす
イベントログ調査では、クライアント1台あたり数GB, サーバなら数十～数百GBのログを見る覚悟がいる。そんなのとてもやってられない。そのため大量のイベントからどうノイズを減らすかが非常に重要。
端末の役割や利用状況で記録されるイベントは大きく異なるので、一様にこう、という指針はないが、普段その機器がどのように利用されているかを把握しておくことは、異常なイベントを見つける上で大きな助けになる。
いいからとりあえず全部見ろって？ 殴りますよ。
2. 目的
何を調査したいのかわからないまま、ログ調査をすることはできない。
大きな目的からブレイクダウンして、調査の目的を明確にすることが重要。
5W1H のような観点でもいいし、Cyber Kill Chain のようなフレームワークでもいい。
なんらかの軸を使って整理すると、調査項目のヌケモレを減らしやすい。
- 侵害は発生したのか？（検知）
- どこから侵入したのか？（初期侵入）
- どのように拡大したのか？（横展開・持続化）
- 何をされたのか？（活動内容）
- 何が影響を受けたのか？（影響範囲）
- なぜそれが可能だったのか？（原因）
とかね。
調査したい理由なんて大抵は「侵害があったかどうか」、あったなら「情報漏洩があったかどうか」とかそんなんでしょう。じゃあそれを調べるためには何を見る必要があるのか？
ログに記録されているのはあくまで個々の具体的なイベントなので、それらの連なりから何が起きたか？それが起きたなら他にどんな痕跡が残るはずか？という仮説を立てて検証していく。
たとえば 「情報漏洩があったか」を知りたいとして、イベントログに「情報漏洩しました」とは書かれるはずもない。 見るべきは、不審なログオン、ファイルアクセス、外部通信、リムーバブルメディア接続、管理共有へのアクセス、不審ツールの実行など、情報漏洩に至るまでに発生しうる行動の痕跡 である。
SANS Instituteが公開している、Windows Forensic Analysis POSTER がある程度網羅的なので見るとよい。このポスター自体は他のアーティファクトについてもまとめてあるのだが、「こういう痕跡が記録されるかもなんだなぁ」という観点で参考になる。
3. 範囲を区切る
ログ調査なんて際限がない（マジに）。
リソースは突っ込んだら突っ込んだだけ消える ので、最初に何をどこまで調査するか範囲を区切ることが重要。
調査結果を見て範囲が足りなかったら、その時考えれば良いのだ。
- どのホストを調べるのか？（サーバー？クライアント？）
- どの期間を調べるのか？（侵害が疑われる前後？検知時刻の前後？）
- どのログを調べるのか？（Security？System？Application？PowerShell？TaskScheduler？）
- どのユーザーを調べるのか？（管理者？一般ユーザー？サービスアカウント？）
- どのような行動を調べるのか？（ログオン？プロセス実行？横展開？永続化？）
最近起きた侵害について調べていたら、何年も前に起きていたであろう別の怪しい痕跡を見つける、なんてよくあること。もちろんそれ自体は注視すべきポイントだが、今起きている侵害をどうにかするほうが優先。
4. 調査の勘所
ここまでで調査したいことと範囲を決めたら、実際にログを見ていく。 主要なEvent IDを調査の起点にしつつ、仮説に応じて見るべきログやイベントを広げていく。
Event IDから探す
基本的には MS Learn などの信頼できる公式ドキュメントを参考にするのがよい。
Sysmon が導入されていれば細かいイベントも見れるのだが、、、ほとんどの環境では入っていない。期待してはいけない。
Securityログに限っていえば、Security Log Encyclopedia も非常に参考になる。Undocumentedなイベントも多いので、気になるEvent IDがあったらここで調べるとよい。
それでも見つからないときには、detection.wiki や MyEventlog で探すと見つかるかも。EventIDはびっくりすることに一意の識別番号ではない 狂気の 仕様なのだが、ちゃんとProvider/Channelごとにまとめられている。
さらにニッチなやつはググりまくると見つかったりする。実機のディスクイメージ保全してるなら無理やりブートしてイベントビューアで直接開いてもいいけどね。
行動から逆引きする
使われたツールや技術がわかっているなら、JPCERT/CCが公開する、個別ツール別分析結果 などを参照しながら痕跡を探すとよい。
大和セキュリティによる、DFIRと脅威ハンティングのためのWindowsイベントログ設定のガイド などを見ても良い。Sigma をもとに、デフォルトのイベントログ設定がどうなっているかなどに言及がある。
可能なら元の Sigma ルール定義を見てもよいが、大量にありすぎてとても覚えられるものではない。
5. 生成AIの利用
契約上許されるなら、生成AIを使ってもよい。
気になるEvent IDやフィールドを調べるときの取っ掛かりにしたり、考えられる攻撃手法を洗い出したり、検索クエリを書かせたり、調査結果を整理したり。使いどころはいろいろ。
ただし、AIの回答をそのまま調査結果にしてはいけない。ニッチなEvent IDやWindowsの仕様について尋ねると、もっともらしい誤った説明を生成してしまうことがしばしばある。必ず裏をとる。
また、インシデント対応で扱うログには、ユーザー名、IPアドレス、ホスト名、ファイルパス、メールアドレスなどの機微な情報が大量に含まれている。AIへログや証拠データを入力してよいかは、慎重に判断すること。
6. 報告
調査の結果、何が起きた可能性があるのか、これからどうすべきかを報告する。
あるいは、それがアナリストの仕事ではないなら、どこから先が別の担当領域なのかを明確にしておくとよい。インシデント対応ではヤバい仕事の押し付け合いになる こともままあるので、あらかじめネゴっておくとスムーズ。
また、報告先へ渡す資料については、何を聞かれてもすべて説明できるくらい脳に叩き込んでおかなければならない。 それ以外については、聞かれたら答えられるように手元に資料を揃えておけばよい。
セカンドオピニオンがついている場合や、お客様がセキュリティに知見がある場合、「◯◯ は確認しましたか？」などと聞かれる場合もある。リソースには限りがあるので全てに備える必要はないが、なぜその項目を確認していないのかは説明できるようにしておくこと。 これこれこういう理由で調査対象からは外しました。契約範囲外です。とかね。
また、報告する内容は絞ってよい。というか、調査結果から考えられる仮説すべてを報告する必要はまったくない。
根拠のない仮説で相手を不必要に不安にさせたり、混乱させないためにも、最も確度の高い仮説と、それを検証するために行った調査の内容を中心に報告すれば十分。
Appendix-1: 主要なEvent ID
とっかかりを見つける という観点で、以下の主要なEvent IDから気になるポイントを見ていくと良い。
起点となる怪しいイベントが分かれば、その前後の時系列を一生懸命追っていけば未知のイベントでも役立つものがあるはず。
ログオン・認証
誰が、いつ、どこから、どの端末へログオンしたのか（横展開）を見る。
問題が発生した機器や、インターネットからの入口となる踏み台サーバなどから調査していく。
見る際には、記録されるイベントがログオン元、ログオン先どちらのものか意識するように。
接続先に記録される
接続元に記録される
- Security.evtx
- 4648: ユーザーが既に別のユーザーとしてログオンしている状態で、明示的な資格情報を使用してコンピュータへのログオンに成功
操作発生元に記録される
Event ID 4672 は、4624と Logon ID で結びつけて調査できるため有用。
Logon Typeについて
Event ID 4624の LogonType は非常に重要。横展開を見るなら3(Network), 10(RemoteInteractive) を中心に、9(NewCredentials)なども補助的に見る。
| Logon Type | 説明 |
|---|---|
| 0 | SYSTEMアカウントでのみ使用されるログオンタイプ。 |
| 1 | 情報なし。 Redditでは、NT 3.x時代の名残では？というウワサ。 |
| 2 | Interactive（対話型）。ユーザーが端末を対話的に使用するログオン。 コンソールログオン、RUNAS、リモートシェル、KVM、Lights-Outカード経由の操作, IIS Basic Auth(6.0未満) など。 |
| 3 | Network（ネットワーク）。ネットワーク経由で対象にアクセスするログオン。 net use による共有アクセス、リモートコンピュータへのMMCスナップイン、PowerShell WinRM、PsExec、Remote Registry、Remote Desktop Gateway、脆弱性スキャナ、IIS統合Windows認証、SQL Windows認証など。LogonUser はこのログオンタイプの資格情報をキャッシュしない。再利用可能な資格情報は原則として宛先LSAセッションに残らないが、Kerberos委任が有効な場合などは例外に注意。PsExecは明示的な認証情報を指定した場合、Network + Interactive の複数ログオンセッションを作ることがある。 |
| 4 | Batch（バッチ）。ユーザーの直接操作なしに、ユーザーの代理でプロセスを実行するためのログオン。 スケジュールタスクなど。メール/Webサーバーなど、一度に多くの平文認証試行を処理する高性能サーバー用途でも使われる。LogonUser はこのログオンタイプの資格情報をキャッシュしない。ただしスケジュールタスクでは、パスワードがLSA Secretとしてディスク上に保存される場合がある。 |
| 5 | Service（サービス）。サービスによるログオン。 対象アカウントには「サービスとしてログオン」権限が必要。サービス実行用の資格情報は再利用可能な資格情報としてLSAセッションに残り得る。また、パスワードがLSA Secretとしてディスク上に保存される場合がある。 |
| 6 | Proxy（プロキシログオン）。公式にはプロキシタイプのログオンと説明される。 Redditでは、内部/開発ビルド専用では？というウワサ。 |
| 7 | Unlock（ロック解除）。ワークステーションのロック解除。 GINA DLLなど、対話的に端末を使用しているユーザーのロック解除を記録するためのログオンタイプ。 |
| 8 | NetworkCleartext（ネットワーク平文認証）。認証パッケージ内に名前とパスワードを保持し、サーバーがクライアントを偽装しながら他のネットワークサーバーへ接続できる。 IIS Basic認証(6.0以降)、CredSSPを用いたPowerShell WinRMなど。再利用可能な資格情報が宛先側に残るため、資格情報窃取リスクが高い。 |
| 9 | NewCredentials（新しい資格情報）。現在のトークンを複製し、外向きのネットワーク接続に別の資格情報を指定する。 ローカルでは元のIDのまま、ネットワーク接続時だけ指定した資格情報を使う。RUNAS /NETWORKなど。再利用可能な資格情報はLSAセッションに残り得るため注意。 |
| 10 | RemoteInteractive（リモート対話型）。リモートかつ対話型のターミナルサービスセッション。Remote Desktopなど。 RDPログオン成功だけでなく、4625のログオン失敗でもRemoteInteractiveとして記録されることがある。再利用可能な資格情報が宛先LSAセッションに残るため、侵害端末への特権アカウントRDPは危険。 |
| 11 | CachedInteractive（キャッシュされた対話型）。ネットワークにアクセスせず、キャッシュされた資格情報を使用した対話型ログオン。 ドメインコントローラへ問い合わせて認証したログオンとは限らない。 |
| 12 | CachedRemoteInteractive（キャッシュされたリモート対話型）。RemoteInteractiveと同様。内部監査用途。 |
| 13 | CachedUnlock（キャッシュされたロック解除）。キャッシュされた資格情報を使用したワークステーションのロック解除。 |
ログオン失敗理由について
Event ID 4625のログオン失敗は、ログオンエラーコード を見ることでなぜ失敗したのかがわかる。
ユーザ名がそもそもないとか、ユーザ名はあっているけどパスワードが間違っているとか。。これによって攻撃者がその行為を行った時点でどの程度の情報を把握していたのかわかる。例えば、一発ログオン成功しているならどっかでパスワードダンプしているか、事前に漏洩していた可能性もある。
Kerberos / NTLM
ドメイン環境では Kerberos / NTLM の認証ログから、どのアカウントが、どの端末から、どのサービスや端末へ認証しようとしたかを追うことができる。
接続先に記録される
- Microsoft-Windows-NTLM%4Operational.evtx
接続元に記録される
- Microsoft-Windows-NTLM%4Operational.evtx
DCに記録される
4776は、ドメインユーザであればDCに記録される。イベントには認証元の端末名は記録されるが、接続先端末は記録されないので注意。
-
Security.evtx
-
Microsoft-Windows-NTLM%4Operational.evtx
RDP / TerminalServices
RDP接続の試行、認証、セッション開始、切断、再接続などを見る。
Securityイベントログが消されていても、RDP関連が残っていることが割とあるため、こっちから流れを追える場合もある。
接続先に記録される
-
Security.evtx
-
Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx
-
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
-
System.evtx
- 9009: デスクトップウィンドウマネージャが終了(RDPセッションの切断などで記録されることがある。それ以外でも使われるため注意。)
接続元に記録される
- Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx
プロセス実行
何が、誰の権限で、どこから起動されたのかなど。
無効になっていることが多いので、あれば儲けたと思えば良い。
4688は「Audit Process Creation」が有効な場合に記録される。
さらにコマンドラインは別途「Include command line in process creation events」を有効化しないと記録されない。
PowerShell / Scripting
PowerShellの起動、実行内容、スクリプトブロック、ログなど。設定依存なので、記録されていればなるべく見る。定期実行されている場合もあるので、普段の運用を把握しつつノイズは頑張って減らす。
- Windows PowerShell.evtx
- Microsoft-Windows-PowerShell%4Operational.evtx
WMI
WMI経由の操作や永続化に使われるイベントフィルター、コンシューマーなど。
ノイズ多めなのであんまり一生懸命見なくてもよい。
- Microsoft-Windows-WMI-Activity%4Operational.evtx
横展開・リモート操作
共有アクセス、管理共有、SMB経由のファイル操作やリモート操作の痕跡を見る。
PsExecなど、SMBや管理共有を利用して横展開する手法も多いので要チェック。
接続先に記録される
-
Security.evtx
-
Microsoft-Windows-SMBServer%4Security.evtx
-
Microsoft-Windows-SMBServer%4Operational.evtx
接続元に記録される
-
Microsoft-Windows-SMBClient%4Connectivity.evtx
-
Microsoft-Windows-SMBClient%4Security.evtx
共有設定を変更したホストに記録される
サービス変更
サービスの作成、起動、停止、起動種別変更を見る。
PsExec系、永続化、EDR/AV停止、バックアップ製品停止などの痕跡が残っていることがある。
- Security.evtx
- 4697: サービスインストール
- System.evtx
スケジュールタスク
タスクの作成、削除、有効化、無効化、更新、実行を見る。
マルウェアの永続化や遅延実行でよく使われるので、タスク名、実行コマンド、作成者、作成時刻を見て怪しいものがないかチェックしておく。
-
Security.evtx
-
Microsoft-Windows-TaskScheduler%4Operational.evtx
- 100: タスクが開始された
- 101: タスクの開始に失敗した
- 102: タスクが完了した
- 103: アクションの開始に失敗した
- 106: タスクが登録された
- 107: タスクがスケジューラによってトリガーされた
- 108: タスクがイベントによってトリガーされた
- 110: タスクがユーザーによってトリガーされた
- 111: タスクが終了された
- 118: タスクがコンピューターの起動時にトリガーされた
- 119: タスクがログオン時にトリガーされた
- 129: タスクのプロセスが作成された
- 140: タスクの登録情報が更新された
- 141: タスクの登録が削除された
- 142: タスクが無効化された
- 200: タスク内のアクションが開始された
- 201: タスク内のアクションが完了した
- 203: タスク内のアクションの開始に失敗した
アカウント・グループ管理
アカウント作成、削除、有効化、パスワード変更、グループ追加を見る。
長期で入られてた事例とかではよく 変なアカウントが追加 されてたりする。
特に、Administrators、Domain Admins、Enterprise Adminsなどの強い権限を持つグループへのメンバー追加は確認すべき。
- Security.evtx
- 4720: ユーザーアカウントが作成された
- 4722: ユーザーアカウントが有効化された
- 4723: アカウントのパスワード変更が試行された
- 4724: アカウントのパスワードリセットが試行された
- 4725: アカウントが無効化された
- 4726: ユーザーアカウントが削除された
- 4728: セキュリティ有効グローバルグループにメンバーが追加された
- 4729: セキュリティ有効グローバルグループからメンバーが削除された
- 4730: セキュリティ有効グローバルグループが削除された
- 4731: セキュリティ有効ローカルグループが作成された
- 4732: セキュリティ有効ローカルグループにメンバーが追加された
- 4733: セキュリティ有効ローカルグループからメンバーが削除された
- 4734: セキュリティ有効ローカルグループが削除された
- 4735: セキュリティ有効ローカルグループが変更された
- 4737: セキュリティ有効グローバルグループが変更された
- 4738: ユーザーアカウントが変更された
- 4740: ユーザーアカウントがロックアウトされた
- 4756: セキュリティ有効ユニバーサルグループにメンバーが追加された
- 4757: セキュリティ有効ユニバーサルグループからメンバーが削除された
- 4764: グループの種類が変更された
ポリシー変更
Active Directoryオブジェクト変更
- Security.evtx
Windows Firewall
WFP(Windows Filtering Platform)による通信と、Windows Firewallの設定変更を見る。 通信系はノイズ多めで役に立つことは少ないが、見たっていい。
通信関連
- Security.evtx
Windows Firewall設定変更
DirectionがInbound/Outboundのどちらか、ActionがAllow/Blockのどちらか、EnabledがTrue/Falseのどちらか、ProfileがDomain/Private/Publicのどれかなど、気をつけて見ること。
- Security.evtx
Microsoft Defender (旧 Windows Defender)
マルウェア検知、駆除・隔離、防御機能の無効化を見る。
検知名、対象パス、実行された処理、防御機能がいつ止められたかを確認する。
検知はしてるけど駆除・隔離してないために実行されてしまっている事例とかもそこそこ。
evtxの名前は環境によって違うことがあるので注意。
- Microsoft-Windows-Windows Defender%4Operational.evtx
- 1116: マルウェアまたは望ましくない可能性のあるソフトウェアを検出した
- 1117: 検出した脅威に対して処理を実行した
- 1118: 検出した脅威に対する処理に失敗した
- 1119: 検出した脅威に対する処理が重大なエラーで失敗した
- 5001: リアルタイム保護が無効化された
- 5004: リアルタイム保護の構成が変更された
- 5007: Microsoft Defender Antivirusの設定が変更された
- 5010: マルウェア・望ましくない可能性のあるソフトウェアのスキャンが無効化された
- 5012: ウイルススキャンが無効化された
- 5013: Tamper ProtectionがDefender設定の変更をブロックした
ログ改ざん・痕跡削除
ログクリア、イベントログサービス停止、監査イベント破棄など。
最初に書いた通り、ログ調査をするときにはどのログがいつからいつまで残っているのかを最初に一覧にしたほうがよい。「不審なログオンはありませんでした！」「Securityログはいつから残っていたんですか？」「...」なんて事にならないように。
-
Security.evtx
-
System.evtx
- 104: その他ログクリア
ログローテート
これは調査で使うことはあまりないかもしれないが、知っておくとログの欠落を見たときになぜそれが起きたのか判断しやすい。
イベントログは、Channel ごとに「最大容量の指定」と「満杯になったときにどうするか」を指定できる。後者には以下3つがある。
- Overwrite events as needed（必要に応じて古いイベントを上書きする）
- Archive the log when full, do not overwrite events（満杯になったファイルをアーカイブして新しいログファイルに記録する）
- Do not overwrite events / Clear log manually（満杯になったら新規イベントを記録しない）
1は、FIFO的に古いログ領域を再利用して新しいイベントを書き込んでいく。そのため、RecordID/RecordNumberの古い番号が欠落しているように見える。ログが欠落しているからといって安易に「侵害者による削除」と断定するのではなく、ログローテート設定を確かめてなぜ消えたかを考えること。
2は、満杯になったログをアーカイブ（自動バックアップ）しながら新しいファイルを作って記録し続ける。調査する人間としてはこれが一番うれしいのだが、当然ながら容量をガンガン消費する。ちゃんとログ管理を設計したい場合、ローカルディスクだけに抱え込むのではなく、イベントログ収集サーバやSIEMなどに転送して保管する設計にした方がよい。またこの場合、Securityログに 1105 が記録される。
3は、満杯になった時点から新規イベントを記録しなくなる。この設定はマジで困るのでやめてほしい。どういう嬉しさがあるのだろう。またこの場合、Securityログに 1104 が記録される。
時刻・電源・再起動・シャットダウン
ログの時刻設定など地味だが重要。
あとは電源状態と他の痕跡に齟齬がないかなどは見ている。電源落ちているはずの時刻に何かが記録されていれば、どっちかがおかしい。(自分がおかしくなっている場合もままある)
- Security.evtx
- 4616: システム時刻が変更された
- System.evtx
- 12: Kernel-General: OSが起動した
- 13: Kernel-General: OSがシャットダウンを開始した
- 41: Kernel-Power: システムが正常にシャットダウンされずに再起動した
- 1074: User32: プロセスまたはユーザーによってシャットダウン/再起動が開始された
- 6005: EventLog: Event Logサービスが開始された
- 6006: EventLog: Event Logサービスが停止された
- 6008: EventLog: 直前のシャットダウンが予期しないものだった
- 6009: EventLog: OS起動時のバージョン情報
- 6013: EventLog: システム稼働時間
アプリケーション異常
アプリケーションのクラッシュなど。
ユーザによってインストールされたアプリケーションの情報があったりなかったり。
- Application.evtx
Sysmon
Sysmon が入っているなら、ぶっちゃけこれとログオンだけ見ときゃそんなに困らない。
これから設定しますとか、解析環境でマルウェア動かして挙動観測したいとかなら入れておけば良い。
とはいえインストールしておわりではなく、ある程度自前でコンフィグをいじってあげないとノイズが多くなりがち。定番の設定は SwiftOnSecurity/sysmon-config 。
Win11からは標準搭載機能 （有効化されているとは言ってない）
- Microsoft-Windows-Sysmon%4Operational.evtx
- 1: Process creation
- 2: A process changed a file creation time
- 3: Network connection detected
- 4: Sysmon service state changed
- 5: Process terminated
- 6: Driver loaded
- 7: Image loaded
- 8: CreateRemoteThread
- 9: RawAccessRead
- 10: ProcessAccess
- 11: FileCreate
- 12: RegistryEvent (Object create and delete)
- 13: RegistryEvent (Value Set)
- 14: RegistryEvent (Key and Value Rename)
- 15: FileCreateStreamHash
- 16: Sysmon config state changed
- 17: Pipe created
- 18: Pipe connected
- 19: WmiEventFilter activity detected
- 20: WmiEventConsumer activity detected
- 21: WmiEventConsumerToFilter activity detected
- 22: DNSEvent
- 23: FileDelete
- 24: ClipboardChange
- 25: Process Tampering
- 26: File Delete Logged
- 27: File Block Executable
- 28: File Block Shredding
- 29: File Executable Detected
- 255: Error
Appendix-2: 主要なログChannel
保全自体はとりあえず何でもかんでもやっておけばよいのだが、いざ見るぞ！というときになんにもわからんなら気合の目grepだ。
とりま Provider/Channel で件数絞ってパラ読みしたいときには以下を中心にみればよい。
- Application.evtx
- Directory Service.evtx
- Microsoft-Windows-Bits-Client%4Operational.evtx
- Microsoft-Windows-CodeIntegrity%4Operational.evtx
- Microsoft-Windows-DNS-Client%4Operational.evtx
- Microsoft-Windows-DNSServer%4Audit.evtx
- Microsoft-Windows-GroupPolicy%4Operational.evtx
- Microsoft-Windows-Kernel-Boot%4Operational.evtx
- Microsoft-Windows-Microsoft Defender%4Operational.evtx
- Microsoft-Windows-NTLM%4Operational.evtx
- Microsoft-Windows-PowerShell%4Admin.evtx
- Microsoft-Windows-PowerShell%4Operational.evtx
- Microsoft-Windows-RemoteDesktopServicesRdpCoreTS%4Operational.evtx
- Microsoft-Windows-SMBClient%4Operational.evtx
- Microsoft-Windows-SMBClient%4Security.evtx
- Microsoft-Windows-SMBServer%4Operational.evtx
- Microsoft-Windows-SMBServer%4Security.evtx
- Microsoft-Windows-SmbClient%4Connectivity.evtx
- Microsoft-Windows-Sysmon%4Operational.evtx
- Microsoft-Windows-TaskScheduler%4Operational.evtx
- Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx
- Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx
- Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
- Microsoft-Windows-Time-Service%4Operational.evtx
- Microsoft-Windows-WMI-Activity%4Operational.evtx
- Microsoft-Windows-WinRM%4Operational.evtx
- Microsoft-Windows-Windows Defender%4Operational.evtx
- Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx
- Microsoft-Windows-Windows Firewall With Advanced Security%4FirewallDiagnostics.evtx
- Microsoft-Windows-WindowsUpdateClient%4Operational.evtx
- Security.evtx
- Setup.evtx
- System.evtx
- Windows PowerShell.evtx
参考: 徳島県つるぎ町立半田病院 コンピュータウイルス感染事案 有識者会議調査報告書 ― 技術編 ―
Appendix-3: 解析ツールの使い方
非アナリスト向け
あなたが現場のSEとか機器管理者で、今すぐ侵害された可能性があるかログ確認しろって言われたならWindows標準のイベントビューアーを使え。
GUIで検索やフィルタができるので、初期の確認には十分使える。
調査部署とか外部に依頼するからエクスポートしろと言われた場合でも、イベントビューアーから保存できる。
右サイドバーの Save All Events As... をクリックすればよい。
ただし、CSVでエクスポートしたものをCSIRTやアナリストに渡すな。マジでやめろ。
調査する側からすると、ゴミみたいなCSVを使えるように整形するところから始める必要があり、余計な手間になる。そもそもかなり情報量が落ちている。調査担当に渡すなら、.csv ではなく .evtx 形式で保全したものにすること。
以下はイベントビューアーからエクスポートしたわけのわからないCSVファイルの例。1カラムに多数の改行が含まれている。張り倒すぞ。
ファストフォレンジックを依頼することを見越してデータ取得するなら、CDIR-Collector あたりをつかっておけばよい。exe ポチポチで主要なデータがゴソッと取れる。
ただし、このツールの知名度は国内に限った話なので、海外のセキュリティベンダ相手に渡すとなにそれ？ってなると思う。どのツールで取得したらよいかは相手方に聞いておこう。CyLR, KAPE, Velociraptor あたりを指定されるかな。。
イベントログの実体は C:\Windows\System32\winevt\Logs\ 以下にあるが、直接ファイルコピーするとロックの兼ね合いで失敗することもある。可能なら正規のエクスポート手順で取得したほうが安全。
標準コマンドでやりたいならこう。外部からツールを持ち込むのが難しい場合はこれで。
アナリスト
あなたが CSIRT とかフォレンジック調査員なら、やり方は好みのものを選択すればよい。 ただし、チーム内で何を使うのかはあらかじめ合意しておくとよい。
たとえあなたが逆張りオタクで人と違うツールを使うのが好きだとしても、そのツールによって証拠性が担保できるということは、あなたが説明しなければならないことを忘れてはいけない。
使ったツールが何をどうパースして、どんな形式で出力し、元ログとどう対応しているのかは把握しておきましょう。
以下は個人的おすすめ順。
| パーサ | 概要 | 備考 |
|---|---|---|
| EvtxECmd | EVTXファイルをCSVやJSONに変換できるコマンドラインツール。 | SANS講師の Eric Zimmerman 氏のツール群の一つ。DFIR用途で広く使われている。 |
| evtx2es/evtx2json | EVTXファイルをElasticsearchにインポートする/JSON変換するコマンドラインツール。 | 当時デファクトだったPython製パーサがハチャメチャに遅かったので作った。ElasticsearchやDuckDBなど、調査システムに組み込みたい場合に便利。 |
| plaso | 様々なアーティファクトからスーパータイムラインを生成するツール | 単一の変換ツールというよりはフレームワークに近い。かなり複雑。 |
| log2timeline | plasoの前身であるperl版。こっちは比較的シンプル。 | はるか古代のツールなのでよほどの理由がなければ今から採用しなくてもよい。 |
| PowerShell | Windows標準のスクリプト言語。イベントログの抽出・整形に利用できる。 | 一度作っておけば使い回せる。バグがあると二次被害が起きたりするので注意。 |
| Log Parser | Microsoftが提供していたコマンドラインツール。SQLライクなクエリでログを解析できる。 | 公式ツールだが、開発は終了している。ドキュメントも全然ない。誰か書いてほしい。 |
| 分析・整形ツール | 概要 | 備考 |
|---|---|---|
| Timeline Explorer | CSVなどをタイムライン形式で閲覧するツール。フィルタやグルーピングに強い。 | Eric Zimmerman 氏のツール群の一つ。パッと見るなら基本これでいいが、プロジェクトファイルの保存・読み込みが弱い。 |
| Quilt | CSVの高速なフィルタ、変換ツール。 | xsvを使っていて困ったポイント（100GB級テキストの処理、処理のチェインなど）に対処するために作った。 |
| LibreOffice Calc | オープンソースの表計算ソフト。 | Excelがない環境でも使える。巨大CSVはちょっと厳しいね。 |
| Excel | Microsoftが提供する表計算ソフト。みんな知ってるね。 | 有償。利用者は多いが、大量ログは読み込めなかったり、勝手に時刻が数値変換されたりする。ふざけるな。 |
| Elasticsearch + Kibana | 検索エンジン/可視化ツール。超大量のログを効率的に分析できる。 | ログのインデックス作成と横断検索に強い。クエリは初見殺しなので生成AIと一緒に使うといいかもしれない。 |
| Event Log Explorer | イベントログの閲覧と分析に特化したGUIツール。 | 商用利用は有償。SANSトレーニングでも使われている信頼のあるツールだが、あまり使いやすいとは思えない。 |
| TimeSketch | Google製ログ分析補助ツール。GUIで怪しいやつをフラグ付けとかできる。 | plasoと親和性が高い。使ってみた が、Webアプリケーションだからかマジで遅い。複数人で同時作業するとかなら良さがあるのかもしれない。 |
| Log Parser Studio | Log ParserのGUIフロントエンド。 | たぶん配布停止。探せばまだあるが。 |
| Log Parser Lizard | Log Parser系のGUIツール。 | Log Parser Studioより高機能。でも使い方がイマイチわからない。 |
| Splunk | 商用のログ管理・分析プラットフォーム。大量ログの検索・可視化に強い。 | 嫌い。 |
あと上記とはちょっと毛色が違うけど ハンティングツール の紹介。事前に作っておいた検知ルールでログをスキャンして怪しいイベントを引っ掛けたりすることができる。
単純な抽出だけではなく加工や正規化もしているので、この結果を直接報告に使うのは難しいが、ざっとスキャンして全体像を掴み、その後で詳細分析をすると素早く怪しいポイントを見つけやすい。
とはいえ原理的に FalsePositive は防げないので、結果を鵜呑みにしないこと。
| ハンティングツール | 概要 | 備考 |
|---|---|---|
| Zircolite | Sigma ルールでイベントログにスキャンかけて検知を行うツール。 | この手のツールの走り。のイメージ。（違ったらごめんなさい） |
| Chainsaw | これも同上。爆速。 | 海外では結構使われているイメージ。 |
| Hayabusa | これも同上。超高機能。 | 言わずとしれたYamato Securityのプロダクト。ドキュメントがかなり豊富で使いやすい。コミット頻度もエグい。 |
CSV で扱う
evtxファイルをバイナリのまま見るのは現実的ではない。
人間が見るなら、フォーマットはCSVが一番取り回しやすい。grepもできるしね。
EvtxECmdがおすすめ。ファイル指定 -f もしくはフォルダ指定 -d で変換する。
フォルダ指定すると配下の .evtx が1つの .csv に統合される。
フィルタリングは Timeline Explorer がおすすめ。
Event Id = 4624 のように条件式でフィルタをかけたり、カラムをクリックしてソートしたり、グルーピングしたり、思いつくほとんどのことはできる。
ただし、フィルタや条件式などが保存できない（バグ？）ので注意。
それゆえ自動化も難しいが、とりあえずざっくり見てみるべ～のときはこれでいい。
調査手法をある程度確立できたら、自動化を検討したってよい。
詳しくは ログ解析パッチワーク を参照。
JSON で扱う
システム化するとか、AIにわたす場合はこっちのほうがよい。
ヘッダーをいちいち気にしなくてよいし、意味を構造で管理しやすい。
evtx2es をダウンロードする。
exe版はDefenderで検知される場合があるので、気になる人はpipでインストールしたりリポジトリをクローンして使っても良い。
素直にElasticsearchに入れて分析してもよいのだが、
検索など単純なタスクに対してシステム側が過剰に複雑になりすぎると思うなら、DuckDBを使うと良い。Web UIもついててお得。
JSONLファイルを直接指定して扱える。
あるいはテーブルにしたってよい。
CLIからちょっと触りたいだけなら jq でもいいが、コマンドがあまり直感的ではないので毎回思い出せない。
AIに聞くか、素直にCSVでやろう。
おわりに
もうイベントログ調査なんてこりごりだ～！
おしまい