Em 25 de junho de 2026, a equipe de inteligência de ameaças da Microsoft publicou os detalhes de uma campanha de phishing que está em andamento desde abril contra hotéis em toda a Europa e Ásia. A isca é simples: um arquivo ZIP chamado photo-<números>.zip, apresentado como a reclamação de um hóspede sobre uma infestação de percevejos ou uma avaliação de estadia, enviado às caixas de entrada da recepção. O que torna essa campanha digna da atenção de qualquer domínio protegido por DMARC não é a isca. É o mecanismo de entrega, que a Microsoft chama de “lavagem de autenticação”.
Cada mensagem dessa campanha passou por SPF, DKIM e DMARC. Não porque o atacante tenha forjado algo, mas porque o atacante nunca precisou disso.
A Cadeia: Do Calendly ao Google, ao Cloudflare, até a Recepção do Hotel
Os e-mails não vinham de um domínio falsificado nem de um parecido. Vinham de uma conta do Calendly genuinamente comprometida, enviados pela própria infraestrutura de notificações do Calendly, apoiada pelo SendGrid, sob o subdomínio em1618.calendly.com. Como o Calendly é o remetente autorizado real do seu próprio domínio de notificações, o SPF passou. Como o Calendly assina seu e-mail de saída com DKIM, isso também passou. Como o alinhamento do domínio From coincidia com a política DMARC do próprio Calendly, o DMARC passou sem qualquer problema.
A mensagem aparecia como “Booking Manager (via Calendly)” – um nome escolhido especificamente porque a equipe de hotelaria está acostumada a esperar notificações de reservas de um remetente exatamente assim. O link dentro da mensagem redirecionava por share.google, o próprio sistema de redirecionamento de links do Google, antes de chegar a um domínio de phishing hospedado atrás do Cloudflare. Cada salto dessa cadeia é, isoladamente, um pedaço legítimo e confiável da infraestrutura da internet.
Ao clicar, era feito o download de um ZIP contendo um arquivo com nome pensado para parecer uma foto – IMG-<aleatório>.png.lnk na primeira onda, PHOTO-<aleatório>.png.lnk em uma segunda onda que começou no fim de maio. Ao abrir o arquivo, era acionado um script do PowerShell que usava um decodificador de sete fases baseado em BigInt para obter a próxima carga útil. A segunda onda acrescentou uma etapa em que o malware compilava localmente uma pequena DLL em .NET usando csc.exe, antes de finalmente baixar uma cópia completa e legítima do runtime Node.js do site nodejs.org e usá-la para executar um implante em JavaScript que a Microsoft rastreia como TonRAT. A persistência era estabelecida por meio das chaves de registro HKCU\Run e HKCU\RunOnce, de modo que remover um caminho deixava o outro intacto. O implante então se comunicava com a infraestrutura de comando e controle por portas não padrão, executava automação de navegador em modo headless e consultava serviços de geolocalização por IP para traçar o perfil da máquina comprometida.
Por Que “Lavagem de Autenticação” é o Nome Certo
DMARC, SPF e DKIM respondem a uma única pergunta: essa mensagem veio de uma infraestrutura que o proprietário do domínio autorizou a enviar em seu nome? Eles não dizem nada sobre se o conteúdo dessa mensagem é seguro, nem sobre o que acontece depois que um destinatário clica em um link incluído pelo remetente autorizado.
A explicação da Microsoft é precisa: quando o domínio remetente é, em si, um serviço legítimo, e um atacante comprometeu uma conta desse serviço ou está abusando de algum recurso dele, as verificações de autenticação confirmam que o remetente é quem diz ser, sem dizer nada sobre a intenção. A confiança que Calendly, SendGrid e Google levaram anos para conquistar junto aos provedores de caixa de entrada se torna a cobertura do atacante. Isso é lavagem no sentido literal: fazer algo ilegítimo passar por um sistema legítimo até sair limpo.
Esse é um modo de falha bem diferente das configurações incorretas de suplantação de domínio e de Exchange híbrido que dominaram as manchetes sobre burla de DMARC neste ano. Ninguém forjou um cabeçalho. Ninguém explorou uma falha de análise. O atacante alugou, phisheou ou obteve acesso de outra forma a uma única conta real em uma única plataforma SaaS real, e cada mecanismo de autenticação posterior fez exatamente o que foi projetado para fazer.
O Que Isso Significa se Você Administra um Domínio Protegido por DMARC
Se o seu domínio aplica DMARC em p=reject, essa campanha não suplanta você. A postura de autenticação do seu próprio domínio é irrelevante para que sua equipe receba esse e-mail específico, porque a mensagem não finge ser do seu domínio – é uma mensagem real do domínio do Calendly, encaminhada pelo domínio do Google, sobre algo que está acontecendo no seu negócio.
E é exatamente esse o ponto. A aplicação do DMARC protege a identidade do seu domínio. Ela não protege, nem pode proteger, sua organização de ser atacada por meio da infraestrutura autenticada de outra empresa. São dois problemas relacionados, mas distintos, e confundi-los é como as organizações acabam confiando em uma segurança de e-mail que, na prática, não têm.
Dessa distinção seguem três conclusões práticas:
Aplique DMARC no seu próprio domínio de qualquer forma. Continua sendo necessário. Simplesmente não é suficiente neste caso, e nenhuma mudança nos seus próprios registros DNS teria impedido essa campanha específica.
Trate cada remetente terceirizado autorizado como parte da sua superfície de ataque. Ferramentas de agendamento, sistemas de notificação de CRM, plataformas de assinatura eletrônica e serviços de automação de marketing que você autorizou no seu registro SPF, ou nos quais sua equipe confia por hábito, são exatamente os canais que essa técnica foi criada para explorar. Um comprometimento de conta em qualquer um deles chega à sua caixa de entrada com um resultado de autenticação limpo.
Monitore seus próprios relatórios agregados DMARC em busca de anomalias nos serviços de envio em que você confia, não apenas em busca de suplantação do seu próprio domínio. Se o volume de envio, a pegada de IP ou os padrões de destino de um fornecedor mudarem abruptamente no e-mail endereçado à sua organização, isso é um sinal que merece investigação mesmo quando SPF, DKIM e DMARC relatam um resultado positivo.
Para equipes de segurança que avaliam arquivos ZIP com tema de fotos, atividade inesperada do csc.exe gerando DLLs pequenas, ou processos Node.js iniciados a partir de AppData\Local\Nodejs com um nome de arquivo aleatório e um argumento de domínio, vale a pena revisar diretamente a lista completa de indicadores da Microsoft. Para todos os outros, a lição é mais simples: um resultado positivo no DMARC diz quem enviou uma mensagem. Ele nunca disse, nem foi projetado para dizer, se essa mensagem é segura para agir.
A visibilidade contínua sobre seus relatórios agregados DMARC é o que permite detectar anomalias nos padrões de envio dos serviços terceirizados que você autorizou, antes que uma campanha de lavagem de autenticação como essa chegue até sua equipe. Cadastre-se gratuitamente na Excello Mail e tenha visibilidade clara e contínua sobre cada fonte que envia e-mail em seu nome.