O toolkit de bug bounty e a CLI da NotHoly

Você não precisa de um toolkit grande para começar. Precisa de um browser, um proxy, um terminal e um lugar para guardar notas e evidência. Este post monta essa lista curta e coloca um modelo de IA onde ele mais ajuda: no terminal, lendo a saída e propondo o próximo passo, enquanto cada comando roda na sua máquina sob a sua aprovação. Ele segue escolher um programa e leva a ler JavaScript com IA.

#A lista curta

Um browser e suas dev tools cobrem uma parte surpreendente do trabalho inicial. Um proxy como o mitmproxy deixa você observar e editar o tráfego entre o browser e o alvo. O terminal é onde vivem o agente e os scanners. As notas são onde um finding vira um relatório.

#A CLI da NotHoly no terminal

A CLI da NotHoly roda um agente no seu projeto. Ela lê e busca arquivos, roda um comando e chama ferramentas remotas de pesquisa, e por padrão pergunta antes de cada escrita e cada comando. Instale e faça login uma vez.

curl -fsSL https://notholy.com/install.sh | sh
notholy login
notholy --version

Rode dentro de um diretório de trabalho do programa. No modo ask, o padrão, o agente propõe um comando e espera o seu sim. No modo plan ele só lê. Comece no modo plan enquanto aprende o app.

notholy --mode plan -p "list the hosts and endpoints you can find in these notes"

O modelo nunca alcança um alvo pelo lado da NotHoly. Os comandos rodam local, do seu endereço, com a sua aprovação. Essa é a propriedade que você quer no bug bounty: o tráfego vem de onde o programa espera, e você consegue logar cada request.

#Registre o escopo com notholy engage

Antes de testar, registre o que o programa deixa você tocar. O notholy engage guarda o escopo da rodada e confere o alvo de cada comando contra ele.

notholy engage init --name acme-web --scope "*.example.com,api.example.com" --exclude vpn.example.com --until 2026-12-31
notholy engage status

Com um engagement ativo, o agente lê o host de cada comando antes dele rodar. Um alvo no escopo passa pela aprovação normal. Um alvo fora do escopo faz você digitar o host você mesmo, e o override é escrito em um log local. A checagem lê o texto do comando e não resolve DNS, então pega os seus erros e não é um sandbox. Ela transforma o escopo de algo que você tem que lembrar em algo que o terminal confere.

#Um proxy para ver cada request

Aponte o seu browser para um proxy local e você consegue ler, pausar, editar e reenviar cada request. É aqui que a maior parte do teste web acontece. Quando uma response parece estranha, copie o request cru e pergunte ao modelo o que ele significa e o que mudar em seguida. Você roda o request modificado pelo proxy você mesmo. O proxy também te dá o texto exato de request e response que um relatório precisa como evidência.

#Mantenha notas e evidência desde o primeiro request

Abra um arquivo de notas por programa antes de tocar em qualquer coisa. Para cada pista, salve o request, a response, a hora e o que você esperava contra o que viu. O modelo consegue rascunhar a partir dessas notas depois, e boas notas são a diferença entre um relatório que paga e um que o triager não reproduz. Mantenha a evidência fora de qualquer repositório público, e mantenha dados de cliente ou de programa fora de serviços compartilhados.

#Um home lab rápido

Rode o app, ou um build de demonstração dele, na sua própria máquina para aprender o comportamento sem mandar tráfego ao alvo ao vivo a cada pergunta. Como montar um home lab legal prepara um ambiente isolado para exatamente isso.

#A seguir nesta trilha

Com o terminal, o proxy e o escopo no lugar, vá para ler JavaScript com IA para achar endpoints. O OWASP Web Security Testing Guide é a referência do que testar depois de mapear a superfície.