はじめに

2026年11月3日、Googleは、世界で130万台以上のAndroid搭載機器に影響を及ぼしていたXCPEボットネットのテイクダウンを発表しました¹。XCPEは、一部のAndroid搭載セットトップボックスなどにプリインストールされているマルウェアで、遠隔からのコマンド実行や情報収集に加え、外部モジュールを導入することでレジデンシャルプロキシとして機器を悪用する機能を備えています。

NICTでは、2026年7月に公開したブログ²でXCPEの一部機能について報告して以降も、マルウェアの解析と関連インフラの観測を継続してきました。テイクダウン前の観測では、日本国内で約1,900台のXCPE感染機器を確認しています。

本記事では、NICTが実施したXCPEの機能解析と実機調査の結果に加え、日本国内におけるXCPE感染機器の観測状況について報告します。

XCPE

XCPE（x.cpe）は、Android搭載のセットトップボックスなどにプリインストールされているマルウェアです。システム権限で動作し、MQTTを用いたC2通信を通じて、任意のコマンドやスクリプトの実行、アプリケーションのインストール、端末情報の収集などを行います。また、外部から追加のモジュールを導入・実行する機能を備えており、感染機器をレジデンシャルプロキシの出口ノードとして利用するほか、広告詐欺などの不正活動にも悪用されます。

XCPEは、複数の機種やファームウェアから確認されており、その実装や機能には検体ごとに違いが見られます。NICTが以前のブログで報告した検体³についても、VirusTotalでは67種類のセキュリティ製品のうち28種類がマルウェアとして検出しています。

XCPE検体の収集と署名情報の分析

NICTでは、Android搭載機器の実機調査を通じてファームウェアからXCPEを抽出するとともに、VirusTotalやGitHub上のリポジトリからも検体を収集し、解析を行いました。表に、収集した検体の入手元、APK署名情報に含まれるメールアドレス、および関連する機器を示します。なお、検体の入手元となったGitHubリポジトリは現在公開されていないため、Webアーカイブを参考文献に記載しています⁴。

Googleは、XCPEボットネットの開発・運用にVideostrong社が関与していたと報告しています。一方、NICTの調査では、Videostrong社以外のメーカーが製造したAndroid搭載機器にもXCPEがプリインストールされていることを確認しました。

具体的には、Shenzhen Skyworth Digital Technology社製のAndroid搭載機器のファームウェアからXCPEを検出しました。また、MECOOL KM2、KM7、KD3、およびLEAP-S1に関連する検体には、いずれもAPK署名情報に skydigital@skyworth.com が記録されていました。

Shenzhen Skyworth Digital Technology社は、中国に本拠を置く電子機器メーカーで、日本を含む世界各国でセットトップボックス端末などを販売しています。今回の調査結果は、XCPEのプリインストールがGoogleの報告で中心的に取り上げられたVideostrong社の製品に限らず、Shenzhen Skyworth Digital Technology社製の機器にも及んでいたことを示しています。

XCPEの実装形態とその変遷

NICTでは、収集したXCPE関連の検体について、特にレジデンシャルプロキシ機能の実装方式と導入方法に着目して解析を行いました。その結果、XCPEの実装形態は大きく以下の3種類に分類でき、インストーラー型、プロキシ機能内蔵型、プロキシ機能外部導入型へと変化してきたことを確認しました。

1. インストーラー型

端末内の所定のディレクトリに配置されたXCPEのAPKをインストールするタイプです。OTAアップデートなどによって配置されたXCPEの導入を担うと考えられます。このタイプ自体には、MQTTによる遠隔制御機能やレジデンシャルプロキシ機能は実装されていません。

2. プロキシ機能内蔵型

MQTTによる遠隔制御機能に加え、レジデンシャルプロキシ機能をXCPE本体に内蔵したタイプです。追加のモジュールを導入することなく、端末をレジデンシャルプロキシの出口ノードとして動作させることができます。

3. プロキシ機能外部導入型

MQTTによる遠隔制御機能を持つ一方、XCPE本体にはレジデンシャルプロキシ機能を実装していないタイプです。C2サーバから受信した指示に従い、プロキシ機能を持つ外部モジュールをダウンロード・インストールすることで、端末をレジデンシャルプロキシの出口ノードとして動作させます。

この実装方式では、XCPE本体とプロキシ機能が分離されており、外部モジュールの追加や更新によって端末の機能を変更できます。

実装形態の変遷と検知回避

これらの検体の解析から、XCPEは導入処理を担う比較的単純な実装から、プロキシ機能を本体に内蔵する形態を経て、外部モジュールとして追加する形態へと変化してきたと考えられます。

特に、プロキシ機能をXCPE本体から分離したことは、マルウェアの検知回避という観点で重要です。プロキシ機能を外部モジュールとして導入する構成では、XCPE本体に当該機能を実装する必要がなくなり、XCPE単体の静的解析では不正機能の全体像を把握することが困難になります。

NICTでは、こうした実装形態の変化について、Videostrong社がXCPEの悪性検知を回避するために導入・実行手法を変更してきた可能性があると考えています。Googleも、2024年後半にXCPE本体から不正モジュールが分離され、外部ローダーを介して実行する構成へ移行したことを報告しており、同様に検知回避を目的とした変更の可能性を指摘しています¹。

MQTTによるC2通信と遠隔制御

XCPEは、MQTTプロトコルを利用してC2サーバと通信し、遠隔からの指令を受信・実行します。解析した検体では、mqtt.szbboys[.]com のTCPポート3885、3886、3887などを接続先として使用していました。

XCPEは、機器ごとに割り当てられたMQTTトピックを購読することで、C2サーバから指令を受信します。トピックは /device/<model>/<chipId>/<action> という構造を持ち、<model> は機種名、<chipId> は機器固有の識別子、<action> は実行する処理を表します。

例えば、機種名が KD3 の機器に対してコマンドを実行する場合、/device/KD3/xxxxxxxxxxxxxx/function/cmd/read という形式のトピックが使用されます。XCPEの解析では、遠隔から実行可能なアクションが40種類以上定義されていることを確認しました。

また、ShodanによるC2サーバの調査では、EMQXの管理ダッシュボードが公開されていることを確認しました。EMQXはMQTTブローカーの実装の一つであり、XCPEのC2通信基盤として利用されていたと考えられます。

C2を通じた遠隔操作

XCPEには、MQTT経由で受信した指令に応じて、アプリケーションの操作、端末の制御、システム情報の収集などを実行する機能が実装されています。解析した検体で確認した主なアクションを以下に示します。

送信される利用者および端末の情報

XCPEは、遠隔制御機能に加え、利用者や端末に関する情報を収集し、C2サーバへ送信する機能を備えています。NICTでは、XCPEのC2通信プロトコルを解析し、C2サーバとの通信内容を調査しました。

その結果、XCPEはC2サーバである mqtt.szbboys[.]com への接続時に、利用者や端末に関する59種類のフィールドで構成されたJSONデータを送信することを確認しました。通信にはTLSが使用されておらず、JSONデータ自体も暗号化されていませんでした。

送信される情報には、端末のハードウェア構成や稼働状況に加え、以下のような利用者やネットワーク環境に関する情報が含まれていました。

• 端末に登録されたGoogleアカウントのメールアドレス
• CPU使用率
• LANおよびWANのIPアドレス
• 端末の言語設定
• メモリ容量（総容量・空き容量）
• ストレージ容量（総容量・空き容量）
• タイムゾーン
• 最終起動時刻
• 稼働時間
• Androidのバージョン
• XCPEのバージョン
• 国名
• MACアドレス（Ethernet／Wi-Fi）
• ネットワーク接続方式（Ethernet／Wi-Fi）
• Wi-FiのSSID
• Wi-Fiのリンク速度

このように、XCPEが送信する情報には、CPU使用率やメモリ容量などの端末の稼働状況に加え、GoogleアカウントのメールアドレスやWi-FiのSSIDなど、利用者の識別や利用環境の把握につながる情報が含まれています。また、LAN内のプライベートIPアドレス、デフォルトゲートウェイ、DNSサーバのアドレスなど、端末が接続されているネットワークの構成に関する情報も収集されています。

特に注意が必要なのは、これらの情報収集機能が、前述したC2経由の遠隔制御機能と組み合わされている点です。攻撃者は、XCPEを通じて端末が接続する宅内LANの情報を取得できるだけでなく、端末上で任意のコマンドやスクリプトを実行できます。そのため、XCPEが組み込まれた機器は、宅内LANに接続された他の機器への探索や、脆弱性を悪用した攻撃の足場として利用されるおそれがあります。

つまり、XCPEがプリインストールされた機器を家庭内のネットワークに接続することは、その機器自体を不正に利用されるリスクにとどまらず、同じネットワークに接続されたPCやスマートフォン、NASなどにも脅威が及ぶ可能性があることを意味します。特に、出所や安全性が確認できないAndroid搭載機器については、購入・利用に際して十分な注意が必要です。

XCPEの日本国内における実態

NICTでは、XCPEのMQTT C2サーバに接続する機器を観測し、ボットネットの規模と地理的な分布を調査しました。その結果、世界213の国・地域から、MQTT通信に含まれる機器固有の識別子（chipId）に基づき、合計800,521台のユニークな機器を確認しました。このうち、日本国内からの接続は1,891台で、全体の約0.2%を占めていました。

Googleの報告でもXCPEボットネットの世界的な分布が示されていますが、NICTの観測からも、日本国内に約1,900台のXCPE感染機器が存在していたことが明らかになりました。

日本国内で観測された機器をモデル別に集計した結果、最も多かったのは SviCloud 9Pの826台で、国内で確認された機器の約44%を占めていました。SviCloud 9Pは、国内外のテレビ番組を無料で視聴できることをうたうAndroid搭載セットトップボックスです。

次いで、TV_Stick が294台、4K_Android_TV_Box が107台でした。ただし、これらは汎用的なモデル名であり、C2サーバに送信された情報だけでは具体的な製品を特定できませんでした。

また、C2サーバに送信されていたWi-FiのSSIDには、「CAR MULTIMEDIA」「ALPHARD」「VELLFIRE」などの車載ネットワークを示唆する名称や、スマートフォンのテザリングに用いられる「○○のiPhone」といった名称も含まれていました。このことから、XCPE感染機器は家庭内に限らず、車内や外出先でも利用されていた可能性があります。

実機調査でXCPEのプリインストールを確認した機器

NICTでは、実際に市販されているAndroid搭載機器を入手し、ファームウェアの解析を行いました。その結果、以下の機器に前述した3種類のいずれかのXCPE関連コンポーネントがプリインストールされていることを確認しました。

XCPEのプリインストールは、セットトップボックスやストリーミング端末だけでなく、サウンドバーやプロジェクターなど、異なる種類のAndroid搭載機器でも確認されました。また、調査対象には国内の家電量販店で一般消費者向けに販売されていた製品も含まれています。

この結果は、XCPEの脅威が特定のメーカーや製品カテゴリーに限定されず、一般に流通しているAndroid搭載機器にも及んでいることを示しています。

XCPEの確認方法と対処

Googleによるテイクダウンでは、XCPEのC2サーバや関連するドメインなどの運用インフラに対する措置が講じられました。しかし、各機器にプリインストールされたマルウェア自体が除去されたわけではありません。したがって、テイクダウン後も、感染機器を使い続けることにはセキュリティ上のリスクが残ります。

NICTが調査した機器では、Androidの設定画面にあるアプリケーション一覧に「XCPE」が表示されることを確認しました。XCPEのインストールが確認された場合は、その機器の使用を中止し、宅内ネットワークから切り離すことを推奨します。

おわりに

今回の調査では、XCPEの機能解析とC2通信の観測を通じて、マルウェアの実装形態や遠隔制御機能、日本国内における感染機器の分布を明らかにしました。また、実機のファームウェア解析により、セットトップボックスだけでなく、ストリーミング端末、サウンドバー、プロジェクターなど、一般に流通するAndroid搭載機器にもXCPEがプリインストールされていることを確認しました。

XCPEが組み込まれた機器では、利用者の同意なく通信回線がレジデンシャルプロキシの出口ノードとして悪用されるほか、GoogleアカウントのメールアドレスやWi-FiのSSID、LAN内のIPアドレスなどが外部に送信されるおそれがあります。さらに、XCPEには遠隔から任意のコマンドやスクリプトを実行する機能があるため、感染機器が宅内LANに接続された他の機器への攻撃の足場として利用される可能性もあります。

今回の事例は、一般消費者向けのAndroid搭載機器にマルウェアがプリインストールされ、利用者が気づかないまま機器がサイバー犯罪に悪用されるという、サプライチェーンに起因するセキュリティ上の問題を示しています。利用者が機器の安全性を購入後に判断することは容易ではなく、製品の製造・流通段階からの対策が求められます。NICTでは引き続き、レジデンシャルプロキシに悪用されるIoT機器の実態把握と、関連するサイバー脅威の調査・分析を進めていきます。

参考文献