Bug bounty con un copiloto de IA: el loop

Bug bounty es prueba pagada dentro de los límites que fija un programa. Esta serie te lleva de cero a un primer reporte válido, con un modelo de IA haciendo la lectura y el borrador mientras tú te quedas con el criterio y con cualquier cosa que llegue a un objetivo. Este primer post es el loop que repites en cada programa. El resto de la serie entra a fondo en cada etapa y luego arma un pequeño agente que corre parte del loop por ti.

Un modelo es un lector rápido y un redactor decente, sin memoria de tu scope y sin nada en juego en tu cuenta. Resume una política, ordena una lista de endpoints, explica una response rara y redacta un reporte. También inventa un endpoint, lee mal un status code y suena seguro mientras lo hace. Tratas su salida como una pista, nunca como un finding.

#El loop

El trabajo es un loop de cinco etapas. Lo corres una vez en un programa, luego otra vez en el siguiente activo, luego otra vez en la siguiente clase de bug. El modelo ayuda en cada etapa. No decide qué está en el scope y no envía un request a un objetivo por ti.

Etapa	Lo que haces	Dónde ayuda el modelo
Elegir	Escoger un programa y un activo	Resumir la política, marcar cláusulas raras
Scope	Leer qué está dentro y qué está fuera	Volver una política larga en un checklist corto
Recon	Mapear la superficie que puedes tocar	Ordenar endpoints, leer JS, sugerir parámetros
Test	Enviar requests y leer responses	Explicar una response, proponer el siguiente caso
Reporte	Escribir el texto	Redactar los pasos mientras confirmas cada línea

#Elige un programa y lee el scope

Un programa es una oferta pública para probar activos nombrados bajo reglas nombradas. Antes que nada lees la política entera: los dominios y apps dentro del scope, los que están fuera, las clases que no paga y los límites de rate y de automatización. Pega la política en un chat y pídele al modelo que liste hosts dentro del scope, hosts fuera del scope y cualquier regla que haría que un reporte se cierre. Luego lee la política tú mismo, porque un resumen equivocado aquí es el tipo de error que termina una cuenta. Cómo elegir tu primer programa explica a fondo cómo leer un scope.

#Recon sin tocar hosts fuera del scope

El recon mapea la superficie que el programa te deja probar. Reúnes subdominios, endpoints y parámetros, y decides dónde es probable un bug. El modelo sirve para leer, no para alcanzar: agrupa una lista desordenada de endpoints, lee un bundle de JavaScript minificado y señala parámetros que valen una prueba. Mantén todo scan y request en los hosts que el scope lista. Para las herramientas, el post del toolkit arma un terminal que te mantiene dentro del scope.

#Prueba, y confirma antes de creerlo

La prueba es donde el principiante pierde tiempo con falsos positivos. El modelo dirá que una response parece un IDOR o un XSS. A veces acierta. Confirmas a mano: reproduce el request, cambia una cosa, observa la response y guarda el request y la response exactos que lo prueban. Un bug que no reproduces cuando quieres todavía no es un bug. Probar bugs web comunes con ayuda de IA recorre IDOR, XSS, SSRF y auth rota, e incluye cómo evitar los falsos positivos que el modelo te entrega.

#Escribe el reporte

Un reporte tiene que dejar que un extraño reproduzca el bug y entienda el impacto. El modelo redacta bien a partir de tus notas: dale el request, la response y el efecto, y produce un texto limpio. Luego confirmas cada paso, cada URL y cada afirmación de impacto, porque el triager lo hará. Escribir reportes que pagan tiene la estructura y el checklist de revisión.

#En qué es bueno el modelo, y dónde miente

Los modelos leen rápido, traducen jerga y mantienen un cerebro cansado andando a las dos de la mañana. También alucinan endpoints, exageran la severidad para parecer útiles y confunden CVEs parecidos. El OWASP Top 10 para Aplicaciones de LLM cataloga estos modos de fallo. La regla que te protege es simple: el modelo propone, tú decides. Nada de lo que escribe llega a un programa antes de que lo reproduzcas.

#Lo siguiente en esta serie

Lee cómo elegir tu primer programa y luego arma el toolkit y el terminal. El caso de uso de bug bounty y la OWASP Web Security Testing Guide son las dos referencias que vale dejar abiertas todo el tiempo. Los posts siguientes arman un hackbot que corre recon y pruebas en tu máquina, bajo tu aprobación, usando la CLI de NotHoly.