💡

Network Analysis – Web Shell (BTLO WriteUp)

2022/04/28に公開約6,100字

概要

これはBlue Team Labs Onlineのチャレンジ問題、「Network Analysis – Web Shell」のWriteUpです。

問題背景

「SOCはSIEMから「ローカルからローカルへのポートスキャン」というアラートを受け取りました。このアラートは内部のプライベートIPが他の内部のシステムへのスキャンを開始していました」
とのことで、pcapファイルが与えられています。全10問の設問が用意されています。

問題の解説

とりあえずpcapファイルをwiresharkで開いてみます。

Q1

問題を読んでみると、
What is the IP responsible for conducting the port scan activity?
ポートスキャンしてるIPはだーれだ?
とのこと。というわけでポートスキャンしてるやつを探しましょう。
適当にスクロールすると、(色つけ設定がデフォルトなら)赤と灰色のかっこいいゼブラゾーンが現れます。

この赤い行は(色つけ設定がデフォルトなら)TCP RSTパケットのときなどを表します。Infoのカラムを見ると、RSTであることがわかります。
RSTパケットが送られる状態には様々ありますが、ここは問題の文脈から考えて、開いてないポートにパケットが送られてハンドシェイクを拒否されているんだろうな~と想像します。
ということで、大量の開いてないポートにSYNパケットを送信している10.251.96.4、犯人はお前だ。

Q2

What is the port range scanned by the suspicious host?
ポートスキャンされているポートのレンジは?
とのこと。
先程のように適当にスクロールして最大最小を探し出すのは骨が折れます。Wireshark先生の力を借ります。
まず、先程ポートスキャンの主がわかったので、送信元IPでフィルタしましょう。
入力窓に「ip.src == 10.251.96.4」と入力します。

これでかなり見やすくなりました。
とはいえ、宛先ポートの順番はバラバラで、最大最小は依然として探しにくいままです。あ~あ、宛先ポート番号でソートできたらな~と思うことでしょう。それができるんです。そう、wiresharkならね。
列名のところを右クリック、Column Preferencesをクリックします。

するとこんなウィンドウが出てくるので「+」ボタンをクリックします

新規列が追加されたはずなので、新規列のNumberとなっているところをダブルクリック

プルダウンメニューからDest port(unresolved)を選択して、題名もいい感じに変えます。ついでに送信元ポートも同じ手順で追加しておきましょう。気持ち悪いので。
ちなみに各行をドラッグ&ドロップで表示順も変えることができます。いい感じにしましょう。
なお、resolvedとunresolvedの違いですが、resolveの場合はウェルノウンポートをサービス名で表示してくれるらしいです。いらないお節介なので、ご厚意には感謝しつつ今回はご遠慮しておきましょう。

で、後は宛先ポートのカラム名をクリックしてソートすれば良いだけです。
なお降順にすると一番上に48994/tcp宛が表示されますが、今回のポートスキャンはポートが空いている場合も通信を行うことなく次のポートをスキャンしているので、コネクションが確立しているこの通信は除外して良いです。また、問題文にレンジと書いているくらいだから連番になっているところだけを選べばいいだろう、という予想もできます。
1-1024が連番の様子なので、入力すると正解でした。

Q3

What is the type of port scan conducted?
行われたポートスキャンのタイプは?
とのことです。
ポートスキャンにタイプなんかあるんですか?という人にはNmapの「ポートスキャンのテクニック」というページが参考になります。

https://nmap.org/man/ja/man-port-scanning-techniques.html
SYNだけ送ってるっぽいし、短時間にめちゃくちゃな量を送りつけていることから、TCP SYNでしょう、ということで正解はTCP SYNです。

Q4

Two more tools were used to perform reconnaissance against open ports, what were they?
開いているポートに対して2つのツールを使って偵察を行っていますが、それらは何でしょう?
とのこと。
開いているポートに対する偵察行為ということで、TCPのセッションは成立した上でたくさんの通信が発生しているだろうな~などと想像しておきます。番号または時間でソートしなおして適当にスクロールすると淡い緑色の目に優しいゾーンが出現します。

この色はHTTPの通信を表すので、TCPのセッションが確立した上で、HTTPとして通信を行っていることがわかります。HTTPならスキャンツールも複数あるだろうし、まあここかな、などと思いながら通信の内容を確認してみます。
適当な緑の行を右クリック→追跡→TCPストリームを選択します。

こんなウィンドウが出てきます。ツールを特定するとのことなので、User-Agentになんかそれっぽいもの入ってないかな~と考えます。この画面では見た感じ普通のブラウザっぽいUAです。おいおい、UAに入ってないと特定するの大変だぞ、などと思いながら次々ストリームを見ていきます。

幸い、すぐにそれっぽいものが出てきました。良かったね。
では残りの一つは同じ要領で探していきます。
ちなみに、ストリームのウィンドウを消すとフィルタがストリーム指定に書き換わっていることに注意してください。
ありました。

ということで答えはgobuster 3.0.1, sqlmap 1.4.7でした。

Q5

What is the name of the php file through which the attacker uploaded a web shell?
攻撃者がweb shellをアップロードする際に利用したphpファイルは何
とのこと。
web shellをアップロードする通信ってことは、サイズはそれなりに大きくなるだろうな~などと思いながら、
ip.src == 10.251.96.4でフィルタしつつ、Lengthで降順にソートしてみます。

upload.php宛のサイズの大きいPOSTリクエストがありました。中身を見てみましょう。

ということで、「dbfunctions.php」という名前で怪しいphpファイルがアップロードされていることがわかります。成功していそうなレスポンス(レスポンスコード200, ファイルアップロード成功の旨のボディ)まで取れています。
phpの内容としてはリクエストからコマンドを受け付けて実行するようです。明らかにweb shellです。本当にありがとうございました。
いや待て、現段階ではなんとなくアップロードできたっぽい応答が返ってきているだけで、本当にアップロードされているのか、あるいはアップロードされていたとしてそれがwebshellとして機能しているのかどうかまではわかりません。(例えば何らかの理由でphpとしてそのファイルが動かなかった場合、webshellとしては機能しないでしょう)
Blue teamの一員として攻撃が成功していないことを祈りつつ、ストリームを追っていきましょう。

あっ
・dbfunctions.phpの存在を確認するためのGETリクエストが成功
  →ファイルアップロード成功
・ボディの内容がない
  →アップロードしたファイルがPHPとして解釈され、しかもcmdというパラメータが存在しないため何も表示されないというコードどおりの結果

コマンドを含むリクエストが送られ、攻撃者の意図したコマンドの結果が返っている
  →webshell が設置されている)

だめでした

ということで、問の答えはupload.php
を入力するとwrong answerと言われてしまいます。
なんで……
と思いつつ先程の通信をよく見てみるとRefererになにやら書いてあります。
ということは、このリファラのページを経由してこの通信が発生したのでしょう。editprofile.phpのページにはファイルを選択するまでの機能があり、「アップロード」みたいなボタンを押すとupload.phpにPOSTリクエストが飛んでファイルがアップロードできる、みたいな流れなんだろうね。
ということで正解はeditprofile.phpです。

Q6

What is the name of the web shell that the attacker uploaded?
攻撃者がアップロードしたweb shellのファイル名は?
これは先程見た通り、dbfunctions.phpです。

Q7

What is the parameter used in the web shell for executing commands?
web shellがコマンドを実行するために使用するパラメータは?
これは先程のphpのソースや、コマンドが実行される通信を見ても明らかなように、cmdというパラメータにコマンドを入れるようです。

Q8

What is the first command executed by the attacker?
攻撃者が最初に実行したコマンドは?
これも見たようにidコマンドを最初に実行しているようです。

Q9

What is the type of shell connection the attacker obtains through command execution?
攻撃者がコマンド実行の結果取得したshell connectionのタイプは?
shell connectionってなんぞ?リバースシェルとかそういうことかな?などと考えつつ、とりあえずストリームを追っていきましょう。

と、ここで謎のシェルっぽい内容が出てきました。ああ、なるほどこれのことね、などと納得します。
この画面の下側を見ると、赤文字がクライアントで、青文字がサーバだそうです。ということは、赤文字のコマンドを受け付ける側から青色のコマンドを打つ側に接続しに行ったんだろうな、ということがわかります。
つまりこれはリバースシェルなので、reverseでいいのかな、などと不安になりながら答えを入力すると無事正解です。

Q10

What is the port he uses for the shell connection?
彼がシェルの接続に利用しているポートは?
ストリームのウィンドウを閉じて、この通信が始まったところを探します。

はい、ありました。
どっちのポートを入力すればいいんだ……などと悩みながら、彼が使っているポートということなので、攻撃者であるIP末尾.4側のポートである48994を入力します。
だめでした。
よくよく考えてみれば、リバースシェルなので攻撃者が意図して選択していると考えられるポートは被害者側のポートです。4422を入力し、無事正解でした。

Discussion

ログインするとコメントできます