Categoría: OSINT

  • OSINT: qué revela un documento Word

    OSINT: qué revela un documento Word

    Archivo entregado por el profesor: comunicado_faro_norte.docx. Es un caso ficticio preparado para esta práctica. No difundas una lista de respuestas antes de que todos los grupos terminen.

    Situación

    El equipo de comunicación de una empresa ficticia, Faro Norte, va a publicar un documento Word. Antes de hacerlo, quiere saber qué información podría descubrir cualquier persona que descargue el archivo. Actuarás como analista y elaborarás un informe breve con pruebas y recomendaciones.

    Trabaja únicamente con el documento de la práctica o con archivos propios autorizados. No publiques nombres reales, rutas personales ni documentos de terceros en servicios de análisis en línea.

    Objetivos

    • Distinguir el contenido visible, las propiedades internas del documento y los datos del sistema de archivos.
    • Extraer propiedades con una interfaz gráfica y con ExifTool.
    • Inspeccionar las partes internas de un DOCX sin modificar el original.
    • Explicar qué conclusiones están demostradas y cuáles son solo hipótesis.
    • Comprobar qué información permanece tras preparar una copia para publicación.

    Material

    • Un equipo con Microsoft Word o LibreOffice Writer y acceso a terminal.
    • ExifTool instalado. Comprueba con exiftool -ver. Si no está disponible, realiza los pasos de Word/LibreOffice y la inspección del DOCX; deja constancia de ello.
    • El archivo comunicado_faro_norte.docx, facilitado junto a este enunciado. El documento y las identidades que figuran en él son ficticios.

    Fase 1. Preparar el archivo y leer lo visible (10 minutos)

    1. Descarga comunicado_faro_norte.docx. Conserva este archivo sin abrirlo en un editor que guarde automáticamente.
    2. Duplica el archivo y llama a la copia comunicado_faro_norte_copia.docx. Analiza la copia; conserva el archivo entregado para poder comparar al final. Si usas una aplicación con guardado automático, desactívalo para este caso o trabaja siempre sobre otra copia.
    3. Abre la copia en Word o LibreOffice y anota únicamente lo que cualquiera puede ver al leer el documento: título, lugar, fecha, actividades y correo de contacto. Cierra sin guardar.
    4. Explica por qué los datos visibles no equivalen a los metadatos. Formula dos preguntas que crees que el documento podría responder sin que la información aparezca en la página.

    Evidencia 1: captura del comunicado y tabla con cinco datos visibles. Todos los nombres y lugares pertenecen al caso ficticio.

    Fase 2. Observar antes de extraer (5 minutos)

    1. Apunta el nombre, tamaño y extensión de la copia.
    2. Anota la fecha de modificación que muestra el explorador de archivos.
    3. Abre el documento y localiza su panel de propiedades: Archivo → Información → Propiedades en Word, o Archivo → Propiedades en LibreOffice. Registra los campos que aparezcan.
    4. Responde: ¿la fecha que muestra el sistema operativo pertenece necesariamente al contenido original? Justifica tu respuesta pensando en la copia que acabas de hacer.

    Evidencia 2: tabla con las propiedades visibles y su procedencia (explorador o editor).

    Fase 3. Leer metadatos con ExifTool (10 minutos)

    Abre una terminal en la carpeta del archivo. Ejecuta:

    exiftool -a -G1 -s comunicado_faro_norte_copia.docx

    En Windows PowerShell, si ExifTool no está en PATH, usa la ruta del ejecutable y del archivo entre comillas:

    & "C:\ruta\a\exiftool.exe" -a -G1 -s "C:\ruta\al\comunicado_faro_norte_copia.docx"

    Anota, solo si existen, Creator, LastModifiedBy, Title, Subject, Keywords, CreateDate, ModifyDate, RevisionNumber, Company, Manager, FileSize, FileType y FileModifyDate. Los nombres exactos pueden variar. No inventes campos ausentes. El prefijo entre corchetes indica el grupo de cada dato.

    Evidencia 3: captura o salida copiada del comando y una tabla:

    CampoValor encontradoGrupo / fuente¿Dato introducido, generado o incierto?

    Pregunta: compara las fechas internas con FileModifyDate. ¿Por qué podrían diferir?

    Fase 4. Examinar el interior del DOCX (15 minutos)

    Un DOCX es un paquete de archivos. Inspecciona una copia adicional sin sobrescribir el documento de trabajo.

    Opción gráfica, válida para Windows, macOS y Linux: duplica el .docx, cambia la extensión de esa copia a .zip y ábrela con un descompresor. Si el sistema pregunta si deseas cambiar la extensión, acepta. Abre estos archivos como texto (no ejecutes ningún contenido):

    • docProps/core.xml: propiedades principales, como creador, título y fechas, si están presentes.
    • docProps/app.xml: propiedades de aplicación, como el programa o estadísticas, cuando existen.
    • word/document.xml: texto del documento en formato XML; su lectura puede resultar incómoda porque el texto está dividido en elementos.

    Opción terminal en Linux/macOS:

    unzip -l comunicado_faro_norte_copia.docx
    unzip -p comunicado_faro_norte_copia.docx docProps/core.xml
    unzip -p comunicado_faro_norte_copia.docx docProps/app.xml

    En Windows puedes usar la opción gráfica; no necesitas instalar comandos adicionales.

    Evidencia 4: nombres de al menos cinco entradas del paquete y dos valores concretos encontrados en core.xml o app.xml. Si un archivo no existe, registra esa ausencia.

    Preguntas: ¿qué datos de ExifTool puedes localizar también en XML? ¿Qué datos proceden del sistema de archivos y no están en esos XML? Localiza también, si aparecen, propiedades que apunten a un proyecto o a personas que no se mencionan en el texto visible. ¿Encuentras alguna información que no se vea al leer el comunicado?

    Fase 5. Construir un informe OSINT (15 minutos)

    Rellena esta tabla. Usa «No consta» si un dato no aparece; «Hipótesis» si depende de una interpretación.

    AfirmaciónEvidencia exacta y ubicaciónGrado de confianzaPosible explicación alternativa
    El documento contiene un título interno
    Una persona concreta lo redactó
    Se editó después de crearlo
    Se utilizó un programa determinado

    Después responde en 100–150 palabras: ¿qué podría aprender un tercero que solo recibiese este DOCX? ¿Qué afirmaciones no puedes demostrar con los metadatos? Recuerda que el campo «Autor» puede configurarse manualmente o conservarse de una plantilla y no identifica necesariamente a quien escribió el texto.

    Fase 6. Reducir exposición y volver a comprobar (10–15 minutos)

    1. Conserva intacto el original. Crea comunicado_faro_norte_publicacion.docx.
    2. En Word, si está disponible, utiliza Archivo → Información → Comprobar si hay problemas → Inspeccionar documento; revisa las categorías ofrecidas y elimina de la copia las propiedades personales que decidas retirar. En LibreOffice, revisa Archivo → Propiedades y las opciones de eliminación de información personal al guardar disponibles en tu versión. Anota exactamente qué hiciste.
    3. Repite el comando de la fase 3 para la copia de publicación. Vuelve a examinar docProps/core.xml en esa copia.
    4. Compara antes y después. No des por hecho que todos los campos desaparecieron. Verifica también que el contenido que se pretende publicar sigue presente.
    Campo o contenidoAntesDespués¿Permanece?
    Autor
    Último editor
    Fechas internas
    Título
    Texto visible

    Conclusión: redacta tres medidas concretas que recomendarías antes de publicar documentos de tu centro o empresa.

    Ampliación opcional: formato DOC antiguo

    Si el profesor proporciona un .doc autorizado, repite solo las fases 2, 3 y 5. El formato .doc es binario: no intentes abrirlo como ZIP ni esperes encontrar docProps/core.xml. Compara qué propiedades puede recuperar ExifTool en cada formato y describe los límites de la comparación.

    Entrega

    Sube un ZIP con:

    1. README.md con objetivo, entorno utilizado, pasos realizados, tablas completadas, respuestas y conclusión.
    2. evidencias/ con capturas o salidas de terminal legibles, sin información personal real.
    3. El DOCX ficticio entregado y la copia preparada para publicación. No incluyas otros archivos personales.

    El README debe permitir que otra persona repita la práctica. Identifica cada captura en el texto. No se evaluará encontrar un número determinado de metadatos: algunos dependen del editor, la configuración y cómo se creó el archivo.

  • OSINT: Operación Atlas

    OSINT: Operación Atlas

    Reconocimiento pasivo de dominios desde terminal

    Documentación de apoyo: Reconocimiento de dominios por terminal y scripting


    1. Introducción

    Una organización ficticia llamada Atlas Digital está revisando la información que su infraestructura publica en Internet. Durante los últimos años ha creado páginas web, aplicaciones, servicios de correo y entornos de pruebas, pero no dispone de un inventario actualizado.

    El equipo de seguridad necesita conocer su superficie externa visible mediante fuentes públicas antes de realizar una auditoría más profunda.

    Tu misión será actuar como analista OSINT. Utilizarás la terminal de Linux para descubrir subdominios, resolver direcciones IP, consultar información pública sobre esas direcciones y automatizar parte del proceso mediante un script en Bash.

    El objetivo no consiste únicamente en ejecutar comandos. Tendrás que interpretar, relacionar y documentar los resultados.


    2. Objetivos de aprendizaje

    Al finalizar el reto deberás ser capaz de:

    • Explicar qué es el reconocimiento OSINT pasivo.
    • Utilizar herramientas desde una terminal Linux.
    • Enumerar subdominios con Amass y Subfinder.
    • guardar, ordenar, combinar y filtrar resultados.
    • Resolver nombres de dominio y obtener sus direcciones IP.
    • Consultar información WHOIS y datos aproximados de geolocalización.
    • Procesar respuestas JSON con curl y jq.
    • Crear un script Bash sencillo para automatizar el análisis.
    • Diferenciar entre un dato, una evidencia y una conclusión.
    • Elaborar un informe técnico reproducible.

    3. Normas y alcance autorizado

    Esta actividad es exclusivamente de reconocimiento pasivo.

    Está permitido

    • Consultar fuentes públicas.
    • Utilizar Amass en modo -passive.
    • Utilizar Subfinder con sus fuentes OSINT.
    • Resolver registros DNS.
    • Consultar WHOIS y servicios públicos de información de IP.
    • Trabajar únicamente con el dominio indicado por el profesor.

    No está permitido

    • Escanear puertos con Nmap u otras herramientas.
    • Buscar vulnerabilidades o ejecutar exploits.
    • Realizar fuerza bruta de subdominios, directorios o credenciales.
    • Acceder a paneles, cuentas o zonas privadas.
    • Enviar tráfico masivo o intentar evadir límites.
    • Investigar dominios distintos de los autorizados.

    Encontrar un servicio visible no autoriza a entrar en él. Si descubres algo que parezca sensible, registra únicamente el nombre y comunícalo al profesor.


    4. Material necesario

    • Ubuntu, Debian, Kali Linux o una máquina virtual Linux.
    • Conexión a Internet.
    • Un dominio autorizado por el profesor.
    • Terminal y editor de texto.
    • Herramientas: amass, subfinder, dnsutils, whois, curl, jq y, opcionalmente, geoip-bin.

    El profesor proporcionará el objetivo:

    DOMINIO_AUTORIZADO=____________________________

    No sustituyas esta variable por el dominio de una empresa elegida al azar.


    5. Preparación del entorno

    Paso 1. Crear la estructura de trabajo

    mkdir -p operacion-atlas/{capturas,resultados,script}
    cd operacion-atlas

    Comprueba la estructura:

    find . -maxdepth 2 -type d

    Paso 2. Instalar las herramientas

    En una distribución basada en Ubuntu o Debian:

    sudo apt update
    sudo apt install amass dnsutils whois curl jq geoip-bin

    Si Subfinder no está disponible en los repositorios de tu distribución, sigue la opción de instalación explicada en la documentación del curso. Por ejemplo, si tienes Snap:

    sudo snap install subfinder

    Paso 3. Comprobar la instalación

    amass version
    subfinder -version
    host -V
    whois --version
    curl --version
    jq --version

    Evidencia 1: incluye una captura o salida de terminal que demuestre que las herramientas están disponibles. Si alguna no se puede instalar, explica el problema y continúa con las que funcionen.


    6. Fase 1: reconocimiento inicial

    Antes de ejecutar herramientas, completa una pequeña ficha:

    CampoRespuesta
    Dominio autorizado
    Fecha y hora de inicio
    Sistema operativo
    Hipótesis inicial
    ¿Qué información esperas encontrar?

    Formula al menos dos hipótesis. Por ejemplo:

    • El dominio puede utilizar varios subdominios para separar servicios.
    • Parte de la infraestructura puede estar alojada en un proveedor cloud.

    No importa si después resultan incorrectas: deberán contrastarse con evidencias.


    7. Fase 2: enumeración pasiva con Amass

    Paso 1. Ejecutar Amass en modo pasivo

    Sustituye dominio-autorizado.example por el objetivo indicado por el profesor:

    amass enum -passive -d dominio-autorizado.example \
      -o resultados/amass.txt

    El parámetro -passive es obligatorio en este reto.

    Paso 2. Revisar los resultados

    cat resultados/amass.txt

    Cuenta los resultados:

    wc -l resultados/amass.txt

    Ordénalos y elimina duplicados:

    sort -u resultados/amass.txt -o resultados/amass_limpio.txt

    Paso 3. Interpretar

    Responde:

    1. ¿Cuántos subdominios distintos encontró Amass?
    2. ¿Qué nombres parecen corresponder a servicios web, correo, API, desarrollo o administración?
    3. ¿Un nombre como dev, test o staging demuestra que existe un entorno vulnerable? Justifica la respuesta.
    4. ¿Por qué el resultado de una fuente OSINT puede estar desactualizado?

    Evidencia 2: incluye el comando, el número de resultados y una selección razonada de hasta diez subdominios. No llenes el informe con capturas repetitivas.


    8. Fase 3: enumeración con Subfinder

    Paso 1. Ejecutar la segunda herramienta

    subfinder -d dominio-autorizado.example \
      -o resultados/subfinder.txt

    Paso 2. Limpiar la salida

    sort -u resultados/subfinder.txt -o resultados/subfinder_limpio.txt

    Paso 3. Comparar las herramientas

    Subdominios encontrados por ambas:

    comm -12 resultados/amass_limpio.txt resultados/subfinder_limpio.txt \
      > resultados/coincidencias.txt

    Encontrados solamente por Amass:

    comm -23 resultados/amass_limpio.txt resultados/subfinder_limpio.txt \
      > resultados/solo_amass.txt

    Encontrados solamente por Subfinder:

    comm -13 resultados/amass_limpio.txt resultados/subfinder_limpio.txt \
      > resultados/solo_subfinder.txt

    Combina todos los resultados:

    sort -u resultados/amass_limpio.txt resultados/subfinder_limpio.txt \
      > resultados/subdominios_finales.txt

    Obtén los recuentos:

    wc -l resultados/amass_limpio.txt \
          resultados/subfinder_limpio.txt \
          resultados/coincidencias.txt \
          resultados/subdominios_finales.txt

    Completa la tabla:

    ResultadoCantidad
    Amass
    Subfinder
    Coincidencias
    Total único

    Preguntas:

    1. ¿Qué herramienta ha encontrado más resultados?
    2. ¿Por qué dos herramientas OSINT pueden devolver resultados diferentes?
    3. ¿Por qué una coincidencia entre ambas fuentes aumenta la confianza, pero no confirma por sí sola que el servicio esté activo?

    Evidencia 3: tabla comparativa y explicación de las diferencias.


    9. Fase 4: resolución DNS

    Ahora comprobarás qué nombres de la lista pueden resolverse actualmente.

    Paso 1. Probar manualmente un subdominio

    host subdominio.dominio-autorizado.example

    También puedes consultar registros concretos:

    dig +short A subdominio.dominio-autorizado.example
    dig +short AAAA subdominio.dominio-autorizado.example
    dig +short CNAME subdominio.dominio-autorizado.example

    Paso 2. Automatizar la resolución de la lista

    while IFS= read -r subdominio; do
      echo "### $subdominio"
      host "$subdominio"
    done < resultados/subdominios_finales.txt \
      | tee resultados/resolucion_dns.txt

    Paso 3. Crear una lista única de IPv4

    while IFS= read -r subdominio; do
      dig +short A "$subdominio"
    done < resultados/subdominios_finales.txt \
      | grep -E '^[0-9]+(\.[0-9]+){3}$' \
      | sort -u \
      > resultados/ips.txt

    Revisa el resultado:

    cat resultados/ips.txt
    wc -l resultados/ips.txt

    Paso 4. Analizar

    Responde:

    1. ¿Todos los nombres encontrados mediante OSINT resuelven actualmente?
    2. ¿Hay varios subdominios que apunten a la misma IP?
    3. ¿Has encontrado registros CNAME?
    4. ¿Qué puede significar que varios servicios compartan dirección IP?
    5. ¿Qué diferencia existe entre no resolver un nombre y demostrar que nunca existió?

    Evidencia 4: presenta una tabla con una muestra de entre cinco y diez resultados.

    SubdominioTipo de registroIP o destino¿Resuelve?Observación

    10. Fase 5: contexto de las direcciones IP

    Selecciona un máximo de cinco IP públicas distintas. No es necesario consultar todas si la lista es muy grande.

    Paso 1. Consulta WHOIS

    whois DIRECCION_IP

    Busca datos como:

    • Organización o propietario del rango.
    • ASN, si aparece.
    • País de registro.
    • Rango o bloque de red.
    • Contactos de abuso, sin utilizarlos ni recopilar datos innecesarios.

    El país registrado en WHOIS no tiene por qué coincidir con la ubicación física exacta del servidor.

    Paso 2. Consulta GeoIP local

    geoiplookup DIRECCION_IP

    Paso 3. Consulta una API desde terminal

    curl -s "https://ipinfo.io/DIRECCION_IP/json" | jq

    Extrae solamente algunos campos:

    curl -s "https://ipinfo.io/DIRECCION_IP/json" \
      | jq '{ip, city, region, country, org, loc}'

    Respeta los límites del servicio: una consulta por cada IP seleccionada es suficiente.

    Paso 4. Correlacionar

    Completa la tabla:

    IPSubdominios asociadosOrganización/ASNPaís aproximadoPosible proveedorConfianza
    Alta/Media/Baja

    Responde:

    1. ¿Parece infraestructura propia, alojamiento compartido, CDN o proveedor cloud?
    2. ¿Coinciden WHOIS, GeoIP y la API?
    3. ¿Qué campos son hechos observados y cuáles son inferencias?
    4. ¿Por qué no debemos presentar una geolocalización de IP como una ubicación exacta?

    Evidencia 5: tabla completada y una conclusión prudente sobre la infraestructura.


    11. Fase 6: construir el script atlas.sh

    Debes crear un script que automatice el proceso básico.

    Requisitos mínimos

    El script deberá:

    1. Recibir un dominio como argumento.
    2. Comprobar que se ha indicado dicho argumento.
    3. Crear un directorio de resultados.
    4. Ejecutar Amass en modo pasivo.
    5. Ejecutar Subfinder.
    6. Combinar y eliminar duplicados.
    7. Resolver las direcciones IPv4.
    8. Guardar los resultados en archivos.
    9. Mostrar un resumen final.

    Plantilla orientativa

    Guárdala como script/atlas.sh y completa las partes marcadas:

    #!/usr/bin/env bash
    
    set -u
    
    if [ "$#" -ne 1 ]; then
      echo "Uso: $0 dominio-autorizado.example"
      exit 1
    fi
    
    DOMINIO="$1"
    FECHA="$(date +%Y%m%d_%H%M%S)"
    SALIDA="resultados_${DOMINIO}_${FECHA}"
    
    mkdir -p "$SALIDA"
    
    echo "[+] Iniciando reconocimiento pasivo de: $DOMINIO"
    
    # 1. Comprobar que las herramientas necesarias existen.
    # PISTA: command -v nombre_herramienta
    
    # 2. Ejecutar Amass exclusivamente en modo pasivo.
    
    # 3. Ejecutar Subfinder.
    
    # 4. Ordenar, combinar y eliminar duplicados.
    
    # 5. Resolver las direcciones IPv4 con dig.
    
    # 6. Mostrar el número de subdominios e IP únicas.
    
    echo "[+] Proceso finalizado. Resultados guardados en: $SALIDA"

    Da permiso de ejecución:

    chmod +x script/atlas.sh

    Ejecútalo únicamente con el dominio autorizado:

    ./script/atlas.sh dominio-autorizado.example

    Validaciones que debe incorporar

    Como mínimo, comprueba la presencia de cada herramienta:

    if ! command -v amass >/dev/null 2>&1; then
      echo "Error: Amass no está instalado."
      exit 1
    fi

    Repite o adapta la validación para las demás herramientas.

    Pruebas obligatorias

    Documenta qué ocurre cuando:

    • Se ejecuta sin argumentos.
    • Se ejecuta con el dominio autorizado.
    • Falta una herramienta necesaria.
    • Una de las herramientas no devuelve resultados.

    Evidencia 6: código completo del script, capturas o salidas de las pruebas y explicación de su funcionamiento.


    12. Fase 7: análisis final

    Redacta una conclusión que responda a estas preguntas:

    1. ¿Cuál es la superficie externa observada?
    2. ¿Cuántos subdominios únicos se han identificado?
    3. ¿Cuántos resolvían en el momento del análisis?
    4. ¿Qué proveedores o redes parecen alojarlos?
    5. ¿Existen indicios de servicios de desarrollo, pruebas, API o correo?
    6. ¿Qué resultados tienen una confianza alta, media o baja?
    7. ¿Qué limitaciones ha tenido la investigación?
    8. ¿Se confirmaron las hipótesis iniciales?
    9. ¿Qué recomendarías revisar al responsable del dominio?

    Las recomendaciones deben ser defensivas. Por ejemplo:

    • Mantener un inventario de subdominios.
    • Eliminar registros DNS abandonados.
    • Revisar nombres que revelen información innecesaria.
    • Comprobar que los entornos de prueba no estén publicados accidentalmente.
    • Repetir periódicamente el inventario pasivo.

    No afirmes que existe una vulnerabilidad si no dispones de evidencia suficiente.


    13. Entrega

    Entrega un archivo ZIP con esta estructura:

    operacion-atlas/
    ├── README.md
    ├── capturas/
    │   ├── 01_herramientas.png
    │   ├── 02_amass.png
    │   ├── 03_subfinder.png
    │   └── ...
    ├── resultados/
    │   ├── amass.txt
    │   ├── subfinder.txt
    │   ├── coincidencias.txt
    │   ├── subdominios_finales.txt
    │   ├── resolucion_dns.txt
    │   └── ips.txt
    └── script/
        └── atlas.sh

    El archivo README.md será el informe principal y deberá contener:

    1. Portada e identificación del alumno o equipo.
    2. Objetivo y alcance autorizado.
    3. Entorno y herramientas.
    4. Hipótesis iniciales.
    5. Procedimiento reproducible.
    6. Evidencias seleccionadas.
    7. Tablas de resultados.
    8. Explicación del script.
    9. Conclusiones y recomendaciones.
    10. Limitaciones y fuentes consultadas.

    No se valorará mejor un informe por tener más capturas. Se valorará que cada evidencia sea legible, necesaria y esté interpretada.


    14. Rúbrica de evaluación

    CriterioPuntuación
    Preparación, alcance ético y organización1 punto
    Enumeración pasiva con Amass y Subfinder2 puntos
    Limpieza, comparación y combinación de resultados1,5 puntos
    Resolución DNS y análisis de IP1,5 puntos
    Script Bash, validaciones y pruebas2 puntos
    Interpretación, correlación y conclusiones1,5 puntos
    Calidad del README y evidencias0,5 puntos
    Total10 puntos

    Penalizaciones importantes

    • Uso de técnicas activas no autorizadas: la práctica podrá considerarse no superada.
    • Investigación de dominios fuera del alcance: la práctica podrá considerarse no superada.
    • Script que no se explica o no se prueba: no se considerará completamente válido.
    • Capturas sin interpretación: tendrán poco valor como evidencia.
    • Resultados o conclusiones inventados: penalización grave.

    15. Nivel avanzado opcional: inteligencia reproducible

    Quienes terminen antes pueden incorporar estas mejoras:

    Mejora A. Archivo CSV

    Genera un archivo con el formato:

    subdominio,ip
    www.dominio.example,203.0.113.10
    api.dominio.example,203.0.113.20

    Mejora B. Parámetros adicionales

    Permite utilizar:

    ./script/atlas.sh -d dominio-autorizado.example -o informe

    Mejora C. Registro de ejecución

    Guarda fecha, herramienta, versión y comando ejecutado en un archivo log.txt.

    Mejora D. Manejo de errores

    Haz que el script continúe de forma controlada si Amass o Subfinder falla, indicando qué fuente no estuvo disponible.

    Mejora E. Comparación temporal

    Ejecuta el análisis en dos momentos autorizados distintos y compara las listas:

    comm -13 resultado_anterior.txt resultado_actual.txt

    Explica qué nombres son nuevos, cuáles han desaparecido y por qué eso no basta para asegurar que se haya producido un cambio real en la infraestructura.


    16. Pregunta de cierre

    Si todas las herramientas utilizadas consultan fuentes públicas, ¿por qué sigue siendo necesario definir un alcance, aplicar límites y tratar los resultados con responsabilidad?

  • Auditoría pasiva con Google Dorks

    Auditoría pasiva con Google Dorks

    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:


    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:

    1. Un dominio de laboratorio proporcionado por el profesor.
    2. Un dominio propio del centro o del alumno para el que exista autorización.
    3. 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

    1. Cread una carpeta con la siguiente estructura:
    reto-google-dorks/
    ├── README.md
    └── img/
    1. 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”.
    1. 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
    -terminoCómo se excluyen resultados
    ORCó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.

    1. Ejecutad una búsqueda general:
    site:DOMINIO-AUTORIZADO
    1. 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.
    1. 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
    1. 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:

    1. ¿La existencia pública de una página de inicio de sesión es por sí sola una vulnerabilidad?
    2. ¿Qué información puede revelar la estructura de una URL?
    3. ¿Qué resultados son normales y cuáles deberían revisarse?
    4. ¿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.

    1. Elegid dos categorías relacionadas con exposición de información.
    2. Seleccionad un ejemplo de consulta de cada categoría.
    3. Explicad qué intenta localizar, sin ejecutarlo sobre organizaciones reales.
    4. Transformadlo en una versión segura para el dominio de laboratorio.
    5. 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:

    IDConsultaHallazgo resumidoEvidenciaProbabilidadImpactoRiesgo¿Falso positivo?
    H-01site:... filetype:pdfDocumento público antiguoURL y capturaMediaBajoBajoNo

    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:

    1. ¿Qué diferencia existe entre una búsqueda normal y un Google Dork?
    2. ¿Por qué una página indexada no es automáticamente una vulnerabilidad?
    3. ¿Cuál ha sido la combinación de operadores más útil?
    4. ¿Qué limitaciones tiene este tipo de auditoría?
    5. ¿Qué riesgo puede tener publicar documentos aparentemente inofensivos?
    6. ¿Qué debe hacer un auditor si encuentra información sensible de forma accidental?
    7. ¿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:

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

    CriterioPeso
    Uso correcto y variado de operadores20 %
    Metodología paso a paso y reproducibilidad15 %
    Interpretación de resultados y falsos positivos15 %
    Clasificación razonada de riesgos15 %
    Medidas de mitigación15 %
    Calidad del README.md y de las evidencias10 %
    Ética, privacidad y cumplimiento de las normas10 %

    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.

    DominioTemáticaEjemplos seguros
    boe.esLegislación españolasite:boe.es filetype:pdf ciberseguridad
    ine.esEstadísticas públicassite:ine.es filetype:xlsx población
    datos.gob.esDatos abiertossite:datos.gob.es filetype:csv transporte
    administracion.gob.esAdministración públicasite:administracion.gob.es filetype:pdf empleo
    europa.euUnión Europeasite:europa.eu filetype:pdf cybersecurity
    data.europa.euDatos abiertos europeossite:data.europa.eu \"open data\"
    who.intSalud pública internacionalsite:who.int filetype:pdf cybersecurity
    un.orgNaciones Unidassite:un.org filetype:pdf \"artificial intelligence\"
    nasa.govCiencia y espaciosite:nasa.gov filetype:pdf mars
    noaa.govMeteorología y océanossite:noaa.gov filetype:pdf climate
    mit.eduUniversidad e investigaciónsite:mit.edu filetype:pdf \"computer security\"
    stanford.eduInvestigación académicasite:stanford.edu filetype:pptx cybersecurity
    docs.python.orgDocumentación técnicasite:docs.python.org intitle:\"Python\" tutorial
    developer.mozilla.orgDesarrollo website:developer.mozilla.org \"HTTP authentication\"
    wikipedia.orgContenido enciclopédicosite:wikipedia.org intitle:OSINT
    archive.orgArchivo históricosite:archive.org filetype:pdf networking
  • OSINT – Investigación digital a partir de una fotografía

    OSINT – Investigación digital a partir de una fotografía

    Investigación digital a partir de una fotografía

    1. Introducción

    Una fotografía puede contener mucha más información de la que se aprecia a simple vista. Además de la propia imagen, el archivo puede guardar metadatos técnicos, fechas, coordenadas, información del dispositivo utilizado y otros datos.

    En esta práctica asumirás el papel de un analista OSINT (Open Source Intelligence). Tu misión será investigar una fotografía y obtener toda la información posible empleando únicamente fuentes abiertas, herramientas gratuitas y técnicas legales.

    No todas las fotografías contienen las mismas pistas. Por tanto, no es obligatorio completar con éxito todos los apartados. También se valorará que expliques correctamente:

    • Qué técnica has utilizado.
    • Qué resultado has obtenido.
    • Qué limitaciones has encontrado.
    • Qué información no has podido verificar.
    • Por qué consideras fiable o no una conclusión.

    2. Objetivos

    Al finalizar la práctica deberás ser capaz de:

    • Examinar técnicamente un archivo de imagen.
    • Extraer e interpretar sus metadatos.
    • Realizar búsquedas inversas de imágenes.
    • Analizar visualmente lugares, objetos, textos y personas sin identificarlas de forma invasiva.
    • Aplicar técnicas básicas de geolocalización.
    • Buscar información relacionada en fuentes abiertas.
    • Contrastar información utilizando varias fuentes.
    • Diferenciar entre evidencia, indicio, hipótesis y conclusión.
    • Documentar de forma ordenada una investigación OSINT.
    • Comprender los riesgos de privacidad asociados a las fotografías.

    3. Normas de la investigación

    La práctica se realizará únicamente con:

    • Fotografías proporcionadas por el profesor.
    • Fotografías propias.
    • Imágenes publicadas con una licencia adecuada.
    • Imágenes de lugares públicos o utilizadas expresamente con fines educativos.

    No está permitido:

    • Investigar a compañeros, profesores o particulares sin su consentimiento.
    • Intentar acceder a cuentas privadas.
    • Contactar con personas que aparezcan en la fotografía.
    • Publicar datos personales obtenidos durante la investigación.
    • Utilizar reconocimiento facial para identificar personas reales.
    • Acosar, seguir o localizar el domicilio de una persona.
    • Modificar o destruir el archivo original.
    • Presentar como segura una información que solamente es una suposición.

    4. Preparación del archivo

    Antes de empezar, crea una carpeta con la siguiente estructura:

    investigacion-osint/
    ├── imagen-original/
    ├── copias-trabajo/
    ├── capturas/
    ├── evidencias/
    └── README.md

    Guarda la fotografía original sin modificar dentro de imagen-original.

    Realiza todas las pruebas sobre una copia situada en copias-trabajo.

    Registro inicial

    Anota:

    • Nombre del archivo.
    • Formato.
    • Tamaño en bytes.
    • Dimensiones en píxeles.
    • Fecha y hora en la que recibiste el archivo.
    • Procedencia conocida de la fotografía.
    • Herramienta utilizada para obtener cada dato.

    Integridad del archivo

    Calcula al menos el hash SHA-256 de la fotografía.

    Ejemplo con Linux:

    sha256sum fotografia.jpg

    Ejemplo con PowerShell:

    Get-FileHash fotografia.jpg -Algorithm SHA256

    Explica para qué sirve un hash y por qué resulta útil conservarlo durante una investigación.


    5. Líneas posibles de investigación

    Deberás realizar todas las fases básicas y elegir varias investigaciones adicionales según las características de la fotografía.

    Fase 1. Inspección visual inicial

    Observa la imagen antes de utilizar buscadores o herramientas automáticas.

    Busca y registra elementos como:

    • Carteles.
    • Matrículas, que deberán ocultarse en la entrega.
    • Nombres de calles.
    • Nombres de comercios.
    • Logotipos.
    • Idiomas.
    • Señales de tráfico.
    • Banderas.
    • Edificios o monumentos.
    • Medios de transporte.
    • Uniformes.
    • Vegetación.
    • Tipo de carretera.
    • Arquitectura.
    • Mobiliario urbano.
    • Clima.
    • Relieve del terreno.
    • Posición del sol.
    • Sombras.
    • Cualquier elemento poco habitual.

    Crea una primera lista de hipótesis sin realizar todavía búsquedas.

    Ejemplo:

    ObservaciónPosible significadoGrado de confianza
    Señal triangular con borde rojoProbablemente EuropaMedio
    Texto aparentemente en portuguésPortugal o BrasilBajo
    Tranvía amarilloPodría ser LisboaBajo

    Las primeras hipótesis pueden ser incorrectas. Esto no se penalizará si posteriormente se contrastan.


    Fase 2. Análisis de metadatos

    Comprueba si la fotografía contiene metadatos EXIF, IPTC o XMP.

    Puedes utilizar herramientas como:

    • ExifTool.
    • Metadata2Go.
    • Jeffrey’s Image Metadata Viewer.
    • Exif.tools.
    • Propiedades del archivo del sistema operativo.

    Busca, si están disponibles, los siguientes campos:

    • Fabricante del dispositivo.
    • Modelo de cámara o teléfono.
    • Fecha y hora de captura.
    • Fecha de modificación.
    • Software utilizado.
    • Orientación.
    • Resolución.
    • Distancia focal.
    • Apertura.
    • Tiempo de exposición.
    • Sensibilidad ISO.
    • Uso del flash.
    • Coordenadas GPS.
    • Altitud.
    • Miniatura incrustada.
    • Autor o propietario.
    • Comentarios.
    • Copyright.

    Debes responder:

    1. ¿Qué metadatos conserva la fotografía?
    2. ¿Cuáles pueden ser útiles para la investigación?
    3. ¿Podrían haber sido modificados?
    4. ¿Existe alguna contradicción entre los metadatos y la imagen?
    5. ¿La fecha corresponde a la captura o a una modificación posterior?
    6. ¿Qué información privada podría revelar el archivo?

    Si aparecen coordenadas GPS, represéntalas en un mapa y compáralas con el contenido visible en la fotografía. No publiques coordenadas de domicilios particulares.


    Fase 3. Búsqueda inversa de imágenes

    Utiliza al menos dos servicios diferentes:

    • Google Lens.
    • Bing Visual Search.
    • TinEye.
    • Yandex Images.

    Compara los resultados obtenidos en cada buscador.

    Busca:

    • La misma fotografía.
    • Versiones recortadas.
    • Versiones con diferente resolución.
    • Publicaciones anteriores.
    • La posible fuente original.
    • Páginas donde se haya reutilizado.
    • Imágenes visualmente parecidas.
    • Posibles manipulaciones.

    Registra:

    BuscadorConsulta o imagen utilizadaResultado relevanteFecha del resultadoValoración

    Prueba también a realizar búsquedas con:

    • La imagen completa.
    • Un recorte de un edificio.
    • Un cartel o logotipo.
    • Un objeto singular.
    • El paisaje del fondo.
    • Una marca de agua.

    Indica cuál de los buscadores ha proporcionado mejores resultados y por qué.


    Fase 4. Extracción y análisis de texto

    Busca cualquier texto presente en la imagen:

    • Carteles.
    • Escaparates.
    • Camisetas.
    • Vehículos.
    • Señales.
    • Billetes.
    • Pantallas.
    • Documentos.
    • Nombres comerciales.

    Puedes utilizar herramientas OCR como:

    • Google Lens.
    • Microsoft Lens.
    • OCR.Space.
    • Tesseract.
    • Herramientas de OCR integradas en móviles u ordenadores.

    Después:

    1. Copia el texto detectado.
    2. Corrige posibles errores del OCR.
    3. Identifica el idioma.
    4. Traduce el texto si es necesario.
    5. Busca frases exactas entre comillas.
    6. Investiga nombres, dominios, teléfonos o establecimientos.
    7. Comprueba si el texto permite relacionar la fotografía con una ubicación o acontecimiento.

    No debes llamar a teléfonos, escribir a direcciones ni contactar con las personas encontradas.


    Fase 5. Geolocalización

    Intenta determinar:

    • País.
    • Región o provincia.
    • Ciudad.
    • Zona aproximada.
    • Punto concreto, únicamente si se trata de un lugar público.

    Puedes utilizar las siguientes pistas:

    Infraestructura

    • Forma y color de las señales.
    • Marcas de la carretera.
    • Semáforos.
    • Farolas.
    • Contenedores.
    • Bolardos.
    • Aceras.
    • Cableado.
    • Postes eléctricos.
    • Paradas de transporte.
    • Matrículas, sin publicar números completos.

    Entorno natural

    • Vegetación.
    • Tipo de suelo.
    • Montañas.
    • Costa.
    • Clima.
    • Estación del año.
    • Fauna visible.

    Entorno urbano

    • Arquitectura.
    • Materiales de construcción.
    • Numeración de edificios.
    • Comercios.
    • Monumentos.
    • Transporte público.
    • Logotipos municipales.

    Herramientas de apoyo

    • Google Maps.
    • Google Street View.
    • Google Earth.
    • OpenStreetMap.
    • Mapillary.
    • Wikimapia.
    • GeoHints.
    • Overpass Turbo, como opción avanzada.

    La ubicación debe justificarse comparando elementos visibles. No será suficiente escribir: “Google Lens dice que es Madrid”.


    Fase 6. Análisis de objetos y elementos

    Selecciona varios objetos relevantes y trata de identificarlos:

    • Modelo aproximado de vehículo.
    • Marca de un producto.
    • Tipo de uniforme.
    • Modelo de teléfono u ordenador.
    • Obra de arte.
    • Monumento.
    • Planta o animal.
    • Máquina o herramienta.
    • Cartel publicitario.
    • Logotipo.

    Para cada elemento indica:

    • Qué crees que es.
    • Cómo lo has buscado.
    • Qué fuentes has consultado.
    • Qué características coinciden.
    • Qué características no coinciden.
    • Nivel de confianza de la identificación.

    Fase 7. Análisis temporal o cronolocalización

    Intenta estimar cuándo fue tomada la fotografía.

    Puedes investigar:

    • Fecha incluida en los metadatos.
    • Carteles de eventos.
    • Publicidad temporal.
    • Obras en edificios.
    • Estado de la vegetación.
    • Ropa de las personas.
    • Meteorología.
    • Decoración navideña o festividades.
    • Modelos de vehículos.
    • Versiones de productos.
    • Posición del sol y dirección de las sombras.
    • Imágenes históricas de Street View.
    • Noticias o publicaciones relacionadas.

    Clasifica el resultado como:

    • Fecha exacta confirmada.
    • Intervalo temporal probable.
    • Estación del año estimada.
    • Fecha desconocida.

    Explica siempre qué evidencias apoyan la estimación.


    Fase 8. Análisis meteorológico

    Si has deducido una posible fecha y lugar, comprueba si el tiempo visible coincide con registros meteorológicos históricos.

    Observa:

    • Cielo despejado o cubierto.
    • Lluvia.
    • Nieve.
    • Suelo mojado.
    • Dirección aparente del viento.
    • Tipo de ropa.
    • Longitud de las sombras.
    • Estado de la vegetación.

    Este análisis no suele demostrar por sí solo una ubicación o fecha, pero puede servir para apoyar o descartar una hipótesis.


    Fase 9. Investigación del contexto

    Trata de averiguar por qué pudo tomarse la fotografía.

    Busca relaciones con:

    • Noticias.
    • Eventos.
    • Manifestaciones.
    • Conciertos.
    • Competiciones deportivas.
    • Ferias.
    • Inauguraciones.
    • Catástrofes naturales.
    • Obras públicas.
    • Publicaciones en páginas institucionales.
    • Bancos de imágenes.
    • Páginas turísticas.
    • Redes sociales públicas.

    No des por hecho que dos fotografías corresponden al mismo acontecimiento únicamente porque se parezcan.


    Fase 10. Comprobación de manipulación

    Analiza si la imagen presenta señales de edición o manipulación.

    Busca:

    • Sombras incoherentes.
    • Reflejos imposibles.
    • Diferencias de iluminación.
    • Bordes extraños.
    • Elementos repetidos.
    • Perspectiva incorrecta.
    • Texto deformado.
    • Zonas excesivamente borrosas.
    • Diferencias de compresión.
    • Metadatos de programas de edición.
    • Partes con distinta resolución.

    Puedes utilizar herramientas como:

    • Forensically.
    • FotoForensics.
    • ExifTool.
    • Ampliación y ajustes de contraste.
    • Búsqueda inversa de recortes.

    Las herramientas automáticas no proporcionan una prueba definitiva. Sus resultados deben interpretarse con prudencia.


    Fase 11. Esteganografía — ampliación avanzada

    Comprueba si la imagen podría contener información oculta.

    Posibles comprobaciones:

    • Archivos añadidos después del final de la imagen.
    • Texto incrustado.
    • Datos ocultos en los bits menos significativos.
    • Contenido comprimido dentro del archivo.
    • Información visible al separar canales de color.

    Herramientas posibles:

    • Binwalk.
    • Strings.
    • StegHide.
    • StegSeek.
    • Zsteg, para formatos compatibles.
    • Aperi’Solve.
    • CyberChef.

    Esta fase solamente debe realizarse sobre la imagen entregada para la práctica. No descargues ni ejecutes archivos desconocidos fuera del entorno controlado del laboratorio.


    6. Clasificación de los resultados

    Cada descubrimiento deberá etiquetarse de una de estas maneras:

    ClasificaciónSignificado
    Hecho confirmadoEstá demostrado mediante una evidencia fiable
    Muy probableExisten varias evidencias coincidentes
    PosibleHay algún indicio, pero no es suficiente
    HipótesisExplicación pendiente de comprobación
    DescartadoLas evidencias demuestran que no es correcto
    No determinadoNo se ha podido obtener información suficiente

    También asignarás un nivel de confianza:

    • Alto.
    • Medio.
    • Bajo.

    Ejemplo:

    La fotografía probablemente fue tomada en la Plaza Mayor de Salamanca. La arquitectura y el nombre visible de un comercio coinciden con Street View. Nivel de confianza: alto.


    7. Registro de evidencias

    Incluye una tabla general:

    IDDato investigadoHerramienta o fuenteResultadoClasificaciónConfianza
    E01Modelo del dispositivoExifTooliPhone 14Hecho confirmadoAlto
    E02CiudadStreet View y cartelValenciaMuy probableAlto
    E03FechaTipo de eventoMayo de 2024PosibleMedio

    Cada evidencia debe incluir:

    • Captura de pantalla.
    • Enlace a la fuente, cuando exista.
    • Fecha y hora de consulta.
    • Explicación del proceso.
    • Interpretación del resultado.

    Las capturas deben ocultar datos personales que no sean necesarios para la práctica.


    8. Informe final

    La entrega se realizará en un archivo README.md escrito en Markdown.

    Estructura obligatoria

    • Título de la investigación.
    • Nombre del alumno o equipo.
    • Curso.
    • Fecha.
    • Imagen reducida o censurada, si procede.

    2. Resumen ejecutivo

    Explicación breve de los principales descubrimientos.

    3. Descripción del archivo

    • Nombre.
    • Formato.
    • Tamaño.
    • Dimensiones.
    • Hash SHA-256.
    • Procedencia.

    4. Metodología

    Explicación de las fases realizadas y las herramientas empleadas.

    5. Análisis visual

    Observaciones iniciales e hipótesis.

    6. Análisis de metadatos

    Resultados obtenidos e interpretación.

    7. Búsqueda inversa

    Buscadores utilizados y resultados.

    8. Investigación del texto

    OCR, traducciones y búsquedas relacionadas.

    9. Geolocalización

    Proceso seguido para identificar el lugar.

    10. Análisis temporal

    Fecha o intervalo estimado.

    11. Otros análisis

    Objetos, contexto, meteorología, manipulación o esteganografía.

    12. Tabla de evidencias

    Listado completo de descubrimientos y nivel de confianza.

    13. Conclusiones

    Debes separar claramente:

    • Lo que has podido confirmar.
    • Lo que consideras probable.
    • Lo que no has podido determinar.
    • Las hipótesis descartadas.

    14. Reflexión sobre privacidad

    Responde:

    1. ¿Qué información sensible podría revelar una fotografía?
    2. ¿Qué datos eliminarías antes de publicarla?
    3. ¿Las redes sociales conservan siempre los metadatos?
    4. ¿Qué riesgos tiene publicar una imagen tomada en casa?
    5. ¿Cómo podría protegerse una persona antes de compartir fotografías?

    15. Fuentes consultadas

    Incluye todas las herramientas, páginas, mapas, artículos y documentos utilizados.


    9. Requisitos mínimos

    Para superar la práctica deberás realizar, como mínimo:

    • Inspección visual.
    • Cálculo del hash.
    • Análisis de metadatos.
    • Dos búsquedas inversas.
    • Extracción de texto, si existe.
    • Un intento razonado de geolocalización.
    • Análisis de al menos tres elementos visibles.
    • Tabla de evidencias.
    • Clasificación del nivel de confianza.
    • Reflexión sobre privacidad.
    • Documentación completa en Markdown.

    10. Opciones de ampliación

    Los alumnos que quieran profundizar podrán realizar una o varias de estas tareas:

    • Comparar los metadatos antes y después de enviar la fotografía por distintas plataformas.
    • Crear una copia sin metadatos y verificar su eliminación.
    • Analizar diferencias entre la imagen original y una versión publicada en una red social.
    • Utilizar Street View histórico.
    • Investigar la dirección de las sombras.
    • Comparar registros meteorológicos.
    • Buscar versiones anteriores de la fotografía.
    • Detectar posibles recortes o ediciones.
    • Utilizar herramientas de análisis forense.
    • Examinar si existe información oculta mediante esteganografía.
    • Elaborar una línea temporal de publicación.
    • Crear un mapa con los lugares candidatos.
    • Analizar cómo cambiarían los resultados si solamente se dispusiera de una captura de pantalla.

    11. Rúbrica orientativa

    ApartadoPorcentaje
    Organización, Markdown y presentación10 %
    Inspección visual y formulación de hipótesis10 %
    Análisis técnico y metadatos15 %
    Búsqueda inversa y localización de fuentes15 %
    OCR, objetos y pistas visuales10 %
    Geolocalización y análisis temporal15 %
    Evidencias, contraste y nivel de confianza15 %
    Conclusiones, privacidad y límites éticos10 %

    No se calificará únicamente la cantidad de información encontrada. Se valorará especialmente:

    • La calidad del razonamiento.
    • La capacidad de contrastar fuentes.
    • La documentación de los intentos fallidos.
    • La separación entre hechos e hipótesis.
    • El uso responsable de las herramientas.
    • La claridad de las conclusiones.

    12. Preguntas para la defensa

    El profesor podrá preguntar:

    • ¿Cuál ha sido la evidencia más importante?
    • ¿Qué dato parecía correcto inicialmente y luego descartaste?
    • ¿Qué herramienta te ha dado mejores resultados?
    • ¿Podrían estar manipulados los metadatos?
    • ¿Cómo has confirmado la ubicación?
    • ¿Qué grado de confianza asignas a tu conclusión?
    • ¿Qué otra explicación podría tener la evidencia?
    • ¿Qué dato no publicarías por motivos de privacidad?
    • ¿Podría otra persona reproducir tu investigación?
    • ¿Qué harías a continuación si dispusieras de más tiempo?

    13. Resultado esperado

    La investigación deberá finalizar con una conclusión prudente y verificable.

    No debes escribir:

    La foto fue tomada en Sevilla.

    Es preferible escribir:

    La fotografía fue tomada probablemente en Sevilla. El nombre del establecimiento visible coincide con un comercio situado en esa ciudad y la fachada puede verificarse en Street View. No se dispone de coordenadas GPS, por lo que la ubicación se clasifica como muy probable, con un nivel de confianza alto.

    En OSINT, reconocer que no existen pruebas suficientes también es un resultado válido.


    RETOS

    1. Plaza del Faro

    naliza el archivo reto_osint_plaza_del_faro.jpg y obtén toda la información posible sin consultar la solución del profesor.

    Debes estudiar:

    • Elementos visibles y posibles pistas engañosas.
    • Textos mediante OCR.
    • Lugar y momento aproximados.
    • Coherencia de luces y sombras.
    • Metadatos técnicos, EXIF, IPTC o XMP.
    • Posible contenido añadido u oculto en el archivo.
    • Diferencia entre hechos, indicios e hipótesis.

    2. Estación ferroviaria ficticia de montaña.

    Analiza reto_osint_estacion_valle_nevado.jpg sin consultar la soluciçon del profesor.

    Investiga los elementos visibles, los textos mediante OCR, la estación del año, la meteorología, la hora aproximada, los metadatos y cualquier contenido añadido al archivo.

    Debes diferenciar entre:

    • Evidencias confirmadas.
    • Indicios razonables.
    • Hipótesis pendientes.
    • Pistas engañosas.

    3. Bilbao

    Analiza el archivo reto_osint_avanzado_bilbao.png y reconstruye toda la cadena de evidencias.

    Objetivos

    • Geolocalizar la escena utilizando varias evidencias independientes.
    • Estimar fecha, hora, estación del año y condiciones meteorológicas.
    • Extraer textos mediante OCR y distinguir pistas válidas de señuelos.
    • Examinar la estructura interna del PNG y sus bloques de metadatos.
    • Detectar información codificada y explicar cómo se ha decodificado.
    • Comprobar si los canales de color contienen información oculta.
    • Detectar datos anexados después del final lógico de la imagen.
    • Construir y justificar la contraseña necesaria para recuperar la evidencia final.
    • Diferenciar entre indicio de edición y prueba de manipulación visual.

    Reglas

    No se proporciona una lista cerrada de herramientas. Cada decisión debe quedar documentada con comandos, capturas, resultados y nivel de confianza.

    El informe deberá incluir:

    1. Hash SHA-256 del archivo recibido.
    2. Análisis visual y OCR.
    3. Geolocalización razonada con al menos tres evidencias.
    4. Línea temporal y análisis de zona horaria.
    5. Inventario de bloques o chunks del PNG.
    6. Metadatos y cadenas encontradas.
    7. Análisis de esteganografía por canales y planos de bits.
    8. Búsqueda de firmas de archivos incrustados o anexados.
    9. Recuperación del código final.
    10. Separación entre hechos, hipótesis y pistas engañosas.

    No se considerará completa la práctica si únicamente se identifica la ciudad. El objetivo es reconstruir todas las capas del archivo.

  • Reconocimiento de dominios por terminal y scripting

    Reconocimiento de dominios por terminal y scripting

    ¿Qué es OSINT y por qué usar terminal?

    OSINT (Open Source Intelligence) es el arte —y la ciencia— de obtener información a partir de fuentes públicas, sin interactuar activamente con el objetivo ni alterar sistemas.

    Trabajar desde la terminal tiene varias ventajas clave:

    • Reproducibilidad: lo que haces hoy lo puedes repetir mañana.
    • Automatización: un comando hoy, un script mañana.
    • Mentalidad analítica: piensas en datos, no en interfaces.
    • Escalabilidad: una IP, cien dominios o mil subdominios.

    1. AMASS – Descubrimiento de subdominios (OSINT real)

    ¿Qué es Amass?

    Amass es una herramienta de OWASP diseñada para mapear la superficie externa de una organización, utilizando únicamente fuentes públicas cuando se trabaja en modo pasivo.

    No escanea puertos, no lanza exploits. Pregunta a Internet lo que Internet ya sabe.

    Instalación en Ubuntu

    
    
    
    
    
    sudo apt update
    sudo apt install amass 
    
    #Tambien puedes usar snap 
    snap install amass 
    
    

    Comprobación:

    
    
    
    
    
    amass version
    

    Uso básico (modo pasivo)

    
    
    
    
    
    amass enum -passive -d ejemplo.com
    

    Qué está ocurriendo aquí:

    • enum: modo enumeración
    • -passive: solo fuentes OSINT
    • -d: dominio objetivo

    Resultado típico:

    • mail.ejemplo.com
    • api.ejemplo.com
    • dev.ejemplo.com

    Cada subdominio es una posible pieza de infraestructura real.


    Uso con salida a archivo

    
    
    
    
    
    amass enum -passive -d ejemplo.com -o subdominios.txt
    

    Esto es clave para:

    • Documentar
    • Analizar después
    • Usar como entrada para otras herramientas

    Enumeración con múltiples dominios

    
    
    
    
    
    amass enum -passive -df dominios.txt -o resultados.txt
    

    Donde dominios.txt contiene:

    
    
    
    
    
    ejemplo.com
    ejemplo.org
    ejemplo.net
    

    Aquí ya empiezan a pensar como analistas, no como usuarios.


    Advertencia ética

    Amass no rompe nada, pero:

    • Solo se usa sobre dominios autorizados o de práctica
    • Nunca sobre empresas reales sin permiso
    • El objetivo es aprender metodología, no recolectar víctimas

    2. Subfinder – Enumeración rápida y minimalista

    ¿Qué es Subfinder?

    Subfinder hace una cosa y la hace muy bien:
    descubrir subdominios usando fuentes OSINT, de forma rápida y limpia.

    Es ideal para:

    • Resultados rápidos
    • Scripts
    • Integrarlo con otras herramientas

    Instalación en Ubuntu

    Opción repositorios:

    
    
    
    
    
    sudo apt install subfinder
    

    Opción manual (recomendado para versiones recientes):

    
    
    
    
    
    sudo apt install snapd
    sudo snap install subfinder
    

    Uso básico

    
    
    
    
    
    subfinder -d ejemplo.com
    

    Salida:

    • Lista de subdominios uno por línea
    • Sin ruido
    • Perfecto para canalizar a otros comandos

    Guardar resultados

    
    
    
    
    
    subfinder -d ejemplo.com -o subfinder.txt
    

    Comparación mental con Amass

    Aquí conviene explicárselo así al alumno:

    • Amass: más pesado, más contexto, más fuentes
    • Subfinder: rápido, limpio, directo
    • Ambos son OSINT pasivo
    • En un proyecto real, se usan juntos

    3. Geolocalización – Poniendo los pies en la Tierra

    La geolocalización no es solo “ver el país”.
    Es contexto físico, legal y técnico.


    3.1 Geolocalización de IP con whois

    
    
    
    
    
    whois 8.8.8.8
    

    Información relevante:

    • País
    • Organización
    • ASN
    • Rango de IPs

    Esto permite responder preguntas como:

    • ¿Está en Europa o fuera?
    • ¿Es cloud o infraestructura propia?
    • ¿Qué proveedor hay detrás?

    3.2 Uso de geoiplookup

    Instalación:

    
    
    
    
    
    sudo apt install geoip-bin
    

    Uso:

    
    
    
    
    
    geoiplookup 8.8.8.8
    

    Salida:

    • País
    • Región aproximada

    Ideal para scripting rápido.


    3.3 Geolocalización con APIs desde terminal

    Ejemplo con curl:

    
    
    
    
    
    curl ipinfo.io/8.8.8.8
    

    Devuelve JSON:

    • Ciudad
    • País
    • Coordenadas
    • ASN
    • Organización

    Aquí puedes introducir:

    • Parseo con jq
    • Automatización
    • Correlación con subdominios

    4. Uniendo piezas: OSINT como proceso

    Aquí es donde el taller se vuelve interesante.

    Ejemplo de flujo real:

    1. Amass descubre subdominios
    2. Subfinder confirma y amplía
    3. Se resuelven IPs
    4. Se geolocalizan
    5. Se detecta:
      • Infraestructura cloud
      • Distribución geográfica
      • Entornos de desarrollo expuestos

    No es magia. Es método.


    5. Ejemplo

    
    
    
    
    
    amass enum -passive -d ejemplo.com -o amass.txt
    subfinder -d ejemplo.com -o subfinder.txt
    sort amass.txt subfinder.txt | uniq > subdominios_finales.txt
    

    Luego:

    
    
    
    
    
    while read sub; do
      echo "Resolviendo $sub"
      host $sub
    done < subdominios_finales.txt
    

    Esto ya es pensar en scripts, no en comandos sueltos.


    OSINT no es “buscar cosas”, es formular hipótesis

    La terminal no es incómoda, es poderosa

    Cada dato aislado no dice nada

    La inteligencia aparece al correlacionar

  • Practica [OSINT]- SEÑALES DE VIDA (O ALGO PEOR) EN LA RED

    Practica [OSINT]- SEÑALES DE VIDA (O ALGO PEOR) EN LA RED

    Operación Nostromo: búsqueda de dispositivos comprometidos antes de que “algo” despierte…


    La nave USCSS Nostromo ha recibido una transmisión automática desde un sistema remoto. No se sabe si es una llamada de socorro… o una advertencia.
    La compañía ha encomendado al Equipo de Investigación (tus alumnos) usar Shodan para rastrear:

    1. Señales de dispositivos expuestos
    2. Orígenes de la transmisión
    3. Infraestructura del sistema remoto
    4. Posibles vectores de intrusión

    La misión: analizar patrones, encontrar conexiones y trazar el mapa de un “nido” digital escondido.

    La actividad se divide en 3 fases, cada una con un objetivo claro y un filtro de Shodan.

    FASE 1 — Localizar señales: “Ping de movimiento”

    Objetivo: practicar filtros por tipo de dispositivo + país/ciudad.

    El sensor de movimiento de la Nostromo detecta actividad anómala en una zona del sistema. Necesitamos saber qué dispositivos expuestos hay allí.

    Tareas:

    1. Buscar un tipo concreto de dispositivo (puerta automatizada, cámara IP, sistema industrial, etc.) Ejemplos:
      • Cámaras IP:
        product:GoAhead
        product:"Hikvision"
        port:554 has_screenshot:true
      • Paneles web expuestos:
        http.title:"login"
    2. Añadir filtro de ubicación (país o ciudad).
      Por ejemplo, España: country:ES product:GoAhead O por ciudad: city:Madrid http.title:login
    3. Apuntar IP, puerto, captura y versión como si fueran “señales biológicas”.


    FASE 2 — Identificar el origen de la transmisión

    Objetivo: buscar por organización o dominio.

    La señal parece provenir de una colonia (una empresa, universidad o dominio). Deben “explorar todas las instalaciones” de ese lugar.

    Ejercicios:

    1. Elegir una organización pública o conocida:
      Ejemplos: org:"Universidad Complutense" org:"Telefonica"
    2. Buscar todos los dispositivos de la misma entidad: hostname:"uic.es" hostname:"unizar.es"
    3. Revisar patrones:
      • ¿Qué puertos están abiertos?
      • ¿Qué servicios viejos aparecen?
      • ¿Hay dispositivos iguales repartidos por varias sedes?

    “Se detectan varias salas técnicas, ventilación, terminales…”
    Vamos, un nido perfecto para un xenomorfo.


    FASE 3 — Conexión entre señales: seguir el rastro del xenomorfo

    Objetivo: enlazar un dispositivo concreto → el resto del ecosistema.


    Han encontrado una máquina sospechosa que transmite paquetes extraños. La misión es identificar todo el entorno que la rodea.

    Cómo hacerlo:

    1. Selecciona un dispositivo que hayas encontrado en Fase 1.
    2. Observan:
      • dominio
      • ASN
      • organización
      • versión del servicio
    3. Construyen una nueva búsqueda:

      IP: 82.X.X.X
      org: "Ayuntamiento de ___"
      port 443 running nginx 1.18.0


      Entonces buscar:

      org:"Ayuntamiento de ___"
      product:"nginx"


      O incluso por ASN:

      asn:3352 (o el ASN que toque)

    4. Buscan patrones:
      • ¿Hay varios dispositivos vulnerables?
      • ¿Alguno tiene panel expuesto?
      • ¿Coinciden versiones?

    Misión Ash (ciencia sintética)

    Encontrar un dispositivo antiguo que no debería seguir activo:

    os:"Windows XP"
    

    o

    "Server: Apache/2.2"
    

    Misión Ripley: “Purgar la amenaza”

    Buscar servicios críticos abiertos sin autenticación:

    port:22 "OpenSSH_7"
    port:21 Anonymous
    

    Misión Bishop (android leal)

    Buscar paneles que tengan captura para analizar visualmente:

    has_screenshot:true city:Barcelona


    Registros:

    Informe breve estilo Weyland-Yutani
    (Ejemplo de redacción)

    • Recomendación para “contención”
    • Descripción de la amenaza detectada
    • Pruebas (capturas de Shodan)
    • Hipótesis del “nido” o red asociada

    (Ejemplo de redacción estilo Weyland-Yutani de la ficción de Alien)


    Alternativas interesantes a Shodan

    Herramienta / buscadorQué la hace útil / especialidad
    CensysEscanea infraestructura global, con foco extra en certificados SSL/TLS, puertos, hosts — útil para mapear superficie de ataque de forma sistemática. 5 Minute Breach+2We Live Security+2
    ZoomEyeSimilar a Shodan; ampliamente usada fuera del “mainstream” occidental. Puede servir para comparar visiones distintas del Internet expuesto. MarPoint+2SecurityVision.ru+2
    BinaryEdgePermite monitorear servicios, puertos abiertos, SSL, accesos remotos — y recibir alertas. Buena opción para vigilancia continua o auditorías periódicas. We Live Security+2LearnHub+2
    FofaOfrece sintaxis de búsqueda avanzada, lo que facilita búsquedas muy específicas (por puerto, servicio, sello de software, etc.). Puede servir bien para ejercicios dirigidos. We Live Security+1
    GreyNoiseNo es exactamente un “scanner” de dispositivos, sino más bien un filtro de ruido: ayuda a clasificar qué direcciones/IPs simplemente están haciendo escaneos automáticos masivos (ruido) frente a actividad potencialmente relevante. Útil para refinar resultados (filtrar falsos positivos). We Live Security+2LearnHub+2
    NetlasPlataforma más reciente, pensada para descubrimiento y monitorización global de “activos conectados”. Puede ser útil si buscas comparar con herramientas más consolidadas. SecurityVision.ru+2Netlas+2

    ⚠️ Cosas a tener en cuenta

    • Ninguna herramienta cubre todos los dispositivos — pueden faltar muchos servicios expuestos, por bloqueo, firewalls, NAT, técnicas de evasión.
    • Los datos recogidos (puertos, software, banners) pueden estar desactualizados o ser engañosos: muchas veces los sistemas cambian o los banners son falsos.
    • Uso de herramientas externas implica responsabilidad ética — incluso si lo haces con fines académicos, siempre debe mantenerse respeto por la privacidad y normas legales.
  • Google Hacking

    Google Hacking

    Google Hacking es una técnica de búsqueda utilizada para encontrar información específica en los motores de búsqueda, como Google.

    [!NOTA]
    Este tipo de búsquedas no son invasivas, ya que no hacen peticiones al servidor del objetivo, por lo que podemos utilizar estas técnicas libremente.

    Google Hacking Database

    https://www.exploit-db.com/google-hacking-database

    La Google Hacking Database (GHDB) es una colección de comandos de búsqueda de Google y técnicas de búsqueda avanzadas que se utilizan para encontrar información que puede ser útil en la realización de pruebas de penetración y en la investigación de seguridad.

    La GHDB fue creada por Johnny Long, un experto en seguridad informática, y es mantenida por una comunidad de profesionales de la seguridad informática. La GHDB contiene miles de comandos de búsqueda de Google y técnicas de búsqueda avanzadas que se utilizan para encontrar información confidencial, como contraseñas, información de inicio de sesión, archivos de configuración, archivos de registro y más.

    Los comandos de búsqueda de Google en la GHDB se organizan en categorías, como «Vulnerabilities», «Files containing passwords» y «Sensitive Directories». Cada comando de búsqueda viene con una descripción detallada de lo que busca y cómo se puede utilizar.

    La GHDB se utiliza comúnmente en pruebas de penetración y en la investigación de seguridad para buscar información confidencial que puede ser utilizada en un ataque. Es importante tener en cuenta que la GHDB debe utilizarse con precaución y solo con el permiso del propietario del sitio web o de la red que se está probando. También es importante asegurarse de que cualquier información confidencial descubierta se informe al propietario del sitio web o a las autoridades apropiadas.

    Google Dorks

    Los Google Dorks son combinaciones específicas de palabras o frases que se usan para realizar búsquedas avanzadas en Google y obtener resultados que no se pueden obtener mediante una búsqueda normal.

    Es importante tener en cuenta que los Google Dorks no son herramientas de hacking en sí mismas, sino una técnica para realizar búsquedas avanzadas en Google. Sin embargo, los Google Dorks pueden ser utilizados por los hackers para encontrar información sensible que puede ser utilizada en ataques posteriores. Por lo tanto, se recomienda utilizar los Google Dorks de manera responsable y con fines éticos, especialmente si se utilizan en el campo de la seguridad informática.

    OperadorDescripciónEjemploExplicación del ejemplo
    site:Limita resultados a un dominio específico.site:example.comEncuentra todas las páginas accesibles en example.com.
    inurl:Busca un término dentro de la URL.inurl:loginLocaliza páginas de inicio de sesión.
    filetype:Filtra por tipo de archivo.filetype:pdfEncuentra documentos PDF descargables.
    intitle:Busca un término en el título de la página.intitle:"confidential report"Busca documentos titulados “informe confidencial” o similares.
    intext: / inbody:Busca dentro del cuerpo del texto.intext:"password reset"Encuentra páginas con “restablecimiento de contraseña”.
    cache:Muestra la versión en caché de Google.cache:example.comVe contenido antiguo o previo de example.com.
    link:Encuentra páginas que enlazan a otra.link:example.comMuestra webs que tienen enlaces hacia example.com.
    related:Encuentra páginas parecidas a otra.related:example.comDescubre sitios similares a example.com.
    info:Muestra información básica sobre un sitio.info:example.comTítulo, descripción y datos del sitio.
    define:Busca definiciones de una palabra.define:phishingObtiene la definición de phishing.
    numrange:Busca números dentro de un rango.site:example.com numrange:1000-2000Busca páginas de ese dominio con números entre 1000 y 2000.
    allintext:Todas las palabras deben aparecer en el texto.allintext:admin password resetLocaliza páginas que contienen ambas palabras.
    allinurl:Todas las palabras deben aparecer en la URL.allinurl:admin panelBusca URLs con “admin” y “panel”.
    allintitle:Todas las palabras deben estar en el título.allintitle:confidential report 2023Busca títulos con esas tres palabras.
    ANDExige que todos los términos aparezcan.site:example.com AND (inurl:admin OR inurl:login)Busca paneles admin o login en example.com.
    ORAcepta cualquiera de los términos."linux" OR "ubuntu" OR "debian"Busca páginas que mencionen cualquiera de esos sistemas.
    NOTExcluye resultados con un término.site:bank.com NOT inurl:loginExcluye las páginas de login.
    * (comodín)Sustituye cualquier palabra/caracter.site:socialnetwork.com filetype:pdf user* manualEncuentra “user guide”, “user manual”, etc.
    .. (rango)Busca valores dentro de un intervalo numérico.site:ecommerce.com "price" 100..500Busca productos entre 100 y 500.
    "" (comillas)Busca coincidencia exacta."information security policy"Busca esa frase exacta.
    - (menos)Excluye un término concreto.site:news.com -inurl:sportsNoticias sin resultados deportivos.

    Ejemplos de uso:

    Google DorkDescripción
    intitle:"Index of" password.txtMuestra directorios que contienen archivos llamados “password.txt”.
    intitle:"Index of" /adminMuestra directorios de administración.
    filetype:xls inurl:"email.xls"Muestra listados de emails expuestos.
    inurl:"login" site:example.comEncuentra páginas de inicio de sesión en un sitio concreto.
    filetype:log inurl:"password.log"Encuentra logs cuyo nombre contiene “password”.
    intitle:index.of id_rsa -id_rsa.pubEncuentra claves privadas SSH expuestas.
    site:.gov intitle:"secret" filetype:pdfEncuentra archivos PDF gubernamentales expuestos.
    intext:"Welcome to phpMyAdmin"Encuentra instalaciones de phpMyAdmin accesibles.
    inurl:/wp-content/uploads/ filetype:pdfBusca PDFs dentro de uploads de WordPress.
    intitle:"Index of" /backupEncuentra directorios de backups accesibles.
    site:example.com ext:sqlBusca bases de datos SQL en ese dominio.
    intitle:"index of" "database.sql"Busca archivos SQL expuestos.
    intitle:"SQL Injection" site:example.comEncuentra páginas del sitio que mencionan SQL Injection.
    site:example.com ext:docBusca documentos Word en ese sitio.
    site:example.com ext:xmlBusca archivos XML.
    site:example.com ext:confBusca archivos de configuración accesibles.
    inurl:"/cgi-bin/pass.txt"Busca archivos “pass.txt” en cgi-bin.
    intitle:"WebcamXP 5"Encuentra cámaras accesibles por WebcamXP 5.
    site:example.com inurl:configBusca archivos/configs dentro del sitio.
    intitle:"index of" intext:config.phpEncuentra directorios con config.php.
    intitle:"index of" intext:.htpasswdMuestra directorios con .htpasswd.
    intitle:"index of" intext:.envBusca directorios con archivos .env.
    intitle:"index of" "wp-content/uploads" site:example.comBusca uploads de WordPress indexados.
    filetype:xls inurl:"email.xls"Encuentra Excel que contienen “email.xls”.
    intext:"Powered by phpBB"Encuentra webs que usan phpBB.
    intext:"Powered by WordPress"Encuentra webs que usan WordPress.
    intext:"@outlook.com" site:example.comBusca correos @outlook.com dentro del sitio.
    inurl:/dana-na/ filetype:cgiBusca CGIs dentro de /dana-na/.
    inurl:server-info "Apache Server Information"Muestra información del servidor Apache.
    intext:"sql syntax near"Muestra webs con errores SQL visibles.
    intext:"confidential" site:example.comPáginas del sitio que contienen “confidencial”.
    inurl:/proc/self/cwdMuestra el directorio actual del servidor (grave exposición).
    intitle:"index of" intext:web.configDirectorios indexados con web.config.
    filetype:reg reg HKEY_CURRENT_USER usernameBusca archivos de registro que contengan “username”.
    inurl:"ViewerFrame?Mode="Encuentra cámaras accesibles por ese visor.
    intext:"powered by vBulletin"Encuentra webs que usan vBulletin.
    intitle:"index of" inurl:ftpFTPs accesibles de forma pública.
    intitle:"index of" "WhatsAppDB.csv"Directorios con bases de datos de WhatsApp expuestas.
    filetype:env intext:APP_ENVBusca archivos .env con info sensible.
    inurl:"/phpinfo.php"Encuentra páginas phpinfo expuestas.
    intitle:"index of" intext:sftp-config.jsonDirectorios con configuraciones SFTP.
    A continuación se muestran algunos ejemplos comunes de Google Dorks; para obtener más ejemplos, consulte la Google Hacking Database:

    Encontrar páginas de inicio de sesión:

    • site:example.com inurl:login
    • site:example.com (inurl:login OR inurl:admin)

    Identificar de archivos expuestos:

    • site:example.com filetype:pdf
    • site:example.com (filetype:xls OR filetype:docx)

    Descubrir archivos de configuración:

    • site:example.com inurl:config.php
    • site:example.com (ext:conf OR ext:cnf)(busca extensiones comúnmente utilizadas para archivos de configuración)

    Localizar copias de seguridad de bases de datos:

    • site:example.com inurl:backup
    • site:example.com filetype:sql

    Automatización: Google Dorking Helper

    Podemos automatizar la generación de Google Dorks con herramientas cómo Google Dorking Helper, que nos permite arrastrar operadores para ir construyendo nuestro dork. Una vez que lo hemos generado podemos darle directamente a «Buscar en Google» para abrirlo en el navegador.

    CASO DE USO: Detectando archivos expuestos en un dominio con Google Dorks

    Imagina que quieres comprobar example.com (o cualquier dominio propio de prácticas) expone algún archivo de configuración, backups o bases de datos de forma accidental.

    1. Entramos en GoogleDorks (la web recopilatoria)

    Hay varias webs que recopilan dorks ya probados, como:

    • Exploit-DB Google Hacking Database (GHDB)
    • googledorks.com
    • publicdorks repos en GitHub

    Las usan solo como referencia, nunca para atacar sistemas reales.

    2. Elegimos un dork útil para auditoría

    Por ejemplo, un clásico para detectar bases de datos expuestas:

    site:example.com ext:sql

    Este dork busca archivos .sql accesibles desde el navegador.

    3. Lo probamos en Google

    En un entorno de práctica (por ejemplo, un dominio controlado por el aula), lo que vemos es algo así:

    • /backup/database.sql
    • /db/export_2023.sql
    • /old/backup.sql

    Si Google muestra entradas similares, quiere decir que los archivos son accesibles públicamente y están indexados. Eso convierte una simple curiosidad en un aviso rojo.

    4. Interpretamos el resultado

    Les explicas a los alumnos:

    • Si Google lo indexa, quiere decir que el servidor lo publica sin restricciones
    • Esto no es hacking activo; es lectura pública de lo que ya está expuesto.
    • Archivos .sql suelen contener tablas, usuarios, hashes de contraseña, etc.

    Aquí entra tu guiño filosófico habitual: el buscador es como un telescopio enorme; si apuntas a una ventana con luz encendida, no estás entrando en la casa, solo ves lo que ellos dejaron abierto.

    5. Propones medidas de mitigación

    Esto les ayuda a cerrar el círculo mental del auditor:

    • Sacar carpetas de backup fuera del public_html o document root.
    • Configurar .htaccess o reglas en el servidor que impidan servir .sql, .env, .conf
    • Quitar directorios listados (“Index of”).
    • Desactivar el autoindex en Apache/Nginx.
    • Aplicar permisos adecuados del sistema.

    6. Otro ejemplo más avanzado desde GoogleDorks.com

    En GoogleDorks encuentran típicamente entradas como:

    intitle:"index of" /backup

    Lo combinan con su dominio de pruebas:

    site:example.com intitle:"index of" /backup

    Resultado (en un entorno controlado):
    Google podría mostrar un listado de backups accesibles.

    Aquí se ve el poder del dork: localizar un error de configuración sin escaneo activo ni intrusiones.

    CASO DE USO: “Ventanas Abiertas en la Red”

    La pantalla parpadea. No estás hackeando nada. Solo observas. Lo que Google muestra es lo que ya estaba ahí, flotando en la superficie como un mensaje en una botella. Elliot lo explica con su serenidad afilada:

    «El buscador es un espejo gigante. Refleja lo que los servidores enseñan sin darse cuenta. Si sabes dónde mirar, puedes encontrar más de lo que cualquier administrador admitiría».

    Elliot abre una pestaña, teclea despacio, casi ritual:

    site:example.com ext:sql

    Darlene levanta una ceja. «¿Ya? ¿Así de simple?»

    Él asiente. «El truco nunca es forzar la cerradura; es descubrir que la puerta estaba abierta desde siempre».

    La búsqueda devuelve un par de enlaces inocentes: /backup/database.sql, /old/export_2022.sql. Como si fuera normal. Como si no contuvieran medio corazón de ese servidor, latido a latido.

    Darlene sonríe, ese tipo de sonrisa que solo aparece cuando ve un fallo que podría haberse evitado con dos minutos de atención. «Archivos SQL, backups… Esto es como dejar el diario íntimo abierto en medio de la calle», murmura.

    Elliot continúa:

    «O mira este, es más evidente»:

    intitle:"index of" /backup

    La pantalla muestra un directorio listado. El índice, los archivos, las fechas. Casi puedes sentir la gravedad del error. Es información pública; Google solo la ha descubierto primero.

    Elliot apoya los codos en la mesa.

    «Esto es Google Dorking. Nada ilegal. Buscamos lo que ya está expuesto. Como revisar los candados de tu propia casa. Y si encuentras una ventana rota, la arreglas antes de que otro la vea».

    Darlene mira al techo. «La gente piensa que la seguridad es un bunker. Pero casi siempre es una persiana mal echada».

    Los dos siguen navegando entre dorks como quien pasea entre sombras familiares. No hay urgencia, solo una especie de calma lúcida: la fase previa a cualquier intrusión ética, el territorio gris donde la información pública se mezcla con la negligencia.

    Elliot concluye, casi en un susurro:
    «El buscador es el confidente más indiscreto de internet. Si le preguntas bien, te lo cuenta todo».

    Buscadores alternativos y meta-buscadores

    Cuando Google te cierra puertas, otros motores silenciosos dejan ventanas abiertas. No son magia negra; simplemente indexan distinto.

    DuckDuckGo
    – Respeta privacidad y deja ver cosas que Google a veces filtra.

    Shodan
    – El “Google del IoT”: cámaras, routers, PLCs, servidores expuestos.
    – Ideal para investigación forense o ética.

    Censys
    – Similar a Shodan pero con enfoque más académico.
    – Perfecto para investigaciones de superficie de ataque.

    Bing + Yandex
    – Indexan directorios de manera más permisiva en algunos casos.


    Herramientas que automatizan Google Dorks (con cabeza)

    No siempre quieres escribir cien consultas a mano. Estas herramientas generan, prueban y organizan dorks.

    GHDB – Google Hacking Database (Exploit-DB)
    – La biblia. Miles de dorks clasificados por categorías (login pages, archivos sensibles, cámaras…).
    – La referencia imprescindible.

    DorkSearch / DorkTester
    – Pequeñas herramientas web para probar dorks rápidamente.
    – Útiles para investigaciones rápidas sin automatizar demasiado.

    Dork-Scanner (Python)
    – Frameworks que lanzan series de dorks y analizan respuestas.
    – Exigen ética e IP propia porque Google puede bloquearte.

    Katana + Nuclei (ProjectDiscovery)
    – No son dorks, pero se llevan muy bien con ellos.
    – Puedes sacar URLs con Katana y luego comprobar hallazgos con Nuclei.


    Extensiones de navegador

    No subestimes las pequeñas utilidades de un clic.

    Google Search Operators Helper
    – Te rellena operadores avanzados.

    Search Diggity (BishopFox)
    – Conjunto de herramientas de OSINT con módulos de dorking seguro.
    – Muy usado en auditorías.


    Herramientas OSINT que complementan Google Dorks

    Porque un dork es solo un portal: después debes investigar.

    theHarvester
    – Extrae correos, dominios, hosts desde motores de búsqueda.
    – Combinación perfecta con filetype:xls, pdf, txt…

    FOCA
    – Analiza metadatos de documentos encontrados con dorks.
    – Joyas ocultas en PDFs y Word.

    SpiderFoot
    – Rastrea información relacionada con dominios, subdominios y filtraciones.

    Amass
    – Recon de subdominios.
    – Combinado con site: y inurl: puedes descubrir puertas laterales.


    Herramientas forenses relacionadas

    Cuando los dorks son parte de una investigación forense, estos compañeros hacen el resto:

    Wayback Machine (Archive.org)
    – Para ver versiones antiguas de páginas descubiertas con dorks.
    – Oro puro cuando el contenido ha sido borrado.

    Exiftool
    – Para explorar metadatos de imágenes encontradas.

    Binwalk
    – Si encuentras firmware expuesto con un dork (sí, pasa), esta herramienta lo destripa.


    Pequeño “arsenal” recomendado según objetivo

    Localizar archivos sensibles: Google + GHDB + FOCA
    Enumerar infraestructura: Google + Shodan + Amass
    Investigación forense: Google + Wayback + Exiftool
    Bug bounty: GHDB + Dork-scanner + Nuclei