CERTIFICATE TRANSPARENCY: CT LOGS COMO LINHA DO TEMPO FORENSE

Introdução: Quando o Domínio Desaparece, o Registro Permanece

Um domínio pode desaparecer. Um servidor pode ser desligado. Um subdomínio pode deixar de existir. Um DNS pode mudar. Mas determinados registros históricos permanecem.

É justamente aí que Certificate Transparency (CT) pode se transformar em uma fonte extremamente interessante para OSINT.

Quando a maioria das pessoas aprende sobre Certificate Transparency, o enquadramento é como um mecanismo de confiança do navegador: CAs logam cada certificado que emitem, navegadores verificam a prova, emissão indevida é pega. Esse enquadramento está correto, mas enterra o ponto principal para trabalho OSINT.

Para um investigador, CT é a melhor fonte cronologicamente ordenada, publicamente auditável, rica em timestamps de infraestrutura da Internet que existe. É um caderno do que alguém construiu, quando construiu, e como nomeou as peças. Todo certificado TLS já emitido para um domínio publicamente confiável está lá, com timestamps assinados por um operador de log independente e que não podem ser editados silenciosamente depois.

A maioria dos posts sobre crt.sh para em “use para enumerar subdomínios”. Essa é a coisa mais básica que você pode fazer com CT e, arguivelmente, a menos interessante. Este artigo é sobre ler CT logs como uma timeline, com exemplos práticos de como usar essa timeline para datar rollouts de infraestrutura, pegar ambientes de staging semanas antes de irem a público, e produzir uma cronologia defensável que você pode colocar num relatório.

O que CT Realmente Registra: Timestamps e Campos Importantes

Uma CA, antes de emitir um certificado, submete o precertificado a um ou mais logs append-only. Cada log assina um Signed Certificate Timestamp (SCT) que é embutido no certificado final. O navegador vê o SCT, verifica a assinatura do log, e confia que o certificado foi publicamente divulgado. Os logs são operados por operadores independentes (Google, Cloudflare, DigiCert, Sectigo, Let’s Encrypt até Fevereiro 2026, e outros). Eles são sharded por semestre agora, então você verá nomes como solera2026h1 ou xenon2026h2. A partir do Chrome 148 (Maio 2026), SCTs entregues via stapled OCSP não são mais aceitos, o que empurra tudo para o caminho de SCT embutido que termina no próprio certificado.

Para nossos propósitos, duas verdades importam: todo certificado é logado, e toda entrada de log carrega um timestamp verificável.

Uma entrada de CT log te dá vários campos de tempo. A maioria dos investigadores só olha para um e isso é um erro.

not_before é quando o certificado se torna válido. É definido pela CA e quase sempre retroativo (backdated) por alguns minutos ou horas para considerar clock skew. É a coisa mais próxima de “quando o certificado foi realmente solicitado”.

not_after é quando o certificado expira. Útil para filtrar ruído, menos útil para trabalho de timeline.

entry_timestamp (às vezes chamado de “ingestion time” do log) é quando o log recebeu a entrada. Este é o timestamp do SCT, assinado pelo log, e impossível de forjar ou retrodatação (backdate). Para estabelecer um limite inferior verificável de quando um nome existiu nos planos de alguém, este é o campo que você cita num relatório.

O padrão para internalizar: not_before te diz quando o certificado começou a funcionar. entry_timestamp te diz o momento mais cedo que um terceiro (o operador do log) pode atestar que o nome existiu. Os dois geralmente estão a minutos de distância, mas numa questão de timeline contestada, o timestamp do log é o que tem proveniência (provenance).

Lendo crt.sh Cronologicamente: JSON e jq

O resultado padrão do crt.sh ordena por ID de certificado. Isso não é cronológico. A primeira coisa a fazer em qualquer investigação é virar a view em algo que você consegue ler numa timeline.

Uma nota rápida sobre alvos de demo antes dos comandos. Todo tutorial de CT na internet usa example.com. Ao longo dos anos isso envenenou como alvo de teste. crt.sh tem dezenas de milhares de entradas históricas para example.com, a query sem filtro dá timeout, e o caminho exclude=expired tem dado 502s nele há meses por causa de problemas de backend em andamento na Sectigo. Se você copiar uma query de tutorial verbatim com example.com substituído, vai bater numa parede que nada tem a ver com a técnica. Para os exemplos abaixo estou usando osintph.info, que é pequeno o suficiente para retornar limpo e real o suficiente para mostrar padrões interessantes. Substitua seu próprio alvo.

https://crt.sh/?q=osintph.info&exclude=expired

A busca avançada em https://crt.sh/?a=1 permite marcar “Exclude expired certificates” que é o único filtro que consistentemente ajuda em domínios médios/grandes. Existe um cap silencioso de 10.000 linhas nos result sets, e para domínios de alto volume como facebook.com ou appspot.com você não verá certificados recentes de jeito nenhum se não excluir os expirados. Isso é uma limitação conhecida e não um bug que você consiga contornar na UI, embora o output JSON te dê mais flexibilidade.

Para trabalho cronológico, mude para JSON:

https://crt.sh/?q=osintph.info&output=json&exclude=expired

Pipe via jq e você tem algo útil:

curl -s 'https://crt.sh/?q=osintph.info&output=json&exclude=expired' \
  | jq 'sort_by(.not_before) | .[] | {name: .name_value, issued: .not_before, issuer: .issuer_name}'

Agora você tem um feed cronológico de cada nome que apareceu num certificado para aquele domínio, do mais antigo para o mais novo, com o emissor para cada um. Este é o material bruto que você constrói uma timeline.

Para descoberta de wildcard, o leading dot wildcard é a sintaxe que realmente funciona:

https://crt.sh/?q=%.osintph.info&output=json&exclude=expired

Queries antigas do crt.sh suportavam padrões arbitrários %api%.target.com. Esses se foram agora e retornam “unsupported use of %.” Leading dot only.

Esta é a matéria-prima que você constrói uma timeline.

O que um Novo Wildcard Realmente Conta Sobre a Infraestrutura

Esta é a seção que a maioria dos posts introdutórios de CT pula inteiramente.

Quando você observa o histórico de certificados de um alvo ao longo do tempo, o padrão de emissão em si é inteligência. Alguns exemplos do que padrões específicos significam na prática.

Um novo *.target.com wildcard aparecendo após longo histórico de certs single-name significa que alguém moveu para um load balancer ou CDN que precisa servir muitos subdomínios sob um cert, ou alguém deployou um service mesh, ou alguém cansou de gerenciar certs individuais e consolidou. Qualquer um desses implica um projeto de infraestrutura que provavelmente estava em planejamento por semanas antes do cert aparecer. Cross-reference a data contra o blog do alvo, press releases, ou job postings e você frequentemente encontra o nome do projeto.

Um novo *.dev.target.com ou *.staging.target.com wildcard é mais alto (louder). Diz que um ambiente non-production foi formalizado ao ponto de precisar do próprio wildcard. Isso acontece quando há mais que um punhado de serviços no ambiente, o que significa que o time passou da fase de protótipo. É um dos sinais mais claros de “isso está sendo construído” que você pode conseguir sem acesso insider.

Uma mudança de CA (CA shift) é um sinal de procurement. Se um alvo emitiu exclusivamente via Let’s Encrypt por anos e de repente mostra DigiCert OV ou EV certs, alguém tomou uma decisão de budget e comprou um CA comercial, provavelmente por causa de requisito de auditoria ou esforço de certificação de compliance.

Um burst de novos certs numa janela curta geralmente significa migração. Ou estão movendo para nova plataforma que re-emite, ou estão rotacionando após comprometimento ou key disclosure. O padrão de burst combinado com os nomes envolvidos te diz qual.

Certificados EV ainda são emitidos, embora o tratamento no navegador tenha sido achatado. Ver um EV cert num domínio corporativo confirma verificação de identidade no momento da emissão, que ocasionalmente é útil quando você precisa provar que uma entidade afirmou um nome legal numa data específica.

A habilidade sendo desenvolvida aqui é ler o diff entre dois snapshots do histórico CT de um alvo e inferir o que mudou no stack deles.

Pegando Ambientes de Staging Antes de Irem a Produção

Aqui é onde CT ganha seu sustento em trabalho de red team e threat intelligence.

Quando uma empresa lança um novo produto, o rollout quase sempre parece assim: builda o produto num ambiente staging interno, conecta um domínio tipo betarollout.target.com, pega um certificado TLS pro domínio (que vai para CT), testa internamente por semanas, depois anuncia. O certificado existe publicamente o tempo todo. O anúncio é o último passo.

Se você está monitorando CT para aquele alvo, vê o nome de staging aparecer no dia em que eles clicaram “request certificate” no IaC deles. Daí é questão de sondar o nome pra ver se um serviço está realmente alcançável (frequentemente sim, atrás de auth wall mas com TLS handshake confirmando que o cert está em uso), e então observar quais padrões de nomes aparecem depois.

O workflow:

1. Identifique o apex domain do alvo e quaisquer second-level domains conhecidos que eles usam.
2. Subscreva um serviço de CT monitoring que te mande email ou webhook em certificados novos. Cert Spotter da SSLMate é a escolha padrão e o free tier cobre a maioria do uso legítimo de pesquisa. Censys também oferece alerting pago se você precisar de volume maior ou delivery programático.
3. Quando um novo nome aparece, capture o SCT timestamp. Essa é sua data “este nome existiu” provável mais antiga.
4. Probe o nome com curl -I -k https://<name> e dig <name> pra ver se resolve e serve. Muitos ambientes staging DNS-resolvem pra um load balancer público com auth na frente.
5. Registre o que achar, observe nomes relacionados, e mantenha a timeline atualizada.

Os usos legítimos aqui são extensos. Times de brand protection usam pra pegar infraestrutura de phishing que imita seus próprios padrões de naming. Times de threat intel usam pra pegar infraestrutura C2 sendo staged. Analistas de competidor usam pra pegar lançamentos de produto. Defensores usam pra pegar shadow IT dentro da própria org subindo serviços internet-facing sem passar pelo time de segurança.

Os usos ilegítimos também existem e é por isso que responsible disclosure importa quando você acha algo interessante. Se você descobre um ambiente staging para produto não lançado, não escreva um blog post teardown sobre isso. Isso não é OSINT, é ser vazador. Anote a data, archive, e siga em frente.

Além do crt.sh: Censys, Cert Spotter e Acesso Direto aos Logs

crt.sh é a interface CT mais acessível mas não é a mais completa e não é a mais confiável.

Censys indexa CT e combina com active scanning da Internet, então você ganha o histórico de certificados junto com tudo mais que eles sabem sobre o IP e o serviço. O free tier é rate-limited e te dá uma view inicial. Uso investigativo sério precisa acesso pago, que não é barato mas é justificável para trabalho profissional. A query language é mais poderosa que crt.sh, particularmente para cross-referenciar entre serviços.

Cert Spotter (SSLMate) é o padrão para monitoramento CT com alertas. O free tier cobre a maioria do uso legítimo de pesquisa. Censys também oferece alerting pago se você precisar de volume maior ou delivery programático.

O cap de 10.000 linhas importa. Em domínios de alto volume você vai silenciosamente perder certificados recentes. Sempre exclua certs expirados em alvos grandes, e considere rodar queries contra subdomínios separadamente pra ficar sob o cap.

Alguns logs foram aposentados. O log Oak do Let’s Encrypt ficou read-only e está shutting down em Fevereiro 2026. Logs Google antigos (Argon, Xenon, Pilot) foram aposentados em várias janelas. Certificados que só foram logados em logs aposentados ainda existem no histórico CT mas a cadeia de auditoria depende do log estar alcançável. Para certificados muito antigos isso é ocasionalmente uma preocupação.

not_before retroativo (backdated) é real mas limitado. CAs comumente setam not_before alguns minutos a algumas horas antes da emissão real. Para timelines de precisão de minuto isso importa. Para precisão de dia, ignore. O SCT entry_timestamp é o constraint mais duro.

Cobertura pré-2018 é patchy. CT não foi universalmente requerido até Outubro 2018 quando a política da Apple entrou. Qualquer coisa antes disso pode ou não estar em CT. Se sua investigação volta pra 2017 ou antes, não espere CT completo.

Certificados internos-only não estão em CT. Qualquer coisa emitida por private CA pra nome interno não aparece. CT só cobre certificados publicamente confiáveis. Se um alvo usa private CA pra serviços internos, você vê os gateway certs mas nada atrás deles.

Onde CT Se Encaixa na Timeline Maior

CT é uma fonte de dados. Combina bem com tudo mais coberto na série.

O post de RDAP e WHOIS te deu timestamps de registrar e registrant pro apex domain. CT te dá os timestamps de emissão para cada nome sob aquele apex. Combinados, você tem “quando o domínio foi registrado” mais “quando cada peça de infraestrutura sob ele veio online”. Passive DNS em cima te diz “quando cada nome resolveu pra um IP pela primeira vez”. Wayback te diz “quando cada nome serviu conteúdo público pela primeira vez”.

Empilhe essas quatro fontes e você tem uma timeline defensável que não depende de dados de um único provedor serem precisos. Esse é o padrão para trabalho sério de atribuição.

Próximo post na timeline series será sobre passive DNS, que preenche o lado da resolução dessa imagem. Se você não assinou o feed ainda, o link tá no topo da página.

Limitações: O Que CT Logs Não Provam

Um registro em Certificate Transparency não significa necessariamente que:

• o serviço ainda existe;
• o host continua ativo;
• determinado servidor permanece no mesmo endereço;
• determinada organização continua utilizando aquela infraestrutura;
• o certificado prova quem operava o sistema.

Diferencie claramente:

EVIDÊNCIA HISTÓRICA — o certificado existiu, foi emitido, logado, timestampado. Isso é fato.

ESTADO ATUAL — o serviço roda, o host responde, a infraestrutura é a mesma. Isso é hipótese até confirmado por outros meios (probing ativo, DNS resolution, HTTP response, etc.).

Essa distinção é fundamental para investigação OSINT responsável. Um certificado em CT te diz “alguém solicitou um cert para este nome nesta data”. Não te diz “este serviço está rodando agora” ou “esta organização controla esta infraestrutura hoje”.

Outras limitações práticas:

• Cap de 10.000 linhas no crt.sh = miss silencioso de certs recentes em domínios alto volume. Sempre exclude=expired em alvos grandes; queries contra subdomínios separadamente.
• Logs aposentados: Let’s Encrypt Oak read-only/shutting down Fev 2026; Google logs antigos (Argon, Xenon, Pilot) aposentados. Cadeia de auditoria depende do log alcançável.
• not_before backdated: minutos a horas antes. SCT entry_timestamp é constraint mais duro.
• Cobertura pré-2018 patchy: CT universal required só Out 2018 (política Apple). Antes disso, não espere CT completo.
• CAs privadas (private CAs) não estão em CT: qualquer coisa emitida por private CA pra nome interno não aparece. Se alvo usa private CA pra serviços internos, você vê gateway certs mas nada atrás deles.

Conclusão: CT Logs Como Caderno Forense

Certificate Transparency não é apenas um mecanismo de confiança do navegador. Para o investigador OSINT, é a melhor fonte cronologicamente ordenada, publicamente auditável, rica em timestamps de infraestrutura da Internet que existe.

É um caderno do que alguém construiu, quando construiu, e como nomeou as peças. Cada certificado TLS já emitido para domínio publicamente confiável está lá, com timestamps assinados por operador de log independente que não podem ser editados silenciosamente depois.

Leia os logs como um caderno forense. Individualmente, um certificado pode parecer pouco relevante. Quando vários registros são colocados em ordem cronológica, padrões aparecem: surgimento de subdomínios, novos ambientes, serviços temporários, infraestrutura antiga, mudanças organizacionais, migrações, nomenclaturas internas expostas, padrões de desenvolvimento.

A habilidade sendo desenvolvida aqui é ler o diff entre dois snapshots do histórico CT de um alvo e inferir o que mudou no stack deles.

CT é uma fonte de dados. Combina com tudo mais: RDAP/WHOIS (apex timestamps) + CT (issuance timestamps) + Passive DNS (resolution timestamps) + Wayback (content timestamps). Empilhe as quatro fontes e você tem uma timeline defensável que não depende de dados de um único provedor serem precisos. Esse é o padrão para trabalho sério de atribuição.

Os alertas nunca param. Agora, nem a leitura.