Auditoria de Logs de Transparência de Certificados TLS

O que Auditoria de Logs de Transparência de Certificados TLS faz?

Quando Usar

• Monitorar domínios próprios quanto à emissão não autorizada ou inesperada de certificados por Autoridades Certificadoras desconhecidas
• Descobrir subdomínios e serviços ocultos por meio de certificados registrados em logs CT públicos
• Detectar infraestrutura de phishing que usa certificados de domínios semelhantes (typosquatting, ataques homógrafos)
• Auditar a conformidade de Autoridades Certificadoras, verificando se todos os certificados emitidos aparecem nos logs CT, conforme exigido pelas políticas dos navegadores
• Construir monitoramento contínuo de certificados em um pipeline de operações de segurança com alertas para novas emissões

Não use para atacar ou interromper Autoridades Certificadoras, para raspar logs CT violando limites de taxa ou termos de serviço, ou como método único de enumeração de subdomínios sem corroborar resultados por meio de verificação DNS.

Pré-requisitos

• Python 3.10+ com as bibliotecas requests, cryptography e pyOpenSSL instaladas
• Acesso de rede a crt.sh (HTTPS) e servidores públicos de log CT
• Uma lista de domínios para monitorar (domínios próprios, variações de marca, candidatos a typosquat)
• Credenciais SMTP ou URL de webhook para alertar sobre novas descobertas de certificados
• Compreensão básica da estrutura de certificados X.509 e validação de cadeia de certificados TLS

Fluxo de Trabalho

Passo 1: Inventário de Domínios e Linha de Base

Construa o inventário inicial de certificados para os domínios monitorados:

• Definir escopo de monitoramento: Liste todos os domínios raiz próprios, nomes de marcas registradas e subsidiárias conhecidas. Inclua padrões curinga (%.exemplo.com) para cobertura abrangente de subdomínios.
• Consultar crt.sh para certificados históricos: Use a API JSON do crt.sh para recuperar todos os certificados conhecidos para cada domínio. O endpoint da API https://crt.sh/?q=%.exemplo.com&output=json retorna certificados correspondentes ao padrão curinga com campos incluindo issuer_ca_id, issuer_name, common_name, name_value, not_before, not_after e serial_number.
• Construir banco de dados de linha de base: Armazene o conjunto inicial de certificados em um banco de dados SQLite local com colunas para ID do certificado, domínio, emissor, datas de validade, SANs (Nomes Alternativos do Sujeito) e timestamp da primeira visualização. Essa linha de base evita alertas sobre certificados já conhecidos.
• Identificar ACs autorizadas: A partir da linha de base, extraia o conjunto de Autoridades Certificadoras que emitiram legitimamente certificados para seus domínios. Qualquer emissão futura de uma AC que não esteja neste conjunto dispara um alerta de alta prioridade.
• Mapear subdomínios: Extraia todos os subdomínios exclusivos do campo name_value em todos os certificados para construir um inventário inicial de subdomínios.

Passo 2: Monitoramento Contínuo de Logs CT

Configure o monitoramento contínuo para novas emissões de certificados:

• Consultar crt.sh periodicamente: Consulte a API crt.sh em intervalos regulares (a cada 15-60 minutos) para novos certificados. Use o parâmetro exclude=expired para focar em certificados atualmente válidos. Compare os resultados com o banco de dados de linha de base para identificar novas entradas.
• Analisar detalhes do certificado: Para cada novo certificado, extraia a lista completa de SANs, cadeia de emissor, período de validade, tipo e tamanho da chave, detalhes do SCT (Timestamp do Certificado Assinado) do log CT e impressão digital do certificado (SHA-256).
• Detectar pré-certificados: Os logs CT incluem pré-certificados (certificados envenenados submetidos antes da emissão final). Rastreie-os como avisos antecipados, pois indicam que um certificado está prestes a ser emitido, mas pode não estar ativo ainda.
• Monitorar Cabeças de Árvore Assinadas (STH) do log CT: Para monitoramento avançado, consulte servidores de log CT diretamente para obter o STH mais recente e verificar provas de consistência entre cabeças de árvore consecutivas. Uma inconsistência indica mau comportamento do log (ataque de visão dividida).
• Consciência de limitação de taxa: Respeite os limites de taxa do crt.sh espaçando as consultas e armazenando respostas em cache. Implemente backoff exponencial em respostas HTTP 429. Para monitoramento de alto volume, considere consultar a interface PostgreSQL do crt.sh diretamente em crt.sh:5432.
• Alternativa de feed Atom/RSS: Inscreva-se no feed Atom do crt.sh para monitoramento mais leve: https://crt.sh/atom?q=%25.exemplo.com fornece notificação em tempo real de novas entradas de log.

Passo 3: Descoberta de Subdomínios via Dados CT

Extraia e valide subdomínios encontrados em dados de transparência de certificados:

• Expansão de curinga: Certificados com SANs curinga (*.dev.exemplo.com) revelam a existência de subdomínios que podem não estar em arquivos de zona DNS. Registre o domínio pai como alvo para enumeração adicional.
• Mineração de certificados históricos: Consulte crt.sh sem o parâmetro exclude=expired para encontrar subdomínios de certificados expirados que ainda podem resolver no DNS. Eles representam infraestrutura histórica que pode ser vulnerável a subdomain takeover.
• Validação DNS: Para cada subdomínio descoberto, realize resolução DNS (registros A, AAAA, CNAME) para determinar se o subdomínio está atualmente ativo. Faça referência cruzada com faixas de IP conhecidas para identificar TI paralela ou serviços não autorizados.
• Detecção de typosquat: Gere permutações do domínio monitorado (bitsquatting, homógrafo, inserção, omissão, transposição, substituição adjacente ao teclado) e consulte logs CT para certificados emitidos para essas variações. Certificados para domínios typosquat indicam fortemente infraestrutura de phishing.
• Deduplicação e enriquecimento: Normalize subdomínios descobertos (minúsculas, remova pontos finais), deduplique e enriqueça com dados WHOIS, geolocalização de IP e cabeçalhos de resposta HTTP para priorizar a investigação.

Passo 4: Alertas de Emissão de Certificados

Configure regras de alerta para eventos de certificados relevantes para segurança:

• Alerta de AC não autorizada: Dispare quando um certificado for emitido por uma AC que não está na lista de ACs autorizadas. Este é o alerta de maior prioridade, pois pode indicar sequestro de domínio, sequestro de BGP para validação de domínio ou uma AC comprometida.
• Alerta de novo subdomínio: Dispare quando um certificado contiver uma SAN com um subdomínio nunca antes visto. Isso captura implantações de TI paralela e serviços não autorizados.
• Alerta de certificado curinga: Dispare em qualquer nova emissão de certificado curinga, pois certificados curinga têm impacto mais amplo se comprometidos e sua emissão deve ser rigidamente controlada.
• Anomalia de certificado de curta duração: Alerte quando certificados tiverem períodos de validade excepcionalmente curtos (menos de 24 horas) que se desviam do ciclo de vida normal de certificados da organização, pois isso pode indicar abuso do Let's Encrypt ou infraestrutura automatizada de phishing.
• Aviso de expiração: Alerte quando certificados para serviços críticos se aproximarem da expiração (30, 14, 7 dias) com base no campo not_after dos dados do log CT.
• Entrega de alertas: Envie alertas por e-mail (SMTP), webhook do Slack, PagerDuty ou grave em um formato de log JSON compatível com SIEM para integração com o monitoramento de segurança existente.

Passo 5: Verificação de Integridade do Log CT e Relatórios

Verifique a integridade do log e produza evidências de conformidade:

• Monitoramento de Cabeça de Árvore Assinada (STH): Obtenha o STH mais recente de cada log CT monitorado por meio do endpoint da API get-sth. O STH contém o tamanho da árvore e um timestamp assinado. Verifique a assinatura usando a chave pública do log.
• Verificação de prova de consistência: Entre buscas consecutivas de STH, solicite uma prova de consistência por meio de get-sth-consistency para verificar se o log permanece somente em anexo e se nenhuma entrada foi modificada ou removida.
• Relatório de inventário de certificados: Produza um inventário completo de todos os certificados emitidos para domínios monitorados, agrupados por emissor, com status de validade e métricas de força da chave.
• Análise de diversidade de ACs: Relate quantas ACs diferentes emitem certificados para a organização, identificando oportunidades de consolidação e pontos únicos de falha.
• Evidência de conformidade: Para organizações sujeitas a PCI-DSS, SOC 2 ou estruturas semelhantes, os logs de monitoramento CT fornecem evidências de gerenciamento do ciclo de vida de certificados e capacidades de detecção de emissão não autorizada.

Conceitos-chave

Termo	Definição
Transparência de Certificados (CT)	Uma estrutura aberta (RFC 6962) que exige que as Autoridades Certificadoras registrem todos os certificados emitidos em logs publicamente auditáveis e somente em anexo, permitindo que proprietários de domínios detectem emissão não autorizada
Timestamp do Certificado Assinado (SCT)	Uma promessa de um log CT de que um certificado será incluído dentro do Atraso Máximo de Mesclagem (tipicamente 24 horas); os navegadores exigem SCTs de vários logs antes de confiar em um certificado
Árvore de Merkle	A estrutura de dados criptográfica usada por logs CT onde nós folha são hashes de certificados e nós pai são hashes de seus filhos, permitindo provas eficientes de consistência e inclusão
Pré-certificado	Um certificado submetido a logs CT antes da emissão final, contendo uma extensão de veneno (OID 1.3.6.1.4.1.11129.2.4.3) que impede seu uso para TLS, mas reserva seu lugar no log
crt.sh	Um serviço web gratuito operado pela Sectigo que agrega certificados de todos os principais logs CT em um banco de dados PostgreSQL pesquisável, fornecendo acesso web e API
Subdomain Takeover	Uma vulnerabilidade onde um registro DNS de um subdomínio aponta para um serviço descomissionado (provedor de nuvem, CDN) que um atacante pode reivindicar, tornado descoberto por meio de certificados CT expirados
Atraso Máximo de Mesclagem (MMD)	O tempo máximo (tipicamente 24 horas) que um log CT tem para incorporar um certificado submetido em sua árvore de Merkle após retornar um SCT
Registro CAA	Registro de Autorização de Autoridade Certificadora DNS que especifica quais ACs têm permissão para emitir certificados para um domínio; o monitoramento CT detecta violações da política CAA

Ferramentas e Sistemas

• crt.sh: Agregador primário de logs CT que fornece acesso à API JSON em https://crt.sh/?q=<consulta>&output=json com suporte para consultas curinga, filtragem de identidade e recuperação de detalhes do certificado
• ct-woodpecker: Ferramenta de código aberto de monitoramento de logs CT do Let's Encrypt que se integra com Prometheus e Grafana para monitoramento operacional da saúde e consistência do log
• certspotter: Monitor de logs CT da SSLMate que observa certificados recém-emitidos e envia notificações; disponível como serviço hospedado ou ferramenta auto-hospedada
• Google Argon / Xenon / Icarus: Logs CT operados pelo Google que são dos mais amplamente utilizados, consultáveis por meio da API RFC 6962 em seus respectivos URLs de log
• OpenSSL: Ferramenta de linha de comando para analisar detalhes de certificados, verificar cadeias e extrair listas de SANs de certificados recuperados por meio de monitoramento CT

Cenários Comuns

Cenário: Detectando Emissão Não Autorizada de Certificado para uma Empresa de Serviços Financeiros

Contexto: Um banco monitora seu domínio principal (banco.exemplo.com) e descobre, por meio de logs CT, que um certificado foi emitido por uma AC que eles nunca usaram, cobrindo secure-login.banco.exemplo.com -- um subdomínio que não existe em seu DNS.

Abordagem:

1. O agente de monitoramento CT detecta um novo certificado da "FreeSSL CA" para secure-login.banco.exemplo.com nos resultados do crt.sh, que não está na lista de ACs autorizadas (DigiCert, Sectigo)
2. Alerta dispara como AC não autorizada + novo subdomínio, escalando para a equipe de segurança dentro de 15 minutos da entrada no log CT
3. Investigue o certificado: extraia a chave pública, verifique se o domínio foi validado via desafio HTTP-01 ou DNS-01, consulte WHOIS para a organização emissora
4. A consulta DNS para secure-login.banco.exemplo.com revela que ele resolve para um endereço IP em um provedor de hospedagem não usado pelo banco -- confirmando que é infraestrutura do atacante
5. Inicie a resposta a incidentes: solicite revogação do certificado à FreeSSL CA, registre um relatório de abuso de domínio, adicione o IP a listas de bloqueio e notifique a equipe anti-phishing
6. Implemente registros DNS CAA (banco.exemplo.com. CAA 0 issue "digicert.com") para impedir que ACs não autorizadas emitam certificados futuros

Armadilhas:

• Não monitorar padrões curinga (%.banco.exemplo.com) e perder certificados para subdomínios
• Ignorar pré-certificados que aparecem nos logs CT antes da emissão do certificado real, perdendo a vantagem do aviso antecipado
• Não verificar se os registros CAA estão configurados corretamente em todos os domínios após um incidente
• Alertar excessivamente sobre renovações legítimas de certificados porque o banco de dados de linha de base não foi atualizado após alterações autorizadas

Cenário: Mapeamento de Superfície de Ataque Através da Descoberta de Subdomínios por Log CT

Contexto: Um testador de penetração usa logs CT como a primeira fase de reconhecimento externo para mapear os serviços voltados para a internet da organização alvo antes da varredura ativa.

Abordagem:

1. Consulte crt.sh para %.alvo.com e todos os domínios de subsidiárias conhecidas, coletando 2.400 certificados exclusivos em 8 anos
2. Extraia 347 subdomínios exclusivos dos campos SAN de todos os certificados, incluindo os expirados
3. Resolva via DNS todos os 347 subdomínios, encontrando 189 atualmente ativos com registros A/AAAA
4. Identifique 12 subdomínios apontando para serviços de nuvem descomissionados (CNAME para buckets S3, endpoints Azure) que são candidatos a subdomain takeover
5. Descubra staging-api.alvo.com e dev-portal.alvo.com que não estão no escopo documentado do alvo, mas são acessíveis e executam versões de software mais antigas
6. Apresente as descobertas à organização alvo, mostrando a lacuna entre seu inventário de ativos conhecido e a superfície de ataque derivada do CT

Armadilhas:

• Assumir que todos os subdomínios descobertos por CT estão no escopo sem confirmar com o proprietário do ativo
• Não verificar respostas DNS curinga que fazem parecer que subdomínios existem quando eles resolvem para um catch-all
• Confiar apenas em dados CT sem fazer referência cruzada com bancos de dados DNS passivos para cobertura abrangente

Formato de Saída

## Relatório de Monitoramento de Log CT

**Domínio**: exemplo.com
**Período de Monitoramento**: 2026-03-01 a 2026-03-19
**Total de Certificados Rastreados**: 142
**Novos Certificados Detectados**: 7
**Alertas Gerados**: 2

### Alerta: Emissão por AC Não Autorizada
- **Severidade**: Crítica
- **CN do Certificado**: secure-login.exemplo.com
- **SANs**: secure-login.exemplo.com,

...

[truncado para tradução]