Pesquisadores de segurança descobriram três ataques que permitem que malware já presente em dispositivos Windows comprometidos abuse das passkeys sincronizadas do Google Password Manager para assumir contas, burlar a verificação do usuário e extrair chaves privadas dessas credenciais.
As passkeys são um método de autenticação sem senha que usa chaves criptográficas armazenadas no dispositivo do usuário para permitir o acesso a contas online. Elas são consideradas mais seguras do que senhas porque não podem ser adivinhadas, reutilizadas nem facilmente roubadas por phishing. Além disso, permitem autenticação com PIN ou biometria, como impressão digital ou reconhecimento facial. “Diferentemente das senhas, as passkeys não podem ser compartilhadas, copiadas, anotadas nem entregues acidentalmente a outra pessoa. Isso as torna mais seguras contra phishing”, diz a documentação do Google sobre passkeys.
No entanto, um novo relatório da Unit 42, da Palo Alto Networks, mostra três ataques inéditos, chamados coletivamente de “Pass-ta-key”, que têm como alvo o Google Password Manager no Chrome em dispositivos Windows equipados com um Trusted Platform Module, ou TPM. Os três ataques exigem que o malware já esteja em execução no computador da vítima e não quebram a criptografia usada pelas passkeys. Em vez disso, exploram fraquezas na forma como o Chrome e o autenticador em nuvem do Google lidam com confiança no dispositivo, cadastro inicial, recuperação e credenciais sincronizadas.
A primeira técnica, chamada Pass-ta-key, permite que um malware sem privilégios se passe por um dispositivo confiável e solicite uma resposta válida de autenticação para uma das passkeys da vítima. O malware abusa da chave de identidade do dispositivo, protegida por TPM, para assinar uma solicitação enviada ao autenticador em nuvem do Google. Isso pode ser feito sem privilégios de administrador, sem interação do usuário, sem biometria e sem desbloquear o dispositivo.
Em seguida, o autenticador em nuvem do Google trata a solicitação como se viesse do computador confiável da vítima e devolve uma resposta de autenticação assinada, conhecida como assertion, que pode ser usada para entrar na conta alvo. Essa resposta, porém, inclui um sinalizador de User Verified, que indica se houve validação por biometria ou PIN. Isso faz com que o ataque falhe quando um serviço exige e valida corretamente que a verificação do usuário ocorreu.
Embora o ataque tenha falhado contra o GitHub, que checava corretamente o sinalizador de User Verified, a Unit 42 afirmou ter testado com sucesso a técnica contra o eBay. Nesse caso, a plataforma exigia verificação do usuário, mas não validava corretamente o sinalizador que indicava se essa verificação havia sido feita. A eBay corrigiu a falha após a notificação dos pesquisadores.
A segunda técnica, chamada Silver Pass-ta-key, vai além e permite que atacantes cadastrem sua própria chave de verificação do usuário no autenticador em nuvem do Google. Para isso, o atacante primeiro usa malware no dispositivo comprometido para forçar o Chrome a realizar um novo cadastro, invalidando a chave de verificação existente ou apagando o arquivo local que contém o estado das passkeys. Durante esse processo, o atacante consegue registrar uma chave de verificação sob seu controle porque o autenticador em nuvem não valida se a nova chave veio de hardware confiável.
O Google então aceita solicitações assinadas com a chave do atacante como prova de que a vítima desbloqueou o dispositivo com PIN ou biometria. Isso permite o acesso a contas que exigem e validam corretamente a verificação do usuário. Depois que a chave maliciosa é registrada, o atacante pode autenticar a partir de outro sistema, sem precisar voltar a acessar o computador da vítima.
A terceira e mais grave técnica, chamada Golden Pass-ta-key, permite que o malware obtenha a chave mestra usada para criptografar todas as passkeys sincronizadas pela conta do Google Password Manager da vítima. Essa chave mestra, conhecida como security domain secret, é enviada temporariamente ao Chrome quando um dispositivo é cadastrado ou recupera o acesso à conta.
A Unit 42 descobriu inicialmente que o Chrome expunha esse segredo em texto simples nos registros internos de FIDO. O Google removeu o segredo desses registros após a notificação dos pesquisadores, mas a Unit 42 afirma que ele ainda é enviado ao Chrome e continua acessível temporariamente na memória do processo do navegador. “Embora o Google tenha removido esse segredo da saída de logs do Chrome após o relatório, o SDS ainda é enviado ao cliente e permanece acessível na memória do processo do Chrome”, explicou a Unit 42. “Se o atacante forçar a vítima a se cadastrar novamente com o autenticador em nuvem e souber qual padrão procurar, ele pode extrair o SDS diretamente da memória.”
Com a chave mestra roubada, o atacante pode descriptografar os registros sincronizados de passkeys da vítima e recuperar suas chaves privadas. Essas chaves podem então ser transferidas para outro sistema e usadas para se passar pela vítima e entrar em suas contas. A Unit 42 alerta que a chave mestra roubada também pode ser usada para descriptografar futuras passkeys sincronizadas na conta.
Segundo os pesquisadores, a implementação atual do Google não oferece um mecanismo para rotacionar ou revogar essa chave, o que significa que as passkeys atuais e futuras continuam protegidas pelo mesmo segredo. Embora os pesquisadores afirmem que as passkeys continuam significativamente mais seguras do que as senhas tradicionais, os ataques mostram que elas não eliminam os riscos representados por malware já em execução em um dispositivo comprometido.
A pesquisa se limita ao Google Password Manager no Chrome em sistemas Windows equipados com TPM, e todas as rotas começam com malware já em execução no dispositivo da vítima. Trata-se de técnicas pós-comprometimento: elas descrevem o que um atacante consegue alcançar em uma máquina já perdida, e não como a máquina foi invadida.
O ataque começa com reconhecimento local. O Chrome armazena registros sincronizados de credenciais em %LocalAppData%\Google\Chrome\User Data\<Perfil>\Sync Data\LevelDB. Os pesquisadores disseram que um processo sem privilégios consegue ler metadados suficientes para identificar os relying parties e os nomes de usuário associados às passkeys da vítima, além de identificadores de credenciais e material criptografado da chave privada.
O código-fonte atual do Chromium mostra por que esse blob é reutilizável na primeira técnica: o Chrome cria a chave TPM sem um nome de chave, e um comentário no código diz que isso impede que ela seja persistida em disco. O Chrome então exporta a chave como um blob opaco e a recarrega depois sob uma flag que suprime qualquer aviso. Um TODO no mesmo arquivo aponta para o problema Chromium 398125799, sugerindo que essas chaves sejam rotuladas.
O código-fonte atual do Chromium também confirma de forma independente que dispositivos recém-registrados podem permanecer no estado deferred_uv_key_creation, mas o código público por si só não comprova o ataque relatado de substituição de chave no servidor na versão estável mais recente do Chrome. A divulgação não informa se o serviço em produção agora verifica atestação de hardware antes de aceitar uma chave de substituição, uma checagem que a Unit 42 recomenda para mitigar essa rota.
O relatório não descreve exploração em ambiente real e não informa identificadores CVE, versões afetadas do Chrome nem o status completo das correções. Uma consulta ao National Vulnerability Database em 3 de agosto de 2026 não encontrou nenhum CVE correspondente às três técnicas nomeadas. O código-fonte do Chromium, na mesma data, corrobora partes da arquitetura, mas não confirma que a versão estável mais recente do Chrome continue explorável.
Os pesquisadores disseram que o Google removeu uma exposição anterior do SDS dos logs FIDO do Chrome e que o eBay agora valida o flag User Verified. Segundo eles, o segredo ainda chega ao cliente e permanece na memória do Chrome, então a mudança nos logs não fecha a rota descrita. Em 3 de agosto de 2026, buscas nos materiais públicos do Chrome, do Google e nas páginas de suporte e imprensa do eBay não encontraram nenhum aviso documentando qualquer uma das mudanças relatadas, e nenhuma delas descreve uma forma de o usuário verificar se um SDS foi exposto.
A documentação pública de suporte do Google permite alterar o PIN do Google Password Manager ou apagar todos os dados do Password Manager, mas não descreve uma rotação ou revogação específica para SDS. A reportagem também buscou comentários do Google sobre se um Security Domain Secret roubado continua válido após a troca do PIN do Password Manager, e da Palo Alto Networks para obter mais detalhes sobre a pesquisa. Segundo o BleepingComputer, o Google foi procurado para comentar as conclusões da Unit 42 e informar se os ataques descritos foram totalmente corrigidos, mas não houve resposta imediata.
Os relying parties devem definir userVerification como required e verificar o bit UV retornado, em vez de confiar apenas na configuração da solicitação. Os provedores de credenciais devem atestar chaves recém-inscritas, reforçar as verificações de reinscrição e recuperação, restringir o acesso ao estado local das passkeys e manter as chaves-mestras fora de logs e da memória do cliente. Os pesquisadores informaram o Google sobre os ataques ao Gerenciador de Senhas e comunicaram as falhas relacionadas à verificação do usuário às plataformas afetadas, incluindo o eBay, antes de publicar os resultados.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...