2026年11月、Google が「出荷時からバックドアが入っていた Android TV ボックスなど、130万台を超える端末のボットネットを止めた」と発表しました。サイネージで安い Android TV ボックスを使っているなら、買ったときの様子 → Play プロテクトの認定 → ルーターでの通信 → ADB の順に確かめ、あやしい端末はネットワークから外して替えます。日本の警察庁も、この件に協力しています。感染していた端末には、デジタルサイネージの端末も含まれていたと Google は書いています。
安い Android ボックス(STB)は、サイネージを小さく始めるときの定番です。Google が感染端末の例にデジタルサイネージを挙げたことで、サイネージの業界でも、自分たちの問題として取りざたされ、気にされています。この記事では、店や会社でサイネージに Android ボックスを使っている方・これから使う方に向けて、次のことをまとめます。
- 何が起きたのか(Google・警察庁・調査会社の発表をもとに)
- サイネージで使っていると、何が困るのか
- 手元の端末の見分け方(Play プロテクト認定 → ルーター → ADB の順に)
- 印が分かっていない端末を、いちから検査するときの手順(実際の検査で使われた4段の手順)
- 見つかったとき・不安なときの対処と、安全な端末の選び方
この記事の前提:内容は、2026年11月9日時点で公開されている発表・報告をもとにしています。編集部は、名指しされた端末を持っておらず、この記事の確認手順を感染した実機で試していません(未検証)。ADB のコマンドは、Android の公式ドキュメントに載っているものだけを使っています。
何が起きたのか(2026年11月の発表)
Google の発表:「XCPE」ボットネット
Google の脅威分析チーム(Google Threat Intelligence Group)の報告(日本語版は2026年11月4日付)の内容は、次のとおりです。
- 規模:「XCPE」と呼ばれるバックドアで、130万台以上のセットトップボックスがボットネットに組み込まれていた。Google は業界のパートナーと一緒に、指令を出すサーバーやドメインを止めた
- だれが入れたか:Google は、このバックドアが Android 端末のメーカー(OEM/ODM)である Videostrong Technology 社によって「経済的利益を目的に意図的に開発、配置、運用されていた」と、高い確信を持って評価していると書いている。内部の一部の人の不正や開発のミスではない、という評価
- どこに入っているか:バックドアの本体(
x.cpe。一部ではcom.oemservice)は、出荷時のファームウェアに入っている。利用者がアンインストールしても、再起動のときに端末の中の別の領域(/oem/)から入れ直される - 何をするか:利用者の同意の記録を消し、Google Play プロテクトの検証を止めたうえで、ほかのプログラムを黙って入れて動かす。Videostrong 社は、この入口を使う権利を犯罪グループに売っていた、とされる。入れられていたのは、端末の回線を他人の通信の出口として貸す「レジデンシャルプロキシ」、余った回線を売る「帯域の共有」、見えない所で広告を再生する「広告の不正」、別のバックドアなど
- どんな端末か:Google の言葉では「感染デバイスの大半は Android TV セットトップボックスですが、遠隔医療端末、カラオケ機器、デジタルサイネージなどのその他の Android ベースの IoT デバイスも確認されました」
- Google の対応:Videostrong 社との提携をやめ、同社と子会社・関連会社が認定 Android デバイスを作ること・売ること、ほかのメーカーにソフトを提供することを禁じた。認定 Android TV デバイスのファームウェアの検証も強めるとしている
Google は、この対応に協力した相手として、日本の警察庁と、Lumen、HUMAN Security、Plume、Synthient、TrendAI を挙げています。
日本の警察庁の発表
警察庁は2026年11月4日に「Google社と連携した犯罪インフラのテイクダウンについて」を公表しました。書かれているのは、次のことです。
- 警察庁、関東管区警察局サイバー特別捜査部、福岡県警察が、レジデンシャルプロキシの対策で Google と連携してきた
- 2025年9月、福岡県警察がインターネットバンキングの不正送金事件で不正アクセス元を捜索したところ、不正なアプリが混入された IoT 機器が見つかった
- サイバー特別捜査部がそのアプリを解析し、機器の製造・販売の状況を調べて、Google に情報を提供した
つまり日本でも、こうした機器が置かれた回線が、犯罪の「出口」に使われた例がある、ということです。日本国内に何台あるかは、警察庁も Google も公表していません(2026年11月9日時点)。
名指しされているメーカー・製品
一次情報で名前が出ているものだけを挙げます。
| 名前 | だれが、どう書いているか |
|---|---|
| Videostrong Technology(中国・深圳のメーカー) | Google が、バックドアを意図的に入れて運用していたと「高い確信を持って評価」(Google) |
| MECOOL ブランドの TV ボックス | 調査会社 Synthient が、MECOOL の Google TV ボックス(KM9PRO 系)を買って調べ、バックドアが最初から入っていたと報告(Synthient)。Plume も、同じ指令サーバーにつながる端末の多くが MECOOL だったと報告(Plume の白書・PDF) |
| 機種名の一覧 | Synthient が、この活動で見つかった機種名の文字列の一覧をGitHub で公開。ただし「機種名だけでは、感染しているとは言い切れない」と注意書きがある |
大事な点が2つあります。
- メーカー名が箱に書かれていない端末も多い:Videostrong 社は、自社の名前の製品のほかに、ほかのブランド向けの製品も作っていると報じられています(The Hacker News)。箱やアプリの画面にこの社名が無くても、関係がないとは言えません
- 「Google の認定がある端末」も含まれていた:Plume は、感染した端末には、認定のない AOSP 版の端末と Google の認定を受けた端末の両方があったと報告しています。Synthient が調べた端末も Google TV でした。Google 自身も、メーカーが審査のすきまを突いて、最初の起動のあとで不正なコードを読み込む仕組みにしていた、と説明しています。認定は大事な目安ですが、今回は認定があるだけでは安心できなかったことになります
今はどうなっているか
指令を出すサーバーは止められました。ただし、TrendAI は「サーバーが無くなって運用者は端末から切り離されたが、埋め込まれたものは各端末に残っている」「持ち主が自分で取り除くことはできない」と書いています(TrendAI)。止まったから安全になった、という話ではありません。
これまでの同じような件とのつながり
出荷時から、または初期設定の途中で不正なプログラムが入る Android 端末の問題は、今回が初めてではありません。
| 時期 | 名前 | 内容 | 出典 |
|---|---|---|---|
| 2024年まで | BADBOX | 出荷前にバックドアが入った Android 端末のボットネット。2024年に妨害された | FBI の注意喚起 |
| 2025年 | BADBOX 2.0 | TV ストリーミング端末、プロジェクター、車載機器、デジタルフォトフレームなど。FBI が2025年6月に注意喚起。Google は2025年7月に、運営者に対する法的措置を発表 | FBI、Google、HUMAN Security |
| 2026年1月 | Kimwolf | 非公式の TV ボックスなどに広がったボットネット。調べた端末のほとんどが、ADB(後で説明するデバッグ用の入口)が出荷時から開いたままだったと報告されている | Krebs on Security |
| 2026年11月 | XCPE(今回) | メーカー自身がファームウェアに入れていた、と Google が評価。認定のある端末も含まれる |
Google の報告は、今回のバックドア経由で配られていたプログラムの一部が、以前から BADBOX 関連の活動で確認されていたものだった、とも書いています。別々の事件というより、安い端末を「回線の出口」や広告の不正に使って稼ぐ仕組みが、形を変えて続いていると見るのがよさそうです。
サイネージで使っていると、何が困るのか
サイネージの端末は、店や会社の回線につながったまま、一日中動いています。発表・報告に書かれている機能から考えると、次のことが困ります。
- 店の回線が、他人の通信の「出口」になる:レジデンシャルプロキシにされると、見知らぬ人の通信が、店の IP アドレスから出ていきます。警察庁の発表にある不正送金事件のように、犯罪の通信の出どころが自分の店の回線になることがあります
- 回線の容量を使われる:帯域を売るプログラムや広告の不正は、回線を使い続けます(どのくらい使うかは、編集部では未検証)
- 同じネットワークの機器が見える:報道によると、このバックドアには、端末がつながっているネットワークの中を調べる機能があります(The Hacker News)。サイネージの端末を、POS レジや事務用のパソコンと同じネットワークに置いていると、そこが入口になります
- 画面と操作を見られる・動かされる:運用者は、画面を撮る、キー操作を送る、端末にコマンドを打つ、アプリを黙って入れることができたと報告されています。サイネージの表示が実際に書き換えられた例は、編集部が読んだ発表・報告の中にはありませんでした。ただ、できる状態だったことになります
- CMS のアカウント:端末の中のアカウント情報やログが持ち出されていた、という報告があります。サイネージの CMS のアプリの情報が取られたかどうかは、発表には書かれていません(未検証)
見分け方①:まず、買う前・買ったときの様子を思い出す
FBI は、BADBOX 2.0 の注意喚起で、あやしい端末の特徴を挙げています(FBI)。当てはまるものが多いほど、注意が必要です。
- 聞いたことのないメーカー・ブランドの IoT 機器
- 「ロック解除済み」「無料で映画やテレビが見られる」とうたう、汎用のストリーミング端末
- Play プロテクトの認定がない Android 端末
- 設定の途中で、Google Play プロテクトをオフにするよう求められる
- アプリを、公式ではないストアから入れるようになっている
- 説明のつかない、あやしい通信がある
FBI は「1つ当てはまるだけで、不正があるとは決まらない」とも書いています。TrendAI も、消費者への助言として「ブランドの分からない端末・認定のない Android TV ボックス」と「回線を共有するとお金がもらえるアプリ」を避けるよう書いています。
見分け方②:Play プロテクトの認定を確かめる
「Play プロテクトの認定」は、その端末が Google の互換性のテストに通り、Google のアプリが正式なライセンスで入っていることを示すものです。
端末の画面で確かめる(Google Play ヘルプの手順)
- Google Play ストアのアプリを開く
- プロフィールのアイコンを選ぶ
- 「設定」→「デバイス情報」(機種によっては「概要」「About」)を開く
- 「Play プロテクトの認定」の欄を見る。認定されていないと「このデバイスは認定されていません」と出る
テレビ用の端末では、メニューの名前や場所が少し違います(編集部は、テレビ用の端末でのこの手順を実機で確かめていません。未検証)。そもそも Google Play ストアが入っていない、または別のアプリストアしかない端末は、認定されていないと考えてください。
一覧で確かめる
- Google の「サポートされているデバイス」の一覧に、メーカー名と機種名があるか(一覧にない端末は、認定済みではないと Google は説明しています)
- Android TV・Google TV の認定パートナーの一覧(Android 公式サイト)に、メーカーがあるか
Play プロテクトの検証がオフになっていないかも見る
今回のバックドアは、Play プロテクトの検証を止めていました。Android 11 以降の Android TV では、Google Play ストア →「Play プロテクト」→ 設定で「Play プロテクトによるアプリのスキャン」がオンかを確かめられます(Android TV ヘルプ)。自分でオフにした覚えがないのにオフになっていたら、あやしい印です。
ここで分かること・分からないこと
- 認定がない → 使わないことをおすすめします(下の「不安なときの対処」へ)
- 認定がある → ひとまずの目安にはなる。ただし上に書いたとおり、今回は認定のある端末にも入っていました。名指しされたブランド・機種に当たる場合は、認定があっても次の確認に進んでください
見分け方③:ルーターで通信を見る
FBI は、対策の1つ目に「家や店のネットワークの通信を見張ること」を挙げています。パソコンが要らないので、ADB より先に試せます。
- ルーターの管理画面で、つながっている機器の一覧を見る:サイネージの端末がどれか(IP アドレスと MAC アドレス)を確かめる
- 通信量を見る:機器ごとの通信量を出せるルーターなら、サイネージの端末の「送信(アップロード)」が多くないかを見る。サイネージの端末は、ふつうは素材を受け取る側です。何もしていない夜中にも送信が続くなら、あやしい印です(どのくらいが「多い」かの目安は、一次情報には書かれていません)
- 通信先を見る:DNS の記録を見られるルーターや、通信先を記録できる機器があれば、報告に載っている通信先と比べる。Google の報告は、指令サーバーのドメインとして
anyevonline[.]com、szbboys[.]comなどを挙げています([.]は、間違って開かないための書き方です。ブラウザで開かないでください)。全部の一覧は、Google の報告と Synthient の一覧にあります - Google の報告によると、指令のやりとりには MQTT という仕組みが、ふつうは使わない番号のポート(3885〜3887)で使われていました
指令サーバーはすでに止められているので、今は通信が見えないこともあります。通信が見えないことは、端末がきれいな証拠にはなりません。
あわせて、サイネージの端末を、レジや事務用のパソコンとは別のネットワーク(ゲスト用の Wi-Fi など)に分けることをおすすめします。Synthient は組織向けに、こうした機器を大事な機器とは別のネットワークに分けるよう助言しています。ゲスト用のネットワークを作れるルーターは、Amazon でも探せます。
Amazonのアソシエイトとして、サイネージファンは適格販売により収入を得ています。
見分け方④:ADB で端末の中を見る
ここからは、パソコンを使う確認です。少し手間がかかるので、①〜③で不安が残ったとき、または台数が多くて入れ替えの判断材料がほしいときに進んでください。
**ADB(Android Debug Bridge)**は、パソコンから Android 端末にコマンドを送る、開発者向けの道具です(Android 公式ドキュメント)。入っているアプリの一覧や、端末の情報を見られます。
はじめに知っておくこと
- ADB は、端末を外から操作できる強い入口です。確認が終わったら、必ずオフに戻します
- あやしい端末を調べるときは、店のネットワークから外して行います(下の USB での接続か、ほかの機器がつながっていないネットワークで)
- この確認で分かるのは「報告に載っている印が見つかるかどうか」です。見つからなくても、安全とは言い切れません。逆に、ふつうの端末にも見慣れない名前のアプリはたくさん入っています
- 編集部は、この手順を感染した実機で試していません(未検証)
準備:パソコンに ADB を入れる
Google が配っている「SDK Platform-Tools」をダウンロードして展開します(Windows・Mac・Linux 用があります)。展開したフォルダでターミナル(Windows なら PowerShell)を開くと、adb コマンドが使えます。
先に試す:ADB が「最初から」開いていないか
端末の設定をさわる前に、これを試します。Kimwolf の件では、調べた非公式の TV ボックスのほとんどが、出荷時から ADB が有効で、認証なしの接続を受け付けていたと報告されています(Krebs on Security)。今回の件でも Plume が、ネットワーク経由の ADB(ポート 5555)を裏でこっそり有効にするスクリプトがあったと報告しています。
- ルーターの管理画面か、端末の「設定」→「ネットワーク」で、端末の IP アドレスを調べる(例:
192.168.1.50) - 同じネットワークにつないだパソコンで、次を実行する
adb connect 192.168.1.50:5555
failed to connect、Connection refusedなどと出てつながらない → ふつうの状態ですconnected to 192.168.1.50:5555と出て、端末の画面に許可のダイアログも出ないままadb shellが使える → 自分で有効にしていないのに ADB が開いています。同じネットワークのだれでも、この端末を操作できる状態です。使うのをやめて、ネットワークから外してください
Android 4.2.2 以降のふつうの端末では、はじめてつなぐパソコンに対して、端末の画面に「このパソコンからのデバッグを許可しますか」というダイアログ(RSA キーの確認)が出ます(Android 公式ドキュメント)。
ADB を有効にする(確認のあいだだけ)
- 端末の「設定」→「デバイス情報(端末情報)」を開き、「ビルド番号」を7回続けて選ぶ。「開発者向けオプション」が出る(場所は機種によって違います。Android 公式ドキュメント)
- 「開発者向けオプション」で「USB デバッグ」をオンにする。Wi-Fi 経由でつなぐなら、機種によって「ネットワーク デバッグ」「ワイヤレス デバッグ」などの名前の項目をオンにする
つなぎ方A:Wi-Fi(LAN)経由
ケーブルが要らない方法です。あやしい端末を調べるときは、ほかの機器がつながっていないネットワーク(インターネットにつないでいない予備のルーターなど)で行います。
adb connect 192.168.1.50:5555
adb devices
adb devices の一覧に、192.168.1.50:5555 device と出ればつながっています。unauthorized と出たら、端末の画面の許可のダイアログで許可します。
Android 11 以降の「ワイヤレス デバッグ」は、先にペア設定が要ります。端末の画面に出る IP アドレス・ポート・ペア設定コードを使い、adb pair <IPアドレス>:<ポート> を実行してから接続します(手順は Android 公式ドキュメント)。
つなぎ方B:USB 経由(USB A-A ケーブル)
端末をどのネットワークにもつながずに調べられるので、あやしい端末にはこちらが向いています。
スマホなら、USB-C のケーブルでパソコンとつなぐだけです。ところが、安い TV ボックスには、四角い USB-A の口(USB メモリを挿す側の形)しか付いていないものが多くあります。パソコン側も USB-A なら、両端が USB-A のオスになっているケーブル(USB A-A ケーブル、「オス-オス」とも呼びます)が必要です。パソコンに USB-C の口しかないなら、USB-C と USB-A オスのケーブルを使います。
Amazonのアソシエイトとして、サイネージファンは適格販売により収入を得ています。
USB A-A ケーブルを使うときの注意です。
- どの口でもつながるわけではない:パソコンとつなげるのは、端末側が「つながれる側」としても動く口(OTG 対応の口)だけです。どの口がそうかは機種によって違います。たとえば開発ボードの Radxa ROCK 4D は、公式の説明で「上側の USB 3.0 の口」と決まっています(Radxa)。Amazon も、初代・第2世代の Fire TV(箱型)では USB でつなげるが「A-to-A の USB ケーブルが要る」と書いています(Amazon 開発者向けドキュメント)。口が複数あるなら1つずつ試し、対応する口が1つもない機種もあります。そのときは Wi-Fi 経由でつなぎます
- パソコンどうし、充電器どうしをつながない:USB-A の口は、もともと「電気を出す側」の形です。両端が A オスのケーブルは、電気を出す側どうしをつなげてしまうので、ふつうの USB 機器の接続では使いません。パソコンとパソコン、パソコンと充電器・モバイルバッテリーなどをつなぐと、故障のおそれがあります。この確認が終わったら、ほかの用途に使い回さず、分かるようにしまっておきます
- データ用のケーブルを選ぶ:充電だけのケーブルでは ADB は使えません
- 編集部は、USB A-A ケーブルでの TV ボックスへの接続を実機で試していません(未検証)
つないだら、次を実行します。
adb devices
一覧に端末が出て、右に device と出ればつながっています。何も出ないときは、別の口、別のケーブルを試します。
入っているアプリの一覧を見る
adb shell pm list packages
端末に入っているすべてのアプリ(パッケージ)の名前が出ます。数が多いので、ファイルに保存して検索すると楽です。
adb shell pm list packages -f > packages.txt
-f を付けると、アプリのファイルがある場所も出ます。-s はシステムのアプリだけ、-3 はあとから入れたアプリだけを出します(Android 公式ドキュメント)。
保存した packages.txt を開いて、報告に載っている名前を検索します。
| パッケージ名 | 報告での説明 | 出典 |
|---|---|---|
x.cpe、com.oemservice |
バックドアの本体 | Google、Synthient |
com.abc.nexus |
ほかのプログラムを読み込むローダー | Google、Synthient、TrendAI |
com.vs.grass |
回線を貸すプログラムの1つ | Google、TrendAI |
com.android.sso.auth.handler、com.android.auth.handler、com.android.system.ntp、com.android.vs.ntp、com.android.providers.cloud.sync、com.android.system.ultimate、com.appdns.change.rc、com.dnschecker.rc、com.ycngmn.notubetv.service |
2026年8月以降に見つかった、システムのアプリのふりをする新しい入口。名前は違っても中身は同じ、と Plume は書いている | Google、Plume |
- 1つでも見つかったら、下の「見つかったとき・不安なときの対処」へ進んでください
com.android.で始まる名前は、Android のふつうのアプリにもたくさんあります。上の表と1文字も違わず同じかどうかで判断してください- この表は2026年11月9日時点の報告によるものです。名前は変えられます(TrendAI は、最新の更新でローダーの名前が変えられたと書いています)。見つからないことは、安全の証明にはなりません
端末の情報を見る(getprop)
getprop は、端末の設定値(システムプロパティ)を読むコマンドです(Android Open Source Project の説明)。
adb shell getprop ro.product.manufacturer
adb shell getprop ro.product.brand
adb shell getprop ro.product.model
adb shell getprop ro.build.fingerprint
- 出てきたメーカー名・ブランド名・機種名を、箱や商品ページの表示と比べます。Synthient が調べた MECOOL の端末は、メーカーが
SkyworthDigital、機種名がUHD Google TV STBと、ブランド名とは違う名前で出ていました。箱の名前と中の名前が違うこと自体は、OEM の製品ではよくあります - 機種名を、Synthient の機種名の一覧と比べます。くり返しになりますが、Synthient は「機種名だけでは感染しているとは言い切れない」と書いています。一覧には
S905、H616のように、多くのメーカーが使うチップの型番と同じ名前も入っています。一覧にあれば、ほかの確認とあわせて判断するという使い方になります
次の3つは、Google と Plume が、新しい入口のプログラムが書き換えると報告している値です。
adb shell getprop persist.networkstack.uninstall
adb shell getprop persist.networkstack.skip_system_install
adb shell getprop persist.networkstack.install_time
Plume によると、インストールの確認を出さないようにしたり、あとから入れたプログラムを「工場で最初から入っていた」ように見せるために、にせの日時を書き込んだりします。値が入っていたら、報告の手口と一致します(ふつうの端末でこの3つがどう返るかは、編集部では未検証です)。
終わったら、ADB をオフに戻す
「開発者向けオプション」で「USB デバッグ」と、ネットワーク経由のデバッグをオフにします。開発者向けオプションそのものもオフにしておきます。
見分け方⑤:実際の検査で使われた手順(棚卸し → 観測 → 結びつけ → 対処)
ここまでは「報告に載っている印を探す」やり方でした。ここでは、印が分かっていない端末を、いちから調べるときの進め方を紹介します。編集部の関係者が、現場向けのサイネージで使う海外製の Android STB(Amlogic 系の SoC、Android 14)を、ネットにつながない運用を前提に検査したときの手順です。4段で、かかる時間は半日ほどです。
検査したきっかけは、おかしな動きが出たことではありません。
- 買ったプレーヤーが、かなり古い機種だった
- 説明されていた Android のバージョンと、実物のバージョンが食い違っていた(9 と聞いていたのに、実際は 14 だった)
- ちょうどバックドアの話題が広がっていたので、「このサイネージ用のプレーヤーは大丈夫か」を確かめることにした
動きに異常がなくても、「仕様の説明と実物が食い違う」「機種が古い」といった点は、検査するきっかけになります。
この節の読み方
- 紹介するのは手順だけです。この検査で何が分かったかは、この記事には書いていません(結果を書ける段階になったら、追記します)。「見つかった」とも「問題なかった」とも読まないでください
- 製品名・型番・メーカーは書きません。特定の製品・メーカーを非難する意図はありません
- この検査は、自分が管理している機器とネットワークでだけ行ってください。他人の機器や、他人のネットワークの通信を調べてはいけません
- コマンドの書式は Android の公式ドキュメントで確かめました。ただし、編集部が自分で実行したものではありません(未検証)。公式ドキュメントで書式を確かめられなかったものは、その場所に書いています
1. 棚卸し:何が入っているかを書き出す
ビルドの種類を見る
「設定」→「デバイス情報」のビルド番号に、test-keys や userdebug という文字が残っていないかを見ます。ADB でも見られます。
adb shell getprop ro.build.fingerprint
test-keys:Android のソースに入っている、だれでも知っているテスト用の鍵で署名されたビルドです。鍵が公開されているので、だれでも「正しい署名」の更新やアプリを作れてしまいます。製品として出すビルドは、メーカーだけが持つ鍵(release-keys)で署名します(Android Open Source Project:リリース用のビルドの署名)userdebug:開発・テスト用のビルドで、root の権限を使えます(Android Open Source Project)
どちらも、量産品に残っていてはいけない印です。これだけでバックドアがあるとは言えませんが、作りの管理が甘いことは分かります。
アプリの一覧を取る
adb shell pm list packages -s > system.txt
adb shell pm list packages -3 > third-party.txt
adb shell pm list packages -f > all-with-path.txt
-s はシステムのアプリ、-3 はあとから入れたアプリ、-f はファイルの場所つきです。気になるアプリは、くわしい情報を出します。
adb shell dumpsys package <パッケージ名>
持っている権限、入れられた日時、ファイルの場所などが出ます(dumpsys の公式ドキュメント)。
注意して見るアプリの特徴
- システムの領域(
/system/、/vendor/、/product/など)に入っている - ホーム画面やアプリの一覧にアイコンが出ない
- 設定の画面からアンインストールも無効化もできない
- 名前から役目が分からない、または Android の標準のアプリに似せた名前
この特徴だけなら、まともなシステムのアプリにも当てはまります。ここでは「あとで通信と結びつける候補」を書き出すだけです。
2. 観測:どこへ通信しているかを見る
端末をネットワークにつなぎ、通信先を記録します。ほかの機器の通信と混ざらないようにするのがこつです。
- STB だけをつないだ Wi-Fi(予備のルーターや、ゲスト用のネットワーク)を用意する。または、上流のルーターやスイッチのミラーポート(通信の写しを別の口に出す機能)を使う
- 記録する道具:ルーターのログ、
tcpdump、Wireshark、Pi-hole などの DNS のログ - 見る場面:電源を入れた直後、サイネージのアプリを動かしているとき、何もしていない夜中
- 書き出すもの:通信先のドメイン・IP アドレス、ポート、頻度、量、暗号化されているか
サイネージの CMS、時刻合わせ、Google のサービスなど、説明のつく通信を消していき、残ったものが次の段の対象です。
DNS のログを取るには、小さな Raspberry Pi に Pi-hole を入れる方法が手軽です。
Amazonのアソシエイトとして、サイネージファンは適格販売により収入を得ています。
3. 結びつけ:どのアプリが通信しているかを突き止める
Android では、アプリごとに別々の番号(UID)が割り当てられます。通信している UID が分かれば、アプリが分かります。
- 端末の中で、通信中の接続と UID を見る。
adb shellに入り、netstatやssを使います(Linux の一般的なコマンドです。端末に入っているか、UID まで出せるかは機種によります。root の権限が要る場合もあります) - UID からパッケージ名を引く。
adb shell pm list packages -Uで、パッケージ名と UID の一覧が出ます(-Uは端末のpmのヘルプに出るオプションで、公式ドキュメントの表には載っていません。使えないときは、候補のアプリをdumpsys package <パッケージ名>で1つずつ見ます) - アプリのファイル(apk)を取り出す
adb shell pm path <パッケージ名>
adb pull <上で出たapkのパス> suspect.apk
- apktool や jadx といった解析の道具で、中身を読む
中身を読むときに見る点の例です。
- 「OTA 更新」「アップデート」を名乗りながら、外から好きな apk を取ってきて、黙ってインストールできる作りになっていないか
- 取ってくる先(サーバー)を、あとから外から変えられるか
- 取ってきたファイルの署名や中身を確かめているか
「バックドア」と判断する根拠の例(1つではなく、重なりで見ます)
- 利用者の同意がない
- 説明書・仕様書・設定の画面のどこにも説明がない
- 好きなコードを取ってきて動かせる
- 利用者の側で無効にできない
正当な遠隔管理や更新の仕組みも、技術的には似た動きをします。分かれ目は、説明と同意があるか、止められるか、取ってくるものが確かめられているか、です。
4. 評価と対処:影響の範囲を決めて、止める
- アプリを止める
adb shell pm disable-user --user 0 <パッケージ名>
adb shell pm uninstall -k --user 0 <パッケージ名>
1つ目は無効化、2つ目は「今の利用者(ユーザー 0)からだけ外す」操作です(-k はデータを残すオプション)。システムのアプリは、これでは端末から消えません。初期化すると元に戻りますし、システムに必要なアプリを止めると起動しなくなることがあります。1つずつ試し、何を止めたかを記録します
- ルーターで止める:残った通信先を、ルーターやファイアウォールで遮断する
- ネットにつながない構成に固定する:Wi-Fi の設定を消し、LAN ケーブルを挿さない。素材の入れ替えは USB メモリなどで行う
- 製造元・販売元に直してもらう:見つけた事実(どのアプリが、いつ、どこへ通信したか)をそえて、説明と修正を求める
- もう一度、観測する:対処のあとに 2 の観測をくり返し、通信がなくなったことを確かめる。ここまでやって、対処が終わりです
この検査から得られた教訓
- 「ネットにつながない運用だから安全」は成り立ちません。設定や更新、時刻合わせのために一度でもつなげば、その瞬間に通信します。「つないだ瞬間に通信する」前提で、つなぐ前に検査します
- 買うときに、ファームウェアの出どころと更新の経路を確かめます。だれが作ったファームウェアか、更新はどこから・どの鍵で署名されて届くか、止められるか。答えられない販売元からは、業務用には買わないのが安全です
見つかったとき・不安なときの対処
1. まず、ネットワークから外す
LAN ケーブルを抜き、Wi-Fi の設定を消し、電源を切ります。Synthient は、組織に対して「見つけたら、つなぐのをやめて処分する」こと、消費者に対しては箱を使うのをやめることを勧めています。
2. 「初期化すれば直る」とは考えない
- Google:バックドアの本体は、アンインストールしても再起動のときに入れ直される
- TrendAI:メーカーの鍵で署名されたシステムのアプリとして動いているので、持ち主は自分で取り除けない。片づけるには「メーカーの対応、プラットフォーム側の保護、または端末の交換」が要る
- Plume:あとから別のバックドアが入れられているおそれがあるので、該当する端末は完全な初期化(ファクトリーリセット)を強く勧める
Plume の勧める初期化は、あとから入れられたものを減らすための手当てです。出荷時のファームウェアに入っている本体まで消えるとは、どの報告も書いていません。編集部では、サイネージには使い続けず、端末を替えることをおすすめします。
3. 同じ回線のほかの機器と、アカウントを見直す
- 同じネットワークにあったパソコン・レジ・NAS・カメラなどに、身に覚えのない動きがないかを確かめる
- その端末で使っていた Google アカウントや、サイネージの CMS のパスワードを変える(端末からアカウント情報が持ち出されていた、という報告があるため)
- 被害が疑われるとき(身に覚えのない不正アクセスの問い合わせが来た、など)は、最寄りの警察署か、都道府県警察のサイバー犯罪相談窓口に相談する
4. 買った店・メーカーに伝える
返品・返金に応じるかどうかは、店とメーカーによります(今回の件で、どこがどう対応しているかは、編集部では確かめていません)。
安全な端末の選び方
今回の件で分かったのは、「安い」「認定と書いてある」だけでは選べない、ということです。編集部は、次の考え方をおすすめします。
- メーカーがはっきりしていて、更新が続いている端末を選ぶ:だれが作り、だれが更新を配っているかが分かるもの
- 端末の中で動くものを減らす:サイネージ専用にして、関係のないアプリを入れない
- ネットワークを分ける:どの端末でも、レジや事務用のパソコンとは別のネットワークに置く
- 「無料で何でも見られる」箱を、業務に使わない
サイネージで使いやすく、作っている会社がはっきりしている端末は、次のとおりです。
| 端末 | 作っている会社 | サイネージでの使い方 |
|---|---|---|
| Fire TV Stick 4K | Amazon | いちばん手軽。対応する CMS が多い(Fire TV Stickでサイネージを始める方法) |
| Google TV Streamer | Google 自身の Google TV 端末。Google Play からサイネージアプリを入れる(Androidのサイネージアプリ) | |
| Apple TV 4K | Apple | 安定して長く使いやすい。Kitcast などが対応(Apple TVでサイネージ) |
| Raspberry Pi 5 | Raspberry Pi | CMS が配る専用の OS を入れて使う。Yodeck などが対応(Raspberry Piでサイネージ) |
Amazonのアソシエイトとして、サイネージファンは適格販売により収入を得ています。
※ Fire TV Stick 4K Select(Vega OS の機種)では、サイネージのアプリを入れられないか、制限つきでしか動きません。くわしくはFire TV Stickでサイネージを始める方法をご覧ください。
これらの端末が、今回の発表・報告で名指しされていないことは確かめました(2026年11月9日時点)。ただし、どの端末にも「絶対に安全」はありません。上の考え方(専用にする、ネットワークを分ける、更新を当てる)は、どれを選んでも同じです。
ほかのメーカーの Android TV ボックスを選ぶときは、少なくとも、Google の「サポートされているデバイス」の一覧と認定パートナーの一覧にあること、今回の報告で名指しされたメーカー・ブランドでないことを確かめてください。
CMS は、端末を選ばないものにしておく
端末を入れ替えるとき、CMS が新しい端末に対応していれば、中身(プレイリストやスケジュール)はそのまま使えます。当サイトのおすすめは Yodeck と Kitcast です。
- Yodeck:Fire TV、Android、Raspberry Pi、Windows など対応端末が広く、1画面は無料。Raspberry Pi を使った専用プレーヤーもあります
- Kitcast:Apple TV に対応。管理画面は日本語表示あり(一部英語・不自然な訳が残る)
どちらも、Claude などの AI から話しかけて中身を更新できます(KitcastとYodeckのMCP比較)。
まとめ
- 2026年11月、Google は、出荷時からバックドア(XCPE)が入った Android TV ボックスなど130万台超のボットネットを止めたと発表した。デジタルサイネージの端末も含まれ、日本の警察庁も協力している
- Google は、メーカーの Videostrong Technology 社が意図的に入れていたと評価している。調査会社は MECOOL ブランドの端末を挙げている。Google の認定がある端末にも入っていた
- サーバーは止まったが、端末の中身は残っている。持ち主が自分で取り除くことはできない、と報告されている
- 見分けるには、①買ったときの様子 → ② Play プロテクトの認定 → ③ルーターでの通信 → ④ ADB(USB-A の口しかない箱は USB A-A ケーブル)の順に確かめる。印が見つからなくても、安全の証明にはならない
- 印が分かっていない端末は、⑤の「棚卸し → 観測 → 結びつけ → 対処」で調べる。動きに異常がなくても、説明と実物の食い違いは検査のきっかけになる。「ネットにつながないから安全」は成り立たない
- あやしい端末は、ネットワークから外して替える。サイネージの端末は、作っている会社がはっきりしたものを選び、レジや事務用の機器とネットワークを分ける
出典(2026年11月9日に確認)
- Google Threat Intelligence Group「XCPE ボットネットを完全封鎖:Google による脅威への対抗と詳細解析」(英語版)
- 警察庁「Google社と連携した犯罪インフラのテイクダウンについて」(2026年11月4日)
- Synthient「The Internals of a Badbox Operation」、機種名・通信先などの一覧(GitHub)
- Plume Security Labs「XCPE ボットネットの白書(PDF)」
- TrendAI「TrendAI Research Helps Disrupt Android TV Botnet of More Than 1.3 Million Pre-Infected Devices」
- 報道:Krebs on Security、The Hacker News、Help Net Security、Impress Watch
- FBI「Home Internet Connected Devices Facilitate Criminal Activity」(2025年6月5日、BADBOX 2.0)
- Google「Google takes legal action against Badbox 2.0」、HUMAN Security「BADBOX 2.0」
- Krebs on Security「The Kimwolf Botnet is Stalking Your Local Network」(2026年1月)
- Google Play ヘルプ「Play プロテクト認定ステータスを確認、修正する」、Android TV ヘルプ「Google Play プロテクトを使用して有害なアプリからテレビを保護する」
- Android 公式ドキュメント「Android Debug Bridge(adb)」「デバイスの開発者向けオプションを設定する」「SDK Platform-Tools」「dumpsys」、Android Open Source Project「リリース用のビルドの署名」
