Sequestro de sessão: por que um cookie roubado vale mais que uma senha
Uma senha roubada ainda precisa passar pelo formulário de login: se a conta está protegida por autenticação multifator, a porta geralmente resiste. Um cookie de sessão roubado é outra coisa: ele é emitido depois que o login já deu certo, e tudo o que a conta faz depois é autenticado apenas pelo cookie. Essa assimetria explica por que o roubo de sessões se tornou, sem alarde, o caminho preferido para contas protegidas.
A mecânica é simples: no login, o servidor entrega ao navegador um cookie de sessão e, a partir daí, cada requisição seguinte é autenticada apenas pelo cookie. A entrada do MITRE para a técnica T1539, Steal Web Session Cookie, observa que esses cookies podem ficar “no disco, na memória do processo do navegador e no tráfego de rede”, e que quem tem um pode usar a aplicação “como um usuário autenticado sem precisar de credenciais”. A técnica complementar para a reutilização, T1550.004, registra que uma sessão reproduzida “contorna alguns protocolos de autenticação multifator, já que a sessão já está autenticada” e que os cookies “costumam ser válidos por um período prolongado”.Por que um cookie vence uma senha
Três propriedades fazem do cookie algo mais valioso que a credencial que ele substituiu. Ele já está além do muro da MFA, porque o usuário legítimo apresentou o segundo fator quando a sessão foi criada. Seu uso não gera ruído de logins malsucedidos — o atacante chega parecendo um navegador normal e autenticado. E trocar a senha não encerra necessariamente a sessão. A detecção se apoia no comportamento, não na requisição em si: o MITRE aponta reutilização de cookies “de user agents ou locais incomuns” e “cenários de viagem impossível e comportamento anômalo”. Atores estatais trabalham a mesma costura. O MITRE registra que a APT29 roubou cookies do Chrome copiando diretórios de perfis do navegador durante o comprometimento da SolarWinds e depois usou um cookie duo-sid forjado para contornar a MFA, enquanto a Star Blizzard usou cookies de sessão coletados por um proxy tipo Evilginx para alcançar caixas de e-mail de vítimas. Nada disso exigiu quebrar uma cifra ou vencer um fator — apenas uma cópia de algo que o navegador já possui.Kits AiTM fazem proxy do muro de login
A versão industrial é o kit adversary-in-the-middle. Uma página de login falsa que apenas colhe senhas morre no segundo fator. Um site AiTM, em vez disso, faz proxy do login real: a vítima se autentica normalmente pelo relay do atacante, o código é digitado e o kit recolhe o cookie de sessão emitido no fim do fluxo. A Microsoft documentou uma campanha assim em julho de 2022, construída em torno de iscas com documentos do Office e mensagens de voz, que teria afetado cerca de 10.000 organizações desde setembro de 2021 — uma campanha projetada, nas palavras da Microsoft, para “roubar senhas, sequestrar sessões abertas (roubar cookies de sessão) e contornar a MFA”. O modelo hoje funciona por assinatura. Em setembro de 2026, o BleepingComputer noticiou o BigBear 2.0, um framework de phishing-como-serviço baseado no Evilginx2 que tinha contornado a MFA em 258 organizações. Um relatório da CloudSEK citado na matéria contabilizava 5.137 registros de credenciais no painel do operador — incluindo 474 autenticações completas com MFA contornada, 1.032 senhas em texto puro e 4.148 cookies de sessão — ligados a 3.331 endereços IP únicos de vítimas em mais de 40 países. As reproduções passam por proxies residenciais compatíveis com o país de cada vítima, e o JavaScript injetado pelo kit interfere nos avisos de FIDO2/WebAuthn para empurrar as vítimas a fatores mais fracos.Logs de infostealer são inventários de cookies
O duto mais silencioso é o malware infostealer, e seu mercado girou de forma visível. O relatório de abril de 2026 do BleepingComputer sobre um stealer comercializado como Storm descreve um painel de aluguel — US$ 300 por uma demo de sete dias, até US$ 1.800 por mês num plano de equipe — cujo centro não é um dump de senhas, mas um painel de restauração de cookies que reconstrói sessões autenticadas no lado do servidor:Alimente o painel com um refresh token do Google e um proxy SOCKS5 geograficamente compatível, e o painel restaura silenciosamente a sessão autenticada da vítima.Os pesquisadores por trás do relatório observaram que o roubo de cookies de sessão vem substituindo o roubo de senhas como objetivo principal do desenvolvimento de stealers. Isso muda o que um log de stealer é: menos uma lista de credenciais para testar do que um inventário de portas já abertas, cada uma válida até a sessão expirar.
O que de fato reduz o risco
As contramedidas são sem brilho — e é em parte por isso que tantas vezes são puladas. Elas se alinham ao que Microsoft e MITRE recomendam desde as primeiras ondas AiTM:- Encurtar o tempo de vida das sessões e apagar cookies persistentes com regularidade — a mitigação do MITRE diz exatamente isso. Sessões longas de “manter conectado” são a matéria-prima desse comércio.
- Vincular sessões ao contexto de dispositivo ou rede: regras de acesso condicional que exigem um dispositivo gerenciado fazem a reprodução de um cookie cru falhar mesmo quando o cookie é autêntico.
- Detectar a reprodução: checagens de viagem impossível e alertas de anomalia de sessão pegam a maioria das reutilizações de cookies.
- Migrar contas sensíveis para autenticação resistente a phishing. Passkeys ligadas a hardware (FIDO2/WebAuthn) estão atadas ao domínio em que se faz login, de modo que um proxy AiTM não consegue retransmiti-las — é justamente por isso que kits como o BigBear tentam suprimir esses avisos.
- Fazer logout. Encerrar a sessão no servidor invalida o cookie; fechar a aba, não.