analyzing-disk-images

ディスクイメージの分析

ディスクイメージは凍結された犯罪現場であり、この分野のあらゆる作業でそれを保全します。検証済みの読み取り専用コピーだけを使い、各段階でハッシュを確認して何も変更されていないことを証明してください。また、削除済みデータや未割り当て領域は、稼働中のファイルシステムより多くを語ることがよくあります。まさに誰かが消そうとしたものだからです。

使用する場面

• 取得済みのディスクイメージ（.E01、.dd／.raw、.aff4、.vmdk、.vhdx）を調査する場合
• 削除済みファイルを復元する場合、または消去・再フォーマットされたボリュームの内容を再構築する場合
• ファイルシステムのタイムライン、またはイメージ全体の完全なスーパータイムラインを作成する場合
• 未割り当て領域、スラック領域、空きクラスターからファイルやアーティファクトをカービングする場合
• マウントしたイメージから、レジストリハイブ、ブラウザーデータ、ログ、その他のアーティファクトをオフラインで抽出する場合
• タイムスタンプ改ざん、消去、隠しコンテナーや暗号化コンテナーなどのアンチフォレンジックを確認または否定する場合

使用しない場面

• ディスクイメージではなく、RAM キャプチャがある場合 — analyzing-memory-images を使用してください
• 稼働中またはトリアージ対象の Windows ホストがあり、生のイメージを扱うのではなく、アーティファクトごとの調査を行いたい場合 — investigating-windows-endpoints を使用してください
• 稼働中の Linux ホストで永続化の痕跡を一掃する場合 — analyzing-linux-persistence を使用してください
• スコープ設定、封じ込め、根絶など、より広範なインシデント対応プロセスが必要な場合 — responding-to-incidents を使用してください
• 特定のサンプルを復元し、実行して分析したい場合 — analyzing-malware を使用してください

取得と完全性

イメージがディスクの正確なコピーであると証明できなければ、その後の作業はすべて無意味です。書き込みブロッカーなしで元のメディアに触れてはいけません。また、元のイメージを分析せず、コピーを使ってください。

# Acquire to E01 (EWF) with built-in compression and hashing — preferred format
sudo ewfacquire -t /evidence/host01 -f encase6 -c deflate:fast \
     -C "IR-2026-014" -E "1" -D "Dell OptiPlex sda" /dev/sda

# Raw acquisition alternative — dd with error handling, hash inline
sudo dd if=/dev/sda bs=4M conv=noerror,sync status=progress \
     | tee /evidence/host01.dd | sha256sum

# Verify an existing E01 against its stored hashes
ewfverify /evidence/host01.E01

# Hash the working copy and record it — MD5 and SHA-256 both, for legacy tooling
md5sum   /evidence/host01.dd
sha256sum /evidence/host01.dd

後回しにせず、取得時に記録してください：

Evidence ID | Source host/serial | Collected by | UTC timestamp | Tool + version
Write blocker used (Y/N + model) | MD5 + SHA-256 at acquisition
SHA-256 verified after each copy | Custodian at each handoff | Storage location

コピーまたは転送のたびにハッシュを検証してください。不一致があれば作業を中止してください。想定している証拠を保持できていないことになります。訴訟や規制当局への対応に発展する可能性がある場合は、取得前に法務部門に相談してください。

イメージを変更せずに raw デバイスとして公開します。 E01 と AFF4 はコンテナー形式です。TSK の多くの操作やマウント操作では、raw ブロックデバイスまたはファイルが必要です。

# Mount an E01 as a raw device (read-only, FUSE) — exposes ./ewf1
ewfmount /evidence/host01.E01 /mnt/ewf
# /mnt/ewf/ewf1 is now a raw image you can feed to mmls, fls, mount -o loop, etc.

# xmount can also convert on the fly (E01 -> raw or VDI) without a second copy
xmount --in ewf /evidence/host01.E01 --out raw /mnt/xmount

マウントとパーティションレイアウト

何かをマウントする前に、ディスクの構成を把握してください。オフセットは重要です。誤った位置でマウントすると、何も表示されないか、意味のないデータが表示されます。

# Sleuth Kit partition table — gives you the starting SECTOR of each volume
mmls /mnt/ewf/ewf1
#   Slot   Start        End          Length       Description
#   002    0000002048   0000206847   0000204800   NTFS / exFAT (0x07)
#   003    0000206848   0976771071   0976564224   NTFS / exFAT (0x07)

# Cross-check with fdisk
fdisk -l /mnt/ewf/ewf1

# Loopback-mount a partition read-only. Offset = start_sector * 512.
# 206848 * 512 = 105906176
sudo mount -o ro,noexec,norecover,loop,offset=105906176 \
     /mnt/ewf/ewf1 /mnt/evidence

ro,noexec は書き込みと誤実行を防ぎます。norecover は、マウント時に ntfs-3g が NTFS ジャーナルを再生する（書き込みを行う）のを防ぎます。ext4 では ro,noload を使用してください。ジャーナルの再生は、調査担当者が証拠を知らないうちに変更してしまう典型的な原因です。

階層化ボリュームと暗号化ボリューム：

# LVM — scan and activate, then mount the logical volume read-only
sudo losetup -r -f -P /mnt/ewf/ewf1
sudo pvscan && sudo vgchange -ay
sudo mount -o ro /dev/mapper/vg0-root /mnt/evidence

# LUKS — needs the passphrase or a recovered key file
sudo cryptsetup --readonly luksOpen /dev/loop0p2 evd_crypt
sudo mount -o ro /dev/mapper/evd_crypt /mnt/evidence

# BitLocker — dislocker with a recovery key, clear key, or FVEK
sudo dislocker -r -V /dev/loop0p2 -p<48-digit-recovery-key> -- /mnt/bde
sudo mount -o ro,loop /mnt/bde/dislocker-file /mnt/evidence

# macOS APFS / HFS+ — apfs-fuse for APFS containers, read-only
apfs-fuse -o ro /dev/loop0p2 /mnt/evidence      # APFS
sudo mount -t hfsplus -o ro,loop /dev/loop0p2 /mnt/evidence   # HFS+

BitLocker 回復キーまたは LUKS パスフレーズがなければ、暗号化されたボリュームは手の打ちようがありません。暗号を破ろうとするのではなく、キー（エスクロー、AD、MDM、メモリイメージ、付箋など）を探してください。

The Sleuth Kit のワークフロー

TSK はイメージからファイルシステムを直接読み取ります。マウントも OS による解釈も不要で、稼働中の状態では隠される削除済みエントリーも確認できます。各 TSK コマンドにオフセット（セクター単位の -o）を指定し、正しいパーティションを対象にしてください。

# List files including deleted (*) ones, recursively, from the NTFS at sector 206848
fls -r -o 206848 /mnt/ewf/ewf1
#   r/r * 5613-128-1:  Users/jdoe/AppData/.../invoice.xlsx   <- deleted

# Detail a specific inode/MFT entry: timestamps, allocation, data runs
istat -o 206848 /mnt/ewf/ewf1 5613

# Extract a file BY INODE, even when deleted, straight out of the image
icat -o 206848 /mnt/ewf/ewf1 5613-128-1 > /evidence/recovered/invoice.xlsx

# Dump all unallocated blocks for carving
blkls -o 206848 /mnt/ewf/ewf1 > /evidence/unalloc.dd

# Bulk-recover every allocated and deleted file TSK can reconstruct
tsk_recover -e -o 206848 /mnt/ewf/ewf1 /evidence/recovered/

inode に対する icat は、最も確実な復元方法です。$MFT レコードとデータランが残っていれば、カービングの推測に頼らず、ファイルを正確に取り出せます。Autopsy は TSK の GUI です。上記のすべて（fls／istat／icat、キーワードインデックス作成、タイムライン、カービング）をケース管理インターフェースに統合しており、スクリプトを使うより閲覧したい場合に適したツールです。

ファイルシステムのタイムラインとスーパータイムライン

タイムラインは、ほかのすべての作業が支える成果物です。タイムラインを 2 つ作成します。まずファイルシステムの簡易タイムラインを作成し、アプリケーションレベルのイベントが必要な場合は、完全なスーパータイムラインを作成します。

# 1. File-system timeline (MAC times) from the whole image via TSK
fls -r -m "/" -o 206848 /mnt/ewf/ewf1 > /evidence/body.txt
mactime -b /evidence/body.txt -d -z UTC > /evidence/fs_timeline.csv
# Filter to a window:
mactime -b /evidence/body.txt -d -z UTC 2026-07-10..2026-07-13 > /evidence/window.csv

# 2. Super-timeline with Plaso across the ENTIRE image (all partitions, all parsers)
log2timeline.py --storage-file /evidence/host01.plaso /mnt/ewf/ewf1

# Render, filtered to the incident window, sorted, UTC
psort.py -o l2tcsv -z UTC \
     -w /evidence/super_timeline.csv /evidence/host01.plaso \
     "date > '2026-07-10 00:00:00' AND date < '2026-07-13 23:59:59'"

Plaso はレジストリ、イベントログ、プリフェッチ、ブラウザー履歴、LNK ファイル、$MFT、$UsnJrnl など数十種類のデータを解析し、正規化された単一のタイムラインにまとめます。これは MAC 時刻だけの場合よりはるかに豊富な情報を提供します。CSV を Timeline Explorer（Eric Zimmerman）に読み込めば、対話的にフィルタリング、色分け、ピボット分析ができます。テキストエディターでは、100 万行のスーパータイムラインを扱えません。すべて UTC で記録し、各行の出典アーティファクトを明記してください。

削除ファイルの復元とカービング

異なる2つの手法があります。復元では、データを引き続き指し示しているファイルシステムのメタデータを使用します。一方、カービングではメタデータを完全に無視し、コンテンツのシグネチャからファイルを特定します。両方を実行してください。

# Metadata-based recovery (already shown) — precise, keeps filenames
tsk_recover -e -o 206848 /mnt/ewf/ewf1 /evidence/recovered/

# Signature carving over unallocated space — recovers files whose MFT record is gone
photorec /evidence/unalloc.dd            # interactive; broadest format support
foremost -o /evidence/foremost -c /etc/foremost.conf /evidence/unalloc.dd
scalpel -o /evidence/scalpel /evidence/unalloc.dd    # foremost successor, configurable

# bulk_extractor — structured artifacts across the RAW image, no file system needed
bulk_extractor -o /evidence/be_out /mnt/ewf/ewf1
#   emails, URLs, credit-card numbers (with Luhn validation), search terms,
#   PII, EXIF, PGP keys, and *_histogram.txt files. Read the histograms first —
#   frequency-stacked domains and emails surface C2 and exfil targets fast.

削除されたコンテンツだけが必要な場合は blkls の出力からカービングし、ファイルスラックを含むすべてのデータが必要な場合は、完全な raw イメージからカービングしてください。カービングしたファイルにはタイムスタンプも名前もありません。コンテンツと位置を使ってタイムラインと照合してください。

OS 別のアーティファクトの宝庫

削除ファイルは全体の半分にすぎません。価値の高いフォレンジックアーティファクトは、何が実行され、何が接続され、何が開かれたかを記録したシステム自体の記録です。

Windows — 読み取り専用でマウントしてから、ハイブとジャーナルを取得します。

# Registry hives (system-wide + per-user)
#   SOFTWARE, SYSTEM, SAM   -> C:\Windows\System32\config\
#   NTUSER.DAT              -> C:\Users\<user>\
RECmd.exe --f "/mnt/evidence/Windows/System32/config/SYSTEM" --bn Services.reb
rip.pl -r /mnt/evidence/Windows/System32/config/SOFTWARE -f software  # RegRipper

# NTFS journals — extract by inode with icat, then parse
#   $MFT (0), $LogFile (2), $UsnJrnl:$J
icat -o 206848 /mnt/ewf/ewf1 0-128-1 > /evidence/\$MFT
MFTECmd.exe -f "/evidence/\$MFT" --csv /evidence/ --csvf mft.csv

Windows のアーティファクト分析は奥が深く、プリフェッチ、amcache、shimcache、shellbags、ジャンプリスト、イベントログ、SRUM などがあります。アーティファクトごとの詳細な調査は investigating-windows-endpoints に引き継いでください。ここでは、イメージから生のハイブとジャーナルを抽出し、完全な状態のまま渡します。

Linux — 証拠はテキストで、予想どおりの場所にあります。

#   /var/log/{auth.log,syslog,secure,journal}   authentication + system events
#   /home/*/.bash_history, /root/.bash_history  command history
#   /etc/{crontab,cron.d,rc.local}, /etc/systemd, ~/.ssh/authorized_keys
#   /etc/passwd, /etc/shadow, /etc/ld.so.preload  accounts + preload persistence
grep -aiE "sudo|ssh|useradd|wget|curl" /mnt/evidence/var/log/auth.log

init パスに沿って体系的に永続化を調査するには、analyzing-linux-persistence に従ってください。

macOS — 統合ログとプロパティリストです。

#   /var/db/diagnostics/*.tracev3          unified log (parse with `log show`)
#   /Library/LaunchDaemons, ~/Library/LaunchAgents   persistence plists
#   ~/Library/Preferences/*.plist          app state, recent items
plutil -p /mnt/evidence/Library/LaunchDaemons/com.suspect.plist

レジストリとハイブの調査

オフラインでのハイブ解析は、Windows イメージにおける最も豊富な情報源の1つです。ログには残らない実行履歴、デバイス履歴、ユーザーの活動が記録されています。

# Autoruns / persistence from the hives
rip.pl -r /mnt/evidence/Windows/System32/config/SOFTWARE -p soft_run
RECmd.exe --f "/mnt/evidence/.../NTUSER.DAT" --bn RunMRU.reb --csv /evidence/

# LastWrite times on keys are effectively per-key timestamps — treat them as evidence
# Shellbags — folders a user browsed, including now-deleted/removable paths
SBECmd.exe -d /mnt/evidence/Users/jdoe -o /evidence/shellbags/
# USB device history — SYSTEM\MountedDevices, USBSTOR; SOFTWARE\...\Windows Portable Devices
rip.pl -r /mnt/evidence/Windows/System32/config/SYSTEM -p usbstor

主要な LastWrite 時刻を使うと、設定や永続化の変更をタイムライン上に位置付けられます。Shellbags と USBSTOR は、現在のライブファイルシステムには表示されないデータへのアクセスやリムーバブルメディアの使用を証明することがよくあります。

アンチフォレンジックと隠されたデータ

対象者が何かを隠そうとしたことを前提としてください。隠蔽の痕跡そのものが調査結果になります。

• タイムスタンプの改ざん — $STANDARD_INFORMATION の時刻は簡単に偽造できますが、$MFT の $FILE_NAME 属性はそうではありません。両者が一致しない場合や、サブ秒精度が不自然にゼロになっている場合は、改ざんの証拠です。MFTECmd では両方を確認できます。比較してください。
• 痕跡の消去 — $MFT レコードは残っているのに、そのデータランが上書き済みのクラスタを指しているファイル、inode 番号の欠落、またはプリフェッチや amcache に残るワイプツール（sdelete、BleachBit）の痕跡を調べます。
• スラック領域 — ファイルスラックとボリュームスラックには、以前そこに存在していたデータの断片が残っていることがあります。blkls -s はスラック領域のみを抽出します。
• 代替データストリーム — NTFS ADS はプライマリストリーム以外の場所にデータを隠します。fls -r には追加の :stream エントリとして表示され、istat にはすべての $DATA 属性が一覧表示されます。
• ステガノグラフィーの手掛かり — 表示されるコンテンツに比べて極端に大きい画像、既知のステガノグラフィーツールの痕跡、ファイルの論理 EOF の後に追加されたデータなどです。
• 暗号化コンテナ — VeraCrypt/TrueCrypt ボリュームは、ヘッダーがなく、サイズが一定の倍数である高エントロピーのファイルに見えます。隠しボリュームは外側のボリュームの空き領域に存在します。bulk_extractor のエントロピー表示とファイルサイズの外れ値を使って候補を見つけてください。

# Enumerate ADS across a mounted NTFS image
fls -r -o 206848 /mnt/ewf/ewf1 | grep ':'
# Extract slack for carving
blkls -s -o 206848 /mnt/ewf/ewf1 > /evidence/slack.dd

大規模な文字列検索とキーワード検索

答えの場所がわからない場合や、ディスク全体を対象に仮説を検証する必要がある場合に使用します。

# bulk_extractor is the scalable default — indexed, structured, histogrammed
bulk_extractor -o /evidence/be_out /mnt/ewf/ewf1
grep -f keywords.txt /evidence/be_out/*_histogram.txt

# Raw strings + grep on the image (ASCII and UTF-16LE), when you need a specific token
strings -a -t d      /mnt/ewf/ewf1 | grep -aiF -f keywords.txt
strings -a -t d -e l /mnt/ewf/ewf1 | grep -aiF -f keywords.txt

# YARA across the entire raw image — malware and IOC hunting on disk
yara -s -r /evidence/rules/incident.yar /mnt/ewf/ewf1

展開された形式の文字列、設定ブロック、厳密な条件ロジックなど、ディスクアーティファクトに対する効果的な YARA ルールの作成方法については、writing-yara-rules を参照してください。文字列ヒットで得た -t d のバイトオフセットを mmls/ifind に渡すと、生のオフセットをファイルに対応付けられます。

タイムラインの報告と引き継ぎ

ディスク分析は、より大規模な調査における入力の1つです。次の段階で作業をやり直さずに活用できるよう、まとめてください。

• タイムラインを提出する — UTCで記載し、各行に出典となるアーティファクトを1つ引用し、観測事項と推定事項を分けて示します。構成についてはreporting-security-findingsを参照してください。
• 証拠台帳 — イメージID、取得時および検証時のハッシュ、保管履歴、復元したすべてのファイルと、その出典となる inode／オフセットを記録します。
• 揮発性証拠を適切な工程に回す — 復元したメモリイメージまたは休止状態ファイル／ページファイルはanalyzing-memory-imagesへ、解析のために投入する復元済みの実行ファイルまたは文書はanalyzing-malwareへ引き継ぎます。
• 不足している情報を明記する — 消去された領域、欠落したパーティション、開けなかった暗号化データ、ログの保存期間の制限を明示し、「何もなかった」と誤解されないようにします。

退けるべき合理化

• 「ファイルは削除されたので、もう存在しない。」 クラスターが再利用されるまでは未割り当て領域から復元できます。また、データランを持つ$MFTレコードが残っていることも多く、icatまたはtsk_recoverで正確に再構成できます。
• 「マウントして閲覧すればいい。」 まず読み取り専用でマウントしてハッシュを計算してください。そうしなければ証拠を改変することになります。既定のマウントではジャーナルが再生されます。これは、保全しようとしている対象への書き込みです。
• 「ハッシュの計算は作業が終わってからでいい。」 取得時にハッシュを計算しなければ、イメージがディスクと一致することを証明できず、弁護側の専門家にもそう指摘されます。完全性は収集時に立証するか、まったく立証できないかのどちらかです。
• 「稼働中のファイルシステムに、関係するものはすべて表示されている。」 削除されたエントリ、ADS、スラック領域、未割り当てデータは表示されません。まさに、消し去りたいものが置かれる場所です。稼働中の表示は、ディスクのごく一部にすぎません。
• 「タイムスタンプを見れば、いつ起きたかわかる。」 $STANDARD_INFORMATIONは数秒で偽装できます。$FILE_NAME、$UsnJrnl、LastWrite時刻を信頼し、それらの不一致はノイズではなく調査結果として扱ってください。
• 「暗号化されているので、何もできない。」 ボリュームを読み取れないと結論付ける前に、キーを探してください。エスクロー、AD、MDM、復元したメモリイメージ、パスフレーズやFVEKが残っている可能性のある未割り当て領域などを調べます。
• 「カービングでファイルを取り出せたので、それで十分だ。」 カービングしたファイルにはメタデータ、名前、タイムスタンプがありません。ファイルシステムのタイムラインと inode の出典に照合しなければ、どこから来たのか、いつのものなのかを説明できません。

参考資料

• analyzing-memory-images — 復元したRAMキャプチャ、hiberfil、またはpagefile
• investigating-windows-endpoints — Windowsアーティファクトを1つずつ調査する手順
• analyzing-linux-persistence — initパスにおける永続化を体系的に調査する手順
• responding-to-incidents — この分析が組み込まれる、より広範なIRプロセス
• analyzing-malware — 復元したサンプルを実行して分析する手順
• writing-yara-rules — イメージとカービング出力をスキャンするためのYARA
• reporting-security-findings — タイムラインと証拠台帳の構成
• The Sleuth Kit / Autopsy（sleuthkit.org）、Plaso / log2timeline（plaso.readthedocs.io）
• bulk_extractor（github.com/simsong/bulk_extractor）、PhotoRec / foremost / scalpel
• libewf / ewf-tools（ewfacquire、ewfverify、ewfmount）、RegRipper、Eric Zimmerman tools （MFTECmd、RECmd、SBECmd、Timeline Explorer）