はじめに
こんにちは。サイバーセキュリティチームに所属している宮﨑です。
普段はセキュリティ製品のアラート分析や、開発組織全体へセキュリティ・バイ・デザインを推進するための取り組みなど組織に関するセキュリティを広く担当しています。
今回のテックブログでは、2025年9月末に当社のAndroidアプリが一部端末でマルウェアとして判定され、お客様から複数のお問い合わせをいただいた際に、サイバーセキュリティチームで実施した調査プロセスと得られた知見を共有します。
対象読者
以下のような方を想定しています。
- 金融・証券・フィンテック業界のセキュリティ担当者/ SOCアナリスト
- スマホアプリ/ Webサービスを開発・運用している事業会社の開発者・セキュリティエンジニア
- CSIRT/ 脅威インテリジェンス/ マルウェア解析に関わる技術者
- セキュリティ教育やリスク管理を担当する企画部門の方
概要
2025年9月末、当社のAndroidアプリが一部の端末環境でマルウェアファミリ「Rootnik」として誤検知される事象を確認しました。
お客様から複数のお問い合わせをいただき調査を進めたところ、とあるメーカー製のAndroid端末でのみ発生していることが分かり、当該端末に標準搭載されているセキュリティ管理アプリ（Avast社エンジン搭載）が検知元であることが判明しました。
本記事では、公開情報の調査・静的解析（リバースエンジニアリング）・実機検証の3軸で原因を切り分け、最終的に外部ライブラリ内に含まれていた特権コマンドの呼び出し処理が誤検知の原因であると判断するに至った流れを共有させていただきます。
なお、本件は外部セキュリティエンジンによる誤検知が要因であり、当社アプリ側に不正挙動は確認されていません。
調査の前に
今回の目的は「なぜAvastの検知エンジンが当社アプリをRootnikと判定したのか」を特定することです。
検知元となるセキュリティ管理アプリの構成を調べたところ、検知エンジンにAvast社のアンチウイルス製品が組み込まれていることが確認できました。
なお、Avast社の公式サイトには誤検知申請フォームが用意されています。
そのため、過検知されたAPKファイルを提供して過検知対応依頼が可能です。
ただし、調査・反映までの所要時間は不明であるため、申請に加えて自社側でも並行して原因を切り分けることにしました。
この時点で判明していること
| 項目 | 内容 |
|---|---|
| 問い合わせ発生日 | 9月末 |
| 対象者 | 特定のメーカーをご利用のお客様 |
| 検知ツール | 組み込みのセキュリティ管理アプリ |
| 検知エンジン | Avast |
誤検知の原因調査
誤検知の原因を特定するために、以下の3つのアプローチで調査を行いました。
- マルウェア判定結果の調査
- スマホアプリのリバースエンジニアリングによる調査
- 実機による調査
【アプローチ：１】マルウェア判定結果の調査
まずは、お客様から共有いただいた検知画面を確認したところ、検知名が「Android.Riskware.Install.Rootnik」と表示されていました。
続いて、この「Rootnik」というマルウェアファミリがどのような挙動を行うのかを整理しました。
公開情報によると、Rootnikは以下の特徴を持つAndroid向けマルウェアとして知られていました。
- 商用のroot化ツールを悪用してroot権限の取得を試みる
- 取得した権限を利用し、端末内の個人情報を不正取得する
参考記事：
- Palo Alto Networks社 Unit 42の解説記事
- Microsoft社の脅威インテリジェンス
- Fortinet社の解析記事
公開情報から見えてきた仮説
Rootnikマルウェアの主な特徴は「root権限を取得して不正操作する」ことです。
なお、当社のスマホアプリにはroot権限が必要な操作は組み込まれていません。
そのため、「検知エンジンがroot権限に関連する何らかのコードや挙動を誤って検知した可能性」
が高いと考えました。
仮説の整理
この段階では、アプリ自体に明確な悪性挙動は見当たらず、
「検知エンジン側のシグネチャ定義による過検知の可能性が高い」という仮説を立てました。
次のステップとして、この仮説を裏付けるための静的解析および実機検証を実施しました。
この時点での新たな発見
| 項目 | 内容 |
|---|---|
| 検知判定 | Android.Riskware.Install.Rootnik |
| 公開情報から得られた整理 | root権限取得から情報窃取 |
【アプローチ：2】スマホアプリのリバースエンジニアリングによる調査
静的に調査するため、実物APKをもとに静的解析（リバースエンジニアリング）を行いました。
なお、社内のGitHubから生のソースコードを確認するという案も検討しましたが、実際にGoogle Playから対象アプリを取得して解析したほうがより正しい結果が得られるため前者を選びました。
※本調査は社内の正当な目的に基づき、当社が権利を保有するアプリの範囲で実施しています。
用意したもの
- Android Studio（
adbによるAPK取得） - JD-GUI（
.classからJavaソースを復元して閲覧）- 公式リンク：https://java-decompiler.github.io/
- macOSのためHomebrewで導入
解析方針は、AndroidManifest.xmlの権限・コンポーネントと、root化に関連する文字列の検索です。
特に、root権限を利用するような処理がないかを重点的に調べたところ、外部ライブラリ内にsuを実行するコードを確認しました。
// root権限でコマンドを実行する処理
Runtime.getRuntime().exec("su")
通常のAndroid端末ではデフォルトでroot権限は無効化されており、この呼び出しは失敗します。
しかし、root化された端末ではこの処理によって「特権シェル」を起動できる可能性があります。
さらに、当該ライブラリ内にはroot権限のみが操作可能な「/system/」配下を確認する処理も見られ、root化検知を目的とするロジックが含まれていると推測されます。
つまり、このコードは端末のroot済み端末/非root端末を検出する目的で存在しており、悪意あるroot取得を行うものではありませんでした。
社内確認の結果、当該コードは特定の機能を提供する外部ライブラリに由来することが分かりました。
このため、Avastのシグネチャ更新タイミングと、当該ライブラリの挙動が相互作用して、一時的に誤検知が発生した可能性が高いと考えられます。
この時点での新たな発見
| 項目 | 内容 |
|---|---|
| リバース解析 | 外部ライブラリ内で su 呼び出しを検知 |
| 推測 | シグネチャ更新とライブラリ挙動の相互作用による誤検知の可能性 |
【アプローチ：3】実機による調査
2025年10月1日、誤検知が発生していたメーカーと同じ端末を社内の検証機として用意し、実機検証（動的デバッグ）を実施しました。
結果、当社アプリはセキュリティ管理アプリでマルウェア検知されず、正常判定となりました。
また、シグネチャ更新履歴を確認したところ、2025年9月30日に更新が入っていることを確認できました。
このことから、9月30日までに適用されたシグネチャ更新で誤検知が解消された可能性が高いと考えています。
この時点での新たな発見
| 項目 | 内容 |
|---|---|
| 実機再現性 | 手元の検証機では再現せず（正常判定） |
| 変化点 | 2025年9月30日にシグネチャ更新 |
| 補足仮説 | 更新前の特定バージョンで誤検知が生じた可能性 |
時系列の整理
ここまでの調査結果をもとに、事象の流れを整理しました。
| 日付（2025年） | 出来事 | 影響の推定 |
|---|---|---|
| 9月25日 | Avastマルウェア検知シグネチャ更新 | - |
| 9月25日〜 | 特定のメーカーの端末で当社アプリがRootnikと判定 | お問い合わせが複数発生 |
| 9月30日 | 公開情報＋リバース解析を実施 | 外部ライブラリのsu呼び出しが原因と推定 |
| 9月30日 | Avastマルウェア検知シグネチャ更新 | 誤検知が解消方向に変化 |
| 10月1日 | 社内実機で再検証 | 検知は再現せず（正常判定） |
調査の結論と考察
事実として確認できたこと
- 外部ライブラリ内に
suコマンド呼び出しが含まれていた - 当社アプリ側でroot権限取得や不正挙動は確認されていない
- 9月30日のシグネチャ更新後は再現せず、問い合わせも収束した
推測される原因
- 外部ライブラリの
su呼び出しロジックが、特定シグネチャ版のAvastエンジンで誤検知された可能性が高い - 同一ライブラリを採用している他社アプリでも同様の誤検知が発生し、ベンダー側で修正が行われたと推測される
※第三者製品の内部ロジックは非公開であるため、上記は当社の調査と事実確認に基づく推測です
結論（当社の判断）
- 発生原因は外部エンジンの定義更新による一時的な誤検知であり、当社アプリに起因する問題はない
注記
本記事の内容は、2025年10月時点で当社が確認した事実と検証結果に基づきます。
第三者製品の仕様やシグネチャは随時更新されるため、将来的に同様の事象が再現しない場合があります。
本記事は当社アプリの品質不具合を示すものではなく、誤検知対応における知見共有を目的としています。
誤検知の収束
調査結果と推測内容を開発チームに共有後、10月2日以降は新規問い合わせ件数が0件となり、事象は収束しました。
さいごに
今回のケースは、外部エンジンのシグネチャ更新による外因的な誤検知でしたが、検知の報告から原因の切り分けまでのプロセスを通じて、「どんなに安全なアプリでも誤検知されることはある」という現実を改めて実感しました。
誤検知対応では、冷静に分析して事実を積み上げることが何より大切です。
公開情報の調査、コードの静的解析、実機検証といった複数のアプローチで検証を進めることで、根拠を持って「問題ない可能性が高い」と説明できるようになります。
そして、このようなトラブルこそ、セキュリティチーム・開発チーム・CSチームが連携する良い機会でもあると感じ、社内での検知対応プロセスの強化にもつながりました。
今後も今回のような事例を通じて得られた知見を継続的に発信し、社内外のセキュリティ品質向上と誤検知対応の効率化に貢献していきたいと考えています。
この記事が、誤検知に直面したときの一つの調査モデルケースとして、同じような状況で課題に直面しているエンジニアの方々の参考になれば幸いです。
読んでいただきありがとうございました。
筆者プロフィール
システム基盤グループ サイバーセキュリティチーム
セキュリティエンジニア
宮﨑（みやざき）
Discussion