Resumo: reuso de token de sessao apos autenticacao entre dispositivos
- A lacuna: Cada pitch trata MFA como linha de chegada. O roubo de cookies desmonta o blefe. MFA autentica o evento de login, e um cookie de sessao roubado e o recibo que prova que o login ja ocorreu, entao o servidor entrega a conta sem novo pedido.
- A evidência: A SpyCloud recuperou mais de 17 bilhoes de registros de credenciais roubadas do submundo criminal em 2024, e o DBSC so cobre o Chrome 146+ no Windows. cside faz fingerprint de dispositivos com mais de 250 sinais a 99,7% de precisao para pegar o momento em que um cookie e reproduzido da maquina errada.
- A decisão: Qualquer time que confie em MFA mais HttpOnly para proteger sessoes vivas esta exposto. Adicione neste trimestre monitoramento runtime de scripts para exfiltracao de tokens e scoring comportamental a nivel de dispositivo, antes que uma venda de infostealer no Telegram vire seu incidente.
Sem tempo? Veja a deteção de account takeover da cside. Cobre tudo o que se segue numa única implementação.
Roubo de cookie é quando um atacante captura o token de sessão que um site emitiu após um utilizador ter feito login e o reproduz noutro dispositivo. O atacante herda o acesso do utilizador sem conhecer a sua senha. Nenhum prompt de MFA é acionado. O utilizador permanece autenticado e não nota nada; ambas as sessões correm em paralelo.
A razão pela qual o MFA não impede isto é estrutural. O MFA autentica o utilizador no evento de login. Após o login, o servidor depende do cookie de sessão, uma credencial com prazo que prova que o browser já passou pela autenticação. Um cookie roubado é prova de que o browser já passou. O servidor não consegue distinguir o utilizador real do atacante a menos que verifique algo além do token em si.
Os investigadores de segurança chamam a isto um ataque pass-the-cookie. É a técnica dominante por trás de uma grande parcela de comprometimentos de contas em 2026.
Como funciona o sequestro de sessão
A cadeia de ataque é a mesma independentemente de como o cookie foi obtido.
- O utilizador autentica-se. O browser completa o login e o MFA. O servidor emite um cookie de sessão, uma string aleatória longa, e devolve-o com a resposta.
- O atacante captura o cookie. Isto acontece através de malware infostealer, um proxy de phishing, ou um script malicioso a correr na página.
- O atacante reproduz o cookie. A partir do seu próprio browser ou de um script, define o cookie roubado e envia um pedido ao site alvo.
- O servidor vê uma sessão válida. O cookie está ativo e foi emitido para um utilizador autenticado. O acesso é concedido.
A sessão legítima permanece aberta. O utilizador ainda está a navegar no seu dispositivo; o atacante está a navegar na mesma conta no dele.
Três formas como atacantes roubam tokens de sessão
Malware infostealer
O malware infostealer é a rota mais comum. Famílias como Lumma, Vidar e RedLine varrem o armazém de cookies em disco do browser, extraem tokens de sessão de centenas de sites e transmitem-nos para um servidor controlado pelo atacante em minutos após a infeção. O Relatório Anual de Exposição de Identidade 2025 da SpyCloud recapturou mais de 17 mil milhões de registos de credenciais roubados do submundo criminal em 2024. Cookies de sessão roubados chegam a mercados no Telegram horas após uma infeção bem-sucedida.
O armazém de cookies do browser é um ficheiro local, texto simples ou uma base de dados SQLite local. Qualquer processo a correr com os privilégios do utilizador pode lê-lo. Os infostealers não intercetam tráfego de rede; leem do disco depois de o browser já ter desencriptado os dados.
Phishing adversary-in-the-middle (AiTM)
O phishing AiTM coloca um proxy reverso entre a vítima e a página de login real. A vítima vê uma cópia visual exata do login, introduz as credenciais e completa o MFA. O proxy encaminha tudo para o site real e captura o cookie de sessão resultante no caminho de volta. O atacante possui agora um token pós-autenticação válido sem ter passado pelo MFA.
Esta técnica derrota os controlos tradicionais anti-phishing porque a página parece autêntica, o prompt de MFA é completado contra o serviço real e a vítima faz login normalmente. Apenas o proxy do atacante fica no meio, invisível.
Scripts maliciosos de terceiros e XSS
Uma vulnerabilidade XSS ou um script de terceiros comprometido pode extrair tokens de sessão do browser em tempo de execução. JavaScript a correr no contexto de origem da página pode ler cookies sem a flag HttpOnly, codificá-los e exfiltrá-los em pedidos que parecem chamadas de análise de rotina.
Este é o vetor da cadeia de fornecimento do lado do cliente: o atacante não tem como alvo o site diretamente, mas compromete uma tag de análise, widget de chat ou biblioteca de pagamento que o site confia e carrega em todas as páginas. O skimmer chega dentro de código que o site já considera seguro.
Por que os mecanismos de defesa padrão falham
A flag HttpOnly
HttpOnly impede que o JavaScript leia o cookie via document.cookie. Bloqueia leituras de tokens XSS para esse cookie específico, o que importa. Mas não faz nada contra malware infostealer que lê o cookie diretamente do disco depois de o browser o ter armazenado, e não protege contra um proxy AiTM que captura o token pela rede antes de chegar ao armazém protegido.
HTTPS e TLS
O TLS encripta o tráfego em trânsito e impede a interceção passiva de rede. Os infostealers leem do disco, após a desencriptação. Os proxies AiTM terminam o TLS em ambos os lados da ligação. Nenhum é impedido apenas pela encriptação do transporte.
MFA
O MFA verifica o utilizador no login. Após o login, o servidor depende apenas do cookie. Um cookie roubado nunca aciona outro prompt de MFA a menos que o servidor force a reautenticação com base em sinais de dispositivo ou comportamentais, o que a maioria dos servidores não faz em cada pedido.
Sessões vinculadas ao dispositivo e DBSC
A correção estrutural para ataques pass-the-cookie é vincular a sessão ao hardware que a criou. Um cookie roubado torna-se inútil se o servidor exigir prova criptográfica de que o browser ainda controla uma chave privada específica do dispositivo.
O protocolo Device Bound Session Credentials (DBSC) do Google faz isso usando o TPM ou Secure Enclave do dispositivo. No Chrome 146+ para Windows, o browser gera uma chave privada em hardware durante o estabelecimento da sessão. Cookies de sessão de curta duração são emitidos apenas enquanto o browser puder provar a posse dessa chave. Um atacante que rouba o cookie noutro dispositivo não consegue renová-lo sem a chave privada.
O DBSC é um avanço significativo contra ataques de reprodução. Os limites práticos em meados de 2026:
- Cobertura: Chrome 146+ no Windows é o principal deployment. iOS, Firefox e Safari ainda não suportam DBSC.
- Caminhos de fallback: quando não há TPM presente ou ocorre um erro de rede durante a verificação da chave, o DBSC pode ignorar o binding. Essa sessão comporta-se então como um cookie convencional.
- Malware no dispositivo: se um infostealer corre no mesmo dispositivo que detém a chave privada, o atacante pode usar a sessão nesse dispositivo. O DBSC aborda a reprodução fora do dispositivo, não o comprometimento no mesmo dispositivo.
Estas lacunas significam que o DBSC é uma camada, não uma solução completa.
Prevenção do sequestro de sessão: uma lista de verificação em camadas
| Controlo | O que impede |
|---|---|
| TLS + HSTS | Interceção de rede (session sidejacking) |
| Flags HttpOnly, Secure, SameSite | Leituras XSS via document.cookie |
| Rotação do ID de sessão após login | Fixação de sessão |
| Timeouts absolutos e de inatividade curtos | Janela para reprodução após roubo |
| Tokens de sessão aleatórios longos | Adivinhação de tokens |
| Revogação do lado do servidor no logout | Sessões ativas após ação na conta |
| DBSC (Chrome 146+ / Windows) | Reprodução fora do dispositivo de cookie roubado |
| Monitorização de scripts do lado do cliente | Exfiltração de tokens via XSS ou cadeia de fornecimento |
| Inteligência de dispositivo + pontuação comportamental | Token reproduzido que chega à sessão em direto |
Nenhum controlo individual é completo. Os infostealers derrotam os controlos de transporte. Os proxies AiTM derrotam o MFA e o HTTPS na camada de sessão. O HttpOnly limita um vetor de leitura JavaScript mas não as leituras de disco. O modelo em camadas funciona porque cada controlo derrota o que os outros falham.
Detetar uma sessão sequestrada no browser em direto
A prevenção reduz a probabilidade de roubo de tokens. A deteção apanha a sessão que já foi roubada e está a ser reproduzida.
O cside corre como um único snippet JavaScript de primeira parte no browser do visitante sem proxy e sem alterações de DNS. Monitoriza o que scripts de terceiros e a própria sessão fazem na página em direto para utilizadores reais, não o que um crawler ou scanner observa em repouso de código.
Exfiltração de tokens na origem. Um script de terceiros que anexa event listeners inesperados a campos de formulário, lê valores de cookies fora de chamadas de análise normais, ou envia dados para um domínio desconhecido aciona um sinal de deteção antes de o token sair da página. Isto fecha o vetor XSS e da cadeia de fornecimento antes de um cookie ser roubado. A mesma monitorização em tempo real também deteta o stuffing de cookies de afiliado e o sequestro de links, onde scripts injetados colocam cookies de afiliado controlados pelo atacante ou reescrevem links de saída para redirecionar a atribuição, um ataque de camada do browser igualmente invisível.
Discrepância de dispositivo na reprodução. Quando um cookie roubado é usado noutro dispositivo, a fingerprint da sessão muda. A inteligência de dispositivo do cside constrói um ID de dispositivo persistente a partir de mais de 250 sinais de browser, hardware e rede com 99.7% de precisão. Uma discrepância de fingerprint após uma sessão estabelecida é uma anomalia que a camada de pontuação comportamental sinaliza para reautenticação ou bloqueio.
Sinais comportamentais. A reprodução automática de sessão a partir de um script ou agente de IA produz padrões que diferem de sessões humanas reais: sem movimento de rato realista, sem variância de scroll, sem cadência de digitação natural. Os sinais comportamentais do cside separam a automação do uso genuíno.
O cside também integra deteção de agentes de IA, apanhando ferramentas de orquestração e browsers automatizados que reproduzem sessões roubadas ou executam acesso scriptado a contas em escala.
PCI DSS 4.0.1 e segurança de sessão em páginas de pagamento
Para plataformas de e-commerce e pagamento, os vetores de script do lado do cliente e XSS que exfiltram tokens de sessão são os mesmos riscos que os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 visam. O requisito 6.4.3 obriga a um inventário de scripts e método de autorização para cada script em páginas de pagamento. O requisito 11.6.1 exige monitorização contínua e alertas sobre alterações não autorizadas a scripts de páginas de pagamento e cabeçalhos de segurança HTTP.
Um script malicioso de terceiros que exfiltra um token de sessão ou dados de cartão de pagamento numa página de checkout é precisamente a ameaça que esses requisitos endereçam. O cside automatiza ambos os controlos e produz relatórios semanais prontos para QSA (validados pela VikingCloud). A monitorização que apanha um script malicioso a roubar tokens de sessão também satisfaz o mandato de deteção de adulteração que os QSA agora avaliam.
Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 são obrigatórios e têm sido avaliados desde 1 de abril de 2025.
