機械学習（ML）ベースのAndroidマルウェア検知ツールを、機能を損なわずに回避できる攻撃手法「DroidBreaker」を開発したという研究が公開された（2026年6月、arXiv掲載の査読前プレプリント）。VirusTotal上の商用スキャナによる検出も大幅に減少することが確認されており、MDMや端末セキュリティ製品のML検知機能への過度な依存には注意が必要だと示している。
この記事でわかること
- DroidBreaker研究の概要と、既存手法との違い
- ML検知が抱える根本的な弱点
- 情シス担当者が取るべき実務的な対応の考え方
何が起きたのか
カリアリ大学ら複数の研究者（Christian Scano, Diego Soi, Angelo Sotgiu ほか）は、機械学習を使ったAndroidマルウェア検知器に対する「問題空間攻撃（problem-space attack）」の研究論文「DroidBreaker」をarXivで公開した（論文番号: arXiv:2606.26707）。
「問題空間攻撃」とは、数学的な数値操作ではなく、実際にAPKファイルを改変してマルウェアとしての機能を保ちながらML検知を回避するアプローチだ。研究者たちはまず先行研究を精査し、既存の問題空間攻撃は「実用的でも機能的でもない」と結論づけた。従来手法は無関係なコードモジュールを丸ごと移植するため、副作用となる特徴量が大量に混入し、ビルド失敗や動作不良を引き起こしていたという。
DroidBreakerはどのように機能するのか
DroidBreakerが既存手法と異なるのは、次の3点だ。
| 特性 | 内容 |
|---|---|
| クエリ効率 | ターゲットMLモデルへの影響が大きいAPKコンポーネントを絞り込み、最小限の操作で回避を達成（ブラックボックス・ホワイトボックス両対応） |
| 細粒度操作 | APIコール・アプリモジュール・パーミッション・URLの注入と難読化を組み合わせ、副作用となる特徴量の混入を最小化 |
| 機能保持の検証 | 実行ログとAPIトレースの比較により「実行時等価性（runtime equivalence）」を確認。改変後もAPKが元通りに動作することを担保 |
つまりDroidBreakerは、改変したAPKが「実際に動作するマルウェア」として機能したまま、MLモデルをすり抜けることを実証的に示している。論文によれば、商用マルウェアスキャナを集めたVirusTotalでの検出数も大幅に減少したとされる（具体的な数値は論文PDF参照）。
なぜMLベースの検知は回避されるのか
MLベースのAndroidマルウェア検知は、APIコールのパターン・パーミッションの組み合わせ・コードの構造的特徴量などを学習して判定する。この仕組みには本質的な弱点がある。
- 特徴量の操作可能性: 学習に使われた「特徴量」の空間が攻撃者に知れれば（あるいは推測されれば）、その特徴を意図的に操作できる
- 良性コードの偽装注入: 無害に見えるAPIコールや許可を追加するだけで、モデルの判定スコアを「安全」側へ押し込める
- モデルの汎化限界: 学習データに含まれない回避パターンには対応できず、継続的な再学習が必要になる
こうした特性は、Android専用に限らずMLベースのセキュリティ製品全般に共通する課題でもある。
情シスはどう受け止めるべきか
MDMや統合エンドポイント管理（UEM）製品が組み込むモバイル脅威防御（MTD）機能の多くは、機械学習を検知エンジンに採用している。今回の研究が示す教訓は、そうしたツールへの過信をやめ、多層防御の発想に立ち返ることだ。
実務で参考にしたいポイント
- ML検知ツールは「補助層」として位置づける: 単独の「正解判定器」として使わず、振る舞い検知・ネットワーク監視・アプリ許可ポリシーと組み合わせる
- サイドローディングを制限する: 公式ストア外からのAPKインストールを組織ポリシーで禁止することで、細工済みAPKの配布経路を絞る
- 検知ツールのシグネチャ・モデルを常に最新に保つ: MLモデルは学習データの鮮度で性能が変わる。ベンダーのアップデートを積極的に適用する
- インシデント対応訓練にモバイル侵害シナリオを加える: 端末検知をすり抜けたマルウェアが社内システムへ横展開するシナリオを想定して備える
IPA（情報処理推進機構）のスマートフォン・タブレット安全管理については、中小企業向けガイドラインやセキュリティ対策のしおりにも関連情報が掲載されている。対策の全体像を確認したい場合は下記を参照してほしい。
現場目線の所感
「MLが検知する」と言われると、なんとなく安心してしまうのが正直なところだ。しかし情シスの立場で端末を何百台・何千台と管理していると、1台ずつの挙動を深く追える状況はほぼない。MLツールを「万能の盾」のように扱いたくなる気持ちはわかるが、今回の研究はそれが危ういと教えてくれる。攻撃者もMLの仕組みを理解した上で細工を加えている——そう意識するだけで、「ツールが検知しなかった＝安全」という思い込みを見直すきっかけになる。特にMDM製品の評価・選定時に「MLを使っているから安心」で話が止まらないよう、現場側から問いを立てていきたい。
査読前論文についての注記
本稿が参照したDroidBreaker論文（arXiv:2606.26707v1）は査読前のプレプリントであり、結果は今後の査読過程で修正・変更される可能性がある。1本の論文で特定のML検知製品の危険度を断定することは適切ではなく、研究の方向性と実務への示唆として受け取るにとどめてほしい。
まとめ
- MLベースのAndroidマルウェア検知は実用的に回避できる——DroidBreaker研究が機能を保ちながら商用スキャナを欺く攻撃を実証した（査読前）
- MLツール単独への過信は禁物——サイドローディング禁止・振る舞い監視・ネットワーク監視と組み合わせた多層防御が基本
- 「検知しなかった＝安全」は通用しない時代——MDM・MTD製品の評価では、ML検知の限界と更新頻度を必ず確認する
出典
- Christian Scano et al., “DroidBreaker: Practical and Functional Problem-Space Attacks on Machine-Learning Android Malware Detectors”, arXiv:2606.26707v1, 2026. https://arxiv.org/abs/2606.26707
