偽ソフト配布サイト「銀狐」の配布基盤が応答方式を切替 — 360 Netlabが、一括探査の後にブラックリスト方式へ移行したと報告

要点

• 中国のセキュリティ研究チーム**「360 Netlab」は2026年9月14日、正規ソフトを装う偽ダウンロードサイトを運用する「銀狐（Silver Fox）」の配布基盤が、悪性サンプルを返す条件を「ホワイトリスト」方式から「ブラックリスト」方式へ切り替えたと報告した**。
• 切り替えは2026年9月12日に、同じ中継ノードへの40秒差の2件のリクエストが別々の結果を返したことで確認された。一方は無害なWeChatの公式インストーラー、他方は実際の悪性サンプルのURLだ。360 Netlabは同日04:35 UTC（日本時間13:35）に17回の対照実験を行い、応答を決めているのはRefererに含まれるドメインだけだと確認した。
• 新方式では、新規ドメインやRefererのないリクエストにも悪性サンプルのURLが返るため、「サンプルが返れば銀狐が運用中のドメイン」という従来の識別方法が使えなくなった。逆に、無害な素材が返るドメインは、すでに無効化された偽ドメインだと判定できるという新たな手がかりが生まれた。
• 360 Netlabは、IoCドメインのDNS・ゲートウェイでのブロック、端末のlocalStorageに「noah_relay_pool」キーが残っていないかの調査、RefererのないEXEダウンロードや非標準ドメインへのクロスオリジン通信の監視、社内ソフトウェア配布の一元化を企業向けの対策として挙げている。

何が報告されたか

360 Netlabは、正規ソフトを装う偽ダウンロードサイト「銀狐」の配布チェーンを継続的に追跡してきた。同チームによると、銀狐はSEO（検索エンジン最適化）の手法で偽サイトを検索結果の上位に表示させ、利用者に自分から「ダウンロード」をクリックさせる手口を使っている。

今回の報告の中心は、その配布チェーンの裏側にあるサーバ側の判定ロジックが、研究者による探査に反応して切り替わったという点にある。360 Netlabは、これまで観測してきた挙動を次の4段階に整理している。

4段階の変遷

第1段階 — 無条件で返す方式

最初期の中継ノードは、リクエストの送信元を一切判定していなかった。中継ノードにアクセスすれば、そのまま悪性サンプルのダウンロード先が返る。実装が単純で悪性サンプルを配りやすい一方、ノードが発見されれば研究者もサンドボックスもそのままサンプルを取得できるという弱点があった。

第2段階 — ホワイトリスト（Refererが鍵）

次に導入されたのがホワイトリスト方式だ。中継ノードのapi.phpは、リクエストヘッダーのRefererが銀狐が運用中の偽ドメインを指す場合にだけ、実際の悪性サンプルのURLを返すようになった。見るのはRefererのドメインだけで、ユーザーエージェントやパスは判定に使われていなかった。

第3段階 — 一括探査（研究者側の行動）

360 Netlabは、「Refererが鍵」という性質を逆手に取った一括探査を実施した。新しく登録されたセカンドレベルドメインを候補として用意し、それらをRefererに設定してapi.phpに順次リクエストを送り、悪性サンプルが返ってきたドメインを「銀狐が運用中の偽ドメイン」と判定する方法だ。この探査で、同チームは新たに投入された偽ドメインを複数特定した。360 Netlabは、この規模の探査が銀狐側の監視によって感知された可能性があるとしており、その後に方式が切り替わったとしている。

第4段階 — クラウドブラックリスト

2026年9月11日の午後にはまだホワイトリスト方式が有効だった。ところが**9月12日未明の観測で、同じ中継ノードが偽ドメインによって異なる応答を返す「分裂した結果」**が現れた。

• gg-steelseries[.]com[.]cn（SteelSeries GGを装う偽サイト）をRefererにしたリクエスト → WeChatの公式インストーラー（dldir1v6[.]qq[.]com/weixin/.../WeChatWin_4.1.13.exe）が返る
• org-bcut[.]com[.]cn（Bilibiliの「必剪」PCクライアントを装う偽サイト）をRefererにしたリクエスト → 実際の悪性サンプル（www[.]0akw8w[.]com/down910）が返る

この2件は40秒差で、参照先のドメイン以外の条件はほぼ同じだった。360 Netlabは同日04:35 UTCに7組・17リクエストの対照実験を行い、次の結果を得た。

• ユーザーエージェントを変えても結果は変わらない（ブラックリストに入ったgg-steelseries[.]com[.]cnはWeChatのパッケージ、それ以外は実際のサンプル）
• 偽サイトを装わない全新規ドメインやランダムなドメインをRefererにしても、実際のサンプルが返る
• Refererを付けない場合や、大手サイトのドメインをRefererにした場合も、実際のサンプルが返る
• ブラックリストに入ったドメインでは、Refererのパスやクエリ、大文字小文字、http/https、wwwの有無を変えても結果は同じ
• 60秒後に再試行しても結果は変わらない

つまり新方式では、**「ブラックリストに入ったドメインには無害な素材を返し、それ以外のすべてには実際の悪性サンプルを返す」**という判定になっている。360 Netlabは、無害な素材が返ってくるドメインこそが、すでに暴露・無効化された偽ドメインだと判定できるとしている（同チームは、この判定に反する例は観測していないとしている）。

配布の仕組みと新旧の違い

360 Netlabの解析によると、配布チェーンは**「偽サイト → 中継ノード → ペイロード配布サイト」の3層**で構成されている。

1. 偽サイト（gg-steelseries[.]com[.]cnなど） — 静的ページで、悪性サンプルは置かれていない。ページを開くとすぐに、中継ノードのrelays.jsonへ問い合わせて中継先の一覧を取得する。
2. 中継ノード（noah-ssh[.]com[.]cn、noah-relay[.]wotudj578[.]workers[.]dev、noah-relay2[.]wotudj578[.]workers[.]dev） — CloudflareとCloudflare Workers上に置かれ、2.5秒のタイムアウトで自動的に次のノードへ切り替える冗長構成になっている。ここでRefererのドメインを見て、返す内容を決める。
3. ペイロード配布サイト（www[.]0akw8w[.]com/down910） — 実際の悪性サンプルを配布する。無害な素材が必要な場合はWeChatの公式インストーラーが使われる。

旧版のスクリプトはapi[.]new-noah[.]topという単一のAPIに依存し、失敗時には偽サイトが自前でホストするsteelseries_gg_official.exeへフォールバックする作りだった。360 Netlabの観測では、この旧APIのドメインは現在名前解決できず、新版のスクリプトが先に動いてリンクを差し込むため、旧版のコードは機能していない。新しく取得した中継先の一覧は、ブラウザのlocalStorageにnoah_relay_poolというキーで保存され、中継の主ドメインが使えなくなっても、一度偽サイトを訪れた端末では配布チェーンが復元される仕組みになっている。

さらに360 Netlabは、favicon.icoへのリクエストに対して返された404ページにも、配布スクリプト全体が埋め込まれていたことを報告している。これは、スクリプトの注入がサーバ側で一律に行われていることを示しており、利用者がダウンロードボタンをクリックしなくても、ページを開いた時点でスクリプトが実行され、悪性サンプルのURLを先に取得しているという。

360 Netlabが示した企業向けの対策

360 Netlabは、報告の中で企業向けの対策を次のように挙げている。

• **DNSやゲートウェイの層でIoCドメインをブロックする。**とくに公式ドメインに似せた.com.cnの登録パターンを重点的に扱う。
• **端末のブラウザのlocalStorageにnoah_relay_poolキーがあるホストを調査する。**このキーの存在は、その端末が銀狐の偽サイトを訪れたことを示す直接の手がかりになる。
• RefererのないEXEファイルのダウンロードや、workers.dev、一般に使われない.com.cnドメインへのクロスオリジン通信を監視する。
• ソフトウェアのダウンロード先を社内のソフトウェア配布基盤や信頼できる許可リストに一本化し、偽サイトに到達する可能性自体を減らす。

日本の読者への影響

360 Netlabが今回追跡した偽サイトは、中国語圏で使われるソフト（SteelSeries GGやBilibiliの「必剪」）を装い、.com.cnドメインを使うものだった。だが、検索結果の上位に偽サイトを表示させて利用者に自分からダウンロードさせる手口はソフトや言語を問わず使われている。

今回の報告が示しているのは、配布基盤が「一方的に配布するだけ」の仕組みではなく、研究者の探査行動に応じて応答を変える運用になっているという点だ。実際、360 Netlabは1回の方式切り替えで、それまでの識別方法が使えなくなったと報告している。同チームによるlocalStorageのキーの確認やRefererのないダウンロードの監視といった対策は、日本国内の組織でもそのまま点検項目として使える内容だ。

出典

• 360 Netlab（Youngs）, 「银狐云端“生死簿”：从“无条件返回”到“黑名单”机制」（2026年9月14日）: https://blog.netlab.360.com/yin-hu-yun-duan-sheng-si-bo-cong-wu-tiao-jian-fan-hui-dao-hei-ming-dan-ji-zhi/