Conta invadida apesar da autenticação de dois fatores (2FA): basta um cookie roubado

O antivírus informa que a verificação foi bem-sucedida. Malware encontrado, removido, tudo limpo. Dois dias depois, sua conta do Google está enviando spam, e a lista de dispositivos mostra um computador que não é seu. A autenticação de dois fatores esteve ativada o tempo todo.

O que ocorre aqui é chamado de sequestro de sessão, ou seja, a apropriação de uma sessão que já está em andamento. O invasor não precisa nem da sua senha nem do seu segundo fator. Tudo o que ele precisa é do pequeno arquivo que o seu navegador armazena após o login, para que você não precise digitar nada novamente na sua próxima visita. Esse arquivo é o cookie de sessão.

O Google descreve isso abertamente em seu próprio blog do Chromium: o roubo ocorre após o login e, portanto, contorna a autenticação de dois fatores. E é difícil neutralizá-lo com software antivírus, pois os cookies continuam funcionando mesmo após a remoção do malware.

Como funciona o roubo

No início, há quase sempre um infostealer, um programa criado para coletar credenciais. Ele chega ao computador por meio de software crackeado, um instalador adulterado ou um anexo. Uma vez lá, ele lê os arquivos nos quais o navegador armazena seus cookies. O invasor então importa o cookie para seu próprio navegador e acessa o site. O serviço detecta uma sessão válida e conectada e não solicita mais nada.

A dimensão desse mercado fica evidente no Relatório Global de Inteligência de Ameaças publicado pela empresa de segurança Flashpoint em 11 de março de 2026. Para o ano de 2025, a Flashpoint contabiliza mais de 11,1 milhões de máquinas infectadas com infostealers e 3,3 bilhões de credenciais e tokens de nuvem roubados delas. Os cookies de sessão nem sequer fazem parte dessa contagem.

O quão próximo isso está de nós ficou demonstrado pela Operação Endgame. Em 24 de junho de 2026, a Europol relatou uma operação contra os grupos de roubo de informações StealC e Amadey e contra a rede de distribuição SocGholish, com participação alemã. Foram desativados 326 servidores e 142 domínios, e recuperados 27 milhões de conjuntos de credenciais. As vítimas foram notificadas por meio do Have I Been Pwned, entre outros canais.

O segundo fator está no lugar errado. Um código por SMS, uma solicitação do aplicativo e uma chave de segurança verificam quem está fazendo login. O cookie só é criado posteriormente, como prova de que essa verificação foi aprovada. Quem possuir essa prova não precisa passar pela verificação novamente. Nem mesmo o Programa de Proteção Avançada do Google altera isso. Qualquer pessoa que permaneça conectada pode não ser solicitada a fornecer a chave de segurança novamente, de acordo com o Google. Como proteger suas contas adequadamente é abordado no artigo “Uma senha por si só não é suficiente”.

O que os navegadores estão fazendo a respeito

No Windows, o Chrome criptografa cookies com a “Criptografia Vinculada ao Aplicativo” (App-Bound Encryption) desde a versão 127, de julho de 2024, e vincula a chave ao aplicativo. O próprio Google aponta a limitação: malware executado com privilégios elevados contorna a proteção. Isso torna o roubo mais oneroso, mas não o impede.

O verdadeiro avanço é chamado de “Device Bound Session Credentials” (Credenciais de Sessão Vinculadas ao Dispositivo), ou DBSC, para abreviar. O navegador gera um par de chaves cuja parte privada nunca sai do dispositivo. No Windows, ela fica no TPM, o chip de segurança na placa-mãe. O serviço verifica regularmente se o navegador ainda possui essa chave. Um cookie na máquina de outra pessoa não passa nessa verificação.

Para sites, a tecnologia está disponível desde o Chrome 145. O Google ativou-a para si mesmo em 9 de abril de 2026 com o Chrome 146 no Windows e vem implementando-a desde 25 de maio de 2026 para contas do Workspace e contas pessoais do Google, sem que os usuários precisem ativar nada. Dois limites permanecem. De acordo com a especificação do W3C, o DBSC não impede o acesso enquanto o invasor ainda estiver no dispositivo. E cada site precisa participar ativamente, razão pela qual a proteção chega primeiro aos serviços do Google.

O Firefox se sai pior nesse aspecto do que muitas pessoas supõem. Seu banco de dados de cookies fica armazenado sem criptografia no disco. A entrada no rastreador de bugs da Mozilla, bug 56788, foi registrada há 25 anos, encerrada como WONTFIX em 2000 e reaberta há dois anos. Ela possui prioridade P3 e não está atribuída a ninguém. A Proteção Total contra Cookies não altera isso; trata-se de proteção contra rastreamento.

O que o senhor pode fazer agora

A ordem é o que importa. Em caso de infecção por malware, o Escritório Federal Alemão de Segurança da Informação (BSI) estabelece a seguinte sequência: reinstale o sistema primeiro e, em seguida, altere as senhas. Quem fizer o contrário e digitar a nova senha no computador infectado estará entregando-o diretamente ao invasor.

Em seguida, vem a etapa que a maioria das pessoas ignora. Uma nova senha não necessariamente bloqueia um invasor que possua um cookie válido. É preciso encerrar as sessões abertas separadamente.

Google: myaccount.google.com, seção Segurança, “Gerenciar todos os dispositivos”. Cada sessão é listada individualmente; toque no dispositivo e faça o logout. O Google não oferece um único botão para todas elas.

Microsoft: account.microsoft.com, opções avançadas de segurança, “Fazer logout em todos os dispositivos”. De acordo com a Microsoft, o logout pode levar até 24 horas, e o Xbox está excluído.

Apple: account.apple.com, seção “Dispositivos”, selecione o dispositivo, “Remover da conta”. O dispositivo aparecerá novamente se alguém ainda estiver conectado nele.

O que as chaves de acesso fazem e o que não fazem

As chaves de acesso são vistas como as sucessoras da senha, e o BSI as considera uma forma muito segura de autenticação. Isso é verdade, mas, mais uma vez, isso abrange apenas o ato de fazer login. Uma chave de acesso impede que alguém faça login como se fosse você. Ela não impede que alguém assuma o controle da sessão que você já tem aberta. O fato de que o próprio login continua vulnerável a ataques é demonstrado pelo Pass-the-Passkey.

O quadro real é preocupante. Em seu blog de segurança de 9 de abril de 2026, o Google escreve que, em nenhum sistema operacional, existe uma maneira confiável de impedir o roubo de cookies apenas com software, uma vez que o malware esteja instalado no dispositivo. O que o DBSC altera é o tempo de validade do material roubado. O cookie roubado passa a ser utilizável apenas na máquina em que foi criado.

Até que isso se aplique em todos os lugares, o incômodo permanece com você. Nada de software pirata, downloads apenas da fonte original e, diante de qualquer suspeita, reinstale primeiro o sistema e, em seguida, encerre as sessões. Nessa ordem.