Certificate transparency e historial de DNS en recon

Cada certificado TLS que emite una CA publica se escribe en logs publicos de certificate transparency, los logs de CT. Los nombres de esos certificados, incluidos subdominios de aspecto interno, los puede buscar cualquiera. Une CT con historial de DNS, el registro de a que apunto un nombre con el tiempo, y mapeas la infraestructura del objetivo sin mandar una peticion. La chat de NotHoly ayuda a correlacionar las piezas: mismo IP, mismo certificado, mismo patron.

#Consulta los logs de CT con crt.sh

crt.sh es una interfaz web a los logs de CT, y tambien habla JSON, asi que puedes automatizarlo.

curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' | anew ct.txt

El %25 es un por ciento codificado en URL, el comodin de SQL, asi que esto devuelve todo nombre visto en un certificado bajo example.com. Algunas lineas vuelven como entradas comodin, con estrella y punto al inicio; mantenlas o quitalas segun prefieras. CT suele revelar hosts que nunca aparecen en brute force de DNS ni en crawling, porque el certificado se emitio antes de que el host saliera al aire.

#Lee lo que un certificado ata

Un solo certificado puede listar muchos nombres en el campo subject alternative name, el SAN. Cuando un host de dev, uno de staging y uno de admin comparten un certificado, suelen compartir un despliegue. Saca el conjunto SAN de un host directo.

echo | openssl s_client -connect api.example.com:443 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

Los nombres impresos junto a tu host son pistas fuertes. Estan en alcance solo si quedan bajo raices que puedes probar, asi que revisa cada uno en tu hoja de alcance.

#Suma el historial de DNS

El registro actual de un nombre es una sola instantanea. El historial de DNS muestra los IP y servidores de correo que uso antes, lo que puede exponer un origen tras una CDN o un servidor viejo aun corriendo. Los proveedores de DNS pasivo guardan estos datos y muchos tienen capa gratis. Resuelve los registros actuales tu mismo con dnsx.

dnsx -l ct.txt -a -resp -silent -o resolved.txt

Compara los IP de hoy con el conjunto historico. Un IP que la CDN ya no cubre, pero que aun responde, merece una mirada cuidadosa y dentro de alcance, porque puede ser el origen que la CDN debia esconder.

#Correlaciona con la chat

Pega los nombres de certificado, los IP resueltos y cualquier historial en la chat de NotHoly.

Aqui estan hosts, sus IP actuales e IP historicas.
Agrupalos por IP y certificado en comun, marca cualquier IP
de origen fuera de los rangos de la CDN y lista los grupos
de infraestructura que puedas inferir. Anota lo incierto.

El modelo agrupa los registros y nombra su incertidumbre, lo que te evita leer de mas una coincidencia. Confirma cada grupo contra tu propia resolucion antes de tratarlo como hecho, porque el dato historico puede estar viejo.

#Alcance y privacidad

CT e historial de DNS son publicos, pero los hosts que revelan no son todos tuyos para tocar. Un certificado puede nombrar una plataforma compartida o un socio, asi que manten solo los nombres bajo las raices que puedes probar. Hallar un IP de origen no amplia tu alcance; si queda fuera, lo anotas y paras.

#Preguntas frecuentes

#Puedo hallar subdominios que el brute force de DNS pierde?

Si. CT muestra nombres de certificados emitidos que quiza nunca tuvieron registro publico de DNS, o que salieron del DNS despues. Es una de las fuentes pasivas de mayor rendimiento, por eso va temprano en la recon.

#Consultar crt.sh es pasivo?

Consultar crt.sh toca crt.sh, no tu objetivo, asi que es pasivo respecto al objetivo. Resolver esos nombres con dnsx si manda consultas de DNS, asi que trata ese paso como trabajo activo leve y mantenlo en alcance.

CT y DNS te dan infraestructura; la siguiente fuente es codigo. Sigue a recon de GitHub y busqueda de codigo. Vuelve a crawling y recoleccion de URL.