Google Dorks para bug bounty: recon con buscadores (guía + ejemplos)

Respuesta rápida: Los Google Dorks son búsquedas avanzadas que usan operadores especiales (site:, inurl:, filetype:, intext:...) para encontrar información expuesta que un buscador normal esconde: paneles de login, archivos sensibles, subdominios olvidados o datos filtrados. En bug bounty son una técnica de reconocimiento pasivo potentísima, siempre que la uses solo dentro del scope de un programa.

¿Qué son los Google Dorks?

Un Google Dork (o Google hacking) es una consulta que aprovecha los operadores de búsqueda de Google para filtrar el índice y sacar a la luz páginas y archivos que normalmente no encontrarías navegando. Google ha rastreado media internet; los dorks son la forma de preguntarle exactamente lo que te interesa.

La idea no es hackear Google: es hackear con Google. Muchas empresas exponen sin querer paneles de administración, copias de seguridad, credenciales en archivos de configuración o endpoints internos que el buscador ha indexado. Un dork bien construido los encuentra en segundos, sin lanzar ni una sola petición contra el objetivo (por eso es recon pasivo).

Para un bug bounty hunter, los dorks son una de las primeras cartas del reconocimiento: baratos, rápidos y sorprendentemente efectivos.

¿Qué operadores de búsqueda debes conocer?

Estos son los ladrillos con los que se construye cualquier dork:

Se combinan libremente. La gracia está en encadenarlos para acotar cada vez más:

site:target.com inurl:admin
site:target.com filetype:pdf intext:"confidential"
site:target.com -www -shop

Dorks para bug bounty (ejemplos por objetivo)

Sustituye target.com por el dominio que tengas en scope. Estos son patrones habituales:

Exposición de información sensible

# Directorios listables (open directory listing)
site:target.com intitle:"index of"

# Archivos de configuración y variables de entorno
site:target.com ext:env OR ext:ini OR ext:conf
site:target.com filetype:log

# Documentos internos filtrados
site:target.com filetype:pdf intext:"internal" OR intext:"confidential"

# Backups y volcados de base de datos
site:target.com ext:sql OR ext:bak OR ext:old OR ext:backup

Paneles de login y administración

site:target.com inurl:admin
site:target.com inurl:login
site:target.com intitle:"admin panel" OR intitle:"dashboard"
site:target.com inurl:wp-admin

Un panel de administración indexado es un punto de entrada evidente: apunta a fallos de control de acceso e IDOR, credenciales por defecto o autenticación débil.

Archivos y parámetros interesantes

# Endpoints con parámetros (candidatos a probar)
site:target.com inurl:"id="
site:target.com inurl:"redirect=" OR inurl:"url=" OR inurl:"next="

# Claves y tokens expuestos en archivos JS o de texto
site:target.com ext:js intext:"api_key" OR intext:"apikey"

Los parámetros tipo url= o redirect= son pistas clásicas de open redirect y de SSRF; un id= numérico invita a probar IDOR.

Enumerar subdominios y activos olvidados

# Subdominios indexados (excluyendo el principal)
site:*.target.com -www

# Entornos de desarrollo y pruebas que no deberían estar públicos
site:target.com inurl:dev OR inurl:staging OR inurl:test

Los subdominios de dev, staging o test suelen tener menos protecciones que producción y son terreno fértil.

Dorks en otros buscadores y en GitHub

Google no es el único índice. La misma filosofía se aplica en:

• Bing / DuckDuckGo: operadores parecidos; a veces indexan cosas que Google no.
• GitHub Dorking: buscar en el código público filtraciones de la empresa (org:targetorg filename:.env, "target.com" api_key). Los desarrolladores suben secretos a repositorios más de lo que crees.
• Shodan / Censys: en lugar de páginas, indexan servicios y dispositivos expuestos (puertos, banners, bases de datos). Complementan perfectamente a los dorks web.

Amplío estas fuentes en la guía de técnicas de recon avanzadas.

Dorks para tecnologías concretas y mensajes de error

Otro filón: buscar por las huellas que dejan tecnologías conocidas o los errores que revelan la tripa de la aplicación.

# Paneles y software concreto
site:target.com inurl:phpmyadmin
site:target.com intitle:"Grafana"
site:target.com inurl:jenkins

# Mensajes de error que filtran rutas o consultas
site:target.com intext:"sql syntax near"
site:target.com intext:"stack trace" OR intext:"exception"

# Documentación de API expuesta
site:target.com inurl:swagger OR inurl:"api-docs"

Un error de SQL indexado sugiere una posible SQL injection; un stack trace filtra rutas internas y versiones; un Swagger público te regala el mapa entero de la API (perfecto para buscar IDOR endpoint por endpoint).

Combos que suben la puntuación

Encadenar operadores es donde está la magia. Algunos combos que suelen dar frutos:

# Archivos de texto con credenciales
site:target.com ext:txt intext:"password" OR intext:"pwd"

# Formularios de subida (candidatos a file upload)
site:target.com inurl:upload

# Parámetros de inclusión de ficheros (candidatos a LFI)
site:target.com inurl:"file=" OR inurl:"page=" OR inurl:"path="

Un parámetro file= o page= es un clásico candidato a LFI; un formulario de subida invita a probar file upload. El dork solo te lleva a la puerta; abrirla depende de que reconozcas el patrón.

¿Cómo automatizar los dorks?

Lanzar dorks a mano está bien para empezar, pero se vuelve lento con muchos objetivos. Formas de escalarlo, siempre con cabeza para que no te bloquee el buscador:

• Google Hacking Database (GHDB): el repositorio de Exploit-DB con miles de dorks clasificados. Úsalo como catálogo del que copiar y adaptar.
• Combina dorks con una lista de dominios. Con una lista de dorks y otra de dominios en scope puedes generar todas las combinaciones y revisarlas de forma ordenada.
• Herramientas de dorking. Existen scripts que automatizan consultas, pero respeta los límites del buscador: consultas masivas y agresivas acaban en captchas o bloqueos temporales de IP. El dorking es una técnica quirúrgica, no un escáner a lo bestia.
• No te quedes solo en Google. Bing, DuckDuckGo, Yandex y los buscadores de código indexan cosas distintas. Y para infraestructura, Shodan y Censys son el equivalente a los dorks pero sobre servicios y puertos.

La automatización te da volumen, pero el criterio sigue siendo humano: de 200 resultados, el valor está en los 3 que tú reconoces como potencialmente vulnerables. Ese ojo se entrena estudiando fallos reales, no acumulando listas de dorks.

Uso ético: solo dentro del scope

Punto no negociable. Buscar con Google es legal, pero actuar sobre lo que encuentres no siempre lo es:

• Solo aplica dorks a dominios que estén en el scope de un programa de bug bounty o de un pentest autorizado.
• Encontrar no es acceder. Que Google te muestre un backup o un panel no te autoriza a descargarlo ni a entrar si está fuera de scope o pertenece a un tercero.
• No toques datos reales de usuarios. Si un dork revela información personal, documenta la exposición y repórtala; no la extraigas ni la conserves.
• Cuando dudes, no lo hagas y pregunta al equipo del programa.

La frontera entre reconocimiento legítimo y delito es, otra vez, la autorización. Un dork que encuentra una filtración en una empresa sin programa no es un hallazgo de bug bounty: es información que no te corresponde tocar.

¿Cómo encajan los dorks en tu metodología de recon?

Los dorks no son un fin en sí mismos: son una fase temprana del reconocimiento. Un flujo típico:

1. Define el scope. Lista exacta de dominios y subdominios permitidos.
2. Recon pasivo con dorks. Busca paneles, archivos, parámetros y subdominios indexados sin tocar el objetivo.
3. Cruza con otras fuentes: enumeración de subdominios, análisis de JavaScript, Wayback Machine, GitHub. Todo eso está en técnicas de recon avanzadas.
4. Prioriza objetivos. De todo lo encontrado, elige lo que huele a fallo: un panel viejo, un parámetro url=, un subdominio de staging.
5. Pasa a la fase activa. Ahí ya interceptas con Burp y pruebas vulnerabilidades concretas, idealmente reconociendo patrones que hayas entrenado antes en labs de casos reales.

Los dorks te dicen dónde mirar; el conocimiento de vulnerabilidades te dice qué probar cuando llegas. Sin lo segundo, un buen dork solo te da una URL que no sabes explotar. Por eso conviene entrenar el patrón de fallos en la Academy en paralelo al recon.

Preguntas frecuentes (FAQ)

¿Es legal usar Google Dorks?
Buscar es legal. Lo que puede no serlo es acceder, descargar o explotar lo que encuentres si está fuera de scope o pertenece a un tercero sin autorización. Úsalos solo sobre objetivos permitidos.

¿Los dorks siguen funcionando en 2026?
Sí. Google ajusta su índice y a veces retira resultados sensibles, pero el reconocimiento con operadores sigue siendo una técnica viva y muy usada por hunters y equipos de seguridad.

¿Dónde encuentro listas de dorks?
La Google Hacking Database (GHDB) de Exploit-DB recopila miles de dorks por categoría. Úsala como inspiración, pero adapta siempre las consultas a tu objetivo concreto.

¿Los dorks sustituyen a las herramientas de recon?
No, las complementan. Son la parte pasiva y manual; las herramientas de enumeración automatizan y amplían la superficie. Lo mejor es combinarlos.

¿Cuál es el mejor operador para empezar?
site: combinado con inurl: o filetype:. Con esos tres cubres la mayoría de casos útiles: acotar al dominio en scope y filtrar por rutas o por tipo de archivo interesante. El resto son refinamientos.

¿Puedo hacer que me indexen mi propia web para probar dorks?
Sí, y es la forma más segura de practicar: monta un entorno propio o usa una web deliberadamente vulnerable y observa qué expone. Así entrenas los operadores sin rozar el scope de nadie. Cuando los domines, aplícalos solo a objetivos autorizados.

Conclusión

Los Google Dorks son una de las técnicas de reconocimiento con mejor relación esfuerzo/resultado del bug bounty: con cuatro operadores bien combinados sacas a la luz paneles, archivos y subdominios que otros pasan por alto, y sin tocar el objetivo. La regla es sencilla: úsalos solo dentro del scope, no confundas encontrar con acceder, y trátalos como el primer paso de un recon más amplio. Combínalos con las técnicas de recon avanzadas y, sobre todo, entrena el ojo para saber qué hacer con lo que encuentres reproduciendo fallos reales en los labs.