Pesquisa revela técnicas que podem contornar passkeys do Google Password Manager após infecção por malware

Pesquisadores da Unit 42, da Palo Alto Networks, identificaram três técnicas que podem permitir que malwares assumam o controle de contas protegidas por passkeys armazenadas no Google Password Manager. Os ataques, entretanto, não exploram falhas na criptografia das passkeys, mas sim mecanismos de gerenciamento implementados pelo Chrome após um computador já ter sido comprometido.

As técnicas, batizadas de Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key, afetam o Google Password Manager em sistemas Windows equipados com Trusted Platform Module (TPM). Todos os cenários exigem que um malware já esteja em execução na máquina da vítima e, até o momento, não há evidências de exploração ativa nem registros de CVEs associados à pesquisa.

Segundo a Unit 42, os ataques exploram a forma como o Chrome armazena chaves do dispositivo, realiza o re-registro de equipamentos e gerencia o processo de autenticação. Dependendo da técnica utilizada, o invasor pode obter uma autenticação válida, instalar uma chave de verificação controlada pelo atacante ou extrair o Security Domain Secret (SDS), segredo de 32 bytes usado para descriptografar as chaves privadas das passkeys sincronizadas na conta Google.

As duas últimas técnicas são consideradas as mais preocupantes, pois podem permitir que o invasor continue acessando as contas da vítima a partir de outro computador, mesmo após perder o acesso inicial ao dispositivo comprometido.

A primeira técnica, chamada Pass-ta-key, reutiliza a chave de identidade protegida pelo TPM do próprio equipamento para gerar uma autenticação válida. Nesse caso, a autenticação ocorre sem impressão digital, PIN ou qualquer interação visível do usuário. No entanto, o indicador User Verified (UV) permanece desativado.

Os pesquisadores observaram que a eficácia desse método depende da implementação do serviço online. Plataformas que exigem obrigatoriamente a validação do indicador UV bloqueiam a tentativa de autenticação. Durante os testes, o GitHub rejeitou as credenciais, enquanto o eBay inicialmente aceitou a autenticação até corrigir o problema após a divulgação responsável da pesquisa.

A segunda técnica, Silver Pass-ta-key, explora o processo de re-registro de dispositivos. Segundo a Unit 42, o malware força o Chrome a registrar novamente o equipamento e aproveita uma janela em que a chave de verificação do usuário ainda não foi criada para cadastrar uma chave controlada pelo invasor. Caso o serviço não valide se essa nova chave foi gerada por hardware confiável, futuras autenticações poderão ocorrer com o indicador UV habilitado, dispensando o dispositivo original da vítima.

Já a terceira técnica, Golden Pass-ta-key, busca extrair da memória do Chrome o Security Domain Secret (SDS) durante o processo de re-registro. Com esse segredo, um invasor pode recuperar as chaves privadas sincronizadas das passkeys e reutilizá-las em seu próprio ambiente. A análise do código-fonte do Chromium confirma que esse segredo realmente é carregado temporariamente na memória do navegador, embora a viabilidade prática da extração e da persistência do ataque tenha sido descrita apenas pelos pesquisadores.

A Unit 42 informou que o Google já eliminou uma exposição anterior do SDS presente nos logs do Chrome relacionados ao FIDO e que o eBay corrigiu a validação do indicador UV. No entanto, não há confirmação pública de que todas as técnicas apresentadas tenham sido totalmente mitigadas.

Até 3 de agosto de 2026, também não havia registros dessas vulnerabilidades na National Vulnerability Database (NVD), nem comunicados públicos do Google informando quais versões do Chrome poderiam ser afetadas ou se houve correções completas para os três cenários.

Outro ponto destacado pelos pesquisadores é que a documentação pública do Google permite alterar o PIN do Google Password Manager ou apagar todos os dados armazenados, mas não esclarece se essas ações invalidam um Security Domain Secret eventualmente obtido por um invasor.

Como medidas de proteção, os pesquisadores recomendam que serviços online configurem o parâmetro userVerification como obrigatório e validem efetivamente o indicador User Verified retornado durante a autenticação. Também sugerem que provedores de credenciais reforcem a verificação de hardware durante o re-registro de dispositivos, fortaleçam os mecanismos de recuperação de contas, limitem o acesso ao estado local das passkeys e evitem manter chaves sensíveis armazenadas em memória ou registradas em logs.