親記事 → CTFにおけるフォレンジック入門とまとめ - はまやんはまやんはまやん
(若干、工事中)
ディスクイメージフォレンジック
- ディスクイメージをそのままダンプしてきて解析する問題
- ファイルシステムを仕様に沿ってちゃんと解析する難しい問題も見たことはあるが、基本的にはマウントして中に入っている情報から有意な情報を抜き出してくるような問題が多い
- そのため、ファイルシステムに対する理解というよりかは、入っているOSのファイルを保存のされ方とか解析方法が要求されている
ファイルシステム自体
- (あんま自信ないな。変なのが紛れ込んでるかも)
- ツールについて
- とりあえずFTK Imagerに突っ込めば中に入っているデータは見られる
- AutoPsyが読み込み対応していれば、自動で色々解析してくれる
- 削除済みアイテムも自動で復元してくれる
- mountコマンドでマウントできるかも
- ジャーナルファイル
- パーティション方式 MBR, GPT, ...
- ブートローダーの解析とかってCTFで出たことあるんでしょうか…?
- ファイルシステム ext4, NTFS, ...
- 暗号化ディスク
- TrueCrypt
- VeraCrypt
- BitLocker
- 削除済みファイル
- 普通の削除では参照が切れているだけでデータはまだ残っている。ツールを使えば復元可能。なんでもいいが、AutoPsyが使えるならオススメ
- RAIDの解析という難題もあるっぽい
Windows
- NTFS
- ADS: Alternate Data Stream
- USNジャーナル
- $MFT
- Windowsの見るところはたくさんあるが、有名どころを紹介しておく
- WindowsのアーティファクトのあれこれはだいたいEric Zimmerman's toolsで分析可能
- レジストリ
- ZimmermanToolsのRegistryExplorerで開いて読めばいい
- 保存場所
- PC全体
%SystemRoot%\System32\Config\
(%SystemRoot%はC:\Windows) - ユーザー固有
~\Ntuser.dat
- PC全体
- イベントログ
- evtxファイルであればイベントログ
%systemroot%\System32\winevt\logs
に入っている
- 標準のイベントビューワーで見てもいいし、ZimmermanToolsのEvtxECmd.exeで変換してTimelineExplorerやExcelで見るのがオススメだが、なんでもいい
- 経験値があれば見る場所の当たりがついたりするが、もう頑張って漁るしかない
- evtxファイルであればイベントログ
- 主要フォルダを漁ってみる
- Cドライブ直下
- Usersフォルダの中(特に%appdata%)
- ProgramData
- Program Filesから入っているソフトウェアを特定して設定ファイルとかログとか漁る
- プリフェッチ
C:\windows\Prefetch
に保存されている。exeの起動履歴を確認可能- WinPrefetchView
- WMIレポジトリ
- C:\WINDOWS\setupapi.log
- ドライバとかのログが入っている
- RDP Bitmap Cache (BMC)
- BMCとはRDPの画面キャッシュのこと。取り出して画面を一部盗み見れる
- ツール
- bmc-tools キャッシュを持ってきて、断片的な画像復元までできる
- RdpCacheStitcher 断片的な復元画像から画面全体の復元までできる
- 手動で置いていくのだが、隣り合っている可能性を色の濃淡で教えてくれる
- 他にもSRUMなど、ほんとに色々ある
- PowerShell解析
- よくWindows向けの攻撃で難読化されたPowerShellを解析する問題がよく見られる
- 難読化されたPowershellを解読していく
- 自分は実際のpowershellを使いながら、部分部分ちょこちょこ解読進めている
- 実際に動かすときは注意すること。せめてWindows Sandbox使うこと
- VBAスクリプト解析
- クラッシュログ
Linux
- あんまり知見なし
- inode
- 確認フォルダ
- カーネルクラッシュログ
- crashコマンドで開いてみていく
crash /usr/lib/debug/boot/vmlinux-5.4.0-99-generic ./ubuntu20.04-5.4.0-99-generic-cloudimg-20220215.kdump
- crashコマンド使い方(
>help
でヘルプが見られる)- 起動時
PANIC:
パニック理由が分かるCOMMAND:
パニックが起きたコマンド
>bt
back traceを確認可能>ps
タスクリスト> bt [pid]
でスタックトレースが見れる
>p [変数名]
グローバル変数が見れる>files [pid]
タスクごとのファイルディスクリプターが見られる>files
と単にやるとクラッシュしたもので見られる- foreachを使うやり方も色々紹介されている
>foreach files -R /var/log
foreach files -R /home
>mod
モジュール一覧表示- 実はgrepも使える
`>mod | grep xxx
- 実はgrepも使える
>net
IF表示
- 起動時
- crashコマンドで開いてみていく
- クラッシュログ
- クラッシュを引き起こすには
- Ctrl+zで離れてpsでPID探して
kill -SIGSEGV [pid]
でkillしてfg
で戻るとクラッシュするかも - クラッシュダンプは
/var/crashes
に置かれる
- Ctrl+zで離れてpsでPID探して
- apport-unpackでクラッシュダンプを解析する
apport-unpack _opt_count.1000.crash /tmp/crash-report
みたいに解凍- CoreDumpにメモリダンプが置かれる?
- クラッシュを引き起こすには
macOS
闇だとは聞くが、知見なし
.DS_Store
find . -name .DS_Store
- mnrkbys/DSStoreParser at fix_bug_non-ascii
Android環境の解析問題もある
- ログ解析
- 全体解析
- abファイル: Android Debug Bridge(adb)を使用したシステムバックアップ
( printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" ; tail -c +25 cat.ab ) | tar xfvz -
とすれば解凍可能
dockerコンテナ
- ディスクイメージとちょっと違うかもしれないが、dockerコンテナ自体が与えられて解析ということもある
- dive
- Dockerイメージを分析するツール
- Layer毎で何が起きたのかを一目で確認可能
- dockerイメージに対して何かする問題では試してみる価値あり
docker save test/xyz > dumped.tar
- レイヤー毎のダンプができる。diveでレイヤーのIDを取得してきて対応するフォルダを見てみる