Androidバンカー「Rokarolla」—PIN・SMS・クリップボードを奪う“多機能RAT化”の臨界点です

今日の深掘りポイント

• 銀行資格情報の窃取にとどまらず、PIN・SMS・クリップボード改竄・Play Protect無効化まで踏み込む「バンカーのRAT化」が進行中です。これを“アカウント不正”だけの問題として片付けると、組織側の防御設計を誤ります。
• 137種のリモートコマンドという報告は、単機能のフィッシング系ではなく、運用面で柔軟に戦術切替が可能な“汎用エージェント”相当であることを示唆します。検知・封じ込めを「機能単位」ではなく「運用能力単位」で評価する必要があります。
• Play Protectの無効化とAccessibility悪用がセットで使われる以上、「公式ストア外アプリ禁止」だけでは不足です。EMMでの機能制御、アプリ側のオーバーレイ耐性、SMS依存認証の段階的廃止まで含めた多層防御が要件化します。
• クリップボード改竄は、暗号資産だけでなく社内送金・B2B決済でも“アドレス/口座のペースト文化”がある限り再現可能です。ウォレット事業者だけの宿題ではありません。
• 迅速対応の観点では、モバイル脅威防御（MTD）の導入や、Accessibility権限の監視・制限、金融アプリのオーバーレイ検知実装が“今四半期でやり切る”べき最優先事項です。

はじめに

新しいAndroidバンキング型トロイの木馬「Rokarolla」が報告されました。対象は217の銀行・暗号資産アプリ。ロック画面のPIN窃取、SMS読み取り、クリップボード書き換えによる暗号資産アドレスの差し替え、さらにGoogle Play Protectの無効化まで備え、悪意あるWebサイト経由で「Play Protectを名乗るドロッパー」をインストールさせる手口です。ターゲットアプリの偽HTMLログインを動的に取得し、上から重ねて認証情報を奪う王道のオーバーレイ攻撃を使います（出典はZimperiumの分析を紹介した報道）[1]。

現場感で言えば、これは“バンカー”というラベルより、“汎用エージェント化した金融特化RAT”と捉えたほうが対策の筋が良くなります。多段防御のどこから崩すか、組織・サービス・ユーザーの三層で再設計するタイミングです。

深掘り詳細

まず押さえるべき事実（報道ベース）

• 標的は217の銀行・暗号資産アプリ。偽のHTMLログインページをダウンロードし、正規アプリの上に重ねて入力情報を窃取します[1]。
• 盗むものはPIN、SMSコード、クリップボードの暗号資産アドレスなど。加えてGoogle Play Protectを無効化します[1]。
• 感染経路は悪性サイト経由。Google Play Protectを装ったドロッパーをユーザーに入れさせ、Accessibility権限を取得して操作を自動化します[1]。
• C2からの遠隔コマンドは137種類とされ、同種マルウェアの中でも多機能と報じられています[1]。
• ベンダは「Google Playからのみインストールし、Play Protect有効化を維持」といった基本対策を推奨しています[1]。

出典： [1] The Hacker Newsによる解説（Zimperiumの調査を引用）: https://thehackernews.com/2026/06/new-rokarolla-android-malware-steals.html

編集部インサイト（戦術・運用で読み解く）

• バンカーの“多機能化”が臨界点に達しつつある
  137コマンドという報は、スパム送信やオーバーレイのオンオフに留まらず、端末設定変更、UIナビゲーション、各種センサー/ストレージへのアクセスなど、運用側が状況に応じて柔軟にプレイブックを切り替えられることを示唆します。結果として、銀行アカウント乗っ取りから暗号資産のアドレス差し替え、二要素の迂回まで“一連の攻撃ライフサイクル”を1マルウェアで回せます。SOCの検知シグナルも「単一挙動」ではなく「連鎖挙動」を捉える設計に寄せるべきです。
• Play Protectの無効化＝“検知面の土台崩し”
  エンドユーザーの最後の砦をオフにしてから本番の窃取に入るのは、EDR殺しと同型の常套手段です。企業側は「公式ストア外の禁止」に加え、EMMで“不明ソースの許可”“アクセスビリティ設定の変更”“アプリのインストール権限”を管理し、MTDでふるまい検知を重ねる必要があります。Play Protect“だけ”に寄りかかると抜かれます。
• PIN窃取の意味合い
  PIN自体は端末暗号の鍵素材やStrongBoxに直接アクセスする万能鍵ではありませんが、オーバーレイ・Accessibilityと組み合わさると、画面ロック解除の自動化や生体代替フローの誘導など“決済直前の摩擦”を落とせます。つまり“高リスク操作のハードルを下げる”戦術価値が高いのです。
• クリップボード改竄は金融全域のアンチパターン
  暗号資産に限らず、口座番号・振込先ID・社内振替先など「長い識別子をコピペする」業務が残る限り、同型の被害は再現します。アプリと業務設計の両面で“ペースト前提”を見直す必要があります。

脅威シナリオと影響

以下は、公開情報を基にした合理的な仮説シナリオです。特定の地域・業界に限定される確証は現時点ではありませんが、国内でも同型の被害が成立しうる前提で評価します。

• シナリオA（個人＋金融アプリ）

  1. 悪性サイトで「Play Protect」を装うインストーラを入手
  2. Accessibility権限の取得とPlay Protect無効化
  3. 銀行アプリ起動に合わせて偽HTMLをオーバーレイ、ID/パス/OTPを収集
  4. 攻撃者が即時ログインし送金、必要に応じてSMSを傍受して2FAを迂回
  5. 暗号資産送金時はクリップボードを差し替え、外部アドレスへ吸い上げ
     影響: 個人口座・暗号資産の直接損失、二次不正（クレカ、EC、通信キャリア）へ波及。

• シナリオB（BYOD/ハイブリッド企業）

  1. 私用端末が感染
  2. 仕事用メール・チャット・SaaSのOTP/通知を読取
  3. 業務アカウントへの不正ログイン→社内情報流出・BEC誘導送金
     影響: 金融以外の事業でも、アカウント乗っ取りからの金銭・信用被害。

• シナリオC（暗号資産事業/大口保有者）

  1. ウォレット操作時にアドレスをコピペ
  2. 直後にクリップボードが攻撃者アドレスへ置換
  3. ユーザーは気付かず送金を確定
     影響: 高額損失。チェーン上で不可逆、事後回復がほぼ不可能。

MITRE ATT&CK for Mobileの観点（仮説マッピング）

• Initial Access: 悪性アプリ配布／ユーザー実行（偽Play Protectドロッパー）
• Execution/Persistence: Accessibility機能の悪用、自己起動・自動権限付与
• Defense Evasion: セキュリティ機能無効化（Play Protect）、アイコン非表示、難読化
• Credential Access: オーバーレイによる資格情報収集、SMS/通知からOTP傍受、PIN窃取
• Discovery: インストール済みアプリ列挙、フォアグラウンドアプリ監視
• Collection: クリップボード読み取り・書き換え、フォーム入力の捕捉
• Command and Control: C2経由の多種類リモートコマンドによる操作
• Impact: 不正送金、暗号資産アドレス差し替えによる資産移転

全体感として、緊急度と実行可能性が高く、かつ信頼できる技術的ディテール（多機能・オーバーレイ・Play Protect無効化・SMS傍受等）が報じられているため、企業・金融機関ともに“即応の価値が高い”案件です。ポジティブな要素は、基本対策（公式ストア限定・Play Protect有効化）で一般ユーザー層の相当割合を守れる点ですが、組織としてはそれを超える層（BYOD・高額決済・暗号資産）に対する上積み対策が勝負になります。

セキュリティ担当者のアクション

• エンタープライズ／CISO・IT運用

  • EMM/Android Enterpriseの徹底
    • 不明ソースからのインストール禁止を全社適用します。
    • Accessibility設定の変更を管理者ポリシーで制限します（利用が必要な部署は承認制でサンドボックス化します）。
    • アプリごとの「不明なアプリのインストール」を原則オフにします。
  • モバイル脅威防御（MTD）の導入
    • Accessibility悪用・オーバーレイ・C2通信・Play Protect無効化といった“連鎖挙動”を検知できるMTDを主要端末に展開します。
  • ネットワーク制御
    • セキュアWebゲートウェイ/DNSフィルタで既知の配布・C2をブロックします。プロキシ回避検知を有効にします。
  • モニタリング
    • 管理端末のPlay Protect状態、Accessibility有効化イベント、SYSTEM_ALERT_WINDOW使用アプリの監査を定期実施します。
  • ユーザー教育
    • 「Play Protectを名乗る更新・保護アプリ」は存在しないこと、Accessibility要求のリスク、クリップボード改竄の実例を周知します。

• 金融・暗号資産サービス（アプリ開発・不正対策）

  • 認証・決済の堅牢化
    • SMS OTP依存を段階的に縮小し、FIDO2/Passkeyやアプリ内プッシュの番号一致・デバイスバインディングへ移行します。
    • Play Integrity API等のデバイス健全性確認と、リスクベース認証（新規端末・高額・深夜）の強化を行います。
  • オーバーレイ・Accessibility耐性
    • 画面がオーバーレイ・タップジャッキング状態の時は高リスク操作を抑止します（例: タッチが隠蔽されている場合の送金ボタン無効化）。
    • Accessibility有効時は追加の確認手順や金額上限を適用します。アクセシビリティを必要とするユーザー配慮の代替UXも用意します。
  • クリップボード・アドレス防御
    • 送金先アドレスのペースト直後にハッシュ末尾/先頭数桁の“読み上げ確認”や、貼り付け後の自動置換検知（短時間での差分検出）を実装します。
    • アドレス帳/ホワイトリスト方式やスキャン（QR/NFC）優先のUXに寄せ、コピペを最短にします。
  • 不正対策運用
    • アプリ外（WebViewやHTML）でのログインフォーム表示をサーバ側で異常値として扱い、セッション隔離やステップアップ認証に切り替えます。

• SOC/Threat Intelligence

  • 収集・ハンティング
    • ベンダ公開のIOC/挙動シグネチャ（配布ドメイン、C2、インストーラ名、Accessibility悪用の固有イベント）を継続収集し、MTD/EDR/SWGへ反映します。
  • 可視化
    • 「Play Protect無効化」「Accessibility新規有効化」「不明ソース有効化」の相関ダッシュボードを作り、短時間相関でアラート化します。
  • インシデント準備
    • 金融アプリ・暗号資産アプリの“強制セッション破棄/デバイス再認証”の標準手順をサービス側と合意しておきます。端末からのアプリデータ退避・初期化手順も利用者向けに整備します。

最後に。Rokarollaのような“多機能バンカー”は、ユーザーの画面と操作をどこまで“運用で奪えるか”の勝負に出ています。こちらは“設計の層”で勝ちにいくしかありません。端末側の機能制御、アプリ側の耐タンパ・耐オーバーレイ、サーバ側の行動分析。この三層の厚みが、結局は被害の出方を分けます。今四半期の優先タスクとして、ぜひ経営の支援を取り付けて進めてほしいと思います。

参考情報

• The Hacker News: New Rokarolla Android Malware Steals PINs, SMS Codes, and Crypto Wallet Funds（Zimperium調査の要点を紹介）: https://thehackernews.com/2026/06/new-rokarolla-android-malware-steals.html

※本稿の技術的事実は上記公開情報に基づき、戦術・運用面の考察は編集部による仮説を含みます。追加の一次情報（IOCやC2詳細等）が公開され次第、続報でアップデートします。