La comunidad
Dentro se pregunta, se enseña lo que se ha encontrado y se resuelve en grupo lo que atascaría a cualquiera solo. Se entra gratis: sin cuenta, sin plan y sin dejar el correo.
Es gratis y abierto. No hace falta tener cuenta en BBLABS para entrar.
Guía de Google Dorks para bug bounty: qué son, los operadores (site:, inurl:, intitle:, filetype:, ext:, intext:), ejemplos listos para exposición de info, paneles, archivos sensibles y subdominios, uso ético dentro del scope y cómo encajan en tu recon.
Gorka El Bochi
Fundador de BBLABS
Deja de leer sobre bugs y empieza a cazarlos
Sin tarjeta · Academy gratis · cancela cuando quieras
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.
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.
Estos son los ladrillos con los que se construye cualquier dork:
| Operador | Qué hace | Ejemplo |
|---|---|---|
site: |
Limita a un dominio | site:target.com |
inurl: |
La cadena aparece en la URL | inurl:admin |
intitle: |
La cadena aparece en el título | intitle:"index of" |
intext: |
La cadena aparece en el cuerpo | intext:"password" |
filetype: / ext: |
Filtra por extensión de archivo | filetype:pdf |
- |
Excluye un término | -www |
"..." |
Coincidencia exacta | "internal use only" |
* |
Comodín | site:*.target.com |
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
Sustituye target.com por el dominio que tengas en scope. Estos son patrones habituales:
# 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
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.
# 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.
# 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.
Google no es el único índice. La misma filosofía se aplica en:
org:targetorg filename:.env, "target.com" api_key). Los desarrolladores suben secretos a repositorios más de lo que crees.Amplío estas fuentes en la guía de técnicas de recon avanzadas.
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).
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.
47 comprobaciones ordenadas por coste: primero lo que te puede meter en un lío, luego lo barato, y al final lo caro — que es donde están los bounties grandes. Te la mando al correo ahora mismo.
Te das de baja en un clic, desde cualquier correo.
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:
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.
Punto no negociable. Buscar con Google es legal, pero actuar sobre lo que encuentres no siempre lo es:
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.
Los dorks no son un fin en sí mismos: son una fase temprana del reconocimiento. Un flujo típico:
url=, un subdominio de staging.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.
¿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.
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.
hunters entrenando
labs de hackeos reales
completaciones
pagados por estos bugs
Crea tu cuenta gratis y practica sobre labs basados en hackeos reales que pagaron miles de euros. La Academy es gratis para siempre.
Sin tarjeta · Academy gratis · cancela cuando quieras
Aprende a identificar y explotar vulnerabilidades IDOR (Insecure Direct Object Reference) en aplicaciones web. Desde los conceptos básicos hasta la escritura de reportes efectivos.
Lleva tu fase de reconocimiento al siguiente nivel con técnicas avanzadas de enumeración de subdominios, análisis de archivos JavaScript, GitHub dorking y automatización.
Explora las técnicas más comunes para atacar implementaciones inseguras de JSON Web Tokens: desde el algoritmo none hasta inyección de JKU/JWK.