Como o malware pode sequestrar passkeys do Google Password Manager no Windows

O ponto importante é que nenhuma das técnicas quebra diretamente a criptografia do WebAuthn ou do FIDO2. Em vez disso, elas exploram falhas na forma como o autenticador em nuvem do Chrome confia no dispositivo, conduz a inclusão de novos dispositivos e sincroniza as credenciais . Todos os cenários dependem de uma condição prévia: o computador Windows já precisa estar comprometido por malware.

As três técnicas, em resumo

Pass-ta-key: aproveita a identidade do dispositivo

Na técnica básica, o malware extrai do arquivo local passkey_enclave_state a chave de identidade do dispositivo protegida pelo TPM — o módulo de segurança presente em muitos computadores modernos. Em seguida, usa chamadas legítimas das APIs CNG de criptografia do Windows para assinar solicitações controladas pelo invasor.

O resultado é uma asserção WebAuthn válida, sem que apareça na tela da vítima um pedido de impressão digital, PIN ou outra interação. O ataque, porém, só funciona contra serviços que não conferem o sinal User Verified (UV) nos dados enviados pelo autenticador .

O que a técnica explora: a confiança do autenticador em nuvem em uma chave de identidade armazenada localmente e a falta de validação da verificação do usuário por alguns sites.

Silver Pass-ta-key: contorna a exigência de verificação

O segundo método tenta superar justamente a exigência do sinal UV. Para isso, o invasor apaga ou invalida o arquivo local passkey_enclave_state, forçando o Chrome a repetir o processo de inclusão do dispositivo.

Durante esse procedimento, o Chrome cria temporariamente a chave de verificação do usuário em um fluxo adiado. É nessa janela que o invasor cadastra sua própria chave UV. Como o autenticador em nuvem do Google não valida a atestação dessa nova chave, as asserções assinadas por ela chegam com o sinal UV definido como 1.

Assim, o ataque pode passar até por sites que exigem verificação do usuário. Além disso, o invasor obtém acesso duradouro a partir do próprio computador: o dispositivo da vítima não precisa continuar conectado à internet .

O que a técnica explora: a ausência de validação de atestação durante a reinclusão do dispositivo e a possibilidade de apagar o arquivo de estado do enclave sem proteções suficientes.

Golden Pass-ta-key: rouba a chave mestra

O cenário mais grave repete o fluxo de reinclusão e, depois, despeja a memória do processo do Chrome para recuperar o Security Domain Secret (SDS) — um segredo simétrico de 32 bytes usado para criptografar todas as passkeys sincronizadas na conta Google da vítima.

Com o SDS, o invasor pode descriptografar as chaves privadas das passkeys já existentes e também das novas credenciais sincronizadas no futuro. Na prática, isso abre caminho para a tomada de todas as contas protegidas por essas passkeys.

A Unit 42 também informou que o Google havia registrado anteriormente o SDS em texto simples na saída chrome://device-log/FIDO do Chrome. Esse registro foi removido após a divulgação da pesquisa, mas o problema de exposição do segredo na memória do processo continuava existindo no momento do relato .

O que a técnica explora: a presença do SDS em texto simples na memória do Chrome durante o processo de inclusão do dispositivo.

Quais sites foram afetados?

A técnica Pass-ta-key básica pode funcionar contra qualquer serviço que não valide o sinal UV. A Unit 42 identificou o eBay como um exemplo de site que não fazia essa verificação; a empresa corrigiu o problema desde então .

Os pesquisadores disseram ter encontrado um número “surpreendente” de sites que solicitam userVerification: "required" durante o cadastro, mas não conferem posteriormente o bit UV retornado pelo autenticador . Isso significa que declarar a exigência na configuração não basta: a validação também precisa ser feita no servidor durante a autenticação.

O que acontece se o SDS for roubado?

O SDS funciona como uma chave mestra das passkeys sincronizadas na conta Google. Se esse segredo for obtido, os riscos incluem:

• descriptografar todas as chaves privadas de passkeys sincronizadas já existentes e qualquer nova chave que seja sincronizada depois ;
• autenticar-se em contas protegidas por passkeys, incluindo o Gmail, sem nova interação da vítima ;
• ampliar o impacto para outros serviços, já que o acesso ao Gmail pode permitir a redefinição de senhas de contas relacionadas ;
• enfrentar a ausência de um mecanismo integrado para trocar ou “rotacionar” o SDS: o Google não oferece ao usuário uma forma de gerar um novo segredo .

Como reduzir o risco

Com base nas descobertas da Unit 42, as principais recomendações são:

• Cadastre pelo menos uma chave de segurança física, como uma YubiKey, além da passkey sincronizada. Credenciais vinculadas ao dispositivo não são sincronizadas com a nuvem, não entram no estado do enclave do Chrome e não podem ser lidas da memória pelo mesmo caminho .
• Ative o Programa de Proteção Avançada do Google se a conta for de alto risco — por exemplo, de jornalistas, executivos, ativistas ou administradores. O programa exige chaves de segurança ou passkeys vinculadas ao dispositivo e reforça os processos de recuperação da conta .
• Revise mensalmente a lista de dispositivos da conta Google e remova sessões ou aparelhos que você não reconheça .
• Trate uma infecção por malware ladrão de informações como um evento de redefinição completa das credenciais. Depois de recuperar a conta, reinstale ou reconstrua o computador e cadastre novamente todas as passkeys usando um dispositivo limpo .
• Para os serviços que aceitam passkeys, valide o sinal UV no servidor e use userVerification: "required", em vez de "preferred", em operações sensíveis .

Situação atual

Na data da publicação, em 3 de agosto de 2026, ainda não havia um CVE atribuído aos problemas. O Google também não havia confirmado publicamente se corrigiria diretamente os caminhos Silver Pass-ta-key ou Golden Pass-ta-key .