
Amplie seu reconhecimento com o poder da nuvem

ReconSwarm é um framework modular de automação de reconhecimento projetado para testes de segurança distribuídos. Ele provisiona infraestrutura em nuvem, executa pipelines de reconhecimento em paralelo e coleta resultados com sobrecarga mínima de configuração.
ReconSwarm é adequado para caçadores de recompensas de bugs, testadores de penetração, engenheiros DevSecOps e pesquisadores de segurança que precisam de fluxos de trabalho de reconhecimento escaláveis e automatizados, sem gerenciamento manual de infraestrutura.

ReconSwarm segue uma arquitetura modular com separação clara de responsabilidades entre provisionamento em nuvem, controle remoto de sistemas, execução de pipelines e gerenciamento de configuração.
ReconSwarm usa um padrão de união discriminada para provisionadores de nuvem. O campo provisioner.type determina qual configuração de provedor está ativa:
provisioner:
type: yandex_cloud # Campo discriminador
yandex_cloud: # Ativo quando type: yandex_cloud
iam_token: "${YC_TOKEN}"
# key_path: "./sa_auth_key.json"
folder_id: "${YC_FOLDER_ID}"
# ... configurações específicas do provedor
Provedores de nuvem adicionais podem ser integrados implementando a interface Provisioner e adicionando um novo tipo à fábrica.
Estágios são componentes extensíveis que executam operações nas VMs workers:
Todos os campos dos estágios suportam renderização de templates. Novos tipos de estágio podem ser adicionados para estender a funcionalidade.
O servidor ReconSwarm é completamente stateless — todo o estado é persistido no etcd:
Esta arquitetura permite:
| Capacidade | Descrição |
|---|---|
| Escalabilidade horizontal |
Configuração de Alta Disponibilidade:
┌─────────────┐
│ Cliente │
└──────┬──────┘
│
┌──────▼──────┐
│Balanceador │
│ de Carga │
└──────┬──────┘
┌────────────┼────────────┐
│ │ │
┌──────▼──────┐ ┌───▼───┐ ┌──────▼──────┐
│ Servidor 1 │ │Ser v2│ │ Servidor 3 │
└──────┬──────┘ └───┬───┘ └──────┬──────┘
│ │ │
└────────────┼────────────┘
│
┌──────▼──────┐
│cluster etcd │
└─────────────┘
Todos os servidores compartilham o mesmo cluster etcd e podem lidar com qualquer requisição. Se um servidor falhar no meio de um pipeline, outro servidor pode continuar a execução após ler o estado do etcd.
Nota: A implementação atual executa pipelines em memória após carregar do etcd. A recuperação completa de falhas com retomada de pipeline está planejada para versões futuras.
git clone <repositório>
cd reconswarm
go mod download
task build
ReconSwarm separa a configuração do servidor da configuração do pipeline:
| Tipo de Config | Arquivo | Descrição |
|---|---|---|
| Servidor | reconswarm.yaml | Provedor de nuvem, etcd, configurações do pool de workers |
| Pipeline | Arquivo YAML separado | Alvos e estágios, passado via flag -f |
A configuração do servidor é armazenada em reconswarm.yaml (configurável via variável de ambiente CONFIG_PATH). Todos os valores de string suportam expansão de variáveis de ambiente usando a sintaxe ${VAR} ou $VAR.
# Configurações do servidor
server:
port: 50051
# Conexão etcd para gerenciamento de estado
etcd:
endpoints:
- "localhost:2379"
dial_timeout: 5 # segundos
username: "" # opcional, suporta ${ETCD_USER}
password: "" # opcional, suporta ${ETCD_PASSWORD}
# Provisionador de nuvem (união discriminada)
provisioner:
type: yandex_cloud # Seletor de provedor
# Configuração Yandex Cloud (ativa quando 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
# Configurações do pool de workers
workers:
max_workers: 5
setup_commands:
- "apt update"
- "apt install -y docker.io"
A configuração do pipeline é armazenada em um arquivo YAML separado e passada via flag -f. Ambos os formatos, encapsulado e não encapsulado, são suportados:
Formato encapsulado (recomendado):
# pipeline.yaml
pipeline:
targets:
- value: "example.com"
type: crtsh
- value: ["sub1.example.com", "sub2.example.com"]
type: list
stages:
- name: "Executar scanner"
type: exec
steps:
- "nmap -sC -sV -iL {{.Targets.filepath}} -oN /opt/recon/scan.txt"
- name: "Coletar resultados"
type: sync
src: "/opt/recon/scan.txt"
dest: "./results/{{.Worker.Name}}.txt"
Formato não encapsulado (também suportado):
# pipeline.yaml
targets:
- value: "example.com"
type: crtsh
stages:
- name: "Executar scanner"
type: exec
steps:
- "nmap -iL {{.Targets.filepath}} -oN /opt/recon/scan.txt"
Os valores de configuração suportam substituição de variáveis de ambiente em dois formatos:
${VAR} — Nome completo da variável entre chaves$VAR — Nome simples da variávelSe uma variável de ambiente não estiver definida, a string literal (incluindo ${VAR} ou $VAR) será utilizada.
Para integração com Yandex Cloud, use o script de configuração fornecido:
Instale a CLI do Yandex Cloud (se ainda não estiver instalada):
# Siga a documentação oficial do Yandex Cloud para instalação da CLI
Configure a CLI do Yandex Cloud:
yc config profile create <nome-do-perfil>
yc config set cloud-id <seu-cloud-id>
yc config set folder-id <seu-folder-id>
Exporte as credenciais:
source ./secrets-setup.sh
Este script exporta:
YC_TOKEN — Token IAM para autenticaçãoYC_FOLDER_ID — ID da pasta para gerenciamento de recursosYC_CLOUD_ID — ID da nuvem (se necessário)Referencie na configuração:
provisioner:
type: yandex_cloud
yandex_cloud:
iam_token: "${YC_TOKEN}"
# key_path: "./sa_auth_key.json"
folder_id: "${YC_FOLDER_ID}"
O script secrets-setup.sh gera automaticamente um novo token IAM a cada execução, garantindo autenticação segura sem codificar credenciais.
Crie uma Conta de Serviço:
Configure o Ambiente:
export GCP_PROJECT_ID="seu-project-id"
export GCP_CREDENTIALS_PATH="/caminho/para/key.json"
Referencie na configuração:
provisioner:
type: gcp
gcp:
project_id: "${GCP_PROJECT_ID}"
credentials_path: "${GCP_CREDENTIALS_PATH}"
default_zone: "us-central1-a"
Crie um Usuário IAM:
Configure o Ambiente:
export AWS_ACCESS_KEY_ID="sua-access-key"
export AWS_SECRET_ACCESS_KEY="sua-secret-key"
Referencie na configuração:
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"
Gere um Token:
Configure o Ambiente:
export DO_TOKEN="seu-token"
Referencie na configuração:
provisioner:
type: digitalocean
digitalocean:
token: "${DO_TOKEN}"
default_region: "nyc1"
Enumeração crt.sh:
targets:
- value: "example.com"
type: crtsh
Lista manual:
targets:
- value: ["sub1.example.com", "sub2.example.com"]
type: list
Todos os campos de configuração de estágios suportam sintaxe de template Go para geração dinâmica de valores. As variáveis do template são renderizadas no momento da execução com dados de contexto fornecidos automaticamente.
Contexto do Template
Os seguintes dados estão disponíveis em todos os templates de estágio:
| Variável | Descrição |
|---|---|
{{.Targets.filepath}} | Caminho absoluto para o arquivo de alvos na VM remota |
{{.Targets.list}} | Array de strings de alvos para acesso programático |
{{.Worker.Name}} | Identificador único da instância da VM worker |
Estágio exec — Executa comandos shell com suporte a templates:
stages:
- name: "Executar ferramenta"
type: exec
steps:
- "docker run --rm -v /opt/recon:/data scanner:latest {{.Targets.filepath}}"
- "cat /opt/recon/results.json"
Todos os comandos no array steps são renderizados com template antes da execução.
Estágio sync — Copia arquivos ou diretórios do remoto para o local usando SFTP. Detecta automaticamente se o caminho é arquivo ou diretório:
stages:
- name: "Coletar resultados"
type: sync
src: "/opt/recon/results.json"
dest: "./results/{{.Worker.Name}}.json"
# Sincronizar diretório inteiro recursivamente
- name: "Coletar todos os resultados"
type: sync
src: "/opt/recon"
dest: "./results/{{.Worker.Name}}"
Tanto src (caminho remoto) quanto dest (caminho local) suportam renderização de template para caminhos de arquivos dinâmicos. O estágio sync detecta automaticamente se o caminho de origem é um arquivo ou diretório e lida adequadamente.
Inicie o servidor gRPC para aceitar submissões de pipeline:
reconswarm server
O servidor lê a configuração de reconswarm.yaml e escuta na porta configurada (padrão: 50051).
Submeta um pipeline a um servidor em execução:
reconswarm run -f examples/pipelines/nuclei.yaml
Opções:
-f, --pipeline — Caminho para o arquivo YAML do pipeline (obrigatório)-s, --server — Endereço do servidor (padrão: localhost:50051)reconswarm status <pipeline-id>
Execute um pipeline diretamente sem o servidor gRPC (útil para testes):
reconswarm manual -f examples/pipelines/nuclei.yaml
Este comando:
reconswarm.yamlworkers.max_workersA desalocação automática de infraestrutura garante total autonomia — todos os recursos em nuvem são provisionados, usados e destruídos sem intervenção manual, permitindo fluxos de trabalho de reconhecimento totalmente automatizados.
Para exemplos completos de pipeline, veja o diretório examples/pipelines.
Enumeração e varredura básica de subdomínios:
# pipeline.yaml
pipeline:
targets:
- value: "example.com"
type: crtsh
stages:
- name: "Escaneie os alvos"
type: exec
steps:
- "nmap -sC -sV -iL {{.Targets.filepath}} -oN /opt/recon/nmap-{{.Worker.Name}}.txt"
- name: "Coletar resultados"
type: sync
src: "/opt/recon/nmap-{{.Worker.Name}}.txt"
dest: "./results/nmap-{{.Worker.Name}}.txt"
Execute com:
reconswarm manual -f pipeline.yaml
# ou submeta ao servidor:
reconswarm run -f pipeline.yaml
Múltiplos alvos com varredura baseada em Docker:
pipeline:
targets:
- value: "example.com"
type: crtsh
- value: ["api.example.com", "www.example.com"]
type: list
stages:
- name: "Executar varredura nuclei"
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: "Copiar resultados nuclei"
type: sync
src: "/opt/recon/nuclei-{{.Worker.Name}}.json"
dest: "./results/nuclei-{{.Worker.Name}}.json"
Toolchain personalizado com múltiplos estágios:
Config do servidor (reconswarm.yaml):
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"
Config do pipeline (pipeline.yaml):
pipeline:
targets:
- value: "example.com"
type: crtsh
stages:
- name: "Enumeração adicional"
type: exec
steps:
- "cd subfinder && ./subfinder -dL {{.Targets.filepath}} -o /opt/recon/subfinder-{{.Worker.Name}}.txt"
- name: "Mesclar alvos"
type: exec
steps:
- "cat {{.Targets.filepath}} /opt/recon/subfinder-{{.Worker.Name}}.txt | sort -u > /opt/recon/all-targets-{{.Worker.Name}}.txt"
- name: "Escaneie alvos mesclados"
type: exec
steps:
- "nmap -sC -sV -iL /opt/recon/all-targets-{{.Worker.Name}}.txt -oN /opt/recon/scan-{{.Worker.Name}}.txt"
- name: "Coletar todos os resultados"
type: sync
src: "/opt/recon"
dest: "./results/{{.Worker.Name}}"
Nota: O estágio sync detecta automaticamente que /opt/recon é um diretório e copia recursivamente todos os arquivos e subdiretórios para o destino local.
Enumeração de subdomínios:
reconswarm crtsh-dump example.com
Busca e filtra subdomínios resolvíveis do crt.sh para um domínio dado.
Comando de depuração (para testar provisionamento de VM):
reconswarm debug
Compile e teste usando Task:
task build # Compilar binário
task test # Executar testes
task lint # Executar linter
task vet # Executar go vet
task ci # Executar todas as verificações de CI
notify — Enviar notificações ou alertas (webhooks, e-mail, Slack)conditional — Executar estágios com base nos resultados de estágios anterioresparallel — Executar múltiplas operações simultaneamente no mesmo workerretry — Reexecutar automaticamente operações com falha com backoff configuráveltimeout — Definir timeouts de execução por estágiovalidate — Validar resultados ou condições antes de prosseguirLicença MIT. Consulte o arquivo LICENSE para detalhes.
| Executar múltiplas instâncias do servidor atrás de um balanceador de carga |
| Reinicializações sem downtime | Reiniciar o servidor sem perder o estado do pipeline |
| Recuperação de falhas | Uma nova instância do servidor continua de onde a anterior parou |
| Inspeção de estado | Consultar o etcd diretamente para depuração e monitoramento |