Session hijacking: como um cookie roubado contorna a tua 2FA

O que é realmente uma sessão

Quando entras num serviço, o servidor confirma a tua palavra-passe e o segundo fator uma única vez. A partir daí, entrega ao navegador um cookie, em geral um token longo e aleatório. Em cada pedido seguinte, o navegador volta a enviar esse cookie e o servidor aceita-o como prova de que já estás autenticado. É por isso que não tens de te identificar de novo em cada página que abres.

Estes tokens costumam manter-se válidos durante dias ou semanas. O Gmail aceita sessões até duas semanas, o Slack e o Discord até um ano, e algumas ferramentas SaaS pura e simplesmente não expiram. Do ponto de vista do servidor, quem apresenta o token é o utilizador legítimo, independentemente do dispositivo que o envie.

O cookie vive numa base de dados dentro do perfil do navegador, em ficheiros como Cookies ou Network State dentro da pasta de utilizador do Chrome. Qualquer programa que corra com os teus privilégios consegue lê-los. O Windows cifra alguns valores, mas fá-lo com a chave DPAPI da mesma conta, a que o programa também tem acesso.

Como os cookies são roubados hoje

Esta família de ataques chama-se infostealers. Programas como o RedLine, Raccoon, Lumma ou Stealc alugam-se como serviço por algumas centenas de dólares por mês. Ficam ativos apenas alguns segundos no computador da vítima, sugam cookies, palavras-passe, entradas de autofill e carteiras de cripto, e desaparecem sem deixar rasto visível.

A porta de entrada mais comum continua a ser o software crackado e os cheats para jogos. Por trás disso estão campanhas de malvertising, instaladores falsos de ferramentas conhecidas e programas alegadamente pirateados. Após a infeção, é preciso menos de um minuto até todos os dados do navegador estarem nas mãos do atacante.

Os pacotes roubados vão parar a marketplaces como o Russian Market, o Genesis ou o 2easy. Aí não se vende uma palavra-passe solta, vende-se um bot completo: um conjunto de cookies, fingerprint, user agent e histórico de IP. Com isso, um comprador recria o teu ambiente de navegação com fidelidade suficiente para passar por baixo do motor de risco do serviço.

Porque é que o teu segundo fator aqui não ajuda

A 2FA protege o login. Assim que o login é concluído, a sessão é emitida. O cookie diz ao servidor «já me verificaste há três dias» e o servidor acredita. Um atacante que reproduza esse cookie salta o processo de autenticação inteiro, incluindo a 2FA e qualquer passo biométrico.

Alguns fornecedores ligam a sessão ao endereço IP ou ao fingerprint do dispositivo. Isso funciona contra dispositivos claramente diferentes, mas não contra um atacante que afina fingerprint e IP para coincidirem. E é exatamente isso que os marketplaces vendem juntamente com o cookie. A tua equipa de segurança vê, na melhor das hipóteses, um login a partir da tua cidade dentro do teu horário de trabalho.

As chaves de hardware com FIDO2 ajudam no momento do login. Contra um cookie já emitido, pouco podem fazer. Nas contas verdadeiramente críticas começa a ver-se o uso de token binding (Device-Bound Session Credentials, DBSC), mas em 2026 a implantação ainda é parcial. Até lá, um cookie roubado continua a ser um cookie válido.

Como detetar um roubo

Os avisos clássicos de início de sessão não detetam nada quando o atacante reaproveita a tua sessão em vez de iniciar uma nova. Os sinais são mais subtis. E-mails enviados que não escreveste são um indicador forte. Filtros novos ou regras de reenvio que não criaste tu são quase sempre marcas deixadas pelo atacante. Se amigos te falam de uma mensagem tua de que não te lembras, o alerta é evidente.

Nos serviços que expõem a gestão de sessões (Google, GitHub, Discord), vale a pena dar uma olhada na lista de dispositivos ativos. As sessões a partir de cidades, navegadores ou sistemas operativos inesperados têm de ser revogadas de imediato. Depois muda a palavra-passe, porque o botão de logout passa por um novo login e nem sempre invalida todas as sessões já roubadas.

Se desconfias de um infostealer, mudar só as palavras-passe não chega. A ordem correta é: reinstalar ou isolar o dispositivo em modo forense, mudar as palavras-passe a partir de uma máquina limpa, invalidar todas as sessões, rodar os segredos de 2FA.

Proteger as sessões sem virar eremita

O passo mais eficaz é evitar que os cookies sensíveis cheguem sequer a existir no teu dispositivo principal. Se entrares num navegador isolado que é limpo no fim da sessão, após o logout não fica nenhum cookie em qualquer máquina que ainda esteja ligada. Um infostealer no teu portátil deixa de ter alguma coisa para roubar.

Na prática, um modelo em camadas funciona bem. Os logins do dia a dia em sites de baixo risco continuam no navegador normal. As contas de alto valor, tudo o que movimenta dinheiro, faz deploy de código, gere orçamentos de publicidade ou dá acesso a dados de clientes, abrem-se apenas dentro de uma sessão isolada. Mudar este hábito é a única coisa que verdadeiramente trava este tipo de ataque. Para uma visão de conjunto, vê How Hackers Use Your Browser History.