La VPN olvidada: enumerar shadow IT desde fuera

Toda organización tiene un activo del que no sabe nada. Normalmente varios. Un appliance de VPN levantado para un proyecto que terminó, un entorno de staging que nunca se desmontó, un subdominio de marketing apuntando a una plataforma que alguien dejó de pagar, un dispositivo que instaló un proveedor y que nadie heredó. Nada de eso aparece en la CMDB, porque la CMDB registra lo que se pidió y no lo que existe.

El activo que no tiene dueño es el que nadie parchea. Esa es toda la razón por la que merece la pena hacer esta pasada, y hacerla de forma periódica en vez de una sola vez.

Empieza por lo que es demostrablemente tuyo

La tentación es empezar con un diccionario de subdominios. Resístete: la fuerza bruta encuentra lo que se te ocurrió adivinar, y los activos interesantes son los que nadie adivinaría. Empieza en cambio por registros que existen porque alguien tuvo que dar de alta algo.

Los logs de certificate transparency son la fuente individual más productiva que hay. Todo certificado de confianza pública emitido para un hostname queda registrado, de forma permanente y consultable, lo que significa que cada host que alguna vez tuvo TLS terminado delante ha dejado un rastro. Eso incluye los nombres de aspecto interno que la gente supone privados: vpn-test, jira-staging, old-mail. A los logs les da igual cuál era tu intención.

# Hostnames from certificate transparency
curl -s 'https://crt.sh/?q=%25.acme.local&output=json' \
  | jq -r '.[].name_value' \
  | tr '[:upper:]' '[:lower:]' | sed 's/^\*\.//' | sort -u

Los datos de registro son el segundo pilar. Trabaja hacia fuera desde los dominios que conoces hasta el ASN de la organización y los netblocks anunciados bajo él, y de ahí al DNS inverso de esos rangos. Esto encuentra infraestructura que no guarda relación con ningún hostname del que partieras, que es exactamente la categoría que buscas.

Tercero, DNS histórico. Los registros que existieron te dicen qué se desplegó en su día, y una proporción sorprendente sigue escuchando en la dirección a la que se apuntó. Un hostname retirado del DNS no es un host dado de baja; es un host sin documentar.

El problema del registro colgante

Hay dos modos de fallo que se repiten lo bastante como para comprobarlos de forma específica, y los dos vienen de la misma causa raíz: un registro DNS que sobrevive a aquello a lo que apunta.

Un CNAME apuntando a un servicio cloud que después se liberó significa que ese nombre lo puede reclamar quien registre el siguiente ese nombre de servicio. El DNS de la propia organización pasa entonces a dirigir de forma autoritativa a los visitantes, y a cualquier cookie con alcance sobre el dominio padre, hacia infraestructura que no controla. Esto es barato de comprobar y fácil de pasar por alto, porque el registro se ve perfectamente sano en el fichero de zona.

Un registro A apuntando a una dirección devuelta al pool de un proveedor tiene la misma forma con otra mecánica. Ambos se encuentran resolviendo cada registro que hayas recopilado y preguntando si el destino está reclamado, sin reclamar o sirviendo algo inesperado.

• Resuelve todo, y anota lo que no resuelve en vez de descartarlo. Un nombre que no resuelve es un hallazgo, no un callejón sin salida.
• Para cada CNAME, comprueba si el destino está registrado ahora mismo.
• Para cada dirección, confirma que está dentro de un rango que la organización controla de verdad. Las direcciones fuera de los netblocks conocidos son o hosting de terceros que nadie documentó o ya no son tuyas en absoluto.

Fingerprinting, y saber cuándo parar

Ya tienes una lista de hosts. Lo que importa es qué hay en ellos, y la respuesta se recoge en orden de menos intrusivo primero: una pasada de recon externo sobre un entorno vivo no es el sitio para descuidarse con un objetivo que aún no has confirmado que sea de tu cliente.

Primero la identificación de servicio y versión, a partir de banners y características de respuesta. Después la tecnología detrás de cualquier servicio web. Después si hay una superficie de autenticación, porque los appliances con página de login son la categoría más valiosa de todas: están expuestos a internet por diseño, con frecuencia sin parchear, y los que no tienen dueño están sin parchear por definición.

# Which of the collected hosts actually answer
httpx -l hosts.txt -sc -title -tech-detect -o live.txt

# Fingerprint without touching anything
nuclei -l live.txt -tags tech,detect -severity info

Aplican dos disciplinas. Confirma la propiedad antes de sondear nada: una búsqueda en certificate transparency por una marca común devuelve hosts de empresas completamente ajenas, y probar uno de esos es el incidente de otra persona. Y mantén separadas las fases pasiva y activa en tus notas, porque el cliente preguntará cuáles de tus hallazgos exigieron tocar su infraestructura y cuáles salieron de registros públicos.

El activo que no tiene dueño es el que nadie parchea. No es una coincidencia: es el mismo hecho dicho dos veces.

Priorizar lo que vuelve

Una primera pasada contra un entorno mediano devuelve más de lo que nadie va a atender. Ordenarlo es la parte que determina si el ejercicio cambia algo.

Ordena por una sola pregunta: si este host estuviera comprometido, ¿hasta dónde llegaría? Eso produce un orden muy distinto del que dan las puntuaciones de severidad.

• Primero las superficies de acceso remoto: concentradores de VPN, gateways de escritorio remoto, interfaces de gestión. Son puntos de entrada a la red por función, así que una debilidad en uno es una debilidad en el perímetro mismo.
• Después cualquier cosa con una superficie de autenticación ligada al directorio corporativo. Una aplicación olvidada que federa contra el proveedor de identidad principal es una posición de recolección de credenciales.
• Después los entornos que no son de producción y llevan datos de producción, que son casi todos.
• Después todo lo demás, que suele ser infraestructura de marketing abandonada y que importa sobre todo por la reputación del dominio.

Informa del vacío de propiedad junto a los hallazgos técnicos. «Este host ejecuta un appliance sin parchear» produce un parche. «Ningún equipo de la organización reclama este host, y hemos encontrado cuatro más iguales» produce un cambio de proceso, y el cambio de proceso es lo que evita que aparezcan los cuatro siguientes.

Haz que se repita

Una evaluación externa puntual describe un día. El entorno cambia cada semana: alguien levanta un subdominio, un proveedor despliega un appliance, un proyecto termina sin paso de desmantelado.

Las fases de recopilación de aquí son todas automatizables y baratas. Lánzalas de forma programada, guarda los resultados y haz diff. Un host nuevo que aparece en certificate transparency para tu dominio, sin ticket de cambio que le corresponda, merece un email esa misma semana en lugar de un hallazgo en el informe del año que viene. El valor no está en el escaneo individual: está en ser el primero en darse cuenta de cada cambio.