E-mail sem clique invade o Zimbra: atualizar o servidor não pode esperar

A correção começa por localizar todas as instalações do Zimbra Collaboration e atualizar qualquer servidor afetado pela CVE-2025-66376. O registro da vulnerabilidade no NVD identifica como vulneráveis as versões 10.0 anteriores à 10.0.18 e 10.1 anteriores à 10.1.13; se uma mensagem maliciosa pode ter sido exibida, porém, o patch deve ser acompanhado de investigação e remoção de persistência.

Não é necessário clicar em link nem abrir anexo: a exploração ocorre quando o Classic Web Client vulnerável renderiza o e-mail preparado. O alerta técnico conjunto sobre a campanha documenta comprometimentos de sessões autenticadas, tentativa de extração dos últimos 90 dias de mensagens e da lista global de endereços, coleta de dados de autenticação e criação de acesso persistente.

1. Confirme a versão em toda a implantação

Faça o inventário antes da manutenção, mas não limite a busca ao servidor principal. Registre a versão efetivamente executada em cada nó, a presença do Classic Web Client, proxies, interfaces publicadas, instâncias de contingência e ambientes de teste que possam ter recebido mensagens reais.

As versões 10.0.18 e 10.1.13 são os primeiros lançamentos corrigidos para essa falha, não um destino obrigatório para qualquer instalação. Use a atualização de segurança mais recente que seja suportada na linha adotada pela organização e siga a ordem de manutenção correspondente à sua topologia.

• Confirme a versão em execução, em vez de verificar apenas o pacote disponível no repositório.
• Inclua nós desativados temporariamente que possam voltar ao balanceamento ou à contingência.
• Determine durante qual período o Classic Web Client vulnerável ficou acessível.
• Registre contas administrativas, integrações e serviços que precisarão ser validados após a mudança.

Quando a atualização imediata for inviável, suspenda o uso do Classic Web Client vulnerável e direcione os usuários para clientes alternativos até concluir a correção. Essa contenção reduz novas exposições, mas não apaga uma exploração que já tenha ocorrido.

2. Separe prevenção de resposta a comprometimento

O divisor operacional é a possibilidade de a mensagem ter sido renderizada. Se o ambiente vulnerável não esteve exposto e não existem indícios de entrega ou exibição, a prioridade é atualizar, validar os serviços e reforçar o monitoramento. Se houve mensagem suspeita, indicador de rede ou exposição sem telemetria suficiente, trate o caso como possível comprometimento.

A falha é um XSS armazenado causado pelo tratamento inadequado de elementos do conteúdo HTML. Fragmentos ocultos na mensagem são reconstruídos pelo navegador e executados dentro da sessão autenticada; por isso, treinamento para não clicar continua útil contra outras fraudes, mas não bloqueia este mecanismo.

O código opera no contexto do webmail e pode usar recursos disponíveis à conta sem instalar um executável convencional no endpoint. Uma busca restrita a alertas de antivírus ou EDR, portanto, não é suficiente para descartar a invasão.

3. Atualize e preserve o que será investigado

Se houver suspeita de exploração, preserve os registros relevantes antes de ações que possam reduzir a visibilidade, sem adiar a contenção do serviço vulnerável. Copie logs, cabeçalhos e corpo bruto das mensagens suspeitas para um repositório controlado e registre horários, contas e nós envolvidos.

1. Faça o backup exigido pelo plano de recuperação e mantenha as cópias de logs separadas do servidor.
2. Instale a versão corrigida e suportada em todos os componentes aplicáveis.
3. Reinicie ou recarregue os serviços conforme o procedimento da edição instalada.
4. Confirme novamente a versão ativa em cada nó.
5. Teste autenticação, envio, recebimento, acesso administrativo e integrações essenciais.
6. Observe erros de serviço e conexões de saída inesperadas após a manutenção.

O término bem-sucedido do instalador não encerra o trabalho. A vulnerabilidade só está fechada quando todos os componentes expostos executam uma versão corrigida; a possível presença do invasor exige uma etapa separada de caça e erradicação.

4. Procure os rastros deixados pela exploração

A análise técnica da Proofpoint descreve o malware ZimReaper criando uma senha específica de aplicativo chamada “ZimbraWeb”, extraindo dados por consultas DNS, enumerando a lista global de endereços e exportando mensagens dos 90 dias anteriores; a análise também recomenda procurar chamadas de criação dessa credencial em /opt/zimbra/log/audit.log.

Examine também /opt/zimbra/log/mailbox.log, onde ficam por padrão as chamadas SOAP usadas para consultar e alterar a conta. A busca deve cobrir todo o período em que a versão vulnerável esteve exposta, respeitando a retenção disponível; falta de registros não equivale a prova de que nada ocorreu.

• Procure muitas chamadas SearchGalRequest feitas pela mesma conta em pouco tempo.
• Localize CreateAppSpecificPasswordRequest, sobretudo com o nome “ZimbraWeb” ou variações não reconhecidas.
• Revise chamadas GetScratchCodesRequest e alterações que habilitem acesso por IMAP.
• Correlacione DNS, SNI, proxy e firewall com domínios e endereços publicados no alerta, considerando que indicadores históricos podem já ter mudado de uso.
• Procure no armazenamento local do navegador chaves no formato zd_comp_YYYY-MM-DD, que podem ajudar a delimitar os dias processados pelo código.
• Localize mensagens pelos hashes, remetentes, assuntos e padrões de conteúdo conhecidos, preservando os artefatos antes da quarentena.

Inclua na análise contas que enviaram mensagens depois do possível comprometimento. A campanha utilizou caixas postais previamente invadidas para distribuir novos e-mails maliciosos, de modo que o escopo pode ultrapassar o primeiro destinatário identificado.

5. Revogue a persistência e o material de autenticação

Uma senha de aplicativo “ZimbraWeb” é um indicador de alta confiança nesta campanha e pode manter acesso por protocolos de e-mail sem repetir o segundo fator. Preserve os dados necessários para a linha do tempo e revogue senhas específicas de aplicativo não reconhecidas, códigos de recuperação e sessões ativas.

Redefina as senhas das contas afetadas por um canal confiável. Como o código tentou coletar credenciais preenchidas automaticamente pelo navegador, avalie também outras senhas armazenadas no gerenciador usado durante a exploração, principalmente quando houver reutilização.

Revise encaminhamentos, filtros, delegações, aliases, tokens, preferências da conta e habilitação de IMAP, POP3 ou SMTP. Se administradores ou contas de serviço foram atingidos, faça a rotação dos segredos e chaves aos quais essas identidades tinham acesso.

Trocar apenas a senha principal não encerra uma sessão já obtida nem remove uma senha de aplicativo. A erradicação precisa invalidar cada mecanismo de retorno compatível com o alcance confirmado ou plausível da invasão.

6. Encerre com critérios diferentes para patch e incidente

Para prevenção, o encerramento exige todos os nós corrigidos, funcionamento validado e monitoramento de logs e rede ativo. Para um incidente, exige também delimitação das contas e dos dados possivelmente alcançados, quarentena das mensagens, revogação da persistência, rotação das credenciais e avaliação das obrigações legais e contratuais aplicáveis.

Mantenha alertas para criação de senhas de aplicativo, enumeração intensa da lista global de endereços, exportações volumosas de caixas postais e consultas DNS anômalas. Atualizar fecha a falha; investigar e revogar acessos expulsa quem pode ter entrado antes do patch.

Leia também:

• “Ações do Claude” ainda não existem — e ofertas antecipadas podem valer zero
• Aprender prompt não basta: quatro habilidades para trabalhar com agentes de IA
• Kit MCP pode alterar sua lista: como limitar permissões antes de conectar a IA