Zimbra CVE-2026-73570: operação não autenticada via SMTP com zimbra-snmp expõe web shells e dados

Nas últimas semanas, foi registrada uma campanha que aproveitou uma falha de segurança em Zimbra Collaboration Suite para executar código sem autenticação, instalar web shells e, em vários casos, extrair dados de caixas de correio. A vulnerabilidade identificada como CVE‐2026‐73570 (CVSS 8.9) afeta instalações com o pacote opcional zimbra‐snmp e as notificações SNMP habilitadas; de acordo com análises públicas, a exploração é realizada através de um pedido de SMTP especialmente construído sem necessidade de credenciais ou interação do usuário. Zimbra publicou um adesivo em julho de 2026 (versão 10.1.20) e organizações de segurança – incluindo a Microsoft e a CERT Polska – documentaram atividade ativa antes e depois da correção.

Tecnicamente, o que se reporta nas análises é um OS command injection não autenticado No caminho que recebe ou processa notificações SNMP associadas ao serviço Zimbra. Um atacante que possa enviar correio para o servidor vulnerável pode provocar a execução de comandos com os privilégios da conta do serviço Zimbra, o que permitiu a implantação de JSP web shells sobre Jetty/mailboxd, a transferência de binários através do wget/curl, a abertura de reverse shells e a criação de mecanismos de persistência (cron, systemd, memfd_create, ssh keys, ficheiros de arranque de shell, etc.). A Microsoft descreveu uma cadeia de ataque completa que inclui descoberta do ambiente (zmprov), escalada de privilégios modificando configurações PAM/sudo, recuperação de segredos por zmlocalconfig, movimento lateral aproveitando a identidade SSH de Zimbra e exfiltração através de ferramentas como AzCopy para armazenamento na nuvem.

Atos confirmados: CVE‐2026‐73570 existe e foi corrigida em Zimbra 10.1.20; a exploração pode ser activada através de SMTP sem autenticação quando o zimbra‐snmp e as notificações SNMP estão activas; os intervenientes lançaram JSP web shells, reverse shells e ferramentas de acesso remoto (por exemplo, Zimclient2) e coleccionaram credenciais e dados de buzones em múltiplos ambientes de telemetria da Microsoft. CERT Polska e CISA emitiram advertências públicas e CISA acrescentou a vulnerabilidade ao seu catálogo Known Exploited Vulnerabilities, com prazos de mitigação para agências federais.

Informação estimada ou ainda incerta: A atribuição das intrusões não é confirmada publicamente; nem a extensão total do sucesso das exfiltrações em todos os incidentes (pelo menos um caso foi observada uma tentativa de transferência para o Azure Blob usando AzCopy, mas não foi confirmada a conclusão da cópia). Além disso, embora a Microsoft descreveu técnicas específicas observadas (modificação de /etc/pam.d/sudo, criação de zimlog.service, uso de rsync entre nós, etc.), nem todos os hosts afetados apresentaram cada passo do fluxo de ataque.

Quem afeta? Qualquer organização que tenha Zimbra exposto ao tráfego SMTP e com o pacote zimbra‐snmp instalado e as notificações SNMP habilitadas podem ser comprometidas. Em particular, implantações com nodos de mailbox/MTA acessíveis da internet e configurações de cluster com identidade SSH compartilhada são mais vulneráveis à exploração lateral e ao roubo de segredos de serviço.

Consequências reais observadas: instalação de portas traseiras persistentes, escalada de privilégios do serviço zimbra, roubo de segredos (tokens, chaves de pré-autenticação, segredos 2FA), extração de tabelas da base de dados Zimbra e arquivamento de conteúdo de buzones. De um ponto de vista operacional, isso pode significar perda de confidencialidade de e-mails corporativos, comprometimento de identidades do serviço e reutilização de credenciais para pivotar outros sistemas dentro do mesmo ambiente de confiança.

Medidas concretas e imediatas a tomar um administrador de Zimbra:

1) Parchear ou mitigar: aplique Zimbra 10.1.20 ou a versão que contém o adesivo quanto antes. Se não estiver imediatamente a utilizar, desinstale zimbra‐snmp ou desactive as notificações SNMP e bloquee o acesso SNMP (portos 161/162) e SMTP (25) de fontes não fiáveis por listas de controlo de acesso ou firewalls. Mais informações sobre avisos e atualizações na página de segurança do Zimbra: https://www.zimbra.com/security/.

2) Verificar indicadores e persistências: Verifique os registros e o sistema para os sinais observados pelos pesquisadores. Procure reinícios incomuns do serviço em /var/log/zimbra.log, JSP web shells em rotas Webapps e /tmp, arquivos recentemente criados com permissões públicas temporariamente alteradas, serviços systemd suspeitos (por exemplo, zimlog.service), entradas cron não esperadas, chaves SSH em /opt/zimbra/.ssh/authorized_keys e modificações em /etc/pam.d/sudo. Comandos úteis (jemplos):

grep - i 'zimbra' /var/log/zimbra.log
find /opt/zimbra -type f -iname '*.jsp' - mtime -30
stat /etc/pam.d/sudo

3) Rotação de segredos e contenção: asuma autorização das chaves de serviço e rote os segredos principais de Zimbra (zimbraPreAuthKey, zimbraAuthTokenKey, zimbraTwoFactorAuthSecret), mude senhas de contas de serviço, invalide tokens e considere a rotação de certificados se houver indícios de exfiltração. Revocar e regenerar credenciais do serviço e restringir a identidade SSH do /opt/zimbra/.ssh/zimbra_identity são passos críticos. Qualquer servidor com indícios de compromisso deve ser isolado da rede e preservado para análise forense.

4) Procurar artefatos de exfiltração e transferência de arquivos: monitoree conexões salientes que usem ferramentas como AzCopy ou padrões incomuns para serviços de armazenamento na nuvem. Verifique a presença de arquivos arquivados localmente (por exemplo final.tar.gz mencionado em telemetria) e chamadas a utilitários de rede que poderiam ter transferido dados. Se detectar tentativas de subida ao Azure Blob Storage, verifique logs e configura alertas para SAS URL e tráfego para domínios de blobs. CISA mantém um catálogo de vulnerabilidades exploradas que pode ajudar a priorizar ações: https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

5) Recuperação recomendada: se confirmar compromisso, planifique reconstrução de backups limpos após uma eliminação forense completa. Não confie em limpar simplesmente os binários encontrados; os atores têm demonstrado múltiplos mecanismos de persistência e movimento lateral que requerem reimagem ou restauração controlada. Documente e preserve evidências para a pesquisa.

Finalmente, embora esta campanha tenha sido documentada em detalhes por várias equipes de resposta, a visibilidade é parcial e podem existir variantes ou atores reutilizando a mesma falha. Mantenha controles de detecção para padrões de comandos anormais em processos de Zimbra, limite exposições desnecessárias de serviços administrativos e atualize políticas de monitoramento para detectar mudanças em PAM/sudo, serviços systemd e transferência de grandes volumes de e-mails ou bases de dados. Para contexto e avisos de segurança adicionais, siga fontes oficiais como o blog de segurança da Microsoft: https://www.microsoft.com/security/blog/, e as equipes CERT locais para indicadores específicos.