$UsnJrnlを制する者は、証拠隠滅を制する――攻撃者の足跡を追う「最後の砦」
現場でインシデント対応をしていると、攻撃者がどれだけ巧妙にログを消そうとも、必ず「見落とし」をするポイントがある。それがNTFSの $UsnJrnl（Update Sequence Number Journal） だ。
多くのエンジニアは「ログはイベントビューアーを見ればいい」と思っている。だが、侵入した攻撃者はまず真っ先にイベントログをクリアし、自身の実行ファイル（マルウェア）を削除して去っていく。しかし、$UsnJrnlには、ファイルが「いつ」「どこで」「何によって」作成、改変、削除されたかという、システムレベルの変更履歴が、攻撃者の意図とは無関係に刻まれているんだ。
今日は、攻撃者がどれほど「証拠隠滅」という名の工作をしても、お前たちがその尻尾を掴めるよう、この強力なタイムライン追跡術を伝授する。
—
1. なぜ $UsnJrnl が「証拠」として最強なのか
$UsnJrnlは、ボリューム上のすべてのファイル変更を記録する循環バッファだ。攻撃者が cmd.exe を使ってバックドアをドロップし、任務完了後にそれを del コマンドで消し去ったとしても、以下の事実はジャーナルの中にしっかりと残る。
- FileCreate: どのプロセスが、その悪意あるファイルを生成したか。
- FileDelete: どのプロセスが、証拠を隠滅しようとしたか。
- DataExtend: ファイルに不正なデータが書き込まれたタイミング。
攻撃者が「ファイルを消したからバレない」と高を括っている間に、我々はこのジャーナルを解析して、攻撃の初動からラストの隠滅までを完全に再構築できる。これがDFIRの醍醐味だ。
—
2. 攻撃者の手口：証拠隠滅のPoC（再現）
攻撃者は、侵害後の足跡を消すために以下のようなバッチファイルやスクリプトを走らせる。
:: 攻撃者が証拠を消すための悪意あるコマンド例
del C:\Temp\malware.exe /f /q
:: ログを消去して痕跡を隠す
wevtutil cl Systemこの操作が行われた瞬間、$UsnJrnl には「malware.exe が Delete された」というレコードが生成される。解析ツール（MFTECmdやUsnJrnl2Csvなど）を通せば、削除の瞬間にどのプロセスが動いていたかが一目瞭然だ。
—
3. 「追跡される側」から「守る側」へ：防御実装の極意
「追跡できる」だけでは足りない。そもそも攻撃者にファイル操作を許さない、あるいは操作ログを確実に保全する仕組みが重要だ。
Pythonによる「ファイル変更検知」の自動監視
ログが消される前に、重要なディレクトリの変更をリアルタイムで検知するスクリプトを動かしておこう。watchdog ライブラリを使えば、$UsnJrnl を解析するまでもなく、異常なファイル作成・削除を瞬時にSlack等へ通知できる。
# watchdogを使用して重要なディレクトリを常時監視するサンプル
import time
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
class SecurityAuditHandler(FileSystemEventHandler):
def on_deleted(self, event):
# 重要なディレクトリでファイルが削除されたら即座にアラート
print(f"[!] 警戒: ファイルが削除されました: {event.src_path}")
# ここでSlack WebhookやSIEMへログを送信する処理を追加する
if __name__ == "__main__":
path = "C:\\inetpub\\wwwroot" # Webサーバーの公開ディレクトリ
event_handler = SecurityAuditHandler()
observer = Observer()
observer.schedule(event_handler, path, recursive=True)
observer.start()
try:
while True:
time.sleep(1)
except KeyboardInterrupt:
observer.stop()
observer.join()設定レベルでの防御：監査ポリシーの強化
$UsnJrnl を解析する以前に、Windowsの「オブジェクトアクセス監査」を有効にしておくことが大前提だ。
1. グループポリシーエディタ (gpedit.msc) を開く。
2. コンピューターの構成 > Windowsの設定 > セキュリティの設定 > 高度な監査ポリシーの構成 > オブジェクトアクセスの監査 を選択。
3. 「ファイルシステムの監査」 を成功・失敗の両方で有効にする。
これを設定しておけば、$UsnJrnl に加え、イベントID 4663（オブジェクトへのアクセス）が生成され、誰がそのファイルに触ったのか、ユーザーアカウントレベルでの特定が可能になる。
—
4. 現場のシニアからのアドバイス：ログを信じすぎないこと
最後に一つだけ忠告しておく。$UsnJrnlも監査ログも、あくまで「OSが正しく動いている時」の記録だ。高度な標的型攻撃者は、OSのAPIを直接叩いてジャーナルへの書き込みをバイパスしたり、カーネルレベルでログを改ざんする。
だからこそ、ログは必ず外部のSIEMやログ収集サーバーにリアルタイムで転送しておけ。 ローカルのハードディスクにあるログを信じるのは、金庫の鍵を金庫の中にしまっておくようなものだ。
インシデント対応において「絶対に安全」という言葉はない。だが、こうして多層的に、かつ執念深く痕跡を追う仕組みを構築しておけば、攻撃者がどれだけ隠れようとしても、必ずどこかで綻びが出る。
次回の調査では、まず $UsnJrnl をダンプすることから始めよう。そこには、攻撃者が隠したかった「真実」が、必ず刻まれているはずだ。
コメント