Pesquisadores da Arctic Wolf estão monitorando uma campanha de phishing generalizada e baseada em email que compartilha claras semelhanças táticas com o Storm-2755, o cluster que a Microsoft nomeou pela primeira vez como “Payroll Pirate” em abril, depois que ele esvaziou salários de depósito direto de funcionários canadenses. A nova atividade se espalhou pelos Estados Unidos, Canadá e Europa, atingindo organizações de saúde, educação, manufatura, governo e serviços profissionais. O que torna essa onda digna de uma segunda olhada não é o fato de ela roubar credenciais. É o que o link de phishing faz no caminho até esse roubo, e por quanto tempo o acesso resultante sobrevive depois de ter sucesso.
Uma Mensagem de Voz Que Passa por Quatro Domínios Confiáveis
O email isca parece uma notificação automática de caixa de mensagens de voz, um formato familiar o suficiente para conseguir um clique sem muito escrutínio. O link por trás dele não vai direto para uma página de login falsa. Ele passa pelo próprio serviço de redirecionamento de links do Google Meet, depois pela infraestrutura de links de saída do Google, em seguida por um rastreador dinâmico de cliques do Google Campaign Manager, antes de finalmente pousar em um arquivo HTML hospedado em um bucket da Amazon S3, que é onde o proxy de adversário no meio realmente vive. Cada salto dessa cadeia fica em um domínio que as ferramentas de segurança aprenderam a confiar: google.com, googleadservices.com, amazonaws.com. A filtragem de URL baseada em reputação, do tipo que sinaliza um link no momento em que ele aponta para algo desconhecido, não tem nada para sinalizar até o último redirecionamento, e a essa altura a vítima já está olhando para uma página de login do Microsoft 365 convincente.
Assim que a vítima faz login, o proxy AiTM captura o cookie de sessão e o token de acesso OAuth emitidos após a autenticação bem-sucedida, o mesmo mecanismo que a Microsoft documentou nos casos originais do Storm-2755. O MFA que não é resistente a phishing não impede isso. A vítima completa seu desafio multifator de verdade, contra o provedor de identidade real, e o proxy simplesmente copia a sessão resultante em vez de tentar adivinhar um código.
Uma Sessão Que se Move Mais Rápido Que Seus Alertas
O detalhe que separa isso de um relato rotineiro de roubo de credenciais é o que acontece depois que o acesso é estabelecido. A Arctic Wolf descobriu que, tipicamente entre onze e vinte e quatro horas após o comprometimento inicial, uma atividade automatizada renova cada sessão sequestrada em intervalos de aproximadamente oito horas, e o SessionID permanece constante em cada renovação mesmo que o endereço IP de origem, o ASN e a localização geográfica mudem. Os operadores também roteiam os logins por proxies residenciais, então o padrão de tráfego que aparece em seus registros se parece com uma conexão de internet residencial comum, em vez de um pico vindo de infraestrutura de hospedagem desconhecida. Uma equipe de segurança observando o sinal de manual de uma tomada de conta, um login de um novo país em um novo ASN, verá exatamente esse sinal disparar repetidamente, ligado a uma sessão que nunca foi forçada a se reautenticar.
De dentro dessa sessão, o agente usa o Microsoft Graph para enumerar quais funcionários lidam com folha de pagamento, RH, finanças e administração, e então lê emails especificamente sobre faturas, dados bancários e benefícios. Esse reconhecimento alimenta o mesmo desfecho que a Microsoft documentou nos casos de abril: regras de caixa de entrada que ocultam as palavras “depósito direto” e “banco” do funcionário real, uma solicitação falsificada para alterar os dados bancários, e um salário que acaba em uma conta que a vítima nunca escolheu.
Por Que Nada Disso Toca no Que o DMARC Verifica
DMARC, SPF e DKIM respondem exatamente uma pergunta: se o domínio no cabeçalho From de uma mensagem está autorizado a enviar aquela mensagem. Essa pergunta é totalmente respondida e aprovada no momento em que o email isca chega, porque nada na notificação de caixa de mensagens precisa de um domínio falsificado para funcionar. A cadeia de redirecionamentos que se segue é um problema de reputação web, não um problema de autenticação, já que Google Meet e Amazon S3 são serviços legítimos usados exatamente como foram projetados por qualquer pessoa que tenha uma conta, que é o que o atacante tem. E o sequestro de sessão que vem depois do clique fica uma camada inteira acima de tudo o que o DMARC avalia. O DMARC verifica o envelope em que uma mensagem chega. Ele não tem mecanismo para revogar um token de sessão, nem visibilidade sobre se um SessionID que já passou por seis ASNs diferentes em três países em dois dias ainda é o mesmo usuário confiável que digitou a senha.
Isso não é uma crítica ao DMARC. É uma descrição do limite em que o DMARC foi construído para atuar, e essa campanha é projetada especificamente para operar além desse limite a partir do primeiro clique.
O Que Isso Significa para o Seu Programa
Priorize o MFA resistente a phishing onde seu provedor de identidade oferecer suporte. Passkeys e chaves de hardware FIDO2 são vinculadas à origem contra a qual foram registradas, o que derrota um proxy posicionado entre a vítima e a página real de login de uma forma que um código de uso único nunca consegue.
Monitore a continuidade do SessionID em mudanças de IP e ASN, não apenas logins de novas localizações. O sinal que essa campanha explora é um em que seus alertas disparam corretamente, mas sua resposta trata cada alerta como um evento novo e isolado em vez de reconhecer uma única sessão que vem persistindo silenciosamente por dias.
Audite regras de caixa de entrada que ocultam palavras como “banco,” “folha de pagamento” ou “depósito direto” como uma detecção permanente, não como uma etapa forense pós-incidente. Essa regra é o mecanismo do qual toda a etapa de dano financeiro dessa campanha depende, e ela é visível antes que qualquer dinheiro se mova, se alguém estiver observando.
Mantenha o DMARC aplicado em reject de qualquer forma. Ele continua fechando a porta para quem tenta falsificar seu domínio diretamente, e essa é uma porta que vale a pena manter fechada mesmo enquanto essa campanha em particular entra por uma completamente diferente.
A Conclusão
Um domínio pode ter o DMARC em aplicação total, com relatórios agregados limpos e cada remetente legítimo alinhado, e ainda assim ver a folha de pagamento de um funcionário ser redirecionada por um atacante que nunca precisou falsificar aquele domínio. A campanha Payroll Pirate tem sucesso ao fazer seu link de phishing passar por infraestrutura na qual seus filtros já confiam, e ao manter a sessão resultante viva muito depois do login que a criou. Fechar essa brecha exige monitoramento consciente de sessões e autenticação resistente a phishing ao lado do DMARC, não uma versão mais forte do próprio DMARC.
A Excello Mail oferece visibilidade contínua sobre a aplicação do seu DMARC e sobre cada fonte autorizada a enviar emails sob seu domínio, para que você sempre saiba o que sua autenticação realmente protege e onde estão seus limites. Cadastre-se gratuitamente na Excello Mail e veja exatamente quem está enviando emails como você, o tempo todo.