IoTボットネット「Cling」は、オペレーターのコマンドをGoogleのSTUN応答に見せかけ、不正な通信を日常的なNAT越えトラフィックに紛れ込ませます。
10月1日に公開された調査報告は、インターネットに露出したネットワーク機器が悪用されている実態と、見慣れたインフラへの信頼を逆手に取るよう設計されたコマンドチャネルを明らかにしています。
研究者らがこのマルウェアを発見したのは、Realtek Jungle SDKの診断コンポーネント（通常はUDPServerとしてコンパイルされる）に存在するリモートコード実行の脆弱性「CVE-2021-35394」の悪用増加を調べていたときです。
CVEデータベースへのアクセス
攻撃者は、orf;で始まるUDPペイロードを送信します。その後ろにシェルコマンドを続け、BusyBoxのwgetでボットをダウンロードして実行させていました。
分析は主にMIPS向けのサンプルを対象に行われました。このサンプルの感染拡大エンジンには、CVE-2014-8361、CVE-2023-26801、CVE-2024-3721、CVE-2025-34037、CVE-2016-10372、CVE-2023-41011、CVE-2016-20016のエクスプロイトも含まれています。対象はRealtekのコンポーネント、LB-LINK、Linksys、Eir、FiberHome、China Mobileの各ルーター、さらにTBKおよびMVPowerのDVRに及びます。
Clingは自身を/root/.clingと/usr/local/bin/.clingにコピーし、/etc/inittab、/etc/init.d/rcS、/etc/rc.d/rc.bootに実行エントリを追記します。
さらにwgetを自身の実行ファイルに置き換えます。正規のバイナリはwget.rとして残し、その場所をwget.pに記録します。
以降にwgetが呼び出されるたびにマルウェアが再起動し、引数は元のユーティリティに受け渡されます。
STUNは、エンドポイントが自身の公開アドレスとNATでマッピングされたポートを調べるための仕組みです。会議システムやブラウザ通信で広く使われているため、Clingが繰り返しUDP通信を行っても不自然に見えにくくなります。
感染デバイスは約5秒ごとに、ハードコードされた13台のSTUNサーバーへBinding Requestを送信します。
準拠した実装とは異なり、これらのリクエストのトランザクションIDはすべてゼロです。ボットはマッピングされたポートを記録し、そのポートと感染手法を示すタグを含む独自の登録データグラムを送信します。
オペレーターのコマンドは、STUNの12バイトのトランザクションIDフィールドに格納されます。本来はランダムであるはずの識別子を、命令とパラメーターの伝達に転用しているのです。
対応する機能は、ペイロードの実行、スキャンとエクスプロイト、TCPトンネリング、プロキシ中継、DoS攻撃（フラッド）などです。
Nozomi Networks Labsは、インターネットに露出したIoT機器やネットワーク機器を悪用するボットネットを特定し、「Cling」と名付けました。
研究者らは、145.249.115[.]184が規格に適合しない応答を返したことから、オペレーターが管理しているか、協力関係にあるインフラだと特定しました。
Cling IoTボットネット
テスト用クライアントで、サーバーごとに異なるポート群を通知したところ、その後のコマンドは、不審なホストだけに伝えたポートに届きました。
この違いは運用上重要です。リストにあるSTUNサーバーの大半は評判に問題がなく、公開ディレクトリにも掲載されています。ボットの設定に含まれているからといって、悪意ある所有者がいるとは断定できません。
アナリストは、接触先のエンドポイントをすべて敵対的なインフラと決めつける前に、プロトコルの異常とデバイスの挙動を突き合わせて確認する必要があります。
コマンドを運ぶパケットは、stun.l.google.comに関連付けられた74.125.250[.]129から送信されたように見えました。
Nozomiは、送信元アドレスの偽装が最も可能性の高い説明だと評価しています。正規のSTUN応答とコマンドパケットとの間で、TTLに一貫した差が見られることが根拠です。
ただし、Googleのインフラが侵害されたことを示す証拠はありません。
数日間の監視で、オペレーターは感染拡大のタスクとフラッド攻撃の指示を出していました。標的は韓国のISP、シカゴ大学のクラスター、2台のMinecraftサーバーです。
これらの観測結果は、攻撃指示を受信したことを示すものであり、サービス障害が独立して確認されたわけではありません。
防御側は、IPレピュテーションに頼らず、STUNの仕様に照らして通信を検査すべきです。
ハンティングの手がかりとして有効なのは、ゼロIDのBinding Requestの反復、STUNエンドポイントに届くSTUNではない登録ペイロード、組み込み機器から出る会議通信のような想定外のトラフィックです。
ホストの調査では、.clingのコピー、改ざんされた初期化スクリプト、wget.rやwget.pの痕跡を確認してください。
Nozomiの技術レポートには、侵害指標（IoC）、YARAルール、ATT&CKマッピングが掲載されており、検知エンジニアリングに活用できます。
組織は、該当デバイスにパッチを適用し、不要なインターネット公開をやめ、受信アクセスを制限し、更新できない機器はセグメント化する必要があります。
Clingから得られる防御上の最大の教訓は、プロトコルのフィールドや送信元アドレスが意図的に操作されれば、信頼できそうに見えるトラフィックでも攻撃者の指示を運びうるということです。
MTTRを21分短縮し、被害が出る前にサイバー脅威を阻止。ANY.RUNのSandboxをSOCに導入。
翻訳元: https://gbhackers.com/cling-iot-botnet/
