2026-10-06 · PESQUISA · A equipe da Offensive Technology

Como os logs de Certificate Transparency vazam subdomínios internos

O Certificate Transparency vaza hostnames internos? Sim, rotineiramente. Lemos os logs públicos de CT de 702 dos principais domínios via crt.sh, a mesma consulta gratuita que qualquer pessoa pode executar, e descobrimos que 65.5% registraram pelo menos um hostname com aparência interna: a dev., staging., vpn., admin., jira., ou vault.-style que quase certamente era voltado para a equipe interna, não para a internet pública. Nenhum host foi escaneado, resolvido ou contatado para obter esse número. O CT é um log público, append-only, de todos os certificados que uma CA pública já emitiu, e basta um nome receber um único certificado publicamente confiável para se tornar um registro permanente e pesquisável. Esse é o primeiro passo de um invasor antes do início de qualquer varredura, e a maioria das organizações está entregando sua convenção interna de nomenclatura de graça.

Por que um log público vaza nomes de aparência privada

O Certificate Transparency existe por um bom motivo: ele impede que uma CA emita incorretamente e em silêncio um certificado para um domínio que não deveria, pois todo certificado emitido fica visível para o proprietário do domínio e para o público. O Chrome e outros navegadores exigem o registro em CT para CAs publicamente confiáveis desde 2018 sob a RFC 6962. Essa é uma vitória real de segurança para o ecossistema. O efeito colateral é que o CT também registra o próprio hostname, e o hostname costuma ser a parte mais reveladora do registro.

Sistemas internos recebem certificados públicos por um motivo simples e rotineiro: ninguém quer ver um aviso no navegador quando a equipe abre o portal da VPN ou a instância interna do Jira, mesmo que o DNS desse nome resolva apenas na rede corporativa ou em um túnel VPN. Assim, o nome recebe um certificado real da Let's Encrypt, DigiCert ou outra CA pública, exatamente como um site exposto à internet receberia. O certificado cumpre seu papel silenciosamente. O efeito colateral é que vpn.example.com ou staging-admin.example.com agora pode ser lido permanentemente por qualquer pessoa que consulte o CT em busca de example.com, por meio de uma ferramenta gratuita como o crt.sh, sem nenhuma interação com a infraestrutura do próprio example.com.

Os dados: o que 702 dos principais domínios registram

Consultamos o crt.sh para uma amostra da lista dos principais sites do Tranco (lista 94Y82), um domínio por vez com caching e backoff para não sobrecarregar o serviço, e classificamos o primeiro rótulo DNS de cada nome registrado em nove categorias convencionais de nomenclatura interna: acesso remoto, autenticação/identidade, não produção, devops/CI, colaboração interna, observabilidade, administração/gestão, segredos/infraestrutura e nomes explicitamente internos. 702 dos 1,000 domínios consultados foram concluídos; 660 tinham algum histórico no CT. Os resultados por domínio foram mantidos apenas em memória durante a execução e nunca gravados em disco, portanto nada aqui expõe uma organização específica. São porcentagens populacionais, não uma lista.

Nomes de não produção dominam: 58.8% dos domínios registraram um nome dev., staging., test. ou similar. Esse é o achado menos surpreendente e o menos perigoso por si só, ter um ambiente de staging nomeado não é uma vulnerabilidade. O que é mais interessante é até onde as categorias perigosas avançam na lista. 20.4% registraram um nome relacionado a segredos ou infraestrutura como vault., consul. ou k8s., e 21.8% registraram um nome de acesso remoto como vpn. ou citrix. Essas são as categorias em que o próprio nome diz ao invasor exatamente para qual produto buscar uma CVE conhecida.

Prefixos individuais contam a mesma história com maior resolução. Aqui estão os doze rótulos mais comuns que encontramos, por participação na amostra de 702 domínios:

O prefixo vpn. sozinho representa 12.8% de toda a amostra, o que significa que cerca de um em cada oito dos domínios mais acessados da internet disse ao mundo, por meio de um log público em que nunca precisou tocar, que opera um produto específico de acesso remoto em um nome específico. Combine isso com o fingerprinting de versão possível assim que um hostname resolve, e o invasor passa de zero conhecimento para uma lista priorizada de alvos sem enviar um único pacote contra o alvo.

Raramente para em um único nome

O vazamento não se distribui de maneira uniforme em apenas um nome por domínio. Dos 460 domínios que vazaram alguma coisa, 113 vazaram um nome de exatamente uma categoria, mas o restante vazou em várias categorias ao mesmo tempo: 65 domínios atingiram três categorias, 42 atingiram seis e 22 domínios vazaram um nome em todas as nove categorias que monitoramos. Uma vez que uma organização adquire o hábito de emitir certificados públicos reais para ferramentas internas, esse hábito tende a se repetir em todas as ferramentas internas que ela opera, e não apenas em uma. Para um invasor, um domínio que vaza amplamente é mais valioso do que um que vaza um único nome, porque mapeia infraestrutura de dev, infraestrutura de autenticação e infraestrutura de admin em uma única consulta.

Como verificar seu próprio domínio

Isso leva menos de um minuto e não exige nenhuma ferramenta além de um navegador ou curl, porque você está lendo o mesmo registro público que nós lemos.

• Consulte o crt.sh diretamente. Abra https://crt.sh/?q=%25.yourdomain.com&output=json e leia todos os hostnames retornados. Isso é tudo o que o CT já registrou para o seu domínio, incluindo nomes emitidos anos atrás para servidores que podem ter sido desativados há muito tempo.
• Filtre a saída com grep procurando rótulos de aparência interna. Procure especificamente pelos prefixos da tabela acima: dev, test, staging, admin, auth, vpn, internal, vault, jenkins, gitlab, grafana e suas variantes próximas. Qualquer coisa que corresponda é permanentemente pública, resolvendo atualmente ou não.
• Trate cada ocorrência como já conhecida por um invasor. Você não pode remover retroativamente um certificado do log. A única atitude é assumir que o nome é público, garantir que o serviço por trás dele não dependa de obscuridade e mantê-lo com patches em dia e controle de acesso como um ativo exposto à internet, porque, para um invasor que lê o CT, ele já é.

O que isso não prova

Limites honestos, porque um número sem suas ressalvas é apenas marketing.

• Um nome registrado não é prova de um serviço ativo, acessível ou vulnerável. Apenas comparamos o texto do hostname no CT, nada mais. Não resolvemos nenhum nome, não nos conectamos a nenhum host nem testamos se o serviço por trás dele ainda existe. Alguns desses nomes apontam para infraestrutura desativada; outros não apontam para absolutamente nada.
• É uma amostra de 702 domínios, não a internet inteira. Os principais sites do Tranco tendem a favorecer organizações grandes e consolidadas, com infraestrutura suficiente para ter ambientes de dev e staging em primeiro lugar. Uma metodologia de ranking diferente ou uma amostra mais ampla alteraria as porcentagens exatas.
• É um snapshot. Esses números descrevem o estado do CT na nossa leitura de 24 de julho de 2026. Organizações adicionam e desativam hostnames internos continuamente, portanto os números exatos mudam com o tempo, mesmo que o comportamento subjacente não mude.
• A correspondência por prefixo é heurística, não exata. Um rótulo como admin geralmente é um painel de administração interno, mas ocasionalmente pode ser o nome legítimo de um produto voltado ao público. Otimizamos a lista de categorias para convenções comuns de nomenclatura, não para precisão perfeita, portanto trate as porcentagens como um forte indicativo, não como um inventário exato.
• Isso mede a exposição de um nome, não a sua explorabilidade. Saber que vpn.example.com existe é reconhecimento, não comprometimento. O que isso dá ao invasor é uma lista priorizada e de baixo esforço do que analisar em seguida.

Perguntas frequentes

Invasores podem usar logs de Certificate Transparency para encontrar subdomínios?

Sim. Todo certificado que uma CA pública emite é registrado sob a RFC 6962, e qualquer pessoa pode pesquisar esses logs gratuitamente pelo crt.sh. Na nossa amostra de 702 domínios, 65.5% das organizações registraram pelo menos um hostname de aparência interna dessa forma, com zero interação com sua infraestrutura.

Os logs de CT podem revelar hostnames internos que nunca deveriam ser públicos?

Sim. Um nome precisa apenas de um certificado publicamente confiável, muitas vezes emitido para que a equipe não veja um aviso no navegador, para se tornar um registro público permanente. O servidor por trás dele não precisa estar acessível pela internet para que o próprio nome vaze.

Quais informações são expostas no campo Subject Alternative Name de um certificado?

O campo SAN lista todos os hostnames cobertos por um certificado. Um único certificado multidomínio pode expor dezenas de nomes de uma só vez, todos pesquisáveis no CT a partir do momento em que o certificado é emitido.

Como descubro subdomínios usando o crt.sh?

Consulte https://crt.sh/?q=%25.yourdomain.com&output=json. Isso retorna todos os certificados registrados para o seu domínio e subdomínios, incluindo os emitidos para servidores que podem nem existir mais. É uma consulta passiva, somente leitura, de um log público, o mesmo método utilizado aqui.

Um certificado wildcard impede que subdomínios apareçam nos logs de CT?

Um certificado wildcard para *.example.com registra apenas a string wildcard, ocultando o rótulo específico do subdomínio. Mas, no momento em que um serviço recebe seu próprio certificado nomeado individualmente, esse nome é registrado mesmo que todo o restante esteja atrás de um wildcard.

Como posso evitar que hostnames internos vazem no Certificate Transparency?

Use uma CA privada e interna para nomes que nunca deveriam ser públicos, já que apenas CAs públicas são obrigadas a registrar no CT. Prefira certificados wildcard em vez de certificados folha nomeados individualmente sempre que sua arquitetura permitir, e trate qualquer coisa que já esteja no CT como permanentemente conhecida.

Autoridades certificadoras privadas ou internas estão isentas do registro em Certificate Transparency?

Sim. O registro em CT é exigido para CAs publicamente confiáveis, não para certificados em geral. Um certificado emitido pela sua própria CA interna, confiável apenas pelos seus dispositivos gerenciados, nunca precisa tocar em um log público de CT.

Leituras complementares

• O que os invasores realmente conseguem ver sobre a sua empresa? A questão mais ampla de superfície de ataque da qual este post responde a uma parte.
• Quanto tempo leva para um certificado aparecer no CT? No mesmo escopo do crt.sh, a questão do tempo em vez da questão do nome.
• O Certificate Transparency já é pós-quântico? Uma camada diferente do mesmo ecossistema de logs públicos, a camada de assinatura de checkpoints em vez do conteúdo do certificado.