痕跡は必ず残る：Amcache.hveが語る「実行された悪意」の全貌
現場でインシデント対応をしていると、侵入した攻撃者がどんなに巧妙にログを消し去ろうとしても、システムは正直だということに気づかされる。特にWindows環境において、攻撃者が実行したマルウェアの正体を暴くための「宝の山」が Amcache.hve だ。
今回は、このレジストリハイブファイルがなぜ重要なのか、そしてどうやってそれを「防御」と「調査」に活かすべきかを、現場の泥臭い知見を交えて解説する。
—
1. Amcache.hveとは何か？ なぜ攻撃者はこれを消し忘れるのか
Amcache.hve は、Windows 8以降、アプリケーションの互換性情報を管理するために導入されたレジストリハイブだ。本来はアプリケーションのクラッシュ防止や最適化のためのものだが、フォレンジックの観点からは「実行された全バイナリのタイムスタンプ、SHA-1ハッシュ、フルパス」を保持する最強の証跡となる。
攻撃者は prefetch ファイルを削除したり、イベントログをクリアしたりする小細工はするが、この Amcache まで丁寧に消去する者は意外と少ない。ここには、彼らがツールを実行した瞬間の「指紋」が刻まれているからだ。
—
2. 攻撃手法（PoC）のリスク：証拠隠滅の限界
攻撃者がマルウェアを実行する際、一時ディレクトリ（C:\Users\<user>\AppData\Local\Temp\）を利用するのは常套手段だ。攻撃のPoC（概念実証）において、彼らは自身のペイロードを難読化し、ファイル名を偽装するが、OSは律儀に以下の情報を記録する。
1. ファイル名
2. SHA-1ハッシュ値（ファイル名を変えてもハッシュは変わらない！）
3. パス情報（どこから実行されたか）
もし君のサーバーで不審なプロセスが動いた場合、まず真っ先に C:\Windows\AppCompat\Programs\Amcache.hve を回収し、解析ツール（AmcacheParser 等）にかけるべきだ。ここで得られたハッシュを VirusTotal に投げるだけで、その攻撃者が何者かが即座に判明する。
—
3. 守りの要：Amcacheの情報を「証拠」として保護する運用
調査のために Amcache を活用するのと同時に、攻撃者に改ざんされないための「守り」も重要だ。特にクラウド環境では、実行ログを外部のセキュアなストレージに転送しておくことが鉄則となる。
以下に、Pythonを用いて実行中のプロセスと Amcache 的な挙動を監視・保護するための簡易的なスクリプト例を示す。
Pythonによるプロセス監視・ログ出力サンプル
このスクリプトは、新しく起動されたプロセスを検知し、そのファイルパスとハッシュをリモートのログサーバーへ送る想定の雛形だ。
import psutil
import hashlib
import time
# 実行中のプロセスを監視し、ファイルハッシュを記録する関数
def get_file_hash(file_path):
"""ファイルのSHA-1ハッシュを計算する"""
sha1 = hashlib.sha1()
try:
with open(file_path, 'rb') as f:
while chunk := f.read(8192):
sha1.update(chunk)
return sha1.hexdigest()
except Exception:
return None
def monitor_processes():
print("プロセス監視を開始します...")
while True:
for proc in psutil.process_iter(['pid', 'name', 'exe']):
try:
exe_path = proc.info['exe']
if exe_path:
file_hash = get_file_hash(exe_path)
# 本来はここでSyslogやSIEMへJSONとして送信する
print(f"検知: {proc.info['name']} | PATH: {exe_path} | SHA-1: {file_hash}")
except (psutil.NoSuchProcess, psutil.AccessDenied):
continue
time.sleep(60) # 60秒おきにスキャン
if __name__ == "__main__":
monitor_processes()—
4. 堅牢なインフラ設定：ログの改ざんを防ぐIAMルール
ローカルの Amcache.hve が消されても、クラウド上のログが残っていれば勝負は決まる。AWS環境であれば、CloudTrail や GuardDuty を活用し、ログの書き込み権限を厳格に制限しよう。
AWS IAM ポリシー：ログバケットへの「書き込み専用」制限例
ログバケット（S3）に対して、攻撃者が既存ログを削除（s3:DeleteObject）できないようにするための設定例だ。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyLogDeletion",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::my-secure-log-bucket/*"
},
{
"Sid": "AllowWriteOnly",
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-secure-log-bucket/*"
}
]
}—
最後に：フォレンジックは「日常」に宿る
「あとで調査すればいい」という考えは、インシデント発生時には通用しない。Amcache.hve のようなOS標準の機能を深く理解し、それらを自社のセキュリティ監視基盤とどう連携させるか。そこまで考え抜いているエンジニアこそが、真に信頼される存在だ。
攻撃者は常に君たちの「盲点」を探している。しかし、OSが刻む記録は嘘をつかない。君が管理しているシステムが、いつ何時も「正確な証言者」でいられるよう、今日からログの保全体制を見直してみてほしい。
コメント