TL;DR. ShimCache のタイムスタンプは、ファイルシステムからコピーされた実行ファイルの $STANDARD_INFORMATION 最終更新時刻です — 実行時刻でもキャッシュ時刻でもありません。タイムライン上のイベントではなく、ファイルのプロパティとして扱ってください。
ShimCache 分析で最もよくある誤りは、タイムスタンプ列を「これが実行された時刻」として読むことです。違います。この誤読は、実際のインシデント報告書に誤った時刻を書き込んできました。本稿はその値が正確に何であり、誤った結論を出さずに使う方法を説明します。
タイムスタンプの正体
各 ShimCache エントリは、Windows がエントリを記録した時点で NTFS ボリューム上にあった実行ファイルの最終更新時刻（$STANDARD_INFORMATION の mtime）を保存します。これはファイルシステム属性の単純なコピーです。プロセス生成、モジュール読み込み、シャットダウンについては何も語りません。
直接的な帰結が 3 つあります。
- 昨年ビルドされ今日実行された binary は、昨年の日付を示します。
- タイムスタンプを保持するツールでコピーされたファイルは、コピー時刻ではなく元の mtime を保ちます。
- 同じ署名付き binary を実行する 2 台のホストは同じタイムスタンプを示します — それはマシンではなくファイルのプロパティだからです。
なぜ実行時刻ではないのか
Windows はアプリケーション互換性のためにファイルを検査したときに ShimCache エントリを追加します — これは多くの場合（常にではない）実行と一致します。一致する場合でも、キャッシュは検査の瞬間ではなくファイルの mtime を保存します。したがってタイムスタンプは「このファイルが最後に変更されたのはいつか？」に答え、「いつ実行されたか？」には決して答えません。実行と存在の区別はShimCache はプログラムが実行されたことの証明になるか？で詳しく扱っています。
それでもタイムスタンプが有用な場面
イベント時刻としては弱くても、同一性のアンカーとしては強力です。
- 改ざん検知。
svchost.exeのようなシステム binary が、ホストのパッチレベルと整合しない mtime を示すなら、そのファイルは差し替えられています。 - ビルド相関。 あるキャンペーンでコンパイルされたマルウェアは、被害者間で mtime のクラスタを共有することが多く、グルーピングに役立ちます。
- 順序付け、ただし慎重に。 1 台のホスト内ではエントリはおおよその挿入順で保存されます。活動の順序付けには絶対タイムスタンプより順序の方が信頼できます。
攻撃者による悪用
ファイルシステム属性に過ぎないため、改変は容易です。タイムストンピング（例：mtime を kernel32.dll の定番日付 2009-07-14 に設定）は、ドロッパーを Windows システムファイルに紛れ込ませます。ShimCache は改変された値を忠実に記録するため、C:\Users\Public\ 配下のパスに付いた「きれいな」2009 年のタイムスタンプ自体が危険信号です。アンチフォレンジックの手口は攻撃者は ShimCache を消去できるか？に整理しています。
タイムラインで正しく使う
ShimCache の mtime はイベント時刻とは別の列に置いてください — 行為であるかのようにメインのタイムラインに混ぜてはいけません。順序付けは、実際にイベント時刻を持つアーティファクトで裏付けます：Prefetch の実行時刻、AmCache のインストール／初回実行、Security 4688、Sysmon 1。完全なクロスリファレンスはPrefetch、AmCache、ShimCache：クイックリファレンスにあります。
生の値を自分で確認するには、SYSTEM ハイブを Shimcache Parser にドロップしてください — ブラウザ内で、何もアップロードせずに、エントリごとの正確な保存 mtime を表示します。
さらに読む
- Mandiant: leveraging the ShimCache — このアーティファクトのフォレンジック利用を定義した原典。
- Eric Zimmerman の AppCompatCacheParser — 同じ mtime セマンティクスで出力するリファレンスパーサー。