Уязвимость CVE-2026-73570 с оценкой 8,9 по CVSS позволяет без аутентификации выполнять команды операционной системы на серверах Zimbra Collaboration Suite (ZCS). Для атаки достаточно специально сформированного SMTP-запроса или письма: участие пользователя не требуется. Уязвимы системы с установленным дополнительным пакетом zimbra-snmp и включёнными уведомлениями протокола Simple Network Management Protocol (SNMP). Zimbra закрыла брешь в версии 10.1.20, выпущенной 20 июля 2026 года.
По телеметрии группы Microsoft Security Research, атаки шли с 20 июля по 13 августа 2026 года, то есть исправление уже существовало, но сведения об уязвимости ещё не были опубликованы. 13 августа 2026 года CVE-2026-73570 раскрыли публично. В августе активную эксплуатацию первой отметила польская группа реагирования CERT Polska. Позднее в том же месяце Агентство по кибербезопасности и защите инфраструктуры США, Cybersecurity and Infrastructure Security Agency (CISA), внесло брешь в каталог Known Exploited Vulnerabilities (KEV). Федеральным учреждениям США предписали установить исправления до 24 августа 2026 года.
После доставки вредоносного SMTP-запроса команды выполнялись от имени служебной учётной записи zimbra. Злоумышленники загружали дополнительные компоненты через wget и curl, запускали их и открывали интерактивные обратные оболочки. В каталогах приложений Jetty и mailboxd размещалось несколько JSP-веб-шеллов. Дублирование было намеренным: удаление одного файла не лишало атакующих доступа. В отдельных случаях они временно разрешали запись в общедоступный каталог, копировали туда веб-шелл, а затем возвращали прежние права. При поверхностной проверке разрешения выглядели нормально, хотя вредоносный файл уже оставался на сервере.
Закрепление не ограничивалось веб-шеллами. Использовались Cron, systemd, OpenRC, файлы запуска оболочки, SSH-ключи в authorized_keys и новые локальные учётные записи. Вызов memfd_create позволял исполнять код из памяти и оставлять меньше файлов на диске. Периодический запуск обеспечивали задания Cron, а созданная злоумышленниками служба zimlog.service стартовала при загрузке системы. Такое сочетание давало несколько путей возврата даже после частичной очистки сервера.
Штатная утилита Zimbra zmprov использовалась для разведки: атакующие находили узлы почтовых ящиков и серверы Mail Transfer Agent (MTA), после чего проверяли наличие внутреннего SSH-идентификатора Zimbra. Для повышения привилегий они меняли файл /etc/pam.d/sudo, предоставляя учётной записи zimbra неограниченный запуск команд через sudo без пароля. Компрометация почтового приложения тем самым перерастала в полный административный доступ к операционной системе.
Особый интерес представляли централизованные секреты, а не пароли отдельных ящиков. Команда zmlocalconfig -s раскрывала служебные параметры и учётные данные, с которыми затем выполнялись аутентифицированные LDAP-запросы. Среди запрашиваемых атрибутов находились zimbraPreAuthKey, zimbraAuthTokenKey и zimbraTwoFactorAuthSecret: материалы предварительной аутентификации, ключи токенов и секреты двухфакторной защиты. После такой кражи одной смены пользовательских паролей недостаточно. Для перемещения между доверенными узлами применялся SSH-ключ /opt/zimbra/.ssh/zimbra_identity, а через Rsync на соседние серверы передавались JSP-шеллы, вспомогательные сценарии и другие файлы.
Связь с инфраструктурой операторов поддерживала обратная оболочка, зашифрованная средствами OpenSSL. По этому каналу выполнялись команды, загружались компоненты и передавались результаты работы; шифрование затрудняло анализ сетевого трафика. В одной из кампаний небольшой shell-загрузчик получал написанный на Go файл Zimdown2. Тот устанавливал агент удалённого доступа Zimclient2 с интерактивной оболочкой, двусторонней передачей файлов и прокси SOCKS5, пригодным для перехода во внутреннюю сеть через заражённый сервер. Агент поддерживал WebSocket, TLS и обычный TCP, а закреплялся через systemd, OpenRC, Cron, стартовые файлы оболочки, SSH-ключи и локальные аккаунты.
В атаках встречался ещё один специализированный исполняемый файл на Go. Он пытался извлечь учётные данные служб Zimbra из файлов по шаблону /opt/zimbra/conf/localconfig.. В описании этого компонента после пути сохранилось слово namespace, по-видимому, обрывок строки или ошибка форматирования; однозначно установленной целью остаются файлы localconfig.. Имплант собирал учётные данные, сертификаты, секреты LDAP, артефакты почтовых правил, конфигурацию, сведения аутентификации и содержимое почтовых ящиков. Подготовленные материалы упаковывались в ZIP-архив для последующей отправки.
На одном сервере недавние резервные копии почтовых ящиков сложили в архив /opt/zimbra/final.tar.gz. Затем атакующий загрузил утилиту Microsoft AzCopy с адреса [.]ms/downloadazcopy-v10-linux и запустил её с предоставленным оператором URL, содержащим подпись общего доступа Azure Blob, то есть SAS. Целевым объектом Azure Blob Storage был wsweb03[.]blob[.]core[.]windows[.]net/log/windows.log. Microsoft зафиксировала создание архивов и дальнейшую активность, связанную с их передачей, но имеющиеся данные не подтверждают, что конкретная выгрузка завершилась успешно.
Пострадавшие организации находились более чем в одном регионе и относились к разным отраслям. Не каждый заражённый узел прошёл все стадии описанной цепочки: где-то обнаруживались веб-шеллы, где-то доступ к почте, сбор аутентификационных данных или подготовка архивов. Личность операторов и их принадлежность к известной группе пока не установлены. Наблюдения Microsoft подтверждают доступ к электронным письмам, данным почтовых ящиков и централизованным секретам, а также попытки перемещаться по доверенной инфраструктуре Zimbra.
CERT Polska рекомендует начинать проверку с журнала /var/log/zimbra.log: искать подозрительные перезапуски служб Zimbra, новые файлы во временных каталогах и директориях webapps. Отдельной проверки требуют JSP-файлы в путях Jetty и mailboxd, служба zimlog.service, правки /etc/pam.d/sudo, неожиданный запуск zmlocalconfig -s и LDAP-запросы к чувствительным атрибутам. Следует поднять историю использования /opt/zimbra/.ssh/zimbra_identity, Rsync, OpenSSL, wget, curl и AzCopy, найти /opt/zimbra/final.tar.gz, Zimdown2, Zimclient2, неизвестные задания Cron, записи OpenRC, новые SSH-ключи, изменения стартовых файлов и незнакомые локальные аккаунты.
Серверы следует обновить как минимум до исправленной Zimbra 10.1.20 либо до более позднего безопасного выпуска. Если патч пока установить нельзя, пакет zimbra-snmp нужно удалить, уведомления SNMP отключить, а доступ по SNMP и SMTP ограничить доверенными узлами. После обнаружения признаков взлома проверяется весь кластер, а не первый найденный сервер. Требуется заменить секреты аутентификации Zimbra, изучить межузловые подключения SSH и Rsync, проверить systemd, OpenRC, Cron, authorized_keys, локальные аккаунты и исходящие обращения к облачным хранилищам. Возвращать прежние права на каталоги безопасно лишь после удаления вредоносных файлов. Если запускалась zmlocalconfig -s или выполнялись подозрительные LDAP-запросы, централизованные ключи следует считать скомпрометированными.
Изображение носит иллюстративный характер
По телеметрии группы Microsoft Security Research, атаки шли с 20 июля по 13 августа 2026 года, то есть исправление уже существовало, но сведения об уязвимости ещё не были опубликованы. 13 августа 2026 года CVE-2026-73570 раскрыли публично. В августе активную эксплуатацию первой отметила польская группа реагирования CERT Polska. Позднее в том же месяце Агентство по кибербезопасности и защите инфраструктуры США, Cybersecurity and Infrastructure Security Agency (CISA), внесло брешь в каталог Known Exploited Vulnerabilities (KEV). Федеральным учреждениям США предписали установить исправления до 24 августа 2026 года.
После доставки вредоносного SMTP-запроса команды выполнялись от имени служебной учётной записи zimbra. Злоумышленники загружали дополнительные компоненты через wget и curl, запускали их и открывали интерактивные обратные оболочки. В каталогах приложений Jetty и mailboxd размещалось несколько JSP-веб-шеллов. Дублирование было намеренным: удаление одного файла не лишало атакующих доступа. В отдельных случаях они временно разрешали запись в общедоступный каталог, копировали туда веб-шелл, а затем возвращали прежние права. При поверхностной проверке разрешения выглядели нормально, хотя вредоносный файл уже оставался на сервере.
Закрепление не ограничивалось веб-шеллами. Использовались Cron, systemd, OpenRC, файлы запуска оболочки, SSH-ключи в authorized_keys и новые локальные учётные записи. Вызов memfd_create позволял исполнять код из памяти и оставлять меньше файлов на диске. Периодический запуск обеспечивали задания Cron, а созданная злоумышленниками служба zimlog.service стартовала при загрузке системы. Такое сочетание давало несколько путей возврата даже после частичной очистки сервера.
Штатная утилита Zimbra zmprov использовалась для разведки: атакующие находили узлы почтовых ящиков и серверы Mail Transfer Agent (MTA), после чего проверяли наличие внутреннего SSH-идентификатора Zimbra. Для повышения привилегий они меняли файл /etc/pam.d/sudo, предоставляя учётной записи zimbra неограниченный запуск команд через sudo без пароля. Компрометация почтового приложения тем самым перерастала в полный административный доступ к операционной системе.
Особый интерес представляли централизованные секреты, а не пароли отдельных ящиков. Команда zmlocalconfig -s раскрывала служебные параметры и учётные данные, с которыми затем выполнялись аутентифицированные LDAP-запросы. Среди запрашиваемых атрибутов находились zimbraPreAuthKey, zimbraAuthTokenKey и zimbraTwoFactorAuthSecret: материалы предварительной аутентификации, ключи токенов и секреты двухфакторной защиты. После такой кражи одной смены пользовательских паролей недостаточно. Для перемещения между доверенными узлами применялся SSH-ключ /opt/zimbra/.ssh/zimbra_identity, а через Rsync на соседние серверы передавались JSP-шеллы, вспомогательные сценарии и другие файлы.
Связь с инфраструктурой операторов поддерживала обратная оболочка, зашифрованная средствами OpenSSL. По этому каналу выполнялись команды, загружались компоненты и передавались результаты работы; шифрование затрудняло анализ сетевого трафика. В одной из кампаний небольшой shell-загрузчик получал написанный на Go файл Zimdown2. Тот устанавливал агент удалённого доступа Zimclient2 с интерактивной оболочкой, двусторонней передачей файлов и прокси SOCKS5, пригодным для перехода во внутреннюю сеть через заражённый сервер. Агент поддерживал WebSocket, TLS и обычный TCP, а закреплялся через systemd, OpenRC, Cron, стартовые файлы оболочки, SSH-ключи и локальные аккаунты.
В атаках встречался ещё один специализированный исполняемый файл на Go. Он пытался извлечь учётные данные служб Zimbra из файлов по шаблону /opt/zimbra/conf/localconfig.. В описании этого компонента после пути сохранилось слово namespace, по-видимому, обрывок строки или ошибка форматирования; однозначно установленной целью остаются файлы localconfig.. Имплант собирал учётные данные, сертификаты, секреты LDAP, артефакты почтовых правил, конфигурацию, сведения аутентификации и содержимое почтовых ящиков. Подготовленные материалы упаковывались в ZIP-архив для последующей отправки.
На одном сервере недавние резервные копии почтовых ящиков сложили в архив /opt/zimbra/final.tar.gz. Затем атакующий загрузил утилиту Microsoft AzCopy с адреса [.]ms/downloadazcopy-v10-linux и запустил её с предоставленным оператором URL, содержащим подпись общего доступа Azure Blob, то есть SAS. Целевым объектом Azure Blob Storage был wsweb03[.]blob[.]core[.]windows[.]net/log/windows.log. Microsoft зафиксировала создание архивов и дальнейшую активность, связанную с их передачей, но имеющиеся данные не подтверждают, что конкретная выгрузка завершилась успешно.
Пострадавшие организации находились более чем в одном регионе и относились к разным отраслям. Не каждый заражённый узел прошёл все стадии описанной цепочки: где-то обнаруживались веб-шеллы, где-то доступ к почте, сбор аутентификационных данных или подготовка архивов. Личность операторов и их принадлежность к известной группе пока не установлены. Наблюдения Microsoft подтверждают доступ к электронным письмам, данным почтовых ящиков и централизованным секретам, а также попытки перемещаться по доверенной инфраструктуре Zimbra.
CERT Polska рекомендует начинать проверку с журнала /var/log/zimbra.log: искать подозрительные перезапуски служб Zimbra, новые файлы во временных каталогах и директориях webapps. Отдельной проверки требуют JSP-файлы в путях Jetty и mailboxd, служба zimlog.service, правки /etc/pam.d/sudo, неожиданный запуск zmlocalconfig -s и LDAP-запросы к чувствительным атрибутам. Следует поднять историю использования /opt/zimbra/.ssh/zimbra_identity, Rsync, OpenSSL, wget, curl и AzCopy, найти /opt/zimbra/final.tar.gz, Zimdown2, Zimclient2, неизвестные задания Cron, записи OpenRC, новые SSH-ключи, изменения стартовых файлов и незнакомые локальные аккаунты.
Серверы следует обновить как минимум до исправленной Zimbra 10.1.20 либо до более позднего безопасного выпуска. Если патч пока установить нельзя, пакет zimbra-snmp нужно удалить, уведомления SNMP отключить, а доступ по SNMP и SMTP ограничить доверенными узлами. После обнаружения признаков взлома проверяется весь кластер, а не первый найденный сервер. Требуется заменить секреты аутентификации Zimbra, изучить межузловые подключения SSH и Rsync, проверить systemd, OpenRC, Cron, authorized_keys, локальные аккаунты и исходящие обращения к облачным хранилищам. Возвращать прежние права на каталоги безопасно лишь после удаления вредоносных файлов. Если запускалась zmlocalconfig -s или выполнялись подозрительные LDAP-запросы, централизованные ключи следует считать скомпрометированными.
