Boss of the SOC (BOTS) Investigation Workshop for Splunkのbotv1を使用してScenario #1_APTを順繰りやっていく４回目。
サイバーキルチェーンはここを参照。
初回が偵察（reconnaissance）で、前前回が攻撃(exploitation)、前回が設置（Installation）、今回が目的に対する行動（Actions on Objective）
Identifying the File that Defaced Our Web Server (Part 1 of 2)Webサーバーを改ざんしたファイルの特定（パート1/2）
Let’s start by taking a look at our web server to determine who is communicating with it. Using our Suricata data and the IP address that we identified earlier for our web server (192.168.250.70), we can see there are 3 internal systems communicating with the web server, but there are no external systems originating traffic and generating alerts. Let’s see what it looks like if the web server is the source of the traffic. That’s not something we would expect to see, but it’s still important to check.
まず、ウェブサーバーを見て、誰と通信しているかを判断します。 Suricataのデータと、Webサーバー（192.168.250.70）で以前に特定したIPアドレスを使用すると、Webサーバーと通信する内部システムが3つあることがわかりますが、トラフィックを発信してアラートを生成する外部システムはありません。 Webサーバーがトラフィックのソースである場合の外観を見てみましょう。 これは私たちが期待するものではありませんが、確認することが重要です。
index=botsv1 dest_ip=192.168.250.70 sourcetype=suricata
In this search, we are treating the web server as the source of the traffic instead of the destination. Is there anything interesting about the results that you see?
この検索では、Webサーバーを宛先ではなくトラフィックの送信元として扱っています。あなたが見る結果について興味深いことはありますか？
It's interesting that the destination IP address values contain three external IP addresses that our web server is originating traffic to. Would we expect a web server to initiate traffic outbound, especially to an external IP address? Is that something that a web server does?
興味深いのは、宛先IPアドレスの値に、Webサーバーがトラフィックを発信する3つの外部IPアドレスが含まれていることです。 Webサーバーが、特に外部IPアドレスへのトラフィックの発信を開始することを期待しますか？それはWebサーバーが行うことですか？
A web server listens for requests and sends data back based on the request. Generally, when observing network or web traffic, the client or browser would be the source IP or host while the web server would be the destination. If an administrator logged onto the web server, executed a browser and started surfing the web, that could be one reason that the web server would be the source in an event, but that action generally violates policy, so at the very least, that should be looked into.
Webサーバーはリクエストをリッスンし、リクエストに基づいてデータを送り返します。一般に、ネットワークまたはWebトラフィックを監視する場合、クライアントまたはブラウザーがソースIPまたはホストになり、Webサーバーが宛先になります。管理者がWebサーバーにログオンし、ブラウザーを実行し、Webサーフィンを開始した場合、Webサーバーがイベントのソースになる可能性がありますが、そのアクションは一般にポリシーに違反するため、少なくとも、調べてください。
index=botsv1 src_ip=192.168.250.70 sourcetype=suricata
この結果だと、40.80.148.42``23.22.63.114``108.161.187.134が該当する。
224.0.0.252はマルチキャストアドレス。ネットワークの構成がわからないけど、外部にはいかないでしょう。
Pivot Into Destination IP Addresses to View URLs
index=botsv1 src_ip=192.168.250.70 dest_ip=23.22.63.114 (sourcetype=stream:http OR sourcetype=suricata)
| search uri=* OR http.url=*
| rename http.url as httpUrl
| eval URL=coalesce(uri,httpUrl)
| chart count over sourcetype by URL
フィールド名に「.」が入っているとcoalesceがうまく動かないというトラップに引っかかりながら、一気に表示。
Number of events originating from the Web Server via stream:http
index=botsv1 imreallynotbatman.com sourcetype=stream:http
|stats count
_22200_件のイベント
Looking at the http traffic that returned those nine results, we can pivot into interesting fields like the URI field in the same way we did with suricata. If we look through the list of URIs we see in the two sourcetypes, we do see some differences, but we also see some similarities. Do you see anything in common?
これら9つの結果を返したhttpトラフィックを見ると、suricataで行ったのと同じ方法で、URIフィールドなどの興味深いフィールドにピボットできます。 2つのソースタイプにあるURIのリストを見ると、いくつかの違いがありますが、いくつかの類似点もあります。 共通点はありますか？
URIs in stream:http
index=botsv1 src_ip=192.168.250.70 sourcetype=stream:http
|chart count over dest_ip by uri
108.161.187.134に関してはjoomlaのアップデート関連ですね。
[先ほどの検索Pivot Into Destination IP Addresses to View URLs](####Pivot Into Destination IP Addresses to View URLs)でjpegが両方のソースタイプで値がでていることが共通点。
Validating Using Firewall Logs the File that Defaced Our Web Server (Part 2 of 2)
Perhaps two data sources aren’t sufficient or we are more comfortable analyzing firewall data. Let's use our firewall data to determine if we saw similar things. A word of caution, don’t fall in love with a single sourcetype, each of them have their strengths in terms of fidelity and having corroborating data sources is incredibly important.
おそらく2つのデータソースでは不十分であるか、ファイアウォールデータをより快適に分析できます。 ファイアウォールデータを使用して、類似したものが見られるかどうかを判断しましょう。 注意点として、単一のソースタイプに恋をしないでください。各ソースタイプは忠実度の点で長所があり、データソースを確証することは非常に重要です。
fgt_utmのフィールドは_送信元IP_がsrcip、_宛先IP_がdstip
Clicking on src
index=botsv1 sourcetype=fgt_utm "192.168.250.70"
| top srcip
| eval percentage=round(percent,2)
| fields - percent
Clicking on dest
index=botsv1 sourcetype=fgt_utm "192.168.250.70"
| top dstip
| eval percentage=round(percent,2)
| fields - percent
２つを比べると23.22.63.114が双方向のアクセスとなっている。
Which Search Do I Start With?
index=botsv1 sourcetype=fgt_utm "192.168.250.70"
| stats count(eval(dstip!="192.168.250.70")) as NOT_dstip_192_168_250_70
count(eval(srcip!="192.168.250.70")) as NOT_srcip_192_168_250_70
```
まとめて表示
### Use Web Site Categorization to Filter
#### Filter on Web Site Categorization
```Splunk:SPL
index=botsv1 sourcetype=fgt_utm "192.168.250.70" NOT dstip="192.168.250.70"
| top catdesc
```
_Malicious Websites_ってなんだろう。
#### Firewall Confirms Findings of suricata and stream:http
```Splunk:SPL
index=botsv1 sourcetype=fgt_utm "192.168.250.70" NOT dstip="192.168.250.70" catdesc="Malicious Websites"
| table _time hostname dstip url msg
```
Appsだと数をだしておしまいだったので、ちょっと表示を綺麗にしてみた。
_suricata_や_stream:http_の調査ででてきた_jpeg_がここにも出てきた。
1337ポートってWebShell?
Actions on Objectiveはここまで。長くなったのでおしまいとします。