El toolkit de bug bounty y la CLI de NotHoly

No necesitas un toolkit grande para empezar. Necesitas un navegador, un proxy, un terminal y un lugar para guardar notas y evidencia. Este post arma esa lista corta y pone un modelo de IA donde más ayuda: en el terminal, leyendo la salida y proponiendo el siguiente paso, mientras cada comando corre en tu máquina bajo tu aprobación. Sigue a elegir un programa y lleva a leer JavaScript con IA.

#La lista corta

Un navegador y sus dev tools cubren una cantidad sorprendente del trabajo temprano. Un proxy como mitmproxy te deja ver y editar el tráfico entre el navegador y el objetivo. El terminal es donde viven el agente y los scanners. Las notas son donde un finding se vuelve un reporte.

#La CLI de NotHoly en el terminal

La CLI de NotHoly corre un agente en tu proyecto. Puede leer y buscar archivos, correr un comando y llamar herramientas de investigación remotas, y por defecto pregunta antes de cada escritura y cada comando. Instálala e inicia sesión una vez.

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

Córrela dentro de un directorio de trabajo para el programa. En modo ask, el de por defecto, el agente propone un comando y espera tu sí. En modo plan solo lee. Empieza en modo plan mientras aprendes la app.

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

El modelo nunca llega a un objetivo desde el lado de NotHoly. Los comandos corren local, desde tu dirección, con tu aprobación. Esa es la propiedad que quieres para bug bounty: el tráfico sale de donde el programa lo espera, y puedes registrar cada request.

#Graba el scope con notholy engage

Antes de probar, graba lo que el programa te deja tocar. notholy engage guarda el scope de la corrida y chequea el objetivo de cada comando contra él.

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

Con un engagement activo, el agente lee el host de cada comando antes de que corra. Un objetivo dentro del scope pasa por la aprobación normal. Un objetivo fuera del scope te hace escribir el host tú mismo, y el override queda escrito en un log local. El chequeo lee el texto del comando y no resuelve DNS, así que atrapa tus errores y no es un sandbox. Vuelve el scope, de algo que tienes que recordar, en algo que el terminal chequea.

#Un proxy para ver cada request

Apunta tu navegador a un proxy local y puedes leer, pausar, editar y reenviar cada request. Aquí es donde pasa la mayor parte de las pruebas web. Cuando una response se ve rara, copia el request crudo y pregunta al modelo qué significa y qué cambiar después. El request cambiado lo corres tú mismo por el proxy. El proxy también te da el texto exacto de request y response que un reporte necesita como evidencia.

#Guarda notas y evidencia desde el primer request

Abre un archivo de notas por programa antes de tocar nada. Por cada pista, guarda el request, la response, la hora y lo que esperabas frente a lo que viste. El modelo puede redactar desde estas notas después, y unas buenas notas son la diferencia entre un reporte que paga y uno que el triager no puede reproducir. Mantén la evidencia fuera de cualquier repositorio público, y mantén los datos de cliente o de programa fuera de servicios compartidos.

#Un home lab rápido

Corre la app, o un build de demo de ella, en tu propia máquina para aprender su comportamiento sin mandar tráfico al objetivo vivo por cada pregunta. Cómo armar un home lab legal arma un entorno aislado para exactamente esto.

#Lo siguiente en esta serie

Con el terminal, el proxy y el scope en su lugar, pasa a leer JavaScript con IA para hallar endpoints. La OWASP Web Security Testing Guide es la referencia de qué probar una vez que mapeaste la superficie.