- O ataque começou onde quase ninguém olha 🔎
- O certificado não estava “quebrado” 🛡️
- Google diz que seus servidores não foram invadidos
- E o que acontece quando o certificado falso existe? ⚠️
- Mas o Google deixou um recado para donos de sites
- Não é a primeira vez que isso acontece
- O fantasma do Sea Turtle 🐢
- O problema é maior do que um certificado falso
- A internet continua dependendo do elo mais fraco
Principais destaques
- Três domínios foram comprometidos: invasores assumiram o controle de zonas DNS ligadas a .gh, .sl e .as e conseguiram obter certificados TLS não autorizados.
- Chrome já bloqueia os certificados: o Google atualizou o navegador e trabalhou com as autoridades certificadoras para revogar os certificados emitidos para seus domínios.
- O problema foi o DNS, não a criptografia: os atacantes exploraram o controle dos registros para passar pelas validações automáticas de domínio, sem precisar invadir a infraestrutura das empresas afetadas.
Um certificado de segurança deveria funcionar como um documento digital capaz de provar que você está realmente falando com o site que pensa estar acessando.
Mas, nesta semana, hackers encontraram uma maneira de conseguir documentos falsos.
O Google afirmou na terça-feira, 6 de outubro, que invasores assumiram o controle de três domínios de nível superior de código de país e usaram esse acesso para obter certificados TLS não autorizados para vários domínios da empresa, além de outras grandes marcas e serviços online.
Os domínios envolvidos são .gh, de Gana, .sl, de Serra Leoa, e .as, da Samoa Americana.
O ataque começou onde quase ninguém olha 🔎
O ponto central da história está no DNS.
Segundo o relato do Ars Technica, os invasores alteraram registros DNS autoritativos de domínios selecionados dentro dos três registros comprometidos. Com isso, conseguiram controlar temporariamente informações que indicavam para onde determinados domínios deveriam apontar.
E isso foi suficiente para enganar um mecanismo fundamental da segurança da internet.
🎯 A brecha estava na validação: autoridades certificadoras verificam se quem solicita um certificado consegue controlar determinado domínio. Ao assumir o controle do DNS, os invasores conseguiram responder aos desafios usados nessa validação.
Na prática, eles não precisaram invadir os servidores do Google.
Precisaram apenas fazer a internet acreditar, por algum tempo, que estavam no controle dos domínios necessários.
O certificado não estava “quebrado” 🛡️
Um certificado TLS associa criptograficamente um nome de domínio a uma chave pública.
É uma das peças que permitem ao navegador estabelecer uma conexão HTTPS e verificar a identidade do site.
O problema é que a validação de domínio tem uma limitação importante: ela comprova que alguém controla o domínio no momento em que a verificação é realizada.
Ela não consegue determinar, por si só, se aquela pessoa ou organização deveria estar controlando o domínio.
Foi exatamente essa diferença que os invasores exploraram.
💡 Não foi preciso quebrar a criptografia. Bastou conseguir controlar o caminho usado para provar que o domínio estava sob controle legítimo.
Google diz que seus servidores não foram invadidos
O Google afirmou que a infraestrutura dos proprietários dos domínios afetados não foi comprometida.
As autoridades certificadoras, segundo a empresa, também seguiram os procedimentos previstos para validar o domínio antes da emissão dos certificados.
O problema estava em uma etapa anterior: quem controlava os registros DNS tinha condições de responder corretamente às verificações.
Com o controle das zonas, os atacantes podiam alterar endereços IP e até delegações de servidores de nomes.
Isso abria espaço para redirecionar o tráfego e responder aos desafios utilizados pelas autoridades certificadoras.
E o que acontece quando o certificado falso existe? ⚠️
Do ponto de vista criptográfico, um certificado TLS não autorizado pode permitir que seu portador se apresente como o domínio legítimo.
É justamente por isso que certificados emitidos incorretamente são tratados como um problema sério.
O Google não revelou quais de seus domínios foram afetados. Também não informou quais outras organizações estavam envolvidas nem quantos certificados foram emitidos.
A empresa, porém, afirmou que já tomou medidas para bloquear os certificados identificados.
Chrome recebeu uma barreira extra 🚧
O Google atualizou o Chrome para bloquear todos os certificados não autorizados que conseguiu identificar.
A companhia também trabalhou com as autoridades certificadoras responsáveis pelas emissões para que os certificados de suas propriedades fossem revogados.
Para os usuários do Chrome, a orientação é simples: não é necessário fazer nada.
A proteção foi implementada no navegador.
Mas o Google deixou um recado para donos de sites
A empresa alertou que o bloqueio realizado pelo Chrome não deveria ser considerado uma solução completa para os proprietários de domínios.
🔐 A recomendação é preventiva: empresas devem acompanhar os registros de transparência de certificados para identificar emissões inesperadas e configurar registros DNS de Autorização de Autoridade de Certificação, conhecidos como CAA.
Esses registros permitem especificar quais autoridades certificadoras estão autorizadas a emitir certificados para determinado domínio.
Na prática, é uma camada adicional de segurança.
Se alguém conseguir assumir temporariamente o controle do DNS, ainda haverá mais uma barreira para impedir que uma autoridade certificadora autorizada seja utilizada indevidamente.
Não é a primeira vez que isso acontece
O episódio também chama atenção porque ataques envolvendo sequestro de domínios e certificados fraudulentos não são exatamente novidade.
Segundo o material fornecido, um certificado do Let’s Encrypt chegou a ser emitido para google.tg no início de 2026, depois que o registro .tg, do Togo, foi comprometido.
Há também um precedente muito mais antigo e conhecido.
Em 2011, invasores que violaram a autoridade certificadora holandesa DigiNotar conseguiram obter um certificado wildcard para google.com. O certificado foi posteriormente usado contra internautas no Irã.
O histórico mostra uma característica desconfortável da arquitetura de segurança da internet: uma cadeia de confiança pode ser bastante robusta e ainda assim depender de pontos administrativos muito menos protegidos.
O fantasma do Sea Turtle 🐢
Pesquisadores de ameaças do Google também já acompanharam uma campanha conhecida como Sea Turtle, que utilizou credenciais roubadas para sequestrar domínios em diferentes registros de ccTLDs e, posteriormente, obter certificados para esses domínios.
A lógica é parecida.
Em vez de tentar quebrar diretamente protocolos criptográficos, o atacante procura uma parte mais frágil da infraestrutura que sustenta a identidade digital.
É uma estratégia que troca força bruta por engenharia da confiança.
O problema é maior do que um certificado falso
O episódio deixa uma questão importante para a infraestrutura global da internet.
A emissão de um certificado TLS depende de uma cadeia de validações. Se uma dessas etapas acreditar que um invasor é o legítimo responsável por um domínio, todo o restante do processo pode funcionar perfeitamente e ainda assim produzir um resultado errado.
🌐 A ironia é essa: a autoridade certificadora pode cumprir corretamente suas regras, o navegador pode verificar corretamente o certificado e a criptografia pode continuar intacta. Mesmo assim, a identidade apresentada ao usuário pode estar errada.
Isso ajuda a explicar por que registros DNS, operadores de ccTLDs e autoridades certificadoras são componentes tão importantes da segurança da web.
E também por que um problema em um domínio nacional relativamente pequeno pode acabar alcançando serviços utilizados em escala global.
A internet continua dependendo do elo mais fraco
O caso envolvendo .gh, .sl e .as mostra que a segurança da internet não depende apenas de algoritmos criptográficos sofisticados.
Ela também depende de quem administra registros, credenciais, DNS e processos de validação.
Não foi necessário encontrar uma falha zero-day no OpenSSL. Também não foi necessário quebrar a criptografia do TLS.
Foi suficiente conseguir alterar os registros que diziam quem estava no controle.
E, quando um simples registro DNS pode ajudar alguém a obter as credenciais digitais de uma grande empresa, fica evidente que a batalha pela segurança da web acontece muito antes de o navegador mostrar o cadeado na barra de endereço.
