Do setup ao recon: como estruturei meu pipeline de bug bounty no CachyOS (Arch Linux)

Montando o ambiente: metodologia e decisões de infraestrutura#

Quando decidi me aprofundar no ecossistema de Bug Bounty, a primeira grande decisão técnica não foi qual programa escolher em plataformas como HackerOne ou Bugcrowd, mas sim como estruturar meu ambiente de trabalho e minha metodologia de caça.

Configurei meu ambiente em um notebook com CachyOS (distribuição baseada em Arch com otimizações de kernel e agendamento de tarefas). Por ser um sistema extremamente rápido para compilação e execução paralela, o setup se mostrou perfeito para automações de linha de comando.

No entanto, logo de cara surgiu uma dúvida comum: devo caçar bugs manualmente ou automatizar tudo via Inteligência Artificial? E, na prática, como transformar ferramentas de terminal em um pipeline de Reconnaissance (Recon) eficiente?

Abaixo, compartilho as decisões tomadas, as ferramentas configuradas e o script em Bash que criei para mapear alvos.

1. O dilema: caça manual vs. automação por IA#

A tentação de tentar criar um robô autônomo com LLMs para caçar vulnerabilidades no piloto automático é grande, mas a prática da segurança ofensiva desmonta essa ideia rapidamente:

1. Volume de ruído e falsos positivos: Ferramentas 100% automáticas e IAs genéricas geram muitas alucinações e alertas sem contexto real de exploração. Enviar relatórios assim só queima sua reputação nas plataformas.
2. A lógica de negócios é humana: Vulnerabilidades críticas (como quebra de controle de acesso IDOR/BOLA ou falhas complexas em regras de negócio) exigem intuição humana e entendimento do fluxo real do sistema.
3. Assimetria de ferramentas: Qualquer falha óbvia que um script simples de botão único encontre já foi corrigida pela esteira interna da empresa ou reportada por outros caçadores.

O papel da IA no meu fluxo: copilota técnica#

Em vez de deixar a IA operando sozinha, posicionei os modelos como apoio pontual:

• Análise estática assistida (SAST): Em programas de caixa-branca (whitebox), uso a IA para acelerar a leitura de trechos densos de código-fonte em busca de falhas em blocos de validação.
• Geração de scripts rápidos de PoC (Proof of Concept): Criação ágil de pequenos scripts em Python para testar parâmetros específicos e coletar códigos HTTP.
• Dissecação técnica: Auxílio para entender o funcionamento de bibliotecas legadas ou formatos de criptografia específicos encontrados no alvo.

2. O arsenal de recon no CachyOS / Arch Linux#

Cerca de 70% do sucesso no Bug Bounty está na fase de Reconnaissance (Recon): encontrar subdomínios legados, ambientes de homologação (staging) desprotegidos e portas esquecidas.

Aproveitando o AUR (Arch User Repository), instalei ferramentas modernas compiladas em Go e C, sem precisar de máquinas virtuais pesadas:

# Descoberta passiva de subdomínios e DNS
yay -S subfinder amass assetfinder findomain

# Sondagem HTTP ativa e varredura de portas
yay -S httpx-bin nmap naabu-bin

# Fuzzing de diretórios e arquivos expostos
yay -S gobuster dirsearch-git

3. O pipeline de recon em formato de funil#

Para economizar banda e tempo de processamento, estruturei a análise em três etapas lógicas:

[ Domínio Raiz ]
       │
       ▼ (1. Coleta Passiva de Subdomínios)
[ Lista Bruta de Subdomínios ]
       │
       ▼ (2. Sondagem HTTP com httpx)
[ Hosts Vivos + Status Code + Tecnologias ]
       │
       ▼ (3. Varredura Rápida de Portas com Naabu)
[ Superfície de Ataque Mapeada ]

Etapa 1: Coleta passiva de subdomínios#

Consulta bases públicas (certificados SSL em crt.sh, DNS histórico e APIs) sem enviar pacotes diretos aos servidores do alvo:

# Execução de ferramentas passivas
subfinder -d domain.com.br -silent > subs_subfinder.txt
assetfinder --subs-only domain.com.br > subs_assetfinder.txt

# Unificação e remoção de duplicados
cat subs_subfinder.txt subs_assetfinder.txt | sort -u > subs_unicos.txt

Etapa 2: Verificação de hosts vivos com httpx#

O httpx testa conexões nas portas 80 e 443, identificando o código de resposta, título da página e as tecnologias em uso:

httpx -l subs_unicos.txt -silent -status-code -title -tech-detect -o hosts_ativos.txt

• Foco analítico: Respostas 403 Forbidden (possíveis painéis administrativos acessíveis com bypass de cabeçalhos) e 500 Internal Server Error (erros de runtime que vazam informações internas).

Etapa 3: Varredura de portas com naabu e nmap#

Para evitar a lentidão de rodar o nmap completo contra centenas de hosts, uso o naabu para uma varredura rápida nas 100 portas mais comuns e, apenas sobre o que for encontrado aberto, rodo o nmap para detecção de versão:

# Varredura rápida assíncrona
naabu -list subs_unicos.txt -top-ports 100 -o portas_abertas.txt

# Detecção aprofundada apenas nos alvos filtrados
nmap -sV -sC -p 80,443,8080,8443 -iL subs_unicos.txt -oN scan_nmap.txt

4. O script de automação: recon.sh#

Para rodar essa rotina de forma limpa em alvos autorizados, consolidei o fluxo neste script em Bash:

#!/bin/bash
DOMAIN=$1

if [ -z "$DOMAIN" ]; then
    echo "[-] Erro: Parâmetro de domínio ausente."
    echo "Uso correto: ./recon.sh domain.com.br"
    exit 1
fi

echo "[+] Iniciando Recon para o alvo: $DOMAIN"

# 1. Coleta passiva de subdomínios
echo "[+] Coletando subdomínios passivamente..."
subfinder -d "$DOMAIN" -silent > subs.txt
assetfinder --subs-only "$DOMAIN" >> subs.txt
sort -u subs.txt -o subs_clean.txt
echo "[+] Subdomínios únicos encontrados: $(wc -l < subs_clean.txt)"

# 2. Sondagem de hosts ativos e tecnologias
echo "[+] Identificando hosts ativos e metadados HTTP..."
httpx -l subs_clean.txt -silent -sc -title -td -o ativos.txt

echo "[+] Recon concluído com sucesso. Resultados salvos em 'ativos.txt'."

Como executar:#

chmod +x recon.sh
./recon.sh domain.com.br

Próximos passos e boas práticas no bug bounty#

Com o pipeline estruturado, o foco prático passa a ser:

• Treinamento prático: Praticar a exploração manual em laboratórios como o PortSwigger Web Security Academy e dominar o OWASP Top 10.
• Atenção total ao escopo: Em plataformas como HackerOne e Bugcrowd, leia sempre as regras do programa antes de disparar ferramentas ativas para respeitar limites de requisição (rate limits).
• Começar por programas VDP: Programas de divulgação de vulnerabilidades focados em pontos/reputação têm menor concorrência e são excelentes para validar relatórios e construir experiência real.

Automatizar as tarefas repetitivas de terminal libera tempo para o que realmente gera resultados: a análise cuidadosa da lógica de cada aplicação.

Veja também

Cibersegurança Do monorepo de IA ao reconnaissance com Google dorking: troubleshooting real no lab Linux

Cibersegurança Arquitetura desacoplada do Imunify email: engenharia reversa de thresholds e monitoramento de quarentena

Cibersegurança Debugando o httpx no stack ProjectDiscovery conflitos de binário go modules e PATH

Este post está licenciado sob CC BY-NC.