あなたの Android 端末に、出荷時点でバックドアが仕込まれている可能性がある。 セキュリティ企業 Human Security の調査により、中国製 Android 端末に「Keenadu」と呼ばれるバックドアがプリインストールされている実態が明らかになった。日本は被害報告の上位国に入っており、個人ユーザーだけでなく企業の端末管理にも深刻な影響を及ぼす。
本記事では、Keenadu の概要から感染機種一覧、自分の端末での確認方法、企業として取るべき対策までを網羅的に解説する。
Keenadu（キーナドゥ）とは何か
Keenadu は、Android 端末のファームウェアに組み込まれた バックドア型マルウェア だ。通常のマルウェアとは異なり、ユーザーが不正アプリをインストールしたわけではない。工場出荷時にすでにシステムレベルで埋め込まれている ため、通常のウイルススキャンでは検出が極めて困難という特性を持つ。
Keenadu の主な挙動
| 挙動 | 詳細 |
|---|---|
| 広告詐欺 | バックグラウンドで非表示の広告を大量にロードし、不正に広告収益を生成する |
| プロキシ悪用 | 感染端末をプロキシサーバーとして利用し、第三者の通信を中継する |
| アカウント不正作成 | Gmail、WhatsApp 等のアカウントを自動作成し、スパム配信やフィッシングに悪用する |
| データ窃取 | 端末の識別情報、位置情報、連絡先データなどを外部サーバーへ送信する |
| リモート制御 | C2（Command & Control）サーバーからの指令で、追加のマルウェアをダウンロード・実行する |
特に危険なのは プロキシ悪用 だ。企業が気付かないうちに、社内ネットワークに接続された感染端末が外部攻撃の踏み台として使われるリスクがある。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
感染が確認されている機種一覧
Human Security の調査報告および後続の分析により、以下のメーカー・機種で Keenadu バックドアの混入が確認されている。
| メーカー | 確認された機種例 | 備考 |
|---|---|---|
| ALLDOCUBE | iPlay 50 Mini Pro など | 日本の Amazon でも販売されている格安タブレット |
| DOOGEE | S59 Pro、T20 など | 耐衝撃性をうたう低価格スマートフォンシリーズ |
| Blackview | BV6600、Tab 8 など | アウトドア向けを謳う中華ブランド |
| UMIDIGI | A13 Pro、G3 Tab など | コスパ重視の SIM フリー端末 |
| Oukitel | WP28、OT5 など | 大容量バッテリー搭載の格安端末 |
| OSCAL | Pad 13、Tiger 12 など | Blackview のサブブランド |
| Lava | 一部モデル | インド市場向け端末 |
| その他 OEM | ノーブランド TV Box 各種 | T95、MXQ Pro 4K、X96 など Android TV Box |
注意点： 上記は公開された調査報告に基づく一覧であり、すべての感染端末を網羅しているわけではない。同一メーカーでも製造ロットやファームウェアバージョンによって感染状況が異なるケースがある。
日本での流通状況
これらの端末は Amazon.co.jp、楽天市場、AliExpress などの EC サイトを通じて日本国内に広く流通している。特に「1万円台のタブレット」「格安 SIM フリースマホ」として購入されるケースが多く、個人利用だけでなく 業務用タブレットや受付端末、サイネージ用端末 として企業が導入している事例もある。
自分の端末が Keenadu に感染しているか確認する方法
以下のステップで、手元の Android 端末が Keenadu バックドアの影響を受けているかチェックできる。
ステップ1：端末のメーカーとモデルを確認する
- 設定 → デバイス情報（または「端末情報」）を開く
- 「モデル番号」「メーカー」を確認する
- 上記の感染機種一覧と照合する
該当メーカーの端末を使用している場合は、以下のステップに進む。
ステップ2：不審なシステムアプリを確認する
- 設定 → アプリ → すべてのアプリを表示 を選択
- 右上メニューから「システムアプリを表示」を有効にする
- 以下のパッケージ名に類似するアプリがないか確認する：
com.fw.upgrade.slientcom.android.gms.stable（正規の Google Play 開発者サービスとは異なる偽装パッケージ）com.sysmonitor.service- その他、インストール元が不明でユーザーが認識していないシステムアプリ
ステップ3：異常な通信を確認する
- 設定 → ネットワークとインターネット → データ使用量 を確認
- バックグラウンドで異常に多くのデータを消費しているアプリがないかチェック
- Wi-Fi 接続時にルーターの管理画面から、端末の通信先 IP アドレスを確認する
ステップ4：ADB を使った詳細チェック（上級者向け）
PC に Android Debug Bridge（ADB）環境がある場合は、より詳細な調査が可能だ。
# 端末に接続後、インストール済みパッケージ一覧を取得
adb shell pm list packages -f
# 不審なパッケージの権限を確認
adb shell dumpsys package <パッケージ名> | grep permission
# ネットワーク接続状況をリアルタイムで確認
adb shell netstat -tlnp
出力結果に覚えのないパッケージや、中国国内の IP アドレス（例：47.x.x.x、39.x.x.x）への定常的な通信が確認された場合は、感染の可能性が高い。
「業務端末が該当機種かもしれない」と感じたら
GXO では企業向けに、端末のセキュリティ診断とバックドア検知調査を提供しています。業務用タブレットや社内配布端末のリスクを可視化し、具体的な対策を提案します。
Keenadu の検知方法──技術的な手順
セキュリティ担当者や IT 管理者向けに、より技術的な検知手順を解説する。
方法1：ファームウェアレベルのハッシュ検証
- 端末のシステムパーティションイメージを取得する（root 権限が必要）
/system/app/および/system/priv-app/配下の APK ファイルのハッシュ値（SHA-256）を計算する- メーカー公式のファームウェアイメージ（入手可能な場合）とハッシュ値を比較する
- 不一致がある APK を VirusTotal 等のマルウェアスキャンサービスでチェックする
方法2：ネットワークトラフィック分析
企業ネットワーク内で感染端末を検知するには、以下の方法が有効だ。
- DNS ログの監視：Keenadu が利用する既知の C2 ドメインへの名前解決リクエストを検知する
- プロキシログの分析：短い間隔で繰り返される HTTP/HTTPS リクエスト（ビーコン通信パターン）を検出する
- NetFlow / sFlow 分析：端末ごとの通信量・接続先の異常を可視化する
方法3：EDR / MDM による一括スキャン
企業が MDM（Mobile Device Management）を導入している場合は、以下のアプローチで一括検知が可能だ。
- MDM コンソールから管理下全端末のインストール済みアプリ一覧を取得
- 既知の Keenadu 関連パッケージ名とのマッチングを実施
- 該当端末を特定し、ネットワークから隔離する
企業として取るべき対策
Keenadu のようなサプライチェーン攻撃は、従来の「アプリをインストールしない」「怪しいサイトを開かない」という対策では防げない。企業として組織的に取り組むべき対策を整理する。
対策1：端末調達ポリシーの見直し
- 調達基準の明文化：業務用端末は、セキュリティ検証体制が確立されたメーカー（Samsung、Google Pixel、Sony 等）から調達する
- 格安端末の禁止：コスト最優先で出所不明のノーブランド端末を導入しない
- BYOD ポリシーの厳格化：個人端末の業務利用を許可する場合は、メーカー・モデルのホワイトリストを設ける
対策2：既存端末の緊急点検
- 現在業務で使用中の Android 端末のメーカー・モデルを全数棚卸しする
- 上記の感染機種一覧に該当する端末を即座に特定する
- 該当端末はネットワークから切り離し、代替端末への切り替えを進める
対策3：ネットワーク監視の強化
- Android 端末セグメントの通信をファイアウォールまたは UTM で重点監視する
- 既知の C2 ドメイン・IP アドレスをブラックリストに追加する
- 異常な通信パターン（大量のバックグラウンド通信、未知の海外 IP への接続）のアラートを設定する
対策4：インシデント対応計画の策定
- バックドア感染端末を発見した場合の対応フロー（隔離→証拠保全→報告→復旧）を文書化する
- 個人情報保護委員会等への報告要否の判断基準を事前に整理する
- 社内への注意喚起と従業員教育を速やかに実施する
対策5：端末・資産管理を「仕組み」にする
対策2の全数棚卸しや対策3のネットワーク監視を、Excel と人手で回し続けるのは限界がある。端末・IT資産の管理やMDM連携を業務システム化しておけば、調達ポリシー違反や該当機種の混入を継続的に検知できる。
- 資産管理・端末管理の仕組みを作る：業務システム開発の相談 ／ DX/システム開発の全体像
- いくらで作れるかを先に把握する：60秒でわかる開発費の概算 ／ 種類別のシステム開発費用
- 委託先を見極める：システム開発会社の選び方
端末・資産管理システムの開発相談から、棚卸しの仕組み化を相談できる。
サプライチェーン攻撃の背景──なぜ工場出荷時にバックドアが混入するのか
低価格端末のサプライチェーン構造
格安 Android 端末は、以下のようなサプライチェーンで製造される。
- チップセットメーカー（MediaTek、Allwinner 等）がリファレンスファームウェアを提供
- ODM（Original Design Manufacturer） がリファレンスをベースにカスタムファームウェアを構築
- OEM ブランド が自社ブランド名で製品化・販売
問題は、このチェーンの ステップ2 にある。ODM が利益を最大化するために、ファームウェアにアドウェアやバックドアを意図的に組み込むケースが確認されている。端末の販売価格が極端に安い場合、端末そのものではなく、そこから得られる広告収益やデータが「真の商品」 となっている可能性がある。
「BADBOX」オペレーションとの関連
Keenadu は、Human Security が「BADBOX」と名付けたサイバー犯罪オペレーションの一部とされる。BADBOX は以下の特徴を持つ。
- 数十万台規模の感染端末ネットワークを構築
- 広告詐欺（PEACHPIT と呼ばれるモジュール）による収益化
- 感染端末のプロキシネットワーク化による匿名通信基盤の構築
- グローバルに展開され、日本、米国、ブラジルなどが主要な被害国
このような組織的なサプライチェーン攻撃は、一個人や一企業の対策だけでは根本的に防ぐことが難しい。業界全体でのサプライチェーン検証の仕組みづくりが求められている。
よくある質問（FAQ）
Q. Keenadu はどのくらい危険なのですか？
Keenadu の危険性は非常に高い。通常のマルウェアは不正アプリの削除で対処できるが、Keenadu はシステムパーティションに組み込まれているため、工場出荷状態にリセットしても除去できない。端末が起動している限り、バックグラウンドでデータ窃取やプロキシ通信が継続する。感染が確認された端末は、業務利用を即座に停止すべきだ。
Q. 中華タブレットはすべてバックドアが入っているのですか？
すべての中国製タブレットにバックドアが含まれているわけではない。ただし、極端に低価格な端末（特に1万円未満のタブレットやノーブランドの Android TV Box）はリスクが高い。Lenovo、Xiaomi、OPPO など大手メーカーの正規製品は、自社でセキュリティ検証体制を持っており、Keenadu のような問題は報告されていない。判断基準としては、「メーカーが自社でファームウェアを開発・管理しているか」がポイントとなる。
Q. Android のバックドア対策として、個人でできることは何ですか？
個人レベルでは以下の対策が有効だ。
- 信頼できるメーカーの端末を選ぶ：Google Pixel、Samsung Galaxy、Sony Xperia など、セキュリティアップデートが定期的に提供される端末を選択する
- Google Play プロテクトを有効にする：設定 → セキュリティ → Google Play プロテクトが有効であることを確認する
- 不審な通信を監視する：NetGuard 等のファイアウォールアプリで、アプリごとの通信先を確認する
- 格安端末の業務利用を避ける：特に機密情報を扱う場合は、出所が明確な端末のみを使用する
Q. 感染端末を初期化すれば安全ですか？
いいえ、初期化では解決しない。 Keenadu はシステムパーティション（/system）に組み込まれているため、ユーザーデータの初期化（Factory Reset）では除去できない。安全を確保するには、クリーンなファームウェアへの完全な書き換え（カスタム ROM のフラッシュ）が必要だが、技術的なハードルが高く、すべてのユーザーに推奨できる方法ではない。感染端末は 廃棄または利用停止 が最も確実な対処法だ。
まとめ──Keenadu 対策は「端末選定」から始まる
Keenadu バックドアの問題は、単なるマルウェア感染ではなく サプライチェーン全体のセキュリティリスク だ。対策の核心は以下の3点に集約される。
- 現状把握：社内で使用中の全 Android 端末を棚卸しし、感染リスクのある端末を特定する
- 調達基準の確立：今後の端末調達において、セキュリティ検証済みメーカーのみを許可する
- 監視体制の構築：ネットワーク監視・EDR/MDM による継続的な異常検知を実施する
「安いから」という理由で導入した端末が、情報漏えいの入口になるリスクを経営層も認識すべきだ。
<!-- GXO_QUALITY_REWRITE_20260507_START -->端末セキュリティの現状を可視化しませんか？
GXO では、企業の Android 端末環境を対象としたセキュリティ診断サービスを提供しています。Keenadu をはじめとするサプライチェーン攻撃のリスク評価から、調達ポリシーの策定支援、ネットワーク監視体制の構築まで、ワンストップで対応します。
GXO実務追記: AI開発・生成AI導入で発注前に確認すべきこと
この記事のテーマは、単なるトレンド紹介ではなく、業務選定、データ整備、セキュリティ、PoCから本番化までの条件を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。
まず決めるべき3つの論点
| 論点 | 確認する内容 | 未整理のまま進めた場合のリスク |
|---|---|---|
| 目的 | 売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか | 成果指標が曖昧になり、PoCや開発が終わっても投資判断できない |
| 範囲 | 対象部署、対象業務、対象データ、対象システムをどこまで含めるか | 見積もりが膨らむ、または重要な連携が後から漏れる |
| 体制 | 自社責任者、現場担当、ベンダー、保守運用者をどう置くか | 要件確認が遅れ、納期遅延や品質低下につながる |
費用・期間・体制の目安
| フェーズ | 期間目安 | 主な成果物 | GXOが見るポイント |
|---|---|---|---|
| 事前診断 | 1〜2週間 | 課題整理、現行確認、投資判断メモ | 目的と範囲が商談前に整理されているか |
| 要件定義 / 設計 | 3〜6週間 | 要件一覧、RFP、概算見積、ロードマップ | 見積比較できる粒度になっているか |
| PoC / MVP | 1〜3ヶ月 | 検証環境、効果測定、リスク評価 | 本番化判断に必要な数値が取れるか |
| 本番導入 | 3〜6ヶ月 | 本番環境、運用設計、教育、改善計画 | 導入後の運用責任と改善サイクルがあるか |
発注前チェックリスト
- AIで置き換える業務ではなく、成果が測れる業務を選んだか
- 参照データの所有者、更新頻度、権限、機密区分を整理したか
- PoC成功条件を精度、時間削減、CV改善、問い合わせ削減などで数値化したか
- プロンプトインジェクション、個人情報、ログ保存、モデル選定のルールを決めたか
- RAG/エージェントの回答を人が監査する運用を設計したか
- 本番化後の費用上限、API使用量、障害時フォールバックを決めたか
参考にすべき一次情報・公的情報
- 経済産業省 AI事業者ガイドライン関連情報
- デジタル庁 AI関連情報
- OpenAI Platform Documentation
- Anthropic Claude Documentation
- OWASP Top 10 for LLM Applications
上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。
GXOに相談するタイミング
次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。
- 見積もり依頼前に、要件やRFPの粒度を整えたい
- 既存ベンダーの提案が妥当か第三者視点で確認したい
- 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
- 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
- PoCや診断で終わらせず、本番導入と運用改善まで進めたい
<!-- GXO_QUALITY_REWRITE_20260507_END -->Keenaduバックドアの確認方法と対策｜感染Android機種一覧・検知手順【2026年】を自社条件で診断したい方へ
GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。
※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。