Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
reconswarm — クラウドの力でリコンを拡張する | Kitploit
ツール/GitHubGitHub/renatus-cartesius/reconswarm
偵察ペネトレーションテストクラウドセキュリティDevSecOpsサブドメイン列挙
GitHubrenatus-cartesius/reconswarm

reconswarm

クラウドの力でリコンを拡張する

リポジトリを見る
95ヶ月前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

ReconSwarm

Architecture

ReconSwarm は、分散型セキュリティテスト向けに設計されたモジュール型偵察自動化フレームワークです。クラウドインフラストラクチャをプロビジョニングし、並列の偵察パイプラインを実行し、最小限の設定オーバーヘッドで結果を収集します。

ReconSwarm は、手動でのインフラ管理を行わずにスケーラブルで自動化された偵察ワークフローを必要とする、バグバウンティハンター、ペネトレーションテスター、DevSecOps エンジニア、セキュリティ研究者に適しています。

特徴

Targets flow

  • 並列実行のためのターゲット分割 — 最終的にコンパイルされたターゲットリストは、偵察タスクを並列実行するためにワーカーに分割されます。
  • 複数のターゲットタイプ — ターゲットリストは、crt.sh 応答からのドメイン、外部リスト(HTTP/HTTPS URL)、単純なリスト(インライン YAML 配列)、シェルコマンド出力など、複数の要素タイプで構成されます。これにより、任意のツール(cook、shodan、gau、katana など)と柔軟に連携できます。
  • クラウド非依存のアーキテクチャ — 複数のクラウドプロバイダー(現在は AWS、GCP、Yandex Cloud、Digital Ocean をサポート)との容易な統合を可能にします。
  • 柔軟なパイプラインステージ — 現在 exec(コマンド実行)と sync(ファイル・ディレクトリ同期)操作をサポートする拡張可能なステージシステム。
  • ステップ内のテンプレートコンテキスト — 実行コンテキストからステップにメタデータを渡す柔軟な方法。

必須機能(未実装)

  • Web UI — 高速な操作のためのシンプルな Web ベースのユーザーフレンドリー UI。
  • ステージからのリアルタイムログ — stdout/stderr をキャプチャし、gRPC ストリーミングでクライアントに送信。
  • ワーカーへのリモートシェル — RS サーバーを介してクライアントからワーカーへの SSH 接続を開く。
  • 発見ステージ — 前のステージ(例:nuclei JSON 結果)から受信したデータを処理し、etcd に保存し、通知を行うステージ。

アーキテクチャ

ReconSwarm は、クラウドプロビジョニング、リモートシステム制御、パイプライン実行、設定管理の間で明確な関心の分離を持つモジュール型アーキテクチャに従います。

クラウドプロバイダー抽象化

ReconSwarm はクラウドプロビジョナーに識別共用体型パターンを使用します。provisioner.type フィールドがアクティブなプロバイダー設定を決定します。

root@kitploit:~
provisioner:
  type: yandex_cloud  # 識別子フィールド
  yandex_cloud:       # type: yandex_cloud のときに有効
    iam_token: "${YC_TOKEN}"
    # key_path: "./sa_auth_key.json"
    folder_id: "${YC_FOLDER_ID}"
    # ... プロバイダー固有の設定

追加のクラウドプロバイダーは、Provisioner インターフェースを実装し、ファクトリに新しいタイプを追加することで統合できます。

パイプラインステージシステム

ステージは、ワーカー VM 上で操作を実行する拡張可能なコンポーネントです。

  • exec — テンプレートサポート付きでシェルコマンドを実行。
  • sync — リモート VM からローカルマシンにファイルまたはディレクトリを SFTP 経由でコピー(ファイルかディレクトリかを自動検出)。

すべてのステージフィールドはテンプレートレンダリングをサポートします。新しいステージタイプを追加して機能を拡張できます。

ステートレスサーバーとフォールトトレランス

ReconSwarm サーバーは完全にステートレスです。すべての状態は etcd に永続化されます。

  • パイプライン状態 — 各パイプラインのステータス、進捗、エラー。
  • ワーカー状態 — VM 情報、現在のタスク、ステータス。
  • SSH 鍵 — VM アクセス用に生成された鍵ペア。

このアーキテクチャにより以下が可能です。

機能説明
水平スケーリングロードバランサーの背後で複数のサーバーインスタンスを実行。
ダウンタイムゼロの再起動パイプラインの状態を失わずにサーバーを再起動。
クラッシュリカバリ

高可用性構成:

root@kitploit:~
                    ┌─────────────┐
                    │   Client    │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │Load Balancer│
                    └──────┬──────┘
              ┌────────────┼────────────┐
              │            │            │
       ┌──────▼──────┐ ┌───▼───┐ ┌──────▼──────┐
       │  Server 1   │ │Server2│ │  Server 3   │
       └──────┬──────┘ └───┬───┘ └──────┬──────┘
              │            │            │
              └────────────┼────────────┘
                           │
                    ┌──────▼──────┐
                    │ etcd cluster│
                    └─────────────┘

すべてのサーバーは同じ etcd クラスターを共有し、任意のリクエストを処理できます。パイプライン実行中にサーバーがクラッシュした場合、別のサーバーが etcd から状態を読み取って実行を継続できます。

注: 現在の実装では、etcd からロードした後、メモリ内でパイプラインを実行します。パイプライン再開を含む完全なクラッシュリカバリは将来のリリースで計画されています。

インストール

root@kitploit:~
git clone <repository>
cd reconswarm
go mod download
task build

設定

ReconSwarm はサーバー設定とパイプライン設定を分離します。

設定タイプファイル説明
サーバーreconswarm.yamlクラウドプロバイダー、etcd、ワーカープール設定。
パイプライン別の YAML ファイルターゲットとステージ。-f フラグで指定。

サーバー設定

サーバー設定は reconswarm.yaml に保存されます(CONFIG_PATH 環境変数で設定可能)。すべての文字列値は ${VAR} または $VAR 構文を使用した環境変数の展開をサポートします。

root@kitploit:~
# Server settings
server:
  port: 50051

# Etcd connection for state management
etcd:
  endpoints:
    - "localhost:2379"
  dial_timeout: 5  # seconds
  username: ""     # optional, supports ${ETCD_USER}
  password: ""     # optional, supports ${ETCD_PASSWORD}

# Cloud provisioner (discriminated union)
provisioner:
  type: yandex_cloud  # Provider selector

  # Yandex Cloud configuration (active when type: yandex_cloud)
  yandex_cloud:
    iam_token: "${YC_TOKEN}"
    # key_path: "./sa_auth_key.json"
    folder_id: "${YC_FOLDER_ID}"
    default_zone: "ru-central1-b"
    default_image: "fd8b1cmhmncn7lt4tqn4"
    default_username: "root"
    default_cores: 2
    default_memory: 2      # GB
    default_disk_size: 20  # GB

# Worker pool settings
workers:
  max_workers: 5
  setup_commands:
    - "apt update"
    - "apt install -y docker.io"

パイプライン設定

パイプライン設定は別の YAML ファイルに保存し、-f フラグで指定します。ラップ形式とアンラップ形式の両方をサポートします。

ラップ形式(推奨):

root@kitploit:~
# pipeline.yaml
pipeline:
  targets:
    - value: "example.com"
      type: crtsh
    - value: ["sub1.example.com", "sub2.example.com"]
      type: list
  stages:
    - name: "Run scanner"
      type: exec
      steps:
        - "nmap -sC -sV -iL {{.Targets.filepath}} -oN /opt/recon/scan.txt"
    - name: "Collect results"
      type: sync
      src: "/opt/recon/scan.txt"
      dest: "./results/{{.Worker.Name}}.txt"

アンラップ形式(同様にサポート):

root@kitploit:~
# pipeline.yaml
targets:
  - value: "example.com"
    type: crtsh
stages:
  - name: "Run scanner"
    type: exec
    steps:
      - "nmap -iL {{.Targets.filepath}} -oN /opt/recon/scan.txt"

環境変数

設定値は、以下の2つの形式で環境変数の置換をサポートします。

  • ${VAR} — 中括弧内の完全な変数名
  • $VAR — 単純な変数名

環境変数が設定されていない場合、リテラル文字列(${VAR} または $VAR を含む)がそのまま使用されます。

Yandex Cloud のセットアップ

Yandex Cloud との統合には、提供されているセットアップスクリプトを使用します。

  1. Yandex Cloud CLI のインストール(まだインストールされていない場合):

    root@kitploit:~
    # 公式の Yandex Cloud ドキュメントに従って CLI をインストール
    
  2. Yandex Cloud CLI の設定:

    root@kitploit:~
    yc config profile create <profile-name>
    yc config set cloud-id <your-cloud-id>
    yc config set folder-id <your-folder-id>
    
  3. 認証情報のエクスポート:

    root@kitploit:~
    source ./secrets-setup.sh
    

    このスクリプトは以下をエクスポートします。

    • YC_TOKEN — 認証用の IAM トークン
    • YC_FOLDER_ID — リソース管理用のフォルダ ID
    • YC_CLOUD_ID — クラウド ID(必要な場合)
  4. 設定で参照:

    root@kitploit:~
    provisioner:
      type: yandex_cloud
      yandex_cloud:
        iam_token: "${YC_TOKEN}"
        # key_path: "./sa_auth_key.json"
        folder_id: "${YC_FOLDER_ID}"
    

secrets-setup.sh スクリプトは、実行するたびに新しい IAM トークンを自動生成するため、認証情報をハードコードせずに安全な認証が可能です。

Google Cloud Platform のセットアップ

  1. サービスアカウントの作成:

    • GCP コンソール > IAM & 管理 > サービスアカウントに移動
    • 「Compute 管理者」ロールを持つサービスアカウントを作成
    • JSON キーを作成しダウンロード
  2. 環境の設定:

    root@kitploit:~
    export GCP_PROJECT_ID="your-project-id"
    export GCP_CREDENTIALS_PATH="/path/to/key.json"
    
  3. 設定で参照:

    root@kitploit:~
    provisioner:
      type: gcp
      gcp:
        project_id: "${GCP_PROJECT_ID}"
        credentials_path: "${GCP_CREDENTIALS_PATH}"
        default_zone: "us-central1-a"
    

AWS のセットアップ

  1. IAM ユーザーの作成:

    • AWS コンソール > IAM > ユーザーに移動
    • 「AmazonEC2FullAccess」権限を持つユーザーを作成
    • アクセスキー ID とシークレットアクセスキーを生成
  2. 環境の設定:

    root@kitploit:~
    export AWS_ACCESS_KEY_ID="your-access-key"
    export AWS_SECRET_ACCESS_KEY="your-secret-key"
    
  3. 設定で参照:

    root@kitploit:~
    provisioner:
      type: aws
      aws:
        region: "us-east-1"
        access_key_id: "${AWS_ACCESS_KEY_ID}"
        secret_access_key: "${AWS_SECRET_ACCESS_KEY}"
        default_zone: "us-east-1a"
    

DigitalOcean のセットアップ

  1. トークンの生成:

    • DigitalOcean コントロールパネル > API に移動
    • 「書き込み」スコープを持つパーソナルアクセストークンを生成
  2. 環境の設定:

    root@kitploit:~
    export DO_TOKEN="your-token"
    
  3. 設定で参照:

    root@kitploit:~
    provisioner:
      type: digitalocean
      digitalocean:
        token: "${DO_TOKEN}"
        default_region: "nyc1"
    

ターゲットタイプ

crt.sh 列挙:

root@kitploit:~
targets:
  - value: "example.com"
    type: crtsh

手動リスト:

root@kitploit:~
targets:
  - value: ["sub1.example.com", "sub2.example.com"]
    type: list

ステージ設定

すべてのステージ設定フィールドは、動的な値生成のために Go テンプレート構文をサポートします。テンプレート変数は実行時にレンダリングされ、コンテキストデータが自動的に提供されます。

テンプレートコンテキスト

すべてのステージテンプレートで以下のデータが利用可能です。

変数説明
{{.Targets.filepath}}リモート VM 上のターゲットファイルへの絶対パス。
{{.Targets.list}}プログラムによるアクセス用のターゲット文字列の配列。
{{.Worker.Name}}ワーカー VM インスタンスの一意の識別子。

Exec ステージ — テンプレートサポート付きでシェルコマンドを実行:

root@kitploit:~
stages:
  - name: "Run tool"
    type: exec
    steps:
      - "docker run --rm -v /opt/recon:/data scanner:latest {{.Targets.filepath}}"
      - "cat /opt/recon/results.json"

steps 配列内のすべてのコマンドは、実行前にテンプレートレンダリングが行われます。

Sync ステージ — SFTP を使用してリモートからローカルにファイルまたはディレクトリをコピー。パスがファイルかディレクトリかを自動検出します。

root@kitploit:~
stages:
  - name: "Collect results"
    type: sync
    src: "/opt/recon/results.json"
    dest: "./results/{{.Worker.Name}}.json"
  
  # Sync entire directory recursively
  - name: "Collect all results"
    type: sync
    src: "/opt/recon"
    dest: "./results/{{.Worker.Name}}"

src(リモートパス)と dest(ローカルパス)の両方が、動的なファイルパスのためのテンプレートレンダリングをサポートします。sync ステージはソースパスがファイルかディレクトリかを自動検出し、それに応じて処理します。

使用方法

サーバーモード

gRPC サーバーを起動してパイプラインの送信を受け付けます。

root@kitploit:~
reconswarm server

サーバーは reconswarm.yaml から設定を読み取り、設定されたポート(デフォルト: 50051)で待機します。

gRPC 経由でパイプラインを送信

実行中のサーバーにパイプラインを送信します。

root@kitploit:~
reconswarm run -f examples/pipelines/nuclei.yaml

オプション:

  • -f, --pipeline — パイプラインファイルへのパス(必須)
  • -s, --server — サーバーアドレス(デフォルト: localhost:50051)

パイプラインの状態を確認

root@kitploit:~
reconswarm status <pipeline-id>

手動パイプライン実行

gRPC サーバーを使わずにパイプラインを直接実行(テストに便利)。

root@kitploit:~
reconswarm manual -f examples/pipelines/nuclei.yaml

このコマンドは:

  1. reconswarm.yaml からサーバー設定を読み取る。
  2. ターゲットを準備する(必要に応じて crt.sh 経由でサブドメインを列挙)。
  3. workers.max_workers 設定に基づいてワーカー VM を作成する。
  4. ターゲットをワーカーに分散する。
  5. 各 VM でセットアップコマンドを実行する。
  6. パイプラインステージを順次実行する。
  7. sync ステージを介して結果を収集する。
  8. 完了後、すべてのインフラストラクチャを自動的に解放する。

自動的なインフラ解放により完全な自律性が確保され、すべてのクラウドリソースが手動介入なしにプロビジョニング、使用、破棄されるため、完全に自動化された偵察ワークフローが可能になります。

設定例

完全なパイプラインの例については、examples/pipelines ディレクトリを参照してください。

基本的なサブドメイン列挙とスキャン:

root@kitploit:~
# pipeline.yaml
pipeline:
  targets:
    - value: "example.com"
      type: crtsh
  stages:
    - name: "Scan targets"
      type: exec
      steps:
        - "nmap -sC -sV -iL {{.Targets.filepath}} -oN /opt/recon/nmap-{{.Worker.Name}}.txt"
    - name: "Collect results"
      type: sync
      src: "/opt/recon/nmap-{{.Worker.Name}}.txt"
      dest: "./results/nmap-{{.Worker.Name}}.txt"

実行方法:

root@kitploit:~
reconswarm manual -f pipeline.yaml
# またはサーバーに送信:
reconswarm run -f pipeline.yaml

Docker ベースのスキャンによる複数ターゲット:

root@kitploit:~
pipeline:
  targets:
    - value: "example.com"
      type: crtsh
    - value: ["api.example.com", "www.example.com"]
      type: list
  stages:
    - name: "Run nuclei scan"
      type: exec
      steps:
        - "docker run --rm -v /opt/recon:/data projectdiscovery/nuclei:latest -l {{.Targets.filepath}} -json -o /opt/recon/nuclei-{{.Worker.Name}}.json"
    - name: "Copy nuclei results"
      type: sync
      src: "/opt/recon/nuclei-{{.Worker.Name}}.json"
      dest: "./results/nuclei-{{.Worker.Name}}.json"

複数ステージのカスタムツールチェーン:

サーバー設定 (reconswarm.yaml):

root@kitploit:~
workers:
  max_workers: 5
  setup_commands:
    - "apt update"
    - "apt install -y git golang"
    - "git clone https://github.com/projectdiscovery/subfinder.git"
    - "cd subfinder && go build"

パイプライン設定 (pipeline.yaml):

root@kitploit:~
pipeline:
  targets:
    - value: "example.com"
      type: crtsh
  stages:
    - name: "Additional enumeration"
      type: exec
      steps:
        - "cd subfinder && ./subfinder -dL {{.Targets.filepath}} -o /opt/recon/subfinder-{{.Worker.Name}}.txt"
    - name: "Merge targets"
      type: exec
      steps:
        - "cat {{.Targets.filepath}} /opt/recon/subfinder-{{.Worker.Name}}.txt | sort -u > /opt/recon/all-targets-{{.Worker.Name}}.txt"
    - name: "Scan merged targets"
      type: exec
      steps:
        - "nmap -sC -sV -iL /opt/recon/all-targets-{{.Worker.Name}}.txt -oN /opt/recon/scan-{{.Worker.Name}}.txt"
    - name: "Collect all results"
      type: sync
      src: "/opt/recon"
      dest: "./results/{{.Worker.Name}}"

注: sync ステージは /opt/recon がディレクトリであることを自動検出し、すべてのファイルとサブディレクトリをローカルの宛先に再帰的にコピーします。

その他のコマンド

サブドメイン列挙:

root@kitploit:~
reconswarm crtsh-dump example.com

指定されたドメインの crt.sh から解決可能なサブドメインを取得してフィルタリングします。

デバッグコマンド(VM プロビジョニングのテスト用):

root@kitploit:~
reconswarm debug

開発

Task を使用してビルドおよびテストします。

root@kitploit:~
task build      # Build binary
task test       # Run tests
task lint       # Run linter
task vet        # Run go vet
task ci         # Run all CI checks

TODO

追加のターゲットソース

  • シェル評価によるターゲットの受け渡しを追加(cook、radamsa または利用可能なすべてのツールを使用するため):
    • クライアントでターゲットを評価し、gRPC 呼び出しで渡す(大きな入力ではネットワークオーバーヘッドあり)
    • サーバーで評価する(サーバー環境の依存関係が必要)
  • DNSDumpster ターゲットソースを追加
  • Censys ターゲットソースを追加
  • Shodan ターゲットソースを追加

ステートフルな実行

  • 実行状態の保存を追加
    • 解決済みターゲットリスト
    • 稼働中および終了済みワーカー

マルチクラウドプロバイダーサポート

  • AWS (EC2) プロビジョナーを追加
  • Google Cloud Platform (Compute Engine) プロビジョナーを追加
  • Azure (Virtual Machines) プロビジョナーを追加
  • DigitalOcean プロビジョナーを追加

拡張パイプラインステージタイプ

  • notify ステージを追加 — 通知またはアラートを送信(Webhook、メール、Slack)
  • conditional ステージを追加 — 前のステージの結果に基づいてステージを実行
  • parallel ステージを追加 — 同じワーカー上で複数の操作を同時に実行
  • retry ステージを追加 — 設定可能なバックオフで失敗した操作を自動リトライ
  • timeout ステージを追加 — ステージごとに実行タイムアウトを設定
  • validate ステージを追加 — 進む前に結果または条件を検証

デーモンモードとスケジュール実行

  • cron 風の式によるスケジュール実行を実装
  • 長時間実行プロセス用の継続監視モードを追加
  • イベント駆動型トリガーを追加(Webhook、外部イベント)
  • 結果の永続化と実行履歴追跡を実装
  • 組み込みのヘルスチェックと自動リカバリを追加

代替結果ストレージタイプ

  • オブジェクトストレージサポートを追加(S3、GCS、Azure Blob Storage)
  • データベースストレージサポートを追加(PostgreSQL、MySQL、MongoDB)
  • メッセージキューサポートを追加(RabbitMQ、Kafka、Redis streams)
  • API エンドポイント統合を追加(カスタム HTTP POST)
  • 添付ファイル付きのメール通知サポートを追加
  • クラウドログ統合を追加(CloudWatch、Stackdriver など)

ライセンス

MIT ライセンス。詳細は LICENSE ファイルを参照してください。

ツールをダウンロード
新しいサーバーインスタンスが前のインスタンスの続きから実行。
状態検査デバッグと監視のために etcd を直接クエリ。