Viper を採用前に読む: LLM エージェントを組み込んだレッドチーム基盤の実像

Viper が埋めようとしている穴は「ツールの断片化」である

レッドチームの作業は、偵察、初期侵入、権限昇格、横展開、侵害後操作という段階ごとに別々のツールを叩く形になりやすい。C2 フレームワークが 1 つ、横展開用のスクリプトが別、結果の記録は表計算ソフト、という構成である。Viper はこの断片化を 1 つのプラットフォームに畳み込むことを狙っている。README の説明では、Windows・Linux・macOS の 3 OS にインプラントを置けること、MITRE ATT&CK の各段階をカバーする 100 以上のポストエクスプロイトモジュールを同梱することが柱になっている。加えて、ピボットグラフ、ハンドラファイアウォール、防衛回避、自動通知といった機能が「More Advanced Features」として列挙されている。対象読者は、複数 OS が混在する環境を評価する必要があり、かつ作業の再現性と記録を後から求められる立場の実務者である。単発のペネトレーションテストを 1 回こなすだけなら、この規模のプラットフォームは過剰装備になり得る。

構成要素: インプラント、モジュール、UI、そして LLM エージェント

README から読み取れるアーキテクチャは大きく 4 層である。第一に各 OS 上のインプラント、第二に Python で書かれた拡張可能なモジュール群、第三に視覚的な操作 UI とピボットグラフ、第四に LLM エージェントである。モジュールが Python で書けるという点は設計上の分岐点で、比較表でも Cobalt Strike の CNA、NightHawk と BruteRatel の非対応と並べて Python が掲げられている。つまり既存の Python 資産や社内ライブラリをそのままモジュール化できる前提の作りだ。LLM エージェントについては README が「自動処理能力とインテリジェントな意思決定支援を強化する」と述べるにとどまり、どのモデルを、どこで動かし、どのデータを外部に送るのかは README からは分からない。自動ワークフローと通知機構についても「24/7 の監視」という表現があるが、判定ロジックや誤検知率には触れていない。この層は最も新しいぶん、ドキュメントが薄い領域だと見てよい。

導入経路: Docker イメージと Web ガイドが前提

README が示す入口は 2 つある。公式サイトの Getting-Started ページ（https://www.viperrtp.com/guide/getting_start）と、Docker Hub の viperplatform/viper イメージである。README の本文には docker run の具体的なコマンド例や compose ファイルの記載はなく、起動手順は Getting-Started 側を参照する構成になっている。そのため、オフライン環境や社内レジストリのみを使う制約がある場合は、イメージの取得経路を別途設計する必要がある。バージョンはリリースタグで管理されており、直近は v3.1.11（2026-03-31、タグ名 3.1.11 Skill is all you need）、その前に v3.1.10（2026-01-18）、v3.1.9（2025-11-09）が並ぶ。v3.1.9 のタグ名が Let's Summarize であることから、要約系の機能がこの時期に追加されたと推測できるが、リリースノート本文は手元の資料に含まれていないため、変更内容の詳細は断定できない。デフォルトブランチは master で、アーカイブはされておらず、最終プッシュは 2026-05-31 である。

ライセンスと保守コスト: ここが最大の未確認事項

最初に断っておく。提供されたリポジトリ情報ではライセンスが unknown であり、README にもライセンス条項の記述がない。比較表には価格欄があり Viper は Free と記載されているが、Free は価格の話であって、再配布、改変、商用利用、社内での複数チーム配布が許されるかは別問題である。法務判断は読者自身の組織が行うべきで、本稿は法的助言を与えない。実務的には、導入検討の最初のステップで作者に利用条件を確認し、回答を文書で残すことを勧める。保守の観点では、v3.1.9 から v3.1.11 まで約 5 か月で 3 回のマイナーリリースが行われており、更新の間隔は短い。レッドチーム用ツールは攻撃側の機能追加と防御側の検知更新が同時に進むため、追従を止めると検知される側に回りやすい。バージョンを固定して運用するなら、固定した版がいつまで現行環境で機能するかを自分で検証する必要がある。

Cobalt Strike との違いは拡張言語とインプラントの広さ

比較表で Viper は Cobalt Strike、NightHawk、BruteRatel と並べられている。差分として明確なのは 2 点ある。第一にインプラントの対応 OS で、Viper は Windows・Linux・macOS の 3 つ、Cobalt Strike・NightHawk・BruteRatel はいずれも Windows のみと表に記載されている。第二に拡張方式で、Viper は Python、Cobalt Strike は CNA である。CNA で書かれた既存のスクリプト資産はそのままでは動かないため、移行を検討するなら書き直しの工数を見積もる必要がある。表ではさらに、内蔵の防衛回避と自動化、チーム共同作業、LLM エージェントの欄で Viper にチェックが付き、Cobalt Strike では自動化と LLM エージェント、内蔵回避が空欄になっている。ただしこの表はプロジェクト自身が作成したもので、項目の判定基準は示されていない。自組織の評価軸で同じ比較をやり直す価値はある。価格欄は Viper が Free、Cobalt Strike が $12,600 user/year、NightHawk が $10,000 user/year、BruteRatel が $3,000 user/year と記載されている。

LLM エージェントを攻撃基盤に載せることの難しさ

Viper の最も特徴的な点は、レッドチーム基盤に LLM エージェントを組み込んだことである。比較表でも他 3 製品にはない欄として扱われている。ただし README の記述は「自動処理能力とインテリジェントな意思決定支援を強化する」という一文に留まり、推論の実行場所、対応モデル、プロンプトの管理方法、監査ログの有無は読み取れない。レッドチーム用途では、対象環境の情報が外部の推論サービスに送られる経路が生まれ得る。評価対象のシステムから得たホスト名、内部 IP、認証情報の断片がそのまま外部に渡ると、契約上の守秘義務に触れる可能性がある。導入を検討するなら、LLM 機能を無効化した状態で他の機能がどこまで動くかを先に確認し、有効化する場合のデータ経路を自分で追うべきである。この点は README だけでは判断できず、公式ドキュメントの該当ページを読む必要がある。

どのチームが採用し、どのチームが避けるべきか

採用が妥当なのは、Linux と macOS を含む環境の侵害後活動を継続的に評価しており、結果をピボットグラフとして残す運用が既にある組織である。Python でモジュールを書ける人材が内部にいるなら、100 以上の同梱モジュールに加えて自組織固有の手順を組み込める。逆に避けるべきなのは、ライセンス条項が確定していない状態で本番調達を通せない組織、商用ベンダーのサポート窓口と SLA を契約条件にしている組織、そして CNA で書いた既存の Cobalt Strike 拡張をそのまま流用したいチームである。判断を保留すべき最大の理由はライセンス不明であり、これは機能評価より先に解消すべき問題だ。次に確認すべきは Docker イメージのタグとリリースの対応、そして LLM エージェントのデータ送信範囲である。この 3 つが自組織の基準を満たした時点で、初めて検証環境への配備に進む意味が出てくる。

編集部の結論

Viper が向くのは、Windows だけでなく Linux と macOS を含む複数 OS の侵害後活動を 1 つの UI とピボットグラフで追いたいレッドチームと、Python で自作モジュールを書ける人材が内部にいる組織である。逆に、商用サポート契約と明確なライセンス条項が調達条件になっている組織、CNA で蓄積した既存の Cobalt Strike 資産をそのまま持ち込みたいチームには向かない。導入前に確認すべきは 3 点で、第一にリポジトリにライセンス識別子が記載されていないため配布条件を作者に直接問い合わせること、第二に Docker Hub の viperplatform/viper イメージのタグと v3.1.11 の対応関係を確認すること、第三に LLM エージェントが外部 API に送るデータ範囲を設定でどこまで絞れるかを検証することである。この 3 点が自組織のポリシーで埋まらない限り、Viper の導入判断は保留すべきだ。

公式情報源

1. FunnyWolf/Viper on GitHub
2. Issues
3. Project website
4. README
5. Releases