AiTM: quando o phishing rouba sua sessão, não só sua senha

Durante muito tempo, o conselho era simples: “ative a autenticação em dois fatores e o phishing não poderá mais nada contra você”. O conselho continua excelente, mas já não basta. Uma família de ataques chamada AiTM, de Adversary-in-the-Middle (“o adversário no meio”), rouba muito mais que uma senha: rouba a sessão já aberta. Vamos ver como, de um jeito simples.

O que é um ataque “Adversary-in-the-Middle”?

No phishing clássico, o site falso é uma cópia: uma página que imita a do banco ou do e-mail e guarda a senha digitada. O atacante precisa usá-la ele mesmo, mais tarde.

No ataque AiTM, o site falso não é mais uma cópia: é um intermediário. Imagine um falso atendente sentado na frente do guichê verdadeiro de um banco. Entregamos nossos documentos, ele os passa ao atendente verdadeiro, traz a resposta, e assim por diante. Tudo corre normalmente… só que ele tira cópia de tudo no caminho.

Tecnicamente, o site falso exibe a página de login verdadeira, que ele busca ao vivo no serviço real. Kits “prontos para usar” fazem esse trabalho e são alugados como uma assinatura, o que coloca a técnica ao alcance de qualquer golpista.

O roubo do cookie de sessão: a pulseira do festival

Quando entramos em um site, não digitamos a senha a cada clique. O site nos entrega um cookie de sessão, uma pequena ficha guardada no navegador que diz: “esta pessoa já se identificou”.

É o equivalente da pulseira de um festival. Na entrada, mostramos o ingresso e o documento. Depois, só mostramos a pulseira. Ninguém confere o ingresso de novo a cada show.

O ataque AiTM consiste em conseguir uma cópia dessa pulseira. O atacante não precisa mais nem da senha nem do código: cola o cookie no próprio navegador e já está dentro da conta, conectado. Por isso trocar a senha depois nem sempre basta: a pulseira roubada pode continuar valendo enquanto a sessão não for encerrada.

Por que algumas autenticações em dois fatores não bastam

A autenticação em dois fatores (2FA) acrescenta uma segunda prova à senha: um código recebido por SMS, um código de aplicativo, uma notificação para aprovar no celular. Contra uma cópia de site, é fortíssima. Contra um intermediário, bem menos: o código é válido, só foi digitado no lugar errado e repassado ao site verdadeiro em um segundo.

Os métodos que resistem são os que verificam sozinhos o endereço do site: as chaves de segurança físicas e as passkeys (chaves de acesso). Na hora do login, a chave olha com qual domínio está falando. Se não for o verdadeiro, ela simplesmente não responde. Um humano pode confundir os sites; a chave não se deixa enganar por uma semelhança.

Como reconhecer uma infraestrutura AiTM

A armadilha do AiTM é que vemos a página verdadeira: logo verdadeiro, layout verdadeiro, às vezes até o papel de parede da empresa e o nosso e-mail já preenchido. O conteúdo não entrega nada. É preciso olhar para outro lugar:

• O endereço na barra do navegador. É a única coisa que o intermediário não consegue imitar à perfeição. Uma página de login da Microsoft em login.microsoftonline.com.secure-auth.example não está na Microsoft: o domínio verdadeiro é secure-auth.example. Para ler um domínio corretamente, veja o guia Quishing: quando o phishing se esconde atrás de um QR code, e para as letras enganosas, Punycode e homógrafos.
• O gerenciador de senhas que não sugere nada. Ele preenche os campos pelo domínio, não pela aparência. Se ficar calado em uma página que normalmente conhece, é sinal de alarme.
• Um desvio antes da página: uma verificação “Você é humano?”, um ou vários redirecionamentos, um link recebido por e-mail ou por QR code.
• Um domínio novinho, criado há poucos dias, muitas vezes atrás de uma CDN ou hospedado em uma plataforma gratuita de páginas web.

Quais elementos reunir para a denúncia

Para que uma hospedagem ou um registrador aja rápido, é preciso dar fatos verificáveis. Reunimos, sem nunca digitar credenciais de novo na página:

• o endereço completo da página e toda a cadeia de redirecionamentos que leva até ela;
• um print em que apareçam ao mesmo tempo a página e a barra de endereço;
• a data e a hora da observação (essas infraestruturas mudam rápido);
• o código-fonte completo do e-mail que continha o link;
• o registrador e a data de criação do domínio, a hospedagem ou a CDN que entrega a página;
• a marca imitada: Microsoft, Google, um banco… As equipes de segurança dessas empresas aceitam esse tipo de denúncia.

Denunciar a infraestrutura com o Baitback

A campanha quase sempre começa com um e-mail. Colamos o código-fonte completo no Baitback: a ferramenta encontra o servidor de envio e o endereço de denúncia da hospedagem, segue os redirecionamentos dos links da mensagem e aponta o que não bate no destino: domínio sósia de uma marca, domínio criado recentemente, hospedagem gratuita, domínio em lista negra. Depois prepara as mensagens de denúncia prontas para enviar.

Para a página em si, enviamos os elementos reunidos ao registrador, à hospedagem ou à CDN, e às plataformas que o Baitback lembra (Google Safe Browsing, Microsoft, Netcraft…). Para entender por que um e-mail desse tipo pode passar em todas as verificações técnicas, veja Um e-mail pode mentir… mesmo quando as verificações dizem “OK”.

Se digitamos nossas credenciais em uma página AiTM

A senha não basta mais, é preciso também recuperar a pulseira:

1. trocar a senha a partir de um aparelho de confiança;
2. usar “sair de todas as sessões” ou, na empresa, pedir ao setor de TI que revogue as sessões;
3. verificar se nenhum novo método de dois fatores foi adicionado;
4. verificar as regras da caixa de e-mail: os atacantes costumam criar uma regra que encaminha ou esconde certos e-mails.