Tahoo!!

自分の勉強していること（コンピュータ関連 / ネットワーク / セキュリティ / サーバ）や趣味について書いていきます

setodaNote CTF Writeup (Forensics)

CTF DFIR フォレンジック

この記事は setodaNote CTF ForensicsジャンルのWriteupです。

paint_flag (50pts, 289solves)

問題ファイルはdocxファイル。Wordで開いてみる。

f:id:takahoyo:20210909231826p:plain

flagが塗りつぶされていて読めない。

docxファイルは実態は"ZIP"ファイルであり、黒塗りされてない生の画像が格納されている。拡張子を .zip にしてファイルを展開。 word/media/flag.png が生の画像ファイル。

f:id:takahoyo:20210909231838p:plain

flag{What_m4tters_is_inside;)}

Mail (50pts, 219solves)

問題ファイルを開くと、大量のmsfファイルと拡張子がないファイルがあるディレクトリが出現する。msf（Mail Summary File）は、Thunderbirdで使われるメールのサマリ情報が書かれたファイルらしい。

f:id:takahoyo:20210909231902p:plain

msfファイルがThunderbirdで使われるファイルであることやINBOXなどの名前からメールボックスに関連するファイル群であることから、どこかにメールのヘッダや本文の情報があるはず。ファイルサイズ的に Sent-1 だけ異常に大きいので何かありそう。

Sent-1 をVSCodeで開いてみるとヘッダ情報と本文がバッチリ残っており、kimitu.zip を添付して何か送ってるのがわかる。

f:id:takahoyo:20210909231910p:plain

添付ファイルはBase64でエンコードされているので、Base64の文字列をコピペしてCyberChefに投げる。以下のレシピでBase64デコード、unzip、画像の表示までやってくれる。

https://gchq.github.io/CyberChef/#recipe=From_Base64('A-Za-z0-9%2B/%3D',true)Unzip('',false)Render_Image('Raw')

f:id:takahoyo:20210909231927p:plain

FLAG

flag{You've_clearly_done_a_good_job_there!!}

Deletedfile (80pts, 195solves)

問題は以下のとおり。

そのファイルを削除した瞬間にそれが誤りであることをあなたは悟ります。どうやら重要なファイルが削除されてしまったようです。あなたはディスクのイメージファイルの入手に成功しました。削除されてしまったファイルを復元し、窮地を脱してください。添付されたファイルを解析し、フラグを得てください。

問題ファイルは、拡張子 .raw がついたファイル。問題文によるとディスクイメージと思われる。

ファイルはWindows上で普通に削除しても、ファイルシステム上で削除フラグが立つだけ（OSから見えなくなるだけ）で、ファイルの実体が直ちに消える訳ではない。よって、ファイルの特徴的なデータ列（シグネチャ）で検索するなどして、ファイルを復元できる。（カービング）

Linuxでbinwalkを使ってカービングしてみる。

$ binwalk --dd='jpeg:jpg' deletedfile.raw -C ./output

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
104448        0x19800         JPEG image data, JFIF standard 1.01
163840        0x28000         JPEG image data, JFIF standard 1.01

output/_deletedfile.raw.extracted/ にファイルが作成される。

ls output/_deletedfile.raw.extracted/
19800.jpg  28000.jpg

19800.jpg の方にFLAGが書いてあった。

f:id:takahoyo:20210909232052p:plain

FLAG

flag{nosce_te_ipsum}

後でAutopsyで開いたら一発だった。

f:id:takahoyo:20210909232032p:plain

Timeline (100pts, 135solves)

問題ファイルは、 C:\Users\stella\AppData\Local\ConnectedDevicesPlatform\L.stella にあるファイル。このフォルダにあるActivitiesChache.db でググると、Windows 10のTimeline機能（Windowsの）が利用しているActivityのデータベース。

フォレンジックツールの神、Eric Zimmerman先生がこのファイルをParseするツール WxTCmd を作ってくれているので、これを利用する。

WxTCmd.exe -f ".\C\Users\stella\AppData\Local\ConnectedDevicesPlatform\L.stella\ActivitiesCache.db" --csv .

f:id:takahoyo:20210909232158p:plain

ツールを実行すると、CSVファイルが出力される。CSVなのでExcelで開いてても良いが、Eric Zimmerman先生のツールが出力するCSVの出力は同じく先生が作っているTimeline Explorerがいい感じに表示してくれるのでこれを使う。

内容を見ているとnotepad.exeでテキストファイルを開いているActivityが記録されており、開いているファイル名が f.txt 、l.txt 、a.txt のようにFLAGになっている。

f:id:takahoyo:20210909232206p:plain

FLAG

flag{Th3_Fu7Ure_1s_N0w}

browser_db (100pts, 182solves)

問題ファイルは、 SQLiteのDBファイル。

DB Browser for SQLite で開いてみる。table名のPrefixが moz_ のものがたくさんあるので、FIreFoxのDBかな。

moz_place のテーブルのデータを見てみると、閲覧したサイトの履歴が残っている。

履歴を見ていると、DuckDuckGoでFLAGをキーワードにして検索している履歴が見つかる。

f:id:takahoyo:20210909232257p:plain

FALG

flag{goosegoosego}

MFT (100pts, 143solves)

以下のような問題。

内部告発によりある要員が極秘情報をファイルサーバからダウンロードしていることが判明しました。組織は要員の身柄を抑え、端末から証拠となるデータを抽出しました。今回のあなたの仕事は、端末から抽出したデータを解析し、ダウンロードされた極秘情報のファイル名を特定することです。組織からは極秘情報のダウンロードされた日時が 2021-07-18 18:30頃 であることと、ファイルサイズが 465030 であることのみが伝えられています。添付ファイルを解析し、極秘情報のファイル名を特定してください。例えばファイル名が file.txt の場合は flag{file.txt} と回答してください。

問題ファイルは、C_$MFT という名前のファイル。

問題名やファイル名のとおり、NTFSでファイルエントリを管理するMFT（Master File Table）ぽい。

TImelineと同様、Eric Zimmerman先生が MFTをparseするMFTECmd というツールを作ってくれているので、これを使って解析する。

MFTECmd.exe -f C_$MFT --csv .

f:id:takahoyo:20210909232332p:plain

これもTimelineと同様に解析結果がCSVで出力されるので 、Timeline Explorerで開いてみる。

問題文より、ダウンロードされた日時が 2021-07-18 18:30頃 で、ファイルサイズが 465030 であることがわかっている。ファイルサイズでフィルタすると、Createdのタイムスタンプが2021-07-18 18:30頃の kimitsu.zip というファイルが見つかった。

f:id:takahoyo:20210909232351p:plain

FLAG

flag{kimitsu.zip}

tkys_another_day (100pts, 126 solves)

問題ファイルは以下のようなPNGファイル。flagの一部がかけている。

f:id:takahoyo:20210909232415p:plain

exiftoolで見てみる。

$ exiftool tkys_another_day.png 
ExifTool Version Number         : 12.16
File Name                       : tkys_another_day.png
Directory                       : .
File Size                       : 12 KiB
File Modification Date/Time     : 2021:07:25 16:47:40+09:00
File Access Date/Time           : 2021:09:09 19:27:22+09:00
File Inode Change Date/Time     : 2021:08:23 17:26:56+09:00
File Permissions                : rw-rw-r--
File Type                       : APNG
File Type Extension             : png
MIME Type                       : image/apng
Image Width                     : 640
Image Height                    : 480
Bit Depth                       : 8
Color Type                      : RGB with Alpha
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Noninterlaced
Animation Frames                : 5
Animation Plays                 : inf
Warning                         : [minor] Text chunk(s) found after APNG IDAT (may be ignored by some readers)
Software                        : APNG Assembler 2.91
Image Size                      : 640x480
Megapixels                      : 0.307

File Typeを見ると、APNGとなっている。APNG (Animated Portable Network Graphics) は、GIFのようにPNGファイルで動画を扱うためのフォーマットである。

APNGを扱うためのPythonライブラリがあったので、これをpipでインストールしてAPNGのフレームを個別のPNGファイルとして抽出した。

from apng import APNG

img = APNG.open('tkys_another_day.png')
for i, (png, control) in enumerate(img.frames):
  png.save("{i}.png".format(i=i))

f:id:takahoyo:20210909232429p:plain

1,2,4番目のframeに書かれている文字を組み合わせて、Submitしたものが正解だった。

flag{a_fake_illness_is_the_most_serious_disease_f5ab7}

TITLE (120pts, 25solves)

今回のCTFで一番解かれなかった問題。

問題ファイルは以下のようなJPGファイル。ファイル名は lo3rs1tkd.jpg （このファイル名でググると、シュタゲの11話で出てくる脅迫メールの添付ファイルの名前がこれ

f:id:takahoyo:20210909232445j:plain

exiftoolを実行してみる。

$ exiftool lo3rs1tkd.jpg 
ExifTool Version Number         : 12.16
File Name                       : lo3rs1tkd.jpg
Directory                       : .
File Size                       : 2.1 MiB
File Modification Date/Time     : 2021:08:15 15:06:46+09:00
File Access Date/Time           : 2021:08:26 01:42:25+09:00
File Inode Change Date/Time     : 2021:08:23 17:47:13+09:00
File Permissions                : rwxrw-rw-
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Resolution Unit                 : None
X Resolution                    : 1
Y Resolution                    : 1
Image Width                     : 1280
Image Height                    : 959
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:4:4 (1 1)
Image Size                      : 1280x959
Megapixels                      : 1.2

画像も普通に見れるし、exiftoolで見ても変わってるところはなし、StegSolve.jarで見ても何もないので、2,3日くらい悩んだ。

いろいろ試してる過程でStegHideを試した。

$ steghide info lo3rs1tkd.jpg
Corrupt JPEG data: 159900 extraneous bytes before marker 0xd9
"lo3rs1tkd.jpg":
  format: jpeg
  capacity: 102.5 KB
Try to get information about embedded data ? (y/n)

結果をよく見ると、Corrupt JPEG data: 159900 extraneous bytes before marker 0xd9 というエラーが表示されている。これは普通の画像を読み込んだ時には表示されない。もしかして何か余計なデータ入ってる？

再び画像を見てみると、右下にモザイクがかったようなデータがある。まだ表示できてない画像データがあるのではないかと疑い、JPEGヘッダで指定されている画像サイズをいじってみることにした。

JPEGファイルフォーマットを解説しているサイト によると、SOF0セグメント (FF C0 のマーカから始まる) で画像の高さと横幅を定義している。マーカから3byte目がJPEG画像の高さ（03 BF = 0x3BF = 959px）、5byte目が幅（05 00 = 0x500 = 1280）である。

f:id:takahoyo:20210909232538j:plain

右下のモザイクがかかったようなデータが気になったので、高さ （03 BF の部分）を変えてみることにした。とりあえず、幅と同じサイズの05 00 にしてみる。

すると、画像の隠れていた部分が表示され、文字と右下のモザイクのような部分の残りが表示された。これは、マーカの部分が消えてるが、もうCTFでは一生見たくないと思ってたQRコードぽい。

f:id:takahoyo:20210909232505j:plain

ここからはGIMPを使ってQRコードの部分を、トリミングしたり、グレースケールにしたり、微妙にQRにかかてる文字や上の画像の部分を修正したりして、抜き出した。ついでにQRマーカもつけた。

そして復元したのが以下の画像。

f:id:takahoyo:20210826234501j:plain

誤り訂正符号の部分がガッツリ消えているが、データの部分は無事なので問題なく抜き出せそう。

ここからデータを抜き出すのために strong-qr-decoder を使おうと思ったが、いろいろ調べていると今の時代には QRazyBox というQRコードを修復するためのWebベースのツールがあるらしい。

画像をImport出来るのでImportしてみると、きれいに認識してくれた。

f:id:takahoyo:20210909232600j:plain

Tools の Extract QR Information を選択すると、記録されているデータを表示してくれた。

f:id:takahoyo:20210909232608j:plain

FLAG

flag{Y0u_h4ve_w1tnessed_t00_much}

普通に画像は見えているしexiftoolでも怪しい部分はなかったので、画像サイズが改変されていることに気づかなかった人が多かったと思う。まさかこの画像からQRが出てくるとは思わなかった。。

CSIRT_asks_you_01 (150pts, 99solves)

以下のような問題。

組織内のインシデント対応部署から急ぎ解析してほしいとの依頼が舞い込みました。不正侵入が確認された端末の Windows イベントログの調査で、状況把握のために侵害に関する詳細な日時を確認してほしいということのようです。今回のあなたの仕事は送られてきたファイルを解析し、不正な方法によってネットワーク経由のログインが成功したことを示している最初の記録日時（TimeCreated SystemTime） と Event ID を特定することです。フラグは UTC での記録日時 を yyyy/mm/dd_hh:mm:ss 形式にし、最後に Event ID をアンダースコアでつなげた形で答えてください。例えば 記録日時 が 2020/01/10 7:05:13.9234567Z 、Event ID が 1234 の場合は flag{2020/01/10_07:05:13_1234} となります。記録日時は UTC+0 で回答することに注意してください。

問題ファイルは、WindowsのSecurityイベントログ。

最初はWindowsの標準イベントログビューアで見ていたが、ログ量が多く検索しにくい。

Eric Zimmerman先生が EVTxをparseするEvtxECmdというのを作っているので、これを使ってみる。

EvtxECmd.exe -f Security.evtx --csv .

f:id:takahoyo:20210909232640p:plain

CSVが結果として出力されるので、Timeline Explorerで開いてみる。

ログオン成功を示すイベントIDは 4624、ネットワーク経由でのログオン示すLogonTypeは 3 なので、これでフィルタをかける。

3つのイベントがフィルタされる。

f:id:takahoyo:20210909232652p:plain

イベントIDのフィルタを解除してそれぞれのログの前後を見てみると、2021/07/18 20:09:21 のログの前後で大量のログオン失敗イベントが発生している。このことから、192.168.224.128からtestアカウントに対してブルートフォース攻撃もしくは辞書攻撃を行っていたと考えられる。

f:id:takahoyo:20210909232701p:plain

恐らくこれが問題文で言っていた "不正な方法" なので、以下のようにSubmitしたら正解だった。

FLAG

flag{2021/07/18_20:09:21_4624}

unallocated_space (150pts, 97solves)

以下のような問題文。

「こりゃ今夜は帰れそうにないな」同僚がそう言いながらハードディスクやUSBメモリが大量に詰まった箱をどさっとデスクに置きます。すべてある組織で使用されていたもので本来は破壊処理されるはずが、不正に利益を得ようとした人物が仲介したことにより、破壊処理されずに中古市場に出回ってしまったもののようです。今日が記念日だという同僚を早く帰すため、あなたはディスクの解析調査を手伝うことにしました。復元可能なデータがないか確認してください。添付されたファイルを解析し、フラグを入手してください。

問題ファイルはバイナリファイル。問題文からディスクイメージだと考えられる。

データを復元せよということなので、Bulk Extractorにレコードのカービング用のプラグインを搭載した Bulk Extractor with Record Carving を使ってみた。

www.kazamiya.net

f:id:takahoyo:20210909232728p:plain

実行してみると、各種プラグインの結果が実行時に指定したディレクトリに出力される。windirsプラグインの結果（windirs.txt）を見ると、 flag.mp4、flag_backup1.mp4、flag_backup2.mp4 というファイルがあったことがわかる。

f:id:takahoyo:20210909232738p:plain

恐らくMFTをカービングしてそこから情報を作成しているので、ファイルサイズの情報もある。ファイルサイズは 559850 bytes

f:id:takahoyo:20210909233014p:plain

MP4ファイルがありそうなのはわかったので、MP4のシグネチャでファイルがないか調べる。以下のサイトによると、MP4のシグネチャは 4 byte offset + 66 74 79 70 なので、66 74 79 70 でバイナリエディタで検索する。

www.garykessler.net

f:id:takahoyo:20210909232746p:plain

ファイルがあることがわかったので、シグネチャでファイルの場所を引っ掛けて、ファイルのスタート地点からファイルサイズ分データをコピーしてMP4ファイルの復元を試みる。Pythonでファイルを復元するコードを書いた。

with open("unallocated_space","rb") as f:
    data = f.read()

file_size = 559850
start = data.find(b"\x66\x74\x79\x70") - 4
mp4 = data[start:start+file_size]

with open("flag.mp4","wb") as f:
    f.write(mp4)

シグネチャにマッチする場所は3箇所あるが、どのデータも同じデータだった。

復元に成功すると、ペイントでflag文字を書いてる動画が復元できる。

f:id:takahoyo:20210909232841p:plain

FLAG

flag{file_carving_gogo}

CSIRT_asks_you_02 (200pts, 62solves)

問題文は以下の通り。

組織内のインシデント対応部署から引き続き急ぎ解析してほしいとの依頼を受けています。一つ目の解析依頼（CSIRT_asks_you_01）の結果と別の証拠などから、あるアカウントのパスワードが脆弱である可能性が示唆されています。添付されたファイルを解析し、そのパスワードを特定してください。フラグはアカウント名とパスワード（平文）をアンダースコアでつないで回答してください。例えばアカウント名が user 、パスワードが pass の場合は flag{user_pass} と回答します。

問題ファイルは、SAM、SECURITY、SYSTEMのレジストリファイル。

Windowsでは、ローカルアカウントの認証の際にSAMレジストリに記録されている情報を使用しており、これを解析することでローカルアカウントの認証情報（NTLMハッシュ）を手に入れることができる。

ペンテストの時によく使うImpacketに、SECYRITY, SAM, SYSTEMレジストリからCredential情報を引っこ抜いてくれる secretsdump.py というツールがあるので、今回はKali Linuxでこれを使用した。

https://github.com/SecureAuthCorp/impacket/blob/master/examples/secretsdump.py

$ impacket-secretsdump -sam SAM -security SECURITY -system SYSTEM LOCAL

Impacket v0.9.22 - Copyright 2020 SecureAuth Corporation

[*] Target system bootKey: 0xc2f71c8a15cee734ce4ab65b3e9da4e1
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:27c3a146aa209b2120f7ecc9db065540:::
stella:1001:aad3b435b51404eeaad3b435b51404ee:2f8ae2e260d0cfe3756ff53e639e3377:::
test:1002:aad3b435b51404eeaad3b435b51404ee:3c99b8901b00758369f18b9df72012c8:::
akari:1003:aad3b435b51404eeaad3b435b51404ee:b66eade488ce2c23ba226427e40fed41:::
[*] Dumping cached domain logon information (domain/username:hash)
[*] Dumping LSA Secrets
[*] DefaultPassword 
(Unknown User):_TBAL_{68EDDCF5-0AEB-4C28-A770-AF5302ECA3C9}
[*] DPAPI_SYSTEM 
dpapi_machinekey:0xd4a669f9f497412cee7cd70c13c318c1b743c4d7
dpapi_userkey:0xe8a7ce7d52e77f0632f7225fe1cb66bccafb0171
[*] NL$KM 
 0000   49 EA 37 D4 AD 86 BC F9  1D C3 70 FD B3 1F 14 5D   I.7.......p....]
 0010   42 AD 20 DB 9F AB C9 30  3F 72 4D 0A 08 63 53 70   B. ....0?rM..cSp
 0020   7F E2 25 F5 57 21 94 D2  98 31 E7 A4 D6 3C D9 37   ..%.W!...1...<.7
 0030   A0 D2 3D ED 49 FD 98 7B  76 34 CF A6 F0 7E 76 B6   ..=.I..{v4...~v.
NL$KM:49ea37d4ad86bcf91dc370fdb31f145d42ad20db9fabc9303f724d0a086353707fe225f5572194d29831e7a4d63cd937a0d23ded49fd987b7634cfa6f07e76b6
[*] Cleaning up...

testのパスワードのNTLMハッシュ 3c99b8901b00758369f18b9df72012c8 でググると、testtest をNTLMハッシュ化したもので、すでにクラックされているNTLMハッシュであることがわかる。

FLAG

flag{test_testtest}

こんなパスワードだったら、辞書攻撃で簡単にログオンされてしまいそうですね。。