モバイルアプリを開発・検証しているエンジニアや、Androidアプリの権限設計をレビューする立場の方に向けて、Zimperium zLabsが2026年8月に報告したAndroidバンキングマルウェア「ToxicPanda 2.0」の手口を整理しました。フロントエンド開発者にとっては縁遠く見えるかもしれませんが、Accessibility Service（画面の内容を読み取り操作を代行する支援機能API）とADB（Android Debug Bridge、開発時に端末を操作するデバッグツール）の組み合わせが悪用される仕組みは、アプリのUI設計や配布プロセスを見直す材料になります。
まず何が起きるかを整理します。ToxicPanda 2.0は偽のインストール画面を表示し、ユーザーにVPN（仮想プライベートネットワーク）権限とAccessibility Serviceの許可を求めます。VPN権限を得ると端末内でローカルVPNを張り、Google PlayやGoogle Play Servicesへの通信を遮断します。これによってセキュリティアップデートや正規ストアからのスキャンを妨害できてしまいます。
次にAccessibility Serviceを使って設定画面を自動操作します。開発者向けオプションが無効な場合、ビルド番号を7回タップして有効化し、ワイヤレスデバッグ画面を開いてペアリングコードを読み取ります。これはAccessibility Serviceが画面上のテキストや要素を読み取れる仕組みを逆手に取った動きです。読み取ったコードを使い、端末内で待ち受けているADBデーモン（127.0.0.1、つまり自分自身のループバックアドレス）にSPAKE2/TLSでペアリングし、シェル権限を獲得します。
重要なのはルート化や既知の脆弱性（CVE）を突いていない点です。あくまでAndroid 11以降で標準搭載されているワイヤレスデバッグ機能と、ユーザー自身に許可させたAccessibility権限を連鎖させているだけです。シェル権限を得た後は実行時権限の付与やバックグラウンド制限の緩和、常駐化のコマンドを実行し、金融アプリを検知すると偽のログイン画面をオーバーレイ表示してPINやパスワードを盗みます。C2サーバー（攻撃者が指令を送るコマンド&コントロールサーバー）とは暗号化WebSocketで常時接続し、報告によれば167種類のリモートコマンドが実装されています。
なぜこの連鎖が成立するのか
原因を段階的に見ていきます。第一の要因はAccessibility Serviceの設計思想です。視覚や運動に障害のあるユーザーを支援するため、画面の読み取りと操作の代行という強力な権限が標準APIとして用意されています。この権限自体は正当な用途がある一方、悪意あるアプリが取得すると設定画面の自動操作まで可能になります。
第二の要因はワイヤレスデバッグの仕様です。従来のADBはUSB接続が前提でしたが、Android 11からWi-Fi経由でのペアリングが標準機能になりました。開発者にとっては便利な一方、ペアリングコードの表示・入力という手続きすべてが画面上の操作で完結するため、Accessibility Serviceによる自動化の対象になり得ます。
第三の要因は配布経路の巧妙さです。AWS（Amazon Web Services）のストレージバケットを使ってペイロードを配布しており、正規のクラウドサービスに紛れる形でホスティングされています。ドロッパー（本体を後から取得・展開する初期段階のアプリ)がインストール画面を偽装するため、ユーザーは通常のアプリインストールと区別しにくい構造です。
自分のプロジェクトが該当するか確認する
フロントエンド・モバイル開発の観点で確認すべき点は大きく3つあります。
- 配布アプリがAccessibility Serviceを要求していないか:
AndroidManifest.xmlでandroid.permission.BIND_ACCESSIBILITY_SERVICEを宣言しているか確認します。正当な用途がない場合は権限自体を削除できないか検討します - 端末側でワイヤレスデバッグが有効になっていないか: 実機で「設定」→「開発者向けオプション」→「ワイヤレスデバッグ」の状態を確認します。検証端末を常時有効にしたままにしていないか棚卸しします
- 社内配布・検証環境でのAPK配布方法: 社内テスト用アプリをS3やGCSなど一般的なクラウドストレージのURLで直接配布していないか確認します。署名検証やMDM（Mobile Device Management）経由の配布に切り替えられるか見直します
Androidアプリ側でAccessibility Serviceを実装している場合は、AccessibilityServiceInfoのflagsやcapabilitiesを最小限に絞り、canRetrieveWindowContentのような広範な読み取り権限を必要な範囲だけに制限することが基本です。Google Playのポリシーコンソールでも、Accessibility APIの使用目的を宣言する項目があるため、審査時にどの機能が該当するか再確認しておくと安心です。
対策の手順
開発・配布側でできる具体的な対応は以下の通りです。
1. アプリ内のAccessibility権限要求を棚卸し: 本当に必要な機能（読み上げ支援など）以外でAccessibility Serviceを要求していないかコードレビューします
2. 社内・検証端末のワイヤレスデバッグを常時オフに: 検証端末はUSBデバッグのみ許可し、使い終わったらワイヤレスデバッグをオフに戻す運用を徹底します
3. 配布URLの制限: AWSやGCSでAPKを配布している場合、署名付きURLの有効期限を短くし、バケットの公開範囲をprivateに設定します
4. MTD/MDMによる異常検知の導入: 組織で配布する端末にはMTD（Mobile Threat Defense）やMDMを導入し、未知アプリによるVPN・Accessibility・Device Administrator権限の取得をアラート対象にします
5. エンドユーザー向けの注意喚起: 自社アプリのインストール手順を案内する際、「インストール中にVPN許可やAccessibility許可を求める画面が出たら中断する」という一文を明記します
個人の端末でも、Google Play ProtectをONにしていれば公式ストア外のAPKインストール時に警告が出ます。設定アプリの「セキュリティ」→「Google Play プロテクト」で有効化状況を確認しておくと、被害の入口を1つ減らせます。
まとめ
ToxicPanda 2.0は既知のOS機能を組み合わせただけの攻撃であり、パッチで塞げる脆弱性ではありません。だからこそアプリの権限設計と配布経路の見直しが直接的な対策になります。
手元でまず着手できるのは、自社アプリのAndroidManifest.xmlでAccessibility関連の宣言を洗い出すことと、検証端末のワイヤレスデバッグ設定を確認することです。あわせてAPK配布に使っているクラウドストレージの公開範囲も点検しておくと、同種の手口への耐性を高められます。