カスタム分析用に脅威スタックからデータをエクスポートする
Threat Stack は現在、 F5 Distributed Cloud App Infrastructure Protection (AIP) です。 今すぐチームで Distributed Cloud AIP を使い始めましょう。
このホストは侵害されていますか? このホストはいつもこうしていたのですか?
運用/エンジニアリング/セキュリティの分野で働いたことがある人なら誰でも、予期しない動作を示すサーバーを一度は経験したことがあるでしょう。 奇妙なプロセスが実行されたり、予想よりも多くのメモリが消費されたり、リクエストが受け入れられたり、GitHub への接続が確立されたりする可能性があります。
イベントをトリアージするための最初のステップは、イベントがあることを認識することです。 特定のホスト サーバーを指し示す可能性のあるデータ ソースは多数あります。
- ディスクやメモリ容量などを測定する監視ツール
- 警告を生成するセキュリティ侵入検知システム
- 特定のホストへの接続の失敗を示すapplicationログ
この時点で、アクセスして詳細情報を取得したいサーバーがあります。 すべてのシステム データが必ずしも SIEM に適合するとは限らないと仮定すると、次の論理的なステップは、ホストに接続し、オペレーティング システムの動作を直接照会することです。 環境に対する習熟度に応じて、uname や vmstat などのツールから、ps や lsof などのより具体的な項目まで、幅広い範囲にわたります。 どちらの場合でも、ホストが現在何をしているかが表示されます。 このプロセスには次のような問題があります。 実際のところ、現在の状態は気にしていません。何が変わったのかを知りたいのです。 Git でプル リクエストを取得する場合と同様に、コード ベース全体をレビューするのではなく、変更された部分だけを確認します。
Amazon S3へのデータ移植
Threat Stack Cloud SecOps Program℠では、SOC のセキュリティ アナリストが、お客様のこのような質問に答えるのに役立つソリューションを開発しました。 Threat Stack Cloud Security Platform® には、データ ポータビリティと呼ばれる便利な機能があります。 大まかに言えば、これにより、実行中の実行可能ファイル、ユーザー、コマンドライン引数、接続など、ホストから収集したテレメトリを取得し、S3 バケットに保存できるようになります。
S3 BLOB の優れた点は、大量のデータを安価に保存できることです。 問題となるのは、インデックス化されていない大量のデータを活用することです。 そのため、私たちは Amazon EMR を使用して Jupyter PySpark ノートブックを作成し、Apache Spark DataFrames と Python pandas DataFrames を使用して、マシンの現在の状態と保持されている以前の状態を比較するための強力なツールを作成しました。
ETL（みんなのお気に入り）
コード例を見る前に、いくつか注意事項があります。 テーブルとスキーマ参照は AWS Glue に保持され、 Linux システムの Threat Stack の生のイベント形式と一致します。 このデータを既存のデータ レイクに追加できます。 次に、Spark クラスターに対して、使用可能なテーブルと列を確認するために Glue から読み取るように指示する設定が定義されています。 その後、クラスターが作成されると、JupyterLab ノートブック内でテーブルを参照できるようになります。
注記： 次のコードは完全に現実のものですが、状況は作為的です。 セキュリティアナリストは、バレンタインデーのある時点で、当社のエージェントが稼働しているホストに侵入するよう依頼されました。 目標は、何が行われたかを把握することでした。
コードを見てみましょう
最初に作成する必要があるのは、SparkSession と SparkContext です。 幸いなことに、PySpark ノートブックを使用すると、最初のセルを実行するときにそれらは自動的にインスタンス化されます。
PySpark ノートブックの設定。
後で参照するオブジェクト spark と、spark コンテキストである sc を取得しました。 その後、それを使用してpandasとMatplotlibに読み込むことができます。
パッケージをインストールしています。
次の手順では、Glue テーブルに基づいてspark.table()を作成して列名を確認し、継承したスキーマを表示します。
AWS Glue から読み込まれた列の構造を読み取ります。
素晴らしい。これで、SQL クエリの実行を開始するために使用できる列と型を確認できるようになりました。 これで、任意のサーバーと任意の時間範囲を選択して比較できるようになりました。 ここでは、インシデント前の調査とインシデント後のフォレンジックに必要なデータを収集する 2 つの Spark DataFrame を作成します。
compact.audit_v4 から date_key、timestamp、tsEventType、syscall、connection、user、command、exe、args を選択します。date_key >= '2020-02-05-00' かつ date_key < '2020-02-14-00' かつ organization_id = '5a8c4a54e11909bd290021ed' かつ agent_id = 'b0f6bdb2-9904-11e9-b036-25972ec55a45' でグループ化 date_key、timestamp、tsEventType、syscall、connection、user、command、exe、args で選択します。compact.audit_v4 から date_key >= でグループ化 date_key、timestamp、tsEventType、syscall、connection、user、command、exe、args で選択します。 '2020-02-14-00' かつ date_key < '2020-02-17-00' かつ organization_id = '5a8c4a54e11909bd290021ed' かつ agent_id = 'b0f6bdb2-9904-11e9-b036-25972ec55a45' GROUP BY date_key、timestamp、tsEventType、syscall、connection、user、command、exe、args
2 月 14 日の侵害日を中心にデータをグループ化します。 (一部のノートブック セルは、読みやすさを考慮して GitHub Gist として表示されています。)
ここで、収集したデータの量を簡単に確認してみましょう。
両方の Spark DataFrame のレコード数をカウントして、調査に適切な量であることを確認します。
それは正しいようです。 preCompromiseDfとpostCompromiseDfの時間範囲ははるかに広くなっています。 (「Df」は、これらが Spark DataFrame オブジェクトであることを覚えておくためのもので、単なる命名規則です。)
Apache Spark DataFrames は、クラスター全体の DataFrame 全体を保存するので便利です。 これは大規模なデータ セットには最適ですが、この場合、実際に比較したいレコードの数は比較的少ないです。 そのために、 toPandas()を実行してそのデータをノートブック マシンのメモリに移動し、計算を高速化します。
この場合、「ビッグデータ」を扱っているわけではないので、残りの分析をローカルで実行する方が速くなります。
分析を始める
これで、2 月 14 日の深夜以降にこのサーバー上で実行されている新しい実行可能ファイルを確認するなど、強力な操作を実行できるようになります。
/tmp/EXCITED_WHILE /usr/bin/wget /tmp/FRONT_RUN /tmp/UNUSUAL_COMB /tmp/SURROUNDING_LOCK /tmp/nmap /usr/bin/scp /tmp/sliver /tmp/sliver2 /tmp/PROUD_THUMB
問題の夜間にサーバー上で実行されていた実行可能ファイルのリスト。
こんにちは、ランダムに大文字で始まる実行可能ファイル名をいくつか紹介します。nmap、scp、wget、そして sliver と呼ばれるものです。 少しグーグルで検索してみると、sliver はhttps://github.com/BishopFox/sliverと関連している可能性が高く、複数のプロトコルに対するコマンドと制御をサポートするインプラント フレームワークであることがわかります。
サーバーが侵害されたという証拠はありますが、十分な調査を行って、これらの実行可能ファイルで実際に何が行われたかを確認したいと考えています。 同じ DataFrame に対するフィルターとしてリストを使用すると、他の詳細と侵害の指標 (IoC) を引き出すことができます。
exe 引数 80 /tmp/EXCITED_WHILE ./EXCITED_WHILE 162 /usr/bin/wget wget https://github.com/andrew-d/static-binari... 255 /tmp/EXCITED_WHILE ./EXCITED_WHILE 256 /tmp/FRONT_RUN ./FRONT_RUN 359 /tmp/UNUSUAL_COMB ./UNUSUAL_COMB 360 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 464 /tmp/nmap 494 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 533 /tmp/EXCITED_WHILE ./EXCITED_WHILE 589 /tmp/FRONT_RUN ./FRONT_RUN 603 /tmp/EXCITED_WHILE ./EXCITED_WHILE 658 /tmp/EXCITED_WHILE ./EXCITED_WHILE 660 /tmp/FRONT_RUN ./FRONT_RUN 671 /usr/bin/scp scp -t /tmp/ 699 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 738 /tmp/UNUSUAL_COMB ./UNUSUAL_COMB 762 /tmp/sliver ./sliver 816 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 834 /tmp/sliver2 ./sliver2 878 /tmp/nmap /tmp/nmap 909 /tmp/EXCITED_WHILE ./EXCITED_WHILE 937 /tmp/FRONT_RUN ./FRONT_RUN 992 /tmp/FRONT_RUN ./FRONT_RUN 1023 /tmp/FRONT_RUN 1040 /usr/bin/scp scp -t /tmp/ ...
疑わしい実行可能ファイルのリストに関連付けられているすべての関連引数を抽出します。
したがって、ファイルの移動には scp が使用され、wget は GitHub からいくつかのコードを取得しました (その行に移動すると、nmap がシステムにどのように侵入したかがわかります)。また、その他のファイルはコマンドライン引数を受け取っていないため、実行の詳細はファイル自体に含まれています。 この時点で、証拠としてホストのスナップショットを取得し、インスタンスを終了するのが妥当です。
最後のステップは、環境内の他のホストが侵害されていないことを確認することです。 このため、以前の IoC リストからいくつかの項目を取り出し、すべてのサーバーで確認します。
compact.audit_v4 から date_key、timestamp、tsEventType、syscall、connection、user、command、exe、args、agentId、tty、session、cwd を選択します。date_key >= '2020-01-01' かつ date_key <= '2020-02-29' かつ organization_id = '5a8c4a54e11909bd290021ed' かつ tsEventType = 'audit' かつ syscall = 'execve' でグループ化します。date_key、timestamp、tsEventType、syscall、connection、user、command、exe、args、agentId、tty、session、cwd
52
このクエリは、環境全体にわたって疑わしい nmap および sliver アクティビティの 52 件の結果を返します。 pandas DataFrame に移動し、結果を各サーバーごとにグループ化することで、このビューをさらに絞り込むことができます。
独自の脅威スタック分析を始める
最後までお付き合いいただきありがとうございました。 私はこのデータが提供する可能性と、それを探索する新しい方法を見つけることに非常に興奮しています。 現在 Threat Stack プラットフォームを活用している場合は、このドキュメントをガイドとして使用して独自のデータ ポータビリティを設定できます。 利点は、独自のビジネス ニーズに合わせて保持するデータの適切なレベルを決定できることです。
当社の Threat Stack Oversight℠ サービスをご活用いただいている方には、30 日間のイベント データをご用意しております。データ レイクをお持ちでない場合でも、このツールセットを活用してお客様の環境に関するより詳細なフォレンジックを提供するために、喜んで協力させていただきます。
脅威スタック セキュリティ運用チームの次のステップは、データ サイエンス ノートブックを使用した次の分析の一環として、データを視覚的に解析するのに役立つグラフィックやチャートをさらに取り入れることを検討することです。 これについては後ほど詳しく説明しますが、ここでは地理的に特定されたいくつかの IP の最初のパスを示します (各円の密度は接続の数を示します)。
Threat Stack Security チームから、さらに多くの分析視覚化が近日中に公開されます。
Threat Stack は現在、 F5 Distributed Cloud App Infrastructure Protection (AIP) です。 今すぐチームで Distributed Cloud AIP を使い始めましょう。