Subdominios

La herramienta combina dos métodos para maximizar la cobertura de subdominios: • Certificate Transparency (CT) — Los registros de Certificate Transparency son logs públicos donde las Autoridades Certificadoras (CAs) deben publicar cada certificado SSL/TLS que emiten. Esto incluye todos los dominios y subdominios cubiertos por el certificado (Common Name y Subject Alternative Names). La herramienta consulta crt.sh, el motor de búsqueda de CT más completo, que indexa miles de millones de certificados. Esta técnica descubre subdominios que tienen o han tenido certificados SSL, incluyendo subdominios internos que fueron incluidos accidentalmente en certificados. • Fuerza bruta DNS — Se prueba una lista de más de 70 nombres de subdominios comunes (www, mail, api, admin, dev, staging, cdn, etc.) concatenados con el dominio objetivo. Para cada uno se intenta una resolución DNS A record. Solo los subdominios que resuelven a una IP se incluyen en los resultados. Esta técnica descubre subdominios que no tienen certificado SSL pero sí tienen registros DNS activos. • Verificación DNS — Todos los subdominios encontrados por cualquier método se verifican con resolución DNS real (A record) para confirmar que están activos en el momento del escaneo. Subdominios que aparecen en certificados antiguos pero ya no tienen DNS activo se excluyen automáticamente.

Certificate Transparency (CT) es un framework definido en RFC 6962 que requiere que las CAs registren públicamente todos los certificados emitidos: • Propósito original — CT fue creado por Google en 2013 para detectar certificados emitidos fraudulentamente o por error. Antes de CT, una CA podía emitir un certificado para google.com sin que Google lo supiera. • Logs públicos — Existen docenas de logs CT operados por Google, Cloudflare, DigiCert, Sectigo y otros. Cada certificado se publica en al menos dos logs independientes antes de ser considerado válido. • crt.sh — Mantenido por Sectigo (antes Comodo), crt.sh indexa todos los logs CT y proporciona una API JSON gratuita. Es la fuente más completa de datos CT disponible públicamente. • Para reconocimiento — Los certificados CT revelan subdominios que el propietario del dominio puede no haber querido hacer públicos: entornos de staging, paneles administrativos, APIs internas, servicios de desarrollo, y más. Un certificado wildcard (*.example.com) no revela subdominios específicos, pero muchas organizaciones emiten certificados para subdominios individuales. • Datos históricos — crt.sh incluye certificados expirados y revocados, lo que puede revelar subdominios que existieron en el pasado. Esta herramienta filtra solo los que tienen DNS activo actualmente.

Los resultados se presentan con varios indicadores: • Fuente CT — El subdominio fue encontrado en registros de Certificate Transparency. Significa que alguien emitió un certificado SSL para ese subdominio en algún momento. • Fuente DNS — El subdominio fue encontrado por resolución DNS directa de nombres comunes. No necesariamente tiene certificado SSL pero sí tiene registros DNS activos. • Agrupación por IP — Los subdominios que comparten la misma dirección IP probablemente están alojados en el mismo servidor. Esto es útil para identificar la infraestructura: muchos subdominios en una IP sugieren un servidor web con virtual hosts, mientras que IPs únicas por subdominio sugieren servicios separados o CDN. • IPs únicas — El número total de direcciones IP distintas entre todos los subdominios. Un número bajo relativo al total de subdominios indica hosting compartido; un número alto sugiere infraestructura distribuida. • Exportación — Los resultados se pueden copiar al portapapeles o descargar como CSV para procesamiento posterior en hojas de cálculo, herramientas SIEM, o como input para otros escaneos de seguridad.

La enumeración de subdominios es una de las primeras fases de cualquier evaluación de seguridad: • Superficie de ataque — Cada subdominio es un punto de entrada potencial. Subdominios olvidados o no mantenidos frecuentemente ejecutan software desactualizado con vulnerabilidades conocidas. • Shadow IT — Subdominios creados por equipos sin coordinación con el equipo de seguridad: servidores de pruebas, APIs de desarrollo, dashboards internos accesibles públicamente. • Takeover de subdominios — Subdominios que apuntan a servicios de terceros (Heroku, GitHub Pages, AWS S3) que ya no están configurados son vulnerables a subdomain takeover. Un atacante puede reclamar el servicio huérfano y controlar el contenido del subdominio. • Enumeración de infraestructura — Los patrones de nombres y la distribución de IPs revelan la arquitectura: servidores en AWS vs datacenter propio, uso de CDN (Cloudflare, Fastly), servicios de email (Google Workspace, Microsoft 365), etc. • Pivoteo — Los subdominios internos descubiertos (staging, dev, admin) pueden tener controles de acceso más débiles que los sistemas de producción, convirtiéndose en vectores de entrada lateral.