Certificados TLS e Certificate Transparency

Nota da seção "06 - Análise de Infraestrutura" do capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE).
Trata o certificado TLS como objeto de inteligência: o que seus campos revelam, como os logs de Certificate Transparency tornam a emissão pesquisável em minutos e como JA3, JA3S e JA4 convertem o handshake em impressão digital de infraestrutura.
Dialoga com as notas de Domínios e Subdomínios, de Hosting e CDN e de Pivoting desta mesma seção, e com a nota de Pirâmide de Dor do capítulo 04.

1. Contexto e Posicionamento na Biblioteca

A análise de infraestrutura trata de responder três perguntas sobre um indicador: quem controla, onde roda e o que mais compartilha esse controle. O certificado TLS ocupa posição central nessa resposta porque é um artefato que o adversário precisa emitir, distribuir e apresentar a cada conexão criptografada, e porque desde 2018 os navegadores exigem que certificados públicos apareçam nos logs de Certificate Transparency (CT). O resultado é uma fonte de inteligência pública, abundante e quase em tempo real, que antecede o primeiro ataque: o certificado do domínio de phishing costuma ser emitido minutos ou horas antes do primeiro clique da vítima.

Esta nota cobre três camadas complementares. A primeira é o certificado como documento, com campos que sustentam pivôs descritos na nota de Pivoting e Correlação de Infraestrutura. A segunda é o ecossistema de CT e seus portais de pesquisa, como o crt.sh, que convertem emissões em fontes de enumeração de subdomínios e de monitoramento de marca. A terceira é a impressão digital do próprio handshake TLS, com JA3, JA3S e JA4, que opera no nível da Pirâmide de Dor superior ao IP e ao domínio, e por isso sobrevive à troca rápida de infraestrutura.

2. O Certificado TLS como Documento de Inteligência

Um certificado X.509 é um documento assinado por uma autoridade certificadora e apresentado pelo servidor em cada handshake. Para o analista, os campos mais produtivos são o Subject, com o Common Name (CN), o Subject Alternative Name (SAN), que lista todos os nomes de domínio cobertos pelo certificado, o Issuer, que identifica a autoridade emissora, o período de validade, a chave pública com seu tipo e tamanho, e o número de série. Cada campo sustenta um tipo de raciocínio analítico diferente, e a combinação deles é o que gera inteligência útil.

O SAN é o pivô mais valioso, porque reúne em um só artefato o conjunto de nomes que o operador considerou seu. Um certificado emitido para três domínios distintos informa que eles compartilham dono, configuração e provável finalidade, mesmo que resolvam para IPs diferentes. O Issuer distingue certificados pagos de organizações validadas de certificados gratuitos de validação de domínio, como os da Let's Encrypt, e o CN repetido em emissores distintos ao longo do tempo revela histórico de migração de infraestrutura. Já a chave pública e o número de série permitem correlacionar reemissões do mesmo operador mesmo após troca de domínio.

A tabela abaixo resume os campos de maior retorno analítico e como cada um alimenta o trabalho de infraestrutura.

Duas práticas operacionais aceleram a extração. A primeira é coletar o certificado ativamente na conexão, com ferramentas padrão de TLS. A segunda é ler sempre o certificado completo, e não apenas o CN, porque o CN moderno costuma repetir apenas o primeiro nome do SAN.

# Coletar e inspecionar o certificado apresentado por um host
echo | openssl s_client -connect exemplo-alvo.com.br:443 \
  -servername exemplo-alvo.com.br 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -E "Subject:|Issuer:|Not Before|Not After|Public-Key" \
  | head -n 10

# Extrair apenas os nomes do Subject Alternative Name
echo | openssl s_client -connect exemplo-alvo.com.br:443 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

3. Certificate Transparency: Como o Ecossistema Funciona

O Certificate Transparency é definido nas RFC 6962 e 9162 e funciona como um serviço público de auditoria de emissões. Toda autoridade certificadora reconhecida pelos navegadores principais submete cada certificado emitido a pelo menos dois logs públicos criptograficamente auditáveis, e o certificado só é aceito pelo navegador com um Signed Certificate Timestamp (SCT) que comprova a submissão. Os logs são append-only, organizados em árvores de Merkle e verificados periodicamente por monitores e auditores independentes, o que torna a falsificação ou remoção silenciosa de uma entrada computacionalmente inviável.

Os logs são operados por organizações distintas, entre elas o Google, a Cloudflare, a DigiCert e a Sectigo, e cada autoridade certificadora envia suas emissões a conjuntos aprovados de logs. Nenhum log único contém tudo, o que significa que portais de pesquisa agregam dezenas de logs e que automações sérias consultam mais de uma fonte. Para a inteligência de ameaças, o efeito prático é que toda emissão de certificado público vira registro público consultável, quase sempre em menos de uma hora. Isso produz três usos diretos. O primeiro é enumeração de subdomínios, já que cada nome listado em certificado aparece nos logs, exceto quando coberto por certificado curinga, como detalha a nota de Domínios e Subdomínios. O segundo é monitoramento de marca, porque emissores de phishing precisam emitir certificados com o nome da organização, e essa emissão dispara antes do golpe. O terceiro é o pivô inverso: dado um domínio suspeito, os logs revelam outros nomes que compartilharam o mesmo certificado ou o mesmo emissor em janelas próximas.

A emissão gratuita e automatizada, consolidada pela Let's Encrypt desde 2016 e seguida por outras autoridades, reduziu o custo do TLS válido para praticamente zero, e o phishing abandonou o antigo padrão de páginas HTTP simples. O analista moderno trabalha com a premissa de que o site de phishing estará bem assinado, e usa a emissão, e não a ausência de criptografia, como sinal.

4. Pesquisa Prática em CT: crt.sh e Consultas Automatizadas

O crt.sh, mantido pela Sectigo, é o portal mais usado pela comunidade para pesquisar os logs de CT, porque aceita busca por domínio, por nome em curinga e por hash de certificado, e oferece saída em JSON para automação. A consulta abaixo recupera todos os nomes já emitidos para um domínio e seus subdomínios, quebra os campos multivalorados e devolve uma lista limpa. Em volumes altos, alternativas incluem o CertSpotter, da SSLMate, com API dedicada a monitoramento contínuo, e o Censys, que indexa certificados junto com a infraestrutura observada na Internet.

# Todos os nomes emitidos em certificados publicos para o dominio alvo
curl -s "https://crt.sh/?q=%25.exemplo-alvo.com.br&output=json" \
  | jq -r '.[].name_value' \
  | sed -e 's/\\n/\n/g' -e 's/^\*\.//' \
  | tr '[:upper:]' '[:lower:]' | sort -u

# Certificados emitidos nas ultimas 72 horas com o nome da organizacao no CN
curl -s "https://crt.sh/?q=MinhaOrganizacao&output=json" \
  | jq -r --arg janela "$(date -d '3 days ago' +%Y-%m-%d)" \
      '.[] | select(.not_before >= $janela)
      | [.not_before, .common_name, .issuer_name] | @tsv' \
  | sort -r | head -n 20

A tabela abaixo compara as fontes de pesquisa que compõem o kit mínimo do analista de infraestrutura.

O resultado bruto exige as mesmas higiene de qualquer fonte OSINT. Registros antigos permanecem nos logs para sempre, então a data de emissão, o campo not_before, precisa entrar no filtro de relevância. Domínios de terceiros que incluem a marca, como provedores de e-mail marketing, produzem falsos positivos, e o CNAME órfão descoberto via CT pode ser legado e não ataque. A nota de Domínios e Subdomínios detalha a triagem desses resultados e a distinção entre ativo órfão e infraestrutura do adversário.

5. Impressão Digital de Handshake: JA3, JA3S e JA4

Enquanto o certificado identifica o servidor, o fingerprint do handshake identifica o cliente e a pilha de software envolvida na conexão. O JA3, proposto pela equipe do Salesforce em 2017, calcula um hash MD5 sobre a tupla formada pela versão TLS, pela lista de cifras, pelas extensões, pelas curvas elípticas e pelos formatos de ponto do Client Hello. Como cada biblioteca TLS e cada malware têm configurações de handshake típicas, o hash agrupa conexões pelo software que as originou. O JA3S complementa com o hash do Server Hello, capturando a resposta do servidor e ajudando a caracterizar o par cliente e servidor.

O JA3 envelheceu por razões técnicas documentadas: navegadores passaram a randomizar a ordem de extensões e cifras justamente para frustrar fingerprints, o GREASE inseria valores fictícios e o suporte a Encrypted Client Hello obscurece parte do handshake. O JA4, publicado pelo projeto aberto JA4+ da FoxIO, corrige esses problemas ordenando as extensões de forma canônica, ignorando GREASE e adicionando leitura humana ao formato. Uma impressão JA4 tem a forma t13d1516h2_8daaf6152771_b186095e22b6, na qual o primeiro segmento descreve protocolo, versão, contagens e presença de SNI e ALPN, e os dois hashes finais separam cifras e extensões. A suíte JA4+ estende a ideia a cabeçalhos HTTP (JA4H), resposta do servidor (JA4S), TCP (JA4T), certificados (JA4X) e SSH (JA4SSH).

O valor tático desse conjunto está no comportamento. Um beacon de malware escrito com uma biblioteca específica mantém o mesmo JA4 enquanto troca de domínio e de IP todas as noites, o que permite caçar a ferramenta em vez da instância. Na Pirâmide de Dor, isso corresponde a subir do nível de rede e artefatos para o nível de ferramentas. As tabelas abaixo resumem as três impressões.

Para referência de leitura, um JA3 puro é um hash MD5 de 32 caracteres, como 72a589da586844d7f0818ce684948eea, um valor clássico documentado pelo projeto original e associado ao cliente TLS do Meterpreter do Metasploit. O JA4, por sua vez, carrega contexto no próprio texto, e o prefixo t13d indica TCP, TLS 1.3 e presença do campo de domínio (SNI), o que permite triagem visual rápida antes de qualquer consulta. Essa legibilidade é deliberada: o projeto foi desenhado para caçadores que leem logs um a um tanto quanto para plataformas que enriquecem milhões de eventos por hora.

6. Certificados em Campanhas: Autofirmados, Gratuitos e Sinais de Fase

Três perfis de certificado dominam a infraestrutura adversária, e cada um produz sinais diferentes. O certificado autofirmado, assinado pelo próprio operador, é comum em servidores C2, em painéis de administração de malware e em infraestrutura interna do atacante, porque não depende de terceiros e não deixa registro público. Sua presença em um host externo com conteúdo legítimo é raridade, então o issuer coincidente com o subject em serviços expostos é sinal de investigação. O certificado de validação de domínio gratuito, dominado pela Let's Encrypt com validade curta de 90 dias, é o padrão do phishing moderno, e o par formado por domínio recém-registrado e certificado emitido no mesmo dia é um dos melhores preditores de campanha disponível em fonte aberta. O certificado pago com validação organizacional, por fim, aparece quando o adversário precisa de credibilidade visual prolongada, como em páginas de portal corporativo falso usadas por grupos de caça financeira.

A combinação desses perfis com metadados de emissão rende hipóteses concretas de hunting. Emissões em massa para o mesmo CN com SANs distintos indicam farm de phishing. Renovações frequentes em domínio de baixa idade indicam operação mantida. Uso do mesmo endereço de chave pública em domínios diferentes indica dono comum, e é um pivô sólido descrito na nota de Pivoting. Todos esses sinais são obtíveis sem tocar na rede alvo, apenas consultando CT e DNS passivo, o que preserva o sigilo da investigação.

7. Hunting de Rede com Dados de TLS

A telemetria de rede já carrega os campos discutidos aqui. O Zeek registra o certificado observado no arquivo ssl.log, com issuer, subject, SAN e validade, e os plugins da suíte JA4+ para Zeek e Suricata acrescentam as impressões de handshake aos logs em tempo real. No lado endpoint, o EDR moderno reporta a conexão com SNI e, em alguns produtos, com o JA3. A consulta abaixo exemplifica duas caçadas clássicas sobre um índice SIEM alimentado por Zeek.

// Caça 1: impressao JA3 que aparece em mais de 10 dominios distintos
// sinal de ferramenta reutilizada sobre infraestrutura giratoria
index=net sourcetype=zeek:ssl ja3=*
| stats dc(server_name) AS dominios, values(server_name) AS nomes by ja3
| where dominios > 10

// Caça 2: conexoes TLS validas para hosts com certificado autofirmado
// emitido fora das autoridades reconhecidas
index=net sourcetype=zeek:ssl
| search issuer="CN=*" subject="CN=*"
| where issuer=subject
| stats count by server_name, id.resp_h
| sort - count

A primeira caça encontra reuso de ferramenta e funciona mesmo quando o adversário gira domínios, porque a pilha TLS do malware é preguiçosa. A segunda encontra C2 e painéis escondidos em IP puro, cenário comum em servidores C2 de malware loader. Ambas devem rodar com histórico de semanas, e não apenas no dia, porque a infraestrutura adversária tem ciclo de vida próprio.

No endpoint, a mesma ideia se aplica quando o EDR expõe o destino das conexões de processo. A consulta abaixo busca processos que conversam com domínios registrados há menos de sete dias, cruzando telemetria de rede com a idade do domínio coletada por enriquecimento, padrão típico de beacon recém-configurado.

// Processos conectando a dominios muito jovens, com base em enriquecimento
DeviceNetworkEvents
| where RemotePort == 443 and isnotempty(RemoteUrl)
| summarize Conexoes = count(), Processos = dcount(InitiatingProcessFileName)
    by RemoteUrl, DeviceId
| where Conexoes >= 3
| project RemoteUrl, DeviceId, Processos, Conexoes

8. Erros Comuns e Pontos de Atenção

• Tratar CT como inventário atual: os logs guardam todo o histórico, então a consulta sem filtro de data mistura emissões de anos atrás com a infraestrutura viva; filtre por not_before e compare com a idade do registro DNS.
• Atribuir por emissor comum: certificados gratuitos da mesma autoridade compartilham issuer por construção, e o Issuer sozinho não é pivô; o pivô é o par chave pública e CN, não a autoridade.
• Ignorar certificados curinga: um certificado para *.exemplo.com.br esconde todos os subdomínios daquele emissor, e a enumeração por CT fica cega para eles; complemente com DNS ativo e DNS passivo.
• Confundir JA3 com identidade de atacante: o hash identifica a biblioteca, e bibliotecas populares produzem hashes compartilhados por milhares de hosts benignos; use JA3 e JA4 como filtro de clustering, nunca como evidência única de atribuição.
• Confiar em impressões com GREASE e randomização: JA3 coletado de navegadores modernos varia por sessão; quando a telemetria permitir, padronize a operação em JA4 e na suíte JA4+.
• Esquecer o certificado no pivô: analistas coletam IP e domínio e descartam o certificado; o SAN e a chave pública estão no log que o próprio adversário entregou, e são dos pivôs mais resistentes à rotação.

9. Integração com o Restante da Biblioteca

Os campos de certificado alimentam diretamente a nota de Pivoting e Correlação de Infraestrutura, na qual o SAN e a chave pública aparecem como pivôs de alta robustez, e a nota de Domínios e Subdomínios, que usa CT como fonte primária de enumeração. A impressão JA4 conecta esta nota ao nível de ferramentas da Pirâmide de Dor e às consultas de hunting de rede descritas nos controles TH.11 e TH.12 da seção 15. O monitoramento de marca por CT, com alerta de emissão contendo o nome da organização, é o caso de uso central do controle INS.4 e do exemplo ponta a ponta do INT.3.

A próxima integração natural é temporal: um pipeline que acompanha as emissões de CT diariamente e cruza com a idade do registro no DNS produz uma fila de domínios recém-ativados com certificado novo, que é a matéria-prima para hipóteses de hunting orientadas por inteligência do TH.6. Nessa esteira, a nota seguinte sobre Hosting e CDN responde a pergunta que o certificado não responde: quem realmente hospeda o servidor por trás do nome.