中国製ルーターのバックドア｜Zbtlink 20 機種の確認手順と日本での影響

はじめに

2026 年 8 月 5 日、セキュリティ企業 VulnCheck が、中国 Zbtlink（深圳市智博通電子）製ルーターのファームウェアに、出荷時点でリモート制御用のインプラントが組み込まれていたとする調査結果を公開しました。研究者はこれを ENDLESSDOORS と命名し、CVE-2026-66747 として採番しています。

この事案が通常の脆弱性報道と異なるのは、原因が実装ミスではなく、ベンダー自身の init スクリプトによって起動される常設のコンポーネントである点です。攻撃者が外部から侵入した結果ではなく、そのように出荷されていたというのが調査の主張です。修正ファームウェアは提供されておらず、パッチ適用による解決ができません。

日本では Zbtlink というブランド名の知名度は高くありませんが、Google トレンドでは「中国製ルーター」「バックドア」といった語が急上昇しています。自社の設置機器が該当するのか、該当しない場合でも何を学ぶべきなのかを整理しておく価値があります。

結論から述べます。本件は修正ファームウェアが存在しないため、パッチ管理ではなく機器そのものを信頼できるかという調達・設計上の問題として扱う必要があります。また、インプラントはルーター側から外向きに接続を張る設計のため、インバウンド遮断を中心とした従来型の境界防御では検知も遮断もできません。日本国内での正規流通は限定的と考えられますが、有線モデルや OEM 品、海外拠点、車載・仮設用途の CPE といった経路には注意が必要です。

ENDLESSDOORS の仕組みとアウトバウンド起点の設計

ENDLESSDOORS の本体は、プロセス一覧に紛れ込むよう命名されたユーザーランドのプロセスです。認証も暗号化もない平文の制御チャネルを外部に張り、受け取った文字列をそのまま root 権限で実行します。

括弧なしの kworker という偽装

Linux では、カーネルスレッドは ps の出力で角括弧に囲まれて表示されます。[kworker/0:0H-kb] のような表記がそれにあたります。調査対象となった AX3000（型番 Z8102AX-2DSIM）では、角括弧のない kworker が 2 つ、いずれも root ユーザーで、実メモリを消費した状態で動作していました。

root@OpenWrt:~# ps
  PID USER       VSZ STAT COMMAND
    6 root         0 IW<  [kworker/0:0H-kb]
   17 root         0 IW<  [kworker/1:0H-kb]
  651 root         0 IW   [kworker/0:2-pm]
 6811 root       852 S    kworker
 6826 root      1132 S    kworker

角括弧の有無と VSZ 値がゼロかどうかが判別の手がかりになります。カーネルスレッドはユーザー空間のメモリを持たないため VSZ はゼロですが、このプロセスには実体があります。ファイルシステム上は /usr/sbin/kworker/usr/lib/librctl.so/etc/kworker.cfg/etc/init.d/skworker として配置され、起動スクリプト skworker によってブート時に自動起動します。

実装のベースは 2015 年公開の rctl

このインプラントは、rctl（remote control linux）というツールを改変したものです。GitHub 上のリポジトリは 2015 年 1 月 14 日に公開されたのみで、その後の更新はありません。README では、大量の Linux デバイスを分類して管理し、クライアント側から接続を開始することでルーティングの問題を解決する、という設計思想が説明されています。

補足として、rctl はセキュリティ業界において以前から悪用例が知られています。Dr.Web のマルウェアデータベースでは、rctl をベースとしたリモートアクセス型トロイの木馬が Linux.BackDoor.RCTL.2 として登録されており、複数のマルウェアを配布するドロッパーの一部として観測されています。

既知の C2 実装が、そのまま量産機器のファームウェアに組み込まれていたという構図です。

参考: ycsunjane/rctl（GitHub）
リポジトリの README には、証明書認証による SSL 通信、クラス単位でのデバイス管理、リモートシェルログイン、クライアント発の接続によるルーティング問題の回避、といった機能が列挙されています。
https://github.com/ycsunjane/rctl

登録は 39 バイト、その後は popen で実行

インプラントがサーバーに到達すると、固定長 39 バイトのメッセージを送信します。内訳は、33 バイトのクラス識別子（末尾を null で埋めたもの）と、LAN 側の MAC アドレス 6 バイトです。これが登録処理のすべてであり、クライアント側もサーバー側も相手を検証しません。

登録後、サーバーから送られた文字列は popen() に渡され、uid 0 として実行されます。許可リストもサンドボックスも存在しません。さらに rctlbash という予約文字列を送ると、インプラントは 7001 番ポートへ 2 本目の接続を張り、疑似端末を割り当てて /bin/sh を起動し、対話型の root シェルを提供します。

制御プロトコルとして提供されている操作は、任意コマンドの root 実行と、root シェルの提供の 2 つだけです。

インバウンドが不要である理由

この設計の実務上の意味は、機器がインターネットから到達可能である必要がないという点にあります。接続はルーターの内側から外向きに開始されるため、NAT も、一般的なアウトバウンド許可のファイアウォールポリシーも、通常の TCP セッションと同じように通過します。

つまり、公開 IP を持つ機器も、複数段のファイアウォールの内側に設置された機器も、C2 に到達できる限りは同じ条件で制御可能ということになります。外部スキャンで開放ポートを探す従来の攻撃面の考え方では、この構造は捉えられません。

さらに、通信経路上の第三者や、ドメインの名前解決を制御できる者であれば、Zbtlink 以外の主体でもインプラントを掌握できます。VulnCheck は実際に rctl のサーバー側プロトコルを実装し、検証機からのアウトバウンド通信を横取りして root シェルを取得したと報告しています。

影響を受ける 20 機種と C2 エンドポイント

影響は単一モデルにとどまりません。Zbtlink 公式サイトのダウンロードページに掲載されていたファームウェアイメージのほぼすべてに同じインプラントが含まれ、いずれも skworker によってブート時に起動する構成でした。

検証で確認された型番一覧

VulnCheck が実機およびファームウェアイメージで確認した型番は以下の 20 機種です。

ここで重要なのは、筐体のロゴではなく型番で照合するという点です。Zbtlink は OEM / ODM 供給を公式サイトでも案内しており、同一のハードウェアとファームウェアが他社ブランドで販売されています。Amazon などでは Wiflyer というブランド名でも流通しており、たとえば「Wiflyer WG3526」は ZBT ロゴの同型機と同一の対象機器です。

調査対象は 20 機種ですが、OEM 供給分を含む実際の影響範囲はこれより広い可能性があり、網羅的な列挙はできないと報告書自身が認めています。

通信先となる 4 つのエンドポイント

各機種が接続を試みる先は、以下の 4 つに集約されます。

大半の機種はベンダー名を含む zbtctl.epplink[.]net に接続します。一方、検証に使われた AX3000 のみは DDNS サービスである wikaba.com のサブドメインを利用しており、帰属の特定を避けやすい構成になっています。

なお、VulnCheck 原文の対処セクションでは「3 つのエンドポイント」と記載されていますが、同記事内の一覧表には 4 件が掲載されています。本記事では表側の 4 件を対象として扱います。名前解決先の IP アドレスは変動する可能性があるため、遮断ルールはドメイン単位と IP 単位の両方で用意しておくことをおすすめします。

ベンダーへの事前通知が行われなかった理由

本件では、一般的な調整済み開示（coordinated disclosure）の手続きが取られていません。VulnCheck は、調整済み開示はベンダーがその挙動を意図していなかったことを前提とする仕組みであり、本件ではその前提が成立しないと説明しています。パーサーのメモリ破壊バグとは異なり、ベンダー自身の init スクリプトが起動する構成要素が、20 機種・数年分のイメージにわたって出荷されていたためです。

参考: ENDLESSDOORS Is Phoning Home. Pick Up.（VulnCheck）
“Treat this as a device-trust problem, not a patching problem.”
（これはパッチ適用の問題ではなく、機器の信頼性の問題として扱ってください）
https://www.vulncheck.com/blog/zbt-endlessdoors

修正ファームウェアが提供される見込みがないため、対処は検知・隔離・交換のいずれかになります。具体的な確認手順は後段で扱います。

日本での影響度: 技適と流通経路から見た現実的なリスク

日本国内で Zbtlink というブランド名を見かける機会は多くありません。ただし「見かけない」と「存在しない」は別の話です。この章では、国内での曝露度を制度と流通経路の両面から整理します。

技適の観点から見た正規流通の限定性

日本国内で無線機器を使用する場合、電波法に基づく技術基準適合証明または工事設計認証（あわせて技適と呼ばれます）が前提になります。技術基準適合証明は、総務大臣の登録を受けた登録証明機関が、無線設備 1 台ごとに技術基準への適合を判定する制度です。一方、量産品では設計単位で審査を受ける工事設計認証が一般的です。

参考: 技適マークのＱ＆Ａ（総務省 電波利用ポータル）
「一部の無線機を除いて、技適マークが付いていない無線機を使用すると、電波法違反になる恐れがあります」
https://www.tele.soumu.go.jp/j/adm/monitoring/summary/qa/giteki_mark/

Zbtlink の公式サイトでは、製品の取得認証として CE、FCC、RoHS が案内されています。技適に関する記載は確認できませんでした。同社製品の主要な販売チャネルは Amazon（米国）、Alibaba、自社 EC であり、日本の量販店やキャリア経由の流通は確認できていません。

結論として、Wi-Fi や LTE / 5G を国内で使用する用途に限れば、正規に導入されている可能性は低いと考えられます。技適の有無は総務省の検索ページで型番から確認できるため、心当たりのある機器があれば照会できます。

参考: 技術基準適合証明等を受けた機器の検索（総務省 電波利用ポータル）
https://www.tele.soumu.go.jp/giteki/SearchServlet?pageID=js01

なお、研究・開発用途などを対象とした特例制度は存在しますが、業務ネットワークでの常用を想定したものではありません。

それでも入り込む可能性がある経路

技適を根拠に「国内では無関係」と結論づけるのは早計です。以下の経路では、実務上入り込む余地があります。

1. 無線を使わない構成での利用

有線ポートのみを使い、Wi-Fi を無効化した状態で使うケース。電波を発射しなければ技適の議論は生じにくく、検証環境やラボで使われている可能性があります。

2. OEM / ODM 供給品

Zbtlink は OEM / ODM を公式に案内しています。国内ブランドのロゴが貼られた製品の中身が同一である可能性は否定できず、この場合は技適を取得したうえで国内流通しているケースも考えられます。

3. 海外拠点・海外出張時の調達

現地法人や支店が現地で調達した CPE が、VPN 経由で本社ネットワークに接続している構成。

4. 車載・仮設・イベント用途

5G / LTE ルーターは車両、建設現場、催事の仮設回線で使われます。IT 部門の資産管理台帳に載らないまま設置されている場合があります。

5. 委託業者・ベンダーによる持ち込み

保守作業や監視のために業者が持ち込んだ機器。

VulnCheck も、購買記録だけでなくホテルや支店の設置機材、車両、委託業者が設置した機器まで確認範囲に含めるよう呼びかけています。日本での焦点は「Zbtlink を買ったか」ではなく、「出所が明確でないセルラー CPE がネットワーク内に存在しないか」です。

政府・自治体の調達動向という補助線

国内の制度面でも、機器の出所を問う方向に動いています。報道によれば、政府は自治体が使用する IT 機器について、セキュリティ上のリスクが低いと認定した機器のみの調達を義務付ける方針で、2027 年夏の運用開始を目指しているとされます。経済産業省が所管する IoT 機器向けの評価制度 JC-STAR や、クラウドサービスのセキュリティ評価制度 ISMAP の認定品に限定する枠組みです。

民間企業に直接適用される制度ではありませんが、調達要件の作り方の参考にはなります。詳しくは後段のリスク判断の章で扱います。

自組織での確認手順と初動対応

まず確認すべきは 2 点だけ

多くの読者にとって、この章の作業は数分で終わります。以下の 2 点で該当がなければ、それ以上の確認は不要です。

zbtctl.epplink.net
online-string.com
rbdg4nzqadui.wikaba.com

ここから先は、該当が判明した場合、または網羅的に確認する場合の手順です。

# プロセス一覧（角括弧のない kworker が 2 つ存在しないか）
ps w

# インプラントの構成ファイル
ls -l /usr/sbin/kworker /usr/lib/librctl.so /etc/kworker.cfg /etc/init.d/skworker

# 通信先の設定
cat /etc/kworker.cfg

# 確立中のコネクション
netstat -tn

該当機器が見つかった場合の初動

修正ファームウェアは提供されていないため、対応は封じ込めと交換が中心になります。なお、この脆弱性の深刻度について二次情報では CVSS 9.3 と報じられていますが、公開時点で NVD 上の評価は確認できていません。スコアの有無にかかわらず、認証なしで root 権限が渡る構造である点をもって優先度を判断することをおすすめします。

交換までの期間、暫定的に上位のファイアウォールや IPS 側で該当通信を止める運用については、関連記事『FortiGate の仮想パッチ運用』で考え方を整理しています。

中国製ネットワーク機器は使ってよいのか: リスク判断のフレーム

この事案を受けて「中国製の機器は使わない方がよいのか」という問いが出てきます。ここでは感情的な結論ではなく、判断のための軸を整理します。

「脆弱性」と「意図的な実装」は別の問題

まず区別すべきは、対処の性質が根本的に異なるという点です。

脆弱性管理のプロセスは、ベンダーが修正を提供するという前提のうえに成り立っています。その前提が崩れた場合、脆弱性管理では扱いきれません。本件で VulnCheck が調整済み開示を行わなかった理由も、この点にあります。

扱うべき問いは「いつパッチを当てるか」ではなく「この機器を信頼し続けるか」です。

判断を難しくしている制度的な背景

中国製ネットワーク機器に対する懸念が繰り返し議論される背景には、2017 年施行の国家情報法があります。国立国会図書館の立法情報によれば、同法第 7 条は、いかなる組織および個人も法に基づき国の情報活動に協力し、その秘密を守る義務を有すると定めています。

参考: 【中国】国家情報法の制定（国立国会図書館 調査及び立法考査局）
「いかなる組織及び個人も、法に基づき国の情報活動に協力し、国の情報活動に関する秘密を守る義務を有し、国は、情報活動に協力した組織及び個人を保護する（第 7 条）」
https://dl.ndl.go.jp/view/download/digidepo_10404463_po_02720209.pdf?contentNo=1

中国政府はこの条文について、続く第 8 条が人権および個人・組織の合法的権益の保護を定めていることを挙げ、一面的な解釈であるとの立場を示しています。法解釈の当否をここで論じることはできませんが、調達側から見れば「ベンダーが要求を拒否できるかを外部から検証できない」という不確実性が残るという点が実務上の論点になります。

一方で、この構図を中国製品だけの問題として扱うのも正確ではありません。所在国を問わず、ファームウェアの中身を検証できない機器を信頼して境界に置いているという状況は共通しています。本件が示したのは、その検証が実際に行われていなかったという事実です。

用途別に判断する 3 つの軸

すべての機器を同じ基準で判断する必要はありません。以下の 3 軸で切り分けると、現実的な運用に落とし込めます。

その機器を通過する情報の重要度

検証用のラボ回線と、業務データが流れる支店回線では判断が変わります。前者であれば、隔離を前提に使い続ける選択肢もあります。

ネットワーク上の位置とセグメント設計

境界に置くのか、閉じたセグメントの内側に置くのか。本件のインプラントは配下の LAN 全体へのアクセスを可能にするため、その機器の LAN 側に何が接続されているかが影響範囲を決めます。

出口制御の有無

アウトバウンドを既定で許可している環境では、この種のインプラントは検知も遮断もできません。逆に、宛先とポートを限定した egress ポリシーと DNS ログの保全があれば、未知のインプラントであっても異常として浮かび上がります。

3 番目の軸は、機器の製造国にかかわらず有効です。製造国での選別は補助的な手段であり、本質的な対策は「機器を信頼しない前提の設計」に置くべきです。

修正が提供されない機器を残す場合の緩和策

交換が直ちにできない場合、以下の緩和策を組み合わせます。

• egress ポリシーの限定: 宛先を業務上必要なものに絞り、既定拒否とする
• DNS の集約と記録: 機器が任意のリゾルバーを参照できないようにし、クエリを記録する
• セグメント分離: 対象機器の LAN 側を独立したセグメントとし、社内ネットワークとの通信を制御する
• 上位機器での遮断とアラート: ファイアウォールや IPS 側で該当通信を止め、通信の試行自体を記録する

いずれも本件に固有の対策ではなく、修正が提供されない機器全般に適用できる考え方です。

調達要件への落とし込み

再発を防ぐ観点では、調達時の要件に以下を含めることが有効です。

• 型番単位での資産登録（ブランド名だけでは同一性を判断できないため）
• ファームウェアの提供元と、OEM 供給の有無の明示
• セキュリティ修正の提供期間と EOL の表明
• 機器が既定で行う外部通信の開示

前章で触れた自治体調達の動向は、認定を受けた機器に限定するという枠組みです。民間企業がそのまま適用する必要はありませんが、「出所と挙動を説明できる機器だけを買う」という原則は共通して使えます。

まとめ

ENDLESSDOORS は、実装の不具合ではなく製品に組み込まれた構成要素として出荷されたリモート制御機能です。修正ファームウェアが提供されないため、脆弱性管理ではなく機器の信頼性の問題として扱う必要があります。日本国内での正規流通は限定的と考えられますが、出所の明確でないセルラー CPE が社内に存在しないかを確認する価値はあります。

• Zbtlink 製 20 機種のファームウェアに root 権限で動作するインプラントを確認
• まず確認すべきは DNS ログでの 3 ドメイン検索と資産台帳のブランド名検索の 2 点
• 照合はブランドではなく型番で行い、OEM 供給品も同一の対象
• 認証も暗号化もない平文の制御チャネルで任意コマンドの root 実行が可能
• ルーター側から外向きに接続するためインバウンド遮断では検知できない
• 修正ファームウェアは提供されず、交換または厳格な出口制御が対応の中心
• 製造国による選別より、機器を信頼しない前提の設計が本質的な対策

以上、最後までお読みいただきありがとうございました。