Roubo de cookie de sessao: como o atacante pula o MFA

O que é roubo de cookie de sessão e por que ele importa

Quando um usuário faz login em um serviço corporativo — Microsoft 365, Google Workspace, um ERP na nuvem, o portal do banco — o servidor não pede a senha novamente a cada clique. Em vez disso, ele emite um token de sessão, normalmente armazenado como cookie no navegador. Esse cookie é a prova de que aquela pessoa já se autenticou. Todo request seguinte carrega o cookie, e o servidor confia nele.

O problema é direto: se o cookie é a prova da autenticação, quem tiver o cookie tem a autenticação. Não importa se o login exigiu senha forte, aplicativo autenticador, biometria ou chave física. Tudo isso aconteceu antes da emissão do token. Uma vez que o token existe e é copiado para outra máquina, o atacante entra direto no ambiente já autenticado, sem nunca ver a senha e sem nunca acionar o segundo fator.

Esse é o motivo pelo qual o roubo de cookie de sessão — também chamado de session hijacking ou pass-the-cookie — virou a técnica preferida contra empresas que fizeram a lição de casa e habilitaram MFA. O MFA continua sendo essencial e barra a maior parte dos ataques por senha vazada. Mas ele protege o momento do login, não a sessão que nasce dele. Quem parou de investir em segurança de identidade logo depois de ligar o MFA está protegido contra o ataque de 2019, não contra o de hoje.

Como o ataque acontece na prática: AiTM e infostealers

Existem dois caminhos principais para o cookie chegar às mãos do atacante, e eles exigem defesas diferentes.

O primeiro é o phishing AiTM (Adversary-in-the-Middle). O usuário recebe um e-mail com link para o que parece ser a página de login legítima da Microsoft. Ele clica e cai em um servidor proxy controlado pelo atacante, que fica no meio do caminho: repassa cada requisição para o site verdadeiro e devolve cada resposta ao usuário. A página é idêntica porque é literalmente a página real, apenas intermediada. A vítima digita a senha, o site verdadeiro pede o segundo fator, a vítima aprova a notificação no celular — tudo funciona, o login é concluído, ela vê a caixa de entrada. Só que o cookie de sessão emitido no final desse fluxo passou pelo proxy e foi capturado. O atacante importa o cookie no navegador dele e está dentro da conta. Kits prontos como Evilginx, Modlishka e EvilProxy tornaram isso acessível para quem não sabe programar.

O segundo caminho é o infostealer — malware que roda na máquina do usuário e faz a varredura dos bancos de dados de cookies dos navegadores. Famílias como RedLine, Raccoon, Lumma e Vidar coletam cookies, senhas salvas, carteiras de criptomoeda e tokens de aplicativos, empacotam tudo e enviam para um servidor de comando. Esses pacotes são vendidos em mercados clandestinos por poucos dólares, com filtro por domínio corporativo. Uma máquina pessoal infectada em casa, usada para acessar o e-mail da empresa, é suficiente.

Na maioria dos incidentes de comprometimento de conta com MFA ativo, a senha nunca foi o elo quebrado. O elo quebrado foi a sessão que sobreviveu ao login.

Depois de entrar, o padrão de comportamento é previsível: o atacante cria regras de encaminhamento na caixa de entrada, registra o próprio dispositivo como método MFA adicional para garantir persistência mesmo se o cookie expirar, baixa arquivos do SharePoint e do OneDrive, e parte para fraude de pagamento ou movimentação lateral. Em campanhas de comprometimento de e-mail corporativo (BEC), o tempo entre o roubo do cookie e a primeira mensagem fraudulenta enviada costuma ser de horas, não dias.

Sinais de que um token foi roubado

Detectar sessão sequestrada é diferente de detectar senha vazada. Não haverá tentativa de login falha, não haverá bloqueio por força bruta, não haverá alerta de senha comprometida. A sessão parece legítima porque, tecnicamente, ela é legítima — apenas está sendo usada pela pessoa errada. A detecção precisa olhar para inconsistência de contexto.

Os indicadores mais confiáveis:

• Viagem impossível. A mesma sessão aparece em São Paulo e, quarenta minutos depois, em outro país. Nenhum deslocamento físico explica.
• Troca de user agent na mesma sessão. O token nasceu em um Chrome no Windows corporativo e passa a ser usado em um Firefox no Linux. Cookie não muda de navegador sozinho.
• Sessão ativa sem evento de autenticação correspondente. Existe atividade na conta, mas não há registro recente de login interativo. Clássico de pass-the-cookie.
• Registro de novo método MFA logo após atividade suspeita. Quase sempre é o atacante fixando acesso permanente.
• Criação de regra de encaminhamento ou de regra que move mensagens para pastas ocultas. Serve para esconder as respostas das vítimas da fraude.
• Acesso por IP de datacenter, VPN comercial ou rede de anonimização em uma conta que historicamente só acessa de banda larga residencial ou da rede da empresa.
• Consentimento concedido a um aplicativo OAuth desconhecido, técnica usada para manter acesso à caixa postal mesmo depois da sessão ser revogada.

Nada disso aparece sozinho no painel. É preciso que os logs de entrada, de auditoria e de atividade de aplicativo estejam sendo coletados, retidos por tempo suficiente e correlacionados por alguma ferramenta que dispare alerta — seja um SIEM, seja a própria detecção de risco da plataforma de identidade. Log que ninguém lê não é detecção, é arquivo morto.

Token binding e acesso condicional: as defesas que realmente barram

Detectar é o segundo passo. O primeiro é fazer com que o cookie roubado simplesmente não funcione fora da máquina de origem. É exatamente isso que o token binding faz: amarra o token de sessão a uma chave criptográfica que vive naquele dispositivo específico, normalmente protegida por hardware (TPM). O servidor não valida só o cookie — valida a prova de posse da chave. Copiar o cookie deixa de ser suficiente, porque a chave não sai do TPM. No ecossistema Microsoft, esse mecanismo aparece como Token Protection em políticas de Acesso Condicional e como PRT (Primary Refresh Token) vinculado ao dispositivo.

Complementando, um conjunto de controles reduz drasticamente a janela de exploração:

1. Exigir dispositivo compatível ou ingressado no domínio para acessar aplicações sensíveis. O cookie roubado, usado em um notebook desconhecido, é rejeitado na política antes de chegar ao aplicativo.
2. Adotar MFA resistente a phishing — FIDO2, chaves de segurança físicas, Windows Hello for Business ou certificado. Esses métodos validam o domínio de origem criptograficamente, o que quebra o proxy AiTM no momento da autenticação: o navegador se recusa a assinar para um domínio que não é o legítimo.
3. Ativar avaliação contínua de acesso (CAE), para que mudanças de risco — troca de rede, conta desabilitada, senha alterada — invalidem a sessão em minutos, em vez de esperar o token expirar naturalmente.
4. Reduzir o tempo de vida das sessões em perfis administrativos e em acessos fora da rede corporativa, aceitando o pequeno atrito em troca de janela menor.
5. Bloquear ou revisar consentimento a aplicativos OAuth de terceiros, exigindo aprovação do administrador.
6. Manter EDR ativo e atualizado nos endpoints, já que a via do infostealer começa no dispositivo, não na nuvem.
7. Restringir acesso a e-mail e arquivos corporativos a partir de equipamentos pessoais não gerenciados, ou permitir apenas em modo web restrito, sem download.

Vale destacar o procedimento de resposta, porque muita gente erra aqui: trocar a senha não encerra a sessão roubada. O token continua válido até expirar. A resposta correta a uma suspeita de sequestro de sessão é revogar explicitamente as sessões e os refresh tokens da conta, revisar e remover métodos MFA não reconhecidos, apagar regras de caixa de entrada criadas pelo atacante, revisar consentimentos OAuth e só então redefinir a credencial. Fora dessa ordem, o invasor permanece dentro enquanto o time acredita ter resolvido.

Colocando isso em prática no seu ambiente

A boa notícia é que a maior parte desses controles já está disponível nas licenças que a maioria das empresas brasileiras de médio porte contrata — falta configuração e acompanhamento, não investimento novo. A má notícia é que as configurações padrão de qualquer plataforma de nuvem são pensadas para compatibilidade e não para resistir a AiTM. Sessão longa, acesso de qualquer dispositivo, MFA por notificação push e nenhuma política de risco é o estado inicial típico. É um ambiente que passa em auditoria superficial de "MFA habilitado?" e falha no primeiro phishing bem feito.

O caminho prático é fazer por etapas, medindo impacto no usuário: primeiro habilitar coleta e retenção de logs de identidade; depois criar políticas de acesso condicional em modo somente relatório para ver o que quebraria; migrar administradores e diretoria para MFA resistente a phishing; ativar token protection e exigência de dispositivo compatível para os aplicativos mais críticos; e por fim estender ao restante da organização. Junto disso, treinar o time a reconhecer que aprovar um MFA inesperado é um evento a ser reportado, não ignorado.

A Duk Informática & Cloud trabalha com esse tipo de projeto há bastante tempo. São mais de 18 anos de atuação em infraestrutura e segurança e mais de 550 empresas atendidas, com a condição de Microsoft Gold Partner — o que significa acesso direto ao suporte e às práticas recomendadas da fabricante quando o assunto é Entra ID, Microsoft 365 e Acesso Condicional. Na prática, nossa atuação começa por um diagnóstico do tenant: como estão as políticas de identidade hoje, quais contas privilegiadas usam método fraco, se há regras de encaminhamento suspeitas ativas e quais aplicativos têm consentimento concedido. A partir daí, desenhamos e implementamos as políticas com acompanhamento, sem derrubar a operação no meio do caminho.

Roubo de cookie de sessão não é ameaça teórica nem exclusividade de grande corporação — é o método padrão contra qualquer empresa que já tenha MFA. Ligar o segundo fator foi o passo certo. Proteger a sessão que nasce depois dele é o passo que falta.