В одной западной организации утро началось не с отчёта, а с разбирательства: сотрудники открывали обычное письмо, а злоумышленники в это время тихо вытаскивали почту за последние 90 дней, адресную книгу и коды для восстановления доступа. Для атаки хватало одного просмотра сообщения в уязвимом веб-клиенте Zimbra.

Что случилось и почему это важно

Речь идёт о CVE-2025-66376 — уязвимости в Classic UI Zimbra Collaboration. Исследователи и профильные ведомства описывают атаку как скрытую XSS-цепочку: вредоносное HTML-письмо запускает JavaScript внутри уже открытой почтовой сессии и получает те же права, что и пользователь.

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

Какие есть варианты защиты

1. Срочно обновить Zimbra и закрыть уязвимую ветку

Это базовый шаг для тех, кто до сих пор держит Zimbra 10.0 или старую 10.1. Разработчик закрыл дыру 6 ноября 2025 года, а для 10.0 линия поддержки уже закончилась, так что откладывать тут некуда.

Плюс очевиден: новый входящий вредоносный HTML уже не сработает на той же ошибке. Минус тоже ясен — обновление не отменяет того, что могло утечь раньше.

2. Проверить учётные записи, а не только версию

Авторы отчётов прямо советуют смотреть на ящики, которые открывали или даже просто просматривали подозрительное письмо в Classic UI. Для таких аккаунтов нужен сброс пароля, завершение всех активных сессий и перевыпуск кодов восстановления 2FA.

Здесь важна проверка почтовых аккаунтов после инцидента: закрыть дыру мало, если атакующий уже успел унести данные. Этот подход требует времени, зато даёт шанс остановить повторный вход.

3. Разобрать следы атаки по журналам и письмам

В опубликованных рекомендациях фигурируют поиск вызовов CreateAppSpecificPassword, проверка включённого IMAP там, где он не нужен, и контроль запросов к GetScratchCodesRequest. Ещё один полезный шаг — просмотреть HTML-письма, которые дошли, но не были открыты, и искать в них характерную разбивку тегов через @import и комментарии.

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

4. Ужесточить правила для почты и публичных сетей

Даже если ваш почтовый сервер не Zimbra, сама схема атаки полезна как предупреждение: webmail, сохранённые пароли, коды восстановления и открытые сессии — это один контур риска. Здесь уместно разделять рабочие и личные браузеры, отключать лишнее автосохранение и не заходить в корпоративную почту с чужих устройств без дополнительной защиты.

Если сотрудникам приходится работать из поездок или из гостиниц, [средство для защищённого подключения в поездках]https://freedome.space может добавить ещё один слой контроля над трафиком. Но это не заменяет обновления сервера и ревизии аккаунтов — максимум помогает снизить лишние риски в чужой сети.

Кому что подходит

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

Отдельно стоит помнить про сотрудников, которые работают в дороге и часто открывают корпоративную почту с ноутбуков и телефонов. Для них важнее не «магическая защита», а дисциплина: обновления, отдельный профиль браузера, двухфакторная защита и осторожность к письмам с новостными дайджестами и вложенным HTML.

Что делать прямо сейчас

  • Проверить, работает ли Zimbra 10.0 или старая 10.1, и поднять версию до поддерживаемой.
  • Сбросить пароль и завершить активные сессии у всех ящиков, которые открывали подозрительные письма.
  • Перевыпустить коды восстановления 2FA.
  • Просмотреть журналы на вызовы CreateAppSpecificPassword, GetScratchCodesRequest и включённый IMAP.
  • Найти в почте письма с HTML-структурой, где теги разбиты через @import и комментарии.
  • Разделить рабочие и личные браузеры и отключить лишнее автозаполнение паролей.
  • Проверить, не используют ли сотрудники публичные сети без дополнительного слоя защиты.
Поделиться: