RatHat AndroidマルウェアはAIを利用するが、より大きな脅威はADBによる永続化

RatHat AndroidマルウェアはAIによる画面制御を導入しているが、より深刻な脅威は、削除を生き延びるよう設計された3層構造にある。セキュリティ研究者は、自動ナビゲーション、認証情報窃取、異例の永続化メカニズムを分析した後、2026年9月16日にこのマルウェアを公開した。RatHatは、Android Accessibilityへのアクセス、ローカルのワイヤレスデバッグ、そして主要な悪性アプリケーションの外側で動作する2つのネイティブエージェントを組み合わせていると報告されている。

AIコンポーネントは、固定された指示だけに全面的に依存するのではなく、変化するインターフェースをRatHatが解釈するのを支援する。これにより、攻撃者はボタンの発見、ラベルの読み取り、侵害端末の操作をより柔軟に行える。しかし、AIが初期侵入を生み出すわけではない。被害者は依然としてGoogle Play以外からAndroidパッケージをインストールし、攻撃開始に必要な権限を付与しなければならない。

より重大な変化は、可視のアプリケーションが消えた後もRatHatが制御を維持しようとする点にある。PromptSpyを含む初期のAI支援型マルウェアは、言語モデルがメーカー固有のインターフェースを操作できることを示した。RatHatは、この適応性にシェルレベルのアクセス、認証情報を盗むオーバーレイ、キーロギング、永続的なネットワークトンネルを組み合わせているとされる。

RatHat AndroidマルウェアはAIと永続的な制御を組み合わせる

RatHatは悪性のAndroidアプリケーションを、アプリケーション自体より長く存続しうる、より広範な制御システムへの入口に変える。

ZimperiumのzLabsチームは、スミッシング、悪性広告、フィッシングページ、サードパーティフォーラムを通じて配布される多段階の感染チェーンを調査した後、RatHatを公開した。これらの経路はユーザーを悪性APKファイルへ誘導する。APKは通常のPlay Store経由ではなくインストールされるAndroidアプリケーションパッケージだ。

悪性アプリはまずAccessibility権限を求める。Android Accessibilityサービスは、利用者による端末操作を支援するために設計されているが、インターフェースの内容を露出させ、自動入力を可能にする場合もある。マルウェアの攻撃者は、画面の読み取り、ボタンの押下、機密性の高い操作の承認に、こうした機能を頻繁に悪用している。

RatHatは、このアクセスを利用してDeveloper OptionsとWireless Debuggingを有効化すると報告されている。次に、ローカルのAndroid Debug Bridge接続に必要な6桁のペアリングコードを抽出する。ADBは、開発、テスト、端末管理のために提供されるAndroidの正規コマンドインターフェースである。

詳細なRatHat分析によれば、このプロセスにより、組み込みのGoエージェントは外部コンピューターなしでシェルレベルの実行を得る。このエージェントは、偽装的なライブラリ名liblocal-service.soで保存される。

このエージェントは、コマンドの実行、バッテリー管理の除外設定の取得、入力情報の収集、永続化の支援を行える。Zimperiumによれば、悪性アプリがインストールされたままであるかも確認し、必要に応じて復元できるという。このコンポーネントが消失した場合、アプリも同様にエージェントを復元できる。

libmedia_codec.soという名前の第2のネイティブコンポーネントは、Fast Reverse Proxyクライアントとして機能する。これは、端末上のローカルサービスと攻撃者のインフラの間にトンネルを構築する。この経路により、攻撃者はアプリ本来のコマンドチャネルだけに依存しないアクセスを得る。

RatHatは、銀行、決済、暗号資産アプリケーションを模倣するHTMLオーバーレイを表示できる。オーバーレイは正規アプリの上に不正なインターフェースを重ね、ユーザーに攻撃者が管理する入力欄へ認証情報を入力させる。

研究者は、SMSメッセージ、通知、ワンタイムパスワードを傍受する機能も確認した。このマルウェアは、テキストの変化を記録し、ブラウザーのアドレスバーを調査し、画面をキャプチャし、インストール済みアプリケーションの一覧を収集できる。

ネイティブエージェントは、低レベルのタッチ入力も監視すると報告されている。この機能は、ユーザーの動きから画面タップ、PIN、パスワード、ロック解除パターンを再構築する助けになりうる。

これらの機能により、AIサブシステムは脅威の一部にすぎない。RatHatはAIを使って操作をより適応的にする一方、ADBアクセスとネイティブエージェントが持続的な運用基盤を提供する。

AIナビゲーションエンジンはコストのかかる手作業を減らす

RatHatのAIが重要なのは、絶え間ない攻撃者の入力を必要とせず、変化するAndroid画面を構造化されたナビゲーション判断へ変換するためだ。

従来のモバイル自動化は、予測可能なレイアウト、リソース識別子、または慎重に記述された指示に大きく依存している。端末メーカーがメニューを変更したり、ラベルを翻訳したり、システムダイアログを再設計したりすると、この手法は信頼できなくなる。

Google Pixelで機能する指示でも、Samsung、Oppo、Xiaomi端末では失敗する可能性がある。画面サイズ、ソフトウェアバージョン、Accessibility構造における日常的な差異でさえ、固定シーケンスを破綻させうる。

RatHatは、現在のAccessibilityツリーをXMLへシリアライズすることでこの問題に対処する。このツリーは、表示中のインターフェース要素、テキストラベル、要素の種類、画面上の位置を記述する。マルウェアは、この構造化されたスナップショットを、Zimperiumが人気の生成AIアシスタントと呼ぶものへ送信する。

研究者は、サービス、モデル、アカウント、ホスティング構成を特定していない。したがって、追加の証拠なしにRatHatが特定の商用モデルを利用していると説明すべきではない。

AIコンポーネントは、対象を絞ったインターフェースの質問に回答するとされる。名前で指定された要素の中心座標を返したり、要素に表示されるテキストを特定したり、SCROLL_DOWNのような指示を提供したりできる。

これは限定的だが有用な役割だ。モデルは独自に攻撃を考案したり、新たなAndroid権限を付与したりするものではない。攻撃者の目的と端末の現在画面の間で、インターフェースの解釈役として機能する。

自律型マルウェアに関する扇情的な説明は、基盤となる仕組みを覆い隠しかねないため、この区別は重要である。RatHatは依然として、ソーシャルエンジニアリング、危険な権限、デバッグアクセス、悪性ネイティブコード、攻撃者が制御するインフラに依存している。

それでもAIレイヤーは労力を削減できる。攻撃者は、感染したすべての画面を監視したり、インターフェースの種類ごとに別々の自動化スクリプトを維持したりする必要がない。モデルは、ライブのインターフェースデータを次の操作へ変換できる。

BleepingComputerのAIナビゲーションに関する報道は、この適応性がRatHatを完全に静的なスクリプトに基づく自動化と区別するものだとしている。また、継続的な手作業なしにリモート攻撃者が操作する別の手段にもなる。

この手法は、以前に発見されたPromptSpyに似ている。このマルウェアは画面状態データをGoogle Geminiへ送信し、端末の最近使用したアプリ画面で自身を固定するための指示を受け取っていた。固定動作はAndroidメーカーごとに異なるため、モデル誘導型ナビゲーションに適した問題となる。

以前の研究が発表された時点で、ESETはテレメトリー上でPromptSpyを確認していなかった。その実際の到達範囲は、したがって不明のままだった。RatHatはこの概念をさらに広範なアーキテクチャへ拡張しているが、その普及状況も明らかにされていない。

この進展は重要だ。生成AIは、攻撃開発の補助から、一部のマルウェアの実行ループへと移行している。その即時的な利点は超人的な推論能力ではない。インターフェースのばらつきへの耐性である。

AIではなく永続化が、より難しいセキュリティ課題を生む

RatHatの中心的な対立は、適応性と封じ込めの間にある。アプリが侵害を開始する一方、別個のエージェントがその維持を試みる。

Androidのアプリケーションサンドボックスは通常、アプリを機密性の高いシステム機能や他のアプリから分離する。RatHatは、ローカルADBペアリングを利用して、より広範なコマンドアクセスを持つシェルレベルのコンテキストへ、その動作の一部を移すと報告されている。

これは、マルウェアが無制限のroot権限を得ることを意味しない。シェルアクセスとrootアクセスは異なる。ただし、ADBシェルは一般的なアプリケーションでは不可能な操作を実行でき、永続的なコマンド実行も支援できる。

RatHatのGoエージェントは、端末のループバックインターフェース上でHTTPサービスを公開する。その後、リバースプロキシコンポーネントが、攻撃者が制御するトンネルを通じてその内部サービスへ到達可能にする。この構成により、リモートアクセスは悪性アプリの可視インターフェースから切り離される。

結果として生じる設計には、3つの協調要素がある。Androidアプリは権限を取得し、活動を調整する。Goエージェントはコマンドを実行し、永続化を管理する。プロキシはローカルサービスへの外部経路を維持する。

被害者がアプリケーションだけを削除した場合、別のコンポーネントがそれを再インストールできると報告されている。ネイティブエージェントが停止した場合、アプリケーションはそのエージェントを復元できる。この相互復旧は、単一の永続化手法よりも厄介である。

RatHatは通常の削除操作も妨害する。研究者によれば、Androidのアンインストール確認画面を監視し、操作をキャンセルしたうえで、インターフェース上に偽のGoogle Playエラーを表示するという。

同様の削除妨害動作はRatHat以前から存在していた。Androidマルウェアは長年にわたり、Accessibilityサービスを悪用してナビゲーションボタンを押したり、セキュリティ制御を覆い隠したりしてきた。RatHatは、この既知の手法を独立したシェルアクセスチャネルと組み合わせている。

マルウェアの解析妨害機能も、もう一つの層を加えている。研究者は、コンテナ改ざん、異例のZIP属性、暗号化文字列、無効なDEX疑似命令、解析ツールに対する実行時チェックを確認した。

Androidマニフェストは61MBで、その99％は文書化されていない2種類のチャンクで構成されているとされる。Androidのランタイムはこれらのチャンクをスキップする一方、一部の解析ツールは処理中に失敗したり、リソースを使い果たしたりする可能性がある。

このマニフェスト爆弾が直接認証情報を盗んだり、スマートフォンを制御したりするわけではない。その目的は自動検査を遅らせ、パッケージの分類を難しくすることにある。この遅延により、シグネチャや侵害指標が広まるまでの間、キャンペーンはより長く活動できる可能性がある。

RatHatは、デバッガー、再パッケージ化、エミュレーター、rootの痕跡、Frida、Xposedも確認する。これらはマルウェア解析環境で一般的なツールだ。それらを検知することで、悪性コードは動作を変えたり、解析下での実行を停止したりできる。

この複合アーキテクチャは、アプリケーションファイルだけに注目する防御側へ圧力をかける。APKの削除、既知ハッシュとの照合、単一のコマンドサーバーの遮断だけでは、すべての活動中コンポーネントを排除できない可能性がある。

行動シグナルの重要性が増す。セキュリティチームは、不審なAccessibility権限の付与、想定外のWireless Debugging活動、ローカルADBペアリング、異常なネイティブデーモン、永続的なリバーストンネルを探すことができる。

これはシグネチャ検知を無用にするものではない。既知のパッケージハッシュ、ドメイン、証明書、ネットワーク指標は引き続き有用である。RatHatは、こうしたシグナルがランタイムおよび端末状態の監視による支援を必要とする理由を示している。

銀行アプリはインターフェース層の敵対者に直面する

RatHatは、金融アプリ内に保存されたデータだけでなく、ユーザーと金融アプリの間にある信頼されたやり取りを攻撃する。

銀行アプリケーションは、ローカルデータベースを暗号化し、サーバー通信を保護できる一方で、マルウェアはユーザーの画面を監視できる。敵対的なAccessibilityサービスがインターフェースの内容を読み取ったり、タッチ操作を注入したりできる場合、アプリケーション層の保護は別種の問題に直面する。

RatHatは、標的とした銀行および暗号資産アプリの上に偽のHTMLインターフェースを表示すると報告されている。被害者は、ログイン画面が正規サービスのものだと信じたまま、悪性オーバーレイに認証情報を入力する可能性がある。

このマルウェアは、認証コードを含むSMSメッセージや通知内容を傍受できる。また、入力されたテキストの収集やブラウザのアクセス先監視も可能で、窃取した認証情報の前後関係を攻撃者に与える。

Androidには、こうした手法への防御機能が追加されている。Android 15では、画面共有中や通知リスナーサービスにおける一部のワンタイムパスワード露出が制限された。Android 16では、開発者が機密性の高いインターフェース要素を指定できるようになった。

accessibilityDataSensitive設定を使うと、未検証のAccessibilityサービスが保護対象ビューを読み取ったり操作したりすることを防げる。GoogleのAndroid 16 guidanceでは、パスワード、金融情報、その他の機密フィールドへの適用を推奨している。

開発者はPlay Integrityの環境シグナルも利用できる。app access verdictは、他のアプリケーションが画面キャプチャ、オーバーレイ表示、デバイス制御を可能にする権限を持つかどうかを示す場合がある。

これらの防御はRatHatの運用コストを引き上げるが、問題そのものをなくすわけではない。保護の有効性は、Androidのバージョン、端末設定、開発者による導入状況、そして悪意あるアプリがすでに別の制御チャネルを確立しているかどうかに左右される。

Accessibilityは、プラットフォームにとって難しいトレードオフでもある。Androidは、インターフェースの内容を読み取り、ユーザーに代わって操作を行う正当な支援ソフトウェアをサポートしなければならない。あらゆる自動操作を遮断すれば、こうした不可欠なツールが損なわれる。

GoogleはPlay経由で配布されるAccessibilityツールを審査し、欺瞞的な利用について警告している。Play Protect guidanceでは、不審なサービスがデバイスの完全な制御や、個人情報・金融情報へのアクセスを要求する可能性があるとしている。

報告によれば、RatHatはGoogle Play以外からダウンロードされたAPKを通じて侵入する。このため公式ストア経由の直接的な露出は限定されるが、ブラウザ、メッセージ、フォーラム、第三者マーケットを通じたサイドロードは依然として可能だ。

Googleは2026年3月、サイドロード元で見つかるマルウェアの頻度がGoogle Playの90倍以上に上ると報告した。同社は開発者認証を拡大しており、地域ごとのインストール要件は2026年9月30日から導入される予定だ。

この時期は、RatHatが悪意ある配布へのより広範なプラットフォーム対応と並行して現れたことを意味する。開発者認証はPlay以外でインストールされるソフトウェアの説明責任を高められる可能性があるが、高度なインストール経路は引き続き利用可能だ。

金融機関にも対応すべき課題がある。高リスクな操作は、侵害されている可能性のあるスマートフォン上で表示・入力された情報だけに全面的に依存すべきではない。

取引確認には、サーバー側のリスクスコアリング、信頼済みデバイスの履歴、行動変化、新規追加受取人への制限を組み込める。端末の完全性やアプリケーションアクセスのシグナルがリスク上昇を示す場合、銀行はセッションに追加認証を求めることもできる。

企業チームにとって、モバイル端末はノートPCと同等のインシデント対応の深度を必要とする。認証アプリ、業務メッセージ、クラウドセッション、銀行アクセスを保持するスマートフォンは、複数のシステムへの足がかりになり得る。

RatHatの影響範囲と帰属は依然として不明

マルウェアの機能は詳細に記録されている一方で、被害者数、キャンペーン規模、運用者の正体は未解決のままである。

ZimperiumはRatHatを、中国から活動しているとみられる攻撃者と関連付けている。公開された証拠には、マルウェア内で見つかった中国語のプロンプトや、観測されたキャンペーンインフラが含まれる。

言語だけで帰属を断定することはできない。マルウェア開発者はコードを再利用したり、誤解を招く手掛かりを埋め込んだり、国境をまたいで活動したり、無関係な運用者にツールを販売したりできる。現時点で入手可能な報告では、特定のグループや政府支援者は特定されていない。

公開研究では、確認済みの感染件数も示されていない。影響を受けた国、標的となった銀行、キャンペーン期間、稼働中のコマンドサーバー数も列挙されていない。

こうした情報不足により、直ちにどの程度露出しているかについての結論は限られる。RatHatは、厳密に標的を絞ったキャンペーン、発展途上の犯罪サービス、あるいは研究者が一部しか観測できていない、より広範な作戦を支える可能性がある。

正体不明のAIサービスも、もう一つの不確実性を生んでいる。調査担当者は、マルウェアがアシスタントにどのように認証するのか、どの頻度でリクエストを送るのか、接続が失われた場合に何が起きるのかを公表していない。

クラウドベースのAIリクエストは、検出可能なネットワーク活動を生む可能性がある。プロバイダーは不正利用アカウントを停止したり、不審なプロンプトをフィルタリングしたり、捜査に協力したりすることもできる。攻撃者は、アカウントのローテーション、プロキシサービスの利用、ローカルホスト型モデルへの移行で対応するかもしれない。

モデルの信頼性にも検証が必要だ。XMLデータが不完全だったり、ラベルが曖昧だったり、画面に想定外のダイアログが表示されたりすると、インターフェース自動化は失敗する可能性がある。誤ったタップはマルウェアの存在を露呈させ、攻撃を中断させ、運用者自身がアクセスできなくなる原因にもなる。

こうした制約が脅威を無力化するわけではない。AI支援型マルウェアが依然としてインフラ、認証情報、接続性、そして慎重に設計されたフォールバックロジックに依存していることを示している。

以前のPromptSpy事例は有用な参考になる。同事例のモデル支援機能は、限定的な永続化タスク1件に対応していた一方、別のVNCモジュールがリモート制御を可能にしていた。研究者は、そのサンプルが実際のキャンペーンを示すものか、概念実証なのかを確認できなかった。

RatHatは、より運用面で完成度が高いように見える。配布チャネル、認証情報を盗むオーバーレイ、コマンドシステム、ネイティブサービス、トンネリングコンポーネントが、一貫した攻撃チェーンを構成している。

ただし、技術的な完成度は大規模展開と同義ではない。読者は、文書化されたあらゆる機能を、大規模なユーザー層に影響を与えた証拠として扱うべきではない。

Zimperiumはモバイルセキュリティ製品も販売しており、自社製品がRatHatを検出するとしている。この商業的背景は技術的知見を無効にするものではないが、独立した再現検証には依然として価値がある。

The Hacker Newsによる2件目の技術記事は、Zimperiumの開示に基づきこのアーキテクチャを裏付けている。ただし、別個のサンプルに基づく独立したマルウェア分析ではない。

現時点で最も妥当な結論は、より限定的なものだ。研究者は、AIによるインターフェース解釈と既存のAndroid乗っ取り手法、さらに異例なほど持続性の高いADBベースのアーキテクチャを組み合わせたマルウェアを分析した。

RatHatがモバイルマルウェアを変えるかを示す3つのシグナル

次の焦点は、RatHatの手法が報告された一つのファミリーを超えて広がり、防御側、金融アプリ、Androidに測定可能な変化を強いるかどうかだ。

第1のシグナルは、独立したキャンペーン証拠である。追加の研究者は、一致するサンプル、コマンドインフラ、署名証明書、配布ページ、顧客テレメトリー内の感染を探すべきだ。

被害者の地理的分布が確認されれば、RatHatが特定の銀行や地域を標的にしているのかが明らかになる。サンプル数の増加は、孤立した技術実験ではなく、活発な開発や配布を示唆するだろう。

広範なテレメトリーが見られなければ、RatHatが即時の世界的な波を意味するという主張は弱まる。それでもアーキテクチャ上の教訓が消えるわけではないが、緊急性の評価は変わる。

第2のシグナルは、ローカルADB永続化チェーンの再利用である。マルウェア作者は、特に公開研究によって模倣を促すに足る実装詳細が明らかになった場合、信頼性が実証された手法を頻繁にコピーする。

防御側は、Wireless Debuggingを有効化し、ペアリングコードを取得し、シェルレベルのエージェントを配備し、アプリケーション削除後もアクセスを維持する新たなファミリーを監視すべきだ。この仕組みが繰り返し採用されれば、RatHatという名称以上に重要なものになる。

Androidと端末メーカーは、Accessibility、Developer Options、ワイヤレスペアリング、バックグラウンドのシェルプロセスの間にある移行をより厳格化することで対応できる。より適切なユーザー警告によって、こうした操作の不審な組み合わせを明らかにすることもできる。

第3のシグナルは、インターフェース検索を超えた実行時AIの拡大である。RatHatは、座標、可視テキスト、ナビゲーションコマンドをモデルに問い合わせると報告されている。将来のサンプルでは、金融画面の分類、不正なプロンプトの適応、より広範な目標に基づく操作選択にモデルが使われるかもしれない。

この展開は、マルウェア調査の中でAIサービストラフィックを監視すべきだという根拠を強める。また、正当なAccessibilityやテストのワークフローを阻害せずに自動化された不正利用を特定するよう、モデルプロバイダーへの圧力も高めるだろう。

AIが少数の脆弱なナビゲーションタスクにとどまるなら、RatHatは段階的な自動化の強化に見えるだろう。複数のマルウェアファミリーが意思決定ループを採用すれば、防御側は端末ごとにさらに変動の大きい挙動に直面することになる。

ユーザーは、これらのシグナルを待たずに現在のリスクを下げられる。求めていないメッセージ、広告、見慣れないダウンロードページから配布されたAPKファイルは避けるべきだ。特に支援機能と無関係なアプリからの予期しないAccessibility要求は、重大な警告として扱う必要がある。

Play Protectを有効に保ち、不明なアプリケーションのスキャンを許可する。侵害が疑われる場合は、有効化されているAccessibilityサービス、通知アクセス、デバイス管理者アプリ、Developer Options、Wireless Debuggingを確認する。

アンインストールを妨げたり、削除済みのアプリケーションを復元したりする端末には、通常の削除操作をもう一度試すだけでは不十分だ。機密性の高いアカウントやネットワークから切断し、適切なインシデント対応支援を求めるべきである。

組織は、別の信頼できる端末からアクティブなセッションを無効化し、露出した認証情報をローテーションし、金融取引を確認すべきだ。調査が重要な場合は証拠を保全する必要がある一方、初期化が必要になることもある。

RatHat Android malwareが注目に値するのは、適応的なナビゲーションと持続的なデバイス制御を組み合わせているためだ。決定的な問いは、そのAIが次のボタンを押せるかではなく、防御側が各構成要素を封じ込められるかどうかにある。