Durante anos, o conselho de segurança digital mais repetido foi simples: use senhas longas e únicas para cada conta, ative a autenticação de dois fatores e pronto. Você está protegido.
Esse conselho ainda é válido, mas ele protege contra apenas uma parte dos ataques reais que acontecem hoje. Existe uma categoria de ameaça que ignora completamente sua senha e seu segundo fator: o roubo de cookie de sessão.
O ataque funciona assim: você faz login normalmente, a autenticação de dois fatores é concluída com sucesso, e o site emite um cookie de sessão, um arquivo que diz ao servidor “essa pessoa já se autenticou, deixe ela acessar a conta”. A partir daí, enquanto esse cookie existir, você não precisa fazer login de novo. O problema é que um malware instalado no seu computador pode silenciosamente copiar esse arquivo e enviá-lo para um servidor controlado por criminosos. Com o cookie em mãos, o atacante abre seu navegador, cola o arquivo lá e assume sua conta, sem saber sua senha, sem precisar do segundo fator.
Esse tipo de ataque escapou do radar de boa parte dos usuários comuns por ser mais complexo de explicar do que um phishing comum. Mas para os criminosos digitais, ele se tornou extremamente atraente justamente por contornar a proteção que a maioria das pessoas acredita ser suficiente.
O Relatório de Violações de Identidade de 2026 da Constella Intelligence documentou que infostealers processaram 51,7 milhões de pacotes de credenciais em 2025, um aumento de 72% em relação ao ano anterior, e que esses pacotes são especialmente letais porque contêm cookies de sessão ativos que permitem aos atacantes contornar completamente a autenticação multifator.
Em 10 de abril de 2026, o Google lançou sua resposta direta a esse problema no Chrome 146 para Windows.
O que é o DBSC: Device Bound Session Credentials (Credenciais de Sessão Vinculadas ao Dispositivo)
O Nome Técnico que o Texto Original Não Mencionou
A tecnologia que protege os cookies de sessão no Chrome tem um nome oficial: Device Bound Session Credentials, abreviado como DBSC. Conforme o Google anunciou em seu blog oficial de segurança, o DBSC está entrando em disponibilidade pública para usuários Windows no Chrome 146, com expansão para macOS numa versão subsequente do navegador.
O que significa “vincular uma sessão ao dispositivo” (device-bound session)? Em vez de emitir um cookie que pode ser copiado e usado em qualquer computador do mundo, o DBSC garante que o cookie de sessão só funcione no hardware específico onde ele foi criado. Isso é feito por meio de criptografia baseada num chip de segurança físico integrado ao computador. Mesmo que um malware consiga copiar o arquivo do cookie, ele não terá a chave criptográfica necessária para usá-lo num outro dispositivo, tornando o dado roubado completamente inútil para o atacante.
O Problema que o DBSC Resolve: a Exfiltração de Cookies
Para entender a importância do DBSC, é preciso entender como os infostealers, um tipo de malware especializado em roubar credenciais, exploravam os navegadores até agora.
Uma vez que malware sofisticado obtém acesso a uma máquina, ele consegue ler os arquivos locais e a memória onde os navegadores armazenam cookies de autenticação, conforme declarado pelas equipes de Segurança de Contas e do Chrome da Google em abril de 2026.
O Google afirma que não há maneira confiável de prevenir a exfiltração de cookies usando apenas software em nenhum sistema operacional. A única forma anterior de combater esse ataque era detectá-lo usando heurísticas, uma abordagem que qualquer pessoa que já recebeu um alerta ao tentar comprar algo com o cartão de crédito sabe que pode falhar.
O que é um infostealer (ladrão de informações)? É uma categoria específica de malware projetada para roubar silenciosamente credenciais, cookies de sessão, senhas salvas e outros dados sensíveis do dispositivo infectado, sem que o usuário perceba. Diferente de ransomwares, que bloqueiam o acesso ao computador e exigem resgate, os infostealers agem de forma discreta, coletando dados e enviando tudo para servidores controlados pelos atacantes. Esses dados são depois vendidos em mercados clandestinos da internet ou usados diretamente para acessar contas bancárias, e-mails corporativos e sistemas empresariais.
O que é o LummaC2? É uma das famílias de infostealers mais prolíficas e sofisticadas em atividade entre 2023 e 2026. Famílias de malware infostealer como o LummaC2 tornaram-se progressivamente mais sofisticadas em colher essas credenciais, segundo o Google. O LummaC2 é vendido como um serviço em fóruns criminosos, o que permite que atacantes sem conhecimento técnico avançado o usem para comprometer contas de usuários em escala.
Veja MaisPIX Ganha Novo Mecanismo para Recuperar Dinheiro de Vítimas de Fraudes: Entenda como Funciona
Google Implementou Criptografia De Ponta A Ponta No Gmail Para Dispositivos Móveis
Smishing: O Golpe por SMS que já custou bilhões e pode estar Mirando o seu Celular Agora
Nova ameaça: Malware Bancário Sturnus burla a criptografia do WhatsApp, Telegram e Signal
Como o DBSC Funciona Tecnicamente
Hardware como Raiz da Confiança
A mudança de paradigma que o DBSC introduz está em mover a segurança da sessão do software para o hardware. Em vez de confiar apenas em arquivos e memória, que qualquer malware com acesso ao sistema pode ler, o DBSC ancora a sessão num chip físico de segurança.
O DBSC funciona vinculando criptograficamente sessões de usuários ao hardware, como o chip de segurança do computador: o TPM (Trusted Platform Module) no Windows e o Secure Enclave no macOS. Como as chaves públicas e privadas únicas usadas para criptografar e descriptografar dados sensíveis são geradas pelo chip de segurança, elas não podem ser roubadas, impedindo que atacantes usem cookies de sessão roubados.
O que é o TPM (Módulo de Plataforma Confiável)? O TPM (do inglês Trusted Platform Module, ou Módulo de Plataforma Confiável) é um chip de segurança dedicado integrado à placa-mãe da maioria dos computadores modernos. Ele é capaz de gerar e armazenar chaves criptográficas de forma isolada do sistema operacional e de qualquer software. A propriedade mais importante do TPM para o DBSC é que as chaves privadas geradas dentro do chip são arquiteturalmente incapazes de serem exportadas: nenhum software, nem mesmo com privilégios de administrador do sistema, consegue extrair essas chaves do chip. O Windows 11 já exige TPM 2.0 como requisito mínimo de hardware, o que significa que a maioria dos usuários modernos de Windows já tem o componente necessário.
O que é o Secure Enclave (Enclave Seguro) no macOS? É o equivalente Apple ao TPM, um coprocessador dedicado à segurança integrado aos chips Apple Silicon (como M1, M2, M3 e M4) e nas versões mais recentes dos chips Intel usados em Macs anteriores. Assim como o TPM, o Secure Enclave armazena chaves criptográficas de forma isolada, sem que nenhum software externo consiga acessá-las diretamente.
O Mecanismo Passo a Passo
Quando você faz login num site compatível com DBSC, o processo funciona assim:
Primeiro, o Chrome gera um par de chaves criptográficas exclusivo diretamente dentro do TPM ou do Secure Enclave do seu dispositivo. A chave privada nunca sai do chip, nenhum software externo consegue lê-la. A chave pública é compartilhada com o servidor do site.
Em seguida, em vez de um único cookie de sessão com longa validade, o servidor emite cookies de curta duração. Mesmo que um infostealer consiga exfiltrar o cookie, ele expira em no máximo 10 minutos. Renovar o cookie exige a chave privada dentro do TPM, mas chaves privadas do TPM não são exportáveis por design de hardware.
Para renovar o acesso, o Chrome precisa provar periodicamente ao servidor que ainda possui a chave privada, sem revelar a chave em si. Se um atacante tentar usar o cookie roubado em outro dispositivo, a prova de posse falha, o acesso é bloqueado e o cookie fica inútil.
O DBSC aborda essa vulnerabilidade movendo a raiz da confiança da sessão para o hardware. A chave privada é gerada dentro do chip e é arquiteturalmente incapaz de ser exportada: malware não consegue lê-la, e nenhuma operação de software consegue extraí-la.
Privacidade como Parte do Projeto
Um ponto que merece destaque é como o DBSC foi projetado para não comprometer a privacidade do usuário em troca de segurança.
O protocolo não transmite identificadores de dispositivo ou dados de atestação para o servidor: ele compartilha apenas a chave pública por sessão necessária para verificar a prova de posse. Essa restrição impede que o DBSC funcione como um mecanismo de impressão digital de dispositivo ou que permita rastreamento entre sites.
Cada sessão tem sua própria chave criptográfica. Isso impede que sites usem o DBSC para correlacionar a atividade de um usuário em diferentes sessões ou em diferentes sites no mesmo dispositivo. Foi desenvolvido de forma aberta, através do processo W3C e adotado pelo Web Application Security Working Group. O Google trabalhou com a Microsoft no design do padrão.
O que o DBSC Não Consegue Fazer: os Limites Reais
Nenhuma análise honesta dessa tecnologia está completa sem abordar o que ela não resolve. Esse ponto é onde o texto original era mais deficiente, ao sugerir que a proteção “é extremamente robusta” sem qualificar adequadamente os limites reais.
Acesso em Tempo Real Enquanto o Malware Está Ativo
O DBSC não impedirá o acesso temporário à sessão do navegador enquanto o atacante estiver residente no dispositivo do usuário. A chave privada deve ser armazenada tão seguramente quanto os sistemas operacionais modernos permitem, impedindo a exfiltração da chave privada de sessão, mas a capacidade de assinatura provavelmente ainda estará disponível para qualquer programa rodando como o usuário no dispositivo do usuário.
Em termos simples: o DBSC torna inútil o cookie roubado depois que ele sai do computador. Mas enquanto o malware ainda está ativo dentro da máquina, ele pode potencialmente usar a sessão em tempo real, sem precisar exportar nada.
Hardware Legado Sem TPM
Dispositivos sem suporte a TPM recorrem ao comportamento padrão. Se o dispositivo de um usuário não tem o módulo de segurança de hardware exigido, o Chrome retrocede graciosamente para o gerenciamento de sessão padrão. Isso inclui hardware mais antigo que ainda é amplamente presente em muitos ambientes corporativos e praticamente em todos os dispositivos pessoais que funcionários usam para acessar recursos corporativos fora de endpoints gerenciados pela empresa.
Cookies Já Comprometidos Antes da Ativação
O DBSC impede que novos roubos de sessão aconteçam em navegadores cobertos. Ele não faz nada para revelar ou remediar o que já foi coletado. Os 51,7 milhões de pacotes de credenciais documentados em 2025 já estão circulando em mercados clandestinos. O DBSC não invalida retrospectivamente esses dados.
macOS Ainda Aguardando a Versão Estável
Usuários do macOS se beneficiarão desse recurso de segurança em uma versão futura do Chrome que ainda não foi anunciada. Até lá, os usuários de Mac continuam com as proteções anteriores, incluindo a App-Bound Encryption (Criptografia Vinculada ao Aplicativo), que já oferece uma camada de proteção, mas sem o nível de garantia de hardware do DBSC completo.
Comparativo: Antes e Depois do DBSC
| Cenário | Chrome sem DBSC | Chrome com DBSC (Chrome 146+) |
|---|---|---|
| Malware exfiltra cookie | Cookie funciona em qualquer dispositivo | Cookie expira em minutos, é inútil em outro dispositivo |
| Atacante tenta usar cookie roubado | Acesso garantido, mesmo com 2FA ativo | Falha na prova de posse, acesso bloqueado |
| Malware ativo no dispositivo | Acesso à sessão disponível | Acesso ainda possível em tempo real |
| Dispositivo sem TPM | Proteção padrão | Mesma proteção padrão (DBSC não disponível) |
| Cookie já roubado antes do DBSC | Inválido sem ação adicional | Inválido sem ação adicional (não revoga retroativamente) |
Como Verificar se Você Está Protegido
Requisitos para o DBSC Funcionar
Para que o DBSC esteja ativo no seu Chrome, três condições precisam ser atendidas simultaneamente:
A primeira é estar usando o Chrome 146 ou superior no Windows. A segunda é ter um dispositivo com TPM 2.0, requisito padrão de qualquer computador com Windows 11 certificado. A terceira é que o site que você está acessando precisa ter implementado o suporte ao DBSC do lado do servidor.
Esse terceiro ponto é o fator limitante no momento do lançamento. O Google vem executando uma versão anterior do protocolo em suas próprias propriedades ao longo do último ano. Para sessões protegidas pelo DBSC, o Google observou uma redução mensurável no roubo de sessão desde o início da implantação. Mas outros sites precisam adotar ativamente o padrão para que seus usuários se beneficiem.
Como Atualizar o Chrome
Para confirmar e atualizar a versão do Chrome, clique nos três pontos no canto superior direito do navegador, selecione Ajuda e depois Sobre o Google Chrome. O navegador verificará automaticamente se há uma versão mais recente disponível e instalará a atualização. Após a atualização, o recurso não requer configuração manual pelo usuário: quando o dispositivo suporta TPM, o Chrome ativa o DBSC automaticamente para os sites compatíveis.
Extensões de Navegador: o Vetor de Ataque que o DBSC Não Elimina
Um ponto de atenção que o texto original abordava superficialmente merece mais profundidade: as extensões do Chrome são um vetor de ataque que o DBSC, por si só, não resolve completamente.
Extensões do Chrome operam dentro do próprio navegador e podem, dependendo das permissões concedidas, acessar cookies e dados de sessão diretamente, sem precisar passar pelo sistema de arquivos ou pela memória do sistema operacional, que é onde o DBSC faz sua defesa. Isso significa que uma extensão maliciosa instalada pelo usuário pode, teoricamente, acessar cookies de sessão antes de eles serem vinculados ao TPM.
A melhor prática continua sendo a mesma: revise as permissões de cada extensão antes de instalar. Se uma extensão solicita acesso para “ler e alterar todos os seus dados nos sites que você visita”, ela tem acesso muito amplo. Prefira extensões de desenvolvedores conhecidos e com histórico público verificável, e remova extensões que você não usa mais.
A Jornada que Chegou Até Aqui
O DBSC estava disponível em beta desde abril de 2024, quando foi anunciado pela primeira vez como uma forma de vincular criptograficamente cookies de sessão a um dispositivo específico. O trabalho de desenvolvimento levou dois anos de colaboração entre equipes do Google, revisão técnica no W3C e um período de testes em escala nas próprias propriedades do Google antes de o recurso ser liberado para todos os usuários.
Segundo a equipe de Segurança de Contas do Google, o DBSC muda fundamentalmente a capacidade da web de se defender contra essa ameaça, deslocando o paradigma da detecção reativa para a prevenção proativa, garantindo que cookies exfiltrados com sucesso não possam ser usados para acessar as contas dos usuários.
Essa distinção entre reativo e proativo é a contribuição mais importante do DBSC para o ecossistema de segurança digital. As proteções anteriores detectavam o abuso de cookies roubados depois que o dano havia acontecido. O DBSC torna o dado roubado inútil antes mesmo de o atacante tentar usá-lo.
Boas Práticas que Continuam Sendo Essenciais
O DBSC é uma camada de proteção significativa, mas não substitui hábitos digitais saudáveis. Confira o que ainda é fundamental:
Manter o Chrome sempre atualizado continua sendo a ação mais simples e impactante que qualquer usuário pode tomar. As atualizações automáticas do Chrome aplicam correções de segurança silenciosamente, sem que você precise fazer nada.
Baixar software apenas de fontes oficiais é o principal fator de risco para infecção por infostealer. A grande maioria dessas infecções começa com um arquivo executável baixado de um site não oficial ou recebido por e-mail ou mensagem. Crackers de software, cheats para jogos e geradores de licença são os vetores mais comuns.
Usar um gerenciador de senhas, como o próprio Google Password Manager, o Bitwarden ou o 1Password, garante que cada conta tenha uma senha única e complexa. Isso continua sendo relevante porque o DBSC protege sessões já autenticadas, mas não protege o login inicial.
Manter o sistema operacional atualizado garante que os próprios mecanismos de TPM e Secure Enclave estejam com os drivers e firmwares mais seguros disponíveis.
Revisar periodicamente os aplicativos e extensões instalados remove vetores de ataque que poderiam ser usados antes que o DBSC entre em ação.
Perguntas Frequentes Sobre Cookies de Sessão e DBSC
O que é um cookie de sessão?
Cookies de sessão são identificadores emitidos pelo servidor de um site após a autenticação bem-sucedida do usuário. Eles são armazenados no navegador e apresentados automaticamente nas requisições seguintes, permitindo que o usuário permaneça logado sem precisar inserir a senha repetidamente. A diferença para cookies persistentes comuns é que os cookies de sessão, em teoria, deveriam expirar quando a sessão termina, mas muitos sites os emitem com longas durações de validade para melhorar a experiência do usuário, o que cria a janela de exposição que os infostealers exploram.
Como saber se um site já suporta o DBSC?
No momento do lançamento, o Google e alguns grandes parceiros são os primeiros a implementar o protocolo do lado do servidor. A adoção por outros sites acontece gradualmente. Como o protocolo foi desenvolvido de forma aberta pelo W3C, qualquer desenvolvedor web pode implementá-lo seguindo a especificação pública disponível em w3c.github.io/webappsec-dbsc.
Extensões podem roubar meus cookies mesmo com o DBSC ativo?
Extensões que operam com permissões amplas dentro do Chrome podem acessar dados de sessão num nível que precede a proteção do DBSC. A recomendação é sempre verificar as permissões antes de instalar qualquer extensão e remover as que não são mais utilizadas.
A proteção é 100% garantida?
Não existe proteção absoluta em segurança digital. O DBSC resolve de forma eficaz o vetor específico de roubo e reutilização de cookies em outros dispositivos. Porém, como detalhado anteriormente, ele não protege contra acesso em tempo real enquanto um malware está ativo no sistema, nem funciona em hardware sem TPM. A segurança digital é sempre uma combinação de tecnologia e comportamento.
Uma Mudança Real, com Limites Reais
O DBSC representa uma mudança genuinamente significativa na arquitetura de segurança do Chrome. Por anos, o roubo de cookies de sessão foi um vetor de ataque que o próprio Google admitia não conseguir bloquear apenas com software. A solução encontrada, ancorar a sessão em hardware criptográfico que não pode ser exportado, muda essa equação de forma estrutural.
Um cookie de sessão é essencialmente o próprio token de autenticação. Emitido pelo servidor após o login, ele é automaticamente anexado às requisições subsequentes para manter o estado de “logado”. O problema: esses cookies ficam em arquivos e memória em formato praticamente legível. Infostealers como o LummaC2 leem cookies de arquivos locais e memória em dispositivos comprometidos, então os exfiltram para servidores controlados pelos atacantes. O atacante simplesmente define o cookie roubado no próprio navegador e está logado na conta da vítima, sem precisar de senha.
O DBSC quebra essa lógica ao nível do hardware. Mas ele não elimina todos os riscos: não revoga dados já comprometidos no passado, não funciona sem TPM, não protege contra malware ativo em tempo real e depende de adoção do lado dos servidores dos sites.
Para o usuário comum, a ação mais importante permanece simples: mantenha o Chrome atualizado para a versão 146 ou superior no Windows e adote as boas práticas de higiene digital descritas neste artigo. O DBSC trabalha em silêncio nos bastidores, sem que você precise configurar nada, desde que o hardware e o software estejam nas versões corretas.
Quer ficar por dentro das próximas atualizações de segurança do Chrome e das melhores práticas de proteção digital? Acompanhe nosso blog para análises técnicas acessíveis sobre o universo da cibersegurança.
Fontes e Referências
Google Workspace Updates: Prevent account takeovers with DBSC
Google Security Blog: Protecting Cookies with Device Bound Session Credentials
BleepingComputer: Google Chrome adds session cookie theft protection for all users
BleepingComputer: Google Chrome adds infostealer protection against session cookie theft
Help Net Security: To counter cookie theft, Chrome ships device-bound session credentials
Privacy Guides: Google Chrome Adding Protection Against Cookie-Stealing Malware
Constella Intelligence: Google Fixed Session Cookie Theft in Chrome. Here Is What It Cannot Stop.
pbxscience.com: Chrome 146 Deploys Device-Bound Sessions to Defeat Cookie Theft
Hackread: Google Chrome Update Disrupts Infostealer Cookie Theft
Aviatrix AI: Google Chrome 2026 DBSC infostealer protection
Lilting.ch: How Chrome 146’s DBSC uses TPM to neutralize session cookie theft
W3C: Device Bound Session Credentials specification
Chrome for Developers: Device Bound Session Credentials (DBSC)
Google Workspace Admin Help: Prevent cookie theft with session binding
