Golpe no Zimbra invade emails de governos sem exigir único clique

Golpe silencioso, executado sem clique algum. Assim operava a campanha de espionagem contra servidores Zimbra, mapeada pela Proofpoint. Em seguida, NSA, FBI, CISA e agências de inteligência de vários países assinaram um alerta conjunto. Segundo o documento, a operação rodava desde julho de 2025 contra órgãos ucranianos, agências norte americanas, instalações nucleares e empresas europeias. Além disso, bastava abrir a mensagem para entregar a conta inteira. Para quem desenvolve, a mecânica do ataque interessa mais do que a geopolítica.

Golpe: O clique que deixou de ser necessário

Campanhas tradicionais de phishing dependem de um gesto humano. Alguém precisa clicar, baixar ou digitar credenciais em uma página falsa. Aqui, o código malicioso vivia dentro do corpo da mensagem. Assim, a simples abertura no cliente web já disparava a execução. Os emails chegavam com temas administrativos, propostas de cooperação internacional e assuntos de negócio. Inicialmente, o envio partia do Proton Mail. Depois, o grupo passou a usar contas comprometidas em invasões anteriores. Dessa forma, cada mensagem chegava com remetente conhecido e reputação limpa.

ZimReaper Golpe trabalhava nos primeiros segundos de leitura

A Proofpoint batizou a ferramenta de ZimReaper. No relatório das agências, ela aparece como Ulej. Assim que a interface renderizava o conteúdo, o script identificava o endereço da vítima e a versão do Zimbra em uso. Em seguida, buscava códigos de recuperação de autenticação em dois fatores, dispositivos vinculados e dados gerais da conta. O grupo responsável aparece nos registros como TA488, também conhecido como Laundry Bear e Void Blizzard.

A senha de aplicativo que virou porta dos fundos

O trecho mais elegante do ataque veio depois dessa coleta inicial. O script criava uma senha de aplicativo para um cliente fictício chamado ZimbraWeb. Com essa credencial em mãos, os operadores abriam sessões IMAP diretas na caixa da vítima. Portanto, a persistência sobrevivia à troca de senha e ao logout. O código exportava até 90 dias de mensagens e consultava a lista de contatos da organização. Logo, cada conta invadida alimentava a próxima rodada de envios. A exfiltração seguia por HTTPS disfarçado e por túneis de DNS até a infraestrutura batizada de Flowerbed.

Um XSS comum sustentou toda a operação

A raiz técnica cabe em três letras. O Zimbra permitia execução de JavaScript dentro da própria interface do email, um Cross Site Scripting clássico. Além disso, o grupo fatiava o payload em trechos pequenos para escapar dos filtros. Ou seja, a sanitização existia e falhava diante da fragmentação. Esse detalhe merece atenção de quem escreve frontend. Renderizar HTML de terceiros é território hostil por definição. Portanto, sanitização por lista de permissão, CSP restritiva e isolamento em iframe com sandbox seguem como o mínimo aceitável.

O patch dormiu na fila por oito meses

A correção saiu em novembro de 2025. Contudo, a vulnerabilidade só ganhou catalogação em janeiro de 2026. Já o relatório técnico completo apareceu apenas em julho. Enquanto isso, os operadores seguiram coletando caixas de entrada por meses. Esse intervalo entre patch, CVE e divulgação explica boa parte do sucesso da campanha. Afinal, times de infraestrutura priorizam o que aparece nos feeds de vulnerabilidade. Quando a correção chega silenciosa, ela costuma dormir na fila.

O que revisar no seu ambiente ainda esta semana

Primeiro, atualize qualquer instância Zimbra para a versão 10.1.13 ou superior. Depois, revise as senhas de aplicativo ativas e revogue tudo que ninguém reconhece. Em seguida, audite sessões IMAP e POP em busca de clientes com nomes genéricos. Além disso, monitore consultas de DNS anômalas em volume e frequência. Por fim, trate atualizações silenciosas de webmail com a urgência reservada a um CVE crítico.

Golpe: A lição que fica para quem escreve código

Superfícies de ataque sem interação humana crescem em ritmo constante. Elas exploram justamente aquilo que o produto promete entregar: renderizar conteúdo externo com fidelidade. Portanto, cada ponto onde a aplicação interpreta dados de terceiros pede revisão periódica. E, sempre que possível, esse interpretador precisa rodar em um contexto sem acesso à sessão do usuário.

Acompanhe nosso perfil no Instagram!