LoginSignup
0
0

More than 3 years have passed since last update.

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

Posted at

Boss of the SOC (BOTS) Advanced APT Hunting Companion App for Splunk
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.

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

全13回

  1. 概要とPowerShell Empire
  2. FTP Exfiltration
  3. DNS Exfiltration
  4. Adversary Infrastructure
  5. Spearphishing Attachment
  6. User Execution
  7. Account Persistence
  8. Scheduled Task
  9. Indicator Removal
  10. User Agent Strings
  11. OSINT Gathering
  12. Lateral Movement
  13. Data Staging

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によると中間貯蔵のことらしい。

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への書き込みなど、後続のアクティビティを探します

まとめ

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

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0