Entre 1º de junho e 4 de agosto, o fornecedor de segurança de e-mail INKY, agora parte da Kaseya, rastreou uma campanha de phishing que funcionou em ondas, parando principalmente nos fins de semana, e colocou 26.589 mensagens em 5.527 organizações. O dia de maior volume foi 3 de junho, quando 2.432 mensagens chegaram a 1.149 organizações de uma só vez. Cada mensagem seguia o mesmo modelo: uma falsa notificação de mensagem de voz com um anexo SVG. O que torna essa campanha digna de um estudo mais atento não é apenas o truque do tipo de arquivo dentro dela. É que essas mensagens falharam em SPF, DKIM e DMARC no perímetro do Microsoft 365, exatamente como deveriam, e mesmo assim foram entregues na caixa de entrada.
Um Arquivo de Imagem Que Nunca Foi uma Imagem
Arquivos SVG são feitos para ser gráficos vetoriais simples, mas os navegadores os renderizam nativamente, incluindo qualquer HTML ou JavaScript incorporado dentro deles. Os atacantes construíram um invólucro gráfico mínimo em torno de um script ofuscado que reconstruía suas próprias strings em tempo de execução e usava execução adiada para dificultar a inspeção estática. Para escapar dos filtros que verificam o tipo de anexo, declararam o tipo MIME do SVG como text/plain em vez de image/svg+xml. Um scanner que verificasse apenas o tipo declarado veria um inofensivo arquivo de texto. A vítima que o abria via uma aba do navegador montar silenciosamente uma página de roubo de credenciais na sua frente, construída inteiramente com script local em vez de baixada de uma URL sinalizada. Não havia nenhum link malicioso na mensagem para um gateway verificar por reputação no momento da entrega, porque a página não existia em lugar nenhum até que o script a construísse.
Mirando em Todos, com Precisão
A campanha mostra pouca evidência de ter escolhido alvos com cuidado. A organização mediana recebeu duas mensagens, e 32 por cento receberam apenas uma. O que ela fez com precisão foi personalizar o texto da isca: 99,5 por cento das mensagens incorporava o próprio endereço de e-mail do destinatário na notificação de mensagem de voz, e 95 por cento falsificava o próprio domínio do destinatário como remetente. Uma mensagem que parece vir de dentro da própria organização, mencionando o próprio endereço, soa mais confiável do que uma de um domínio externo, não importa quantas outras empresas tenham recebido o modelo idêntico naquela mesma semana.
O DMARC Funcionou. A Entrega Aconteceu Assim Mesmo.
É aqui que essa campanha deixa de se parecer com a maioria das que cobrimos. Normalmente o interessante é que o DMARC nunca teve chance de avaliar nada, porque o ataque contornava a identidade por completo. Aqui, o DMARC cumpriu sua função. As mensagens falsificadas não tinham nenhuma autorização legítima dos domínios que alegavam representar, então SPF, DKIM e DMARC falharam todos no perímetro da Microsoft, correta e esperadamente.
As mensagens chegaram às caixas de entrada mesmo assim por causa de como foram enviadas. Os operadores as retransmitiram pela SparkPost, um provedor de serviços de e-mail legítimo usado por um número enorme de empresas reais para e-mail real. A infraestrutura de envio da SparkPost carrega uma reputação sólida junto aos provedores de caixa de entrada, construída ao longo de anos de tráfego majoritariamente legítimo passando por suas faixas de IP. A filtragem de spam da Microsoft trata uma falha de DMARC como um sinal a mais entre vários que alimentam uma pontuação de Nível de Confiança de Spam, não como uma instrução automática de rejeição, a menos que a própria política do domínio e a configuração do sistema receptor forcem esse resultado. Diante de uma plataforma de envio com a reputação da SparkPost, uma falha de autenticação não foi suficiente para reverter isso. A INKY marcou cada mensagem com um veredito de “Perigo”, e sua detecção de conteúdo de phishing identificou 100 por cento delas. Setenta e cinco por cento ainda assim carregavam um SCL da Microsoft de 0 ou 1, a faixa que a Microsoft trata como não spam.
O Que Isso Significa Para o Seu Programa
Uma falha de DMARC é um veredito, não automaticamente uma rejeição. Se esse veredito realmente bloqueia a entrega depende de como o sistema receptor o pondera contra tudo mais que sabe, incluindo a reputação da infraestrutura pela qual a mensagem viajou. Publicar p=reject no seu próprio domínio é o que obriga os receptores a tratar suas falhas de autenticação como definitivas, em vez de apenas mais uma entre muitas.
Fique de olho nos seus relatórios agregados de DMARC em busca de tráfego de ESP que você não autorizou. Se o seu domínio está sendo falsificado por meio de uma plataforma respeitada como SparkPost, Mailgun ou SendGrid, seus relatórios são um dos poucos lugares onde esse padrão aparece antes de virar um chamado de suporte ou uma transferência fraudulenta.
Não deixe a reputação de uma plataforma confiável substituir uma verificação do que ela realmente está transportando. A mesma infraestrutura que entrega seu próprio e-mail de marketing e transacional está disponível para qualquer outra pessoa com uma conta, e os provedores de caixa de entrada nem sempre conseguem distinguir a diferença no momento em que uma mensagem chega.
Sinalize incompatibilidades de tipo de arquivo nos anexos, não apenas as extensões. Um SVG declarado como text/plain é uma inconsistência específica e verificável entre o que um arquivo alega ser e o que ele realmente é, e é exatamente o tipo de sinal que uma verificação estática de extensão deixa passar.
A Conclusão
A maioria das campanhas que cobrimos tem sucesso por ficar completamente fora do que o DMARC avalia. Esta é diferente: o DMARC rodou, o DMARC fez a mensagem falhar, e a mensagem foi entregue mesmo assim, porque a infraestrutura que a carregava havia conquistado confiança suficiente em outro lugar para superar essa falha. Um registro DNS que diz p=reject é um pedido. Se um sistema receptor o honra como uma instrução ou o trata como uma sugestão depende de tudo mais que aquela mensagem traz consigo, e aparentemente a reputação de uma plataforma legítima ainda é suficiente para comprar um lugar na caixa de entrada para uma verificação de autenticação que falhou.
Os relatórios agregados de DMARC são onde você primeiro veria seu domínio sendo usado como identidade falsificada em uma campanha como essa, muito antes de virar um chamado de suporte ou uma transferência fraudulenta. A Excello Mail transforma esses relatórios em uma visão clara e contínua de cada fonte que envia em seu nome, autorizada ou não, para que você consiga distinguir entre seu próprio e-mail e alguém aproveitando a reputação de uma plataforma confiável para chegar às caixas de entrada dos seus destinatários. Cadastre-se gratuitamente na Excello Mail e coloque essa visibilidade em prática.