Reconocimiento pasivo:
cómo los atacantes te investigan antes de tocarte
Serie Red Team | unfantasmaenelsistema.com
Antes de que un atacante envíe el primer paquete a tus sistemas, antes de que intente explotar la primera vulnerabilidad, antes de que comience el ataque en sí, hay una fase que puede durar días, semanas o incluso meses: el reconocimiento. Es la fase más silenciosa, la más subestimada y, en muchos casos, la que determina el éxito de todo lo que viene después.
El reconocimiento pasivo es el arte de recopilar la máxima información posible sobre un objetivo sin interactuar directamente con sus sistemas. Solo fuentes públicas: buscadores, registros DNS, bases de datos de certificados, repositorios de código, redes sociales. El objetivo no recibe ningún paquete. No hay forma de que lo detecte.
Este artículo cubre las técnicas y herramientas más usadas en reconocimiento pasivo, con comandos listos para usar y el flujo completo que sigue un auditor profesional desde el dominio inicial hasta tener un mapa completo de la superficie de ataque.
Qué aprenderás en este artículo
Qué información busca un atacante antes de lanzar nada · Google Dorks y Shodan: los dos buscadores que exponen lo que nunca debería ser público · theHarvester, DNS y Certificate Transparency para mapear infraestructura y personas · Cómo GitHub se convierte en la fuente de secretos más valiosa del reconocimiento · El flujo completo que sigue un auditor profesional, fase a fase
1. El reconocimiento en el ciclo del ataque
El reconocimiento no es un paso opcional que los atacantes descuidados se saltan. Es la base de todo. Un atacante que conoce perfectamente la infraestructura de su objetivo, sus empleados, sus tecnologías y sus puntos débiles necesita muchos menos intentos para tener éxito y genera mucho menos ruido en el proceso.
2. Qué información busca un atacante
El reconocimiento no es una búsqueda aleatoria de información: es una recopilación sistemática de datos específicos que servirán para diseñar el ataque. Cada categoría de información tiene un uso concreto.
| Categoría | Qué revela | Para qué la usa el atacante |
|---|---|---|
| Identidad corporativa | Razón social, marcas, filiales, adquisiciones recientes | Delimitar el alcance real del objetivo y sus activos menos vigilados |
| Infraestructura técnica | IPs, rangos de red, subdominios, proveedores cloud | Construir el mapa de superficie de ataque técnica |
| Personas y roles | Empleados, cargos, formato de email corporativo | Diseñar phishing dirigido y probar credenciales filtradas |
| Huella digital y leaks | Credenciales filtradas, claves en repositorios, documentos indexados | Saltarse la explotación técnica accediendo directamente |
| Pila tecnológica | CMS, frameworks, versiones de software expuestas | Buscar CVEs conocidas para esa versión concreta |
El hallazgo más valioso suele ser la combinación de credenciales filtradas con el formato de email corporativo. Si theHarvester encuentra que la empresa usa el formato nombre.apellido@empresa.com y HaveIBeenPwned confirma que ese dominio aparece en filtraciones, el atacante puede probar directamente si esas credenciales siguen activas en la VPN o en el correo corporativo. Sin explotar ninguna vulnerabilidad técnica.
3. Google Dorks: el buscador como herramienta de auditoría
Google indexa literalmente todo lo que puede encontrar en internet, incluyendo archivos que nunca deberían haber sido públicos. Los Google Dorks son consultas avanzadas que combinan operadores especiales para filtrar exactamente el tipo de exposición que buscas.
site:empresa.com filetype:pdf site:empresa.com inurl:admin OR inurl:login OR inurl:panel site:empresa.com ext:sql OR ext:bak OR ext:log site:empresa.com intext:"Index of /" site:empresa.com ext:env OR ext:cfg OR ext:conf site:empresa.com inurl:wp-config.php site:empresa.com inurl:.git site:empresa.com filetype:txt intext:"password" site:empresa.com filetype:log intext:"password" site:empresa.com filetype:xlsx intext:"contraseña" site:*.empresa.com site:empresa.com intext:"Powered by" OR intext:"Built with" site:empresa.com filetype:pdf OR filetype:docx OR filetype:xlsx site:github.com "empresa.com" password OR secret OR api_key site:github.com "empresa.com" filename:.env
La Google Hacking Database (GHDB) en exploit-db.com contiene miles de dorks categorizados por tipo de exposición: archivos con contraseñas, paneles de administración, cámaras IP, sistemas industriales, archivos de configuración. Es el punto de partida para cualquier auditor que quiera saber qué tiene una empresa expuesto en Google.
4. Shodan: el buscador de dispositivos expuestos
Si Google indexa el contenido de las páginas web, Shodan indexa los servicios que escuchan en puertos de internet: servidores web, bases de datos, paneles de administración, cámaras IP, sistemas de control industrial, routers, impresoras. Cualquier cosa con una IP pública y un puerto abierto.
org:"Empresa SA" hostname:empresa.com net:93.184.216.0/24 hostname:empresa.com port:3389 hostname:empresa.com port:22 hostname:empresa.com product:"Apache httpd" version:"2.4.49" hostname:empresa.com http.title:"phpMyAdmin" hostname:empresa.com http.title:"Kibana" hostname:empresa.com http.title:"Grafana" shodan host 93.184.216.34 shodan search hostname:empresa.com shodan search --fields ip_str,port,org hostname:empresa.com > resultados.csv shodan host 8.8.8.8
El hallazgo más frecuente y más impactante en Shodan es el de paneles de administración accesibles directamente desde internet: Kibana sin autenticación, Grafana con credenciales por defecto, phpMyAdmin expuesto, Elasticsearch sin contraseña. En muchos casos, el acceso no requiere ningún exploit: simplemente están ahí, abiertos, esperando.
5. theHarvester: emails, subdominios y más
theHarvester automatiza la búsqueda de emails y subdominios en múltiples fuentes simultáneamente. Es la primera herramienta que ejecuta la mayoría de pentesters al comenzar una auditoría: en minutos puede proporcionar una lista de empleados, sus emails corporativos y todos los subdominios públicos del dominio objetivo.
theHarvester -d empresa.com -b google theHarvester -d empresa.com -b google,bing,linkedin theHarvester -d empresa.com -b all theHarvester -d empresa.com -b google -l 200 theHarvester -d empresa.com -b all -f resultados_empresa theHarvester -d empresa.com -b google -n
Los subdominios más interesantes desde el punto de vista de la auditoría no son los obvios (www, mail, ftp). Son los que sugieren entornos no productivos: dev.empresa.com, staging.empresa.com, test.empresa.com. Estos entornos suelen tener las mismas vulnerabilidades que producción pero con menos monitorización y controles de acceso más laxos.
6. Reconocimiento DNS
El DNS es uno de los protocolos más ricos en información de toda la infraestructura de internet. Los registros MX revelan el proveedor de email. Los registros TXT revelan si hay protección contra spoofing. Los nameservers revelan el proveedor DNS. Y una transferencia de zona mal configurada puede revelar toda la infraestructura de una vez.
nslookup empresa.com dig empresa.com A dig empresa.com MX dig empresa.com TXT dig empresa.com NS dig axfr @ns1.empresa.com empresa.com amass enum -d empresa.com amass enum -active -d empresa.com subfinder -d empresa.com subfinder -d empresa.com -o subdominios.txt dnsrecon -d empresa.com dnsrecon -d empresa.com -t brt -D /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
7. Certificados TLS: la mina de oro de subdominios
Cada certificado TLS emitido queda registrado en el Certificate Transparency Log, un registro público y auditable. Lo que esto significa para el reconocimiento es que puedes ver todos los subdominios para los que una empresa ha emitido certificados, incluyendo subdominios históricos que ya no existen y subdominios internos que se expusieron accidentalmente.
7.1 WHOIS y rangos de IP
whois empresa.com whois 93.184.216.34 whois -h whois.radb.net -- '-i origin AS12345'
8. GitHub: donde los desarrolladores dejan las llaves puestas
GitHub es probablemente la fuente de información más valiosa y más subestimada en el reconocimiento de organizaciones. Los desarrolladores cometen errores: suben claves de API, contraseñas de bases de datos, tokens de acceso a servicios cloud. Y aunque los borren después, los commits de Git son permanentes: el historial completo está siempre disponible.
trufflehog git https://github.com/empresa/repositorio trufflehog git https://github.com/empresa/repositorio --since-commit HEAD~100 gitleaks detect --source /ruta/al/repo/clonado
El hallazgo más crítico posible en GitHub es una clave de AWS (AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY) activa. Con esas dos cadenas de texto, un atacante puede acceder a toda la infraestructura cloud de la empresa: servidores, bases de datos, buckets S3 con datos de clientes, funciones Lambda, todo. Ha ocurrido en empresas de todos los tamaños.
9. Maltego: visualizar las relaciones
email@empresa.com
|
v
Perfil de LinkedIn ----> "Administrador de sistemas"
|
v
Cuenta de GitHub personal
|
v
Repositorio con historial de commits
|
v
AWS_ACCESS_KEY_ID encontrada en un commit antiguo
|
v
Acceso a la infraestructura cloud completaEl valor de Maltego no está en recopilar información nueva, sino en mostrar las conexiones entre la información que ya tienes. Un email encontrado por theHarvester puede conectar con un perfil de LinkedIn que revela que esa persona es el administrador de sistemas. Ese administrador tiene un GitHub con repositorios de la empresa. Uno de esos repositorios tiene en su historial una clave de AWS. De un email a acceso cloud, todo visible en el grafo.
10. Frameworks de reconocimiento: recon-ng y SpiderFoot
recon-ng workspaces create empresa_objetivo marketplace install all db insert domains modules load recon/domains-hosts/certificate_transparency run modules load recon/domains-contacts/whois_pocs run show hosts show contacts show credentials modules load reporting/html options set FILENAME /tmp/recon_empresa.html run spiderfoot -l 127.0.0.1:5001
11. El flujo completo de reconocimiento pasivo
Con todas las herramientas individuales cubiertas, aquí está el flujo que sigue un auditor profesional para construir un perfil completo del objetivo.
| Fase | Herramientas | Qué obtienes |
|---|---|---|
| 1. Búsqueda inicial | Google Dorks, GHDB | Archivos expuestos, paneles, primera exposición pública |
| 2. Infraestructura | Shodan, DNS, WHOIS | IPs, rangos de red, servicios expuestos, proveedores |
| 3. Superficie de dominio | amass, subfinder, Certificate Transparency | Mapa completo de subdominios, incluidos entornos dev/staging |
| 4. Personas | theHarvester, LinkedIn | Empleados, formato de email, organigrama aproximado |
| 5. Código expuesto | GitHub, trufflehog, gitleaks | Secretos filtrados, claves de API, tecnologías internas |
| 6. Consolidación | Maltego, recon-ng, SpiderFoot | Mapa relacional completo listo para diseñar el ataque |
12. Cómo defenderse: reducir la superficie de exposición
La mejor defensa contra el reconocimiento pasivo es realizar ese mismo reconocimiento sobre ti mismo periódicamente. Saber qué información tienes expuesta es el primer paso para reducirla.
Checklist de reconocimiento defensivo (OSINT sobre tu propia empresa)
Ejecuta theHarvester y Google Dorks contra tu propio dominio cada trimestre · Activa alertas de Certificate Transparency para tu dominio (crt.sh tiene notificaciones) · Habilita GitHub secret scanning y push protection en todos los repositorios de la organización · Audita subdominios activos con amass o subfinder y da de baja los que ya no se usan · Forma a los empleados sobre qué información corporativa no debería aparecer en perfiles públicos
Conclusión
El reconocimiento pasivo demuestra algo que muchos profesionales de seguridad no quieren escuchar: la cantidad de información que una organización expone públicamente es siempre mayor de lo que cree. Subdominios olvidados, repositorios con secretos en el historial de commits, empleados con información detallada en LinkedIn, software con versiones visibles en banners. Cada pieza de información es un dato que el atacante usa para diseñar un ataque más preciso y menos ruidoso.
El ejercicio más valioso que un equipo de seguridad puede hacer es ejecutar exactamente las técnicas de este artículo contra su propia organización. Lo que encuentres es lo que encontrará un atacante antes de que empiece el ataque de verdad. Mejor encontrarlo tú primero.