Ataque AiTM e roubo de token MFA

O atacante não precisa de fabricar um site falso: instala um servidor web que faz passar os pacotes HTTP entre a vítima e o serviço visado, nos dois sentidos¹. A página contém duas sessões TLS distintas, uma com a vítima e outra com o site verdadeiro, o que lhe permite extrair dos pedidos as palavras-passe e, mais importante, os cookies de sessão¹.

Este trabalho pode ser automatizado com kits de código aberto. A Microsoft cita o Evilginx2, o Modlishka e o Muraena¹. A MITRE esclarece que o Evilginx2 pode servir de retransmissor AiTM entre um site legítimo e uma pessoa vítima de phishing para capturar credenciais, tokens de autenticação e cookies de sessão⁵. Depois de obter o cookie, o atacante injeta-o no seu próprio navegador para saltar a autenticação, mesmo que a MFA do alvo esteja ativada¹.

No início, há uma mensagem. A MITRE descreve o correio eletrónico com ligação armadilhada, que serve nomeadamente para evitar as defesas que inspecionam anexos⁶. Na campanha estudada pela Microsoft, o correio trazia um anexo HTML e anunciava uma mensagem de voz¹. A página mostrava uma barra de transferência da mensagem, mas a barra estava escrita de forma fixa no ficheiro: nenhum ficheiro de áudio era transferido¹. A vítima era depois redirecionada para uma página que pré-preenchia o seu endereço de correio eletrónico, o que reforçava a credibilidade da armadilha¹.

Segue-se a página de início de sessão, cópia do portal da Microsoft. Depois de introduzidas as credenciais e concluída a autenticação, a vítima chegava à página verdadeira office.com¹. Nada assinala a interceção: em segundo plano, o atacante já tinha intercetado as credenciais e aberto uma sessão por sua vez¹.

Eis uma ilustração neutralizada da forma de um endereço destes, para mostrar que só o endereço denuncia a armadilha:

Ilustração (endereço neutralizado, inventado para o exemplo):
hxxps://login[.]exemple-portail[.]invalid/[identificador da vítima]
Página apresentada: [cópia do formulário de início de sessão da Microsoft]
Endereço esperado: [o endereço oficial do serviço, escrito ou guardado por si]

Um serviço web abre uma sessão depois da autenticação, para não voltar a pedir a identidade em cada página. Essa sessão assenta num cookie fornecido pelo serviço de autenticação, que prova ao servidor que o utilizador tem sessão iniciada¹. A MITRE refere que estes cookies permanecem muitas vezes válidos durante muito tempo, mesmo quando a aplicação não está a ser usada ativamente⁷. Um atacante que tenha um pode importá-lo para um navegador que controla e iniciar sessão na aplicação².

Na campanha de 2022, os cookies traziam uma declaração MFA: o atacante servia-se deles para aceder à conta apesar da política MFA da organização¹. A MITRE cita também um caso em que o APT29 usou cookies roubados para aceder a recursos na nuvem, e um cookie duo-sid forjado para contornar a MFA de uma conta de correio eletrónico, durante o comprometimento da SolarWinds².

Do lado da defesa, a CISA classifica as formas de MFA da mais forte à mais fraca. Os códigos de utilização única de uma aplicação são vulneráveis ao phishing, tal como os SMS e as chamadas de voz³. As notificações push com introdução de um número resistem ao «push bombing», mas não ao phishing³. Só a FIDO/WebAuthn é, segundo a CISA, a autenticação resistente ao phishing amplamente disponível³. O NCSC britânico dedica um guia aos métodos de MFA mais sólidos⁸. A Microsoft recomenda ainda políticas de acesso condicional, avaliadas a cada tentativa de utilização de um cookie roubado (dispositivo conforme, endereço IP de confiança)¹.

Julho de 2022: uma campanha dirigida a mais de 10 000 organizações

A 12 de julho de 2022, a Microsoft publica a análise de uma campanha de phishing AiTM em grande escala. Roubou palavras-passe, desviou sessões e ignorou a autenticação mesmo quando a MFA estava ativada. Segundo os dados da Microsoft, tentou atingir mais de 10 000 organizações desde setembro de 2021¹. Os atacantes imitavam a página de autenticação em linha do Office, com o kit Evilginx2¹.

Depois do roubo: a fraude por transferência

Os atacantes serviam-se depois das credenciais e dos cookies roubados para aceder a caixas de correio e lançar fraudes por transferência (BEC) contra outros alvos¹. A Microsoft observou que cinco minutos podiam bastar entre o roubo e o início da fraude¹. Nos dias seguintes, o atacante consultava de poucas em poucas horas os correios e anexos financeiros, procurava conversas em curso e depois apagava o correio de phishing inicial¹.

Criava depois uma regra da caixa de entrada que movia para «Arquivo», marcadas como lidas, as mensagens vindas do domínio do alvo da fraude, para que o titular não visse nada¹. Por fim, respondia aos fios de conversa sobre pagamentos e faturas e apagava as suas respostas dos itens enviados¹. Numa ocasião, conduziu várias tentativas em paralelo a partir da mesma caixa¹.