Roubo de cookie de sessão: o ataque que ignora seu 2FA

Em janeiro de 2023, a CircleCI divulgou uma violação que deixou a comunidade de segurança desconfortável por um motivo específico: o atacante não quebrou nenhuma senha, não explorou nenhum zero-day e não precisou de um único código de autenticação. Um malware instalado no dispositivo de um funcionário extraiu o token de sessão SSO protegido por 2FA e, com esse cookie em mãos, manteve acesso irrestrito à infraestrutura da empresa por semanas. O segundo fator foi completamente ignorado — não porque estivesse mal configurado, mas porque o ataque aconteceu depois do login.

Esse é o session hijacking via roubo de cookie. E é, segundo o Bleeping Computer, o principal objetivo dos infostealers modernos — mais do que senhas em si.

O que é um cookie de sessão

Quando você faz login em qualquer serviço — Gmail, GitHub, banco digital, conta do trabalho — o servidor gera um identificador único chamado cookie de sessão e o envia ao seu navegador. Esse cookie funciona como um crachá temporário: em vez de pedir sua senha e 2FA a cada clique, o servidor verifica o cookie e confirma "esse navegador está autenticado".

O problema é que o crachá é transferível. Se alguém copiar esse cookie e apresentá-lo ao servidor de outro dispositivo, o servidor não tem como distinguir o titular original do impostor — afinal, o crachá é válido. A autenticação já aconteceu. O 2FA já foi aprovado. O cookie é a prova disso.

Como o roubo acontece na prática

Existem três formas principais de roubar cookies de sessão ativos:

Infostealers que extraem cookies do disco

Navegadores como Chrome, Firefox e Edge armazenam cookies em arquivos de banco de dados SQLite no perfil local do usuário. Infostealers — malwares projetados especificamente para coleta de credenciais — leem esses arquivos diretamente, descriptografam os valores (usando as chaves do sistema operacional) e exportam tudo para o servidor do atacante.

O Storm, um infostealer que surgiu em redes de crime cibernético no início de 2026, oferecia exatamente essa capacidade por menos de US$ 1.000 por mês em modelo de assinatura, incluindo extração de cookies, credenciais salvas e carteiras de criptomoedas. Não é um malware sofisticado — é barato, disponível e eficaz porque a maioria dos usuários não espera que arquivos locais do navegador sejam um vetor de ataque.

Esse tipo de ameaça se encaixa na categoria dos malwares que dificilmente o antivírus tradicional flagra, especialmente quando executados rapidamente e depois removidos.

Extensões maliciosas no navegador

Uma extensão instalada no navegador tem acesso nativo aos cookies de qualquer domínio que a permissão dela abranger. Extensões maliciosas no Chrome já foram flagradas exfiltrando tokens de autenticação silenciosamente, sem nenhuma interação do usuário além da instalação inicial.

A diferença em relação ao infostealer é que a extensão não precisa nem mesmo descriptografar nada — ela opera dentro do contexto do navegador, onde os cookies já estão decifrados e disponíveis via API.

XSS e interceptação em redes abertas

Cross-site scripting (XSS) permite que um atacante injete código JavaScript numa página vulnerável e leia cookies que não têm a flag HttpOnly configurada. Em redes sem HTTPS — ainda existentes em alguns serviços legados — cookies podem ser capturados em trânsito por interceptação de rede. Ambos os vetores têm mitigações técnicas do lado do servidor (flags de segurança nos cookies, HTTPS obrigatório), mas dependem de implementação correta por parte dos desenvolvedores do serviço, não do usuário final.

Por que 2FA não protege contra session hijacking?

O 2FA autentica o login, não a sessão. Uma vez que o servidor emite o cookie após um login bem-sucedido com o segundo fator, aquele cookie representa uma sessão já autenticada. O servidor não repede o 2FA a cada requisição — seria inviável. Então, ao apresentar o cookie roubado de outro dispositivo, o atacante chega depois do portão de autenticação, num momento em que o 2FA já cumpriu (e encerrou) seu papel.

Isso é diferente de ataques como MFA fatigue, que tentam enganar a vítima para aprovar o segundo fator. No session hijacking, o 2FA sequer é chamado — o atacante pula essa etapa inteira.

Como se proteger: 6 medidas concretas

Do lado do usuário, é possível reduzir bastante a superfície de ataque:

• Faça logout explícito em serviços sensíveis ao terminar a sessão. O logout invalida o cookie no servidor — um cookie roubado de uma sessão encerrada não funciona mais.
• Verifique sessões ativas periodicamente. Google, GitHub, Microsoft e a maioria dos serviços importantes mostram onde sua conta está logada. Encerre sessões desconhecidas imediatamente.
• Evite extensões desnecessárias. Cada extensão instalada é uma superfície de ataque. Remova as que não usa e prefira as publicadas por organizações verificadas, com histórico longo e poucos usuários de permissões excessivas.
• Mantenha o endpoint protegido. Um infostealer que nunca é executado não rouba nada. Manter o Windows com as configurações de segurança corretas, antivírus atualizado e SmartScreen ativo reduz significativamente o risco de execução de malware.
• Use HTTPS em todo lugar. Em 2026 isso é quase garantido, mas ainda existem serviços legados sem HTTPS. Se o cadeado não aparecer na barra de endereços, não insira credenciais nem confie em sessões.
• Considere passkeys. As passkeys FIDO2/WebAuthn eliminam cookies de sessão vinculados a credenciais tradicionais. A autenticação é vinculada ao dispositivo por criptografia assimétrica, e o token resultante não é exportável da mesma forma que um cookie convencional.

O que o Chrome 146 fez para mitigar

O Google lançou no Chrome 146 (Windows) o Device Bound Session Credentials (DBSC), uma proteção que vincula criptograficamente o cookie de sessão ao dispositivo onde ele foi criado. Na prática, mesmo que um infostealer consiga extrair o cookie do disco, ele não consegue usá-lo em outro dispositivo — a apresentação do cookie exige uma prova de posse da chave privada que nunca sai do chip de segurança do hardware.

O DBSC não é mágica: exige suporte do servidor (os serviços precisam adotar o protocolo), e a proteção é limitada a cenários em que o cookie é usado de outro dispositivo. Se o atacante operar no mesmo dispositivo comprometido, o DBSC não ajuda. Mas representa um avanço real contra o vetor de infostealer clássico, que é exatamente o mais prevalente.

A lição que fica

Segurança de autenticação vai além do momento do login. O token que você recebe depois de se autenticar com senha, 2FA e biometria é tão valioso quanto a senha em si — e muitas vezes menos protegido. Tratar cookies de sessão como credenciais descartáveis (fazer logout, verificar sessões ativas, manter o dispositivo limpo) é a defesa mais eficaz que o usuário final tem hoje, enquanto a indústria padroniza proteções como o DBSC.

Se quiser entender os outros vetores pelos quais atacantes burlam autenticação moderna, o post sobre MFA fatigue e push bombing cobre o lado da engenharia social — o complemento direto do que vimos aqui.