A Microsoft Threat Intelligence detectou a exploração da vulnerabilidade CVE-2026-73570 no caminho de notificações SNMP do Zimbra Collaboration Suite. A vulnerabilidade permite a execução remota de comandos do sistema sem autenticação ou interação do usuário quando o pacote opcional zimbra-snmp está instalado e as notificações SNMP estão ativadas em um servidor Zimbra exposto à Internet.
Segundo a Microsoft, a exploração começa com uma mensagem SMTP especialmente criada, na qual um valor controlado pelo invasor pode chegar ao processamento de notificações SNMP e ser inserido em uma chamada de shell associada ao monitoramento do estado do serviço. Como resultado, o invasor pode executar comandos com os privilégios da conta de serviço zimbra.
Exploração iniciada antes da divulgação pública
A Zimbra lançou a correção na versão 10.1.20 em 20 de julho de 2026, enquanto a vulnerabilidade foi divulgada publicamente em 13 de agosto. Entre 28 de julho e 7 de agosto, a Microsoft detectou ferramentas externas de varredura e teste que verificavam a possibilidade de execução de comandos pelo mesmo caminho, antes da divulgação pública da vulnerabilidade.
Os testes usaram solicitações HTTP, consultas DNS e ICMP e comandos como curl, wget, ping, nslookup e id para comprovar a execução de comandos e o acesso externo ao servidor, sem necessariamente precisar baixar uma carga completa.
Da execução de comandos ao controle do servidor
Após o acesso inicial, os invasores implantaram backdoors no formato JSP dentro dos caminhos de aplicativos do Zimbra, criaram sessões de shell reverso e executaram processos em segundo plano. A Microsoft também detectou o uso de cron, systemd e memfd_create para manter a execução ou executar uma carga a partir da memória.
Em uma das cadeias de ataque, componentes autorizados a usar sudo e um caminho associado ao PAM foram explorados para elevar os privilégios da conta zimbra para root. Os invasores também instalaram um serviço systemd chamado zimlog.service, um nome que imita um componente legítimo do Zimbra, para executar a carga na inicialização do sistema.
A atividade não parou no primeiro servidor. A identidade SSH existente no Zimbra e o programa rsync foram usados para transferir arquivos e backdoors para outros nós dentro do cluster de e-mail, ampliando o alcance do acesso e reduzindo a dependência de um único ponto de comprometimento.
Alvo: dados de autenticação e e-mail
Os invasores coletaram valores das configurações locais do Zimbra, incluindo credenciais dos serviços LDAP, MySQL, Postfix, Amavis e de replicação. Também tiveram como alvo chaves como zimbraPreAuthKey, zimbraAuthTokenKey e zimbraTwoFactorAuthSecret.
A análise da Microsoft indica que algumas ferramentas tentaram ler bancos de dados de e-mail, dados de dispositivos e configurações de ausência temporária, além de certificados, chaves privadas e arquivos de configuração do Postfix. Em um incidente, backups recentes das caixas de e-mail foram coletados em um arquivo e, em seguida, o AzCopy foi usado para tentar transferi-los para o armazenamento Azure Blob. As evidências disponíveis não confirmam que a transferência foi concluída.
O que os operadores devem fazer?
A recomendação principal é atualizar todos os servidores Zimbra para a versão 10.1.20 ou posterior. Se a correção imediata não for possível, a Microsoft recomenda remover o pacote opcional zimbra-snmp, desativar as notificações SNMP e restringir o acesso a SNMP e SMTP apenas a hosts confiáveis.
Os alertas de shell reverso em servidores de e-mail expostos à Internet também devem ser tratados como incidentes de alta prioridade, sem limitar a busca a nomes de malwares conhecidos; alguns dos resultados mais graves envolveram o uso de um shell interativo comum, sem uma família específica de malware. As medidas de resposta incluem rotacionar os segredos do Zimbra e as chaves de autenticação, verificar serviços systemd, módulos PAM e sudo, além de procurar arquivos JSP inesperados e vestígios de servlets gerados em todos os nós de e-mail.
Esta investigação mostra que o risco prático não se limita à execução de um único comando. Uma única vulnerabilidade em um servidor de e-mail exposto pode se transformar em um ponto de partida para coletar segredos, implantar mecanismos de acesso persistente, movimentar-se dentro do cluster e tentar extrair dados de e-mail. Por outro lado, indicadores como a criação de um arquivo ou a execução de uma ferramenta de transferência para a nuvem, isoladamente, não comprovam o sucesso do roubo de dados; isso exige correlacionar registros de processos, arquivos e conexões para determinar o que realmente ocorreu.