新たに解析されたフィッシング攻撃キャンペーンでは、サーバー側でポリモーフィズム(多態性)を利用し、リクエストのたびにほぼ異なる認証情報窃取ページを生成する手口が確認されました。この手法により、ファイルハッシュや固定のHTML識別子、静的なJavaScriptシグネチャに依存した検知手法が無効化されてしまいます。
このキャンペーンは、SANS Internet Storm Center(ISC)に提出された1通のフィッシングメールがきっかけで発覚しました。このメールは受信者を hxxps://addresses[.]performs[.]vu/communications.html?good=[recipient_address] という構造のURLへ誘導するものでした。
一見すると、ありふれた誘導メールに見えました。しかしこのURL先では、極めて難読化されたJavaScriptが配信され、アクセスのたびに挙動が変化し、最終的には読み込むたびにソースコードが変わる認証情報窃取ページが表示される仕組みになっていました。
最初のアクセス時には、フィッシングフォームはまったく表示されませんでした。その代わり、ブラウザは約30秒間停止し、その間CPUの1コアが使用率100%に達しました。これはサーバー側の応答遅延ではなく、クライアント側の問題であることを示唆しています。
解析の結果、JavaScriptのデコーダーにロジック上のエラーがあることが判明しました。2つの関数が同じ未宣言のループ変数「k」を参照しており、これがローカル変数ではなくグローバル変数になっていたのです。
外側のルーチンは本来、デコード用のマップを構築する際に0から63までの値を反復処理するはずでした。各ループでは、Base64アルファベット用の文字列を生成するヘルパー関数を呼び出していました。
最後に呼び出されるヘルパー関数がグローバルカウンターを48にリセットしていました。その後、外側のループがこれを49にインクリメントするものの、内側のルーチンが再びリセットしてしまいます。
その結果、デコーダーは48→49という値を繰り返すループに陥ってしまい、ブラウザはレンダリングを完了できないままCPUリソースを消費し続けることになりました。
この変数スコープの衝突を修正すると、ペイロードが正常にデコードされ、それ以外は一般的な認証情報窃取フォームが姿を現しました。
この不具合のあるレスポンスは、当初は単純なコーディングミスのように見えました。しかしその後のリクエストでは事情が異なることが判明します。同じURLに再度アクセスすると正常に読み込まれるものの、レスポンスのたびにフィッシングページの実装内容が異なっていたのです。
研究者らが繰り返しページを読み込んで観察したところ、関数名や変数名がランダム化されていること、関数の順序が入れ替わっていること、数値が異なる算術式で表現されていること、そして最終的なフィッシングペイロードを含むエンコードされたJavaScriptブロックが変化していることが確認されました。
ページタイトルも「Solution」「Viewer」「Credentials」「Private」「Authenticate」といった、当たり障りのない単語の間でローテーションしていました。
同一URLを50回ダウンロードして検証したところ、50個すべてが異なるSHA-256ハッシュ値を持つサンプルとなりました。このうち、ページタイトルの種類は21種類確認されています。
49個のサンプルは正常に難読化解除に成功した一方、1個は別のランダム化された変数名の衝突が原因で、先述の無限ループ状態を再現しました。
ポリモーフィック型フィッシング攻撃
SANSの研究者らによると、ポリモーフィズムはJavaScriptのデコード後も続いていたとのことです。生成された各フィッシングページでは、フォームフィールド名、HTML要素のID、CSSクラス名、画像読み込みパラメータ、そしてゼロ幅文字の配置がそれぞれ異なっていました。
こうしたソースコードレベルでの変化があったにもかかわらず、被害者側に表示されるフォームや認証情報窃取のワークフロー自体は、実質的にほぼ同一のままでした。
この手法は、従来型の検知指標(インジケーター)の有効性を低下させることを狙って設計されています。
URLレピュテーションシステムであれば、依然としてこの攻撃インフラを検知できる可能性があります。しかし、単一の悪意あるハッシュ値、特定の入力フィールドの識別子、あるいは固定のJavaScript文字列に依存する検知手法は、リクエストのたびに構文的に新しいサンプルが生成される状況では機能しなくなる恐れがあります。
Zscalerは以前、ランダムな名前のファイルやディレクトリに加え、ランダムなHTML属性の値をアクセスごとに生成し、解析やシグネチャベースの検知を困難にするキットについて報告しています。
しかし今回の事例は、攻撃者にとって過度な変異(ミューテーション)が運用上のリスクをもたらしうることも示しています。収集された約56個のサンプルのうち、2個は正常に機能しませんでした。これは、このポリモーフィック生成エンジンが、時折、自身のデコード処理を完了できないページを生成してしまうことを示しています。
この失敗率だけでキャンペーン全体の信頼性を判断することはできませんが、回避を狙ったコード生成が、攻撃者による認証情報窃取の成功率を低下させる可能性があることは分かります。
このキャンペーンがリクエストごとにページを生成している点から、LLM(大規模言語モデル)が関与しているのではないかという疑問が当然浮かびます。しかし、それを裏付ける証拠は存在しません。
むしろ、体系的な変換パターンや繰り返し発生する変数スコープの不具合は、JavaScriptのスコープを正しく考慮せずにコードのリネームや並べ替えを行う、従来型のポリモーフィック難読化ツールによるものである可能性の方が高いと考えられます。
とはいえ、この可能性自体は依然として無視できません。Unit 42は、被害者のブラウザ内で信頼されたLLMサービスを呼び出し、悪意あるJavaScriptを動的に生成するWebページの概念実証(PoC)を既に実演しています。
このモデルを用いれば、アクセスごとに構文的に異なるフィッシングペイロードを生成し、静的検査やネットワークのみに依存した検査の有効性を低下させることが可能になります。
防御側にとっての実践的な教訓は、振る舞いおよびランタイムのシグナルを優先することです。具体的には、不審なフォーム送信先、ブラウザ側での難読化解除の動き、過度なCPU消費、動的に生成されるDOMコンテンツ、そして認証情報の窃取行為などが挙げられます。
ポリモーフィズムは静的シグネチャを無力化するかもしれませんが、認証情報を収集し外部へ持ち出すというページの最終的な挙動そのものを変えるわけではありません。
★ 削減すべきセキュリティツールはどれか?1ページでスコア化 – Inherited Security Stack Guideをダウンロード
翻訳元: https://gbhackers.com/polymorphic-phishing-attack/
