Introducción
Este laboratorio consistió en aplicar técnicas de reconocimiento y footprinting —pasivas y activas— sobre un dominio real: att.com (AT&T, la operadora de telecomunicaciones estadounidense). El objetivo no era explotar nada, sino reconstruir cuánta información queda expuesta sobre una organización usando exclusivamente fuentes públicas y herramientas de reconocimiento, y razonar qué de todo eso sería aprovechable por un atacante real.
Uso 15 herramientas y fuentes distintas, divididas en dos bloques: pasivas (no generan tráfico directo hacia la infraestructura del objetivo, solo consultan fuentes de terceros) y activas (sí interactúan directamente con los sistemas del objetivo). Por transparencia y privacidad, en este post generalizo algunos hallazgos concretos —direcciones de correo de empleados, IPs de servicios puntuales— y me centro en la metodología y en qué tipo de información revela cada herramienta.
Reconocimiento pasivo
Whois
Lo primero, información de registro del dominio: registrador (CSC Corporate Domains), fecha de creación (24/04/1986 — el dominio lleva casi 40 años activo), fecha de expiración, datos de contacto corporativos y los servidores DNS (todos con infraestructura Akamai). Los estados del dominio (clientTransferProhibited, serverDeleteProhibited, etc.) indican que está protegido contra transferencias o cambios no autorizados — un detalle pequeño pero que ya dice algo sobre la madurez de la gestión del dominio.
crt.sh
Buscar en los logs de Certificate Transparency es una de las formas más eficientes de mapear subdominios, porque cualquier certificado TLS emitido queda registrado públicamente. Entre los resultados aparecen patrones muy reconocibles:
- Subdominios con
test,stage,uat,deven el nombre — entornos de pruebas, normalmente con menos controles de seguridad que producción. - Wildcards como
*.stage.att.como*.test.att.com— un certificado wildcard comprometido expondría de golpe todos los subdominios que cuelgan de él. - Subdominios de producción (
prod,nprd) mezclados con los anteriores, lo que ayuda a inferir la convención de nombres interna.
Google Dorks
Con operadores de búsqueda avanzada (site:att.com filetype:pdf, filetype:xls, intext:"confidential") aparecen documentos corporativos indexados por Google sin que nadie los haya filtrado — todos publicados intencionadamente por la propia compañía, pero no necesariamente pensados para ser fáciles de encontrar:
- Documentos técnicos (plan de pruebas de red, plan de migración TDM→IP).
- Una hoja de cálculo pública con el listado de módulos de comunicación aprobados por AT&T (fabricante, modelo, tecnología, bandas de frecuencia) — con el fabricante y modelo exactos, el siguiente paso natural sería buscar CVEs conocidos para ese hardware.
- El informe de transparencia de AT&T, publicado por la propia compañía, que detalla su cooperación con solicitudes gubernamentales.
La lección aquí no es que haya nada filtrado — es que “público” y “fácil de encontrar” son cosas distintas, y los dorks cierran esa distancia.
theHarvester, Amass (passive) y Sublist3r
Estas tres se solapan en propósito: recolectar correos, hosts y subdominios de fuentes pasivas (motores de búsqueda, certificados, registros DNS). Sublist3r por sí solo devolvió 2.829 subdominios — a esa escala, la mayoría son ruido o falsos positivos, así que hay que cruzar los resultados con otras fuentes antes de darlos por buenos. Amass, además, permitió reconstruir relaciones: qué subdominios resuelven a IPs de AT&T, cuáles a AWS, y la lista de ASN (números de sistema autónomo) asociados a la organización.
Shodan
Shodan indexa servicios expuestos directamente a internet. Sin apuntar a IPs ni paneles concretos: se detectaron paneles de login potencialmente vulnerables, formularios de registro expuestos, al menos un host con el puerto 3389 (RDP) accesible desde fuera, y servidores IIS que podrían tener versiones desactualizadas. Cualquiera de estos sería un punto de partida razonable para una fase de explotación — que es exactamente el motivo por el que no se debería confiar en “nadie va a encontrar esto”.
Wappalyzer
Aquí no hay nada sensible, solo huella tecnológica: React y Next.js en el frontend, Nginx como proxy reverso, Akamai como CDN y bot manager, HSTS y reCAPTCHA como medidas de seguridad, y una lista larga de herramientas de analítica y marketing (Google Analytics, Adobe Target, Dynatrace…). Conocer el stack ayuda a priorizar qué CVEs buscar primero.
Maltego (pasivo), Dmitry y Leakix
Maltego, en modo pasivo y con la versión gratuita (sin APIs de pago), permitió visualizar relaciones entre dominios, subdominios, correos y documentos como un grafo — la propia limitación de la versión community es un dato en sí: con acceso a fuentes de pago se habría descubierto bastante más. Dmitry aportó más subdominios y decenas de direcciones de correo de empleados — no las reproduzco aquí por privacidad, pero el volumen en sí ya es representativo de cuánta superficie humana (phishing, ingeniería social) queda expuesta sin que la organización pueda hacer mucho al respecto. Leakix, en este caso, no aportó nada claramente vinculado al objetivo.
Reconocimiento activo
A partir de aquí las herramientas ya interactúan directamente con la infraestructura del objetivo, en vez de limitarse a consultar fuentes de terceros.
Amass (active)
En modo activo, Amass generó consultas DNS directas y reveló más relaciones: registros MX apuntando a Proofpoint (gestión de correo), servidores de nombres Akamai, y subdominios repartidos entre Azure (CloudApp, Front Door), AWS y Oracle Cloud — una infraestructura multi-nube nada trivial de vigilar por completo.
Nmap
Escaneo dirigido al dominio principal:
nmap -Pn -T3 --top-ports=10 -sS -sV -sC -f -vvv att.com| Puerto | Estado | Servicio |
|---|---|---|
| 21 | filtrado | FTP |
| 22 | filtrado | SSH |
| 23 | filtrado | Telnet |
| 25 | filtrado | SMTP |
| 80 | abierto | HTTP (redirige a HTTPS) |
| 110 | filtrado | POP3 |
| 139 | filtrado | NetBIOS-SSN |
| 443 | abierto | HTTPS (certificado válido, DigiCert) |
| 445 | filtrado | Microsoft-DS |
| 3389 | filtrado | RDP |
Este resultado es, de hecho, un buen ejemplo de perímetro bien gestionado: de los diez puertos más comunes, solo 80 y 443 responden abiertamente — todo lo demás (SSH, RDP, SMB, FTP…) está filtrado en el perímetro principal. El contraste con lo encontrado en Shodan sobre otros hosts del mismo dominio muestra algo importante: la seguridad de una organización grande no es uniforme, varía host a host.
Maltego (active), WhatWeb y Photon
Maltego en modo activo consulta directamente al servidor en vez de solo agregarlo desde fuentes pasivas. WhatWeb hizo fingerprinting HTTP explícito: http://att.com responde 301 vía un balanceador BigIP, mientras que https://www.att.com responde 403 Forbidden detrás de Akamai — dos capas de infraestructura distintas para lo que parece la misma web. Photon, por su parte, rastreó la web como un crawler (sin hacer scraping de contenido) y encontró 75 URLs en robots.txt, 80 URLs internas enlazadas, y 4 URLs candidatas a pruebas de fuzzing.
Análisis de riesgo
De todo el reconocimiento, estos son los puntos que más pesan de cara a un atacante real:
- Superficie de ataque amplia (alto): con miles de subdominios expuestos, cada uno es un punto de entrada potencial — y no todos van a estar igual de actualizados.
- Subdominios inactivos (crítico): un subdominio que no devuelve contenido pero sigue teniendo un registro DNS es candidato a secuestro de dominio (subdomain takeover) si el recurso al que apuntaba (un bucket S3, una app de Azure…) ya no existe pero el DNS no se limpió.
- Exposición de entornos de desarrollo o pruebas (alto): los subdominios
test/stage/uatsuelen tener menos controles de seguridad que producción, pero a veces manejan datos igual de sensibles. - Diversidad de infraestructura (medio): depender de tantos proveedores externos (Akamai, AWS, Azure, Oracle) multiplica la superficie de monitorización y añade puntos débiles fuera del control directo de la organización.
Reflexión
Algunas conclusiones del propio proceso, más allá de los hallazgos concretos:
¿Qué fuentes resultaron más útiles? Amass y Maltego, con diferencia — incluso usando solo la versión community de Maltego (sin APIs de pago). Con acceso a fuentes comerciales se habría descubierto bastante más.
¿Qué técnicas fueron más eficientes en reconocimiento pasivo? La enumeración pasiva de Amass, consultar fuentes públicas directamente, y sobre todo cruzar los resultados de varias herramientas entre sí para descartar falsos positivos — con 2.829 subdominios de Sublist3r de entrada, sin verificación cruzada esos datos no sirven de mucho.
¿Patrones comunes entre los servicios detectados? Sí: una estructura de nombres de subdominio consistente, sufijos reutilizados entre entornos, y una dependencia constante de servicios externos (CDN, proveedores cloud, plataformas de correo).
¿Qué se podría aprovechar en un ataque dirigido? Subdominios inactivos o mal configurados (secuestro de dominio), la estructura organizativa inferida de los propios nombres (útil para phishing dirigido o ingeniería social), servicios internos mal protegidos, y los nombres de proyecto repetidos entre distintos entornos — que en la práctica funcionan como pistas de qué buscar a continuación.
Conclusión
Lo que más se queda de este laboratorio no es ninguna herramienta en concreto, sino la idea de que el reconocimiento pasivo por sí solo —sin tocar un solo sistema del objetivo— ya construye un mapa bastante completo de la superficie de ataque de una organización grande. Cruzar fuentes y desconfiar de los datos en bruto (los 2.829 subdominios de Sublist3r son el ejemplo perfecto) es tan importante como saber qué herramienta usar.