Pacific News #298: O Presente de Grego

Assunto do momento: Uma nova ameaça frente a autenticação passwordless

O que aconteceu? Pesquisadores da Unit 42, da Palo Alto, descobriram uma nova classe de ataques ao ecossistema passwordless do Google, onde um malware em um endpoint comprometido pode modificar os fluxos de trabalho de integração, recuperação e confiança do dispositivo para efetuar o takeover de contas protegidas por passkey.

Reconhecimento: Antes de qualquer ataque, o ofensor precisa ter a visibilidade de como os passkeys são usados no contexto da conta de sua vítima. Quando você sincroniza suas passkeys no Chrome, o navegador salva essas informações localmente no computador, como parte do processo de sincronização com a conta Google. Para ler esses arquivos, não é preciso ter privilégios de administrador, portanto, basta um endpoint comprometido. 

O desafio: contornar as proteções da chave privada, que é utilizada para assinar os desafios de autenticação e protegida por uma chave mestra. Mesmo que uma versão criptografada dessa chave esteja guardada no dispositivo do usuário, somente o autenticador da nuvem (Google) consegue decifrá-la. 

Pass-ta-Key: A primeira forma de contornar esse mecanismo é imitando o comportamento do Gerenciador de Senhas do Google e do Chrome durante uma autenticação legítima, através de personificação, partindo de um malware na máquina da vítima e efetuando o ataque conhecido como “Pass-ta-Key”:

1. O atacante escolhe uma conta-alvo e inicia um login por passkey. 
2. O serviço online responde com um desafio de autenticação novo. 
3. O atacante então abre uma conexão com o autenticador na nuvem do Google e, usando o hash gerado nessa conexão, interage com o módulo da plataforma de segurança  da vítima para usar a chave de identidade extraída e assinar tanto esse hash quanto o pedido de autenticação. 
4. Com essa assinatura em mãos, o atacante envia o pedido de autenticação ao autenticador na nuvem, que, ao ver uma assinatura válida, entende se tratar de um dispositivo confiável e responde com uma autenticação válida. 
5. Essa resposta é então repassada ao serviço online, completando o login e dando ao atacante controle total da conta da vítima. 

E em contas mais protegidas:? Em alguns cenários, contas de usuário são protegidas por requerimentos mais robustos de autenticação, que validam a verificação de usuário com uma chave específica (chave UV), que é controlada pela própria interação do usuário: o sistema operacional confirma a identidade da pessoa do mesmo jeito que faz para desbloquear o dispositivo (Windows Hello, por exemplo). Ou seja, sem conseguir privilégios de sistema ou acesso físico ao aparelho da vítima, o atacante não tem, a princípio, como obter essa chave. 

Sim, mas: Em vez de tentar contornar a proteção da chave UV, o atacante invalida a chave atualmente registrada no autenticador na nuvem com o comando “device/forget” no nome da vítima. Isso é possível com um malware no computador da vítima. 

A chave de prata: Sem a chave anterior, o ofensor gera uma chave nova e a registra, sob seu controle. A partir desse momento, qualquer mensagem assinada com essa nova chave é aceita pelo autenticador na nuvem como se o usuário tivesse realmente desbloqueado o dispositivo. 

Recuperando a chave mestra: Lembra que falamos da chave mestra protegida e inacessível? Ela é chamada SDS e deveria ser inacessível. Mas, na primeira vez que uma passkey é usada em um dispositivo, o Chrome adia a criação da chave de verificação do usuário (UV) pela segunda vez, evitando pedir autenticação duas vezes seguidas. Nesse intervalo, o dispositivo fica num estado "pendente". Nesse estado forçado, o atacante pode monitorar o sistema até o momento onde o Chrome processe o SDS durante o registro com o autenticador na nuvem. Com um dump de memória do Chrome, é possível extrair o SDS que, por uma falha de implementação, transita em texto puro pela memória do navegador.  

A chave de ouro: Com o SDS extraído, o atacante usa os dados de passkeys já coletados anteriormente para descriptografar, offline, as chaves privadas de todas as passkeys da vítima. A partir daí, ele consegue assinar qualquer desafio de autenticação e logar em qualquer conta protegida por passkey. O que torna esse ataque especialmente grave é a persistência, uma vez que não existe hoje uma forma de revogar ou trocar o SDS. Isso significa que, uma vez roubado, ele continua válido para todas as passkeys atuais e futuras da conta da vítima.

Saiba mais: Recomendamos a leitura integral do artigo original sobre os ataques Passwordless feitos pela Unit 42, da Palo Alto, escrito por Arie Olshtein.

A governança de IA está repetindo os erros da cibersegurança?

O que aconteceu? Com a rápida evolução dos modelos de IA, empresas, pesquisadores e governos tentam criar estruturas capazes de avaliar e controlar seus riscos. O problema é que essa discussão ainda se encontra em um estágio semelhante ao vivido pela indústria de cibersegurança no início dos anos 2000: os próprios fornecedores desenvolvem as tecnologias, controlam grande parte das avaliações e decidem quais evidências serão divulgadas.

Um pouco de história: Em maio de 1998, integrantes do coletivo L0pht Heavy Industries testemunharam perante o Comitê de Assuntos Governamentais do Senado dos Estados Unidos, alertando que uma única pessoa com conhecimento suficiente poderia tornar a internet inutilizável em todo o país em aproximadamente 30 minutos. Nos anos seguintes, fornecedores de tecnologia e pesquisadores travaram uma longa disputa sobre quem deveria controlar a divulgação de vulnerabilidades. A cibersegurança nunca resolveu completamente esse problema, mas criou mecanismos para reduzir a dependência da palavra dos fornecedores, introduzindo uma ideia fundamental: a avaliação do fornecedor não pode ser a única avaliação considerada válida. 

Por que isso importa? Porque os sistemas que ainda estamos aprendendo a governar já demonstraram capacidade para descobrir vulnerabilidades, explorar falhas e acessar sistemas reais de forma autônoma. O risco deixou de ser apenas teórico ou restrito ao conteúdo produzido por esses modelos. Ele passou a envolver as ações que agentes de IA podem executar sobre infraestruturas externas.

Os impactos: O incidente que atingiu a Hugging Face começou durante uma avaliação interna conduzida pela OpenAI. A empresa testava o GPT-5.6 Sol e um modelo experimental mais capaz contra o ExploitGym, um benchmark voltado à avaliação de capacidades ofensivas em cibersegurança. Durante os testes, os modelos identificaram e exploraram uma vulnerabilidade zero-day no JFrog Artifactory usado pela infraestrutura da OpenAI, conseguiram acesso à internet e avançaram até os sistemas de produção da Hugging Face. Os agentes roubaram credenciais, exploraram outras vulnerabilidades e acessaram informações que poderiam ajudá-los a obter melhores resultados na própria avaliação. Os incidentes divulgados pela Anthropic ocorreram sob uma configuração diferente. Nesse caso, as avaliações eram realizadas em parceria com a Irregular, um laboratório externo de segurança. Entretanto, uma configuração incorreta manteve o acesso à internet ativo em ambientes que deveriam estar isolados.

Saiba mais: Os incidentes de julho de 2026 expuseram dois modelos de falha em um curto intervalo: a autoavaliação conduzida integralmente pelo fornecedor e a avaliação terceirizada realizada sobre uma fronteira de contenção que não havia sido adequadamente verificada. A experiência da cibersegurança mostra que contratar uma empresa externa não é suficiente. Também é necessário fiscalizar os avaliadores, estabelecer requisitos de independência e competência, inspecionar metodologias, preservar evidências, declarar conflitos de interesse e aplicar consequências quando falhas graves ocorrerem.

Papo Rápido

@Ataques

O malware XCSSET voltou a atacar desenvolvedores de macOS por meio de projetos Xcode e repositórios GitHub comprometidos. A nova versão do malware rouba credenciais, sequestra o Chrome, substitui o Telegram por uma versão maliciosa e desativa proteções do sistema. (BleepingComputer)

Criminosos ligados à inteligência russa estão explorando redes Wi-Fi públicas para distribuir malwares capazes de roubar credenciais e monitorar dispositivos. A campanha, identificada como CaptiveCrunch, usa falsos avisos de atualização e páginas de phishing para infectar usuários em hotéis e outros locais com redes compartilhadas. (TheRegister)

@Patches

O grupo INC Ransomware ampliou a exploração das vulnerabilidades CVE-2026-15409 e CVE-2026-15410 em dispositivos SonicWall SMA 1000, atingindo organizações em diversos países. O grupo também passou a pressionar as vítimas com ligações e emails durante a negociação de extorsão. A recomendação é aplicar imediatamente as correções de segurança e investigar possíveis comprometimentos. (SecurityAffairs)

@Mundo

Um ataque ao Police National Legal Database (PNLD), serviço jurídico usado por forças policiais do Reino Unido, expôs dados de contato de mais de 100 mil policiais e profissionais do sistema de justiça. As autoridades informaram que não há evidências de vazamento de senhas ou credenciais, e a investigação segue com apoio de especialistas e da Agência Nacional de Crimes. (BleepingComputer)

Ataques cibernéticos contra sistemas de água e esgoto dos EUA atingiram pelo menos sete estados, incluindo Minnesota, Michigan, Dakota do Sul e Geórgia. As autoridades investigam uma possível ligação com criminosos apoiados pelo Irã, enquanto agências de segurança alertam para riscos em sistemas industriais conectados à internet. (SecurityWeek)

Quer saber mais? Siga-nos nas redes sociais: Linkedin, Instagram.
Segurança nunca é demais, ainda mais nos dias de hoje.
Compartilhe o conhecimento, espalhe a segurança!

Siga nossa Newsletter e se mantenha atualizado sobre as últimas tendências em Cybersec!

Escrito por: Thaís Hudari Abib, Murilo Lopes e Cíntia Baltar
Arte: George Lopes e Anselmo Costa