O ataque mais eficiente contra MFA não é quebrar MFA. É roubar o cookie de sessão e pular a autenticação inteira. Sem senha. Sem segundo fator. Acesso total. Esse vetor dominou o ecossistema de infostealers nos últimos anos. Agora, esse vetor tem data de validade. Pelo menos no Chrome.
O problema: session cookies bypassam MFA
Infostealers processaram 51,7 milhões de pacotes em 2025, um aumento de 72% em relação ao ano anterior (Constella). Dessas credenciais, 98,6% continham senhas ativas. O padrão de ataque é simples e escalável: malware rouba o cookie de sessão do browser → atacante reutiliza a sessão ativa → acesso total à conta, sem passar por autenticação.
MFA protege o login. Não protege a sessão depois do login. O cookie de sessão é a prova de que o usuário já se autenticou. Quem tem o cookie tem a sessão. Em ambientes enterprise, um único cookie do O365 ou Google Workspace pode dar acesso lateral a toda a infraestrutura. A cadeia de defesa tem um elo que ninguém estava protegendo.
Antes do DBSC, a resposta era reativa: heurísticas para detectar cookies roubados, análise de comportamento de sessão, revogação manual. Funciona parcialmente. O atacante sempre tem uma janela de oportunidade entre o roubo e a detecção.
Como DBSC funciona: binding criptográfico ao hardware
Device Bound Session Credentials (DBSC) chegou ao general availability. Google anunciou em 28 de maio de 2026: habilitado por padrão no Chrome para Windows.
O mecanismo é direto: durante a autenticação, o Chrome gera um par de chaves criptográficas dentro do chip de segurança do dispositivo. No Windows, o TPM. No macOS, o Secure Enclave (Chrome 148). A chave privada nunca sai do hardware. Não pode ser exportada, copiada ou exfiltrada por malware.
Os cookies de sessão se tornam short-lived. Quando expiram, o Chrome precisa provar posse da chave privada antes de renovar. Essa prova acontece dentro do chip de segurança — o cookie de renovação só é emitido se a prova criptográfica for válida. Sem a chave hardware-bound, o cookie roubado expira e não renova. O atacante fica com um cookie morto.
Google reportou redução significativa em session theft desde o deploy inicial. A mudança é estrutural: de reativo para proativo. Antes, detectar cookies roubados com heurísticas. Agora, cookies roubados são inúteis sem a chave que vive no hardware.
Por que DBSC é a melhoria de segurança de browser mais significativa em anos
O impacto não é incremental. DBSC invalida o vetor mais usado para bypassar MFA em escala. Infostealers evoluíram para se especializar em session cookies exatamente porque esse bypass é barato, escalável e funciona contra qualquer serviço que use cookies de sessão — ou seja, praticamente todos.
DBSC muda a economia do ataque. Antes: infostealer rouba cookie → atacante acessa conta. Depois do DBSC: infostealer rouba cookie → cookie expira → atacante não acessa. O custo do ataque não muda, mas o ROI cai a zero para esse vetor específico.
Nenhuma outra melhoria de browser nos últimos anos teve esse impacto prático. SameSite cookies mitigaram CSRF. HTTPOnly mitigaram XSS-based cookie theft. Mas nenhum dos dois resolveu o problema do roubo de cookies via malware — que é exatamente o vetor que os infostealers exploram. DBSC ataca o problema na raiz: o cookie roubado não funciona fora do dispositivo.
O que DBSC não resolve
DBSC é essencial. Não é suficiente. As limitações são reais e precisam ser enfrentadas.
Cobertura limitada. Chrome no Windows hoje. macOS chegando no Chrome 148. Mobile e outros browsers não suportam. Firefox e Safari não anunciaram suporte. A proteção cobre uma parte significativa do tráfego enterprise, mas não cobre tudo.
Infostealers roubam mais que cookies. Senhas salvas, PII, chaves SSH, configurações VPN, cloud tokens. DBSC protege a sessão. O resto continua sendo exfiltrado. Um infostealer que não consiga roubar cookies ainda rouba credenciais que podem ser usadas em credential stuffing, acesso VPN e movimentação lateral.
Credenciais já em circulação. Os 51,7 milhões de pacotes de 2025 já estão no underground. DBSC previne novos roubos de sessão. Não remedia o que já vazou. Credenciais comprometidas antes do DBSC continuam válidas até serem rotacionadas.
Dispositivos sem TPM. Sem chip de segurança, o Chrome faz fallback para comportamento padrão. Hardware antigo e dispositivos pessoais sem TPM ficam desprotegidos. Em ambientes com BYOD, isso é uma lacuna real.
Malware ativo durante o login. Se o infostealer está rodando no momento da autenticação, pode interceptar o cookie antes do binding ser concluído. É um ataque mais complexo — exige timing e persistência — mas é possível. DBSC protege contra roubo de cookies em repouso, não contra interceptação em tempo real.
Conclusão
DBSC é a melhoria de segurança de browser mais significativa em anos. Mata o vetor mais usado para bypassar MFA. Mas é uma camada, não solução completa. Infostealers continuam roubando tudo que não é cookie de sessão. E 51,7 milhões de pacotes já estão lá fora.
Na Tech86, implementamos defesa em profundidade contra infostealers — de hardening de endpoints a monitoramento de credenciais em circulação no underground. DBSC é uma camada essencial dessa defesa. Não é a única que você precisa.