Cómo elegir tu primer objetivo de bug bounty: el sistema de los 3 filtros

TL;DR

La mayoría de los principiantes no abandonan el bug bounty por falta de habilidades. Lo abandonan porque eligen el objetivo equivocado. Elegir bien el objetivo es una habilidad que se aprende, y es más importante que conocer todos los payloads. Pasa cada programa por tres filtros antes de dedicarle una sola hora:

1. Tamaño del scope. Elige un objetivo que puedas mapear por completo en menos de 30 minutos.
2. Stack tecnológico. Investiga las tecnologías que ya entiendes.
3. Densidad de hunters. Elige programas donde compitas contra cinco hunters, no contra cinco mil.

Después ejecuta una checklist de recon de 2 horas, puntúa el objetivo sobre 30 y comprométete con un solo objetivo durante cuatro semanas. Así es como alcanzas el conocimiento profundo donde viven los bugs de verdad.

La elección del objetivo es la habilidad que nadie enseña

Esta es la verdad que nadie te cuenta. La mayoría de los principiantes no abandonan el bug bounty porque no sean lo bastante listos. Lo abandonan porque abren un programa con un scope enorme, pasan semanas ejecutando escáneres automatizados, no encuentran nada y asumen que no valen para este campo.

Elegir el objetivo es una habilidad. Es más importante que conocer todos los payloads de XSS. Es más importante que tener veinte herramientas instaladas. Cuando eliges un objetivo que encaja con tu nivel actual, encuentras bugs. Cuando eliges un objetivo demasiado grande, demasiado complejo o demasiado saturado, te quemas.

Yo lo aprendí por las malas. Al principio de mi carrera cazaba cualquier cosa que tuviera una recompensa. Perdí meses en objetivos demasiado grandes, demasiado complejos o demasiado saturados. En cuanto empecé a filtrar los objetivos antes de probarlos, mis resultados cambiaron al instante. Esa disciplina es la que me llevó a más de 250 entradas en Hall of Fame de organizaciones como la WHO, UNESCO, BBC, Boeing, Cambridge, Sheffield, Deutsche Börse, BASF, Michelin y Philips.

Esta guía convierte esa disciplina en un sistema sencillo y repetible. El sistema de los 3 filtros no es complicado y no requiere herramientas avanzadas. Solo requiere ser honesto sobre dónde estás ahora mismo como hunter. Pasa cada objetivo potencial por estas tres comprobaciones. Si un objetivo falla cualquiera de ellas, descártalo y busca otro.

1. Filtro 1: tamaño del scope (¿puedes mapearlo en 30 minutos?)

Para tus primeros diez bugs, elige un scope que quepa en una sola pantalla. Evita los scopes con comodín como *.target.com cuando empiezas. Busca scopes enfocados como api.target.com, dashboard.target.com, o endpoints y subdominios concretos listados en la política.

Por qué el tamaño del scope decide tus probabilidades

Un scope con comodín es una trampa para principiantes. Pasarás dos semanas mapeando miles de subdominios. Encontrarás un servidor antiguo, te ilusionarás y luego descubrirás que alguien lo reportó hace dos días usando automatización. Acabas de gastar ochenta horas para aprender que otro hunter es más rápido que tú.

Los scopes grandes también provocan fatiga de decisión. Cuando tienes diez mil subdominios, nunca desarrollas un conocimiento profundo de ninguna aplicación concreta. Saltas de un activo a otro. Pero los bugs de lógica viven en el conocimiento profundo. Los IDOR, las race conditions y la manipulación de precios los encuentran quienes entienden el flujo de negocio mejor que los propios desarrolladores.

Piénsalo así. Si alguien te pidiera encontrar un error en un solo capítulo de un libro, podrías hacerlo en una hora. Si te pidieran encontrar un error en algún punto de una biblioteca entera, vagarías durante días y probablemente no lo verías. Eso es exactamente lo que pasa cuando los principiantes cazan en scopes con comodín. El bug está ahí, pero estás mirando en demasiados sitios a la vez.

Un scope enfocado te obliga a entender cada funcionalidad. Aprendes cómo se registran los usuarios, cómo fluyen los pedidos, cómo se procesan los pagos y cómo se comparten los archivos. Ahí es donde se esconden los bugs de verdad. Cuando te sabes de memoria cada endpoint, empiezas a notar los comportamientos raros: un parámetro que cambia el comportamiento cuando lo modificas, un endpoint que no comprueba bien los permisos. Esos momentos solo ocurren cuando conoces la aplicación a fondo.

Cómo se ve esto en el mundo real

Un investigador de seguridad compartió su experiencia en Reddit tras ocho meses de fracaso. Era desarrollador web con buenos conocimientos técnicos. Cada vez que empezaba a cazar, listaba todos los subdominios de un objetivo grande y luego navegaba por ellos al azar. Usaba herramientas de enumeración de subdominios, crawlers y extractores de URLs de archivos. Tras encontrar endpoints, no sabía qué hacer a continuación. Escribió que sentía que tendría que pasar un año entero solo para encontrar un bug minúsculo. Estaba cazando en scopes enormes de programas populares sin un plan, y el tamaño del objetivo lo superaba por completo. Puedes leer el hilo aquí: Bug bounty is insanely hard. Am I doing something wrong?

Otro hunter escribió sobre el error que frenó su progreso durante meses. Perseguía programas enormes con scopes amplios, cambiaba de objetivo cada pocos días y nunca se comprometía a entender a fondo una aplicación. En cuanto se centró en scopes más pequeños y manejables, sus resultados cambiaron al instante: The Bug Hunting Mistake That Slowed My Progress.

Scopes ideales para principiantes

• api.target.com o mobile.target.com con menos subdominios y activos
• Endpoints concretos como /api/v1/users o /api/v1/orders
• Aplicaciones únicas con roles de usuario claros
• Tiendas online con flujos de carrito y checkout

La regla: si no puedes leer todos los endpoints del scope en treinta minutos, el objetivo es demasiado grande. Sáltalo.

2. Filtro 2: stack tecnológico (investiga lo que entiendes)

Elige objetivos en los que entiendas la lógica y el protocolo. Si nunca has tocado GraphQL, no elijas un objetivo cuya API entera sea nativa de GraphQL. Si no entiendes las aplicaciones móviles, sáltate los scopes móviles por ahora. Esas tecnologías puedes aprenderlas más adelante, pero no son por donde empiezas. Investiga lo que conoces.

Por qué un desajuste de tecnología mata la motivación

Cuando eliges un objetivo construido sobre una tecnología que no entiendes, pasas tu primera semana aprendiendo sintaxis en lugar de encontrar bugs. Pasas la segunda semana peleando con los conceptos. Para la tercera semana, estás frustrado y listo para abandonar.

Los principiantes suelen perseguir recompensas altas en objetivos difíciles. Un pago máximo de 50.000 dólares no significa nada si la aplicación corre sobre un stack que no puedes probar. Facebook, Google y Apple tienen seguridad de primer nivel y llevan más de una década siendo probados por los mejores hunters. Como principiante, lo más probable es que pases cien horas y no encuentres nada.

Compáralo con un hunter que entendía las APIs REST y los formularios web estándar y encontró un bug de manipulación de precios en un sitio PHP sencillo. La API de checkout era una simple petición POST. Sin microservicios, sin arquitectura compleja, solo un parámetro de precio enviado desde el lado del cliente. Cambió el precio de quinientos dólares a dos dólares, y el servidor lo aceptó. Ese bug no requería ningún código de exploit ni payloads especiales. Solo requería entender una simple petición POST y preguntarse por qué el precio venía del cliente. Eso es una clásica vulnerabilidad de lógica de negocio, y es justo el tipo de bug que puedes encontrar cuando tienes la mente libre para buscar fallos de lógica en lugar de pelear con lo básico.

Caso real: la barrera de GraphQL

Un principiante compartió públicamente la historia de su primera recompensa. Encontró un archivo JavaScript que contenía una clave de API de GraphQL en un objetivo con un scope enorme, y descubrió un endpoint /graphql mediante fuzzing de directorios. Pero había un problema: no sabía nada de GraphQL. Pasó varios días investigando, aprendiendo y recopilando herramientas solo para entender el esquema. Usó PortSwigger Academy para aprender lo básico y la extensión InQL de Burp para visualizar el esquema. Al final consiguió una recompensa de 700 dólares, pero la brecha tecnológica casi le hace abandonar antes de empezar. Si hubiera elegido un objetivo de API REST estándar, podría haber empezado a probar de inmediato. Historia completa: How I Got My First Bounty.

Stacks aptos para principiantes

• APIs REST estándar con endpoints GET y POST claros (consulta nuestra guía de pruebas de seguridad de APIs)
• Aplicaciones web tradicionales con roles de usuario como Admin, User y Guest
• Flujos de ecommerce con pasos de carrito, checkout y pago
• Plataformas con funciones de equipo o de invitación

Stacks que evitar como principiante

• Uso intensivo de WebSocket. Difícil de probar sin herramientas a medida.
• GraphQL con autorización compleja. Curva de aprendizaje pronunciada.
• Internet de las cosas o scopes de hardware. Requiere dispositivos físicos.
• Blockchain o scopes de smart contracts. Un conjunto de habilidades completamente distinto.

Si todavía estás construyendo los fundamentos, dedica tiempo primero a un laboratorio en casa y a la PortSwigger Web Security Academy. Ambos te permiten practicar con los stacks anteriores sin ningún riesgo legal.

3. Filtro 3: densidad de hunters (evita la multitud)

Busca programas donde la competencia sea baja pero el scope sea real. Evita la avalancha de los programas populares. Busca programas de divulgación de vulnerabilidades con listas de Hall of Fame pequeñas, y programas más nuevos que aún no estén exprimidos.

Por qué la densidad es un multiplicador oculto

Una densidad alta de hunters significa probabilidades bajas. Cuando cinco mil hunters miran el mismo objetivo, tu probabilidad de encontrar un bug nuevo cae casi a cero. Los bugs fáciles se encontraron el primer día. Los bugs medios se encontraron en la primera semana. Lo que queda requiere una pericia profunda o condiciones muy específicas.

Los programas populares de las grandes plataformas son como caladeros abarrotados. Todo el mundo echa el sedal, y las grandes capturas son raras. En los programas más saturados, una gran parte de los informes que llegan se cierran como duplicados, lo que significa que incluso un hallazgo válido puede no reportarte nada.

Los programas ocultos son tu arma secreta. Algunos de los mejores objetivos para principiantes no están en las portadas de HackerOne ni de Bugcrowd. Son programas de divulgación responsable enterrados en la página de seguridad de una empresa, o autoalojados mediante un archivo security.txt en el sitio web de la empresa. Estos programas quizá no paguen dinero, pero ofrecen entradas en el Hall of Fame, swag, reputación y experiencia. Y lo más importante: tienen muy poca competencia. Una empresa que gestiona un VDP a través de su propio sitio web podría tener solo cinco o diez hunters que le hayan reportado alguna vez. Compáralo con un programa estrella con cinco mil hunters. ¿Dónde preferirías invertir tus dos semanas?

Caso real: doce nombres en el Hall of Fame

Un hunter consiguió su primera recompensa de 1.000 dólares evitando la multitud por completo. En lugar de lanzarse a un programa popular, eligió un programa público maduro y, tras casi dos meses, volvió a sus notas y revisó de nuevo robots.txt. Encontró una ruta no permitida que apuntaba a un panel de administración que devolvía un 403, lo que confirmaba que el recurso existía, y luego encontró la manera de saltarse la restricción. El detalle clave es que eligió un objetivo enfocado y de poca competencia, lo que le permitió dedicar tiempo a detalles como robots.txt sin preocuparse de que quinientos hunters más ya los hubieran revisado: My First Bug Bounty: How I Earned $1,000.

Otro investigador encontró un VDP fintech con exactamente doce nombres en el Hall of Fame y un scope de solo dos APIs. Como la competencia era tan baja, probó a fondo cada funcionalidad durante dos semanas y encontró tres bugs válidos en funciones secundarias que otros hunters habían pasado por alto. En un programa con quinientos hunters activos, esos bugs habrían desaparecido en la primera semana.

Cómo medir la densidad de hunters

1. Revisa la página del Hall of Fame. Si tiene más de 200 nombres, el programa está saturado. De diez a cincuenta nombres significa que tienes margen para trabajar.
2. Fíjate en la antigüedad del programa. Un programa lanzado hace seis meses con trescientos informes resueltos probablemente esté exprimido. Un programa lanzado hace tres semanas con cinco informes está fresco.
3. Comprueba la última actividad. Si el último informe resuelto fue ayer, hay hunters trabajándolo activamente. Si el último informe fue hace tres semanas, los hunters han seguido adelante pero los bugs podrían seguir ahí.

Encontrar programas ocultos con Google dorks

El Google dorking usa operadores de búsqueda avanzados para sacar a la luz programas con poca competencia:

site:com inurl:responsible-disclosure
site:de inurl:security.txt
inurl:.well-known/security.txt "contact"
site:io "report a vulnerability"

Cuando encuentres un archivo security.txt (estandarizado como RFC 9116), léelo con atención. Si lista un contacto y una página de agradecimientos, has encontrado un objetivo con prácticamente cero competencia.

4. Ejecuta una checklist de recon de 2 horas antes de probar

Una vez que un objetivo pasa los tres filtros, no empieces a disparar payloads. Dedica dos horas a un reconocimiento estructurado. Si no puedes responder a estas preguntas en 120 minutos, el objetivo es demasiado complejo o tus notas necesitan trabajo.

Hora 1: mapea la superficie de ataque

Tu objetivo en la primera hora es entender toda la superficie de ataque, no encontrar bugs todavía.

• Registra dos cuentas. Necesitas dos cuentas para probar IDOR y otros problemas de control de acceso.
• Identifica todos los roles de usuario. Guest, User, Admin, Vendor. ¿Puede uno escalar a otro?
• Lista cada funcionalidad. Login, restablecimiento de contraseña, actualización de perfil, subida de archivos, compartición, checkout.
• Encuentra la documentación de la API. Busca colecciones de Swagger o Postman, o lee las llamadas JavaScript del frontend.

Hora 2: tantea la fruta madura

• Flujo de restablecimiento de contraseña. ¿Es predecible el token? ¿Puedes hacerle fuerza bruta?
• Subida de archivos. ¿Hay filtrado por extensión? ¿Puedes subir HTML o JavaScript?
• Actualización de perfil. ¿Puedes cambiar tu email por el de un usuario existente?
• Flujos de compartición o invitación. ¿Puedes invitarte a ti mismo al recurso de otro usuario?
• Flujo de checkout o pago. ¿El precio final se envía desde el cliente?

Si terminas esta checklist y no encuentras nada, no abandones. Solo has probado la superficie. Pero si encuentras aunque sea un comportamiento raro, como un 200 OK en un ID modificado o la falta de rate limit, tienes una pista. Sigue esa pista. ¿Eres nuevo con las herramientas de recon? Empieza con nuestro tutorial de Nmap y los comandos esenciales de Linux.

5. Puntúa cada objetivo con la Tabla de puntuación de objetivos

Usa esta tabla de puntuación para cada objetivo antes de dedicarle una sola hora. Lleva cinco minutos y te ahorrará semanas de esfuerzo desperdiciado.

Guía de puntuación:

• 25 a 30: objetivo de primera. Comprométete cuatro semanas.
• 18 a 24: aceptable. Bueno para aprender, pero gestiona tus expectativas.
• Por debajo de 18: descártalo. Busca algo mejor. Tu tiempo vale demasiado.

Guarda esta tabla en tus notas y ejecútala antes de cada nuevo objetivo.

6. Comprométete con un objetivo durante cuatro semanas

Una vez que un objetivo pasa los filtros y supera la tabla de puntuación, comprométete con él durante cuatro semanas. No añadas un segundo objetivo hasta que hayas dedicado cuatro semanas completas al primero.

La mayoría de los principiantes son turistas de objetivos. Cazan un programa durante tres días, no encuentran nada y se pasan al siguiente. Nunca desarrollan el conocimiento profundo necesario para encontrar fallos de lógica. Y los bugs de lógica no se revelan el día tres. Se revelan el día diez, cuando notas que el endpoint de borrado de cuenta se comporta de forma distinta si lo envías dos veces. Se revelan el día veinte, cuando te das cuenta de que la API móvil tiene un parámetro que la aplicación web nunca usa. Se revelan el día treinta, cuando entiendes el flujo de negocio mejor que el desarrollador.

Esta disciplina es incómoda. Se siente lenta. Pero es así como construyes el reconocimiento de patrones que más tarde hace que cazar parezca sin esfuerzo. Si no encuentras ningún bug en cuatro semanas, revisa tus notas antes de seguir adelante. ¿Se te pasó una funcionalidad? ¿Te saltaste un flujo? Solo entonces plantéate cambiar.

7. Dónde encaja el bug bounty en tu carrera más amplia

El bug bounty es una de las formas más rápidas de demostrar habilidad en seguridad ofensiva en público, pero rara vez es toda la historia. La misma disciplina de elección de objetivos (foco, profundidad y paciencia) es lo que los empleadores buscan en los pentesters y en los miembros de red team. Si estás construyendo una carrera, combina tu caza con un aprendizaje estructurado: una ruta profesional en ciberseguridad clara, las certificaciones adecuadas para principiantes y la prueba de que sabes trabajar de forma segura, que construyes en un laboratorio de ciberseguridad en casa. ¿Cambias de campo sin formación reglada? Mira cómo la gente entra sin titulación.

Lee informes divulgados cada semana para entrenar tu reconocimiento de patrones. La PortSwigger Web Security Academy y las páginas del proyecto OWASP son gratuitas, autorizadas y se corresponden directamente con los bugs que vas a cazar.

Conclusión: pon las probabilidades a tu favor

El bug bounty no es una lotería. Se trata de poner las probabilidades a tu favor.

No necesitas hackear Google para ser un hacker de verdad. Necesitas encontrar un objetivo que encaje con tus habilidades actuales, entenderlo a fondo y cazar donde los demás no están mirando. El sistema de los 3 filtros convierte el adivinar al azar en un proceso. El tamaño del scope te mantiene enfocado. El stack tecnológico te mantiene eficaz. La densidad de hunters te mantiene competitivo.

Tu primera entrada en el Hall of Fame está escondida en una API enfocada, en un programa con otros doce hunters, en un flujo de lógica de negocio que a nadie más se le ocurrió probar. Usa los filtros. Usa la tabla de puntuación. Comprométete cuatro semanas. Ve a encontrarla.