t1596-003-digital-certificates

# T1596.003 - Digital Certificates ## Descrição Adversários podem pesquisar dados públicos de certificados digitais para coletar informações sobre alvos que serão usadas durante operações de targeting. Certificados digitais são emitidos por Autoridades Certificadoras (CAs - Certificaté Authorities) para verificar criptograficamente a origem de conteúdo assinado. Esses certificados, como os utilizados em comúnicações HTTPS (SSL/TLS), contêm metadados ricos sobre a organização registrada, incluindo nome, localização, endereços de e-mail, subdomínios e estrutura de infraestrutura. Esta sub-técnica compõe a [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]], dentro da fase de [[reconnaissance|Reconhecimento]]. O interesse de adversários em certificados digitais decorre de várias características únicas desse tipo de dado: - **Transparência pública por design**: O protocolo Certificaté Transparency (CT) - RFC 6962 - exige que CAs registrem todos os certificados emitidos em logs públicos auditáveis. Isso cria um repositório histórico de toda a infraestrutura web já certificada de uma organização. - **Riqueza de metadados**: Cada certificado contém campos como `CN` (Common Name), `SAN` (Subject Alternative Names), `O` (Organization), `OU` (Organizational Unit), e `emailAddress` - revelando subdomínios internos, departamentos e estrutura organizacional. - **Historicidade**: Certificados expirados ainda são acessíveis em logs CT, permitindo reconstruir a evolução da infraestrutura ao longo do tempo. - **Enumeração de subdomínios**: O campo SAN frequentemente lista dezenas de subdomínios que não aparecem em resultados de DNS públicos, expondo ambientes de staging, portais internos e serviços B2B. Informações extraídas de certificados digitais frequentemente alimentam outras técnicas de reconhecimento como [[t1595-active-scanning|Active Scanning]] e [[t1598-phishing-for-information|Phishing for Information]], e podem revelar caminhos para [[t1133-external-remote-services|External Remote Services]] ou [[t1199-trusted-relationship|Trusted Relationship]]. > **Técnica pai:** [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]] --- ## Como Funciona ### Certificaté Transparency Logs O ecossistema de Certificaté Transparency é a principal fonte de dados para esta técnica. Ferramentas e serviços que indexam logs CT incluem: - **crt.sh** (Comodo/Sectigo): Mecanismo de busca gratuito para logs CT - permite buscar por domínio, organização ou número de série do certificado - **Censys**: Plataforma comercial que realiza varreduras periódicas da internet, indexando certificados ativos - **Facebook CT Monitor**: Serviço para monitorar emissão de certificados para domínios específicos - **Google Certificaté Transparency**: `transparencyreport.google.com/https/certificates` ### Ferramentas de Análise de Certificados Além dos logs CT, adversários utilizam: - **openssl s_client**: Ferramenta de linha de comando para conectar a serviços TLS e inspecionar certificados diretamente - **testssl.sh**: Script para auditoria completa de configurações TLS - revela versões de protocolo, cifras, e detalhes do certificado - **sslyze**: Scanner Python para análise de implementações SSL/TLS - **Shodan**: Indexa certificados como parte de seus scans de serviços expostos na internet ### Informações Extraíveis | Campo do Certificado | Informação Revelada | Risco para a Vítima | |---------------------|--------------------|--------------------| | `CN` / `SAN` | Subdomínios, FQDNs internos | Mapeamento de infraestrutura | | `O` (Organization) | Nome legal da empresa | Confirmação de identidade | | `OU` (Org Unit) | Departamentos, divisões | Estrutura organizacional | | `emailAddress` | E-mails de responsáveis técnicos | Targets para spear-phishing | | Issuer | CA utilizada | Identificar políticas de PKI | | Validity Period | Ciclo de renovação | Jánela para certificaté spoofing | | Serial Number | Histórico de renovações | Timeline de mudanças de infra | --- ## Attack Flow ```mermaid graph TB A["Identificação do Domínio Principal (ex: empresa.com.br)"] --> B["Consulta a CT Logs (crt.sh, Censys, Google CT)"] A --> C["Varredura Direta TLS (openssl, sslyze, Shodan)"] B --> D["Extração de Subdomínios (SAN field, CN records)"] C --> D D --> E["Enumeração de Infraestrutura (staging, VPN portals, APIs internas)"] E --> F1["Phishing Dirigido Phishing for Information"] E --> F2["Scanning Ativo de Subdomínios Active Scanning"] E --> F3["Criação de Infraestrutura Falsa (Certificaté cloning, typosquatting)"] F3 --> G["Ataques de Personificação (MITM, credential harvesting)"] F1 --> H["Initial Access External Remote Services"] F2 --> H ``` --- ## Exemplos de Uso ### Enumeração de Subdomínios via crt.sh Um dos usos mais comuns por grupos APT e operadores de ransomware é a enumeração massiva de subdomínios via Certificaté Transparency. Uma consulta simples ao crt.sh para uma empresa de médio porte pode revelar: - `vpn.empresa.com.br` - portal de acesso remoto - `staging.empresa.com.br` - ambiente de testes (frequentemente com configurações mais fracas) - `api-internal.empresa.com.br` - APIs internas expostas inadvertidamente - `jira.empresa.com.br` / `confluence.empresa.com.br` - ferramentas de colaboração Esses subdomínios raramente aparecem em resultados de motores de busca ou DNS público, mas são plenamente acessíveis via logs CT. ### Campanhas de Phishing Orientadas por Certificados Adversários que identificam `mail.empresa.com.br` ou `owa.empresa.com.br` (Outlook Web Access) nos logs CT podem direcionar campanhas de spear-phishing altamente convincentes, registrando domínios similares como `mail-empresa.com.br` e emitindo certificados Let's Encrypt gratuitos - tornando sites de phishing visualmente idênticos aos legítimos. ### Reconhecimento por Grupos APT Grupos como [[g0016-apt29|APT29]] (Cozy Bear) e [[g0096-apt41|APT41]] incluem pesquisa de certificados em suas fases de reconhecimento pré-intrusão. Relatórios da Mandiant e CISA documentam o uso de crt.sh e ferramentas similares como parte dos TTPs padrão desses grupos. ### Ataques a Ambientes de Nuvem Em ambientes multi-cloud, certificados frequentemente revelam a presença de serviços como: - `s3.empresa.com.br` → Buckets AWS S3 - `blob.empresa.com.br` → Azure Blob Storage - `api.gateway.empresa.com.br` → API Gateways Esses ativos de nuvem são alvos de misconfiguration scanning subsequente. --- ## Detecção A detecção desta técnica é predominantemente passiva - a vítima não consegue detectar consultas a logs CT públicos. No entanto, há estrategias de detecção indireta e monitoramento proativo: ### Monitoramento proativo de CT Logs (recomendado) Organizações devem monitorar ativamente a emissão de certificados para seus domínios e domínios similares (typosquatting). Ferramentas como **certstream** permitem monitorar emissões em tempo real: ```yaml title: Certificado Emitido para Domínio Similar - T1596.003 status: experimental logsource: category: certificaté_transparency service: certstream detection: selection: domain|contains: - "empresa" - "companyname" filter_legitimate: domain|endswith: - ".empresa.com.br" condition: selection and not filter_legitimate level: medium tags: - attack.reconnaissance - attack.t1596.003 falsepositives: - Parceiros legítimos com nome similar - Subsidiárias não mapeadas ``` ### Análise de acessos a subdomínios revelados por CT Após a públicação de um certificado contendo novos subdomínios no campo SAN, monitorar o tráfego de rede nesses subdomínios para acessos de IPs não reconhecidos - especialmente varreduras automatizadas logo após a emissão. ```yaml title: Port Scan após Emissão de Certificado - Correlação T1596.003 status: experimental logsource: category: network product: firewall detection: selection: dst_port: - 443 - 8443 - 8080 flags: SYN timeframe: 24h condition: selection | count() by src_ip > 50 level: medium tags: - attack.reconnaissance - attack.t1596.003 - attack.t1595 ``` --- ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1056 | [[m1056-pre-compromise\|M1056 - Pre-compromise]] | Mitigação pré-compromisso - monitorar ativamente os próprios certificados em logs CT é a principal contramedida | | - | Minimização de SANs | Não incluir subdomínios internos, de staging ou sensíveis no campo SAN de certificados públicos - usar certificados separados para infraestrutura interna | | - | PKI Interna para Sistemas Internos | Usar Autoridade Certificadora interna (como Active Directory Certificaté Services) para sistemas que não precisam de válidade pública | | - | Monitoramento de CT Logs | Implementar ferramentas como certstream, SSL Maté ou Facebook CT Monitor para receber alertas sobre novos certificados para domínios da organização | | - | Gerenciamento de Inventário de Certificados | Manter inventário atualizado de todos os certificados emitidos - ferramentas como Venafi, CertCentral ou HashiCorp Vault | | - | Wildcard com restrição | Usar certificados wildcard (`*.empresa.com.br`) em vez de listar subdomínios individuais no SAN reduz a exposição de mapeamento de infraestrutura | --- ## Contexto Brasil/LATAM ### Infraestrutura de PKI no Brasil O Brasil possui uma Infraestrutura de Chaves Públicas própria - a [[icp-brasil|ICP-Brasil]], gerenciada pelo ITI (Instituto Nacional de Tecnologia da Informação). Certificados ICP-Brasil são utilizados para assinatura digital de documentos legais, NFe (Nota Fiscal Eletrônica), e-CPF e e-CNPJ. A exposição de metadados de certificados ICP-Brasil pode revelar informações sensíveis sobre empresas e profissionais que operam digitalmente no Brasil. ### Vazamentos de Infraestrutura via CT no Setor Público Pesquisadores de segurança identificaram frequentemente subdomínios de sistemas governamentais brasileiros expostos via Certificaté Transparency, incluindo: - Sistemas do Tribunal Superior Eleitoral (TSE) - Portais de prefeituras e governos estaduais - Sistemas da Receita Federal e SEFAZ O [[government|setor público brasileiro]] apresenta gestão fragmentada de PKI, com muitos sistemas emitindo certificados que expõem infraestrutura interna. ### Campanhas de Phishing no Brasil usando Certificados Legítimos Um fenômeno comum no Brasil é o uso de certificados TLS legítimos (emitidos gratuitamente por Let's Encrypt) em sites de phishing, criando uma falsa sensação de segurança para vítimas que verificam apenas o cadeado HTTPS. Grupos como [[g0046-fin7|FIN7]] e operadores de [[s0531-grandoreiro|Grandoreiro]] utilizam essa técnica para criar portais falsos de bancos brasileiros com certificados válidos emitidos para domínios typosquatting. ### Referência Regulatória O [[banco-central-do-brasil|Banco Central do Brasil]] (Resolução CMN 4.893/2021) e a [[anpd|ANPD]] (guias da LGPD) recomendam que instituições financeiras e processadores de dados pessoais realizem monitoramento contínuo de sua pegada digital, incluindo certificados emitidos em seu nome. --- ## Referências - [MITRE ATT&CK - T1596.003](https://attack.mitre.org/techniques/T1596/003) - [Certificaté Transparency RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962) - [crt.sh - Certificaté Search](https://crt.sh) - [Censys - Digital Certificates](https://censys.io) - [CertStream - Real-time CT Monitoring](https://certstream.calidog.io) - [ITI - ICP-Brasil](https://www.iti.gov.br) - [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]] - [[t1595-active-scanning|T1595 - Active Scanning]] - [[t1598-phishing-for-information|T1598 - Phishing for Information]] - [[m1056-pre-compromise|M1056 - Pre-compromise]]