2026-10-06 · RESEARCH · El equipo de Offensive Technology

Cómo los registros de Certificate Transparency filtran subdominios internos

¿Filtra Certificate Transparency hostnames internos? Sí, de forma rutinaria. Analizamos los registros públicos de CT de 702 dominios principales a través de crt.sh, la misma consulta gratuita que cualquiera puede ejecutar, y descubrimos que el 65.5% ha registrado al menos un hostname con apariencia interna: a dev., staging., vpn., admin., jira., o vault.-style que casi con certeza estaba destinado al personal, no a internet pública. No se escaneó, resolvió ni contactó a ningún host para obtener este número. CT es un registro público, de solo adición, de cada certificado que una CA pública haya emitido jamás, y un nombre solo necesita recibir un único certificado públicamente confiable para convertirse en un registro permanente y consultable. Este es el primer paso de un atacante antes de iniciar cualquier escaneo, y la mayoría de las organizaciones están entregando su convención interna de nomenclatura de forma gratuita.

Por qué un registro público filtra nombres con apariencia privada

Certificate Transparency existe por una buena razón: evita que una CA emita indebidamente y en silencio un certificado para un dominio que no debería, ya que cada certificado emitido se vuelve visible para el propietario del dominio y para el público. Chrome y otros navegadores exigen el registro en CT a las CA públicamente confiables desde 2018 en virtud de la RFC 6962. Esa es una auténtica victoria de seguridad para el ecosistema. El efecto secundario es que CT también registra el propio hostname, y el hostname suele ser la parte más reveladora del registro.

Los sistemas internos obtienen certificados públicos por una razón común y ordinaria: nadie quiere ver una advertencia en el navegador cuando el personal abre el portal de la VPN o la instancia interna de Jira, incluso si el DNS para ese nombre solo resuelve en la red corporativa o a través de un túnel VPN. Por tanto, el nombre obtiene un certificado real de Let's Encrypt, DigiCert u otra CA pública, exactamente igual que lo haría un sitio expuesto a internet. El certificado cumple su función en silencio. El efecto secundario es que vpn.example.com o staging-admin.example.com ahora puede ser leído permanentemente por cualquiera que consulte CT para example.com, a través de una herramienta gratuita como crt.sh, con cero interacción con la propia infraestructura de example.com.

Los datos: qué registran 702 dominios principales

Consultamos crt.sh para una muestra de la lista de sitios principales de Tranco (lista 94Y82), un dominio a la vez con almacenamiento en caché y backoff para no sobrecargar el servicio, y clasificamos la primera etiqueta DNS de cada nombre registrado en nueve categorías de nomenclatura interna convencional: acceso remoto, autenticación/identidad, no producción, devops/CI, colaboración interna, observabilidad, administración/gestión, secretos/infraestructura y nombres explícitamente internos. 702 de los 1,000 dominios solicitados se completaron; 660 tenían algún historial en CT. Los resultados por dominio solo se mantuvieron en memoria durante la ejecución y nunca se escribieron en disco, por lo que nada aquí nombra a una organización específica. Estos son porcentajes poblacionales, no una lista.

Los nombres de entornos de no producción dominan: el 58.8% de los dominios ha registrado un nombre dev., staging., test. o similar. Ese es el hallazgo menos sorprendente y el menos peligroso por sí solo, que un entorno de staging tenga un nombre no constituye una vulnerabilidad. Lo que resulta más interesante es hasta dónde llegan las categorías peligrosas en la lista. el 20.4% ha registrado un nombre vinculado a secretos o infraestructura como vault., consul. o k8s., y el 21.8% ha registrado un nombre de acceso remoto como vpn. o citrix. Esas son las categorías donde el propio nombre le indica a un atacante con exactitud contra qué producto debe buscar un CVE conocido.

Los prefijos individuales cuentan la misma historia con mayor nivel de detalle. Estas son las doce etiquetas más comunes que identificamos, según su proporción en la muestra de 702 dominios:

El prefijo vpn. por sí solo se sitúa en el 12.8% de toda la muestra, lo que significa que aproximadamente uno de cada ocho de los dominios con más tráfico de internet ha revelado al mundo, a través de un registro público que nunca tuvieron que tocar, que ejecutan un producto de acceso remoto específico en un nombre específico. Combine eso con el fingerprinting de versiones posible una vez que un hostname resuelve, y un atacante habrá pasado de cero conocimiento a una lista priorizada de objetivos sin enviar un solo paquete hacia el objetivo.

Rara vez se detiene en un solo nombre

La filtración no se distribuye de manera uniforme a razón de un nombre por dominio. De los 460 dominios que filtraron algo, 113 filtraron un nombre de exactamente una categoría, pero el resto filtró en múltiples categorías a la vez: 65 dominios coincidieron en tres categorías, 42 en seis, y 22 dominios filtraron un nombre en las nueve categorías que rastreamos. Una vez que una organización adopta el hábito de asignar certificados públicos reales a sus herramientas internas, la costumbre tiende a repetirse en cada herramienta interna que opera, no solo en una. Para un atacante, un dominio que filtra ampliamente es más valioso que uno que filtra un único nombre, porque mapea infraestructura de dev, de autenticación y de administración en una sola consulta.

Cómo revisar su propio dominio

Esto toma menos de un minuto y no requiere más herramientas que un navegador o curl, ya que usted está leyendo el mismo registro público que nosotros leímos.

• Consulte crt.sh directamente. Abra https://crt.sh/?q=%25.yourdomain.com&output=json y revise cada hostname devuelto. Eso es todo lo que CT ha registrado alguna vez para su dominio, incluidos nombres emitidos hace años para servidores que podrían llevar mucho tiempo fuera de servicio.
• Filtre la salida con grep buscando etiquetas con apariencia interna. Busque específicamente los prefijos de la tabla anterior: dev, test, staging, admin, auth, vpn, internal, vault, jenkins, gitlab, grafana y sus variantes cercanas. Cualquier coincidencia es permanentemente pública, resuelva actualmente o no.
• Trate cada coincidencia como si ya fuera conocida por un atacante. No se puede eliminar retroactivamente un certificado del registro. La única medida es asumir que el nombre es público, asegurarse de que el servicio detrás de él no dependa de la oscuridad, y mantenerlo actualizado con parches y con control de acceso igual que un activo expuesto a internet, porque para un atacante que lea CT, ya lo es.

Lo que esto no demuestra

Límites honestos, porque un número sin sus matices es marketing.

• Un nombre registrado no es prueba de un servicio activo, accesible o vulnerable. Coincidimos texto de hostnames en CT, nada más. No resolvimos ningún nombre, no nos conectamos a ningún host ni comprobamos si el servicio detrás de él todavía existe. Algunos de estos nombres apuntan a infraestructura dada de baja; otros no apuntan a nada en absoluto.
• Es una muestra de 702 dominios, no todo internet. Los sitios principales de Tranco se inclinan hacia organizaciones grandes y consolidadas, con infraestructura suficiente para tener entornos de dev y staging en primer lugar. Una metodología de clasificación diferente o una muestra más amplia modificaría los porcentajes exactos.
• Es una instantánea. Estas cifras describen el estado de CT a fecha de nuestra lectura del 24 de julio de 2026. Las organizaciones agregan y retiran hostnames internos continuamente, por lo que las cifras exactas varían con el tiempo aunque el comportamiento de fondo no lo haga.
• La coincidencia por prefijo es heurística, no certera. Una etiqueta como admin suele ser un panel de administración interno, pero en ocasiones puede ser el nombre de un producto legítimo expuesto al público. Optimizamos la lista de categorías para la nomenclatura convencional, no para una precisión perfecta, así que trate los porcentajes como una señal sólida, no como un inventario exacto.
• Esto mide la exposición de un nombre, no su explotabilidad. Saber que vpn.example.com existe es reconocimiento, no compromiso. Lo que le proporciona a un atacante es una lista priorizada y de bajo esfuerzo sobre qué investigar a continuación.

Preguntas frecuentes

¿Pueden los atacantes usar los registros de Certificate Transparency para encontrar subdominios?

Sí. Cada certificado que emite una CA pública queda registrado bajo el RFC 6962, y cualquiera puede buscar en esos registros de forma gratuita a través de crt.sh. En nuestra muestra de 702 dominios, el 65.5% de las organizaciones había registrado al menos un hostname con apariencia interna de este modo, con cero interacción con su infraestructura.

¿Pueden los registros de CT revelar hostnames internos que nunca debieron ser públicos?

Sí. Un nombre solo necesita un certificado públicamente confiable, a menudo emitido para que los empleados no vean una advertencia del navegador, para convertirse en un registro público permanente. El servidor detrás de él no necesita ser accesible desde internet para que el nombre en sí se filtre.

¿Qué información queda expuesta en el campo Subject Alternative Name de un certificado?

El campo SAN enumera cada hostname que cubre un certificado. Un único certificado multidominio puede exponer docenas de nombres a la vez, todos consultables en CT en el momento en que se emite el certificado.

¿Cómo descubro subdominios utilizando crt.sh?

Consulte https://crt.sh/?q=%25.yourdomain.com&output=json. Devuelve cada certificado registrado para su dominio y sus subdominios, incluidos los emitidos para servidores que tal vez ya no existan. Es una consulta pasiva y de solo lectura en un registro público, el mismo método que utilizamos aquí.

¿Evita un certificado wildcard que los subdominios aparezcan en los registros de CT?

Un certificado wildcard para *.example.com solo registra la cadena wildcard, ocultando la etiqueta de subdominio específica. Pero en el momento en que un servicio obtiene su propio certificado con un nombre único, ese nombre queda registrado aunque todo lo demás esté detrás de un wildcard.

¿Cómo puedo evitar que los hostnames internos se filtren en Certificate Transparency?

Utilice una CA interna y privada para nombres que nunca deberían ser públicos, ya que solo las CA públicas deben registrar en CT. Priorice certificados wildcard sobre certificados hoja con nombres únicos donde su arquitectura lo permita, y trate cualquier elemento que ya esté en CT como permanentemente conocido.

¿Están las autoridades de certificación privadas o internas exentas del registro en Certificate Transparency?

Sí. El registro en CT se exige a las CA públicamente confiables, no a los certificados en general. Un certificado de su propia CA interna, confiable solo para sus dispositivos administrados, nunca tiene que pasar por un registro público de CT.

Lecturas relacionadas

• ¿Qué pueden ver realmente los atacantes sobre su empresa? La cuestión más amplia sobre la superficie de ataque de la que este artículo aborda solo una parte.
• ¿Cuánto tarda un certificado en aparecer en CT? En el mismo ámbito de crt.sh, aborda los tiempos en lugar de la nomenclatura.
• ¿Certificate Transparency ya es poscuántica? Una capa diferente del mismo ecosistema de registros públicos, la capa de firma de checkpoints en lugar del contenido del certificado.