NadMesh：露出したAIサービスからクラウド鍵を刈り取るGo製ボットネットの現実

今日の深掘りポイント

• 「AIエンドポイント＝内向きサービス」という思い込みが最大の脆弱性になっています。ComfyUIやOllamaの“素のまま公開”は、環境変数に眠るAWSキーやKubernetesトークンを一網打尽にされます。
• NadMeshはスキャナでもエクスプロイトキットでもなく「鍵回収に最適化したボットネット」。目的が明確な分、運用の綻びに刺さる速度が速いです。
• 露出Docker APIやJenkinsコンソールといった「便利の裏側」に寄り添う攻撃面が主戦場です。日常の利便設定が、そのまま攻撃チェーンのレールになります。
• 指標的には新規性・即時性・行動可能性が高く、悲観寄りの評価にふさわしい事案です。対策は「棚卸し・遮断・ローテーション」を最優先に、攻撃面の台帳と短命認証への移行を並走させるのが現実解です。
• MITRE ATT&CKでの想定マッピングは、Initial Accessの露出サービス悪用から、Credential Accessの環境変数・ファイル窃取、CloudのValid Accounts、ContainersのDeploy Containerまで直線的につながります。

はじめに

生成AIの導入が爆発的に広がる一方で、推論用の軽量エンドポイントや可視化UIは「デフォルトで認証なし」「同一セグメント前提」という設計が少なくありません。NadMeshと名付けられたGo製ボットネットは、この隙を突き、インターネットに露出したComfyUIやOllama、さらにはDockerのリモートAPIやJenkinsのコンソールといった運用上の“近道”を足がかりに、環境変数や設定に眠るクラウド資格情報を収集します。

The Hacker Newsは、運用者ダッシュボードにおける観測値として、ユニークなAWSキーの収集が数千件規模、直近24時間でのデプロイ数が異常に多いと報じています。AI導入が生む新しい攻撃面が、国境や産業をまたいでクラウドの共通リスクへと変質する過程が、いま可視化されつつあると言えます。

本稿では、公開情報に基づく確度の高い事実を整理しつつ、CISO／SOC／Threat Intel視点での運用示唆と、MITRE ATT&CKに沿った脅威シナリオを提示します。一次レポートの詳細は現時点で限定的なため、一部は仮説であることを明示します。

深掘り詳細

事実の整理（確認できる範囲）

• NadMeshはGoで実装されたボットネットで、露出したAI関連サービス（ComfyUI、Ollamaなど）をスキャンし、環境変数や設定ファイルからAWSキーやKubernetesトークン等のクラウド資格情報を収集する、と報じられています。
• 攻撃は、認証が無効または不十分なサービス（DockerリモートAPI、Jenkinsコンソール等）も足掛かりにします。開発・実験系でありがちな「外部公開＋簡易運用」の組み合わせが狙われます。
• 研究者の観測として、運用者側ダッシュボードにおいてユニークなAWSキーが3,811件、過去24時間のデプロイが95,700件という規模感が示されています（いずれも報道ベース）。
• 出典（セカンダリ）：The Hacker News: New NadMesh Botnet Hunts Exposed AI Services for Cloud Keys

上記は現時点での公開報道に基づく事実関係です。一次の研究ブログやIoCの完全版は未確認のため、技術的詳細（C2手法、バイナリの持続化機構、ペイロード多様性など）は確証を置かずに踏み込みません。

編集部のインサイト（仮説を含む）

• 攻撃者の狙いの中心は「鍵の回収と再利用」です。資格情報は即金性・転売性が高く、クラウド横断で価値を持ちます。AIエンドポイントは「RCEの可否」以前に「鍵の近さ」で狙い目になります。環境変数、アプリ設定、ログ、コンテナのサービスアカウントトークンなど、開発便宜上“そこにある”秘密が最大のリターンです。
• 露出Docker API経由でのコンテナ展開は、最短で実行基盤を掌握できる手口です。ここから環境変数の覗き見、ボリューム経由のファイル秘匿情報の査収、ネットワーク越しのクラウドメタデータ問い合わせ（これは仮説）へと展開しやすいです。
• Jenkinsコンソールの露出は、スクリプト実行→環境変数・ビルドシークレット抽出→SCMトークンやCI/CD署名鍵の奪取へとつながりやすく、単なる「鍵泥棒」を超えたソフトウェアサプライチェーン汚染の入口になり得ます。
• 数値指標の示唆は明確です。いま起きているのは実験環境や個人管理の推論サーバ群が国際的な“鍵回収インフラ”に取り込まれていく現象です。新規性と即時性が高いほど「棚卸し→遮断→ローテーション」を先に回すのが合理的で、恒久対策（ゼロトラスト化、短命トークン化、秘密の外だし）は次のスプリントで確実に仕留めるべきです。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った仮説シナリオです。現時点で全てが確認済みではないため、あくまで想定経路として提示します。

• シナリオA：露出AIエンドポイントからの鍵回収 → クラウド横展開

  • Initial Access: Exploit Public-Facing Application（T1190）または External Remote Services（T1133）相当の露出インターフェース悪用
  • Execution: Command and Scripting Interpreter（T1059）によるAPI経由の任意操作（仮説）
  • Credential Access: Unsecured Credentials（環境変数 T1552.006、ファイル T1552.001）
  • Discovery: Cloud Service Discovery（T1526）
  • Defense Evasion/C2: Ingress Tool Transfer（T1105）、Exfiltration Over C2 Channel（T1041）
  • Credential Use: Valid Accounts（Cloud Accounts, T1078.004）
  • 影響: クラウド上でのリソース乗っ取り（Resource Hijacking, T1496）、データアクセス、コスト爆発

• シナリオB：露出Docker API → コンテナ展開 → 秘密窃取 → ホスト/クラウド侵害

  • Initial Access: Exploit Public-Facing Application（T1190）対Docker API
  • Containers: Deploy Container（T1610）、必要に応じてPrivilege濫用からEscape to Host（T1611, 仮説）
  • Credential Access: コンテナ内のサービスアカウントトークンやマウントボリュームからの秘匿情報取得（T1552系）
  • Lateral Movement: Remote Services（T1021）やCloud API経由での横展開（T1078.004）
  • 影響: K8sクラスター支配、CI/CD連鎖侵害、暗号資産マイニング

• シナリオC：Jenkinsコンソール露出 → ビルドシークレット奪取 → サプライチェーン汚染

  • Initial Access: Valid Accounts（管理者流出時, T1078）または公開コンソール悪用（T1190）
  • Execution: Command and Scripting Interpreter（T1059, Groovy 等）
  • Credential Access: Unsecured Credentials（T1552.*）
  • Impact: アーティファクト署名鍵・SCMトークン奪取を起点とした下流汚染（T1553 Code Signingの悪用等, 仮説）

現実の影響は次の通りです。

• クラウド費用・データ外部流出・業務停止の複合被害。特に短時間でのクレデンシャル悪用により、IR前に高額課金やデータ散逸が進むリスクが高いです。
• モデルやプロンプトログの漏洩。AI運用特有の入力データや推論結果は、しばしば機微情報を含み、法的・レピュテーションの負荷が大きいです。
• サプライチェーン波及。CI/CD・レジストリ・IaCテンプレートの鍵が引き抜かれた場合、二次被害の検出は困難になります。

セキュリティ担当者のアクション

緊急度が高いため、時間軸で優先順位を整理します。

• 直ちに（0〜72時間）

  • 露出棚卸しと遮断
    • 外部公開のComfyUI/Ollama、Docker API、Jenkins、K8sダッシュボード等を全社スキャンで抽出し、インターネット到達を遮断またはIP制限します。簡易でも良いので、逆プロキシ＋認証で守ります。
  • 資格情報のローテーション
    • 露出ホスト／コンテナで扱われた可能性のあるAWS/IAMキー、長寿命のクラウドアクセストークン、K8sサービスアカウントトークンを優先的に無効化・再発行します。併せてCloudTrailや同等の監査ログで直近アクセスを遡及確認します。
  • ハンティング
    • ログにおける不審パターン（例：Ollama/ComfyUIの未認証API多発、DockerリモートAPIへのPOST増加、Jenkinsスクリプトコンソール実行）を検索し、発見時は鍵ローテーションと併行して端末隔離を実施します。

• 1〜2週間

  • 秘密の扱いを“環境変数から卒業”
    • アプリやパイプラインの秘密はSecret Manager/KMS等に集約し、アプリはOIDCフェデレーション等の短命トークンで取得する設計に移行します。K8sはBound Service Account Token Volume（短命・監査可能）を利用し、古い長命トークンを廃止します。
  • クラウドの防御強化
    • IMDSv2必須化（AWS）、過大権限の見直し、SCP/条件付きポリシーでキー濫用の飛び地（全リージョン・全サービス）を狭めます。発見用にCanaryトークン（ハニートークン）を数点配置し、外部持ち出しを即検知します。
  • 運用ガードレール
    • 「AIエンドポイント公開チェックリスト」を作成し、公開前に自動検査（認証必須、TLS、CORS、管理UI遮断、デフォルトポート閉塞）を義務化します。シャドー運用を抑止するため、社内DNS/資産台帳と引き当てます。

• 継続対策（四半期サイクル）

  • 攻撃面管理
    • 攻撃面台帳（ASM）を維持し、開発部門・データサイエンス部門の検証環境まで可視化します。定期的に未認証UI・管理APIの暴露監査を回します。
  • 監視と検知の磨き込み
    • 典型的なTTPに対応するユースケースをSOCに実装します。
      • Initial Access: 露出サービスへのスキャン/POST急増の検知（レート・ASN相関）
      • Containers: 新規コンテナの異常展開（特に--privileged、ホストマウント、異常なイメージソース）
      • Credential Access: プロセスによる/proc/self/environ、サービスアカウントトークン、.aws/credentials等へのアクセス増加
      • Cloud: 新規リージョン・未知ASNからのAPIコール、未使用サービスの急な使用
  • テーブルトップ演習
    • 「露出AI→鍵流出→クラウド横展開」を想定したインシデント対応演習を年2回以上実施し、鍵ローテーションとビリング抑止の連携手順を整備します。

最後に、今回の事案は“ゼロデイ”ではなく“ゼロガード”の問題に近いです。生成AIのスピードに合わせて運用と設計のガードレールを引き直すことが、最短で最大のリスク低減につながります。AI導入は止めず、守りを進化させる——それがいま、最も合理的な選択肢です。

参考情報

• The Hacker News: New NadMesh Botnet Hunts Exposed AI Services for Cloud Keys（報道ベースの事実整理に利用しました）: https://thehackernews.com/2026/07/new-nadmesh-botnet-hunts-exposed-ai.html