- Claude Codeは危険なコマンドを、通常の復旧作業として扱いながら実行していました
- 一つの偽のエラーメッセージが、隠された攻撃連鎖全体の引き金となっていました
- 静的スキャナーやファイアウォールには、通常のDNS解決にしか見えませんでした
MozillaのセキュリティチームであるOdinチームの研究者たちは、開発者のデバイス上で隠れたリバースシェルを開かせるようClaude Codeを操作できることを示しました。
クローンしたプロジェクト内に悪意のあるコードを仕込む必要は一切ありませんでした。目に見えるすべてのファイルは通常のレビューをそのまま通過し、疑いを招くことはなかったからです。
その代わり、危険な指示は後になって届きました。スキャナーが決して検査することのないDNSのTXTレコードから、実行時に取得される仕組みだったのです。
ありふれたセットアップエラーが侵入口になった経緯
攻撃は、Axiomという一般的な監視ツールのインストール方法を説明する、何の変哲もないMarkdownファイルから始まりました。
このツールを初期化せずに実行すると、特定のセットアップコマンドを実行するよう指示する、ごく普通のエラーメッセージが表示されました。
研究チームは、このパターンが通常の開発者によるトラブルシューティングと酷似していると指摘しています。まさにそれこそが、これほど巧妙に疑いをかいくぐった理由だといいます。
Claude Codeは、あくまで役に立とうとする姿勢から、この記載された指示を自動的に実行し、文書化された修正手順を通常のエラー復旧作業として扱ってしまいました。
この一つのコマンドが引き金となり、隠されたシェルスクリプトが実行されました。このスクリプトは、攻撃者が完全に制御するDNSのTXTレコードに静かに問い合わせを行っていました。
そのレコードをデコードするとBase64でエンコードされたリバースシェルコマンドが現れ、これが静かに実行されて攻撃者のリモートサーバーへ直接接続していました。
いったん侵入されると、攻撃者はSSHキーを仕込んだり、隠れたcronジョブをスケジュールしたりできるため、永続的なアクセスを確保することも可能でした。
求人情報やチャットメッセージで共有されたリポジトリへのリンク一つだけで、それを開いた開発者全員が危険にさらされる可能性がありました。
アンチウイルスソフトやファイアウォール保護といった通常のセキュリティツールは、この欠陥に気づけませんでした。個々のステップだけを見ると、どれも疑わしく見えなかったからです。
静的コードスキャンツールが検知したのは通常のDNSルックアップのみで、何か悪意のある動きが進行しているとは示していませんでした。
ネットワーク監視も通常のドメイン名解決以上のものは記録しておらず、エージェント自身もこのコマンドを事前に承認済みのセットアップ作業とみなしていました。
0dinは、コーディングエージェントが何かを実行する前に、実際に実行されるセットアップスクリプトの中身を正確に検査する必要があると強調しています。
同チームは、セットアップファイルがどれほど普通に見えても、開発者はなじみのないリポジトリを安易に信用すべきではないと結論付けています。
今回の事例は、大規模言語モデルを基盤とするエージェント型AIツールには、はるかに強固な実行時の安全対策が必要になる可能性を示唆しています。
こうしたエージェントが、コマンドが実際に何を実行するのかを意味のある形で評価できるようになるまで、同様の間接的な攻撃を防ぐことは依然として困難であり続けるとみられます。
この教訓はClaude Codeにとどまりません。エージェント型AIシステムの多くが、間接的なプロンプトインジェクションに対して同様の死角を抱えているからです。
現時点では、見慣れない自動化処理を実際のリスクとして扱うことが、多くの個人開発者にとって最も確実な防御策であり続けています。
