新しいアプローチにより、LLM駆動のペネトレーションテスト（pentest）エージェントは、単に侵害を主張するのではなく、チャレンジ・レスポンス方式のnonce（ナンス）を使用して、侵害を証明することが強制されます。HALOフレームワークで実証されたこの手法は、「シェルを取得したようだ」という状態を「実際にシェルを取得した」という状態へと変貌させます。
なぜ誤検知による侵害が問題なのか
大規模言語モデル（LLM）上に構築された自動エクスプロイトエンジンは、一度の実行で数十もの「成功した」ポート侵害を量産してしまう可能性があります。多くのサービスはバナー内に「uid=0」といった文字列をエコー（表示）しますが、巧妙に細工されたターゲットは、攻撃者のコードを一度も実行することなく、それらの出力を模倣できてしまいます。エージェントがそれらのエコーを信じてしまうと、ピボット、データの持ち出し、あるいは横展開（lateral movement）といったその後のすべての決定が、嘘に基づいたものになってしまいます。セキュリティチームは実体のない足がかりを追いかけるために何時間も無駄にし、インシデントレスポンダーは真の脅威の優先順位付けを誤る可能性があります。
主張を証明に変える
この解決策は、古典的な認証のトリックを応用しています。エクスプロイトを実行する前に、攻撃者のシステムは一意のトークン、すなわちnonceを生成し、それをペイロードに埋め込みます。コントローラーが結果を本物の侵害として受け入れるためには、エクスプロイトがその正確なトークンを返さなければなりません。偽のバナーではnonceを推測することはできず、レスポンスにトークンを埋め込むためには攻撃者のコードを実行する必要があります。返されたデータに一致するnonceが含まれていない場合、その試行は誤検知として破棄されます。
この転換により、検証モデルは「出力が正しそうに見える」から「出力が実行を証明する」へと変わります。これにより、自律型攻撃ツールを悩ませる楽観バイアスが取り除かれます。
信頼性の高いデリバリー・ラダー（伝達経路）の構築
ペイロードをターゲットに届けるには、依然として強固なデリバリーチェーンが必要です。HALOは、一般的な3つの経路を分類しています。
- Reverse shells – 侵害されたホストが、攻撃者が制御するリスナーに対して接続を開始します。インバウンドトラフィックがブロックされている場合に有効です。
- Bind shells – 攻撃者がターゲット上の待機中のサービスに直接接続します。アウトバウンドフィルタが緩い場合に機能します。
- Blind callbacks – 直接的なチャネルを開設できない高度に制限された環境において、実行を確認するための一方向の信号（例：DNSリクエスト）です。
ラダーの各ステップはnonceを保持しなければならず、さもなければ後続の証明ステップが失敗します。
自己完結型のエクスプロイトの確保
誤った自信のもう一つの原因は、ターゲットに存在しない可能性のある外部ライブラリへの依存です。HALOは、配信前に必要なすべてのコンポーネントを単一のファイルにまとめます。その後、そのバンドルは、元の依存関係を意図的に欠いたサンドボックス内でテストされます。エクスプロイトがそれでも動作する場合、そのアーティファクトは真に自己完結しており、制限の厳しいシステムでも信頼できます。
開発の痕跡をクリーンにする
公開準備中に、著者はGitの履歴に実際のIPアドレスが残っていることに気づきました。ワーキングツリーをクリーンにしても、それらの記録は消えません。Gitはすべてのコミットを保持しているからです。著者はリポジトリを単一のクリーンなコミットに書き換え、漏洩したアドレスをRFC 5737で定義されたドキュメント専用の範囲（例：192.0.2.0/24）に置き換えました。これにより、ツールが共有された際に本番環境のインフラが誤って露出することを防ぎます。
セキュリティツール作成のための実践的なルール
- すべてのテストフィクスチャにおいて、ドキュメント専用のIP範囲を使用する。
- 初回コミットからシークレットやスコープファイルを削除する。
- 侵害の主張を検証するために、チャレンジ・レスポンス方式のnonceを適用する。
- 関連性の薄いスクリプトではなく、実際に配信される正確なファイルを検証する。
証明は楽観論に勝ります。自律型ペネトレーションテストエージェントに検証可能なトークンの提示を強制することで、HALOは、ターゲットが攻撃者のコードを実行したことを証明できて初めて、侵害が「侵害」となることを示しています。まずはゲート（関門）を構築すること。それ以外はすべてその後に続きます。