クローボットからオープンクローへ:自動化がデジタル裏口となる時

2026年1月29日
Lucie Cardiet
サイバー脅威リサーチマネージャー
クローボットからオープンクローへ:自動化がデジタル裏口となる時

本記事の初版公開後、旧称ClawdbotおよびMoltbotとして知られていたプロジェクトは再ブランド化を実施し、 現在はOpenClawと命名されている。ここで論じた基盤となるエージェント型アーキテクチャとセキュリティ上の考慮事項は、新名称のもとでも引き続き関連性を保っている。

---

Clawdbotは2026年初頭、最も話題を集めたオープンソースAIエージェントの一つとして 登場した。単なるチャットボットだったからではなく、多くのツールが踏み込めなかった領域に踏み込んだからだ。大規模言語モデルと、オペレーティングシステム、ファイル、認証情報、メッセージングプラットフォームへの直接的かつ自律的なアクセスを組み合わせたのである。

しかし、ユーザーが生産性で得たものは、攻撃者にとって新たな攻撃対象領域として得たものとなった。

そして、商標問題からクローボットがモルトボットへ改名した際、リスクプロファイルは再び変化した。根本的なエージェントが変わったからではなく、急激な人気が運用上の未準備と衝突したためだ。リポジトリやドメイン、ソーシャルアカウントの名称変更を急ぐ中で、所有権の空白が生じた。攻撃者は管理者を凌駕する速さで動き、放棄されたアイデンティティを乗っ取り、コミュニティの信頼を数秒で悪用した。

プロジェクトがOpenClawへ移行したことに伴い、セキュリティファースト設計への注力が再強化され、自律システムアクセスに伴うリスクに関する警告が明確化された。これは、初期導入者が露呈した強化のギャップを、現在では保守担当者が認識していることを示している。

現在、このツールの爆発的な普及は攻撃者に有利に働いている。急増するユーザー層は、セキュリティ上の疑問が完全に理解される前に、このツールを試用し、複製し、統合し、広範な権限で実行しようと躍起になっている。高い特権、急速な普及、一時的なアイデンティティの混乱という組み合わせが、もともと機密性の高い自動化ツールを極めて魅力的な標的に変えている。

ピーター・スタインバーガーのXへの投稿のスクリーンショット
Clawdbot(現在は Moltbot)は、Peter Steinberger によって作成されました (@steipete)によって作成されました。彼は、このプロジェクトを、3 ヶ月も経っていない、未完成の若い趣味のプロジェクトであり、技術に詳しくないユーザー向けではないと繰り返し説明しています。これは、実験的な試みとして作成されたものであり、堅牢なエンタープライズ製品として動作するようには設計されていません。

Clawdbotはデフォルトで公開されるよう設計されていません。サーバーの堅牢化、リバースプロキシの信頼境界の理解、最小権限制御による高権限サービスの運用に不安がある場合、パブリックVPSへのデプロイは推奨されません。

このプロジェクトは、多くのユーザーが過小評価している 運用成熟度 前提としており、これまでに見られた実世界の障害の大半は、脆弱性の悪用ではなく設定ミスに起因している。

ターミナルに表示されたClawdbotのインストール画面のスクリーンショット
インストール時、Clawdbotはこのリスクを明示します。ユーザーには、エージェントがコマンドの実行、ファイルへのアクセス、有効化されたツール全体での動作が可能であることが明確に警告表示され、続行するには明示的に同意する必要があります。「いいえ」を選択するとインストールは完全に停止します。

これは失敗したAIプロジェクトの話ではない。信頼と自動化とアイデンティティがセキュリティ対策よりも速く進化する中で、現代の攻撃がどのように形成されるかの物語である。

クローボットがなぜこれほど迅速に攻撃者を引き寄せるのかを理解するには、エージェントが実際に展開された後の動作を検証することが有効である。

TL;DR

  • Moltbotは、公開または誤設定された場合、自動化を特権の高い攻撃対象領域に変えてしまう
  • 現実世界の侵害の大半は、ゼロデイ攻撃ではなく設定ミスや信頼関係の悪用から生じている。
  • 一度侵害されると、このエージェントは認証情報の窃取、横方向の移動、ランサムウェアを可能にする。
  • 自律型AIエージェントは、生産性向上ツールではなく、特権的なインフラとして扱わなければならない。
  • 保護と監視ができない場合は 公開しないでください。

本記事の残りの部分では、Moltbotがなぜこれほど 短期間で魅力的な標的 となったのか、攻撃者が実際にどのように悪用しているのか、そしてこれがエージェント型AIセキュリティの将来に何を示唆しているのかを解説する。運用上のガイダンスを求める読者は、終盤付近の強化策のセクションへ直接進むことができる。

永続的な影のスーパーユーザーとしてのAIエージェント

Clawdbotは、ユーザーが管理するインフラストラクチャ、ノートパソコン、ホームサーバー、クラウドインスタンス、さらにはシングルボードコンピュータ上で動作するよう設計されています。シェルコマンドの実行、ファイルの読み書き、ウェブの閲覧、メールやチャットメッセージの送信、セッションをまたいだ永続的なメモリの維持が可能です。 実際には、APIキーやOAuthトークン、チャット認証情報を保持し、時にはルートレベルのアクセス権を持つ、特権の高い自動化レイヤーとして機能します。この設計により、複数の信頼境界が単一システムに統合されます。メッセージングプラットフォーム、ローカルOS、クラウドAPI、サードパーティツールがすべて、一つの自律エージェントを通じて収束します。一度デプロイされると、Clawdbotは単なるアプリケーションではなく、環境のセキュリティ基盤の一部となります。

モルトボットの機能のスクリーンショット
ソース: モルトボット

攻撃者の視点から見れば、これは理想的な状況だ。エージェントを一度侵害すれば、そのエージェントがアクセス可能なすべてのリソースを、環境を跨いで継承できる。

そのレベルのアクセス権が存在すれば、攻撃者は新たな手法を必要とせず、はるかに高性能な仲介者を通じて既知の手法を再利用するだけで済む。

攻撃者が実際にClawdbotを悪用する方法

クローボット(現モルトボット)が展開されれば、問題は悪用されるかどうかではなく、どのように悪用されるかとなる。設定ミスによる情報漏洩や サプライチェーン攻撃といった手法は既に報告されている一方、プロンプト注入のような手法は研究で十分に立証されており、エージェントが信頼できないコンテンツを読み取りツールを実行できる環境下では現実的な脅威となる。

初期アクセス:エージェントが侵入経路となる場合

Clawdbotが侵害される最も一般的な方法は、巧妙なエクスプロイトではなく、単純な露出によるものです。コントロールUIはローカルアクセスを前提とした管理インターフェースです。実際には、設定ミスや開いたポート、安全でないプロキシ設定により、一部のユーザーが誤ってインターネットからアクセス可能にしてしまうケースがあります。

その場合、ローカル管理ダッシュボードがリモートコントロールパネルのように動作し始める可能性があります

混乱の一因は、この言葉が exposed という語の用法に起因している。実際には、意味のある差異が存在する:

  • インターネット向け:公開IPアドレスとポートでアクセス可能。
  • フィンガープリント:認証が有効であっても、HTTPレスポンスがMoltbotまたはClawdbotのシグネチャと一致するため、ShodanやCensysによって検出可能。
  • 認証されていない、またはバイパスされている:有効なペアリングや認証情報なしに制御UIにアクセス可能であり、多くの場合設定ミスが原因である。これは危険なケースである。

この区別は重要です。管理インターフェースがパブリックインターネットからアクセス可能になると、発見が容易になりますShodanのような検索エンジンはこれらのシステムを素早く発見し、単一の設定ミスを広範な問題へと発展させかねません。

「Clawdbot」クエリに対する検索結果を表示したShodanインターフェースのスクリーンショット
Shodanで多数のClawdbot結果が表示されたスクリーンショット。出典: Shodan.io

多数のクローボット結果を示す公開スクリーンショットは誤解を招く恐れがあります。多くは可視化されているものの保護された状態のシステムを表しています。真のリスクは、認証が欠如しているか無効な少数のケースに潜んでいます。

そのような状況では、コントロールUIがパブリックインターネットからアクセス可能となり、 攻撃者はエージェントの設定内容に応じて、設定データの閲覧、会話履歴へのアクセス、またはコマンドの実行が可能となる可能性があります。

クローボットのUIとソースコードのスクリーンショット
露出状態のクローボット制御UIのスクリーンショット。出典: X

ユーザーが認証が有効化されていると信じていても、安全でないデフォルト設定やプロキシの誤設定により、攻撃者は認証を完全に回避できる。zero-day 。単一のヘッダー書き換え転送ルールでさえ、信頼されたアクセスと信頼されていないアクセスの境界を崩壊させ得る。一度侵入すれば、攻撃者はエージェントが実行可能なすべての権限を継承する。

すべての初期アクセスがネットワークへの露出や設定ミスを必要とするわけではない。

ソーシャルエンジニアリングとプロンプトインジェクション

Clawdbotがメール、チャットメッセージ、文書を読み取る能力は、ペイロードがマルウェアではなく言語である新たな攻撃対象領域を生み出します。 マルウェア。

プロンプト注入は研究および実用的なエージェント設定において実証されている:巧妙に作成されたメッセージは、攻撃者が直接ホストに触れることなくとも、エージェントを誘導して機密データの漏洩や意図しない行動を実行させることがある。

Moltbotにおける悪意のあるプロンプト注入コマンドに関するReddit投稿のスクリーンショット
悪意のあるMoltbot「スキル」が公開リポジトリに公開され、便利なツールとして提示されていたことを示すReddit投稿のスクリーンショット。ユーザーにターミナルにコマンドをコピー&ペーストするよう指示していた。この指示に従った者は、知らずに自身のマシン上でリモートスクリプトを実行することになる。出典: Reddit

防御は「バグの修正」というより、エージェントの動作範囲の制限通信可能な対象の限定、そして信頼できないコンテンツの処理方法の制御に重点が置かれている。

攻撃者がホストに足場を築いた場合、Clawdbotのローカル設計により、より静かな第二の乗っ取り経路が形成される

マルウェア Clawdbotデータを標的とする

エンドポイント マルウェア マルウェアや情報窃取型マルウェアは、エージェントの展開から利益を得るためにClawdbot固有のエクスプロイトを必要としません 。トークン、OAuthアーティファクト、またはエージェントの状態がローカルに保存されている場合、特に平文で保存されている場合、通常のエンドポイント侵害がエスカレートし、エージェントおよびそれがアクセス可能なすべての接続サービスの乗っ取りにつながる可能性があります。

複数の情報窃取型マルウェアおよび脅威インテリジェンス報告書が、認証情報窃取型マルウェアについて言及している マルウェア がローカルアプリ/設定データを収集する事例を扱っており、その範囲や詳細は時期によって異なる。スクリーンショット出典: HudsonRock

他のケースでは、攻撃者はホストに直接触れることはなく、信頼された拡張機能や統合を通じて侵入します。

サプライチェーン悪用、プラグインおよび悪意のある拡張機能

Clawdbotのプラグインモデルは、新たな初期アクセスベクトルを導入する。拡張機能はエージェントと同じマシン上でコードとして実行され、その権限を継承する。悪意のあるプラグイン、あるいは侵害された正規のプラグインは即時のリモートコード実行として機能する。エージェントが配信メカニズムとなる。

中核ソフトウェア以外にも、攻撃者は周辺エコシステムを悪用している。最近では偽のClawdbot VS Code拡張機能がScreenConnectリモートアクセストロイの木馬をインストールするために使用され、プロジェクト名に対する開発者の信頼を悪用して完全なリモート制御を実現した。この拡張機能は正当に見え、適切なブランディングを施され、ソフトウェアの脆弱性ではなくタイミングと名称認知に依存していた。

偽のClawdBot拡張機能。出典: 合気道

この種の攻撃はブランド変更時に効果を高める。プロジェクト名、リポジトリ、ドメインが急変すると、攻撃者は混乱に乗じて正規に見せかけた類似リポジトリや拡張機能を公開する。コードレビューが行われる前に侵害が発生することが多く、名称とタイミングに基づいて信頼が前提とされるためである。

ここでの防御策は、パッチ適用よりも本人確認に重点を置きます。ブランド変更後は、インストールを公式のGitHub組織およびプロジェクトドメインに限定すべきです新規作成またはスポンサー付きリポジトリは特に厳重な監視が必要であり、プラグインやスキルは厳選された許可リストに制限されるべきです

開発者ツールについても同様です。エディター拡張機能については、発行元を確認し、更新履歴と更新頻度を検証し、利用可能な場合はハッシュ値や署名をチェックしてください。このエコシステムにおいて、サプライチェーンの信頼性はセキュリティ境界の一部です。

悪意のある拡張機能がインストールされると、それ以上の攻撃手段は不要となり、即座に制御が確立される

指揮統制:エージェントをC2チャネルに変える

攻撃者がコントロールUIやツールを実行可能なチャネルへのアクセス権を取得した場合、Clawdbot自体がコマンドアンドコントロールフレームワークとして機能します。制御インターフェースやAPIを通じて、攻撃者はシェルコマンドを発行し、出力を収集し、対話的に操作できます。リスクはMoltbotが単独で魔法のようにセキュリティを破ることではなく、侵害されたエージェントが既に実行権限、永続性、通信経路を組み込まれている点にあります。

Clawdbotが様々なAPIキーを平文でダンプしているスクリーンショット。出典: X

正当な統合の悪用

Clawdbotは、正当な認証情報を使用してSlack、Telegram、メール、その他のプラットフォームを通じてメッセージを送信できます。攻撃者はこれらの連携機能を悪用し、データを不正に流出させたり指示を受け取ったりすることができ、通常のトラフィックに完全に溶け込みます。検知の観点から見ると、これはC2トラフィックではなく、想定される自動化動作のように見えます。

認知層における中間者攻撃

攻撃者がエージェントの設定、プロンプト、または保存されたメモリ(例えばファイルシステムへのアクセス権を取得した後など)を変更できる場合、ユーザーに表示される内容やエージェントの動作に影響を与えようと試みることが可能です。

実際には、要約の操作アラートの抑制、あるいは後で発動する隠された指示の挿入などが考えられる。これは、適切に隔離された環境における保証された機能ではなく、侵害された場合の潜在的な結果として扱うのが最善である。

エージェントの制御は、従来型の特権境界も崩壊させる。

特権昇格と認証情報の悪用

Clawdbotが標準ユーザーとして実行される場合、攻撃者は従来の権限昇格手法を実行するためにこれを利用できる。多くの導入環境では、特にコンテナ化環境やシングルユーザー環境において、エージェントは既に昇格された権限で実行されているため、権限昇格は不要である。

ソース:X

Clawdbotは設計上、認証情報を一元管理します。APIキー、OAuthトークン、チャット認証情報、クラウドシークレット、場合によってはVPNアクセス権限まで、すべてが一箇所に集約されます。これらの認証情報が取得されると、 攻撃者はユーザーをなりすまし、クラウドリソースにアクセスし、 元のシステムに再び触れることなく横方向に移動することが 可能になります

ハイブリッド環境では、この影響は倍増する。ノートPC上で動作する侵害されたエージェントは、企業のSaaSアクセスを危険に晒す可能性がある。クラウド上で動作するエージェントは、攻撃者がインフラを構築したり、データストアにアクセスしたり、CI/CDパイプラインを改ざんしたりすることを可能にするIAM権限を保持しているかもしれない。エージェントは、本来直接接続されることを想定されていなかった環境間の架け橋となる。

アクセスを確保した攻撃者は、気づかれずにその場に留まることに注力する。

持続性:エージェントが攻撃者を記憶する場合

エージェントは長期的な状態をディスクに保持することが多いため、侵害されたホストはその状態を永続化に利用できます。攻撃者がエージェントのメモリや設定への書き込み権限を得た場合、再起動後も残存する 指示や痕跡を残しシステムが再構築されシークレットが更新されるまで有害な動作を継続させることが可能です

クローボットは継続的に動作し、スケジュールに基づいてタスクを実行するよう設計されているため、攻撃者は繰り返し実行されるアクションを埋め込むことが可能です。データの外部流出、システム列挙、または外部通信が、追加の操作なしに自動的にトリガーされる可能性があります

シェルアクセスにより、攻撃者は従来の永続化手法スケジュールされたタスク、起動スクリプト追加のバックドアなど)に頼ることも可能だ。違いは、Clawdbotがこうした動作を正当な自動化処理の背後に隠すことが多く、フォレンジック分析をより困難にする点にある。

侵害されたエージェントが他のすべてへの橋渡しとして使われる時、真の被害が始まる。

横方向の動きと広範な影響

単一の侵害されたエージェントから、攻撃者は内部ネットワークをスキャンし、認証情報を再利用し、横方向に移動できます。また、Clawdbotは個人、企業、クラウドのコンテキストにまたがることが多いため、いずれかの領域での侵害は、しばしばこれら3つすべてへの侵害につながります

盗まれたトークンにより、攻撃者はSaaSプラットフォーム社内コラボレーションツール、クラウド環境へ 侵入経路を拡大できる。攻撃者はユーザーをなりすまし、信頼されたメッセージを送信し、防御側が攻撃経路として監視しないソーシャルチャネルを通じてさらなるアクセス権を拡散させることが可能となる。

最悪の場合、攻撃者はClawdbotを利用してランサムウェアを展開したり、データを破壊したり、業務を妨害したりできる。エージェントは既にファイルへのアクセス権、実行権限、通信経路を保持している。あらゆる破壊行為は、単なるアシスタントが遂行すべき「タスク」に過ぎない

これらの行動を総合すると、現代の攻撃が展開される方法におけるより広範な変化が明らかになる。

自動化が攻撃対象領域となる時

Clawdbotは自律型AIの約束とリスクの両方を体現している。強力な自動化を実現する一方で、その自律性こそが高価値な攻撃対象領域を生み出す。公開されたインターフェース、悪意ある入力、そして適応された マルウェア により、攻撃者はエージェントをコマンド&コントロール、特権乱用、持続的侵入、横方向移動のために悪用できます。これらの手法は従来の侵入経路とAI主導 との境界を曖昧にし、個人システム、クラウド環境、企業ネットワークにわたり影響を及ぼします。侵害されたエージェントは、接続先に応じて標的型データ窃取から大規模ランサムウェア攻撃まであらゆる行為を可能にします。

Clawdbot/Moltbotは、特権的なインフラと同様に扱うべきであり、 気軽な週末の実験として扱うべき ではありませんこれは認証情報を一元管理し、アカウントやデバイスを跨いだアクションを実行できるためです。強力な認証、ネットワーク露出の制限、シークレット情報の慎重な取り扱いは最低限の要件です。 組織はこれらのエージェントの実行場所を可視化し、セグメンテーションを適用し、不審な動作(許可されていない操作や予期せぬ通信など)を監視する必要があります。プロンプト注入はさらなるリスク要因であり、エージェントの動作自体を監視しない限り、悪用が見逃される可能性があります。

Clawdbotは環境内で影のスーパーユーザーのように振る舞う。自律エージェントが普及するにつれ、教訓は明快だ:制御なき能力は危険に晒される。攻撃者に先んじてこれらのエージェントを保護する責任は、今やユーザーとセキュリティチームにある。

この変化を理解することは、最初のステップに過ぎない。リスクを低減するには、Moltbotを他の特権システムと同様に扱い露出アイデンティティ、実行、監視の周りに 意図的な制御を適用する必要がある

Moltbotを実行する際のリスク低減方法

自律エージェントは優雅に失敗しない。広範なアクセス権限で展開されると、小さな設定ミスが過大な影響を及ぼす可能性がある。強化の目的はMoltbotを「安全」にすることではなく、被害範囲を限定し、露出を減らし、悪用を検知可能にすることである。

1. ベースライン強化チェックリスト

エリア 安全なデフォルト なぜそれが重要なのか
コントロールUIへのアクセス ローカルホストにバインドする。SSHトンネルまたはVPN経由でのみアクセス可能。デフォルトでは決して公開しない。 インターネット上での発見を防ぎ、ブルートフォース攻撃や認証バイパスのリスクを低減します。
リバースプロキシ 信頼できるプロキシと実際のクライアントIPを設定してください。プロキシ経由のトラフィックをすべてローカルホストとして扱わないでください。 認証境界を崩壊させる「リモートがローカルに見える」という誤りを回避します。
チャンネル(Telegram、Discordなど) ユーザー、サーバー、チャンネルに対するデフォルト拒否の許可リスト。公開ダイレクトメッセージを無効化。 チャンネルが高特権アクションのリモートトリガーとなることを防止します。
ツールとOSの権限 非rootユーザーで実行。特権Dockerを禁止。ホストマウントを禁止。シェル操作、ファイル書き込み、ブラウザ操作には確認を要求。 エージェントが騙された場合、またはUIやチャネルが不正利用された場合に、爆発範囲を制限する。

2. ホストとインフラストラクチャの分離

  • コントロールUIをパブリックインターネットに公開しないでください。TailscaleやWireGuardなどのVPN、またはローカルホストへのSSHトンネリングを優先してください。エージェントを本番ワークロードから分離してください。
  • バックエンドサービス、データベース、または個人ファイルをホストしている同じVPS上でMoltbotを実行しないでください。
  • あらゆるVPSでSSHを強化する。パスワード認証とrootログインを無効化し、鍵認証のみを使用する。ファイアウォールルールとレート制限、またはfail2banを有効化する。
  • エージェントを非rootユーザーとして実行してください。特権コンテナの使用を避け、ホストファイルシステムやDockerソケットをマウントしないでください。
  • 定期的にパッチを適用する。OSの更新を適用し、コンテナイメージを更新し、長期使用の鍵をローテーションする。

3. 制御UIおよびゲートウェイ設定

  • リモートアクセスが厳密に必要な場合を除き、ゲートウェイとコントロールUIを127.0.0.1にバインドしてください。
  • 制御UI認証を有効化し、リバースプロキシ設定を確認して、リモートクライアントがローカルホストとして扱われないようにする。
  • 新しいデバイスのペアリング、設定変更、およびツール実行イベントをログに記録し、アラートを発行する。

4. チャネルと統合

  • ボットにメッセージを送信できるユーザーを厳格な許可リストで管理してください。デフォルトは拒否設定とするべきです。
  • シェルアクセス、ファイル書き込み、ブラウザ自動化などの高リスクなツールは、絶対に必要な場合を除き無効化または制限してください。
  • 統合には、最小権限のスコープを持つ別々のアカウントを使用してください。例えば、専用のGmailアカウント、制限付きSlackボットスコープ、限定されたGitHubトークンなどです。
  • シグナルデバイスのリンクQRコードとURIはパスワードと同様に扱ってください。ペアリング情報を世界から閲覧可能な場所に放置せず、漏洩した場合は再設定または再リンクを行ってください。
  • サービスごとのボットアカウントを優先し、公開範囲を制限する。パブリックDiscordサーバーは避け、ダイレクトメッセージは許可リストに限定する。

5. 秘密とデータ処理

ホスト上で監査すべき一般的なデフォルトの場所です。機密扱いし、権限を厳重に制限してください:

エリア 主要な操作
ホストとインフラストラクチャの分離
  • コントロールUIをパブリックインターネットに公開しないでください。VPN(Tailscale、WireGuard)またはSSHトンネリングによるlocalhost接続を推奨します。
  • エージェントを本番環境のワークロードから分離してください。Moltbotをバックエンドサービス、データベース、または個人ファイルと同じVPS上で実行しないでください。
  • あらゆるVPSでSSHを強化する。パスワード認証とrootログインを無効化し、鍵認証のみを使用する。さらにファイアウォールルールとレート制限、またはfail2banを有効化する。
  • エージェントを非rootユーザーとして実行してください。特権コンテナの使用を避け、ホストファイルシステムやDockerソケットをマウントしないでください。
  • 定期的にパッチを適用する。OSの更新を適用し、コンテナイメージを更新し、長期使用の鍵をローテーションする。
制御UIおよびゲートウェイ設定
  • リモートアクセスが厳密に必要な場合を除き、ゲートウェイとコントロールUIを127.0.0.1にバインドしてください。
  • 制御UI認証を有効化し、リバースプロキシ設定を確認して、リモートクライアントがローカルホストとして扱われないようにする。
  • 新しいデバイスのペアリング、設定変更、およびツール実行イベントをログに記録し、アラートを発行する。
チャネルと統合
  • ボットにメッセージを送信できるユーザーを厳格な許可リストで管理してください。デフォルトは拒否設定とするべきです。
  • シェルアクセス、ファイル書き込み、ブラウザ自動化などの高リスクなツールは、必要がない限り無効化または制限してください。
  • 統合には、最小権限のスコープを持つ別々のアカウントを使用してください。例えば、専用のGmailアカウントや制限付きSlackボットスコープなどです。
  • シグナルデバイスのリンクQRコードとURIはパスワードと同様に扱ってください。漏洩した場合は再発行または再リンクしてください。
  • サービスごとのボットアカウントを優先してください。パブリックDiscordサーバーは避け、ダイレクトメッセージは許可リストに制限してください。
秘密とデータ処理 デフォルトのエージェントパスと設定ファイルは機密扱いとする。ファイル権限を厳格に制限し、可能な限りストレージを暗号化し、トークンは漏洩後に積極的にローテーションし、ログと会話履歴の保持期間を制限する。

追加の制御:

  • エージェントを機密情報管理者のように扱う。可能な限りファイル権限を厳格化し、ストレージを暗号化する。
  • 疑わしい漏洩が発生した後は、積極的にトークンを回転・失効させること。長寿命のAPIキーよりも短寿命のOAuthトークンを優先すること。
  • 会話履歴と添付ファイルの保存期間を制限する。セッションログの保存期間はデフォルトで7~14日間とし、毎週ローテーションまたは削除する。より長い保存期間が必要な場合は、保存時の暗号化を実施する。

6. プロンプト注入と信頼できないコンテンツ

  • あらゆる電子メール、文書、ウェブページ、チャットメッセージには、悪意のある指示が含まれている可能性があると考えてください。
  • 信頼できないテキストがシェルコマンドや認証情報のエクスポートを直接トリガーすることを許可しないでください。
  • チャンネルごとのツールポリシーを使用します。例えば、メールやSlackでは要約を許可しますが、TelegramやDiscordからのシェル操作やファイル書き込みアクションは拒否します。
  • コマンドの実行、ファイルのエクスポート、設定の変更、ログインの開始など、高リスクな操作には人間の確認を必要とします。
  • ブラウザの自動化は高リスクとみなすこと。エージェント用に別途、ログアウト済みのブラウザプロファイルを使用し、個人用セッションを再利用しないこと。
  • 有用なパターンとして、コンテンツのオリジンタグ付けと、オリジンごとのツールポリシー、および高リスクツールに対する必須の確認を組み合わせることが挙げられる。

7. 監視と検知、最小限の実行可能なカバレッジ

防御者向け ATT&CK 略語集

  • 初期アクセス:制御UIの露出またはサプライチェーンの悪用
  • 実行: シェル およびツールの実行
  • 認証情報のアクセス:ローカルトークンと設定ファイル
  • 永続性:変更された設定、メモリ、またはプラグイン
  • 指揮統制:チャットチャンネル
  • エクソフィルトレーション:アップロードとウェブフック

最低限の監視信号

  • コントロールUIの認証失敗、新規デバイスのペアリング、および設定変更を制御する
  • シェル実行、ファイルの読み書き、ブラウザ自動化、外部へのアップロードなどのツール呼び出し
  • ~/.clawdbot/* およびエージェントワークスペースにおける予期せぬファイルシステム変更
  • 新規の送信元ドメイン、メッセージングの急増、または異常なWebhookトラフィックなどのネットワーク活動
  • Moltbotポート上のファイアウォールログ、SSHログインイベント、異常な子プロセスなどのホスト信号

8. 曝露が疑われる場合:迅速な対応

  • サービスを停止し、証拠を保全してください。VMまたはコンテナのスナップショットを取得し、システムログと~/.clawdbot/*.
  • 認証情報を更新および失効させる。トークンを置き換え、OAuthセッションを失効させ、SSHキーを更新し、長期有効なAPIキーを再発行する。
  • アクセスパスを無効化します。公開チャネルを無効化し、許可リストをリセットし、コントロールUIのペアリングまたはパスワードをローテーションします。
  • 適切な場合に機密履歴を消去する。シークレットを含むセッション記録は削除し、その後、短い保持期間を適用する。
  • 疑わしい場合は再構築してください。強固な認証なしにホストに到達できた場合、またはコマンド実行が疑われる場合は、クリーンなイメージから再構築し、チャネルを慎重に再リンクしてください。
  • システムチェック後の永続化ポイント(systemdサービス、crontab、SSH認証鍵、インストール済みプラグインや拡張機能など)

持ち帰るべきもの

  1. モルトボットを特権インフラとして扱ってください。秘密情報を保持し、コマンドを実行し、信頼されたチャネルを介して通信します。
  2. ほとんどの失敗は設定の問題であり、脆弱性の悪用ではない。公開された管理UI、脆弱なプロキシ設定、開放された通信チャネル、そして過剰な権限を持つツールが、インシデントの大部分を占めている。
  3. アイデンティティは攻撃対象領域の一部です。特にブランド変更時には、公式組織・ドメイン・拡張子のみを信頼してください
  4. 保護できないものは公開しないこと。管理UIはローカルホストまたはVPN上に配置し、通信経路を制限し、危険な操作には確認を要求する。

このモデルに対する防御には、資産だけでなく行動の可視化が必要です。ここで重要な役割を果たすのが Vectra が極めて重要となります。これによりセキュリティチームは、信頼された自動化がID、ネットワーク、クラウド、ハイブリッド環境全体で悪用された際に現れる検知 行動を検知 、それらの行動が完全な侵害にエスカレートする前に阻止することが可能になります。

---

情報源

  • 公式Moltbot/Clawdbotセキュリティガイダンス(強化、リバースプロキシ、認証):https://docs.clawd.bot/gateway/security
  • 公式プロジェクトサイト: https://molt.bot (また https://clawd.bot)
  • 公式GitHubリポジトリ/組織: https://github.com/moltbot/clawdbot (組織ページ: https://github.com/clawdbot/)
  • Chirag (@mrnacknack) による一般的な設定ミスとプロンプト注入経路に関する解説記事(二次情報として参照):https://x.com/mrnacknack/article/2016134416897360212(@theonejvo のスレッドも参照)。
  • Cointelegraphによる公開インスタンスと認証情報漏洩リスクの報道(TradingViewミラー経由):https://www.tradingview.com/news/cointelegraph:99cbc6b7d094b:0-viral-ai-assistant-clawdbot-risks-leaking-private-messages-credentials/
  • Binance NewsによるGitHub/X乗っ取り+トークン詐欺混乱のまとめ: https://www.binance.com/en/square/post/01-27-2026-clawdbot-founder-faces-github-account-hijack-by-crypto-scammers-35643613762385
  • DEVコミュニティにおける名称変更と詐欺的なりすましの波に関するタイムライン: https://dev.to/sivarampg/from-clawdbot-to-moltbot-how-a-cd-crypto-scammers-and-10-seconds-of-chaos-took-down-the-internets-hottest-ai-project-4eck
  • 偽のClawdbot VS Code拡張機能の合気道セキュリティ分析: https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-マルウェア
  • プロジェクト変更履歴(セキュリティ関連の変更を追跡するため):https://github.com/clawdbot/clawdbot/blob/main/CHANGELOG.md
  • 情報窃取型マルウェアがClawdbot/Moltbotエコシステムに関心を示す二次的報告(方向性のみ、確定ではない):https://www.infostealers.com/article/clawdbot-the-new-primary-target-for-infostealers-in-the-ai-era/

よくあるご質問(FAQ)