日々のいろいろ

【setodaNote CTF】Network問題に挑戦しました

投稿日: 5/25/2025

前回の記事ではCryptoを解きました。
今回はNetworkです。
ろくにWiresharkも使えないのですが、とりあえずやってみる。

チュートリアル的な1問目は省略します。

解答の参考にさせていただいたサイトです
https://zenn.dev/judenfly/articles/judenfly-20241014
https://takahoyo.hatenablog.com/entry/2021/09/09/234804

2 tkys_never_die

問題

うまく爆発を避けれられているといいが。爆発音とともに通信が途切れる間際、後輩からデータが送られてきました。ターゲットが重要なファイルにアクセスしたことを示す証拠だと言い残して。後輩のためにもデータを解析し、重要なファイルの内容を特定してください。

添付されたファイルを解析し、フラグを得てください。

ファイルを開くと、下記HTTP通信を確認できます。
http://ctf.setodanote.net/flag.html へのGETリクエスト
http://ctf.setodanote.net/flag.png へのGETリクエスト

各htmlやpngファイルのデータ自体もレスポンスとしてキャプチャされているので、オブジェクトをエクスポートしてみます。

画像

flag.htmlは特になんの情報もありませんでしたが、flag.pngをエクスポートしたところ、flagが記載された画像ファイルとして取得できました。

3 echo_request

組織内の通信を監視している部署から不審な通信データがあるので解析をしてほしいと依頼がありました。通信自体は許可されたプロトコルが使用されているようですが、、、

添付されたファイルを解析し、フラグを入手してください。

ファイルを開いたところ、ICMPと、TLSのネゴシエーション、RDPの通信を確認できます。
実際のレスポンスまで見てみると、pingもRDPも失敗しているようです。
TLSはAlertで終わっているので、ここがflagへのヒントかと思いましたが、特にこれ以上情報が見つからずギブアップ。

画像

解答

解答はICMPパケットの中身でした。
29番目から、ICMPパケット内のデータが1パケットずつ変わっているのがわかります。

画像

これをつなげると16進数のデータが得られるので、変換するとflagが得られます。

画像

なるほど...やけに多いパケットには、flagが1データずつ分割されて格納されている可能性がある、ということを学べました。

4 stay_in_touch

問題

あなたはある事件の調査としてある人物の通信を監視しています。どうやら誰かと連絡を取り合っているようです。通信データファイルを解析し、やりとりの内容を明らかにしてください。

添付されたファイルを解析し、フラグを入手してください。

ファイルを開くと、どうやらメールの送受信のパケットのようです。

メールの内容自体はBase64エンコードされているので、かたっぱしからデコードしてみましたが、特に怪しい部分はなく。
変に文字化けしている部分も調べたら「・」の変換だったようです。

画像

ここで、DovecotへのログインがPLANE(平文)での認証になっていることを確認しました。

画像

AHNldG9kYQBzZXRvZGFANDQyMw==をBase64デコードすると
ユーザーが「setoda」、パスワードが「setoda@4423」であることがわかりました。

画像

このログイン情報で実際に接続して、受信メールを確認できるかもしれないかと思いましたが、Dovecotのサーバーにアクセスすることすらできませんでした。

ギブアップ。

解答

TCPストリーム(tcp.stream eq 12)を追跡すると、以下のようにBase64エンコードされたZIPファイルのデータを発見しました。

画像

Base64でデコードしてZIPファイルを作成します。

画像

展開にはパスワードが必要だそうです。

画像

tcp.stream eq 12より後のTCPストリームを確認すると、TCPストリーム14にパスワードが記載されたメールのパケットがあります。
PPAPですね。

ASCIIのままでは全文が表示されないので、charset=utf-8に従ってUTF-8で開いたほうがよさそうですね。

画像
画像

パスワードを使って、作成したZIPを展開するとflagが記載されたファイルを取得できます。

5 yes_you_can

問題

精密機械の技術者である古い友人から一通の封筒が送られてきました。中にはあなたに解析してほしいと震えた筆跡で書かれた手紙と1枚の SD カード。SD カードの中には1つのファイルが記録されていました。

添付されたファイルを解析してフラグを入手してください。

今度はpcapファイルではなく、.logファイルです。
開くと以下のようなログでした。

(1628245600.155918) vcan0 095#800007F400000017
(1628245600.157006) vcan0 1A4#000000080000003E
(1628245600.157018) vcan0 1AA#7FFF00000000673F
(1628245600.157020) vcan0 1B0#000F0000000175
(1628245600.157023) vcan0 1D0#000000000000000A
(1628245600.158095) vcan0 166#D0320027
(1628245600.160232) vcan0 158#0000000000000028
(1628245600.160243) vcan0 161#000005500108002B
(1628245600.160245) vcan0 191#010010A141001A
(1628245600.160247) vcan0 133#00000000B6
(1628245600.160249) vcan0 136#0002000000000039
(1628245600.161317) vcan0 13A#0000000000000037
(1628245600.161327) vcan0 13F#000000050000003D
(1628245600.161329) vcan0 164#0000C01AA8000013
(1628245600.161331) vcan0 17C#0000000010000030
...

何もわかりません。。
調べると、CANバス信号という自動車やIoTで使われる通信方式だそうです。

解析について調べましたが、有力な情報は得られず、とりあえずデータをバイト変換するのが初手らしい?のでAIを使ってPythonで解析してみましたがわからず。ギブアップ。

解答

こちらのWriteupを拝見しました。
なるほど、16進数のデータ部にf,l,a,g,{,}に該当する66, 6c, 61, 67, 7b, 7dが含まれている行を抜き出し、データ部の4バイト目をそれぞれ調整して合わせると、flagになるというものでした。

ログのフォーマットが理解できれば、CANバス信号自体の理解は不要だったようです。

6 Digdig

問題

組織内の通信を監視している部署からマルウェア感染した端末から他にはない不審な通信が発生していたことが分かり、急ぎ解析してほしいを依頼がありました。どうやら、通信自体は組織内で許可されているプロトコルが使用されていたため外部に通信できた可能性もあり焦っているようです。

添付されたファイルを解析し、フラグを入手してください。

確認したところ、対象のドメインのA, AAAAレコードのDNSクエリのパケットのようです。

画像

実際にnslookupしてみても手掛かりはなく、クエリ自体にデータが埋め込まれているような感じでもありませんでした。
ギブアップ。

解答

上記画像のNo.15以降のパケットにて、対象のサブドメイン(005aa002735f69735f44414d.setodanote.net)が16進数になっていることを発見する必要があるそうです(だいぶ経験が必要そうですね...)。

サブドメインだけ抽出して昇順にソートすると綺麗にflagに変換できるようです。

7 Logger

問題

夕暮れ時、あなたの携帯が鳴動します。相手の番号は不明。非通知は拒否設定のはずと不思議に思いつつ電話に出ると「お前の秘密を知っている」と低い男の声が聞こえすぐに切れてしまいました。直後、あなたの携帯にファイルが添付された空白のメールが届きます。

添付されたファイルを解析してフラグを入手してください。

USB接続の外部機器とホスト間の通信のキャプチャだそうです。
ファイルはぱっと見情報量多くなさそうですが、Leftover Capture Dataなど、flagデータが埋め込まれる余地はありそうです。

画像
画像

調査しましたが、発展はなくギブアップ。

解答

Leftover Capture Dataのデータは、USB接続のキーボードの入力データだそうです。

https://usb.org/sites/default/files/hut1_6.pdf に、USBキーボードのデータ対応表がありました。
※USB LEDの表もありましたね。ちゃんと読んでみると面白そう。

8バイトの16進数に、各キーが対応していて....
デコードするとflagの含まれた文ができるそうです(他人事)。

調べてみると、今回の問題に適したPythonのライブラリなんかも作られているようですね。

tkys_not_enough

問題

せっかく内偵中の後輩から通信データが送られてきたのに。いわく決定的な証拠を掴んだとのことですが、普段とは異なる方法で取得したデータなのか解析ツールにうまく取り込めません。後輩に聞こうにも通信データが送られた直後「やはり君だったか」という聞きなれない男の声を最後に連絡が途絶えてしまっています。あなたは何とかしてこの通信データを解析しなければなりません。

添付されたファイルを解析し、フラグを入手してください。

今度は、.pcapファイルを開こうとしたら、形式が違うのかエラーが出ました。
メモ帳で開いてみると、etlの文字を発見。

画像

調べてみると、Windows用の解析ソフトに対応したファイルであることがわかりました。
ETLファイルに変換したうえで、解析ソフトMicrosoft Network Monitor 3.4をインストールします。

なんとかETLファイルをソフトで開くことに成功しました。

画像

個々のデータの詳細は以下のような感じです。ファイル開けたことに満足してギブアップ。

画像

解答

ダウンロードしたpcapファイルの拡張子を手動で「etl」に変えて、Microsoft Network Monitorで開いたあと、cap拡張子で保存。
capを再度手動で「pcap」に変更するとWiresharkで開けるようです。

他にもツール使ってCLIで変換できる方法があるようです。

基本的にはETLファイルも、変換してWiresharkで解析するのがよさそうですね。

Malformed Packetについて、詳細を確認するとHTTP通信であることがわかります。

画像

ISAKMPが利用するUDP/500への通信をHTTPで行っているために、不審なパケットとしてWireshark側で判定されてしまっているようです。
ISAKMPをHTTPとして判定するように設定をいじります。

画像

HTTPのパケットに対して、HTTPストリームを確認すると3つ目にflagがありました。

画像


コメント

まだコメントがありません

コメントする
0 / 1500 文字