CVE-2026-73570: атаки на почтовые серверы Zimbra начались до раскрытия уязвимости

Уязвимость затрагивает необязательный компонент Zimbra, который отвечает за отправку уведомлений по протоколу SNMP (стандарт обмена служебными сообщениями между системами мониторинга). Если этот компонент установлен, а уведомления включены, злоумышленник передаёт через обычное почтовое соединение команды операционной системы. Они выполняются с правами служебной учётной записи почтового сервера. Исправление вышло 20 июля 2026 года в версии 10.1.20. Публично об уязвимости сообщили только 13 августа.

По данным Microsoft Threat Intelligence, в промежутке между этими датами серверы уже проверяли на уязвимость. С 28 июля по 7 августа два разных инструмента сканирования обращались к тому же участку кода, который позже использовали при эксплуатации. Проверка шла осторожно: операторы отправляли лёгкие запросы на уникальные поддомены, размещённые на публичных сервисах отслеживания обращений, и по ответам убеждались, что команды исполняются. Полезную нагрузку на этом этапе они не доставляли. Вместо этого снимали отпечаток системы и проверяли доступ к веб-каталогу сервера.

После подтверждения доступа атакующие размещали веб-оболочки - программы, дающие удалённое управление через браузер. Права на запись в общедоступные каталоги приложения открывали временно, а затем возвращали прежние значения, чтобы изменения не бросались в глаза при беглой проверке. Копии оболочек появлялись и на соседних почтовых узлах, поэтому удаление одной из них не лишало злоумышленников доступа. Параллельно запускались фоновые процессы и устанавливались обратные оболочки - каналы, по которым отдаются команды и приходят ответы.

Дальше следовала разведка внутри инфраструктуры. Штатными средствами администрирования Zimbra атакующие составили карту развёртывания: сколько в кластере почтовых узлов и какие роли у серверов. Отдельно они проверяли, доверяют ли узлы друг другу по SSH (протокол защищённого удалённого доступа). Готовая схема доверия упрощала перемещение между машинами. Часть сведений о среде уходила наружу через DNS-запросы.

Закрепление начиналось с повышения прав. Атакующие использовали штатные служебные механизмы Zimbra и папку журналов, доступную на запись. Файл журнала подменяли символической ссылкой на конфигурацию подсистемы аутентификации PAM, которая отвечает за проверку прав в Linux, а затем запускали привилегированный процесс комплекса. В результате конфигурационный файл переходил в собственность служебной учётной записи и становился доступным для правки. Добавленный обработчик сеанса выполнялся с правами суперпользователя. Он создавал запись, дающую служебной учётной записи неограниченный доступ к sudo (механизм выполнения команд от имени других пользователей). Следы подчищали, но саму запись оставляли. Второй механизм закрепления - служба systemd (системный менеджер, запускающий фоновые службы) под именем, похожим на штатный компонент журналирования. Файл службы положили вне каталогов Zimbra, а отметки времени подогнали под давно установленные системные службы.

Целью сбора были не пароли отдельных ящиков, а централизованные служебные секреты. Штатная команда Zimbra выдала пароли для каталога LDAP (служба каталогов), базы данных, почтового и антивирусного компонентов, а также для репликации. С их помощью атакующие запрашивали у каталога ключи подписи пользовательских сессий, ключи предварительной аутентификации и секреты двухфакторной проверки. Ключ подписи сессий особенно опасен: он позволяет сформировать действующую сессию для любой учётной записи без знания её пароля. Часть собранного сжимали в скрытые архивы.

Перемещение по кластеру шло через существующий ключ SSH самой Zimbra и утилиту синхронизации файлов. Она переносила на соседние узлы фрагменты полезной нагрузки, вспомогательные скрипты и веб-оболочки, а исходные файлы на первой машине удалялись. Так доступ распространялся на весь почтовый кластер, а не оставался на одном сервере.

Связь с захваченными серверами шла по обычному веб-протоколу и через DNS-запросы. Для устойчивого канала использовали шифрованное соединение на базе OpenSSL (библиотека шифрования): команды поступали в оболочку, а результаты возвращались тем же путём. В одной из кампаний применялась многоступенчатая цепочка - лёгкий загрузчик, установщик и полноценная программа удалённого доступа. Последняя давала интерактивную командную строку, обмен файлами и проксирование трафика. Закреплялась она сразу несколькими способами: системными службами, планировщиком заданий, файлами автозапуска оболочки, ключами SSH и созданием локальных учётных записей.

В кампании встречалась программа, написанная специально под Zimbra. Она читала главный конфигурационный файл комплекса, извлекала служебные пароли и выгружала содержимое баз: списки ящиков, метаданные, данные мобильных устройств, автоответы. Туда же попадали сертификаты, закрытые ключи, параметры каталога и почтовые правила. На одном сервере злоумышленники собрали архив свежих почтовых резервных копий и попытались отправить его в облачное хранилище Azure служебной утилитой. Подтверждений, что передача завершилась успешно, нет.

Обновление до версии 10.1.20 и выше закрывает уязвимость. Если установка исправления откладывается, стоит удалить необязательный компонент SNMP, отключить уведомления и разрешить обращения к SNMP и почтовому протоколу только с доверенных адресов. Сигнал об обратной оболочке на почтовом сервере, доступном из интернета, заслуживает статуса приоритетного инцидента: само соединение говорит о доступе злоумышленника, даже если вредоносный файл не найден. Опоры только на детекторы известных вредоносных программ мало - часть описанных действий выполнялась обычной командной оболочкой. Следует сменить ключи предварительной аутентификации. Полезно проверить системные службы на неожиданных владельцев и изменённые отметки времени. Лишние веб-оболочки стоит искать во всех каталогах приложения на каждом почтовом узле. Права служебных учётных записей почтового сервера разумно ограничить средствами изоляции процессов.

Хронология кампании показывает, что промежуток между выпуском исправления и публичным раскрытием уязвимости злоумышленники используют как рабочее окно. Исправление от 20 июля появилось раньше предупреждения от 13 августа, и за это время эксплуатацию уже начали. Скорость установки обновлений и готовность замечать подозрительную активность без привязки к известным вредоносным файлам определяют, насколько успешной окажется защита почтовой инфраструктуры.