Um malware em execução como usuário comum em uma máquina Windows consegue entrar nas contas protegidas por chaves de acesso da vítima sem exigir impressão digital, PIN ou qualquer outra interação visível na tela.
A Unit 42 detalhou três caminhos de ataque contra o autenticador na nuvem do Gerenciador de Senhas do Google no Chrome, que ela chama de Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key; o mais severo mira a chave mestra que protege as chaves de acesso sincronizadas do usuário.
Nada disso quebra a criptografia. Os ataques vão atrás do código em torno da chave de acesso: como o Chrome guarda suas chaves de dispositivo, como ele recadastra um dispositivo depois que esse estado desaparece e se o site no qual você está entrando se dá ao trabalho de verificar se houve confirmação de uma pessoa de verdade.
Os ataques podem obter silenciosamente uma asserção de autenticação válida, instalar uma chave de verificação de usuário controlada pelo invasor ou extrair o Segredo do Domínio de Segurança (Security Domain Secret, SDS) de 32 bytes usado para decriptar as chaves privadas sincronizadas.
Os pesquisadores afirmaram que os dois últimos caminhos podem oferecer acesso reutilizável a partir do próprio ambiente do invasor após o comprometimento inicial do endpoint. O relatório não descreve exploração em ambiente real e não fornece identificadores CVE (Vulnerabilidades e Exposições Comuns), versões afetadas do Chrome nem status completo de correção.
Uma consulta ao Banco de Dados Nacional de Vulnerabilidades (National Vulnerability Database, NVD) no dia 3 de agosto de 2026 não encontrou nenhum CVE correspondente às três técnicas nomeadas.
A pesquisa se limita ao Gerenciador de Senhas do Google no Chrome em sistemas Windows equipados com um TPM (Módulo de Plataforma Confiável, do inglês Trusted Platform Module), e cada caminho começa com um malware já em execução no dispositivo da vítima.
O código-fonte do Chromium em 3 de agosto corrobora partes da arquitetura, mas não que a versão estável mais recente do Chrome permaneça explorável. São técnicas pós-comprometimento. Elas descrevem o que um invasor alcança em uma máquina já perdida, e não como ela foi perdida.
O ataque começa com reconhecimento local. O Chrome armazena registros de credenciais sincronizadas em %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. Os pesquisadores disseram que um processo sem privilégios consegue ler metadados suficientes para identificar as partes confiáveis e nomes de usuário vinculados às chaves de acesso da vítima, além de identificadores de credenciais e material de chave privada criptografado.
Primeiro caminho de ataque
A primeira técnica, Pass-ta-key, extrai a chave de identidade do dispositivo envolta pelo Chrome e pede ao mesmo TPM que assine uma requisição controlada pelo invasor por meio de chamadas da CNG (API de Criptografia: Próxima Geração, do inglês Cryptography API: Next Generation) do Windows.
O código-fonte atual do Chromium mostra por que esse blob é reutilizável: o Chrome cria a chave do TPM sem um nome de chave, o que, segundo um comentário no código, impede que ela seja persistida em disco. O Chrome então exporta a chave como um blob opaco e a recarrega mais tarde sob um sinalizador que suprime qualquer prompt. Um TODO no mesmo arquivo aponta para a issue 398125799 do Chromium, que propõe rotular essas chaves.
O Google Cloud Authenticator devolve uma asserção válida, e a única coisa que a separa de uma produzida após uma verificação real do usuário é um único bit, o sinalizador UV (Usuário Verificado, do inglês User Verified), deixado zerado. A especificação atual de Web Authentication diz que uma parte confiável que define userVerification como obrigatório deve reprovar a cerimônia quando esse bit estiver ausente.
Os pesquisadores afirmaram que o GitHub aplicou a verificação, enquanto o eBay aceitou a asserção de teste até a empresa corrigir a falha de validação após a divulgação. Dos três caminhos, este é o que depende de uma checagem controlada pela parte confiável, então um site pode reprová-lo independentemente do comportamento do serviço na nuvem — e, das duas que a Unit 42 cita, uma reprovou.
Segundo caminho de ataque
O Silver Pass-ta-key mira a próxima camada. O malware força o Chrome a recadastrar o dispositivo. O Chrome não cria imediatamente sua chave de verificação de usuário, e nessa janela um invasor pode registrar uma chave própria no lugar.
A Unit 42 disse que o serviço não verifica se uma chave recém-registrada veio de hardware seguro. Asserções assinadas com essa chave carregam o sinalizador UV, o que, segundo os pesquisadores, viabiliza logins posteriores sem o dispositivo da vítima. O código-fonte atual do Chromium confirma de forma independente que dispositivos recém-registrados podem manter um estado deferred_uv_key_creation, mas o código público sozinho não verifica o ataque de substituição de chave no servidor contra a versão estável mais recente do Chrome.
A divulgação não esclarece se o serviço de produção agora verifica o atestado de hardware antes de aceitar uma chave substituta, uma checagem que a Unit 42 recomenda para mitigar esse caminho.
Terceiro caminho de ataque
O Golden Pass-ta-key vai atrás do próprio SDS. A Unit 42 afirmou que o malware pode acionar o recadastro, ler o segredo da memória do processo do Chrome enquanto ele permanece ali brevemente em texto claro e usá-lo para recuperar chaves privadas de acesso sincronizadas.
O código-fonte atual do Chromium corrobora a exposição subjacente: o Chrome cria ou recebe segredos de domínio de segurança de 32 bytes em estruturas de dados do processo cliente. Isso confirma que o segredo entra na memória do Chrome, embora a extração confiável, o sequestro de conta e a persistência em futuras épocas de segredo continuem atribuídos à Unit 42 ou permaneçam em aberto.
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 sinalizador UV. Eles afirmaram que o segredo ainda chega ao cliente e permanece na memória do Chrome, então a mudança no log não fecha o caminho descrito.
A divulgação não estabelece se os três caminhos de ataque foram fechados. Em 3 de agosto de 2026, buscas nos materiais públicos do Google sobre o Chrome e nas páginas de suporte e imprensa do eBay não encontraram nenhum aviso documentando qualquer das mudanças relatadas, e nenhum deles descreve uma forma de o usuário verificar se um SDS foi exposto.
A documentação pública de suporte do Google permite que os usuários alterem o PIN do Gerenciador de Senhas do Google ou apaguem todos os dados do Gerenciador de Senhas, mas não descreve um controle de rotação ou revogação específico para o SDS.
O The Hacker News procurou o Google para comentar se um Segredo do Domínio de Segurança roubado sobrevive a uma troca de PIN do Gerenciador de Senhas, e a Palo Alto Networks para obter mais detalhes sobre a pesquisa, e atualizará esta matéria com qualquer resposta.
As partes confiáveis devem definir userVerification como obrigatório e verificar o bit UV retornado, em vez de confiar apenas na configuração da requisição. Provedores de credenciais devem atestar as chaves recém-cadastradas, reforçar as checagens de recadastro e recuperação, restringir o acesso ao estado local das chaves de acesso e manter as chaves mestres fora dos logs e da memória do cliente.
As fontes analisadas não dizem se alterar o PIN do Gerenciador de Senhas do Google ou apagar os dados do Gerenciador de Senhas invalida um segredo que o invasor já possui, que é o que um usuário que desconfia de comprometimento precisaria saber para agir.
