TL;DR. ケース作業には Eric Zimmerman の AppCompatCacheParser を使ってください。最も広い OS カバレッジ、CSV 出力、十分にテスト済み。艦隊規模のライブトリアージには Velociraptor を使ってください。シンプルな Python リファレンスが役立つときは Mandiant の Shim Cache Parser を使ってください。インストールゼロ、アップロードゼロが欲しいときは本ツールを使ってください。意見の相違は相互検証してください。フォーマットは細かく、2 つのパーサがときどき異なる解釈をする程度には独特です。
ShimCache 解析で重要なオープンソースツールは 4 つです。それぞれにニッチがあります。ジュニアアナリストがする間違いは 1 つを選んですべての案件の答えとして扱うことです。正しい答えはスケールしているか、スクリプティングしているか、午前 2 時に単一のハイブを見つめているかに依存します。
重要な 4 つのパーサ
| ツール | 言語 | 配布 | 最適 |
|---|---|---|---|
| Mandiant Shim Cache Parser | Python | GitHub 上のソース | フォーマットの読解、カスタム解析のスクリプト化 |
| Eric Zimmerman AppCompatCacheParser | C# / .NET | 単一バイナリ | ケース作業。本番レポートで最も信頼できる。 |
Velociraptor Windows.Registry.AppCompatCache | VQL | Velociraptor サーバ | 艦隊規模のライブ収集 |
| Shimcache Parser（本ツール） | Rust → WebAssembly | ブラウザのみ、インストールなし | セットアップなしの迅速なトリアージ、データはマシンを離れない |
どれをいつ手に取るか
Eric Zimmerman の AppCompatCacheParser
オフライン解析の事実上の標準。XP から Windows 11 までのすべての Windows バリアントをカバーし、SYSTEM トランザクションログを自動的に再生し、Timeline Explorer にきれいに落ちる CSV を出力します。出力が最終レポートに入る場合、これがレビュアーが使ったと期待するものです。
AppCompatCacheParser.exe -f SYSTEM --csv .
注意点：Windows 専用バイナリ、.NET Framework または Core が必要、ブラウザベースの即興トリアージ用には設計されていません。
Velociraptor
数十または数千のホストから ShimCache を引く必要があるとき、Velociraptor が勝ちます。アーティファクトは稼働中のエンドポイントから直接インメモリキャッシュを読みます。これはシャットダウン時に OS がフラッシュするはずだったのと同じビューですが、シャットダウンを待たずに済みます。理由については メモリダンプからの ShimCache 抽出 を参照してください。
注意点：Velociraptor インフラが必要です。単発の解析にはオーバーキルです。
Mandiant Shim Cache Parser
オリジナルの Python proof-of-concept。EZ のツールほど洗練されていませんが、フォーマットがどう正確にデコードされるかを理解するためにコードを読みたいとき、その周りにカスタム解析をスクリプト化したいときに有用です。出力はプレーンテキストです。他の Python パイプラインと統合してください。
python ShimCacheParser.py -t -h /path/to/SYSTEM
注意点：Python 2.x または互換フォークが必要。CSV / JSON 出力は EZ より洗練されていません。
この Shimcache Parser
他がうまくカバーしない 2 つのケースのために存在します：
- ゼロインストールトリアージ。 ページを開き、ハイブをドロップし、エントリを見ます。DFIR ツールがインストールされていないホストにいるとき、またはノートパソコンや貸与機で解析するときに有用です。
- 信頼に敏感な解析。 ハイブは WebAssembly を介して完全にブラウザで解析されます。ファイルはページを離れず、サーバに到達せず、どのログにも現れません。ハイブが顧客や、アップロードが受け入れられないケースに属するときに重要です。
トレードオフ：コマンドラインインターフェースなし、自動化フックなし。パイプラインではなく、人間が駆動するトリアージに使用してください。パイプラインには EZ のツールが正解です。
パーサが食い違うときの相互検証
バイナリフォーマットは寛容ではありません。Windows 10/11 レイアウトリファレンス は、単一のオフセット数え間違いが Blob の残りにどう波及するかを示します。実際にはパーサは通常一致しますが、実世界のハイブはわずかに仕様外のデータを出荷することがあり、パーサは以下で食い違います：
- Win7 ハイブでの bit 性検出。 ヘッダは x86 vs x64 を明確に言わないので、パーサはヒューリスティックに選びます。同じハイブで 2 つのツールが異なるパスを出力するのが手がかりです。
- パス正規化。 バックスラッシュエスケープ、ドライブレターの大文字小文字、先頭の
\??\マーカー。パーサごとに正規化が異なります。 - 空またはプレースホルダエントリ。 未使用スロットに空白行を出すツールもあれば、スキップするツールもあります。
重要なときは、2 つのパーサを実行して diff してください。私が手に取る組み合わせ：
- EZ + 本ツールで高速相互チェック。
- EZ + Mandiant で「Python vs C#」のサニティチェック。
- EZ + Velociraptor で「ライブインメモリ vs ディスク上ハイブ」の比較。
よくある落とし穴
- トランザクションログを忘れないでください。
SYSTEM.LOG1とSYSTEM.LOG2は保留中の書き込みを保持します。それらなしでは古いハイブを読んでいます。EZ のツールは自動的に再生します。他の一部はしません。SYSTEM ハイブの取得 を参照してください。 - ディスク上とインメモリの ShimCache を直接比較しないでください。 これらは異なる真実のソースです。ディスク上は前回のクリーンシャットダウン状態のみを持ちます。インメモリは現在のセッションを持ちます。補完的なものとして扱ってください。
- 実行を仮定しないでください。 どのパーサもこれを修正できません。キャッシュは検査を記録し、実行を記録するわけではありません。
さらに読む
- Eric Zimmerman の AppCompatCacheParser：リファレンスパーサ。
- Mandiant の Shim Cache Parser：オリジナルの Python 実装。
- Velociraptor
Windows.Registry.AppCompatCache：VQL アーティファクト。 - Ø Security の Windows 10/11 AppCompatCache deep dive：パーサが時々食い違う理由を説明。