Ataque à DigiCert: o que o abuso de certificados EV de assinatura de código revela

Em outras palavras: malware assinado continua sendo malware. A diferença é que ele pode parecer menos suspeito no primeiro olhar.

Como o ataque saiu do chat e chegou aos certificados

O ponto de entrada foi engenharia social contra o suporte. A Help Net Security resume o núcleo do caso da mesma forma: um arquivo ZIP que parecia conter uma captura de tela de cliente trazia, na verdade, um arquivo .scr malicioso .

De acordo com a SecurityWeek, a malware infectou dois endpoints: um foi identificado em 3 de abril, e outro em 14 de abril . A partir de um sistema comprometido, os invasores teriam avançado para um portal interno de suporte . Esse portal oferecia uma função limitada que permitia a analistas autenticados da DigiCert acessar contas de clientes; por essa função, era possível chegar a recursos específicos, incluindo códigos de inicialização de certificados pendentes .

A BleepingComputer também descreve o escopo como limitado, mas detalha que o acesso expôs códigos de inicialização de certificados EV de assinatura de código que já tinham sido aprovados, porém ainda não entregues .

A leitura importante aqui é que o ataque não precisou começar por uma chave criptográfica mestra. Ele explorou uma etapa operacional do processo de suporte e emissão de certificados.

O alvo real era a confiança

A consequência mais séria não foi apenas o acesso a um portal interno. Foi o uso da confiança de certificados válidos como cobertura para malware.

A ThreatNoir afirma que alguns dos certificados de assinatura de código obtidos foram usados para assinar malware . A CyberInsider também descreve um incidente em que sistemas internos de suporte foram comprometidos e dados de emissão de certificados foram abusados para obter certificados EV válidos de assinatura de código, sendo alguns deles usados posteriormente para assinar malware .

Para equipes de segurança, isso muda a triagem. Uma assinatura válida pode enriquecer a análise, mas não deve encerrar a discussão. Se a política de defesa trata todo binário EV-assinado como confiável por padrão, um atacante pode transformar justamente esse atalho em vantagem .

O que os relatos não comprovam

Há uma distinção importante: as fontes disponíveis falam de endpoints de suporte comprometidos, funções internas de portal e acesso a códigos de inicialização . Elas não indicam comprometimento de chaves raiz da DigiCert nem de chaves de autoridade certificadora.

Isso não torna o incidente pequeno ou irrelevante. Significa apenas que, pelo que foi relatado, o caso é melhor entendido como abuso de um processo de suporte e emissão ligado a certificados de assinatura de código, não como tomada completa da autoridade certificadora .

Qual foi o tamanho do dano?

Os números públicos variam porque as fontes parecem tratar categorias diferentes:

• A ThreatNoir fala em um número limitado de certificados de assinatura de código, dos quais alguns foram usados para assinar malware .
• A Risky Business relata 27 certificados de assinatura de código roubados e posteriormente usados para assinar malware .
• A ThreatLocker menciona 60 certificados de assinatura de código revogados no total .

A diferença entre certificados obtidos, usados e revogados é relevante. Para a defesa, porém, o ponto prático é o mesmo: mesmo poucos certificados aparentemente legítimos podem bastar para dar mais credibilidade a uma campanha maliciosa e dificultar a detecção baseada apenas em assinatura .

A resposta: revogação e cancelamento de pedidos pendentes

Segundo a BleepingComputer, a DigiCert revogou os certificados identificados em até 24 horas após a descoberta e definiu a data de revogação como a própria data de emissão . Pedidos pendentes dentro da janela afetada também foram cancelados como medida de precaução . A ThreatNoir relata a mesma linha de contenção: revogação dos certificados afetados em até 24 horas e anulação de pedidos pendentes no período de interesse .

Revogar limita o uso futuro dos certificados, mas não elimina o trabalho das equipes de resposta. Arquivos assinados ainda precisam ser avaliados com base em dados do certificado, hashes, comportamento, conexões de rede, mecanismos de persistência e contexto de inteligência de ameaças. A assinatura é um dado da análise, não uma absolvição automática .

O ruído extra: falsos positivos no Microsoft Defender

Como se o caso já não fosse delicado, houve ainda confusão com alertas do Microsoft Defender. A BleepingComputer informou que o Defender passou a marcar certificados da DigiCert incorretamente como Trojan:Win32/Cerdigent.A!dha . O daily.dev resumiu que certificados raiz legítimos da DigiCert foram sinalizados de forma errada após uma atualização de assinatura em 30 de abril; depois, a Microsoft teria corrigido o problema com a atualização de inteligência de segurança 1.449.430.0, restaurando certificados removidos .

Na prática, isso criou um problema operacional clássico de resposta a incidentes: separar abuso real de certificado, possíveis amostras de malware assinadas e falsos positivos contra certificados legítimos .

Lições para equipes de segurança

A conclusão não é que assinatura de código deixou de ter valor. A lição é que ela não pode ser o único critério de confiança.

• Assinatura deve ser verificada, não obedecida cegamente. Uma assinatura válida, mesmo EV, não garante que o arquivo seja seguro; atacantes podem usar certificados EV para assinar arquivos maliciosos e se aproveitar da confiança associada a eles .
• Detalhes do certificado importam. Emissor, número de série, cadeia de certificação, carimbo de tempo e status de revogação devem entrar na análise. No caso da DigiCert, a revogação e a data de revogação ajustada para a data de emissão foram parte central da contenção .
• Comportamento do arquivo precisa pesar mais. Hashes, processos criados, conexões externas, persistência e resultados de sandbox ajudam a diferenciar software legítimo de malware que só parece confiável porque está assinado .
• Portais de suporte também são zonas críticas. O incidente mostra que uma função aparentemente limitada pode se tornar sensível quando permite acessar contas de clientes ou códigos de inicialização de certificados .
• Falsos positivos exigem processo, não pânico. Os alertas do Defender mostram que uma detecção envolvendo certificados não significa automaticamente infecção real; certificados raiz legítimos da DigiCert foram sinalizados de forma incorreta e depois restaurados por atualização da Microsoft .

Em resumo

O caso da DigiCert é relevante porque atacou a confiança, não apenas um sistema. Os relatos apontam para um incidente limitado envolvendo suporte, códigos de inicialização e certificados EV de assinatura de código usados indevidamente, sem evidência pública de comprometimento de chaves raiz ou de CA . Ainda assim, a mensagem para a defesa é direta: em malware moderno, assinatura digital é pista — não veredito.