A Proofpoint vem monitorando desde maio de 2026 um grupo de ameaça que chama de UNK_MassTraction, e a campanha é um lembrete útil de que alguns dos ataques mais danosos que chegam por e-mail nunca tocam em nada que o DMARC foi criado para verificar. O grupo encadeia duas vulnerabilidades no Roundcube, o cliente de webmail de código aberto amplamente usado por universidades e organizações pequenas para operar seu próprio e-mail hospedado, para passar de uma vítima simplesmente abrindo uma mensagem a um backdoor permanente no próprio servidor de e-mail. Não é preciso clicar em nenhum link. Não é preciso digitar nenhuma credencial em uma página falsa. E não é preciso falsificar nenhum domínio em nenhum ponto da cadeia.
Como Funciona a Cadeia de Exploração
O ponto de entrada é o CVE-2024-42009, uma falha de cross-site scripting no Roundcube que não sanitiza corretamente certos manipuladores de eventos de animação HTML, permitindo que o JavaScript do atacante seja executado no momento em que um e-mail manipulado é aberto em uma caixa de entrada Roundcube vulnerável. As iscas da Proofpoint eram deliberadamente genéricas, projetadas apenas para fazer o alvo visualizar a mensagem, já que visualizar é toda a superfície de ataque que essa falha exige. O JavaScript disparado é um ladrão do lado do navegador criado sob medida, ao qual a Proofpoint deu o nome de IceCube, que escapa do sandbox de iframe do Roundcube por meio de travessia do DOM e obtém acesso total ao DOM da página e à sessão autenticada ativa do Roundcube da vítima. A partir daí, o IceCube implanta o que a Proofpoint chama de “helpers”, que exploram uma segunda falha, o CVE-2025-49113, uma vulnerabilidade de desserialização em PHP que abusa da forma como o Crypt_GPG_Engine embutido do Roundcube analisa a entrada, para instalar um webshell leve que os pesquisadores batizaram de SquareShell diretamente no servidor de e-mail. Desde junho de 2026, a cadeia também ganhou um mecanismo de contingência: se a instalação do SquareShell falhar, um script de shell é executado por meio da mesma falha de desserialização para entregar o VShell, um backdoor residente em memória, em vez de simplesmente desistir.
Ambas as vulnerabilidades já são notícia antiga em termos de correções. O Roundcube lançou correções para o CVE-2024-42009 e o CVE-2025-49113 nas versões 1.5.10 e 1.6.11 em meados de 2025. O UNK_MassTraction não está explorando um zero-day; está explorando a lacuna entre o momento em que uma correção é lançada e o momento em que um servidor de e-mail autogerenciado é de fato atualizado, uma lacuna que em universidades que operam infraestrutura de e-mail com equipes de TI limitadas pode se estender por um ano ou mais.
Quem Está Sendo Alvo
O direcionamento é estreito e deliberado. A Proofpoint observou diretamente menos de dez universidades atingidas, com a pegada real estimada em algumas dezenas ao considerar a infraestrutura relacionada, concentrada em administradores e professores de departamentos de física e engenharia em instituições importantes dos EUA e do Canadá, particularmente aquelas com vínculos de segurança nacional ou pesquisa em astrofísica e física de partículas. Essa especificidade, combinada com uma rede de retransmissão encoberta compartilhada com outros grupos alinhados à China, a eventual migração para o VShell e os artefatos em idioma chinês deixados nos próprios e-mails de phishing, é o que leva a Proofpoint a avaliar isso como uma suposta operação de espionagem alinhada à China, em vez de um crime com motivação financeira.
Por Que o DMARC Não Tem Nada a Dizer Aqui
Vale a pena precisar por que essa campanha fica inteiramente fora do escopo do DMARC, porque o motivo é diferente das campanhas de tomada de conta e de intermediário (adversary-in-the-middle) que já cobrimos antes. O DMARC, o SPF e o DKIM existem para responder a uma pergunta: essa mensagem realmente veio de infraestrutura que o domínio de envio declarado autorizou? Eles não dizem absolutamente nada sobre o conteúdo da mensagem. O CVE-2024-42009 é disparado por uma renderização de HTML malformado dentro do cliente de webmail, não por nada relacionado à identidade do remetente. Um atacante poderia rotear essa mesma carga útil por um domínio com um registro DMARC perfeito, aplicação estrita e SPF e DKIM impecáveis, e o exploit dispararia exatamente da mesma forma, porque a vulnerabilidade está em como o Roundcube analisa eventos de animação HTML, não em quem tem permissão para reivindicar um domínio.
A segunda metade da cadeia torna a lacuna ainda mais concreta. Uma vez que o SquareShell ou o VShell está instalado no servidor de e-mail, o atacante tem um ponto de apoio em uma infraestrutura que o próprio registro DMARC da universidade autoriza explicitamente a enviar e-mail. Qualquer mensagem que esse servidor enviar depois disso terá origem no IP correto, poderá ser assinada com a chave DKIM real do domínio caso o atacante decida abusar desse acesso, e passará pela verificação de alinhamento do DMARC de forma limpa em qualquer destinatário que a verifique, porque, até onde o protocolo consegue saber, é genuinamente o servidor de e-mail da universidade enviando e-mail genuíno da universidade. O DMARC foi criado para detectar alguém falsificando um domínio de fora. Ele não tem nenhum mecanismo para perceber que o servidor legítimo por trás desse domínio foi silenciosamente entregue a outra pessoa.
O Que os Defensores Devem Fazer
Atualizar o Roundcube agora, se ainda não o fez. As versões 1.5.10 e 1.6.11 corrigem as duas vulnerabilidades dessa cadeia, e elas estão disponíveis há mais de um ano. Se sua organização usa Roundcube e não consegue confirmar hoje seu nível de correção, trate isso como o item mais urgente da sua lista.
Auditar em busca de comprometimento já existente, não apenas de exposição futura. Como essa cadeia está ativa desde maio de 2026 e as falhas subjacentes são públicas há mais de um ano, qualquer instância do Roundcube sem correção deveria ser verificada quanto a webshells, tarefas cron inesperadas ou processos desconhecidos, e não simplesmente corrigida presumindo que está limpa.
Restringir e monitorar o caminho de e-mail de saída do servidor Roundcube separadamente do restante da sua infraestrutura. Um servidor de webmail que de repente começa a enviar e-mails por caminhos, volumes ou horários que não correspondem ao seu padrão normal é um sinal mais forte do que qualquer coisa que os relatórios agregados do DMARC sozinhos possam revelar, já que o e-mail em si vai se autenticar de forma limpa.
Tratar a aplicação do DMARC e a atualização do webmail como dois controles separados que não se substituem. Bloquear todos os domínios que sua organização possui em p=reject continua correto e necessário. Isso não reduz a urgência de manter atualizado o software que realmente processa seu e-mail, porque os dois controles protegem contra modos de falha completamente diferentes.
A Conclusão
O UNK_MassTraction não é uma forma de contornar o DMARC em nenhum sentido relevante, porque nunca precisou nem chegar perto do DMARC. Ele mira o software que renderiza e armazena o e-mail, não as afirmações de identidade que a autenticação de e-mail verifica, e assim que tem sucesso, herda o mesmo caminho de envio confiável e autenticado que o DMARC foi criado para proteger. Duas correções disponíveis há mais de um ano teriam interrompido essa campanha por completo. Nenhuma política de DMARC, por mais rígida que fosse, teria feito isso.
A Excello Mail oferece visibilidade contínua sobre seus relatórios agregados de DMARC e suas fontes de envio, para que você possa identificar padrões incomuns mesmo vindos de infraestrutura em que já confia. Cadastre-se gratuitamente na Excello Mail para manter essa visibilidade em vigor enquanto sua equipe mantém o restante da pilha de e-mail atualizado.