Android TV BOXを乗っ取るボットネット「Kimwolf v7」— 本物そっくりのHTTP/2攻撃とブロックチェーンC2（Unit 42分析）

Palo Alto Networksの脅威分析チーム Unit 42 は2026年8月11日、Android端末向けボットネット 「Kimwolf」 の新しい亜種 v7 の分析結果を公開した。Android TV BOX（テレビ接続型の小型端末）やセットトップボックスを主な標的にし、ブラウザーの指紋情報を完全に偽装したHTTP/2型のDDoS攻撃と、ブロックチェーンとTorを組み合わせたC2（指令サーバー）基盤を持つことが特徴だ。

Kimwolfとは

Kimwolfは2024年8月から活動しているボットネットだ。同じ運営者による別系統の亜種「AISURU」も含めて追跡されている。当初はLinux系のIoT機器を狙っていたが、2025年8月ごろからAndroid TV BOXを標的にするようになったという。Android向けをKimwolf、Linux向けをAISURUとして、同じ運営者が2つのコードベースを使い分けている。

感染経路は、認証なしで公開されたADB（Android Debug Bridge）だ。ADBはAndroid端末を開発・管理するための標準機能で、ポート5555で待ち受ける。一部のAndroid TV BOXは初期状態でADBが有効になっており、攻撃者は住宅用プロキシサービスを経由してローカルネットワークに入り込み、認証なしでマルウェアをインストールできる。

今回のv7は、Unit 42が2026年2月3日に発見した。XLab、Synthient、Infoblox、Cloudflareなどが公開した先行情報を手がかりにした脅威ハンティングの結果だという。

ブラウザーそっくりのHTTP/2攻撃

v7の最大の目玉は、HTTP/2による新しいDDoS攻撃機能だ。マルウェアはHTTP/2ライブラリ（nghttp2）を使って攻撃パケットを作り、ブラウザーの指紋情報（フィンガープリント）を構成するヘッダーまで再現する。

従来のHTTP/2フラッドは、ヘッダーの並びや設定パラメータの「不自然さ」で攻撃と判別できた。しかしv7は正常なブラウザーの挙動を模倣するため、攻撃トラフィックと本物のブラウジングを見分けるのが難しくなる。アプリケーション層のDDoS対策をすり抜ける可能性が高い。

v7のDDoS機能はレイヤー3〜7にまたがる15種類に整理されている（UDPフラッド、TCP系、HTTP/2フラッドなど）。旧バージョンにあったスキャン・脆弱性悪用・ブルートフォース機能はすべて削除された。攻撃者は「感染の拡大」と「DDoS攻撃」を分離し、外部のローダーに感染拡大を任せる設計に変えたようだ。ARM NEON（SIMD命令）を使ったUDPチェックサムの高速化も実装され、Android TV BOXに載っているARMプロセッサの性能を引き出している。

3段構えのC2基盤

v7のもう一つの特徴は、止めにくいC2基盤だ。KimwolfのC2は2025年12月に**2回のドメイン停止（テイクダウン）**を経験しており、v7はその教訓を反映している。

C2アドレスの解決は次の3層で構成される。

1. イーサリアムのENSドメイン — マルウェア本体に5つの公開イーサリアムRPCエンドポイントが平文で埋め込まれている。これらは正規の公開サービスだが、マルウェアはこれを悪用してENS（イーサリアムのブロックチェーン上の名前解決システム）のレコードを照会し、C2アドレスを得る。照会のたびに疑似乱数でエンドポイントをシャッフルするため、遮断は難しい
2. Torの.onionフォールバック — ENSでの解決に失敗すると、ハードコードされたTor v3の.onionアドレスに接続する
3. ローカルプロキシ — すべてのC2通信は127.0.0.1:23075のローカルプロキシを経由する。通常のインターネット（クリヤネット）とTorのどちらに流すかを柔軟に切り替えられる。プロキシ部分はボット本体とは独立して更新できる設計だ

さらにUnit 42は、6つ目のRPCエンドポイント「eth.rpcuniverse[.]com」は攻撃者の管理下にある可能性が高い（中程度の確信度）と評価している。専用の単一テナントホスティングを使い、登録時期がKimwolfの活動時期と一致し、Kimwolfのバイナリにだけ現れることなどが理由だ。なお、5つの公開エンドポイントは正規サービスなので、遮断ではなく「IoT機器からの不審なイーサリアムRPC通信」の監視をUnit 42は勧めている。

ロシア拠点のC2インフラ

C2サーバーの解析では、22のIPアドレスが同一のSSHホスト鍵を共有していることが判明した。最初のホストは2025年12月18日に確認され、以降6週間かけて順次追加され、最後の追加は2026年1月31日。22ホストはすべて**AS202799（ロシア・サンクトペテルブルク）**に所在する。

また、Android用APK（アプリのパッケージ）は「SystemService」というシステムサービスを装い、実行時にroot権限を確認して内蔵のELFペイロードを実行する。プロセス名は「netd_service」や「TVHelper」に偽装され、正規のAndroidプロセスやTVヘルパーサービスのように見せかける。

日本での注意点

Android TV BOXは、日本でもテレビやモニターに接続して動画配信などに使うユーザーが増えている。こうした端末は「家電」として扱われがちで、ファームウェアの更新がされず、ADBが有効なままネットワークに置かれるケースが多い。

特に注意したいのは、業務ネットワークへの接続だ。在宅勤務のネットワークやオフィスの会議室のディスプレイにAndroid TV BOXが接続されている場合、それがボットネットの一員になると、企業ネットワークからDDoS攻撃の踏み台にされるだけでなく、内部ネットワークへの足がかりにされるリスクもある。

今何をすべきか

1. Android TV BOXを「信頼しない端末」として扱う — 業務ネットワークとは別のVLAN（ネットワークの分割）に置き、企業ネットワークへの直接アクセスを遮断する
2. ADBを無効化する — 使わないのであればADBを無効にし、使う場合もUSB接続時のみに制限する（ネットワーク経由のADB＝ポート5555を開けたままにしない）。これがこのボットネットの最大の感染経路を断つことになる
3. ファームウェアを最新に保つ — Android TV BOXのメーカー提供アップデートを定期的に確認・適用する
4. 不審な通信を監視する — IoT機器からの異常なHTTP/2通信やイーサリアムRPCエンドポイントへのアクセス、Torへの接続がないかを監視する

ボットネットは「高性能なマルウェア」だけで成り立っているわけではない。初期状態で公開された管理機能（ADB）と、放置されたIoT機器が土台になっている。Kimwolf v7のC2基盤は非常に頑丈だが、感染経路の封鎖は比較的単純だ。まずはネットワークの棚卸しから始めてほしい。

出典: Unit 42 — Kimwolf v7: An Evolution of the Kimwolf Botnet