Splunk BOSS of the SOC ver 2について(Data Staging)

[Boss of the SOC (BOTS) Advanced APT Hunting Companion App for Splunk](https://splunkbase.splunk.com/app/4430/)
Hunting an APT with Splunk Workshop
Welcome to the Hunting an APT with Splunk Workshop based on the Boss of the SOC 2017 data set.

こちらを元に、手順を追ってみる。データセットは[ここ](https://github.com/splunk/botsv2)
なお、ログの時間を合わせるためユーザの時間帯を**(GMT -08:00)**にする必要がある。

全１３回

1. [概要とPowerShell Empire](https://qiita.com/toshikawa/items/511af1a3054ab81cd475)
2. [FTP Exfiltration](https://qiita.com/toshikawa/items/ca6483e4c0ef7f3bb9d3)
3. [DNS Exfiltration](https://qiita.com/toshikawa/items/93a57d9ac0e06bab0bde)
4. [Adversary Infrastructure](https://qiita.com/toshikawa/items/75cbfa0b522735bc5228)
5. [Spearphishing Attachment](https://qiita.com/toshikawa/items/b9bc3527c0f9787d6be1)
6. [User Execution](https://qiita.com/toshikawa/items/945e271b05c1ea55ef34/)
7. [Account Persistence](https://qiita.com/toshikawa/items/df27a896ab71bafb512d)
8. [Scheduled Task](https://qiita.com/toshikawa/items/b203eb78c699192cfc6d/)
9. [Indicator Removal](https://qiita.com/toshikawa/items/8e0c730280e051a3ed4e/)
10. [User Agent Strings](https://qiita.com/toshikawa/items/bb0055bf74af461824a9/)
11. [OSINT Gathering](https://qiita.com/toshikawa/items/4cad2830289bc83ca330/edit)
12. [Lateral Movement](https://qiita.com/toshikawa/items/054c8c358c79758dec25/)
13. [Data Staging](https://qiita.com/toshikawa/items/886df42faf744c299985/)

#Data Staging
##Data Staging - Hypothesis
>仮説
敵は、データを抽出する前にステージングして、選択した時点でデータを抽出しやすくするとともに、識別された情報を中央に配置します。
説明
収集されたデータは、エクスフィルトレーションの前に中央の場所またはディレクトリにステージングされます。 データは、個別のファイルに保存するか、Data CompressedやData Encryptedなどの手法で1つのファイルに結合できます。 対話型コマンドシェルを使用できます。また、cmdおよびbash内の共通機能を使用して、データをステージング場所にコピーできます。

####How Might We Confirm or Refute Our Hypothesis?
- どのようなデータセット（sourcetypes）が上演されている私たちは、データを識別するのに役立つかもしれませんか？
- データのステージングを示すトラフィックフローはどのようなものでしょうか？
- データがステージングされている場所では、どのようなデータが見つかる可能性がありますか？
- データがステージングされる可能性のある場所はどこですか？
- 上演されたデータがexfiltratedされていることをリードして、その後の活動はありますか？
- データのステージングに使用できるユーザーアカウントは何ですか？

Data stagingの定義は[wikipekia](https://en.wikipedia.org/wiki/Staging_(data))によると中間貯蔵のことらしい。

##Data Staging - Data Details
>Officeファイルと圧縮ファイル

>データのステージングが懸念される場合、オフィスファイルまたは圧縮されている可能性のあるファイルを気にする可能性があります。 大規模な環境では、おそらく圧縮ファイルとオフィスファイルが分割されますが、この検索ではいくつかの異なるファイルタイプを探し、これらのファイルタイプを参照するソースタイプの数を取得します。

####Identifying Data Sets of Interest
>仮説を少し進化させて、もっと詳しく知りたいファイルの種類について考え始めましょう

####Familiarization with Fields in sourcetypes
>検索はワイルドカードを使用するとすぐに高額になるため、さまざまなソースタイプで使用可能な特定のフィールドを理解する必要があります。 データセットによっては、tstatとデータモデルアクセラレーションを使用できる場合がありますが、現時点ではSPLを使用します。

>SMBはこの検索に基づいた最大のソースタイプであり、データファイルがネットワーク上で移動されるという考え方により、SMBはイベント数が多いにもかかわらず魅力的な開始場所になります。 典型的なSMBレコードは次のようになります。

####src & dest Over Time
>stream：smb sourcetypeに焦点を当てると、evalコマンドを使用して、ソースIPと宛先IPの一意のセットを構築し、タイムチャート全体にレイアウトできます。 ここでは、ソースと宛先のペアが3セットあり、それらがイベントカウントとともに発生したことがわかります。 他のハントを実行している場合、攻撃の一般的な時間枠は8月23日であり、参照されたIPアドレスはある程度馴染みがあるため、それに焦点を合わせます。 それがわからない場合は、各自で何が起こっているかを詳しく調べることができます。 Splunkで使用できる別の手法は、そのグラフを線形ではなく対数に設定して、src / destのペアが多数ある場合に、視覚的に目立つ大きなペアを作成することです。

####Most Frequently Seen Files
>時間範囲が特定されたら、statsコマンドを実行して、各ファイルが参照された回数を確認できます。 多くのファイルが複数回表示されますが、時間枠内で2回以下しか表示されません。

##Data Staging - SMB and FTP
>SMBコマンド

>SMBコマンドは、データの移動および特定の場所へのデータのステージングに関する洞察を提供します。

####Drill Down to stream:smb
>そのリストの最初のファイルを取得し、時間枠内でその文字列を検索して、ファイルで何が起こっているのかを確認しましょう。 収集しているイベントに応じて、実行、読み取り、ダウンロード、またはファイルを参照する他のイベントを表示できます。 ここでは、SMBとFTPの両方がそのファイルが参照されていることがわかります。 stream：smbデータをピボットして、これら3つのイベントを見てみましょう。

####SMB Interesting Fields
>利用可能な興味深いフィールドを見ると、SMBデータ内のフィールドflow_idを見つけることができます。 フィールドflow_idをクリックすると、これら3つのイベントすべてが同じ「トランザクション」内で発生したことを示す単一のフローが返されます。このフィールドを見つけるには下にスクロールする必要がある場合があります。 見やすくなっています。

####What are all the SMB commands in this flow?
>pdfの1つに関連付けられた3つのイベントを持つこのフローを使用して、そのフロー内のすべてのコマンドを検索し、statsコマンドを使用して、使用されているさまざまなコマンドを確認できます。 ここから、それぞれをクリックして生のイベントにピボットし、何を処理する必要があるかを確認できます。

####SMB Read
>このフローで最も多くのイベントを持つSMB読み取りコマンドから開始できます。 これらの22K +イベントを取得したら、statsコマンドを使用してイベントカウントとbytes_inとbytes_outの合計を生成し、evalコマンドを使用してバイトをMBに変換できます。 資産センターのwrk-btunとしても知られる10.0.2.107は、サーバーのvenusである10.0.1.101と通信していることがわかります。 107から101に2MBが送信され、サーバーからクライアントに1.2GBが送信されました。 これは、ワークステーションに配置されるデータのかなりの塊のように聞こえます。 MITER ATT＆CKを見ると、これはリモートファイルコピーも示している可能性があります。

####SMB2 Create
>コマンドをsmb2 createに変更すると、少し異なる結果セットが得られます。 今回は、値（ファイル名）をstatコマンドに追加して、SMB作成の一部として参照されるすべてのファイル名を表示します。 MBの入出力は非常に小さくなっていますが、ファイルをコピーする読み取りが発生する前に、コンテナを作成することになります。

####SMB2 Close
>SMB2 Closeには使用するファイル名がなく、MB outの合計は適切なサイズですが、読み取り操作と同じサイズではありません。 それでも、データがサーバーを離れ、クライアントワークステーションに移動していることは非常に明確です。

####Drill Down to stream:ftp
>以前の検索に戻ると、stream：ftpデータをピボットして、他の2つのイベントを確認できます。

####stream:ftp
>生のイベントを見ると、10.0.2.107がpdfを160.153.91.7に正常にアップロードしたことがわかります。そのため、ftpを介したファイルの流出が見られます。 他の狩りをしたことがあるなら、すでにこの活動を見ているかもしれません。 そうでない場合、これは、代替プロトコルを介して盗み出された可能性がある他のファイルのハンティングを開始するトリガーになる可能性があります。

##Data Staging - Findings
####Were We Able To Confirm Our Hypothesis?
- 大量のファイルが10.0.1.101から10.0.2.107にコピーされました
- コピーアクティビティの後、ftpアクティビティを確認しました

####What We Learned
- 今月中の3つの異なる内部IPと10.0.1.101間の通信
 - 他の2つの内部IPについては、追加のハントが必要になる場合があります
- 10.0.2.107から10.0.1.101のSMB読み取りにより、サーバー（10.0.1.101）からクライアント（10.0.2.107）に1.2GBの転送が行われました
- 他の2つのバーストを除いて、他のどの時間よりもかなり多くのイベント
- ファイルはほぼすべてpdfであるように見え、イーストレシピディレクトリから来ています
- ポストファイルコピーは、10.0.2.107から外部IP 160.153.91.7へのFTP経由です。

####What should we operationalize?
- ワークステーションからサーバーへの通信は完全に正常であるため、外れ値分析が推奨される場合があります
　- Statsコマンドと、bytes_in / bytes_out、イベントカウント、ベースラインの動作と比較したファイル名の観察
- ファイルシステムに書き込まれたデータを確認するためのエンドポイントロギングが役立つ場合があります
- エンクレーブ間の転送のネットワークロギングも役立ちます。
- ワイヤーデータは、ログに基づいてこれを確認する唯一の方法であり、SMBは、あなたが望むかもしれないすべての忠実度を提供するわけではありません。
- 外部アドレスへのファイル転送やUSBへの書き込みなど、後続のアクティビティを探します

##まとめ
こんなログを見つけてしまったら頭をかかえること間違えなしな項目だった。
ｓａｍｂａ関係はあんまり知識がないので参考になった。

これですべての項目は終了です。