痕跡は「消した」瞬間から始まる：MFT解析で暴く攻撃者の「隠蔽術」
現場でインシデント対応をしていると、「ログを全部消しました」と報告してくる攻撃者や、それを鵜呑みにするエンジニアに出くわすことがあります。しかし、WindowsのNTFSファイルシステムを使っている限り、「ファイル削除」は決して完全な消滅を意味しません。
今日は、攻撃者が残した「消えたはずの痕跡」をMFT（Master File Table）の構造から炙り出す、現場の泥臭いテクニックを共有します。
—
MFTとは何か？攻撃者の墓場である理由
NTFSにおけるMFTは、ディスク上のすべてのファイルに関する「メタデータ」を格納するデータベースです。重要なのは、ファイルを削除しても、MFT内のレコード自体は即座に上書きされないという点です。
具体的には、ファイルが削除されると以下の変化が起きます。
1. MFTレコードのヘッダーにある「フラグ」が 0x01（使用中）から 0x00（未使用）に切り替わる。
2. しかし、ファイル名、タイムスタンプ（$FILE_NAME属性）、そしてデータストリームへの参照情報は、次のデータが書き込まれるまでそこに残り続ける。
攻撃者は、バックドアのスクリプトを設置し、作業後に del コマンドで消去したつもりになります。しかし、我々フォレンジック調査官からすれば、MFTをパースすれば「いつ、どんな名前で、どのクラスタに存在したか」が丸見えなのです。
現場で使う「MFTから痕跡を拾う」Pythonスクリプト
本格的なフォレンジックには MFTECmd のようなツールを使いますが、開発・運用チームが自身のサーバーの整合性をチェックするために、MFTレコードのヘッダー状態をサクッと確認するツールを用意しました。
このスクリプトは、NTFSの生のMFTレコードを読み込み、フラグが「未使用」になっているのにデータ属性が残っている「削除済みファイル」のメタデータを抽出するヒントになります。
import struct
def analyze_mft_record(record_data):
"""
MFTレコードの先頭バイトを解析し、削除フラグを確認する関数
"""
# MFTレコードのフラグ位置（オフセット0x16）を取得
# 0x01: 使用中, 0x00: 未使用
flags = struct.unpack('<H', record_data[0x16:0x18])[0]
if flags == 0x00:
return "Deleted/Unused Record"
elif flags == 0x01:
return "Active File"
return "Unknown"
# 実際の運用ではディスクのRawイメージからMFT領域(通常$MFTファイル)を読み込んで実行
# 1レコードは通常1024バイト
record_size = 1024
# 読み込んだレコードデータブロックの例
sample_record = b'\x46\x49\x4c\x45...'
status = analyze_mft_record(sample_record)
print(f"解析結果: {status}")—
攻撃を「防御」へ：痕跡を残さない、あるいは残させない設計
攻撃者はこのMFTの仕様を悪用し、タイムスタンプを書き換える「Timestomping」を行って調査を撹乱します。これを防ぐ、あるいは事後の追跡を確実にするには、単なるファイル管理以上の対策が必要です。
1. ファイルサーバーの改ざん検知（FIM）
OS標準のファイル削除に頼るのではなく、整合性を強制するFIM（File Integrity Monitoring）を導入してください。Linuxであれば auditd、Windowsであれば Sysmon を活用し、削除イベント（Event ID 4660, 4663）をSIEMに飛ばすのが基本中の基本です。
2. Nginx等でのログの外部転送
攻撃者は自分の行動を隠すためにログを消します。ローカルにログを保存する設定は「自分、ここに証拠があります」と言っているようなものです。
セキュアなログ転送設定（Nginx）
# ローカルへの書き込みを最小限にし、syslog経由でリモートへ転送する
access_log syslog:server=10.0.0.50:514,facility=local7,tag=nginx,severity=info combined;
error_log syslog:server=10.0.0.50:514,facility=local7,tag=nginx error;3. クラウドIAMでの「削除権限」の分離
Webアプリケーションのバックエンドから「ファイル削除権限」を剥奪してください。多くの侵害は、アップロード機能の脆弱性からサーバー内のファイルを上書き・削除されることで進行します。
IAMポリシーの鉄則（AWSの場合）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::my-secure-bucket/*"
// "s3:DeleteObject" は絶対に含めない。
// 削除が必要な場合は別の管理用ロールに限定する。
}
]
}—
最後に：エンジニアへのメッセージ
インシデントが発生した際、一番怖いのは「何が消されたかわからないこと」です。
MFTの解析は、単なるフォレンジックの技術ではなく、「システムが嘘をついていないか」を確認する強力な手段です。開発するアプリケーションにおいても、「削除」という操作をあえて困難にする（権限を絞る、論理削除のみにする、監査ログを外部へ飛ばす）という設計思想を持つことが、真の堅牢なインフラを構築する第一歩になります。
「消したから大丈夫」と考える攻撃者の一歩先を、我々エンジニアが読みましょう。何かわからないことがあれば、またいつでも相談してください。
コメント