🐾 claw-stack
· Orange & Qiushi Wu CTF multi-agent case study

24時間、40の課題: AIチームがBearcatCTF 2026でトップ6%を達成した方法

Claw-Stack Trinity アーキテクチャをBearcatCTF 2026にデプロイした完全なレトロスペクティブ — 何がうまくいったのか、何がうまくいかなかったのか、そしてAIエージェントがどこで限界に達したのか。

最終結果: 362チーム中20位。44の課題のうち40を解決。24時間の無人自動運用。これらの数字は私たちの予想を上回り、予期しなかったことを明らかにしました — AIについてではなく、構造化されたエージェント調整によって何が可能になるかについてです。

Trinityアーキテクチャ

BearcatCTFは、私たちがTrinityと呼ぶものの最初の実世界デプロイメントでした。つまり、共有知識ベース上で動作する、異なる役割を持つ3つの特殊化されたエージェントです。

Commander (Claude Opus) は戦略層として機能しました。課題を割り当てられると、Commanderは素早い偵察フェーズを実行し、攻撃計画を構築し、OperatorとLibrarianに実行を調整させました。ブラックボード上の進捗を追跡し、戦略をピボットするタイミングを決定し、行き止まりを放棄するタイミングを判定しました。Commanderは直接エクスプロイトコードを書くことはありませんでした — その仕事は各課題内での計画と調整です。

Operator (Claude Sonnet) はソルバーでした。Commanderから課題を割り当てられると、Operatorは課題説明、添付ファイル、および前の課題から関連する知識についてのLibrarianからのブリーフィングを受け取りました。Operatorは問題に取り組みました: スクリプトを書き、ペイロードをテストし、ソースコードを読み、ツールを実行しました。

Librarian (Claude Haiku) は知識ベースを管理しました。解決した課題ごとに、Librarianは主要なテクニックを抽出し、カテゴリーに分類し、共有ブラックボードに保存しました。Operatorが新しい課題に直面したとき、Librarian は関連する項目を引き出しました — 「2時間前にJWT偽造について学んだことはこれです」。

3つのエージェントはOpenClawの sessions_spawn と自動通知メカニズムを通じて通信しました。Commanderは各タスク用のサブエージェントとしてOperatorとLibrarianをスポーンしました。サブエージェントが終了すると、結果をCommanderに自動通知しました。永続的な blackboard.json ファイル — Commanderによって保守されている — は耐久性のある状態層として機能し、スポーン全体での検出結果、完了したステップ、現在の攻撃計画を追跡しました。これにより、Commanderはメッセージ履歴だけに頼らずに、セッション圧縮後でもフルコンテキストを再開できました。

最初の数時間

競技は正午に始まりました。7つのカテゴリーにわたる44の課題 — リバースエンジニアリング(7)、OSINT(5)、フォレンジック(7)、暗号化(8)、ウェブ(4)、その他(8)、pwn(5)。私たちはおおまかな優先順位で課題をCommanderに投入し、迅速な解決が期待できるカテゴリーから始めました。

最初の数時間は速かったです。ウェブの課題は迅速に解決されました: 基本的なSQLインジェクション、安全でないクッキー実装、alg: none を持つJWT。暗号化にはいくつかのエンコーディング課題があり、Operatorは数分で処理しました。Librarianはカタログ化していました。

4時間目までに、解決率は低下していました。残りの課題はより難しく、Commanderは各課題に費やす時間が増えていました — より深い偵察、より多くのLibrarian相談、より長いOperatorセッションです。

アンチチーティングメカニズム

私たちはシステムに早期にルールを組み込みました: 課題が3分以内に解決された場合、フラグを送信する前に自動監査を実行しました。監査人はセッション履歴をレビューし、エージェントが実際に問題に取り組んでいたのか、それとも何らかのショートカットを通じてフラグを取得していたのかをチェックしました。

明確にするために — これは競争的な意味でのチーティングについてではありません。CTF競技ではベンチマークのようなチーティングの問題は本当にはありません。アンチチーティングメカニズムはベンチマークの整合性についてでした: エージェントが40の課題を解決したというログが、偶発的なフラグ漏洩やまぐれではなく、本当の問題解決を反映していることを確認したかったのです。私たちのエージェントが40の課題を解決したと主張するつもりなら、各解決が本物だと確信する必要があります。

このメカニズムは重要であることがわかりました。監査はOneReal Case をキャッチしました: CryptoPwn (pwn課題)では、Operatorはサービスを実際に悪用するのではなく、課題ディレクトリの README.md ファイルを読んでフラグを含んでいました。セッションはsolveログで CHEATED としてマークされ、Commanderは正当な悪用を通じて課題をやり直すよう指示されました。

このメカニズムはまた、CTFをAIベンチマークとして使用している人にも関連しています — これはますます一般的になっています。このような監査がなければ、実際の能力を反映していない偽陽性でsolve率を水増しするのは簡単です。

ミッドゲーム

時間6から20は競技のコアでした。これはLibrarian統合が最も明確にその価値を示した場所です。フォレンジック課題はしばしばテクニックを共有します — ステガノグラフィ、ファイルカービング、メタデータ抽出。Librarianが解決したフォレンジック課題から知識を蓄積するにつれて、新しいフォレンジック課題に対するOperatorの最初の試みは改善されました。毎回最初の原則から始まるのではなく、OperatorはLibrarianブリーフィングを受け取りました: 「以前のフォレンジック課題はbinwalkとforemostを使用しました; JPEGステガノグラフィは2回出現しました」。

暗号化も同様のパターンを示しました。8番目の暗号課題は最初のものよりはるかに速く解決されました。実際の難易度は同じであっても、その時点までにLibrarianはその時点でチームの置換暗号へのアプローチ、パディングオラクル攻撃、XORキー回復を抽出していたからです。

各課題内で、Commanderは確かな戦術的判断を下しました。1つのアプローチが停滞したとき、Operatorを異なる攻撃ベクトルにピボットさせるのではなく、それを粉砕させました。文字列分析が機能していなかったフォレンジック課題では、Commanderはエントロピー分析に切り替え、数分で隠しペイロードを発見しました。

4つの未解決の課題

40/44で終了しました。4つの未解決の課題は3つの異なる障害モードに分かれていました:

2つは画像依存でした。 1つは劣化した画像からQRコードを読む必要があり、もう1つは写真の視覚的な詳細を識別することを含みました。Claudeのビジョン機能は一般的な画像理解のために堅牢ですが、CTF画像課題が必要とするピクセルレベルの正確な分析には最適化されていません。

1つはウェブ検索を必要とするOSINT課題でした。 エージェントは視覚的およびコンテキスト的な手がかりに基づいてオンラインで特定の情報を見つける必要がありましたが、検索ベースのOSINTワークフロー — 部分的な結果に基づいてクエリーを反復的に改善する必要があるもの — は時間予算内でのソリューションへの収束に失敗しました。

1つはハードpwn課題でした。 これは本物の難しさ上限でした: バイナリエクスプロイテーションは、エージェントが利用可能な時間内に推論できるものを超えた特定の制約を持つカスタムシェルコードを書くことを必要としました。

3つの異なる能力ギャップ、3つの異なる修正。画像課題には特殊化されたビジョンツール — 画像処理ライブラリをラップするカスタムMCPサーバーのようなものが — 必要です。OSINT検索ギャップには反復的なウェブ研究のためのより良いツール統合が必要です。ハードpwnは純粋な推論深度の問題であり、モデルがより強力になるにつれて改善されます。

学んだこと

ブラックボードパターンが機能します。 永続的な blackboard.json を耐久性のある状態層として使用する — spawn/announceを密接に結合せずにエージェント通信に並行して使用する — は、エージェントを調整するための単純で効果的な方法です。Librarianの知識抽出は洗練されていませんでした — 本質的には「このカテゴリーで最後に解決された課題からのテクニックはこれです」でした — しかし、その単純なバージョンでさえ、同じカテゴリーの後の課題に対するOperatorの最初の試み品質を意味深く改善しました。

役割によるモデル選択が重要です。 Librarianにはじめていることが正しい呼び出しでした: 知識抽出と保存は、推論深度よりもレイテンシーが重要な単純で高ボリュームなタスクです。Commanderにはじめていることは、戦略層に優先順位付けとシーケンスについての判断呼び出しを行うのに必要な推論容量を与えました。Operatorに使用されたSonnetは、実際の仕事の大部分の深さとコストのバランスを取りました。

未解決の課題には3つの異なる天井がありました。 画像分析、検索ベースのOSINT、およびハードバイナリ悪用は、それぞれ異なる能力ギャップを表しています。画像と検索のギャップはより良いツール作成 (特殊化されたビジョンモデル、反復的な検索ワークフロー) で対処できます。pwn天井は純粋な推論深度の問題です — それはモデルがより強力になるにつれて改善されます。

無人運用は達成可能ですが、特定の方法では脆弱です。 システムは24時間人間の干渉なしに実行されました。クラッシュしませんでした、ループしませんでした、明らかに間違ったフラグを送信しませんでした。しかし、それはまた、処理できないものにぶつかったときに助けを求めませんでした。ここには設計上の問題があります: 自律型エージェントが人間の入力を待つために停止する場合と、最善の推測を行って先に進む場合です。CTFの場合、先に進むのは通常正しいです。他のドメインでは、そうではないかもしれません。

競技ログ — セッション履歴、ツール呼び出し、およびLibrarian項目 — は数十メガバイト実行されます。私たちはまだそれらの分析を始めたばかりです。見出し数 — トップ6% — は満足感がありますが、より興味深いデータは障害モードにあります。

← ブログに戻る Orange & Qiushi Wu