A maioria dos kits de phishing é detectada da mesma forma: um fornecedor de segurança extrai a impressão digital da página, calcula seu hash, e esse hash acaba em uma lista de bloqueio que os demais fornecedores acabam herdando. É lento, mas funciona, porque a maioria dos kits entrega o mesmo HTML para todo mundo que clica no link. O analista do SANS Internet Storm Center Xavier Mertens encontrou um kit que se recusa completamente a seguir essa regra. Cada requisição para a mesma URL retorna estruturalmente diferente, o que significa que qualquer defesa baseada em hash está perseguindo um alvo que nunca fica parado. O interessante não é que a evasão funcione. É que o mecanismo construído para viabilizá-la tem falhas suficientes para se sabotar de vez em quando.
Cinquenta Requisições, Cinquenta Impressões Digitais
Mertens pegou o link de phishing de uma mensagem capturada em uma armadilha de spam e, em vez de apenas registrar e seguir em frente, escreveu um script para buscar a mesma URL cinquenta vezes seguidas e comparar o que voltava. Cada uma das cinquenta amostras produziu um hash SHA-256 distinto. Só o título da página alternou entre pelo menos 21 valores diferentes, passando por palavras deliberadamente neutras como Solution, Viewer, Credentials, Private e Authenticate, nenhuma das quais significaria algo para um analista dando uma olhada rápida no resultado de um scanner de URLs. Nomes de campos de formulário e de input, nomes de classes CSS e identificadores de elementos foram todos reembaralhados entre uma requisição e outra. Valores numéricos dentro do código foram reescritos como expressões aritméticas em vez de dígitos simples. Caracteres de largura zero foram inseridos dentro de strings por outro lado visíveis, um truque antigo para driblar regras simples de correspondência de texto que um leitor humano jamais notaria. Nada disso muda o que a página faz com um visitante. Ela existe só para garantir que nenhuma cópia se pareça com outra aos olhos de uma máquina.
O Bug Escondido Dentro do Ofuscador
Quarenta e nove das cinquenta amostras foram desofuscadas sem problemas e exibiram o formulário de credenciais conforme projetado. Uma não foi. Ficou presa em um loop infinito em vez de exibir qualquer coisa. Mertens rastreou a falha até a própria aleatorização do ofuscador: duas funções separadas dentro da cadeia de decodificação receberam nomes distintos e gerados aleatoriamente, exatamente o que se espera de um motor polimórfico, mas os loops de ambas as funções referenciavam a mesma variável não declarada, um k minúsculo. Como a variável nunca foi declarada com escopo próprio, o JavaScript a tratou como uma única variável global compartilhada em vez de dois contadores independentes, e quando as duas funções tentaram usá-la ao mesmo tempo, o loop nunca terminou. O ofuscador foi sistemático o suficiente para reescrever quase tudo o mais na página a cada passagem. Não foi disciplinado o suficiente para verificar se sua própria lógica de renomeação respeitava o escopo das variáveis, então aproximadamente um em cada cinquenta visitantes recebeu uma página quebrada em vez de uma armadilha de credenciais funcional.
Polimorfismo É um Problema de Detecção, Não um Problema de DMARC
Nada disso toca na pergunta que DMARC, SPF e DKIM existem para responder, que é se o domínio no cabeçalho From de uma mensagem tinha autoridade para enviá-la. O polimorfismo acontece inteiramente depois do clique, em infraestrutura que o atacante controla totalmente, reescrevendo a página que o navegador renderiza em vez de qualquer coisa relacionada a como o e-mail que carregava o link foi autenticado ou entregue. Uma mensagem apontando para esse kit poderia, em princípio, passar por todas as verificações de autenticação que uma caixa de entrada receptora executa e ainda assim levar um usuário a uma página construída especificamente para driblar as ferramentas de correspondência por hash e assinatura estática que ficam a jusante dessa caixa de entrada. Os protocolos de autenticação nunca foram projetados para avaliar o que um link acaba renderizando, e um kit como esse é um lembrete de exatamente quanto terreno fica além dessa fronteira, terreno que ainda vale a pena defender, só que não com as mesmas ferramentas.
O Que Isso Significa Para o Seu Programa
Não dependa de correspondência por hash ou assinatura exata como sua única defesa contra páginas de roubo de credenciais. Um kit que regenera seu HTML a cada requisição vai produzir um hash novo para cada analista, cada sandbox e cada rastreador automatizado que o tocar, transformando a impressão digital estática em uma corrida perdida por design.
Leve a inspeção de links e conteúdo além da caixa de entrada. Como o DMARC valida apenas o domínio remetente, uma pilha de segurança precisa de uma camada separada, seja detonação de links em sandbox, análise comportamental de páginas ou isolamento de navegador, que realmente avalie o que uma URL entrega quando alguém clica nela.
Trate páginas de phishing inconsistentes ou quebradas como uma oportunidade de detecção, não um beco sem saída. Os próprios bugs de um kit, como a variável compartilhada que travou uma em cada cinquenta amostras aqui, às vezes podem oferecer uma impressão digital mais confiável do que o conteúdo intencionalmente aleatorizado da página.
Continue coletando e comparando múltiplas amostras da mesma URL suspeita antes de tirar conclusões. Uma única busca de uma página polimórfica quase não diz nada sobre o kit por trás dela. A amostragem repetida, do jeito que Mertens abordou esse caso, é o que realmente revela o padrão.
A Conclusão
Um kit de phishing que reescreve seu próprio HTML a cada visita representa um salto real em quão difícil essas páginas se tornam para pegar com as ferramentas baseadas em assinatura das quais a maioria das defesas ainda depende. Também representa, na única amostra quebrada entre cinquenta, um lembrete de que atacantes constroem sob a mesma pressão e o mesmo descuido que qualquer outra pessoa, e que sofisticação em uma dimensão não garante correção em outra. Nem a evasão nem o bug têm qualquer relação com DMARC, porque ambos vivem inteiramente do outro lado do clique. Isso não é uma falha do DMARC. É um escopo, e a defesa de cada organização precisa de uma camada construída especificamente para o que fica além dele.
O DMARC diz se um domínio tinha autoridade para enviar uma mensagem. Ele não consegue dizer o que um link dentro dessa mensagem renderiza quando alguém clica, polimórfico ou não. O Excello Mail transforma seus relatórios agregados de DMARC em um registro claro e contínuo de cada serviço que envia em nome do seu domínio, para que a camada que a autenticação realmente cobre continue vigiada enquanto sua equipe constrói as defesas para tudo o que fica além do clique. Cadastre-se gratuitamente no Excello Mail e deixe essa base pronta.