Investigadores da Unit 42 da Palo Alto Networks divulgaram três novas técnicas de ataque que permitem a malware já presente num computador Windows apoderar-se de contas protegidas por passkeys sincronizadas através do Google Password Manager no Chrome. Segundo a Unit 42, é possível autenticar sem interação do utilizador, contornar requisitos de verificação do utilizador e extrair todas as chaves privadas das passkeys sincronizadas. As técnicas foram batizadas coletivamente de «Pass-ta-key», e nenhuma delas quebra a criptografia subjacente das passkeys — exploram, sim, a forma como o Chrome e o autenticador na nuvem da Google tratam a confiança de dispositivos, o registo e a recuperação de credenciais.
Resposta rápida: A Unit 42 mostrou três ataques (Pass-ta-key, Silver e Golden) que permitem a malware já instalado num Windows com Chrome e Google Password Manager assumir o controlo de contas com passkeys, sem PIN nem biometria. Não há falha na criptografia: todos os ataques exigem que o dispositivo já esteja comprometido, pelo que a primeira linha de defesa é evitar a infeção inicial — mantenha o sistema atualizado, use proteção de endpoint e desconfie de instaladores e anexos suspeitos.
O que são passkeys e por que se consideram mais seguras
As passkeys são um método de autenticação sem palavra-passe. Usam chaves criptográficas guardadas no dispositivo do utilizador para iniciar sessão em contas online e são consideradas mais seguras do que as palavras-passe porque não podem ser adivinhadas, reutilizadas ou facilmente roubadas através de phishing, permitindo ainda autenticar com PIN ou dados biométricos, como impressão digital ou reconhecimento facial. Empresas como a Google, a Microsoft e a Apple têm acelerado a transição para este modelo.
É por isso importante sublinhar a natureza deste estudo. Trata-se de técnicas pós-comprometimento: descrevem aquilo a que um atacante consegue chegar numa máquina que já está perdida, e não como a máquina foi perdida. Os próprios investigadores reforçam que as passkeys continuam significativamente mais seguras do que as palavras-passe tradicionais, mas os ataques demonstram que não eliminam os riscos colocados por malware já em execução num dispositivo comprometido.
Sistemas afetados
O âmbito da investigação é preciso. A pesquisa limita-se ao Google Password Manager no Chrome em sistemas Windows equipados com um Trusted Platform Module (TPM), e todos os caminhos começam com malware já em execução no dispositivo da vítima. As técnicas exigem que o malware já esteja a correr na conta de utilizador padrão da vítima, mas não requerem privilégios de administrador. A cadeia começa por reconhecimento local: o Chrome guarda os registos de credenciais sincronizadas em %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB.
As três técnicas Pass-ta-key
Na técnica base, malware a correr com direitos de utilizador padrão abusa da chave de identidade do dispositivo apoiada em TPM do Chrome para pedir uma asserção de autenticação de passkey válida ao autenticador na nuvem da Google. O problema de raiz está na forma como o Chrome trata essa chave: em vez de a manter permanentemente bloqueada dentro do TPM, gera-a como um blob temporário e exportável, permitindo que o malware a extraia e assine pedidos usando as APIs de criptografia padrão do Windows, exatamente como faria o navegador. Curiosamente, o TPM continua a fazer a assinatura, porque o pedido que lhe chega parece legítimo.
A segunda variante ataca o processo de re-registo do dispositivo. O Silver Pass-ta-key força o Chrome a inscrever novamente o dispositivo e a registar uma chave de verificação controlada pelo atacante, porque o autenticador na nuvem da Google não confirma que a nova chave veio de hardware de confiança. A Google pode então aceitar assinaturas da chave do atacante como prova de que a vítima concluiu a verificação por PIN ou biométrica. A consequência prática é grave: o atacante pode posteriormente autenticar-se a partir de outro sistema sem manter o acesso ao computador original.
A terceira e mais grave técnica, o Golden Pass-ta-key, visa a chave-mestra. Permite ao malware obter a chave usada para cifrar todas as passkeys sincronizadas através da conta do Google Password Manager da vítima — o security domain secret (SDS), enviado temporariamente para o Chrome quando um dispositivo se regista ou recupera acesso à conta. Trata-se de uma chave simétrica de 32 bytes que cifra todas as passkeys sincronizadas na conta. A Unit 42 explica que, apesar de inicialmente o Chrome expor o segredo em texto simples através dos registos FIDO internos, e de a Google o ter removido dos registos após o reporte dos investigadores, o SDS continua a ser enviado para o Chrome e permanece temporariamente acessível na memória do processo do navegador.
O impacto do roubo do SDS é duradouro. O Golden Pass-ta-key extrai o segredo de 32 bytes da memória do Chrome, decifrando todas as passkeys sincronizadas na conta, e a Google não oferece forma de o rodar. Segundo a Unit 42, a implementação atual não permite rodar nem revogar a chave, o que significa que as passkeys sincronizadas atuais e futuras permanecem protegidas pelo mesmo segredo.
Cronologia e estado da divulgação
| Momento | Desenvolvimento |
|---|---|
| Antes da publicação | Unit 42 reporta as falhas à Google; SDS exposto nos registos FIDO do Chrome |
| Após o reporte | Google remove o SDS da saída de registo do Chrome; a exposição em memória mantém-se, segundo a Unit 42 |
| Divulgação pública (agosto de 2026) | Unit 42 publica as três técnicas Pass-ta-key |
É de notar uma ressalva importante quanto à verificação. Fontes que analisaram o código do Chromium indicam que, à data, o código-fonte atual corrobora que o Chrome cria ou recebe segredos de 32 bytes em estruturas de dados do processo cliente, o que confirma que o segredo entra na memória do Chrome; contudo, a extração fiável, a tomada de conta e a persistência entre futuras épocas do segredo continuam a ser atribuídas à Unit 42 ou por resolver. Por outras palavras, a arquitetura é confirmada, mas nem todos os detalhes operacionais foram independentemente reproduzidos.
Mitigações recomendadas
Como todas as técnicas partem de um endpoint já comprometido, a defesa mais eficaz é evitar a infeção. A Unit 42 dirige recomendações a websites e a gestores de credenciais:
- Os websites devem exigir e validar corretamente a verificação do utilizador.
- Os gestores de credenciais devem validar as chaves de dispositivo recém-registadas, reforçar os processos de recuperação e re-registo de dispositivos e impedir que as chaves-mestras fiquem acessíveis na memória do navegador.
- Como cada técnica exige malware já em execução no endpoint Windows, a proteção de endpoint, a deteção de malware e a resposta a incidentes são as primeiras linhas de defesa.
- Para utilizadores e PME: mantenha o Chrome e o Windows atualizados, use software antimalware fiável e evite instalar aplicações de origem duvidosa — os infostealers são o vetor de entrega realista para este tipo de ataque.
Por que importa em Portugal
A relevância deste caso vai além do detalhe técnico. Uma conta Google comprometida raramente fica isolada: funciona como caixa de correio central que valida a identidade de muitas outras contas, através de códigos de acesso, alertas de faturação e ligações de recuperação. Comprometer esse inbox permite ao atacante herdar tudo o que dele depende, um link de reposição de cada vez.
Para as organizações abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), este cenário reforça a exigência de medidas de gestão de risco proporcionais, incluindo proteção robusta de endpoints e capacidade de resposta a incidentes — precisamente as camadas que impedem que o malware chegue a executar-se. O CNCS e o CERT.PT recomendam de forma consistente a higiene de endpoints e a atualização de software como pilares da prevenção. E, uma vez que a tomada de uma conta pode implicar acesso a dados pessoais, aplica-se também o RGPD, com potenciais obrigações de notificação em caso de violação de dados. A mensagem central da investigação é equilibrada: as passkeys continuam a ser uma proteção superior às palavras-passe, mas nenhum método de autenticação substitui a defesa do próprio dispositivo.
Perguntas frequentes
As passkeys deixaram de ser seguras?
Não. Os próprios investigadores da Unit 42 sublinham que as passkeys continuam significativamente mais seguras do que as palavras-passe tradicionais. Os ataques só funcionam quando já existe malware a correr no dispositivo e não quebram a criptografia das passkeys.
Que sistemas estão em risco?
A investigação limita-se ao Google Password Manager no Chrome em sistemas Windows equipados com TPM. Todos os cenários pressupõem um dispositivo já comprometido por malware, com privilégios de utilizador padrão.
O que é o Golden Pass-ta-key e por que é o mais grave?
É a técnica que extrai o security domain secret (SDS), a chave-mestra de 32 bytes que cifra todas as passkeys sincronizadas da conta. Como a Google não disponibiliza forma de rodar ou revogar esse segredo, o seu roubo pode permitir acesso continuado mesmo após a limpeza do dispositivo.
Como me posso proteger?
Como o ataque parte de um endpoint infetado, foque-se na prevenção da infeção: mantenha o Chrome e o Windows atualizados, use proteção de endpoint fiável, evite instaladores e anexos suspeitos e vigie sinais de infostealers. Para organizações, a deteção e a resposta a incidentes são as linhas de defesa prioritárias.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Unit 42 da Palo Alto Networks e por fontes de imprensa especializada.