- Cisco Talos は、NetSupport RAT を利用して持続感染を引き起こす複数のマルウェア攻撃を積極的に追跡しています。
- これらの攻撃では、難読化とアップデートによって検出を回避しています。
- Snort
が提供する強力な防御により、マルウェアがエンドポイントに到達する前に検出できます。 - Talos ネットワーク検出・対応チームによる詳細解説の初回となる今回は、防御担当者が Snort を活用して回避型マルウェアの脅威を検出する方法について詳しく説明します。
2023 年 11 月、複数のセキュリティベンダーが新しい NetSupport RAT 攻撃を確認しました。侵害された悪意のある Web サイトに仕込んだ偽のブラウザ更新を使用してユーザーを騙し、PowerShell コマンドをダウンロードして起動するステージャをダウンロードさせるというものです。この PowerShell コマンドにより、NetSupport Manager のエージェントが攻撃対象のマシンにインストールされ、永続性が確立されます。
2024 年 1 月、セキュリティ研究者らは、同じ攻撃に関する別の分析を発表しました。JavaScript の初期ペイロードに若干の違いはあるものの、攻撃者が初期ステージャの難読化に改めて力を入れていることがわかります。また、ランダム化された新しいインストールパスなど、エージェントのインストールにも変更が確認されています。
そこで、Cisco Talos は独自の詳細分析を続行し、攻撃で使用されている複数の難読化や回避の手口を特定して、ユーザーを保護し続けるための適切な検出方法を編み出しました。攻撃の難読化の手口に存在する具体的な弱点と侵害の指標（IOC）を特定することで、この攻撃を高い精度で検出することができます。また Talos は、Snort や ClamAV など主にオープンソースの検出ツールを持っているという特異な立場にあります。これらの機能について明確にご理解いただけるよう、ここからは Talos の検出手法について詳しく説明していきます。
攻撃の経緯
NetSupport Manager は、リモートデバイス管理用として 1989 年から市販されているツールです。IT リモートサポート業界の多くのツールと同様、NetSupport Manager も、独自の RAT を開発できない、あるいは開発したくない攻撃者に武器として利用されてきました。NetSupport が初めて悪意のある目的で利用されたのは 2017 年のことでした。現在では、大半のセキュリティベンダーに、RAT として広く認知されるようになっています。2020 年代には、多くのオフィスワーカーがテレワークにシフトしました。その結果、フィッシング攻撃やドライブバイダウンロード攻撃で NetSupport RAT が使用されることが増えました。また、他のローダーと併用されるようにもなりました。今回の攻撃は、近年で最も注目すべき NetSupport RAT の使用事例です。悪意のある大規模な広告キャンペーンで、数十ものドメインに散らばる数百もの既知のステージャの亜種が使用されています。
攻撃の概要
VirusTotal のグラフのコンポーネント
- ステージ 1 は、JavaScript のファイルです。複数存在する悪意のある広告や侵害された Web サイトの 1 つからダウンロードされます。これは難読化されたダウンローダーであり、ステージ 2 の JavaScript と PowerShell のペイロードをメモリ内に保持します。実際の機能はドロッパーと言えます。ステージ 1 は難読化されていて、他の点では無害な JavaScript ライブラリ内に埋め込まれています。
- ステージ 2 では、JavaScript で PowerShell スクリプトが実行されます。どちらも難読化されており、PowerShell は JavaScript の中に、JavaScript はランダムな ASCII 16 進数の大きなコメントブロックの中に埋め込まれています。PowerShell は、base64 エンコードされた ZIP を取得するために、別の HTTP GET を実行します。取得できたら、半ランダムなパスにペイロードを展開して実行を開始し、基本的なレジストリの永続性を確立します。
- 最終ペイロードは、市販の NetSupport Manager RAT ユーティリティの完全にポータブルなインストールです。対象を絞った検出を避けるために、スクリプトが追加されていたり、ファイル名が若干変更されたりしているものもあります。
ステージ 1：JavaScript ステージャ
3b587d0c311e8ebc3bb104d564235c41ef8e64592c7419f17f48e0cee9ebc878 のペイロード
上のスクリーンショットは、ステージ 1 の JavaScript の古いバージョンの正規化された内部ペイロードです。この古いサンプルでは、他の点では無害な JavaScript ライブラリ内に実際の悪意のあるコードが埋め込まれています。使用されるライブラリは、jQuery、moment.js、SheetJS などさまざまです。なお、このステージの実際の悪意のあるペイロードは、ほとんど難読化されていません。URL をダウンロードする次のステージはプレーンテキストです。HTTP 接続を作成するための「activeXObject」の呼び出しも、eval の呼び出しもプレーンテキストです。
01d867d552a06bd778c812810a476441681c4bebabf967e80f8024b3856cb03e のペイロード
一方こちらは、同じ攻撃のごく最近（最初に確認されたのは 2024 年 3 月 9 日）のステージャのサンプルの正規化されたコンテンツです。旧バージョンと同様に、他の点では無害なライブラリ内に悪意のあるペイロードが埋め込まれています。以前のバージョンよりも改善されており、オープンソースツールの javascript-obfuscator を使用して、内部の悪意のあるペイロードがさらに難読化されています。これに伴い、プレーンテキストの「activeXObject」と「eval」は削除されました。ただ、JavaScript-obfuscator の出力パターンは、すべての変数名と関数名がアンダースコアで始まるランダムな 16 進数値になるというものなので、高精度で特定が可能です。
難読化を解除した 01d867d552a06bd778c812810a476441681c4bebabf967e80f8024b3856cb03e
新旧のサンプルにはどちらにも主に 2 つの特徴がありました。まず、すべての難読化は事前に計算されており、ダウンロードのたびに行われるわけではありません。これは、javascript-obfuscator で難読化された後でも、非常に多くのステージが共通のエントリーポイント関数で特定できるという事実から確認できます。また、難読化済みのステージャは、新しいランダムなダウンロード URL を埋め込んで再利用されます。しかも、この URL はプレーンテキストになっているので、あるステージャの特異性の高い関数名を特定できれば、さらに多くのステージャを見つけ、埋め込まれているダウンロード URL を静的に自動抽出することができます。この方法なら、分析用のサンドボックスにすべてのステージャを投入するよりはるかに短時間で済みます。
fast_pattern のみの検出ルール
ステージ 1 の検出
検出については、Snort を使用して fast_pattern のみのファイルルールを活用できます。このシンプルなルールで検出されるのは、ダウンロードされるステージャの特定のクラスタのみですが、特異性の高いテキストを対象とする fast_pattern のみのルールなので、このルールを実行するオーバーヘッドがほとんど生じません。そのため、より一般的な Snort ポリシー構成に組み込むことが可能です。さらに、この Snort 3 ファイルルールは、FTP や SMTP など、ファイルが伝送されるプロトコルからすべての抽象化を行うため、既知の悪意のある広告以外の方法でファイルが伝送されている場合でも、より広範な攻撃対象領域をカバーできます。
ステージ 2：JavaScript および PowerShell のドロッパー
この攻撃の第 2 ステージは、ディスク上の JavaScript によりダウンロードされるメモリ内ペイロードです。PowerShell を呼び出す JavaScript 関数で構成されています。
6f3681cd91f7a19c1cf2699e1f9f7b550dfe46841ab5171124e79979fae5424a のペイロード
JavaScript のコンテンツの両側は、ランダムに繰り返されるサイズが大きなコメントブロックで埋め尽くされています。実際の JavaScript は非常にシンプルで、PowerShell コマンドラインを実行できるようにする ActiveXObject（「WScript.Shell」）への呼び出しを少し難読化したものです。
難読化を解除した 6f3681cd91f7a19c1cf2699e1f9f7b550dfe46841ab5171124e79979fae5424a
PowerShell の呼び出し部分で、ドロッパーとしての機能の大半が実行されます。PowerShell は、コマンドラインフラグ「-Ex Bypass」、「-NoP」、「-C」で実行されます。「-Ex Bypass」は、実行ポリシーを「Bypass」に設定して署名なしの実行を可能にします。「-NoP」は「-NoPolicy」の略で、現在のユーザーのスタートアップスクリプトを回避します。「-C」は「-command」の略で、以降のコマンドライン文字列を PowerShell スクリプトとして実行します。コマンド自体は、次のステージを単純にダウンロードするものです。次のステージとは base64 エンコードされた ZIP ファイルで、この中に NetSupport Manager エージェントのポータブルインストールが格納されています。ダウンロードされたペイロードは、base64 で復号されてからディスクに書き込まれ、攻撃対象のインストールフォルダに展開されます。エージェントの主要な実行ファイルである「client32.exe」が出力ディレクトリに存在することを確認するチェックを行ったうえで、このファイルを実行します。最後に、ログイン時にエージェントのユーザーレベルの永続性を確立するためのレジストリエントリが作成されます。
興味深いことに、このステージの難読化に使われている手口は、ステージ 1 のファイルとは異なります。PowerShell ファイルは、ランダムな変数名と文字列連結によってわずかに難読化されているだけです。JavaScript の難読化では、前述したサイズの大きいランダムなコメントブロックに加えて、これと同じ手法が使用されています。この難読化は非常にわずかなものなので、静的シグネチャで十分検出できます。ステージャの今後のバージョンでさらに難読化された場合には、Snort で js_data のような正規化されたコンテンツバッファを使用すれば、このペイロードを引き続き一貫して把握できます。ただ、2023 年 11 月から 2024 年 3 月まで、ペイロード URL の他にはほとんど変化がありません。
ステージ 2 の検出
Snort による検出には、PowerShell スクリプトのコンテンツと一致する単純な一連のコンテンツを使用できます。難読化されていない永続化用のレジストリキーと PowerShell フラグを組み合わせれば、潜在的なマルウェアドロッパーを検出できる優れたルールができあがります。さらに、client32.exe のファイル名をルールに含めて検出対象を絞り込むこともでき、この攻撃あるいは類似の NetSupport RAT の使用に対する警告であることがわかるようになります。
他には、HTTP サービスルールを使用する方法もあります。HTTP_PORTS を事前に定義する必要がある Snort 2 とは違って、Snort 3 のサービスインスペクタは、ポートに関係なく既知のサービスを識別できます。このルールは、攻撃者が HTTP ペイロードをホストしているポートに関係なく、悪意のあるコンテンツを検出できます。
この Snort ルールを使えば、ドロッパーペイロードの現在のバージョンを識別して防御できます。より総合的な防御アプローチを取りたい場合には、動作検出も含めるとよいでしょう。Talos は、テキストの難読化に関係なく、このドロッパーの動作を確認できるので、保護されたエンドポイント上でこの手口が使われるのを効果的に防ぎ、攻撃者に戦術を変更させることができます。
Sigma による検出の例
Sigma の動作ルール言語を使えば、この検出を非常にうまくカプセル化できます。ほとんどのインストールを検出することができますが、名前の変更や別のレジストリキーの使用による難読化を識別することはできません。
難読化された NetSupport Manager のダウンロード
少し話が戻りますが、PowerShell 呼び出しでは、NetSupport Manager エージェントの全インストールである base64 エンコードされた ZIP ファイルがダウンロードされます。NetSupport Manager など、ほとんどの正規ソフトウェアパッケージの配布にはめったに使われない方法です。たいていのアプリケーションは、MSI パッケージまたは EXE インストーラを使用してインストールされ、完全なアプリケーションが難読化されずにダウンロードされます。攻撃者は、クライアントのバイナリを難読化していません。既存のコンパイル済みバイナリの難読化は、ステージ 1 およびステージ 2 のファイルで特定されたソースコードスクリプトの難読化よりも難しいからです。このため、NetSupport Manager クライアントの実際のロジックのほとんどを含む固有の DLL の名前は変更されていません。
悪意のあるファイルコンテンツをスキャンするには、base64 コンテンツをストリームデコードし、メモリ内で解凍する必要があるように思えるかもしれませんが、base64 フォーマットの ZIP が持つ 2 つの特徴を利用することができます。1 つめの特徴として、特異性の高い DLL 名は、ZIP アーカイブの中央ディレクトリ（アーカイブに含まれるファイルの情報を保持している構造）でひとまとめになっています。2 つめの特徴として、base64 はランダムなエンコーディングではないため、特定の入力を表す base64 エンコード文字列（可能性は 3 つ）をすべて事前に計算できます。この仕組みについては、CyberChef が優れたデモを公開しています。この方法では、特定の base64 文字の 6 ビットのエンコードサイズ内で取り得る 2 ビットのアライメント位置を使います。これをすべてまとめると、静的なコンテンツの一致だけを探す高速ルールとして使える base64 エンコードされた DLL 名のすべての組み合わせを、事前に計算できることになります。
この攻撃で NetSupport RAT を使用している攻撃者は、通常、RAT エージェントを展開する最速の方法を探っています。NetSupport Manager エージェントの難読化はもちろん、ドロッパーの難読化にもあまり力を入れていないので、攻撃者が使用する非標準的なダウンロードパスの検出には、このルールが効果的です。
Snort によるその他の検出
Talos は、NetSupport Manager エージェントのネットワークアクティビティに対する既存の Snort カバレッジを提供しています。2017 年に作成された SID 44678 を活用したものです。また、攻撃者による利用が増加したため、2020 年に SID 53539 ～ 53544 を作成し、カバレッジを拡大しました。直近の攻撃については、以前にはなかった Snort の機能を使ってカバレッジを拡大しました。ファイルルールは Snort 3 でのみ利用できる機能です。ファイルを伝送するプロトコルからコンテンツの抽象化を行えるので、より広範な検出が可能になるシグネチャを作成できます。
NetSupport RAT のファイルは通常難読化されておらず、多くの特殊な機能を持つ正規の市販製品なので、ファイル検出機能を作成できる方法は多数存在します。たとえば EXE にも DLL にも、NetSupport Manager クライアントの製造元と製品情報がすべて詳細に記載されています。
他の正規のソフトウェアのバイナリに NetSupport Manager の完全なメタデータが含まれている可能性は低いため、リバースエンジニアリングを行わなくても、バイナリを識別できる重要なシグネチャを得られます。Snort には Unicode 文字列用の修飾子はありませんが、Unicode テキストバイト文字列は検出に活用できます。先述したとおり、「ファイル」ルールターゲットを使用すれば、HTTP ダウンロードよりもはるかに広い範囲に検出網を広げられます。NetSupport Manager RAT を使用する他の攻撃についても、複数のプロトコルのファイルストリームを検査できる Snort の機能があるため、同じルールで確認できます。
NetSupport RAT は攻撃で使用され続けていますが、広く使われているがゆえに、わざわざリソースを割いてまで独自のツールやより回避的な手口を開発しようとは思わない攻撃者の妨げになっています。この攻撃は今も活発に行われ、更新もされているため、いずれ攻撃者がそうした手口を開発して展開するのを確認することになるかもしれません。今のところは、持続的ではあるものの高度ではない脅威の一例と言えます。
IOC（侵害の指標）
この脅威に関連する IOC は、こちらをご覧ください。
本稿は 2024 年 08 月 01 日にTalos Group
Authors