Microsoft Threat Intelligence обнаружила эксплуатацию уязвимости CVE-2026-73570 в пути уведомлений SNMP в Zimbra Collaboration Suite. Уязвимость позволяет удалённо выполнять системные команды без аутентификации или взаимодействия с пользователем, если установлен необязательный пакет zimbra-snmp и на доступном через интернет сервере Zimbra включены уведомления SNMP.
По данным Microsoft, эксплуатация начинается со специально сформированного SMTP-сообщения: контролируемое атакующим значение может попасть в обработку уведомлений SNMP, а затем быть включено в вызов shell, связанный с мониторингом состояния службы. В результате атакующий может выполнять команды с привилегиями служебной учётной записи zimbra.
Эксплуатация началась до публичного раскрытия
Zimbra выпустила исправление в версии 10.1.20 20 июля 2026 года, тогда как публично об уязвимости сообщили 13 августа. В период с 28 июля по 7 августа Microsoft обнаружила внешние инструменты сканирования и тестирования, проверявшие возможность выполнения команд через тот же путь, ещё до публичного раскрытия уязвимости.
В ходе тестов использовались HTTP-запросы, DNS- и ICMP-запросы, а также такие команды, как curl, wget, ping, nslookup и id, чтобы подтвердить выполнение команд и внешний доступ к серверу, причём полная загрузка полезной нагрузки требовалась не всегда.
От выполнения команды к захвату сервера
После первоначального доступа атакующие размещали бэкдоры в формате JSP в путях приложений Zimbra, создавали обратные shell-сеансы и выполняли фоновые процессы. Microsoft также обнаружила использование cron, systemd и memfd_create для сохранения выполнения или запуска полезной нагрузки из памяти.
В одной из цепочек атаки были использованы компоненты, которым разрешено применение sudo, и путь, связанный с PAM, для повышения привилегий учётной записи zimbra до root. Атакующие также установили службу systemd с именем zimlog.service — названием, имитирующим легитимный компонент Zimbra, — чтобы запускать полезную нагрузку при загрузке системы.
Активность не ограничилась первым сервером. Для передачи файлов и бэкдоров на другие узлы внутри почтового кластера использовались имеющаяся в Zimbra идентификация SSH и программа rsync, что расширило масштаб доступа и снизило зависимость от одной точки компрометации.
Нацеливание на данные аутентификации и почту
Атакующие собирали значения из локальных настроек Zimbra, включая учётные данные служб LDAP, MySQL, Postfix, Amavis и репликации. Они также нацеливались на такие ключи, как zimbraPreAuthKey, zimbraAuthTokenKey и zimbraTwoFactorAuthSecret.
Анализ Microsoft показывает, что некоторые инструменты пытались читать базы данных почты, данные устройств и настройки автоответов, а также сертификаты, закрытые ключи и файлы конфигурации Postfix. В одном инциденте свежие резервные копии почтовых ящиков были собраны в архив, после чего для попытки передачи в хранилище Azure Blob использовался AzCopy. Имеющиеся данные не подтверждают завершение передачи.
Что следует делать операторам?
Основная рекомендация — обновить все серверы Zimbra до версии 10.1.20 или более поздней. Если немедленное исправление невозможно, Microsoft рекомендует удалить необязательный пакет zimbra-snmp, отключить уведомления SNMP и ограничить доступ к SNMP и SMTP только доверенными узлами.
Оповещения об обратном shell на обращённых к интернету почтовых серверах также следует рассматривать как инциденты высокого приоритета и не ограничиваться поиском названий известных вредоносных программ: некоторые наиболее серьёзные результаты включали использование обычного интерактивного shell без конкретного семейства вредоносного ПО. Меры реагирования включают ротацию секретов Zimbra и ключей аутентификации, проверку служб systemd, модулей PAM и sudo, а также поиск неожиданных JSP-файлов и следов сгенерированных servlet на всех почтовых узлах.
Это расследование показывает, что практический риск не ограничивается выполнением одной команды. Одна уязвимость на открытом почтовом сервере может превратиться в отправную точку для сбора секретов, установки средств постоянного доступа, перемещения внутри кластера и попытки извлечения почтовых данных. Вместе с тем такие признаки, как создание архива или запуск инструмента облачной передачи, сами по себе не доказывают успешную кражу данных; для определения того, что произошло на самом деле, необходимо сопоставить журналы процессов, файлов и сетевых соединений.