フォレンジック系コマンド記事の第6弾です。第1〜5弾でイベントログ・ネットワーク証跡・USB・メモリ・ブラウザ・レジストリ・アンチフォレンジック・スマートフォン接続・横展開・DNSトンネリング・仮想マシン・PowerShell難読化など、実に広い領域を扱ってきました。今回もまだ未踏のテーマが残っています。
今回のテーマは「MFT・inode ファイルシステムの深層分析」「Auditdによる高精度な操作追跡（Linux）」「クラウドCLIの操作証跡」「プリンタ・クリップボード・サムネイルの意外な痕跡」「SQLiteデータベースを使うアプリの証跡」の5本柱です。「まさかそんなところに証拠が残っているとは」という驚きのある内容をお届けします。
⚠️ 重要： 本記事の内容は自分が管理するシステムの調査・学習を目的としています。他者のシステムへの無断調査は不正アクセス禁止法の対象です。組織内での調査は必ず法務・情報セキュリティ部門の承認のもとで実施してください。
目次
- 【MFT・inode 深層分析編】ファイルシステムの「地層」を読み解くコマンド
- 【Auditd 高精度追跡編】Linuxの操作をミクロ単位で記録・分析するコマンド
- 【クラウドCLI証跡編】AWS・Azure・GCPの操作履歴を追うコマンド
- 【意外な証跡編】プリンタ・クリップボード・サムネイルに残る痕跡
- 【SQLiteアプリ証跡編】日常アプリが記録し続けるデータベースを読む
- まとめ
【MFT・inode 深層分析編】ファイルシステムの「地層」を読み解くコマンド
ファイルシステムにはOSが自動的に維持する「メタデータの地層」があります。NTFSのMFT（Master File Table）はWindowsファイルシステムの根幹で、すべてのファイルとフォルダの存在・属性・タイムスタンプ・断片化情報を1エントリ1KBのレコードとして記録しています。ファイルを削除してもMFTのエントリはすぐには消えず、再利用されるまで痕跡が残ります。
💡 FACT： NTFSのMFTは1988年にMicrosoftがWindows NT向けに設計したファイルシステムの中核です。MFTには各ファイルについて「$STANDARD_INFORMATION」（標準タイムスタンプ）と「$FILE_NAME」（ファイル名タイムスタンプ）の2種類のタイムスタンプが存在し、攻撃者がタイムスタンプを偽装（timestomping）しても両者を比較することで改ざんを検出できます。SANS DFIR研究チームはこの手法を「タイムスタンプの矛盾検出」と呼び、標準的な検出手法として紹介しています。
① MFTの内容をコマンドで読み解く（Windows）
MFTファイル（$MFT）はシステムが使用中のため直接開けませんが、ボリュームシャドウコピーや専用ツールを経由して読み取れます。
Windows（PowerShell）：
# $MFTファイルの存在とサイズを確認（直接開けないがサイズは確認可）
$mft = Get-Item "C:\`$MFT" -Force -ErrorAction SilentlyContinue
if ($mft) {
Write-Host "MFTサイズ: $([math]::Round($mft.Length / 1MB, 1)) MB"
Write-Host "MFT エントリ数（概算）: $([math]::Round($mft.Length / 1024)) エントリ"
} else {
Write-Host "直接アクセス不可（管理者権限でVolume Shadow Copyから取得を推奨）"
}
# ボリュームシャドウコピーから$MFTを取得する
$vss = Get-WmiObject -Query "SELECT * FROM Win32_ShadowCopy" | Select-Object -First 1
if ($vss) {
$link = $vss.DeviceObject + "\"
Write-Host "VSS経由のパス: $link"
# cmd.exe /c "mklink /d C:\vss_mount $link" で仮想ドライブとしてマウント可能
}
# MFTParser（Eric Zimmerman製・無償）を使った解析コマンド例
# .\MFTECmd.exe -f "C:\`$MFT" --csv "C:\forensics\" --csvf mft_output.csv
# NTFSのボリューム情報を確認（クラスタサイズ・MFTの開始位置等）
fsutil fsinfo ntfsinfo C:② ボリュームシャドウコピーを証拠として活用する（Windows）
ボリュームシャドウコピー（VSS）はWindowsが自動的に作成するディスクの「スナップショット」です。削除・変更される前のファイルがここに残っていることがあります。ランサムウェアが最初に削除するのもこのVSSであるほど、フォレンジック的に価値が高いデータです。
Windows（コマンドプロンプト / PowerShell）：
# 現在のVSSスナップショット一覧（作成日時・サイズ）
vssadmin list shadows
vssadmin list shadows /for=C:
# PowerShellで詳細情報を取得
Get-WmiObject Win32_ShadowCopy |
Select-Object ID, VolumeName, InstallDate, DeviceObject |
Sort-Object InstallDate -Descending | Format-Table -AutoSize
# 最新のシャドウコピーをドライブとしてマウント（管理者権限）
$shadow = (Get-WmiObject Win32_ShadowCopy | Sort-Object InstallDate -Descending | Select-Object -First 1).DeviceObject
cmd /c "mklink /d C:\shadow_mount `"$shadow\`""
# マウント後は C:\shadow_mount\ から過去のファイルにアクセス可能
# シャドウコピーが削除された痕跡を確認（ランサムウェアの典型行動）
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='VSS'} -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match "delete\|削除" } |
Select-Object TimeCreated, Message | Select-Object -First 10
# vssadminコマンドでの削除をイベントID 4688から確認
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -ErrorAction SilentlyContinue |
Where-Object { $_.Properties[8].Value -match "vssadmin.*delete\|wmic.*shadowcopy.*delete" } |
Select-Object TimeCreated, @{N='CmdLine';E={$_.Properties[8].Value}} |
Sort-Object TimeCreated -Descending③ Linuxのinode情報でファイルの真の歴史を読む
Linuxのinodeはファイルの実体データとは別に保存されるメタデータブロックです。ファイル名・パーミッション・所有者・タイムスタンプ・ハードリンク数を記録しており、ファイルシステムレベルの詳細調査に不可欠です。
macOS / Linux：
# inodeの詳細情報を確認（3種類のタイムスタンプ）
stat /path/to/file
# atime: 最終アクセス時刻
# mtime: 最終内容変更時刻
# ctime: 最終inode変更時刻（パーミッション変更・リンク変更も含む）
# inodeの番号を確認（同じinodeを指すハードリンクを探すのに使う）
ls -i /path/to/file
stat -c "%i" /path/to/file # Linux
# 同じinodeを持つファイル（ハードリンク）を全検索
INODE=$(stat -c "%i" /path/to/file)
find / -inum $INODE 2>/dev/null
# 複数のパスが表示された場合、別名のハードリンクが存在する
# 削除されたファイルのinode痕跡を確認（The Sleuth Kit）
sudo apt install sleuthkit 2>/dev/null
sudo ils /dev/sda1 | head -30 # 削除済みinode一覧
sudo istat /dev/sda1 # 特定inodeの詳細
# 最近ctimeが変わったファイルを検索（inode変更=権限変更やリンク操作）
find /usr /bin /sbin -ctime -1 -type f 2>/dev/null | head -20【Auditd 高精度追跡編】Linuxの操作をミクロ単位で記録・分析するコマンド
Linuxのauditd（Audit Daemon）はシステムコールレベルでの操作をリアルタイム記録するカーネル組み込みの監査フレームワークです。ファイルアクセス・ユーザー認証・プロセス実行・ネットワーク接続・権限昇格のすべてをルール設定に応じて記録します。デフォルト設定では限定的なログしか取れませんが、ルールを追加することで法執行機関レベルの証拠品質のログを収集できます。
💡 FACT： 米国国防総省のSTIG（Security Technical Implementation Guide）では、Linuxサーバーに対してauditdによる監査ルールの設定を必須要件として定めています。CISベンチマーク（Center for Internet Security）でもauditdの設定は「Level 2」セキュリティの必須項目とされており、コンプライアンス要件のある環境では標準的に実装されています。
① auditdの基本的なログ確認と分析
Linux：
# auditdの動作状態を確認
sudo systemctl status auditd
sudo auditctl -s # 現在の監査ルールの統計
# 現在のルール一覧を確認
sudo auditctl -l
# 過去のすべての監査イベントを検索
sudo ausearch -ts today # 今日のイベント
sudo ausearch -ts week-ago # 過去1週間
sudo ausearch -ts "2025-03-01 00:00:00" -te "2025-03-01 23:59:59" # 特定日
# イベントタイプ別に検索
sudo ausearch -m USER_LOGIN # ログインイベント
sudo ausearch -m USER_AUTH # 認証イベント
sudo ausearch -m EXECVE # コマンド実行イベント
sudo ausearch -m SYSCALL -sc openat # openatシステムコールを追跡
# 特定ユーザーの操作を追跡
sudo ausearch -ua username --interpret | head -100
# 人間が読みやすい形式でレポート生成
sudo aureport -au # 認証の要約レポート
sudo aureport -x # 実行コマンドの要約レポート
sudo aureport -f # ファイルアクセスの要約レポート
sudo aureport --failed # 失敗したイベントのみ② 高度な監査ルールを設定して証拠収集能力を上げる
Linux（管理者権限）：
# 機密ファイルへのアクセスを監査するルールを追加
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/shadow -p wa -k shadow_changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes
# 特定ディレクトリのすべての操作を記録
sudo auditctl -w /var/www/html -p rwxa -k web_access
sudo auditctl -w /home -p rwa -k home_access
# 特権コマンドの実行をすべて記録
sudo auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
# ネットワーク接続の作成を記録
sudo auditctl -a always,exit -F arch=b64 -S connect -k network_connect
# ルールを永続化（再起動後も有効）
sudo bash -c 'cat >> /etc/audit/rules.d/forensics.rules << EOF
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
-a always,exit -F arch=b64 -S connect -k network_connect
EOF'
sudo augenrules --load③ auditdログの高度な分析・相関
Linux：
# 特定のキーワードで記録されたイベントを分析
sudo ausearch -k passwd_changes --interpret | grep -A 5 "type=SYSCALL"
# 誰がいつsudoを使ったか一覧
sudo ausearch -m USER_CMD | grep "cmd=" | awk -F'cmd=' '{print $2}' | sort | uniq -c | sort -rn | head -20
# 特定ファイルへのアクセス試行を時系列で表示
sudo ausearch -k web_access -ts week-ago --interpret |
grep -E "^----$|type=PATH|type=SYSCALL|auid=|uid=" | head -100
# 権限昇格（SUID実行）の痕跡を確認
sudo ausearch -m SYSCALL -sc execve 2>/dev/null |
grep -B5 "euid=0" | grep -E "exe=|auid=" | head -40
# 失敗した権限昇格の試みを集計
sudo aureport --failed -au | head -30【クラウドCLI証跡編】AWS・Azure・GCPの操作履歴を追うコマンド
クラウド環境への移行が進む現代では、クラウドサービスに対する操作の証跡調査が不可欠になっています。総務省「クラウドサービスの利用動向調査（2024年）」によると、国内企業のクラウド利用率は72.2%に達し、クラウド環境を標的にしたインシデントも急増しています。CLIツールの操作履歴やクラウド側のAPIログは、侵害の特定に重要な証拠になります。
① AWS CLIの操作証跡を調べる
macOS / Linux / Windows 共通：
# AWS CLIの設定ファイルと認証情報の場所を確認
# macOS/Linux
cat ~/.aws/credentials # アクセスキーの確認（誰の認証情報が設定されているか）
cat ~/.aws/config # リージョン・プロファイル設定
ls -la ~/.aws/ # ディレクトリ全体の確認
# Windows
type %USERPROFILE%\.aws\credentials
type %USERPROFILE%\.aws\config
# AWS CLIのコマンド実行履歴（bash/zsh履歴から）
grep "aws " ~/.bash_history ~/.zsh_history 2>/dev/null | tail -50
# AWS CLIがどのバージョンかを確認
aws --version
# AWS CLIのデバッグログで過去のAPI呼び出しを確認
# AWS_CLI_FILE_ENCODINGやAWS_DEFAULT_OUTPUT等の環境変数も確認
env | grep -i "AWS_"
# CloudTrailのログをCLIで検索（AWSアカウントにアクセス権がある場合）
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=Username,AttributeValue=suspicious_user \
--start-time 2025-02-01 --end-time 2025-03-01 \
--query 'Events[*].[EventTime,EventName,Username,SourceIPAddress]' \
--output table 2>/dev/null
# 不審なIAMユーザー・ロールの操作を確認
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser \
--query 'Events[*].[EventTime,Username,SourceIPAddress]' \
--output table 2>/dev/null💡 FACT： AWSのCloudTrailは有効化すると全APIコールを90日間記録します（無料）。S3バケットへの長期保存を設定すれば無期限に保持でき、AWSのセキュリティベストプラクティスでも最優先で有効化すべき機能として位置づけられています。CloudTrailが無効化されていた場合、その無効化操作自体が最後のCloudTrailイベントとして記録されるため、無効化の事実は隠せません。
② Azure CLIの操作証跡を調べる
macOS / Linux / Windows 共通：
# Azure CLIの認証状態と設定確認
az account show 2>/dev/null
az account list --output table 2>/dev/null
# ログインしているユーザー・サービスプリンシパルを確認
az account get-access-token --query '{user:name, exp:expiresOn}' 2>/dev/null
# Azure CLIのコマンド履歴（bash/zsh/PowerShell履歴から）
grep "az " ~/.bash_history ~/.zsh_history 2>/dev/null | tail -50
# Azure Activity Logで過去の操作履歴を取得（サブスクリプションの権限が必要）
az monitor activity-log list \
--start-time 2025-02-01T00:00:00Z \
--end-time 2025-03-01T00:00:00Z \
--query '[*].{time:eventTimestamp,caller:caller,operation:operationName.value,status:status.value}' \
--output table 2>/dev/null | head -50
# 不審なロール割り当ての変更を確認
az monitor activity-log list \
--query '[?contains(operationName.value, `roleAssignment`)].{time:eventTimestamp,caller:caller,op:operationName.value}' \
--output table 2>/dev/null③ GCP（Google Cloud）CLIの操作証跡を調べる
macOS / Linux / Windows 共通：
# gcloud CLIの設定確認
gcloud config list 2>/dev/null
gcloud auth list 2>/dev/null # 認証済みアカウント一覧
# gcloudコマンドの実行履歴
grep "gcloud " ~/.bash_history ~/.zsh_history 2>/dev/null | tail -50
cat ~/.config/gcloud/logs/*/2025.*/0.log 2>/dev/null | tail -100 # gcloudの内部ログ
# Cloud Audit Logsで過去の操作を確認（プロジェクトのアクセス権が必要）
gcloud logging read "logName=projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity" \
--freshness=7d \
--format="table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.methodName,protoPayload.requestMetadata.callerIp)" \
2>/dev/null | head -30
# IAMポリシーの変更ログを確認
gcloud logging read 'protoPayload.methodName="SetIamPolicy"' \
--freshness=30d \
--format="table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.request)" \
2>/dev/null | head -20【意外な証跡編】プリンタ・クリップボード・サムネイルに残る痕跡
「まさかこんなところに証拠が」と思わせる、見落とされがちな痕跡の宝庫を紹介します。内部犯行の調査では特に、紙に印刷してオフィスから持ち出す手口や、スクリーンショット・コピーペーストによるデータ抜き出しの証拠が問題になります。
① 印刷ジョブの履歴を調べる（Windows）
Windowsはプリントスプーラーへのジョブ送信をイベントログに記録します。「いつ・誰が・何を印刷したか」が後から確認できます。
Windows（PowerShell）：
# 印刷ジョブのイベントログ（Microsoft-Windows-PrintService/Operational）
# まずログが有効かを確認
Get-WinEvent -ListLog "Microsoft-Windows-PrintService/Operational" |
Select-Object LogName, IsEnabled, RecordCount
# 印刷ジョブの記録を取得（イベントID 307：印刷ドキュメントの記録）
Get-WinEvent -LogName "Microsoft-Windows-PrintService/Operational" -ErrorAction SilentlyContinue |
Where-Object { $_.Id -eq 307 } |
Select-Object TimeCreated,
@{N='User';E={$_.Properties[2].Value}},
@{N='Document';E={$_.Properties[1].Value}},
@{N='Printer';E={$_.Properties[4].Value}},
@{N='Pages';E={$_.Properties[7].Value}},
@{N='Bytes';E={$_.Properties[6].Value}} |
Sort-Object TimeCreated -Descending | Select-Object -First 50 | Format-Table -AutoSize
# 印刷ログを有効化するコマンド（無効の場合）
wevtutil sl "Microsoft-Windows-PrintService/Operational" /e:true
# スプーラーディレクトリのファイル確認（処理待ちまたは残留ジョブ）
Get-ChildItem "C:\Windows\System32\spool\PRINTERS" -Force |
Select-Object Name, LastWriteTime, Length | Sort-Object LastWriteTime -Descending② サムネイルキャッシュからファイルの存在を証明する（Windows）
Windowsエクスプローラーは画像・動画・ドキュメントのサムネイルを自動キャッシュします。ファイルを削除してもサムネイルが残ることがあり、「このPCに存在したことがある」ことを証明できます。
Windows（PowerShell）：
# サムネイルキャッシュの場所を確認
$thumbPath = "$env:LOCALAPPDATA\Microsoft\Windows\Explorer"
Get-ChildItem $thumbPath -Filter "thumbcache_*.db" |
Select-Object Name, LastWriteTime, @{N='SizeMB';E={[math]::Round($_.Length/1MB,2)}} |
Sort-Object LastWriteTime -Descending | Format-Table -AutoSize
# サムネイルキャッシュの最終更新日時は「直近でエクスプローラーが画像フォルダを開いた日時」を示す
# thumbcache_256.db: 中サイズのサムネイル（最もよく使われる）
# thumbcache_1024.db: 大サイズのプレビュー
# thumbcache_idx.db: インデックスファイル
# IconCacheも確認（アプリケーションの使用痕跡）
Get-ChildItem "$env:LOCALAPPDATA" -Filter "IconCache.db" -Force |
Select-Object FullName, LastWriteTime
# Windows 10/11ではthumbs.dbが各フォルダに残ることがある
Get-ChildItem "C:\Users" -Recurse -Include "thumbs.db","Thumbs.db" -Force -ErrorAction SilentlyContinue |
Select-Object FullName, LastWriteTime | Sort-Object LastWriteTime -Descending | Select-Object -First 20💡 FACT： Windowsのサムネイルキャッシュ（thumbcache）はファイルが削除された後もキャッシュが残ることがあります。フォレンジック調査では「このPCに画像・動画が存在していた」ことの状況証拠として使われます。Thumbnail Database Viewerなどのツールでキャッシュからサムネイル画像を復元することも可能です。
③ Windowsのクリップボード履歴を調べる
Windows 10以降では「クリップボード履歴」機能（Win+V）が搭載されており、コピーした内容が保存されています。
Windows（PowerShell）：
# クリップボード履歴が有効かどうか確認
reg query "HKCU\Software\Microsoft\Clipboard" /v EnableClipboardHistory 2>$null
# クリップボード履歴のデータファイルの場所
$clipPath = "$env:LOCALAPPDATA\Microsoft\Windows\Clipboard"
if (Test-Path $clipPath) {
Get-ChildItem $clipPath -Recurse -Force |
Select-Object FullName, LastWriteTime, @{N='SizeKB';E={[math]::Round($_.Length/1KB,1)}} |
Sort-Object LastWriteTime -Descending | Format-Table -AutoSize
}
# 現在のクリップボードの内容を表示（テキストのみ）
Add-Type -AssemblyName System.Windows.Forms
$clip = [System.Windows.Forms.Clipboard]::GetText()
if ($clip) {
Write-Host "現在のクリップボード内容（最初の200文字）:"
Write-Host $clip.Substring(0, [Math]::Min(200, $clip.Length))
}
# クリップボード関連のレジストリ設定を確認
reg query "HKCU\Software\Microsoft\Clipboard" /s④ macOSのクイックルック・サムネイルキャッシュを調べる
macOS：
# QuickLookのサムネイルキャッシュの場所
ls -la ~/Library/Caches/com.apple.QuickLook.thumbnailcache/ 2>/dev/null
du -sh ~/Library/Caches/com.apple.QuickLook.thumbnailcache/ 2>/dev/null
# より詳細な場所（macOSバージョンによって異なる）
find ~/Library/Caches -name "*.qlcache" -o -name "thumbnails*" 2>/dev/null | head -10
# Spotlightのインデックス（ファイルの内容検索インデックス）
# 削除済みファイルの情報が残っていることがある
sudo find /.Spotlight-V100 -name "*.plist" 2>/dev/null | head -5
# Recentlyプロパティリストから最近使ったファイルを確認
defaults read com.apple.recentitems 2>/dev/null | grep -A2 "Name\|Alias" | head -40【SQLiteアプリ証跡編】日常アプリが記録し続けるデータベースを読む
スマートフォン・デスクトップアプリ・ブラウザ・チャットツールの多くがSQLiteデータベースにデータを保存しています。第3弾ではブラウザのHistoryデータベースを取り上げましたが、今回はさらに広いアプリのSQLite証跡を掘り下げます。
① Slack・Teams・Discordのローカルキャッシュを調べる
Windows（PowerShell）：
# Slackのローカルデータ（SQLite + Electronキャッシュ）
$slackPath = "$env:APPDATA\Slack"
if (Test-Path $slackPath) {
Write-Host "=== Slack データ ==="
Get-ChildItem $slackPath -Recurse -Include "*.db","*.sqlite" -ErrorAction SilentlyContinue |
Select-Object FullName, LastWriteTime, @{N='SizeMB';E={[math]::Round($_.Length/1MB,2)}} |
Sort-Object LastWriteTime -Descending | Format-Table -AutoSize
}
# Microsoft Teamsのローカルキャッシュ（旧版）
$teamsPath = "$env:APPDATA\Microsoft\Teams"
if (Test-Path $teamsPath) {
Write-Host "=== Teams データ ==="
Get-ChildItem $teamsPath -Recurse -Include "*.db","*.sqlite","IndexedDB" -ErrorAction SilentlyContinue |
Select-Object FullName, LastWriteTime | Sort-Object LastWriteTime -Descending | Select-Object -First 10
}
# Teams (新版) のキャッシュ場所
$teamsNew = "$env:LOCALAPPDATA\Packages\MSTeams_*\LocalCache"
Get-ChildItem $teamsNew -Recurse -Include "*.db" -ErrorAction SilentlyContinue |
Select-Object FullName, LastWriteTime | Sort-Object LastWriteTime -Descending | Select-Object -First 10macOS：
# SlackのSQLiteデータベースを確認
find ~/Library/Application\ Support/Slack -name "*.db" -o -name "*.sqlite" 2>/dev/null |
xargs ls -lh 2>/dev/null
# Slack DBの内容を確認（テーブル一覧）
sqlite3 ~/Library/Application\ Support/Slack/*/db.sqlite ".tables" 2>/dev/null | head -5
# Discordのキャッシュ確認
find ~/Library/Application\ Support/discord -name "*.db" 2>/dev/null | xargs ls -lh 2>/dev/null② Windowsの通知履歴（Action Center）をSQLiteから読む
Windowsの通知センターは受信した通知をSQLiteデータベースに保存しています。「いつ・どのアプリから・どんな通知が来たか」を確認できます。
Windows（PowerShell）：
# 通知データベースの場所を確認
$notifPath = "$env:LOCALAPPDATA\Microsoft\Windows\Notifications"
if (Test-Path $notifPath) {
Get-ChildItem $notifPath -Include "*.db","wpndatabase.db" -Recurse |
Select-Object FullName, LastWriteTime, @{N='SizeKB';E={[math]::Round($_.Length/1KB,1)}}
}
# SQLite3でクエリ（wpndatabase.dbの主要テーブルを確認）
# ※ SQLite3.exeが必要
# sqlite3.exe "$env:LOCALAPPDATA\Microsoft\Windows\Notifications\wpndatabase.db" ".tables"
# PowerShellでSQLiteを使う（PSSQLiteモジュールを使用）
# Install-Module PSSQLite -Scope CurrentUser
# Invoke-SqliteQuery -DataSource "$env:LOCALAPPDATA\Microsoft\Windows\Notifications\wpndatabase.db" `
# -Query "SELECT * FROM Notification ORDER BY ArrivalTime DESC LIMIT 50"③ macOSのknowledgeC.db — 最も強力な活動履歴データベース
knowledgeC.dbはmacOS/iOSに存在する「活動知識データベース」です。アプリの使用時間・起動/終了・ユーザーの入力活動・デバイスの使用状態などが詳細に記録されており、「そのユーザーがその時刻にMacを使っていたか」を証明できます。
macOS：
# knowledgeC.dbの場所と更新日時を確認
ls -la ~/Library/Application\ Support/Knowledge/knowledgeC.db 2>/dev/null
# コピーしてから解析
cp ~/Library/Application\ Support/Knowledge/knowledgeC.db /tmp/knowledgeC_copy.db
# テーブル一覧を確認
sqlite3 /tmp/knowledgeC_copy.db ".tables"
# アプリの使用履歴を確認
sqlite3 /tmp/knowledgeC_copy.db \
"SELECT datetime(ZOBJECT.ZSTARTDATE + 978307200, 'unixepoch', 'localtime') as start_time,
datetime(ZOBJECT.ZENDDATE + 978307200, 'unixepoch', 'localtime') as end_time,
ZOBJECT.ZVALUESTRING as bundle_id
FROM ZOBJECT
WHERE ZOBJECT.ZSTREAMNAME = '/app/inFocus'
ORDER BY ZOBJECT.ZSTARTDATE DESC LIMIT 50;"
# ユーザーがキーボード・マウスを操作していた時間帯を確認
sqlite3 /tmp/knowledgeC_copy.db \
"SELECT datetime(ZSTARTDATE + 978307200, 'unixepoch', 'localtime') as active_time,
ZVALUESTRING as device_state
FROM ZOBJECT
WHERE ZSTREAMNAME = '/device/isBacklit'
ORDER BY ZSTARTDATE DESC LIMIT 30;"💡 FACT： macOSのknowledgeC.dbはiOSのScreen Time機能のデータソースでもあります。法執行機関のiOSフォレンジック調査では最重要データベースの一つとされており、アプリの起動・終了・ユーザーの操作活動が数ヶ月分記録されます。Sarah Edwards氏（SANS DFIR）がこのデータベースの詳細な解析手法を2019年に初めて公開したことで、macOSフォレンジックの重要性が広く認識されるようになりました。
まとめ
本記事で紹介したコマンドと手法を一覧にまとめました。
| カテゴリ | コマンド / 手法 | 調査目的 |
|---|---|---|
| MFT・inode分析 | fsutil fsinfo ntfsinfo / $MFTサイズ確認 | NTFSファイルシステムの基本情報取得 |
| MFT・inode分析 | vssadmin / Get-WmiObject Win32_ShadowCopy | VSS（シャドウコピー）の一覧とマウント |
| MFT・inode分析 | stat / ls -i / find -inum | inodeからハードリンク・タイムスタンプを追跡 |
| MFT・inode分析 | ils / istat（The Sleuth Kit） | 削除済みinodeの痕跡確認 |
| Auditd追跡 | ausearch / aureport | Linuxの操作ログ検索・要約レポート |
| Auditd追跡 | auditctl -w / -a always,exit | ファイル・コマンド実行の高精度監査ルール設定 |
| クラウドCLI | aws cloudtrail lookup-events | AWSの全API操作履歴の抽出 |
| クラウドCLI | az monitor activity-log list | Azureの操作・ロール変更の記録 |
| クラウドCLI | gcloud logging read | GCPのCloudAuditログの確認 |
| 意外な証跡 | PrintService/Operational イベントID 307 | 印刷ジョブの完全な記録（誰が何を印刷） |
| 意外な証跡 | thumbcache_*.db の確認 | 削除済み画像ファイルが存在した証拠 |
| 意外な証跡 | クリップボード履歴DBの確認 | コピーされたテキスト・データの確認 |
| 意外な証跡 | macOS QuickLook / Recentlyプロパティ | 開いたファイルのサムネイルキャッシュ |
| SQLiteアプリ証跡 | Slack / Teams の .db ファイル確認 | チャットツールのローカルキャッシュ |
| SQLiteアプリ証跡 | wpndatabase.db（Windows通知履歴） | アプリからの通知受信記録 |
| SQLiteアプリ証跡 | macOS knowledgeC.db | アプリ使用時間・ユーザー操作活動の詳細記録 |
「まさかここに証拠が」の重要性
今回の記事で特に強調したいのは、調査対象者が「消した」と思っているデータが、全く別の場所に残っているという現象です。
- 機密ファイルを削除しても → サムネイルキャッシュ・QuickLookキャッシュにサムネイルが残る
- ブラウザ履歴を消しても → knowledgeC.dbにアプリ使用時間が残る
- 印刷物を持ち出しても → PrintServiceイベントログに「いつ・何ページ・何を」が残る
- クリップボードをクリアしても → クリップボード履歴データベースに残る
- クラウドCLIの設定を消しても → クラウド側のAuditログに操作の全記録が残る
デジタルフォレンジックはOSとアプリケーションが無意識に記録し続けるデータを「読む」技術です。本シリーズ6弾を通じて、その「無意識の記録」がいかに広範囲にわたるかをご理解いただけたなら幸いです。
※ 本記事の内容は情報セキュリティの学習・自己管理目的で掲載しています。他者のシステムへの無断調査は不正アクセス禁止法により処罰の対象となります。クラウドサービスのログ取得は自分がアクセス権を持つアカウントのみで実施してください。企業・組織内での調査は法務・情報セキュリティ部門の承認のもとで実施してください。
コメント