Cómo ver los subdominios ocultos de cualquier web sin instalar nada

Hoy en día la gran mayoría de dominios y subdominios hacen uso de certificados TLS, ya sea proporcionados por el popular Let’s Encrypt que es totalmente gratuito, o bien por otras CA, pero en todos los casos se proporcionan los registros CT a los populares navegadores de Chrome y Apple a medida que se van registrando.

Cómo detecta crt.name todos los subdominios

La herramienta que os damos a conocer hoy es crt.name, una herramienta totalmente gratuita que nos permitirá ver el índice completo de subdominios que han obtenido un certificado TLS. Esta herramienta lee todos los registros CT utilizables de los navegadores de Chrome y Apple, tanto los CT estáticos (como los de Let’s Encrypt), como también los antiguos RFC 6962 (Google, Sectigo o DigiCert). De esta forma, analizará cada certificado en memoria, y extraerá los nombres de host SAN (Subject Alternative Name) que contienen los subdominios, y descartará el resto de metadatos.

Un aspecto muy importante, es que solamente estarán las entradas nuevas, los subdominios más antiguos podrían no estar disponibles porque provienen de registros CT obsoletos, para poder verlos deberás usar Internet Archive, Common Crawl, archivos de zona ICANN CZDS y otras fuentes. El índice de subdominios que nos proporciona esta herramienta nos proporcionará el listado completo de subdominios encontrados, e incluso podemos ver la fecha en la cual estuvo disponible por primera vez en su propio índice, no la fecha de la emisión del certificado, para dominios muy antiguos, los resultados pueden ser incompletos. Su funcionamiento interno y el parámetro «&dates=1» no forman parte del estándar CT definido en las RFC 6962 y RFC 9162.

Los estándares RFC 6962 y 9162 definen cómo funcionan los logs CT, pero no definen ningún parámetro de búsqueda que sí es capaz de realizar esta herramienta. El estándar último es el RFC 9162 que podríamos llamarlo «CT versión 2», mientras que el anterior se considera obsoleto pero sigue siendo usado por Chrome. Todos los registros CT definidos en estas RFC son de bajo nivel: reciben los certificados, los almacenan y permiten su consulta.

Funcionamiento

Lo primero que debemos hacer es meternos en la web de crt.name, ponemos el dominio principal que queremos buscar, por ejemplo, «redeszone.net», y pinchamos en «Search». En pocos segundos nos proporcionará todos los subdominios encontrados:

De manera predeterminada, el enlace que veremos en la barra de navegación será similar a «https://crt.name/v1/search?apex=redeszone.net«, podemos ver todos los subdominios, sin embargo, no vamos a poder ver la fecha asociada. Para hacer esto, basta con añadir «&dates=1» a la URL anterior, se quedaría de la siguiente forma:

• https://crt.name/v1/search?apex=redeszone.net&dates=1

Así podemos ver también las fechas:

Un aspecto importante, es que estas fechas solamente aparecerán de los nuevos registros CT que tenemos disponibles y cuando fue indexado por primera vez en su base de datos, no es la fecha de creación del subdominio o la emisión del primer certificado. Por ejemplo, el dominio de redeszone.net realmente lleva existiendo desde 2010, además, el subdominio www.redeszone.net existe desde los inicios, por lo que la fecha no es la correcta. Deberás tomar esta información con precaución, porque no podría ser del todo fiable. Para una investigación más exhaustiva, se deben contrastar estos datos con otras fuentes disponibles.

Guía práctica: Interpretación y siguientes pasos tras la enumeración

Después de enumerar los subdominios de un determinado dominio, comienzan otros pasos claves como verificar cuáles pueden ser de pruebas, verificar el estado de los mismos, si exponen servicios internos.

Clasificación de los subdominios

Esta sería la primera fase, debemos identificar patrones de nombres que sugieran que hay entornos de desarrollo como «dev, staging y test», también podemos identificar subdominios de administración como «admin, panel, cpanel», e incluso podemos descubrir servicios internos como «vpn, intranet o mail» entre otros muchos. Al agrupar y clasificar todos los subdominios por tipo, podemos posteriormente ver los registros DNS asociados (A, AAAA, MX, TXT y CNAME) para seguir extrayendo información sobre la empresa en cuestión.

Es muy importante diferenciar entre los subdominios que vienen de los registros CT, de otros que pueden provenir de fuentes históricas, los cuales podrían no estar disponibles hoy en día. Además, deberías prestar mucha atención a los subdominios «críticos» como «vpn, intranet» o similares, ya que podrían ser la puerta hacia la red interna de la organización.

Verificación de estado

Es muy importante verificar en qué estado se encuentran esos subdominios, es posible que hayan dejado ya de existir, para ello es recomendable realizar una resolución de DNS (registros A, AAAA y CNAME), esto lo podemos hacer con herramientas como «dig» o «nslookup», también podrías usar herramientas online relacionadas con ver los registros DNS y verificar si los subdominios resuelven una determinada dirección IP. Posteriormente, haciendo un «curl» podríamos revelar el servidor web y el código de estado que nos proporciona.

Podemos usar herramientas avanzadas como nmap para realizar un escaneo de puertos comunes como 80/443 para web, 22 SSH, 25 SMTP, 53 DNS, 3389 RDP, 445 SMB entre otros, y confirmar qué servicios están realmente escuchando. Es recomendable hacer un escaneo con pocos puertos para evitar que nos detecten, luego podríamos ampliarlos a otros puertos diferentes.

Detectar señales de exposición de servicios internos

Si eres el pentester de la empresa, después de hacer esto deberías considerar peligrosos los subdominios públicos que apuntan a direcciones de red internas o privadas, o que exponen servicios muy usados en redes corporativas como mDNS e incluso servidores DNS en local, los cuales solamente están disponibles para uso interno.

Otro aspecto importante a valorar es el «Subdomain Takeover«, si un CNAME del subdominio apunta a un servicio en la nube (AWS, Azure, GitHub Pages, Cloudflare) que ya ha sido eliminado, pero el registro sigue activo. En estos casos, un atacante podría registrar ese mismo recurso en la nube y tomar el control del subdominio. Esto es extremadamente peligroso porque podría usarlo para campañas de phishing, robo de cookies de sesión o suplantación de identidad, dañando gravemente la reputación de la empresa legítima.

Legalidad y ética

La enumeración de dominios forma parte del pentesting a una empresa, es posible que haya subdominios que siguen funcionando, y nos darán acceso a la intranet de la empresa si no están protegidos. Toda esta información es pública, tomada desde los registros de Certificate Transparency, no supone ningún tipo de vulneración ni pruebas de pentesting, eso viene después, una vez que ya conocemos los dominios.

Este tipo de descubrimientos son la fase inicial y pasiva de una auditoría de seguridad o pentesting autorizado, y el objetivo es mapear la superficie de exposición. Si se encuentran dominios como «admin.empresa.com» o «vpn.empresa.com» es posible que no sean accesibles públicamente, y se necesite usar una VPN o similar para acceder, en el caso de que sí sean accesibles públicamente estaremos ante un hallazgo importante y de alto riesgo para la ciberseguridad de la empresa, porque podrían ser la puerta de entrada a la red interna. Cualquier prueba activa contra esos subdominios sin autorización podría ser ilegal, así que no deberías hacerlo a no ser que tengas permiso explícito de la empresa.

Cómo ocultar tus subdominios con certificados Wildcard

Nosotros tenemos un dominio personal con muchos subdominios, haciendo uso de Cloudflare Tunnels para entrar a diferentes servicios de la red local de forma segura. Todos estos dominios no aparecen en estos registros CT debido a que tenemos un certificado TLS de tipo Wildcard, es decir, un certificado TLS para el dominio completo, de esta forma, no está cada subdominio uno por uno con un certificado TLS distinto. De esta forma, no aparecemos en ningún listado y tendremos mayor privacidad. Si no quieres que tus subdominios se puedan ver en estos registros, nuestra recomendación es que uses certificados Wildcard.

Si tienes un dominio, podrías obtener un certificado Wildcard con Let’s Encrypt de forma sencilla, pero tendrás que hacer uso del desafío «DNS-01 challenge» con Certbot. Este desafío consiste en probar que nosotros controlamos los DNS del nombre de dominio que vamos a registrar, tendremos que poner un valor específico en el registro TXT del dominio. Si vas a usar este desafío, es importante que tu proveedor del dominio tenga una API para automatizar poner un TXT y así renovar en un futuro el certificado TLS emitido. Los dos motivos para usar este tipo de desafío son que podemos obtener certificados Wildcard de tipo *dominio.com y también que funciona bien incluso si tenemos varios servidores web. La parte negativa, es que debemos usar credenciales API en el servidor web, es posible que el proveedor del dominio no tenga API, o bien que no proporcione tiempos de propagación del TXT configurado.

Si usas un programa como Certbot para obtener los certificados TLS de Let’s Encrypt, tienes que ejecutar un comando como este:

Certbot nos pedirá añadir en la gestión de DNS el registro TXT «_acme-challenge» proporcionado por el programa, esperaremos unos minutos hasta que se propague correctamente el TXT, y luego podemos seguir con el asistente de Certbot. Una vez hecho, tendrás que realizar una automatización para posteriores renovaciones del certificado TLS, usando la API del registrador que uses. Os recomendamos acceder a los plugins DNS para automatizar el proceso, encontraréis todos los pasos que tendréis que hacer dependiendo del proveedor de DNS.

En el caso de usar Cloudflare Tunnels, la creación del Wildcard es totalmente transparente, no tienes que realizar estas acciones.