イベント ログ クリアと、生き残るギャップ

イベント ログ クリアは、すべてのオペレーターが最初に学ぶアンチフォレンジック テクニックで、最も使える跡を残すものでもあります。後半は直感に反します。ログをクリアする目的は証拠を取り除くことで、Security.evtx のクリアに成功した攻撃者は、あなたが読みたかった何千ものイベントを削除しています。しかしクリア行為自体が騒がしく、より静かにしようとするテクニックは異なる、しかし同様に診断的なシグネチャを残し、多くのオペレーターが忘れるチャネルがクリアされたものを再構築できるだけのものを保持しています。

何が生き残るかを知ることが重要なのは、ホストへの質問を変えるからです。「Security ログには何があるか」が「Security ログから何が欠けていて、それらのイベントは他のどこに行ったか」になります。

1102、104、1100: 騒がしい方法

Security ログを消したいオペレーターのデフォルトの反射は wevtutil cl Security です。これは:

• Security.evtx に 1 つの EventID=1102 を生成、クリアの直後、クリアを実行したアカウントと時刻を記録。このイベントは、クリアされた新ファイルに最初に書かれるイベントなのでクリアされたログでも生き残ります。煙の銃と扱ってください。アカウント名、送信元ワークステーション、クリア時刻はすべてイベント データにあります。
• System.evtx の Microsoft-Windows-Eventlog プロバイダーから、クリアされたチャネル名を持つ対応する EventID=104。これは System ログ側の 1102 ミラーです。オペレーターが複数チャネルをクリアし順序が重要なため、2 つのうち 1 つしか生き残らないこともあります。
• オペレーターがクリア前にサービスを停止していれば、サービス シャットダウンを示す Event Log サービスからの 1100。1100 の後に説明できないギャップ、その後 1102 の組み合わせは、古典的な「シャットダウン、改ざん、再起動」パターンです。

これら 3 イベントが大きいシグネチャです。何をしているか分かっている攻撃者は、それらを生成しないか、生成してから再度クリアして取り除きます。これにより 2 つ目の 1102 と、さらに小さい生き残りログが生じます。各クリア パスは 1102 を残します。ホストが履歴に複数の 1102 を持つこと自体が異常です。

クリアされるイベントだけが犠牲者ではありません。チャネルをクリアすると基底の EVTX ファイルがリセットされ、ディスク上のファイルが書き換えられます。旧ファイルのチャンクは未割り当てになります。妥当な時間内にホストをイメージ取得すれば、ディスクから復元可能です。これがこの物語のもう 1 つの枝です (carving 記事で扱う)。

wevtutil cl 対スレッド停止

より洗練されたオペレーターはログをクリアしません。Windows Event Log サービス (eventlog) のスレッドを停止し、騒がしい行為を行い、スレッドを再開します。スレッドが停止している間、OS とアプリケーションが生成するイベントは ETW インフラストラクチャでキューに入りますが、EVTX ファイルには書かれません。スレッドが再開すると、キューはほぼフラッシュされますが、停止ウィンドウ中にバッファを溢れたイベントは永遠に失われます。

これが Invoke-Phant0m (Halil Dalabasmaz による PowerShell) の動作です。Mimikatz モジュール event::drop も同様のことを行いますが、サービス プロセス内の ETW コールバックをフックします。両方とも以下を残します:

• 1102 なし。何もクリアされていない。
• 104 なし。同じ理由。
• ギャップ。停止ウィンドウの前後のイベントは存在し、内側のイベントは欠けています。これが検知です。

ギャップは 2 つの方法で検知可能です。1 つ目は連続 RecordID の健全性チェック: EVTX チャンク ヘッダーは FirstEventRecordIdentifier と LastEventRecordIdentifier を記録し、レコード ID がチャンクをまたいで単調であることを検証できます。停止は RecordID カウンタを壊しません (サービスは停止、カーネル ETW プロバイダーは停止していない) が、チャンク内のタイムスタンプは忙しいプロバイダーからのイベントがないウィンドウを示し、ドメイン コントローラー上では一目瞭然です。

2 つ目は、再昇格せずには停止できないチャネルに対する相関です。Microsoft-Windows-EventLog%4Operational.evtx チャネルはイベント ログ サービス自体のライフサイクルを記録します。スレッド停止はここに明示的な「スレッドが停止された」イベントを生成しませんが、サービスの内部ハートビート (105、106、運用チャネルが高い詳細度にあるときのプロバイダー固有デバッグ イベント) は時に不整合を記録します。

3 つ目、より難しい、は Sysmon の証跡です。Sysmon は独自ドライバー経由で自分のチャネルに書き、イベント ログ サービスの停止に影響されません。Sysmon のあるホストは、停止ウィンドウを通じてプロセス作成と image load の連続記録を持ちます。Security.evtx の疑わしいギャップ時刻を Sysmon の Operational チャネルに対して相互参照してください。Sysmon がギャップ開始時に Phant0m ソース コードに一致するコマンドライン内容を持つ powershell.exe プロセス (または 12 ほどある公開バリアントのいずれか) を表示すれば、答えが出ます。

転送イベント チャネル

Windows Event Collector (WEC) は、イベントを中央コレクターに転送する標準メカニズムです。転送されたイベントは WEC サブスクライバーの Microsoft-Windows-EventLog%4ForwardedEvents に到着し、発信ホストの Computer フィールド、元の RecordID、元のタイムスタンプを保持します。

環境に WEC があり、コレクター自体が侵害されていなければ、転送イベント チャネルは、ローカル ログがクリアされたホストで何が起きたかの唯一の完全な記録になることがあります。イベントは (コレクター追加のメタデータを除いて) 発信ホストで生成されたものとバイト等しく、発信ホストの RecordID で転送コピーをローカル ログの RecordID タイムラインに縫い戻せます。

注意点: WEC サブスクリプションはデフォルトでプル ベースで、15 分のハートビート。高速な攻撃者は、転送ハートビートの間にローカル ログをクリアでき、コレクターには最後の成功プル以前のイベントしかありません。重要なチャネルに対しては MinLatency モード (プッシュ、30 秒バッチ レイテンシ) でサブスクリプションを構成してください。ネットワークとコレクターのスループットがかかりますが、必要になった初回でペイバックします。

もう 1 つの注意点: WEC はデフォルトでは転送しません。サブスクリプションを誰も構成していなければ、コレクター チャネルは空です。この証拠経路に賭ける前に、候補コレクターのサブスクリプション状態を確認してください。

選択的削除と EVTX レベルの問題

ライブ EVTX ファイルから特定イベントを削除しつつ残りを残す選択的レコード削除は、形式知識でファイルを編集してチャンク CRC を再計算すれば理論上可能です。実務ではライブ運用で誰もこれをしません。イベント ログ サービスがファイルを開いてロックしているため、サービスを停止しない限りユーザーランドから編集できず、サービスを停止すると 1100/105 イベントが生成されるからです。

実際に起きるのは、事後のオフライン改ざんです。EVTX ファイルをエクスフィルし、自分のマシンで編集し、ライブ ファイルを置き換える (サービス停止後) オペレーターは:

• 編集したチャンクで一貫性のない CRC を残します、チャンク ヘッダー CRC とレコード領域 CRC の両方を正しく再計算しなければ。
• それらも更新していなければチャンク ヘッダーで一貫性のない LastEventRecordNumber。
• チャンク境界をまたぐ RecordID の不連続。

まともなパーサーはこれらにフラグを立てます。evtx_dump はデフォルトで CRC ミスマッチで警告します。EvtxECmd は出力に不一致をログします。侵害されたと疑われるホストからの EVTX ファイルの解析中の任意の CRC 警告は、潜在的改ざんインジケータとして扱い、他のことをする前に基底ディスクをイメージ取得してください。

Microsoft-Windows-EventLog%4Operational.evtx でしか浮かばないもの

このチャネルは Security.evtx から独立しており、多くの攻撃者は無視します。記録するもの:

• イベント ログ サービスの開始と停止 (105、106)。
• チャネル状態変更 (サブスクリプション開始、チャネル有効/無効)。
• マニフェスト登録イベント。

Event Log サービスが再起動されたとき (オペレーターが Stop-Service eventlog を使ったか、パッチを当てて再起動したから)、1100/105/106 ファミリとペアになるイベントがここで得られます。Security.evtx が時刻 T に 1100 を示し、EventLog%4Operational.evtx が同じ T に対応するサービス状態変更を示すなら、シャットダウンは秩序立っていました。Security.evtx がギャップを 1100 なしで示し、EventLog%4Operational.evtx がサービスが再起動されたことを示せば、サービスは秩序立ったシャットダウンなしにクラッシュまたは強制終了されたことになり、それ自体怪しい。

このチャネルは小さく、読むのが速い。デフォルトのトリアージ チェックリストに追加してください。

ホスト アーティファクトに対するクロス バリデーション

Security ログがなくなったり改ざんされたりしたとき、生き残るアーティファクトはおなじみの容疑者です:

• EVTX ファイル自体の Master File Table。$STANDARD_INFORMATION と $FILE_NAME のタイムスタンプは、ファイルがクリアで書き換えられた時刻を示します。
• Security.evtx の DATA_OVERWRITE と DATA_TRUNCATION イベントの USN journal。これらはクリアをジャーナル用語で高解像度タイムスタンプ付きで示します。
• wevtutil.exe の実行、または疑わしいクリアと並んだ powershell.exe 実行の Prefetch。
• 攻撃者がクリアを実行するために持ち込んだツール、特にデフォルト以外のバイナリを使った場合の Shimcache と AmCache。
• 取得したなら、RAM dump のアーティファクト。イベント ログ サービスのインメモリ キャッシュには、ディスクにフラッシュされなかったレコードが含まれます。

Security ログは 1 つのソースです。1 つのソースとして扱ってください。それだけに依存する調査は、1 つの改ざんファイルで無用になります。本サイトのパーサー は出力でチャンク CRC ミスマッチと RecordID ギャップにフラグを立てます。これが、1 時間読む前に改ざんされたログを見ているかどうかの安価な一次チェックです。

参考資料

• Halil Dalabasmaz の Invoke-Phant0m ソース。何をするか読んでください。検知はそこから直接出ます。
• Roberto Rodriguez の ThreatHunter-Playbook entry on 1102 と関連するクリア検知資料。
• Microsoft の Windows Event Collector サブスクリプション ドキュメント、転送イベントのセーフティ ネットを提供する WEC 構成。