Google Dorks: qué son, operadores principales y cómo se usan en OSINT y Red Team

Los Google Dorks son consultas de búsqueda construidas con operadores avanzados de Google para localizar información sensible expuesta en la web indexada que un usuario corriente no encontraría con búsquedas normales. La técnica también se conoce como Google Hacking, lleva en uso desde principios de los 2000, y sigue siendo una de las formas más rápidas y baratas de descubrir documentos confidenciales, paneles de administración, ficheros de configuración, credenciales y dispositivos expuestos pertenecientes a una organización. Es una herramienta neutra: la usan auditores de seguridad, equipos OSINT, periodistas de investigación y, también, atacantes.

Esta guía explica qué son los Google Dorks, qué operadores aportan valor real, casos de uso defensivos y ofensivos, ejemplos por categoría, alternativas (Bing dorks, Shodan, Censys), aspectos legales y cómo proteger una organización frente a su uso malicioso.

Qué son los Google Dorks

Un Google Dork es una consulta que combina operadores avanzados (site:, inurl:, intitle:, filetype:, intext: y otros) para filtrar el índice de Google a un subconjunto muy específico. La técnica explota dos hechos: Google indexa más cosas de las que la mayoría de organizaciones imagina, y los administradores cometen errores recurrentes (subir backups a directorios públicos, dejar paneles sin proteger, exponer logs con datos sensibles).

El término Google Hacking lo popularizó Johnny Long en el libro homónimo y dio origen a la Google Hacking Database (GHDB), mantenida actualmente por Offensive Security dentro de Exploit-DB. La GHDB es el catálogo público con miles de dorks clasificados por tipo de hallazgo: documentos, vulnerabilidades, credenciales, dispositivos.

Lo importante: el dork no rompe nada. Sólo busca lo que ya está expuesto. La responsabilidad por el dato visible es de quien lo expuso, no del buscador.

Operadores principales

Los operadores que aportan el 90% del valor real:

• site: restringe la búsqueda a un dominio o subdominio. site:secra.es devuelve sólo páginas de Secra. site:*.gov.es devuelve resultados en cualquier subdominio gov.es.
• inurl: filtra por palabras en la URL. inurl:admin encuentra paths que contengan "admin".
• intitle: busca palabras en el <title> HTML. intitle:"index of" localiza listados de directorios indexados.
• intext: busca en el cuerpo de la página. intext:"password" encuentra páginas con esa palabra en el contenido.
• filetype: o ext: filtra por extensión de fichero. filetype:pdf, filetype:xlsx, filetype:env, filetype:sql.
• cache: muestra la versión cacheada por Google de una URL. Útil cuando el contenido se ha eliminado pero todavía está en caché.
• -término excluye resultados con esa palabra. Combinado con otros operadores afina las búsquedas.
• "frase exacta" entre comillas busca literalmente esa cadena.
• OR y | lógico, combina términos.
• * wildcard, sustituye palabras en frases.

Los operadores se combinan. Una consulta seria nunca usa uno solo: encadena tres o cuatro para reducir el ruido al mínimo.

Casos de uso

La técnica se usa en dos direcciones, con motivaciones opuestas pero metodología idéntica.

Defensivo: auditoría de exposición digital

Un equipo de seguridad lanza dorks contra los dominios de su propia organización para descubrir qué deja ver Google que no debería. Es el primer paso de cualquier ejercicio de footprinting y aparece en el alcance estándar de auditorías de Red Team y de pentesting externo. Permite encontrar:

• Documentos PDF, Excel u Office con metadatos o información interna que se subieron al sitio web sin revisar.
• Backups de bases de datos (.sql, .bak) accesibles vía web por error.
• Repositorios .git expuestos, ficheros .env, configuraciones con credenciales.
• Subdominios olvidados con servicios desatendidos.
• Paneles de admin (CMS, routers, IoT) sin autenticación.
• Logs de aplicación con trazas de errores que filtran información sensible.

Ofensivo: reconocimiento previo a un ataque

El atacante construye un perfil de la organización antes de tocar nada. Usa los mismos dorks para localizar puntos débiles que después atacar (panel de admin con credenciales por defecto, fichero de configuración con clave AWS, repositorio expuesto con secretos). Es lo que Google Dorks comparte metodología con OSINT más amplio: trabajo de inteligencia público y silencioso, sin tocar la infraestructura del objetivo.

La dualidad de uso justifica que cualquier organización serie incluya un barrido periódico de dorks sobre sus propios dominios. Lo que tu equipo encuentra es lo que un atacante también puede encontrar.

Ejemplos prácticos por categoría

Consultas reales que aparecen en auditorías. Los ejemplos están planteados para que la organización los use sobre sus propios dominios.

Documentos sensibles expuestos

site:tudominio.com filetype:pdf intext:"confidencial"
site:tudominio.com filetype:xlsx OR filetype:xls
site:tudominio.com filetype:docx intext:"interno"
site:tudominio.com filetype:pptx intext:"borrador"

Suelen aparecer presentaciones internas, hojas de cálculo con datos personales, plantillas con credenciales de prueba.

Ficheros de configuración y credenciales

site:tudominio.com filetype:env
site:tudominio.com filetype:config OR filetype:conf
site:tudominio.com filetype:sql intext:"INSERT INTO"
site:tudominio.com inurl:wp-config intext:"DB_PASSWORD"
site:tudominio.com filetype:log intext:"password"

Estos hallazgos suelen ser críticos. Un .env indexado puede contener claves AWS, tokens de pasarela de pago, secretos JWT. Si aparece, el incidente es inmediato.

Listados de directorios

site:tudominio.com intitle:"index of"
site:tudominio.com intitle:"index of" "parent directory"
site:tudominio.com intitle:"index of /backup"

Servidores web mal configurados que muestran el árbol de ficheros completo. Es un clásico que sigue apareciendo en 2026.

Paneles de administración

site:tudominio.com inurl:admin OR inurl:login
site:tudominio.com intitle:"admin login"
site:tudominio.com inurl:phpmyadmin
site:tudominio.com inurl:wp-admin

Permite localizar páginas de login que conviene revisar (si tienen 2FA, bloqueo por intentos, exposición innecesaria).

Logs y errores

site:tudominio.com filetype:log
site:tudominio.com "error" "stack trace"
site:tudominio.com intext:"sql syntax"
site:tudominio.com intext:"ORA-00942"

Logs públicos exponen rutas internas, versiones de software con vulnerabilidades CVE conocidas, nombres de tablas y campos.

Repositorios y código fuente expuesto

site:tudominio.com inurl:.git
site:tudominio.com filetype:sql OR filetype:bak
site:tudominio.com inurl:.svn OR inurl:.hg

Encontrar .git indexado equivale a poder reconstruir el repositorio entero, incluyendo histórico de cambios y, posiblemente, secretos commiteados y luego "borrados".

Dispositivos IoT y cámaras

Aunque GHDB tiene cientos de dorks específicos para cámaras IP, routers, impresoras y dispositivos OT con interfaces web, esta categoría es típicamente terreno de Shodan, no de Google. Lo veremos en alternativas.

Google Hacking Database (GHDB)

La GHDB de Offensive Security es el catálogo público con miles de dorks clasificados. Categorías principales:

• Footholds: configuraciones que permiten establecer presencia.
• Files containing usernames / passwords: ficheros expuestos con credenciales.
• Sensitive Directories: directorios que no deberían ser accesibles.
• Web Server Detection: identificación de versión de servidor web.
• Vulnerable Files: ficheros con vulnerabilidades conocidas.
• Vulnerable Servers: servidores con vulnerabilidades específicas.
• Error Messages: errores que filtran información.
• Network or Vulnerability Data: información sensible de red.
• Pages containing login portals: páginas de login interesantes.
• Various Online Devices: dispositivos IoT expuestos.
• Advisories and Vulnerabilities: advisories que afectan a productos específicos.

La GHDB se actualiza constantemente. Lo razonable es revisar las categorías relevantes para tu sector y probar los dorks aplicables sobre tus propios dominios.

Cómo protegerse

Lo que cualquier organización debe revisar para reducir su exposición vía dorks.

1. Inventario de subdominios y dominios secundarios. Lo que no sabes que tienes no lo proteges. Herramientas tipo Amass, Subfinder o consulta a Certificate Transparency revelan subdominios olvidados.
2. Auditoría periódica con tus propios dorks. Lanzar mensualmente las categorías relevantes (filetype, intitle:"index of", inurl:admin, .env, .git) sobre todos tus dominios. Si sale algo, retirarlo del índice y arreglar la causa raíz.
3. robots.txt con cabeza. Bloquea lo que no debe indexarse, pero recuerda que robots.txt también lista el camino a un atacante curioso. Combinarlo con noindex HTTP o <meta name="robots" content="noindex">.
4. Gestión de retiradas. Cuando aparece algo sensible indexado, retirar el contenido del servidor, esperar unos días, y forzar la eliminación de Google con la herramienta de retirada de URLs en Search Console. Sin retirada explícita, la caché puede sobrevivir semanas.
5. Configuración del servidor web. Desactivar Indexes en Apache (Options -Indexes), autoindex off en Nginx. Listar directorios sólo para activos públicos, nunca para todo el documento root.
6. Política de subida de ficheros. Antes de publicar PDF, Excel u Office en el sitio, eliminar metadatos (Title, Author, Comments suelen filtrar nombres y rutas). Herramientas como exiftool lo automatizan.
7. Repositorios y secretos. Pre-commit hooks que detecten secretos (gitleaks, trufflehog) y prohibición efectiva de subir .env, .git, .svn, .bak a producción.
8. Monitorización continua. Servicios que avisan cuando aparece algo nuevo en Google que afecta a tus dominios. Más eficiente que la auditoría manual mensual.

Limitaciones y alternativas

Google Dorks tiene tres límites importantes:

• Sólo ve lo indexado por Google. Mucho contenido legítimo no entra en el índice (intranets, backends sin link público, recursos detrás de auth).
• Google penaliza el uso intensivo. Búsquedas masivas desde la misma IP disparan CAPTCHA. Para investigaciones serias se combina con APIs de pago o proxies rotativos.
• El catálogo dinámico cambia. Lo que aparece hoy puede no aparecer mañana. La auditoría debe ser periódica.

Por eso un OSINT serio combina dorks con varias fuentes complementarias.

Bing Dorks

Bing acepta operadores similares (site:, filetype:, inurl:, intitle:) y a veces indexa cosas que Google no, especialmente dominios de menor autoridad. Es una segunda fuente útil. La sintaxis es casi idéntica.

Shodan

Buscador de dispositivos conectados a internet (no de páginas web). Indexa banners de servicios (puertos, versiones de software), por eso es la herramienta de elección para encontrar cámaras IP, routers, impresoras, ICS/OT, bases de datos expuestas, paneles de admin sin auth. Operadores como org:, country:, port:, product:, vuln: permiten consultas muy específicas.

Censys

Similar a Shodan pero con foco fuerte en certificados TLS, escaneo continuo y APIs orientadas a investigación. Especialmente útil para correlacionar certificados, descubrir subdominios y mapear infraestructura de una organización.

GitHub Dorks

GitHub también responde a búsquedas con operadores. org:tuempresa filename:.env o "AWS_SECRET_ACCESS_KEY" org:tuempresa ayuda a detectar secretos commiteados al repositorio público de la organización.

DorkGPT y herramientas asistidas por IA

Aparecen herramientas que generan dorks automáticamente a partir de un objetivo en lenguaje natural. El concepto es nuevo y la calidad varía mucho, pero conviene tenerlo en el radar como evolución de la disciplina.

Aspectos legales y éticos

El uso de Google Dorks es legal en sí mismo: estás haciendo búsquedas en un servicio público. Lo que cambia el marco jurídico es cómo usas la información encontrada.

• Sobre tus propios sistemas: sin restricciones. Auditoría preventiva es aconsejable y exigida en marcos como NIS2 e ISO 27001.
• Sobre sistemas de un cliente con autorización escrita: parte estándar del alcance de auditoría externa o Red Team.
• Sobre terceros sin autorización: jurídicamente delicado. Sólo localizar información expuesta no constituye intrusión, pero acceder, descargar o explotar lo encontrado puede caer en delitos de descubrimiento y revelación de secretos (art. 197 Código Penal español), acceso ilícito (art. 197 bis) o daños informáticos (art. 264) según el caso. La línea entre OSINT legal y descubrimiento ilícito está mal definida y depende mucho del contexto y del tipo de dato.

Recomendación operativa: si encuentras información expuesta de un tercero (clientes, proveedores, terceros de tu sector) que parezca un incidente, no la descargues ni la explores. Notifica al responsable a través del canal oficial (security.txt si lo tienen, o una vía de contacto formal) y deja constancia escrita del hallazgo.

Preguntas frecuentes

¿Es ilegal usar Google Dorks?

No, en sí mismos. Es una técnica de búsqueda. Lo que regulan las leyes es qué haces con la información. Buscar es legal; acceder o explotar lo encontrado puede no serlo, dependiendo del contexto y de la jurisdicción.

¿Para qué sirven los Google Dorks en una empresa?

Para auditar la propia exposición. Lanzar dorks contra los dominios de la organización es la forma más barata y rápida de descubrir qué deja ver Google que no debería: documentos, paneles, ficheros de configuración, repositorios. Es parte estándar del footprinting en pentesting externo y Red Team.

¿Cómo evito que mis ficheros aparezcan en Google?

Combinando varias capas: noindex en cabeceras HTTP o meta tags, autenticación obligatoria para contenido sensible, robots.txt para lo que no debe indexarse (con cuidado: el fichero también es público), revisión de cabeceras X-Robots-Tag, eliminación de metadatos en documentos públicos, y monitorización continua.

¿Sigue siendo eficaz Google Dorks en 2026?

Sí. Las técnicas básicas son las mismas que hace 20 años, los errores de configuración también, y siguen apareciendo descubrimientos relevantes a diario. Lo que ha cambiado es que ahora hay más alternativas (Shodan, Censys, GitHub) y que las plataformas modernas (Cloudflare, AWS, Vercel) reducen la exposición por defecto.

¿Qué diferencia hay entre Google Dorks y OSINT?

Google Dorks es una técnica concreta dentro de OSINT (Open Source Intelligence). OSINT es la disciplina amplia de inteligencia a partir de fuentes abiertas: redes sociales, registros públicos, certificados TLS, dorks, Shodan, leaks. Los dorks son una herramienta más en la caja.

¿Hay herramientas que automatizan dorks?

Sí. Pagodo, GooGonk, theHarvester (parcialmente), recon-ng (con módulos de Google Search) y sCRIPTKIDDIES varios. Para uso intensivo profesional, Google ofrece la Custom Search JSON API con cuota razonable. Las opciones gratuitas tropiezan rápido con CAPTCHA.

Recursos relacionados

• Qué es Red Team: la disciplina ofensiva donde el OSINT y los dorks son la fase inicial obligatoria.
• Qué es un CVE: cómo se identifican las vulnerabilidades que un dork puede ayudar a localizar en versiones expuestas.
• Qué es threat hunting: la disciplina defensiva que aprovecha información de exposición para construir hipótesis.
• Pentesting de aplicaciones web: la auditoría que sigue al footprinting cuando el dorking detecta superficie atacable.
• Pentesting de infraestructura: el ejercicio donde la enumeración externa empieza por dorks.

Google Dorks en Secra

En Secra los Google Dorks forman parte del footprinting estándar de cualquier ejercicio de Red Team y de pentesting externo. Lo que un atacante puede ver de tu organización en Google es nuestro punto de partida: documentos olvidados, paneles abiertos, ficheros de configuración, repositorios expuestos, subdominios desatendidos. Si quieres saber qué deja ver tu superficie pública o necesitas un barrido de exposición completo (Google, Bing, Shodan, Censys, GitHub) escríbenos a través de contacto o consulta nuestro servicio de Red Team.