TL;DR. ShimCache は HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache に存在します。Windows はセッションごとにメモリ上で再構築し、クリーンシャットダウン時にのみ SYSTEM ハイブにフラッシュします。ハードリブートでは直近のエントリが完全に失われる可能性があります。読み取った内容を信じる前に、SYSTEM.LOG1 と SYSTEM.LOG2 を再生してください。
ほとんどの ShimCache でのトラブルは同じ根本原因にたどり着きます。アナリストがキャッシュをログファイルのように更新されると考えてしまうのです。そうではありません。キャッシュはシステム稼働中はメモリ上に存在し、ディスク上のコピーは前回のクリーンシャットダウン時の状態のみを反映します。これを間違えると、ホストはクリーンだと書くレポートが実は感染しているということになります。
レジストリパス
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache
末尾の AppCompatCache はサブキーではなく値です。データは単一のバイナリ Blob で、そのスキーマは Windows リリースによって異なります。XP、7、8、8.1、10/11 ファミリはすべて異なるレイアウトを使用します。バイナリフォーマット解説 で最新の Windows 10/11 スキーマを詳細に扱っています。
オフラインでは、SYSTEM ハイブ（C:\Windows\System32\config\ 配下のファイルの一つ）を取り出し、パーサを向けます。SYSTEM.LOG1 と SYSTEM.LOG2 も持参してください。Shimcache Parser は SYSTEM ハイブをブラウザ内で読み込み、アップロードはありませんが、受け付けるのはその 1 ファイルのみで、ログの再生は行いません。ハイブが dirty の場合は、先に Eric Zimmerman の rla.exe で .LOG1 と .LOG2 を再生して（または Registry Explorer で読み込んでクリーンなハイブを保存して）から、その結果を解析してください。
ControlSet の落とし穴
Windows は実際には複数の ControlSet を保持しており、通常は ControlSet001 と ControlSet002 です。任意の瞬間、HKLM\SYSTEM\Select\Current が示すように、ちょうど一つがアクティブです。CurrentControlSet はアクティブなものへのランタイムエイリアスです。稼働システムでは常に正しく解決されますが、オフラインでは自分で作業する必要があります。
防御可能なパーサは次のとおりです。
HKLM\SYSTEM\Select\Current（DWORD、通常 1 か 2）を読みます。- 対応する
ControlSetXXX\Control\Session Manager\AppCompatCache\AppCompatCache値を辿ります。 Select\Currentが読み取れない場合はControlSet001とControlSet002の両方をスキャンするフォールバックを行います。
本ツール、Eric Zimmerman の AppCompatCacheParser、Mandiant の Shim Cache Parser はいずれもこの解決を自動的に処理します。自作する場合は自己責任で。
Windows が実際に書き込むとき
ここが人々を捕える部分です。Windows が稼働中、ShimCache はメモリ上に存在します。ディスクコピーはクリーンシャットダウン時にのみ書き込まれます。したがって：
- ハードリブート、停電、BSOD、ハイパーバイザーレベルでの VM 強制終了は、まだ永続化されていなかったすべてのエントリを破壊します。
reg.exeや RegRipper を使ったライブトリアージは、メモリ上で構築中のキャッシュではなく、以前に永続化された値を読みます。- RAM ダンプ に対する Volatility 3 の
windows.shimcachememプラグインは、現在のインメモリキャッシュを回収します。これがクリーンシャットダウンされていないホストからアクティブセッションのエントリを取得する唯一の方法です。
ハードリブートされた侵害済みマシンに到着した場合、ディスク上のハイブはインシデント前のキャッシュを保持しています。攻撃者がアクティブセッションで実行したものはすべて、メモリも取得していない限り失われます。裏付けのストーリーは通常、継続的に書き込みを行い同じリブートを生き残る AmCache から取得する必要があります。
トランザクションログ
SYSTEM.LOG1 と SYSTEM.LOG2 は、まだメインハイブにマージされていないレジストリ書き込みを保持します。堅牢なパーサは ShimCache を読み取る前にこれらのログを再生します。SYSTEM だけをコピーしてログをスキップした場合、古いビューを読んでいます。これは最も一般的な取得ミスです。取得ガイド で 3 つすべてを安全に取得する方法を解説しています。
クイックチェックリスト
- ShimCache の値：
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache。 - アクティブな ControlSet は
HKLM\SYSTEM\Select\Currentで選択されます。 - メモリに保存され、クリーンシャットダウン時にのみフラッシュされます。最近の活動については AmCache で裏付けてください。
- 解析前に必ず
SYSTEM.LOG1とSYSTEM.LOG2を再生してください。
さらに読む
- Microsoft Learn: Registry hives：ハイブファイルと ControlSet の正式リファレンス。
- Mandiant の ShimCacheParser：オリジナルの Python パーサ、フォーマットリファレンスとして有用。
- Velociraptor
Windows.Registry.AppCompatCache：稼働システムからの収集ロジック。