TL;DR. 攻撃者は主にクリーンシャットダウンを避けることで ShimCache と戦い、キャッシュをフラッシュさせないようにします。直接のレジストリ編集は通常 Blob を不正な形に残します。改ざんは、異常に短いキャッシュ、常に存在するはずの Windows バイナリの欠落、不正なエントリサイズ、メモリ vs ディスクの不一致で見つけます。
このキャッシュは大半の Windows アーティファクトより改ざんが困難です。不可能ではありません。いくつかのインシデントを経ると、攻撃者の試みに驚くのをやめ、彼らが指紋を残す頻度に驚くようになります。実際に見てきた手法と、それぞれが何を残すかのカタログです。
攻撃者が実際に試すこと
1. フラッシュ前のハードリブート。 キャッシュに対する最もクリーンなアンチフォレンジックは、Windows に書き込ませる機会を与えないことです。強制電源断、ハイパーバイザーでの VM 強制終了をすれば、そのセッションのインメモリ ShimCache はそのまま失われます。ディスク上のハイブは前回のクリーンシャットダウン時にフラッシュされたものを保持します。これがランサムウェア対応で圧倒的に最も一般的なパターンです。メカニズムについては キャッシュが書き込まれるとき を参照してください。
2. 値 Blob への直接的なレジストリ編集。 SYSTEM レベルの攻撃者は HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache を上書きできます。理論的には特定のエントリを削除します。実際には バイナリレイアウト は手編集が通常 Blob を不正な形に残したり、エントリ数を意味不明にする程度には自明ではありません。
3. オフラインハイブ置換。 攻撃者がシステムをダウンさせられるなら、SYSTEM ハイブを完全に入れ替えられます。国家関与の作業以外では稀ですが、起こります。registry parser は SYSTEM ハイブのタイムスタンプと構造がホストの他のアーティファクトと一貫しているかを示せます。
4. バイナリのタイムストンピング。 キャッシュがファイルの $STANDARD_INFORMATION mtime を保存するため、Windows が検査する前にバイナリのタイムストンプを行う攻撃者は、キャッシュされたタイムスタンプをずらします。キャッシュは嘘をついていません。捕捉したファイルメタデータがすでに改ざんされていたのです。改ざんがより困難な MFT の $FILE_NAME 属性と相互参照してください。
5. 裏付けアーティファクトの消去。 ShimCache の役割を学んだ攻撃者は、しばしば AmCache、Prefetch、EVTX、そして ごみ箱 も消去し、ShimCache を唯一の証人として残し、実行証明の投稿 で挙げた理由で却下されることを期待します。
検出の手がかり
改ざんを疑うときは、以下を探してください：
- 異常に短いキャッシュ。 Windows は通常使用で約 1,024 エントリまでキャッシュを満たします。数日稼働しているシステムで数件のエントリしか含まない Blob は、強力な改ざんシグナルです。
- 常に存在するはずのエントリの欠落。 いくつかの Windows バイナリは、バージョンに応じてほぼすべての ShimCache に確実に現れます：シェルコンポーネント、スケジュールタスクヘルパー、OS 更新ツール。使用されているワークステーションでのそれらの欠落は疑わしいです。
- 不正なエントリサイズ。 解析が途中で失敗し、残りのバッファがゼロまたはゴミで埋められている Blob は、ぎこちない編集の古典的な指標です。Shimcache Parser はこれを明示的なエラーとして浮上させます。
- インメモリとディスクの不一致。 RAM ダンプ から抽出したキャッシュをディスク上のハイブと比較してください（抽出ガイド）。メモリに存在しディスクに不在のエントリはハードリブートを意味するかもしれません。同じスロットでメモリと矛盾するエントリ（異なるパスや mtime）がディスクにある場合、誰かがハイブに書き込んだことを示唆します。
- AmCache と ShimCache の不一致。 AmCache はバイナリが実行されたことを示すが、ShimCache はそのファイルについて空です。なぜか問うてください。ShimCache を消去する攻撃者は AmCache の存在を忘れることが多いです。
- アンチフォレンジックツールの足跡。 関連する期間に
reg.exe、PowerShellRemove-ItemProperty、サードパーティのハイブエディタが実行された証拠を Prefetch、Sysmon Event ID 1、USN ジャーナル で探してください。
これが調査員に伝えること
レポートで強制している実用的なルール：
- 空または空に近い ShimCache を証拠として扱う。 証拠の不在として扱わない。明示的に文書化してください。
- 可能なときは RAM ダンプを引く。 ハイブが失ったものをしばしば捕えます。
- 常に AmCache と Prefetch で裏付ける。 アーティファクトリファレンス を参照。3 つのアーティファクトを一貫して消去するのは 1 つよりはるかに困難です。
- 「攻撃者が ShimCache を消去した」と主張しないでください、何が消去されたか示せない限り。エントリ数のギャップ、ベースラインバイナリの欠落、メモリ vs ディスクの不一致を指してください。
さらに読む
- Velociraptor の
Windows.Registry.AppCompatCache：異常を見つけるための大規模収集。 - Ø Security の Windows 10/11 AppCompatCache deep dive：改ざんされた Blob がどのフィールドを偽造しなければならないかを理解するのに有用。
- Mehrnoush の ShimCache & AmCache forensic analysis：改ざんシナリオを含むケーススタディ。
- MITRE ATT&CK T1070 Indicator Removal：このようなアーティファクトについてリソースの豊富な攻撃者が何をするかのコンテキスト。