Androidアクセシビリティ機能はなぜ不正送金に悪用される？攻撃の仕組みと対策

by

Androidスマートフォンには「アクセシビリティ」という機能があります。

本来は、視覚や身体などに障害のある人をはじめ、スマートフォンの操作を支援するために用意されている重要な機能です。

ところが、このアクセシビリティ機能がAndroidを狙うバンキングマルウェアによって悪用され、不正送金などにつながるケースがあります。

「アクセシビリティ機能を有効にしただけで、なぜ銀行口座からお金を盗めるのか？」

疑問に思う人もいるでしょう。

問題はアクセシビリティ機能そのものではありません。

アクセシビリティサービスには、ユーザーの操作を支援するために、画面上の情報を認識したり、UIを操作したりする強力な機能があります。

悪意のあるアプリにこうした権限を与えてしまうと、その能力が逆に利用され、

画面情報の取得
↓
ボタンや入力欄の認識
↓
ユーザー操作への干渉
↓
銀行アプリなどの操作
↓
不正送金

へ発展する可能性があります。

実際にAndroidバンキングマルウェアでは、Accessibility Serviceを利用して送金処理を自動化する**ATS（Automated Transfer System）**と呼ばれる攻撃機能も確認されています。

本記事では、

  • Androidアクセシビリティ機能とは何か
  • なぜマルウェアに悪用されるのか
  • 不正送金まで発展する仕組み
  • ATSとは何か
  • オーバーレイ攻撃との違い
  • Device Bindingだけでは防げない理由
  • 利用者と金融・決済アプリ側ができる対策

について解説します。

Androidのアクセシビリティ機能とは？

Androidのアクセシビリティ機能は、本来ユーザーのスマートフォン操作を支援するためのものです。

例えば、

  • 画面上の情報を読み取る
  • UI要素を認識する
  • 操作を補助する
  • 特定の操作を自動化する

といった用途に利用できます。

これらは、スマートフォンを操作することが難しいユーザーにとって非常に重要な機能です。

したがって、

アクセシビリティ機能＝危険な機能

ではありません。

問題になるのは、その強力な権限を悪意のあるアプリに与えてしまった場合です。

なぜアクセシビリティ機能がマルウェアに狙われるのか？

理由は、ユーザーを支援するための機能が、攻撃者にとっても非常に強力だからです。

Accessibility Serviceを悪用するAndroidマルウェアでは、画面上のUI要素を認識したり、クリックなどの操作を実行したりすることができます。

ThreatFabricが分析したバンキングマルウェア「Medusa」では、Accessibility Serviceを利用したスクリプトエンジンによって、被害端末上でユーザーに代わって操作を実行する機能が確認されています。

つまり攻撃者からすると、

ユーザーがスマートフォン上でできる操作の一部を、マルウェアにも実行させられる

ことになります。

不正送金はどうやって行われる？

典型的なイメージを考えてみましょう。

まず利用者が、

「セキュリティアップデートが必要です」

「本人確認アプリをインストールしてください」

などと誘導され、不正なAndroidアプリをインストールしたとします。

さらに、

「正常に動作させるにはアクセシビリティを有効にしてください」

などと案内され、利用者自身が権限を許可してしまいます。

すると悪意あるアプリが強力な操作能力を得る可能性があります。

攻撃の流れ

一例を簡略化すると、次のようになります。

① 不正アプリをインストール

↓

② アクセシビリティ権限を要求

↓

③ ユーザーが許可

↓

④ マルウェアが画面や操作を監視

↓

⑤ 銀行・決済アプリの利用を検知

↓

⑥ UI情報を読み取り・操作

↓

⑦ 振込先や金額などを操作

↓

⑧ 認証・確認操作へ干渉

↓

⑨ 不正送金

実際の攻撃方法はマルウェアによって異なりますが、ポイントは攻撃者が必ずしも別のPCやスマートフォンから銀行へログインする必要がないことです。

ATS（Automated Transfer System）とは？

この問題を理解するうえで重要なのが、

ATS（Automated Transfer System）

です。

日本語では「自動送金システム」などと表現できます。

ATSは、バンキングマルウェアが銀行アプリなどのUIを認識・操作し、送金処理の一部または大部分を自動化する仕組みです。

ThreatFabricが分析したXenomorphでは、Accessibility Serviceを利用したランタイムエンジンによってATSフレームワークを実装し、感染から資金窃取までの不正処理を大幅に自動化する能力が確認されています。

「パスワードを盗む」から「本人の代わりに操作する」へ

ここが非常に重要です。

従来のフィッシングでは、

ID
＋
パスワード

を盗み、

攻撃者が別の端末からログインするイメージが一般的でした。

しかしATS型の攻撃では発想が違います。

本人のスマートフォンそのものを操作してしまう

のです。

つまり攻撃は、

Credential Theft（認証情報窃取）

から、

Device Takeover（端末操作の乗っ取り）

へ進化していると考えることができます。

ATSでは何が操作される？

Accessibility Serviceから見えるUI情報を利用できれば、マルウェアは画面上の特定の要素を探すことができます。

例えば、

  • 振込
  • 振込先
  • 口座番号
  • 金額
  • 確認
  • 実行

などです。

ThreatFabricが報告したMedusaでは、Accessibility Serviceを利用して特定の入力欄へ攻撃者が指定した値を設定できる機能が確認されており、例として銀行振込の受取人口座を書き換える可能性が示されています。

ユーザーに画面を見せない攻撃もある

さらに厄介なのが、利用者から不正操作を隠そうとする手法です。

攻撃者は、

偽の画面
黒い画面
「処理中です」という表示

などをユーザーへ見せながら、背後で操作を行う場合があります。

そのため、

「自分は送金操作なんてしていない」

にもかかわらず、正規端末上では操作が進められる可能性があります。

オーバーレイ攻撃とは何が違う？

アクセシビリティ悪用と一緒に語られることが多いのがオーバーレイ攻撃です。

両者は関連する場合がありますが、同じものではありません。

オーバーレイ攻撃では、悪意のあるアプリが正規アプリの上に偽の画面を表示します。

例えば、

本物の銀行アプリを起動

↓

その上に偽ログイン画面を表示

↓

ユーザーがID・PWを入力

↓

マルウェアが取得

という攻撃です。

OWASPも、オーバーレイ攻撃について、正規アプリの上に偽のUIを重ね、ユーザーを騙して認証情報などを取得する攻撃として説明しています。

アクセシビリティ悪用では「操作」までできる

一方、Accessibility Serviceの悪用では、

画面を見る
だけでなく、

UIを探す
↓
ボタンを押す
↓
文字を入力する
↓
画面を移動する

といった操作まで自動化できる場合があります。

そのため、

オーバーレイ：ユーザーを騙して入力させる

Accessibility悪用：ユーザーに代わって端末を操作する

という違いで理解すると分かりやすいでしょう。

実際には両方を組み合わせるマルウェアもあります。

OTP・SMS認証があっても安心とは限らない

「でも銀行ならワンタイムパスワードがあるから大丈夫では？」

と思うかもしれません。

ここも注意が必要です。

Androidマルウェアでは、

  • SMS
  • 通知
  • 画面
  • ユーザー操作

など、複数の情報を狙うものがあります。

OWASPも、Androidの通知はプライベートな情報として扱うべきではなく、NotificationListenerServiceを悪用して通知に表示された2FAコードなどを取得するマルウェアが存在すると説明しています。

つまり、

パスワード
↓
OTP
↓
端末操作

と、攻撃者側も認証対策に合わせて攻撃手法を拡張しているのです。

Device Bindingを導入していても防げない？

前の記事で解説したDevice Binding（端末認証）は、不正ログイン対策として非常に有効な防御層です。

例えば、

ユーザーの登録端末A

とアカウントを結びつければ、

攻撃者が、

端末B

から正しいID・パスワード・OTPを入力しても、

「登録端末ではない」

という情報を利用できます。

しかしアクセシビリティ悪用では事情が変わります。

攻撃に使われているのが「登録済みの正規端末」

攻撃者が遠隔地の端末Bからログインするのではなく、

ユーザー自身の登録済み端末A

をマルウェアが操作したらどうでしょうか。

サービス側から見れば、

正しいユーザー
＋
登録済み端末
＋
正規アプリ

からアクセスしているように見える可能性があります。

これがDevice Bindingだけでは十分でない理由です。

「正しい端末＝本人操作」とは限らない

ここまで来ると、モバイル不正対策の難しさが見えてきます。

正しいパスワードだから本人

とは限りません。

正しいOTPだから本人

とも限りません。

登録済み端末だから本人

とも限りません。

アクセシビリティ悪用などを考えると、

「その操作を本当にユーザー本人が行っているのか？」

まで考える必要があります。

Root化していないAndroidでも狙われる？

ここも重要なポイントです。

アクセシビリティ悪用は、必ずしも端末のRoot化を前提とした攻撃ではありません。

Accessibility Service自体はAndroidが提供する正規機能です。

ユーザーが悪意あるアプリに必要な権限を許可してしまえば、攻撃者はOSの脆弱性を利用してRoot権限を取得しなくても、強力な機能を悪用できる場合があります。

つまり、

「自分のスマホはRoot化していないから安全」

とは限りません。

Googleもアクセシビリティ権限を金融詐欺リスクとして扱っている

この問題はGoogle側でも対策が進められています。

Google Play Protectでは、ブラウザやメッセージアプリ、ファイルマネージャーなどから直接インストールされるアプリが、

  • SMS受信
  • SMS読み取り
  • 通知アクセス
  • Accessibility

などの機密性の高い権限を利用する場合、金融詐欺で頻繁に悪用される高リスクな組み合わせとして扱い、一定条件下でインストールをブロックしています。

つまりアクセシビリティ悪用は、理論上の攻撃ではなく、Androidプラットフォーム側も金融詐欺対策として警戒している攻撃経路です。

利用者側でできる対策

1．知らないアプリにアクセシビリティ権限を与えない

最も重要です。

アプリから、

「アクセシビリティをONにしてください」

と表示されたら、なぜその権限が必要なのか確認してください。

特に、

  • SMSで案内されたアプリ
  • メールからインストールしたアプリ
  • WebサイトからダウンロードしたAPK
  • 「セキュリティ対策」を名乗る見覚えのないアプリ

などには注意が必要です。

2．アプリは原則として正規ストアから入手する

Google Play以外からアプリをインストールする、いわゆるサイドローディングには注意が必要です。

特に、

「銀行から案内された」
「本人確認に必要」
「セキュリティ更新が必要」

などとしてAPKファイルのインストールを求められた場合は、公式サイト・公式窓口から確認してください。

3．アクセシビリティ設定を確認する

Androidの設定から、どのアプリにアクセシビリティ権限を許可しているか確認できます。

見覚えのないアプリや、アクセシビリティ機能を必要とする理由が分からないアプリが有効になっている場合は注意してください。

ただし、アクセシビリティサービスには正当な用途もあります。

「アクセシビリティを使っているアプリはすべて危険」ではありません。

4．Play Protectを無効にしない

不正アプリが、

「インストールできない場合はPlay ProtectをOFFにしてください」

などと要求する場合があります。

これは非常に危険なサインです。

セキュリティ機能を無効にするよう求めるアプリには注意してください。

金融・決済アプリ側ではどう対策する？

ここからは企業側の視点です。

アクセシビリティ悪用型の攻撃では、

認証を強化するだけでは不十分

という問題があります。

正規端末上でマルウェアが操作している可能性があるからです。

1．危険な実行環境を検知する

金融アプリ側では、

  • Root化
  • Hooking
  • デバッグ
  • アプリ改ざん
  • エミュレーター
  • 不正なオーバーレイ
  • リスクの高い実行環境

などを検知し、リスク評価へ利用する方法があります。

OWASP MASVSでも、プラットフォームの整合性確認やアンチタンパリング、動的解析への耐性などをモバイルアプリのセキュリティ要件として扱っています。

2．オーバーレイ攻撃を防御する

Androidには、アプリ側でオーバーレイ攻撃を抑制する仕組みもあります。

OWASPでは、Android 12以降で利用できるHIDE_OVERLAY_WINDOWSや、画面が別ウィンドウに覆われている場合のタッチイベントを検出・制御する仕組みなどを紹介しています。

重要な認証画面や送金画面では、こうした対策も検討できます。

3．重要操作をリスクベースで評価する

例えば、

ログイン
↓
振込先追加
↓
高額送金

が短時間に行われた場合、

認証がすべて成功していても通常とは異なる行動として評価できます。

そこで、

  • 新しい振込先
  • 高額取引
  • 通常と異なる操作速度
  • 端末状態
  • 過去の利用傾向
  • セッション状態

などを組み合わせてリスクを評価します。

4．「ログイン成功」でセキュリティを終わらせない

従来型の認証では、

ID・パスワード
↓
MFA
↓
ログイン成功

までがセキュリティの中心でした。

しかし現在のモバイル不正対策では、

ログイン成功
↓
端末状態
↓
アプリ状態
↓
セッション
↓
重要操作
↓
取引

まで継続的に見る必要があります。

Device Binding＋アプリ保護＋取引監視

前回の記事との関係を整理すると、次のようになります。

MFA

「本当に認証要素を持っているか？」

↓

Device Binding

「登録された端末なのか？」

↓

アプリ・実行環境保護

「その端末・アプリは安全な状態なのか？」

↓

セッション・行動監視

「操作は通常と一致しているか？」

↓

取引監視

「この送金を許可してよいか？」

一つの技術ですべてを解決するのではなく、攻撃の段階ごとに異なる防御層を置くことが重要です。

アクセシビリティを一律禁止すればいいのか？

これは簡単ではありません。

アクセシビリティ機能は、本来必要としているユーザーがいる重要な機能だからです。

単純に、

アクセシビリティ機能が有効なら銀行アプリを利用不可

とすると、正当なアクセシビリティツールを利用しているユーザーまで排除してしまう可能性があります。

したがって企業側では、

アクセシビリティ利用の有無だけで判断するのではなく、アプリ・端末・認証・操作・取引など複数のシグナルを組み合わせる

という設計が重要になります。

不正送金対策は「本人確認」から「操作の信頼性確認」へ

アクセシビリティ悪用型攻撃が示しているのは、

本人認証に成功したから安全

という考え方の限界です。

攻撃者が、

本人の認証情報
＋
本人のスマートフォン
＋
正規の銀行アプリ

を利用して操作できるなら、従来の認証だけでは見分けることが難しくなります。

そこで必要になるのが、

誰なのか
だけでなく、

どの端末なのか
どのアプリなのか
端末は安全なのか
どんな操作をしているのか
どんな取引なのか

まで含めた信頼判断です。

まとめ｜アクセシビリティ悪用は「本人の端末を使う」から厄介

Androidのアクセシビリティ機能は、本来スマートフォンの操作を支援するための重要な機能です。

問題は、その強力な機能がマルウェアに悪用されることです。

Accessibility Serviceを悪用するバンキングマルウェアでは、

画面情報を取得
↓
UIを認識
↓
ユーザー操作を自動化
↓
銀行アプリを操作
↓
不正送金

まで発展する可能性があります。

特にATS（Automated Transfer System）型の攻撃では、単純にパスワードを盗むだけではなく、被害者自身のスマートフォン上で不正送金処理を自動化する能力が確認されています。

このため、

MFAを入れれば安全

でも、

Device Bindingを入れれば安全

でもありません。

金融・決済アプリでは、

フィッシング耐性の高い認証
＋
MFA
＋
Device Binding
＋
アプリ・実行環境保護
＋
セッション監視
＋
異常取引検知

という多層的な対策が重要になります。

そして利用者側では、何よりも**「なぜこのアプリがアクセシビリティ権限を必要としているのか？」を確認してから許可すること**が重要です。

アクセシビリティ機能そのものを怖がるのではなく、強力な正規機能を誰に許可しているのかを意識することが、Androidを安全に利用する第一歩になります。

関連記事

参考情報

OWASP：Overlay Attacks
Google：Play Protectの警告と高リスク権限
ThreatFabric：XenomorphとATS
ThreatFabric：MedusaのAccessibility悪用