Auditoría pasiva con Google Dorks

Autor:

ciberkaos

– Tema:

OSINT

– Publicado:

septiembre 17, 2026

– Actualizado:

septiembre 17, 2026

Contenido

Desarrollo paso a paso
Misión extra

Situación

La empresa ficticia Nébula Systems está preparando una revisión de seguridad. La dirección sospecha que algunos documentos, formularios, directorios o páginas antiguas pueden estar apareciendo en buscadores sin que el equipo técnico sea consciente de ello.

Vuestro equipo ha sido contratado para realizar una auditoría OSINT pasiva. No debéis atacar servidores, probar contraseñas ni explotar vulnerabilidades. Vuestra misión consiste en utilizar operadores avanzados de búsqueda para descubrir qué información pública puede localizar un usuario externo y proponer cómo reducir esa exposición.

El trabajo se basa en la documentación Google Hacking de La Aventura de Aprender:

Google Hacking

Objetivos de aprendizaje

Al finalizar el reto deberéis ser capaces de:

Explicar qué son Google Hacking y Google Dorks.
Utilizar operadores avanzados de búsqueda de forma combinada.
Diferenciar un hallazgo real, un falso positivo y un resultado irrelevante.
Evaluar el riesgo de la información indexada.
Registrar evidencias sin recopilar datos personales ni información sensible.
Proponer medidas de mitigación adecuadas.
Elaborar un informe técnico reproducible en Markdown.

Normas de seguridad y uso ético

Este reto solo puede realizarse sobre uno de estos objetivos:

Un dominio de laboratorio proporcionado por el profesor.
Un dominio propio del centro o del alumno para el que exista autorización.
Dominios de demostración indicados expresamente por el profesor.

Está permitido

Realizar búsquedas en Google, Bing o DuckDuckGo.
Analizar únicamente la información que aparece en los resultados del buscador.
Visitar páginas públicas ordinarias cuando el profesor lo haya autorizado.
Registrar URL, título, descripción y tipo de información encontrada.
Consultar GHDB para aprender a construir consultas.

Está prohibido

Buscar deliberadamente contraseñas, claves privadas, tokens, datos médicos o datos personales reales.
Descargar bases de datos, copias de seguridad, archivos de configuración o documentos sensibles.
Acceder a paneles de administración o intentar iniciar sesión.
Realizar escaneos, fuerza bruta, explotación de vulnerabilidades o evasión de controles.
Automatizar búsquedas masivas.
Compartir públicamente una exposición real.

Si aparece accidentalmente información sensible, no la abráis, no la descarguéis y no la copiéis. Detened la investigación, anotad de forma genérica que se ha localizado un posible hallazgo y avisad al profesor.

Organización

Modalidad: individual o parejas.
Duración recomendada: 2 sesiones de 90 minutos.
Producto final: un repositorio o archivo ZIP con un README.md y una carpeta img.
Nombre recomendado: reto-google-dorks-apellido1-apellido2.

Desarrollo paso a paso

Fase 0. Preparación del entorno

Cread una carpeta con la siguiente estructura:

reto-google-dorks/
├── README.md
└── img/

En el README.md, añadid:

Título del reto.
Nombre de los integrantes.
Fecha.
Dominio autorizado asignado.
Buscador utilizado.
Declaración ética: “La investigación se ha realizado mediante técnicas pasivas y sobre un objetivo autorizado”.

Leed la documentación de referencia antes de realizar búsquedas.

Evidencia requerida: captura de la estructura del proyecto o bloque de código que la represente.

Fase 1. Comprender los operadores

Explicad con vuestras propias palabras para qué sirven los siguientes operadores:

Operador	¿Qué debéis explicar?
`site:`	Cómo limita la búsqueda a un dominio
`filetype:`	Cómo filtra por tipo de documento
`inurl:`	Cómo busca términos dentro de la URL
`intitle:`	Cómo busca términos en el título
`intext:`	Cómo busca texto dentro de una página
`"frase exacta"`	Qué cambia al utilizar comillas
`-termino`	Cómo se excluyen resultados
`OR`	Cómo se ofrecen alternativas

Después, cread un ejemplo seguro y genérico de cada uno empleando example.com o el dominio autorizado.

No copiéis únicamente las definiciones de la documentación. Debéis explicar qué utilidad tendría cada operador durante una auditoría.

Evidencia requerida: tabla de operadores, explicación y ejemplo.

Fase 2. Reconocimiento inicial del dominio

Sustituid DOMINIO-AUTORIZADO por el objetivo asignado.

Ejecutad una búsqueda general:

site:DOMINIO-AUTORIZADO

Observad las primeras páginas de resultados y anotad:

Número aproximado de resultados indicado por el buscador.
Tipos de páginas que aparecen.
Secciones o subdominios visibles.
Resultados antiguos, duplicados o inesperados.

Repetid la consulta añadiendo al menos dos palabras relevantes para la organización, por ejemplo:

site:DOMINIO-AUTORIZADO contacto
site:DOMINIO-AUTORIZADO formación

Comparad los resultados y explicad qué información básica podría obtener un tercero.

El número de resultados del buscador es aproximado y puede variar. No debe tratarse como una medición exacta.

Evidencia requerida: consultas empleadas, fecha, resumen de resultados y una captura sin datos personales.

Fase 3. Localización de documentos públicos

Buscad documentos que la organización publique de forma legítima. Realizad al menos cuatro consultas usando tipos diferentes:

site:DOMINIO-AUTORIZADO filetype:pdf
site:DOMINIO-AUTORIZADO filetype:docx
site:DOMINIO-AUTORIZADO filetype:xlsx
site:DOMINIO-AUTORIZADO filetype:pptx

Si una extensión no ofrece resultados, registrad igualmente la consulta. Un resultado negativo también es una evidencia válida.

Para cada consulta, indicad:

Qué pretendíais encontrar.
Qué habéis encontrado.
Si el resultado parece intencionadamente público.
Qué información revela el título o el fragmento mostrado por Google.
Riesgo inicial: informativo, bajo, medio o alto.

No descarguéis documentos que parezcan internos, confidenciales o que contengan datos personales.

Evidencia requerida: tabla comparativa de al menos cuatro búsquedas.

Fase 4. Identificación de rutas y servicios visibles

Realizad búsquedas orientadas a reconocer la estructura pública del sitio:

site:DOMINIO-AUTORIZADO inurl:login
site:DOMINIO-AUTORIZADO inurl:admin
site:DOMINIO-AUTORIZADO inurl:portal
site:DOMINIO-AUTORIZADO inurl:uploads
site:DOMINIO-AUTORIZADO inurl:documentos

Podéis adaptar las palabras al contexto del objetivo. No accedáis a paneles ni intentéis autenticaros.

Responded:

¿La existencia pública de una página de inicio de sesión es por sí sola una vulnerabilidad?
¿Qué información puede revelar la estructura de una URL?
¿Qué resultados son normales y cuáles deberían revisarse?
¿Habéis detectado falsos positivos?

Evidencia requerida: mínimo tres consultas comentadas y clasificación de sus resultados.

Fase 5. Consultas combinadas

Ahora debéis construir búsquedas más precisas combinando operadores. Cread y probad al menos cinco consultas propias.

Ejemplos seguros:

site:DOMINIO-AUTORIZADO filetype:pdf "manual"
site:DOMINIO-AUTORIZADO (filetype:pdf OR filetype:docx) "curso"
site:DOMINIO-AUTORIZADO inurl:uploads filetype:pdf
site:DOMINIO-AUTORIZADO intitle:"contacto"
site:DOMINIO-AUTORIZADO filetype:pdf -inurl:blog

Cada consulta deberá incluir:

Hipótesis: qué creéis que puede localizar.
Dork utilizado.
Resultado obtenido.
Interpretación.
Modificación realizada para mejorar la precisión.

Al menos una consulta debe usar OR, otra debe excluir un término con - y otra debe combinar tres operadores.

Evidencia requerida: cinco fichas de consulta completas.

Fase 6. Investigación en GHDB

Consultad la Google Hacking Database enlazada en la documentación.

Elegid dos categorías relacionadas con exposición de información.
Seleccionad un ejemplo de consulta de cada categoría.
Explicad qué intenta localizar, sin ejecutarlo sobre organizaciones reales.
Transformadlo en una versión segura para el dominio de laboratorio.
Indicad qué riesgo representaría un resultado positivo.

No se valorará que el dork sea espectacular, sino que comprendáis su funcionamiento y sepáis adaptarlo de manera responsable.

Evidencia requerida: dos análisis de dorks de GHDB, con referencia a su categoría y versión adaptada.

Fase 7. Comparación entre buscadores

Elegid dos consultas anteriores y repetidlas en otro buscador, como Bing o DuckDuckGo.

Comparad:

Cantidad y relevancia de resultados.
Documentos que aparecen en uno y no en otro.
Diferencias en títulos y fragmentos.
Posibles causas de las diferencias.

No es necesario que todos los buscadores admitan exactamente los mismos operadores. Si uno no funciona, documentadlo.

Evidencia requerida: tabla comparativa de dos consultas en dos buscadores.

Fase 8. Registro y clasificación de hallazgos

Reunid los resultados relevantes en una tabla como esta:

ID	Consulta	Hallazgo resumido	Evidencia	Probabilidad	Impacto	Riesgo	¿Falso positivo?
H-01	`site:... filetype:pdf`	Documento público antiguo	URL y captura	Media	Bajo	Bajo	No

Utilizad esta escala:

Informativo: no existe un problema, pero el resultado ayuda a conocer la huella digital.
Bajo: información pública poco sensible o desactualizada.
Medio: información no prevista que facilita reconocimiento o ingeniería social.
Alto: posible exposición de información interna o sensible. No debe abrirse; se comunica al profesor.

Para cada hallazgo relevante, explicad por qué le asignáis esa valoración. El nivel de riesgo no depende de que el resultado “parezca interesante”, sino de su impacto y probabilidad.

Evidencia requerida: inventario de hallazgos. Puede haber hallazgos informativos o resultados negativos.

Fase 9. Plan de mitigación

Proponed al menos una medida concreta para cada hallazgo que necesite corrección. Podéis considerar:

Retirar documentos que ya no deban ser públicos.
Mover copias de seguridad fuera del directorio web.
Desactivar el listado de directorios.
Revisar permisos y reglas del servidor.
Proteger áreas privadas mediante autenticación y autorización.
Evitar publicar información sensible en nombres de archivo, títulos o metadatos.
Solicitar la retirada de resultados obsoletos del buscador.
Utilizar noindex cuando proceda.
Revisar robots.txt, entendiendo que no es un mecanismo de seguridad.

Para cada medida indicad:

Hallazgo al que responde.
Acción propuesta.
Responsable recomendado.
Prioridad.
Cómo comprobaríais posteriormente que la corrección funciona.

Evidencia requerida: plan de mitigación priorizado.

Fase 10. Conclusiones

Responded razonadamente:

¿Qué diferencia existe entre una búsqueda normal y un Google Dork?
¿Por qué una página indexada no es automáticamente una vulnerabilidad?
¿Cuál ha sido la combinación de operadores más útil?
¿Qué limitaciones tiene este tipo de auditoría?
¿Qué riesgo puede tener publicar documentos aparentemente inofensivos?
¿Qué debe hacer un auditor si encuentra información sensible de forma accidental?
¿Qué cambiaríais en la exposición pública del dominio analizado?

Misión extra

Quienes terminen el reto principal pueden realizar esta ampliación:

Diseñad una matriz con tres objetivos: documentos, rutas y contenido textual.
Cread tres consultas diferentes para cada objetivo, sin ejecutar búsquedas agresivas.
Comparad los resultados actuales con una versión histórica pública del sitio mediante Wayback Machine, si el profesor lo autoriza.
Seleccionad un documento público e indicad qué metadatos sería razonable revisar en un laboratorio, sin descargar material sensible.
Diseñad una consulta periódica que la propia organización podría usar para vigilar su exposición.
Proponed un procedimiento responsable de notificación de hallazgos.

La ampliación debe centrarse en la metodología y la defensa. No se permite utilizar herramientas automáticas de escaneo.

Estructura obligatoria del `README.md`

# Operación Huella Digital

## 1. Datos del equipo
## 2. Objetivo y autorización
## 3. Declaración ética
## 4. Operadores estudiados
## 5. Reconocimiento inicial
## 6. Búsqueda de documentos
## 7. Rutas y servicios visibles
## 8. Consultas combinadas
## 9. Investigación en GHDB
## 10. Comparación de buscadores
## 11. Inventario de hallazgos
## 12. Plan de mitigación
## 13. Conclusiones
## 14. Bibliografía y recursos

Las capturas deberán guardarse en img/ y enlazarse mediante rutas relativas:

![Resultado de una consulta autorizada](img/consulta-01.png)

Antes de incluir una captura, ocultad nombres, correos, identificadores, cookies, cuentas abiertas y cualquier dato personal.

Entrega

La entrega debe contener:

README.md completo y bien estructurado.
Carpeta img con las evidencias necesarias.
Entre 10 y 15 consultas propias documentadas.
Al menos cinco consultas combinadas.
Comparación de dos buscadores.
Inventario de hallazgos.
Plan de mitigación.
Conclusiones personales.

Aunque inicialmente se entregue como ZIP, el proyecto deberá estar preparado para subirse posteriormente a un repositorio Git.

No incluyáis archivos obtenidos durante la investigación. Solo se entregarán el informe y capturas saneadas.

Rúbrica de evaluación

Criterio	Peso
Uso correcto y variado de operadores	20 %
Metodología paso a paso y reproducibilidad	15 %
Interpretación de resultados y falsos positivos	15 %
Clasificación razonada de riesgos	15 %
Medidas de mitigación	15 %
Calidad del `README.md` y de las evidencias	10 %
Ética, privacidad y cumplimiento de las normas	10 %

Penalizaciones

Ejecutar pruebas fuera de los objetivos autorizados: actividad no superada.
Incluir datos personales o información sensible en la entrega: actividad no superada hasta corregirla.
Presentar consultas sin explicar su finalidad y sus resultados: no se consideran realizadas.
Copiar definiciones sin interpretación propia: reducción de la puntuación correspondiente.

Lista de comprobación final

He trabajado únicamente sobre un objetivo autorizado.
No he intentado iniciar sesión ni explotar ningún sistema.
He documentado las consultas aunque no ofrecieran resultados.
He diferenciado hallazgos, falsos positivos y resultados irrelevantes.
Las capturas no contienen datos personales.
No he descargado ni adjuntado información sensible.
Cada riesgo incluye una medida de mitigación.
El README.md puede entenderse sin explicaciones adicionales.
He citado la documentación utilizada.

Resultado esperado

El objetivo no es encontrar “secretos”, sino demostrar que sabéis formular preguntas precisas a un buscador, interpretar responsablemente las respuestas y convertir la información pública en recomendaciones defensivas útiles.

Dominios recomendados para búsquedas inocuas

En estos dominios limitaría la práctica a operadores como site:, filetype:, intitle:, inurl: y frases entre comillas, buscando exclusivamente información pública.

Dominio	Temática	Ejemplos seguros
`boe.es`	Legislación española	`site:boe.es filetype:pdf ciberseguridad`
`ine.es`	Estadísticas públicas	`site:ine.es filetype:xlsx población`
`datos.gob.es`	Datos abiertos	`site:datos.gob.es filetype:csv transporte`
`administracion.gob.es`	Administración pública	`site:administracion.gob.es filetype:pdf empleo`
`europa.eu`	Unión Europea	`site:europa.eu filetype:pdf cybersecurity`
`data.europa.eu`	Datos abiertos europeos	`site:data.europa.eu \"open data\"`
`who.int`	Salud pública internacional	`site:who.int filetype:pdf cybersecurity`
`un.org`	Naciones Unidas	`site:un.org filetype:pdf \"artificial intelligence\"`
`nasa.gov`	Ciencia y espacio	`site:nasa.gov filetype:pdf mars`
`noaa.gov`	Meteorología y océanos	`site:noaa.gov filetype:pdf climate`
`mit.edu`	Universidad e investigación	`site:mit.edu filetype:pdf \"computer security\"`
`stanford.edu`	Investigación académica	`site:stanford.edu filetype:pptx cybersecurity`
`docs.python.org`	Documentación técnica	`site:docs.python.org intitle:\"Python\" tutorial`
`developer.mozilla.org`	Desarrollo web	`site:developer.mozilla.org \"HTTP authentication\"`
`wikipedia.org`	Contenido enciclopédico	`site:wikipedia.org intitle:OSINT`
`archive.org`	Archivo histórico	`site:archive.org filetype:pdf networking`