As suas passkeys são inquebráveis? Três investigações dizem o contrário

Três linhas de investigação divulgadas nas últimas semanas mostram que, embora a criptografia por trás das passkeys continue intacta, tudo o que a rodeia — o browser, o cofre na nuvem, os fluxos de recuperação, o registo de eventos do Windows e a validação feita pelos serviços — pode ser suficiente para um atacante autenticar-se em nome da vítima. A Unit 42 da Palo Alto Networks demonstrou como malware já presente num computador Windows consegue recuperar as chaves privadas de passkeys sincronizadas pelo Gestor de Senhas da Google; o investigador Dirk-jan Mollema mostrou como uma sessão comprometida pode “emprestar” a chave do Windows Hello for Business para autenticar no Microsoft Entra ID; e a SpecterOps identificou uma cadeia de reutilização de assinaturas associada à vulnerabilidade CVE-2026-34348, já corrigida pela Microsoft. Nenhuma destas técnicas quebra o WebAuthn ou o FIDO2 — todas partem de um ponto final já comprometido.

O que a Unit 42 demonstrou nas passkeys sincronizadas da Google

A investigação da Unit 42, intitulada Pass the Passkey, descreve como um atacante pode autenticar-se sem interação do utilizador, contornar requisitos de verificação de utilizador e extrair todas as chaves privadas de passkeys sincronizadas. O âmbito é explícito: o trabalho foca-se no Gestor de Senhas da Google no Chrome em Windows, especificamente em dispositivos equipados com TPM, e todos os ataques apresentados assumem que já existe malware no dispositivo da vítima na fase inicial.

O primeiro passo é o reconhecimento. O Chrome guarda localmente os dados das passkeys sincronizadas em registos WebauthnCredentialSpecifics codificados em proto, dentro da sua base de dados de sincronização em %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB; o acesso a esses registos não exige privilégios elevados e permite enumerar onde a vítima usa passkeys, com nomes de utilizador, identificadores de credenciais e a chave privada cifrada.

A empresa batizou as técnicas de Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key, cada uma dirigida a uma parte diferente do sistema de autenticação sem palavra-passe: identidade do dispositivo, verificação do utilizador, recuperação e sincronização de credenciais. Na primeira, malware sem privilégios personifica um dispositivo de confiança e pede uma resposta de autenticação válida para uma das passkeys da vítima, abusando da chave de identidade do dispositivo protegida por TPM que o Chrome usa para assinar o pedido enviado ao autenticador na nuvem da Google.

O resultado dessa primeira técnica tem uma limitação: a asserção WebAuthn é produzida sem a flag de verificação de utilizador (UV). E foi aqui que a validação dos serviços fez a diferença — o GitHub rejeitou o ataque por faltar o sinal UV exigido, enquanto o eBay aceitou a asserção apesar de pedir verificação de utilizador, tendo depois alterado a implementação para validar corretamente a flag. A variante seguinte contorna essa barreira: a Unit 42 diz que o malware pode forçar o Chrome a repetir o processo de integração do dispositivo e registar uma nova chave que o autenticador na nuvem trata como prova de que o utilizador concluiu a verificação com o Windows Hello, permitindo produzir asserções com a flag UV ativa sem reproduzir a biometria ou o PIN.

A chave-mestra de 32 bytes que não se consegue rodar

O cenário mais grave é o da terceira técnica, ligada ao chamado Security Domain Secret. Os investigadores descobriram que este segredo de 32 bytes ficou brevemente exposto em registos internos do Chrome e permanece acessível em memória durante a recuperação do dispositivo; extraí-lo permite decifrar todas as passkeys associadas à conta, passadas e futuras. A Google removeu o segredo dos registos após a comunicação dos investigadores, mas a Unit 42 afirma que continua a ser enviado ao cliente e permanece temporariamente acessível na memória do processo do Chrome.

Com essa chave-mestra, o atacante consegue decifrar os registos de passkeys sincronizadas e recuperar as chaves privadas, que podem ser transferidas para outro sistema e usadas para personificar a vítima. A Unit 42 avisa ainda que a chave roubada poderia servir para decifrar passkeys futuras sincronizadas com a conta, sendo que a implementação atual da Google, segundo a investigação, não oferece forma de rodar ou revogar esse segredo. Há também um ponto cego de deteção: o WebAuthn define um contador de assinaturas (signCount) para ajudar a detetar credenciais clonadas, mas em sistemas de passkeys sincronizadas as asserções contêm habitualmente um valor constante, o que reduz a visibilidade sobre uso não autorizado.

Importa não exagerar o alcance. A Unit 42 não demonstra a quebra da criptografia de chave pública: não extrai chaves privadas a partir da chave pública guardada num site, não forja assinaturas sem acesso a material de chave de confiança nem identifica fraqueza no protocolo de desafio-resposta do WebAuthn — os ataques exploram os sistemas responsáveis por armazenar, sincronizar e usar as credenciais, expondo lacunas entre os pressupostos de segurança e a implementação. A Unit 42 não reportou exploração observada em ambiente real.

Windows Hello for Business: chaves “emprestadas” dentro da sessão

A segunda linha de investigação vem de Dirk-jan Mollema, que publicou no seu blogue um trabalho sobre a possibilidade de usar a chave privada que suporta a autenticação do Windows Hello for Business para executar WebAuthn, tratando-a essencialmente como uma chave FIDO2, algo relevante porque normalmente essas chaves são usadas via um PRT ligado ao dispositivo. O investigador enquadra o comportamento como estrutural: trata-se de uma técnica que foi deixada como está, por ser mais ou menos uma consequência do funcionamento do Windows Hello for Business — a capacidade de fazer single sign-on com as chaves criptográficas a partir de uma sessão de utilizador, sem necessidade do PIN ou de presença do utilizador.

Em termos práticos, em sistemas com TPM o atacante não extrai a chave privada, não recupera o PIN nem provoca um pedido de biometria: o mecanismo de ticketing do Windows mantém as operações de chave privada disponíveis enquanto o utilizador está com sessão interativa aberta, permitindo que código a correr como o utilizador peça ao Windows para assinar dados de autenticação, sem privilégios de administrador. O detalhe decisivo está no desafio: o desafio WebAuthn do Entra testado permanece válido cinco minutos e não está vinculado a uma sessão, utilizador ou tenant, o que permite iniciar parte do processo noutra máquina, passar o desafio ao malware no equipamento comprometido, obter a assinatura e apresentar a asserção ao Entra ID.

As consequências são de persistência em identidade na nuvem: o atacante pode estabelecer acesso mais duradouro, registar um dispositivo que controla, obter um Primary Refresh Token e adicionar métodos de autenticação adicionais quando as políticas do tenant o permitem. Os tokens obtidos por esta via podem não conter a reivindicação de identificador de dispositivo — o que cria dificuldades face a políticas de Acesso Condicional que exigem dispositivo conforme, mas abre caminho a persistência — e, como a autenticação Windows Hello conta como MFA recente, pode satisfazer controlos que protegem o registo de métodos de autenticação.

CVE-2026-34348: quando o registo de eventos guarda o que não devia

A terceira peça vem da SpecterOps. A investigação de Michael Grafnetter, principal security researcher da empresa, apresentada na Black Hat USA, identificou três vulnerabilidades em Windows 11 e Microsoft Entra ID, duas das quais formavam uma cadeia de replay que poderia permitir personificar identidades privilegiadas na nuvem contornando MFA resistente a phishing. Segundo a investigação, o Windows 11 escrevia no registo de eventos uma cópia completa da asserção e o Entra ID não impedia adequadamente a sua reutilização, pelo que organizações que usam Windows Hello ou chaves FIDO2 com o Entra ID devem prestar particular atenção. Nas palavras do investigador, “se a implementação envolvente for falhada, os atacantes podem reintroduzir caminhos de replay, relay e semelhantes a phishing, mesmo quando a criptografia WebAuthn é sólida”.

Os dados do quadro seguem o aviso oficial: a Microsoft descreve uma falha de mecanismo de proteção no Windows Event Logging Service que permite a um atacante autorizado divulgar informação através da rede, com lançamento a 14 de julho de 2026, severidade máxima “Important”, classificação CWE-693 e CVSS 3.1 de 6.5. As correções foram distribuídas para Windows 10, Windows 11, Windows Server 2019, 2022 e 2025, sendo as atualizações cumulativas de julho o caminho direto de remediação. Note-se que à data de publicação a Microsoft avaliou a exploração como menos provável e indicou que a falha não era publicamente conhecida nem estava a ser explorada.

Artefactos e sinais a monitorizar

Do lado da deteção, as equipas de segurança devem investigar pedidos inesperados de recuperação do Gestor de Senhas da Google, registos de dispositivo inexplicados e autenticações com passkey a partir de sistemas desconhecidos. Em ambientes Microsoft, recomenda-se vigiar nos registos de início de sessão do Entra ID as autenticações Windows Hello for Business com o campo de identificador de dispositivo vazio — situação que pode ocorrer legitimamente em navegação privada ou browsers sem SSO, mas que deverá ser relativamente incomum em muitas empresas.

Mitigações concretas

• Aplicar as atualizações de segurança da Microsoft indicadas no aviso de CVE-2026-34348, começando pelos sistemas mais críticos.
• Nos serviços que aceitam WebAuthn: definir userVerification como obrigatório e verificar o bit UV devolvido, em vez de confiar apenas na configuração do pedido.
• Nos fornecedores de credenciais: emitir atestação para chaves recém-registadas, reforçar as verificações de reinscrição e recuperação, restringir o acesso ao estado local das passkeys e manter chaves-mestras fora de registos e da memória do cliente.
• Nos pontos finais: limitar o acesso à base de dados de sincronização do Chrome e a ficheiros de estado local como passkey_enclave_state ao processo do browser, com controlos de acesso da plataforma, reduzindo a capacidade de enumerar credenciais e manipular o estado de integração.
• Reforçar a prevenção e deteção de malware no posto de trabalho: todas estas cadeias começam com execução de código no dispositivo do utilizador.

Porque é que isto importa em Portugal

A leitura correta não é abandonar as passkeys. Os investigadores sublinham que as passkeys continuam significativamente mais seguras do que as palavras-passe tradicionais, mas os ataques demonstram que não eliminam os riscos criados por malware já em execução num dispositivo comprometido. A FIDO Alliance tem contestado afirmações genéricas de que ataques envolvendo browsers ou pontos finais comprometidos signifiquem que as passkeys estão quebradas. O contexto de adoção também ajuda a explicar a atenção mediática: segundo o relatório FIDO de 2026, menos de um terço das organizações (30%) implementou passkeys como método principal de início de sessão dos seus trabalhadores, com 57% ainda dependentes sobretudo de palavras-passe ou de outro mecanismo suscetível a phishing.

Para as organizações portuguesas, a conclusão operacional encaixa nas obrigações de gestão de risco do Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025 (transposição da NIS2): a autenticação multifator resistente a phishing continua a ser uma medida recomendada, mas não substitui a gestão de vulnerabilidades, a proteção do posto de trabalho e a monitorização de eventos de autenticação. As entidades abrangidas devem também garantir capacidade de notificação de incidentes ao CNCS/CERT.PT quando um comprometimento de identidade tenha impacto relevante nos serviços.

Há ainda uma dimensão de proteção de dados. Se um atacante utilizar chaves privadas sincronizadas ou asserções reutilizadas para acessos ilegítimos a contas com dados pessoais, estamos diante de uma potencial violação de dados pessoais nos termos do RGPD, com deveres de avaliação de risco, documentação interna e eventual notificação à CNPD e aos titulares. Para PME e cidadãos, a mensagem prática é simples: continuar a usar passkeys, manter o Chrome e o Windows atualizados, evitar instalar software de origem duvidosa e revisar periodicamente os dispositivos e métodos de autenticação associados à conta Google ou Microsoft.

Perguntas frequentes

As passkeys deixaram de ser seguras?

Não. Nenhuma das investigações quebra a criptografia do WebAuthn ou do FIDO2. Os ataques exploram os sistemas que guardam, sincronizam e usam as credenciais, e partem sempre de um dispositivo já comprometido por malware.

Devo deixar de sincronizar passkeys no Chrome?

Para a maioria dos utilizadores, a sincronização continua a ser preferível a palavras-passe reutilizadas. Em contextos de risco elevado, faz sentido complementar com chaves de segurança físicas e políticas que exijam dispositivo conforme para acessos privilegiados.

Qual é a atualização mais urgente a instalar?

A correção associada a CVE-2026-34348, no Windows Event Logging Service, publicada pela Microsoft a 14 de julho de 2026 e distribuída nas atualizações cumulativas para Windows 10, Windows 11 e Windows Server.

O que deve uma equipa de segurança monitorizar desde já?

Pedidos inesperados de recuperação do gestor de senhas, registos de dispositivo não explicados, inícios de sessão com passkey a partir de sistemas desconhecidos e autenticações Windows Hello for Business sem identificador de dispositivo no Entra ID.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Unit 42 da Palo Alto Networks, pelo investigador Dirk-jan Mollema, pela SpecterOps, pelo Microsoft Security Response Center e pela FIDO Alliance.