☠️
4-1. スパイアプリ解析（ Metasploit編）

2025/10/16に公開
 Metasploitとは
本稿では、Metasploitで作成したアプリを解析していきます。

ここでMetasploitとは、セキュリティ企業であるRapid７が提供している侵入テスト用のソフトウェアで、企業や製品のセキュリティ上の弱点を把握するために利用されます。その一環で、マルウェアや不正アプリ的な機能を持つアプリを作成して試すこともできます。

教育目的で一部無償で利用できます。

そこで、今回はMetasploitで作成したアプリを解析することにします。

 Metasploitで作成したアプリの特徴
Metasploitは、Kali Linuxでプリインストールされていますので、ターミナルを開いて"msfvenom"と入力すると利用できます。

以下では、コマンドの一覧を表示する -h(hepl)コマンドを入力しています。

”Payload”とは、遠隔操作用のソフトを意味していますので、1行目を訳すと”Metasploitはスタンドアローンの遠隔操作用ソフトの生成機です”となります。

使い方は「Armoris日記 Android app HTTP Reverse Shell編」が分かりやすく整理してくれています。

 Manifestファイルの確認
では、Metasploitで生成する遠隔操作用アプリはどのような機能を持っているのでしょうか。

ここで、「3. 解析ツール　MobSFの使い方」で紹介したMobSFに遠隔操作用アプリのAPKファイルをアップロードします。

その結果、以下のようなダッシュボードが表示されました。

まずは赤囲み部分の”View AndroidManifest.xml”をクリックして、Manifestファイル確認します。そうすると、以下のような記載がありました。

”ACCESS_FINE_LOCATION”は「位置情報へのアクセス」、”READ_SMS”は「SMSの読み込み」なので、位置情報やSMSメッセージにアクセスするためのPermissionが記載されていることが分かります。

ということは、このアプリは、スマホ内に保存された位置情報やSMSのデータにアクセスする気マンマンという予測がつきます。

 ソースコードの探索
続いて位置情報やSMSにアクセスするためのjavaのソースコードがどうなっているかを見ていきましょう。

ダッシュボードの"View Source"をクリックすると、以下のようなディクレトリの構造が表示されます。

確認すべきファイルが多いので、mobSFの検索機能を活用します。

上記のManifestファイルのPermission欄において、位置情報として”ACCESS_FINE_LOCATION”と記載されていたので”LOCATION”又は”location”と検索してみます。

残念ながらヒットしませんでした。
続いて、SMSを読み込み機能ということで、”sms”で検索します。

こちらも残念ながらヒットしませんでした。
こちらも「3. 解析ツール　MobSFの使い方」で書いたように、リバースエンジニアリングでは、ソースコードを復元できるわけではなくあくまで”Java風”のソースコードを復元できるに留まります。元のソースコード→コンパイル→APKファイル（→リバースエンジニアリング）の過程で文字が変換してしまった可能性があります。
もう一つの可能性として、このアプリはローダ（Loader）である可能性が考えられます。ローダとは、インストールされた後に悪意のあるコードをダウンロード（Load）する機能を持ちます。アップロードやダウンロードでいうところのロードをする機能を持つのがローダです。

本稿でも分かるとおり、ソースコード自体にスパイ機能が記載されていると解析されちゃいます。人間が解析して発見できるということは、セキュリティソフトも当然発見できため簡単に駆除されちゃいます。アプリの場合は、そもそもGoogle Playなどの公式アプリストアの審査で拒否される可能性もあります。
そこで、セキュリティを掻い潜るための手法としてローダがあります。ローダ自体には、悪意のあるコードは含まれておらず、外部のC2（Command & Control）サーバから本丸であるソースコードを受け取る機能だけが搭載されています。なので、セキュリティソフトやアプリストアでも掻い潜る目的で利用されます。
ローダでよく使われる機能として「ClassLoader」があります。

これは、Androidの標準機能で、クラスに関するデータをメモリ上に展開して実行可能にします。これ自体は標準機能でして、本来はアプリの機能を後から追加・更新する場合に利用されます。

セキュリティの文脈では、この機能が悪用され、最初は何の変哲もないアプリとして提供しておいてセキュリティソフトやアプリストアのチェックを突破させ、後から不正な機能を追加でダウンロードさせる目的で利用されます。

そこで、検索してみると、、、ヒットしました。

どうやらPayload.javaというファイルに記載されているようです。

 ソースコードの確認
Payload.javaを確認すると、以下の通り「ClassLoader」という文字列が見つかりました。
悪用防止の観点からコードの詳細は非表示としますが、”a”という関数の中にClassLoaderが含まれています。ちなみに、関数名”a”は元のソースコードでは別の名称("ranRemoteControl"等)が付いていたはずですが、コンパイルの過程を経る上で消えてしまっています。これが”java風のコード”と言われる一例です。
ClassLoaderは、上記のとおり標準機能として特定のクラスをロードする仕組みですが、ここでは外部のC2サーバから受信した（攻撃者が送信した）不正な命令に関するデータをメモリ上に展開して実行する役割を担います。

詳述すると、"Payload.class.getClassLoader()"は、特定のクラスに関するデータ（payload）を受け取る（get）ためのクラス（class）として利用されています。

続くloadClass(e)は、"e"というクラス名の機能を読み込むことを指定します。この”e”も元々の名称が失われていますが、位置情報を盗む機能であれば”com.attack.module.LacationManager”、SMSメッセージを盗む機能であれば”com.attack.module.ReadSms”といった名称であったことが予想されます。

ここまでのイメージとしては、"e"という名称の不正な機能の設計図をメモリ上に展開するというものです。

なお、ここではif文によって不正な機能を持ったクラス”e”が既に端末内に存在することを前提とした処理ですが、"e"がまだ存在しない場合は、この後のelseブロック（上記のスクショでは省略）にて、外部から受信するよう設計されています。
続いて、”getConstructor”及び"newInstance"以下で、インターネット、つまりC２サーバから具体的なデータを受信して、メモリ上に展開した"e"という設計図とおりに不正なプログラムを構築して、そのプログラムとおりに実行を開始します。

一度実行開始すると、例えばアプリ内の位置情報にアクセスして、その情報をC2サーバに随時送信します。もちろん、この過程は"e"の中にすべてプログラムされていますので、自動的に実行されます。
セキュリティエンジニアの視点で言えば、対応に苦慮するなかなか高度な攻撃です。

クラス"e"又はそれに相当するクラスの中身は、外部のC２サーバからその都度受信されて、メモリ上で処理されます。そのため具体的なソースコードはアプリ内に存在しないため、その機能やロジックを静的解析しようがありません。

また、メモリ上で処理されるということは、ファイル形式でストレージに痕跡が残りません。そのため、フォレンジック調査の観点からは、メモリダンプという特殊な調査をしない限り、どのような攻撃を受けたか判明しません。
攻撃者側の視点で言えば、このアプリをターゲットのスマートフォンにインストールさせます。そして、ユーザーが当該アプリを立ち上げてパーミッション（許可）ボタンを押してしまったとします。

そうすると、攻撃者は手元で用意した「位置情報を盗め」、「SMS情報を盗め」といった命令を当該アプリに送信することで、アプリ側はこの命令に従ってスマートフォンから位置情報やSMSのメッセージを情報を入手して攻撃者に返信します。
ユーザーの自衛としては、公式アプリストア以外からアプリをDLしない、アプリに対して不必要にパーミッションを与えない、という点が考えられます。

なお、このMetasploitで作成したアプリは、現在のAndroidスマートフォンだと、Google Protectというセキュリティソフトによって駆除されます。