新しい脆弱性や脅威に対して最適な検知ルールを作成するためには、包括的な調査が必要である。しかし、「最良」とはどういう意味だろうか?まあ、「最良」の解釈は、脆弱性について私たちが何を知っているかによって異なりますが、重要な情報が利用できないこともあります。したがって、悪意のある活動を追跡できる正確な検出ルールを開発するには、悪意のあるツールのバイナリコードのような、従来とは異なる領域でこの情報を検索する必要があります。
このブログでは、バックドアエクスプロイトのソースコードを詳細に分析することにより、正確なネットワークシグネチャを作成するプロセスについて詳しく説明します。ネットワーク分析におけるリバースエンジニアリングは、悪意のあるネットワークパケットを効果的に検出し、誤検出を減らし、最終的に悪意のある脅威から身を守るためのルールを構築するために不可欠です。OT/IoT
脅威の検知
ある脆弱性に関して利用可能な唯一の情報が、同じ研究者によって作成されたコマンドとエクスプロイトを実行するルーターの基本的で非技術的な記述であるとしよう。この限られた情報でも、そのエクスプロイトを検出する最初のルールを作成することは可能です。図1は、Nozomi Networks Labs IoT ハニーポットによって採取されたインテリジェンスとネットワークトレースの例を示しています。この例は、CVE-2022-27255を悪用するネットワーク・パケットを示していますが、悪用はすぐには明らかになりません。誤検出を防ぐためには、より多くのコンテキストが必要です。
この悪用を検知するには、使用されているプロトコルを調べ、特定のオフセットに存在すべきデータと存在すべきでないデータを理解する必要がある。SANSは、特定の文字列と、正当なパケットのパラメータに基づくパケットサイズに基づく検出戦略を提案している。
SANSは素晴らしい脅威検知戦略を提供してくれましたが、私たちの目標は、攻撃者が特定の脆弱性を悪用するさまざまな方法を検知することです。そのエクスプロイトの複数の亜種を検出できるような柔軟性のあるルールを作成し、誤検出の可能性を冒すか、あるいは、1つの亜種だけを検出することに焦点を絞った狭いルールを作成するかは、難しい決断です。
エクスプロイトに基づく検出ルールの作成
CVE-2022-27255を悪用した図1のようなパケットは、脆弱性が悪用されるたびにカスタムメイドされるわけではありません。そのため、この種のエクスプロイトが一般に公開されるようになると、これらのネットワーク・パケットがどのように作成されるかをより深く理解できるようになり、より優れた効率的な検出ルールを作成するのに役立ちます。
ほとんどの場合、脆弱性を発見した研究者が公開した最初のバージョンを基に、新たなエクスプロイトが作成されます。私たちは、IoT 、公開されているエクスプロイトのソースコードを模倣したマルウェアに狙われているデバイスを確認しています。私たちは、同じ脆弱性を悪用する異なる攻撃者間で、同じようなループ、文字列、実行フローロジックが存在することに気づきました。唯一の違いは、エラーをチェックする方法やデータ構造を初期化する方法にわずかな違いがあるだけです。
なぜだろうか?既存のエクスプロイトを複製することは、マルウェア作者にとって、すでに行われた研究に費やす時間とエネルギーを節約する便利な方法だからだ。つまり、新しい亜種はたいてい以前のバージョンと似ているため、ネットワークシグネチャの作成が容易になるのだ。
そのため、実際の脅威を検出する際に邪魔になる不要な検出を避けるために、追加情報が必要となる。これを達成するために、ルールは悪用に厳密に必要なコードにのみ依存しなければならない。
図2のTP-Link Archerデバイスのエクスプロイトを見てください。
バックドア攻撃の調査
私たちのチームは、リモートアクセスツール(RAT)、ボットネット、バックドアエクスプロイト、その他の悪意のあるツールのバイナリをリバースエンジニアリングすることにより、ネットワークシグネチャを日々作成しています。
例えば、数年前に検出され、現在も悪用されているバックドア悪用について考えてみよう。一部のNetisデバイス(中国ではNetcore)には、そのデバイスから任意のコマンドを実行したり、ファイルをアップロード/ダウンロードしたりできるようにするバックドアが仕込まれていた。コマンドの送信を開始するには、バックドアを有効にするための特定の文字列を送信する必要があった。いったん有効になると、バックドアはコマンドを受け付け、実行し、その結果を返すようになる。これはエクスプロイトそのものではないが、必要な調査手順は本質的に似ている。
私たちが調査を始めたとき、このバックドアにアクセスするための3つの異なるエクスプロイトを目にした:
- GitHubDDOS-RootSec
- GitHubMSF-Testing-Scripts
- イデオン
これらすべてのエクスプロイトにおいて、図3に見られるように、バックドアを有効にするための共通の文字列が見られました。
脅威検出の複雑さ
脅威検知の基本的な方法を確認したので、さらに一歩進んでみよう。ログインコマンドの検知だけに焦点を当てると、検知システムは新しい接続を識別することしかできません。バックドア実行ファイルが最初のログインパケットを受信すると、バックドアは有効化され、コマンドの実行を要求してパケットを処理する準備が整います。コマンドを実行するこれらのパケットはログインコマンドとは異なるため、同じ検出ロジックを使用して検出することはできません。
悪意のある接続では、最初のログインコマンドは1つですが、コマンド実行を要求するパケットは複数あります。もし私たちの検知システムがログインコマンドの検知だけに集中すれば、以前にバックドアを有効化した悪意のある接続を検知することはできないでしょう。もし私たちの検知エンジンが、バックドアがすでに有効になっているネットワーク上でリッスンを開始したらどうなるでしょうか?これは珍しい状況ですが、そのウィンドウを開いたままにすることはできません。このシナリオでは、検出システムはバックドアと相互作用している人を検出しないため、このバックドアへの接続を検出するには別のアプローチが必要になります。
パターンを見つけるための異なるアプローチ
このプロトコルがめったに使われない53413 UDPポートで実行されるという事実はさておき、検出パターンの研究に集中しよう。ログインコマンドを実行する方法にはかなりの一貫性があるが、異なるコマンドをすべて検出する単一のパターンを開発しようとすると、困難さが増す。
Exploit-DBに見られるように、8つのゼロで始まるパターンを送信するものもあれば、GitHubに見られるように、アルファベットの「A」とゼロを混ぜて送信するもの(AAx00x00x00AAAA)もある。また、Exploit-DBには、コマンドのヘッダーに0と1が混在している例もある!これらの例を見ると、いくつかの疑問が生じる。これらはすべて同じ目的を果たすものなのだろうか?これらのヘッダは厳密に必要なのか、それとも攻撃者は検出を避けるためにヘッダを完全にランダム化することができるのか?いくつかの異なるソースコードがありますが、私たちはバックドアにコマンドを送るこれら3つの異なる方法を見ました。私たちは、バックドアとやりとりする3つの方法がこれらだけであると確信することはできません。最悪の場合、私たちはこれら3つの異なる攻撃しか検出することができませんが、理想的には、バックドアとのすべての可能な相互作用を検出することが望ましいです。
いつものように、このバックドアに関する公式なドキュメントはありません...しかし、私たちの調査によってバックドアされた実行ファイルを見つけることができました。Metasploitの共同研究者の何人かは、開発中のコードがバックドアと適切にやりとりできるかどうかをチェックするために、バックドアシステムを実行しました。公式なドキュメントやバックドアのソースコードがない中で、バックドアのバイナリを手に入れたことは非常に良いニュースです。
バイナリーを逆工学してパターンを見つける
ここで、リバースエンジニアリングのプロセスによって、バックドアがどのように動作するのか、その内部ワークフロー、そして侵害されたデバイス上でコマンドを実行できるようにするために受信したインバウンド接続に対して行われるチェックを完全に理解することができます。既にリバースエンジニアリングは行われているので、サンプルを完全にリバースエンジニアリングするつもりはありません。
このバックドアの検出ルールを作成する方法を理解するために、コードのロジックを大まかに追い、受信したUDPパケットを解析するバイナリの部分に焦点を当てる。こうすることで、コードに関する知識を得て、バックドアとの相互作用をより正確に検出できるルールを作成できるようになります。
ネットワーク分析におけるリバース・エンジニアリングが重要な理由
脆弱性の悪用を検知するには、関係するすべてのプロトコルを深く理解する必要がある。時には、完璧な脆弱性検出範囲を達成するためには、いくつかの偽陽性検出のリスクを負う必要があります。これは、予測不可能な結果につながる偽陰性の警告よりも望ましいことです。
ボットネット開発者は、一つひとつの脆弱性を深く理解するのに時間をかけるよりも、幅広い脆弱性をカバーすることを優先する傾向がある。これは、攻撃を完璧なものにするために余分な労力を費やすと、検出されやすくなる可能性があり、わずかな修正でエクスプロイトが失敗する可能性があるためです。
したがって、悪意のあるツールのバイナリをリバース・エンジニアリングすることは、研究者が正確なネットワーク・シグネチャを作成する上で有効な手法となる。