Tu programa de bug bounty te protege de hallazgos, no de atacantes.
Los atacantes no tienen un alcance. Sin reglas de enfrentamiento. Sin "estas IPs están fuera de alcance." Sin "solo prueba la aplicación web." Lo miran todo. Subdominios, adquisiciones, integraciones de terceros, cuentas de empleados, esa VPN olvidada que nadie monitoriza. Todo vale.
Ahora mira cómo funcionan la mayoría de programas de bug bounty.
Dominios limitados. Listas de exclusiones largas. "No probar" en la mitad de la infraestructura. Lo que se prueba está seguro. Lo que no es donde ocurren las brechas.
He visto esto pasar más veces de las que puedo contar. Una empresa lanza un programa de bug bounty con un alcance reducido: dos dominios, una API, y una lista de exclusiones más larga que la propia lista de objetivos. Los hunters machacan esos dos dominios, encuentran alguna cosa de severidad media, y el equipo de seguridad se queda tranquilo. "Nuestro programa de bug bounty funciona."
Mientras tanto, el entorno de staging de 2021 sigue funcionando con credenciales por defecto. La herramienta interna que usa recursos humanos tiene una inyección SQL que nadie ha mirado. La empresa adquirida el año pasado todavía tiene su propia infraestructura, sin probar, conectada a la misma red.
Eso no es seguridad. Es teatro de seguridad.
Al atacante que acabe comprometiendo esa empresa le dará igual el alcance del bug bounty. Encontrará la VPN con el CVE conocido. Hará phishing a un empleado y pivotará desde ahí. Descubrirá el subdominio olvidado con Jenkins sin autenticación. El documento de alcance no significa nada para ellos.
Por eso siempre busco alcances a nivel de empresa y wildcard. Te permiten operar más cerca de cómo lo haría un atacante real. Sin límites artificiales. Superficie completa. Cuando un programa dice *.company.com, puedo probar las cosas que importan de verdad en vez de pelearme por los mismos cinco endpoints con otros 200 hunters.
Y ahí es donde el reconocimiento lo es todo.
Cuando el alcance es amplio, no puedes simplemente lanzar un escáner y empezar a hacer clic. Necesitas un proceso. Enumeración profunda de subdominios. Fingerprinting. Identificar activos olvidados, entornos de staging, sistemas legacy. Mapear lo que la empresa ni siquiera sabe que está expuesto.
Eso es lo que intento hacer con mi automatización de reconocimiento. Ir a lo ancho, ir a lo profundo, encontrar lo que nadie está mirando.
El proceso es algo así:
- Enumeración de subdominios cruzando múltiples fuentes, no solo una herramienta
- Escaneo de puertos en los hosts descubiertos para encontrar servicios en puertos no estándar
- Fingerprinting de tecnologías para identificar stacks desactualizados o vulnerables
- Rastreo en busca de paneles expuestos, páginas de login e interfaces de administración
- Comprobación de credenciales por defecto en cualquier cosa que parezca olvidada
- Correlacionar empresas adquiridas y su infraestructura con la empresa matriz
La mayoría de esto se ejecuta de forma automática. El trabajo manual viene después, cuando reviso los resultados y elijo los objetivos que parecen descuidados. Ahí es donde viven los hallazgos críticos.
He encontrado RCEs en servidores de staging que replicaban producción. He encontrado acceso completo a bases de datos a través de herramientas internas que nunca debieron ser públicas. He encontrado paneles de administración sin autenticación en subdominios que la empresa no sabía que existían.
Nada de eso estaba en la aplicación principal.
Si eres hunter, deja de limitarte a los objetivos obvios. Si un programa ofrece un alcance wildcard, úsalo. Si no lo tiene, busca programas que sí lo hagan. La competencia es menor, los hallazgos son mejores y los pagos son más altos.
Si eres una empresa, plantéatelo. Mira el alcance de tu bug bounty y pregúntate: "¿Esto refleja lo que un atacante atacaría de verdad?" Si la respuesta es no, no estás gestionando un programa de seguridad. Estás marcando una casilla de cumplimiento.
Deja de proteger tu alcance. Empieza a proteger tu superficie de ataque real.
