米国のセキュリティメディア「The Hacker News」などは、アンドロイド向け新種マルウェア「RatHat」が、標準的なアプリの枠を超えて端末内部にシェル権限を確保し、悪性アプリをアンインストールした後も遠隔操作を継続し得る仕組みを報じた。RatHatは、中国拠点とみられる攻撃者グループによる高度なモバイルマルウェアであり、アクセスビリティ権限とADB（Android Debug Bridge）、さらにAI（人工知能）を組み合わせて端末操作を自動化・高度化する点が特徴とされている。
事案の詳細
報道によると、RatHatはアンドロイド端末を狙うモバイルバンキング型のマルウェアで、主にスミッシング（SMSによるフィッシング）や不正広告サイトなどから配布される。端末が感染すると、まずユーザーにアクセスビリティサービスの許可を求め、その高権限を悪用して画面上の操作を自動化し、開発者向けオプションの有効化やワイヤレスデバッグ（Wireless Debugging）のオンなど、通常のアプリでは行えない設定変更を行う。
その後RatHatは、端末画面に表示されるADBペアリングコードやポート番号を自動的に読み取り、端末内部からローカルのADBデーモンとペアリングする。これにより、外部PCをUSB接続することなく、端末内部でADBシェルを確立し、ネイティブのエージェント（liblocal-service.so等）を展開してシェルレベルの権限でコマンドを実行できるようになる。このネイティブコンポーネントは、アプリのライフサイクルとは切り離された常駐プロセスとして動作し、バッテリー最適化などの制限を回避しつつ、継続的なコマンド実行や再感染の足場として機能するとされる。
鍵となるのはADB（Android Debug Bridge）と呼ばれる仕組みの悪用だ。ADBは本来、開発者がPCから端末を操作・デバッグするための正規の機能であり、Android 11以降ではワイヤレスデバッグによるペアリングコード方式が採用されている。RatHatはこのワイヤレスADBを、アクセスビリティサービスによる自動タップや画面読み取り機能を使って有効化し、端末自身のローカルADBデーモンとペアリングすることで、標準的なアプリサンドボックスを突破し、アプリとは独立したシェル環境を確立する。結果として、利用者が不審に思って表面上の悪性アプリを削除した後でも、攻撃者側はシェルレベルの操作経路を維持し、必要に応じて再度マルウェアアプリをインストールしたり、設定変更やデータ取得を続けたりできる可能性がある。
さらに報道では、アンインストール後も維持されるのは「シェルアクセス」であり、端末上での各種操作（コマンドの実行）につながると説明されている。シェル権限を得た攻撃者は、銀行アプリや決済アプリの画面をAIを用いて解析し、PINコードやワンタイムパスワード（OTP）、認証情報を窃取したり、アプリデータやログを操作したり、重要な設定を変更したりすることが可能になる。また、画面遷移をAIが支援することで、固定的なスクリプトでは対応できないUIの変化にも追随し、被害者がアプリを削除しても、バックグラウンドでシェル経由の制御や再インストールを行うなど、「削除で終わらない」持続的な侵害が生じ得ると指摘されている。なお、個々の端末でどこまで被害が拡大するかは、端末の設定状況（開発者オプションの有効/無効、OSバージョン、利用アプリ）や攻撃者の目的に左右されるため、具体的な被害範囲は現時点では端末ごとに異なるとみられ、詳細は現時点で不明な部分もある。
日本への影響
日本の中小企業でも、業務連絡や取引先対応にスマートフォンを使う場面は増えている。私物端末を業務に使うBYODや、社用端末の一括管理が十分でない環境では、端末側の異常に気づきにくい。RatHatのようにアクセスビリティ権限とワイヤレスADBを悪用して「アンインストールしてもシェルレベルの操作権限が残る」タイプのマルウェアは、従来の「怪しいアプリを消して様子を見る」という初動が効きにくく、情報漏えい・アカウント乗っ取り・業務チャットやメールの不正閲覧、さらには銀行アプリや決済サービスの不正利用などにつながり得る点で注意が必要だ。
特に、Android 11以降でワイヤレスデバッグ機能が有効化され得る端末や、開発者向けオプションが安易にオンになっている端末ではリスクが高まる。RatHatはアクセスビリティを足掛かりに、開発者オプションやワイヤレスデバッグを自動操作で有効化し、画面上のペアリングコードやポート情報を読み取ってローカルADBとペアリングするため、利用者が設定内容を正確に把握していない場合、知らないうちにシェル権限を奪われる可能性がある。こうした攻撃は海外での流行を経て日本にも波及することが多く、今後、日本国内の個人や企業ユーザーを標的とした亜種やキャンペーンが出現する可能性は否定できないものの、具体的な国内事例や被害件数については現時点で公表情報が限られており、詳細は現時点で不明である。
対策・今後の展望
- 端末の開発者向け機能を点検する：端末設定で開発者向けオプションやUSBデバッグ、ワイヤレスデバッグ（ADB関連）が不要に有効化されていないかを確認し、業務端末では原則オフにする。RatHatはアクセスビリティの悪用によりこれらの設定を自動で有効化し、ローカルADBデーモンとペアリングしてシェル権限を得るとされるため、そもそも開発者向け機能を使わない端末では、これらを無効化しておくことがリスク低減につながる。
- 「削除したら終わり」を前提にしない：不審な挙動がある端末は、アプリ削除だけでなく、端末のログ確認や初期化（工場出荷状態へのリセット）、OSアップデート、アカウントパスワードの変更などを含む手順を社内で決め、相談先（販売店・保守・セキュリティ支援）を明確にする。RatHatのように、悪性アプリのアンインストール後もネイティブのシェルエージェントやローカルADBセッションが残り、再感染や再インストールが可能なケースでは、「削除＝安全」とは言えないため、端末全体の健全性を確認するプロセスが必要になる。
- 業務データの置き方を見直す：端末単体にデータを抱え込まず、可能な範囲でクラウド側に集約し、多要素認証などでアカウント防御を強化する。RatHatはシェル権限やアクセスビリティ権限を通じて銀行・決済アプリや業務アプリを操作し、認証情報やOTPを窃取し得るとされるため、クラウドサービス側のセキュリティ（多要素認証、アクセス制御、監査ログ）を強化しておくことで、端末侵害後の被害拡大を一定程度抑制できる。
- 端末管理の導入・設定を検討する：MDM（モバイル端末管理）や企業向けの管理機能で、デバッグ系設定の抑止、アプリ配布の制限、紛失時の遠隔ロック・ワイプ、不審なアクセスビリティサービスの検知などを実施する。RatHatのような高度なマルウェアは、標準的なウイルス対策だけでは検知が難しい場合もあるため、企業としてはモバイル端末管理の仕組みを導入し、開発者オプションやワイヤレスデバッグの利用をポリシーベースで制限することが望ましい。
CSRIからの現場アドバイス
【観点①：現場で何が起きているか】MDRや診断の現場では、海外で流行した手口が「取引先を装う連絡」「端末設定の誘導」経由で数週間〜数カ月遅れで入ってくることが多いです。RatHatのように、アクセスビリティ権限を使って開発者オプションやワイヤレスデバッグをオンにし、ローカルADBとペアリングしてシェルアクセスを確保するタイプの攻撃は、表面上のアプリ削除では収束せず、モバイルはPCより監視が薄いこともあって“消したのに直らない”事象が放置されがちで、日本企業でも波及しやすい領域です。現場では、不審なアクセスビリティサービスや開発者向け設定が勝手に有効化されていないかをチェックすることが重要になります。
【観点②：平易な解説】例えるなら、泥棒が玄関の鍵（アプリ）を外されても、勝手口に合鍵（ローカルADB経由の入口）を作って残すようなものです。つまり「怪しいアプリを消した＝安全」ではなく、端末の操作権限そのものが、開発者オプションとワイヤレスデバッグを通じて奪われている可能性がある、ということです。RatHatはアクセスビリティを使って端末の画面構造を取得し、その情報をAIに渡して「どこをタップすればよいか」「どの画面に遷移すべきか」といった指示を得ることで、銀行アプリや設定画面を人手に近い精度でナビゲートします。そのうえで、ADBシェル権限を確保しておくことで、玄関の鍵（見えているアプリ）を外されても、勝手口の合鍵から再び侵入できる状態を維持していると考えられます。
【観点③：今週中にできること】まず業務で使う端末の設定で、開発者向けオプションやUSBデバッグ、ワイヤレスデバッグが有効になっていないかを確認してください。不要な場合はすべてオフにし、社内の標準設定として「開発者オプションは原則無効」を明文化します。次に「不審な端末はアプリ削除で終わらせず、初期化やOSアップデート、主要アカウントのパスワード変更・多要素認証の有効化も検討する」方針を担当者に共有します。最後に主要アカウント（メール、グループウェア、クラウドストレージ、銀行・決済サービスなど）の多要素認証を有効化し、端末側の侵害に備えます。RatHatのような高度なマルウェアに対しては、端末単体の防御に加え、アカウント・サービス側の多層的な防御が不可欠です。
参照: RatHat Android Malware Abuses ADB to Retain Shell Access After Uninstall