- 28,547
- 46
- 8 Ноя 2022
Вредоносный JavaScript запускался при просмотре сообщения и выгружал данные за 90 дней
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1400/788;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Одного просмотра письма в уязвимой Zimbra хватало, чтобы злоумышленники получили доступ к корпоративному ящику, переписке за три месяца, резервным кодам двухфакторной аутентификации и паролям из браузера. Переходить по ссылке, открывать вложение или запускать файл жертве не требовалось. Вредоносный JavaScript срабатывал при открытии письма или показе сообщения в области предварительного просмотра.
23 июля 2026 года кибербезопасность и разведывательные службы 16 стран опубликовали совместное предупреждение о продолжающейся шпионской кампании против пользователей платформы Zimbra Collaboration Suite (ZCS). Документ подготовили американские NSA (Агентство национальной безопасности), FBI (Федеральное бюро расследований), CISA (Агентство кибербезопасности и защиты инфраструктуры), DCSA (Агентство защиты контрразведки и безопасности), DC3 (Киберкриминалистический центр Министерства обороны США) и Министерство финансов, а также NCIS (Служба уголовных расследований ВМС США), нидерландские AIVD (Служба общей разведки и безопасности) и MIVD (Военная разведывательная служба), а также профильные ведомства Австралии, Великобритании, Канады, Новой Зеландии, Чехии, Дании, Эстонии, Финляндии, Франции, Италии, Молдовы, Польши, Испании и Швеции. Полная техническая версия также опубликована на сайтах Министерства обороны США и Центра приёма жалоб о киберпреступлениях ФБР (IC3) .
Западные службы связывают кампанию с группировкой Laundry Bear и считают, что предположительно русскоязычные хакеры собирают информацию в интересах России. В отраслевых отчётах та же активность фигурирует под названиями Void Blizzard , CL-STA-1114 и TA488, ранее UNK_PitStop. Авторы предупреждения отдельно оговаривают, что классификации разных компаний могут пересекаться не полностью.
Жертвами стали государственные учреждения, оборонные предприятия, подрядчики военно-промышленного комплекса, поставщики ИТ-услуг, учебные заведения, энергетические компании, правоохранительные органы, СМИ, некоммерческие организации и технологический сектор. Нидерландская AIVD сообщила о большом количестве пострадавших организаций в западных странах. В Нидерландах жертв нынешней волны атак на Zimbra не обнаружили, хотя Laundry Bear ранее взломала Национальную полицию страны в 2024 году.
Активность Laundry Bear прослеживается как минимум с апреля 2024 года. Первые операции не отличались сложной техникой. Группировка распыляла пароли по множеству учётных записей, покупала украденные данные на криминальных площадках, рассылала фишинговые письма и повторно использовала перехваченные куки-файлы и токены сессий.
Весной 2025 года злоумышленники создали поддельный сайт регистрации на европейский саммит по вопросам обороны и безопасности. Посетителям предлагали войти через учётную запись Microsoft. Модифицированная версия Evilginx перехватывала пароли и токены авторизации по схеме «противник посередине» (adversary-in-the-middle, AitM), после чего группировка массово выгружала почту через легитимные программные интерфейсы.
Примерно в июле 2025 года Laundry Bear перешла к более сложной атаке на локальные серверы Zimbra. Основой кампании стала уязвимость CVE-2025-66376 — хранимая уязвимость межсайтового скриптинга (XSS) в классическом веб-интерфейсе Zimbra Collaboration Suite. Ошибка затрагивает ветку ZCS 10 до версии 10.0.18 и ветку ZCS 10.1 до версии 10.1.13.
Первые атаки начались за несколько месяцев до выпуска исправления, поэтому CVE-2025-66376 действительно была уязвимостью нулевого дня. Zimbra закрыла проблему 6 ноября 2025 года в версиях 10.0.18 и 10.1.13, а запись CVE появилась 5 января 2026 года. Кампания продолжилась после выпуска исправления, поскольку многие администраторы не обновили серверы.
Злоумышленники отправляли обычные на вид письма с нейтральными деловыми предложениями, приглашениями к сотрудничеству и обсуждением встреч. В сообщениях не было вредоносных ссылок, макросов или подозрительных вложений. Эксплойт находился непосредственно внутри HTML-кода письма и запускался в любом браузере, если пользователь открывал сообщение через уязвимый классический клиент Zimbra.
Proofpoint называет подобный приём «эксплойтом с полукликом». Термин точнее распространённого определения zero-click («без единого клика»), поскольку пользователь всё же должен открыть письмо или увидеть его в окне предварительного просмотра. Нажимать элементы внутри сообщения уже не требуется.
После ноября 2025 года часть писем приходила с ранее взломанных адресов. Получатель видел знакомый или правдоподобный домен, а системы фильтрации реже воспринимали сообщение как фишинг. Захваченные ящики одновременно становились источниками новых атак.
CVE-2025-66376 возникла из-за неправильной очистки директив CSS <code>@import</code> в HTML-письмах. Атакующие помещали несколько таких директив перед элементом SVG, в атрибуте <code>onload</code> которого скрывался закодированный сценарий. Внешняя часть полезной нагрузки использовала кодировку Base64, внутренняя дополнительно шифровалась операцией XOR (логическое исключающее ИЛИ) с жёстко заданным ключом.
Сценарий расшифровывал следующую часть кода непосредственно в браузере и запускал её в контексте уже авторизованной сессии Zimbra. Группировка могла менять XOR-ключ, добавлять бессмысленные директивы <code>@import</code> и перестраивать код, чтобы обходить простые сигнатуры защиты. Работа внутри движка JavaScript не оставляла на диске традиционный исполняемый файл и заметно осложняла обнаружение антивирусами и системами класса EDR (Endpoint Detection and Response — обнаружение и реагирование на угрозы на конечных устройствах).
Инструментарий получил название Ulej, или «Улей». Proofpoint отслеживает клиентскую часть под именем ZimReaper. Весь процесс состоял из 12 асинхронных этапов. Код отправлял начальный сигнал, определял адрес пользователя, собирал параметры среды, похищал резервные коды двухфакторной аутентификации (2FA), создавал пароль приложения, проверял подключённые устройства и OAuth-приложения, пытался извлечь пароль из автозаполнения, включал почтовые протоколы, выгружал глобальную адресную книгу и архивы писем, после чего отправлял финальный сигнал.
Для обращения к внутренним функциям Zimbra сценарий забирал CSRF-токен (Cross-Site Request Forgery — защита от подделки межсайтовых запросов) из <code>localStorage</code> браузера. Без токена большинство SOAP-запросов не работало. После получения токена ZimReaper вызывал команды <code>GetIdentitiesRequest</code>, <code>GetInfoRequest</code>, <code>GetScratchCodesRequest</code>, <code>CreateAppSpecificPasswordRequest</code>, <code>GetDeviceStatusRequest</code>, <code>GetOAuthConsumersRequest</code>, <code>SearchGalRequest</code> и <code>ModifyPrefsRequest</code>.
Глобальную адресную книгу организации инструмент перебирал почти методом грубой силы. Сценарий составлял двухсимвольные сочетания из латинских букв, цифр, точки, дефиса и подчёркивания, затем отправлял 20 пакетов SOAP-запросов. Первые 19 пакетов содержали по 77 команд <code>SearchGalRequest</code>, последний содержал 58 команд. Полученные адреса могли использоваться для выбора следующих целей.
ZimReaper определял тип открытого клиента Zimbra, версию сервера и текущий адрес страницы. Сценарий распознавал расширенный, стандартный и современный интерфейсы по элементам URL. Инструмент также запрашивал сведения о зарегистрированных устройствах и OAuth-приложениях, что помогало понять конфигурацию учётной записи и доступные способы закрепления.
Затем код выгружал все письма за последние 90 дней, кроме сообщений из папки спама. Почта запрашивалась отдельно за каждый день и передавалась в виде сжатых GZIP-архивов. Вложения уходили вместе с содержимым ящика. Для каждого обработанного дня ZimReaper создавал в <code>localStorage</code> отметку формата <code>zd_comp_YYYY-MM-DD</code>, чтобы при повторном запуске не выгружать один архив дважды. Почта за текущий день собиралась при каждом запуске независимо от сохранённой отметки.
Такие отметки обычно сохраняются после закрытия браузера, если пользователь не работает в приватном режиме. Механизм помогал атакующим экономить трафик, но оставлял полезный след для расследования. По датам в ключах <code>zd_comp_YYYY-MM-DD</code> специалисты могут оценить, за какие дни почта уже была выгружена.
Для кражи сохранённого пароля сценарий добавлял за пределами видимой части страницы два скрытых поля авторизации. Браузер или менеджер паролей мог автоматически заполнить поля именем пользователя и текущим паролем. Через пять секунд ZimReaper считывал подставленное значение и отправлял его на сервер группировки. Под угрозой оказывался не только пароль Zimbra, но и другие учётные данные, если менеджер паролей ошибочно связывал скрытую форму с сохранённой записью.
Для постоянного доступа код пытался включить IMAP через параметр <code>zimbraPrefImapEnabled</code>. Затем команда <code>CreateAppSpecificPasswordRequest</code> создавала отдельный пароль приложения с названием ZimbraWeb. Такой пароль позволял подключаться к ящику через IMAP, POP3 или SMTP без обычной проверки второго фактора, читать почту вручную и рассылать новые вредоносные сообщения.
Одновременно ZimReaper запрашивал резервные коды двухфакторной аутентификации через <code>GetScratchCodesRequest</code>. Каждый найденный код отправлялся отдельно. Даже смена основного пароля могла не лишить злоумышленников доступа, если администратор не отзывал созданный пароль приложения, активные сессии и резервные коды.
Собранные данные уходили двумя каналами. Небольшие значения кодировались в Base32 и помещались в поддомены DNS-запросов типа A. Через DNS передавались адрес жертвы, тип и версия клиента, текущий URL, коды 2FA, пароль ZimbraWeb и пароль из автозаполнения. Для каждой жертвы создавался случайный идентификатор длиной 10 или 11 символов.
Тот же набор и более крупные массивы отправлялись по HTTPS. JSON-запросы шли по пути <code>/v/p</code>, двоичные данные по пути <code>/v/d</code>. Через HTTPS передавались письма, вложения, контакты, глобальная адресная книга, сведения об устройствах, OAuth-приложениях и возникающих ошибках. Сервер мог отвечать прозрачным GIF-изображением размером один на один пиксель, что маскировало часть обмена под обычную загрузку веб-ресурса.
Серверная часть Ulej называлась Flowerbed и работала на арендованных VPS (Virtual Private Server — виртуальных выделенных серверах). Фреймворк (программный каркас) представлял собой проект на Python с четырьмя контейнерами Docker. Catcher принимал DNS- и HTTP-трафик, Certbot автоматически получал сертификаты Let's Encrypt через Cloudflare, Nginx выполнял роль HTTPS-прокси, а Gardener проверял работоспособность Catcher.
Nginx пропускал соединение к Catcher только при наличии шаблона <code>*.i.*</code> в SNI (Server Name Indication — поле имени сервера при установке TLS-соединения). Остальным клиентам сервер возвращал нестандартный код 444. Catcher слушал DNS на порту 53 и HTTP на порту 8000, а Nginx принимал HTTPS на порту 443. Proofpoint также обнаружил открытый порт SSH (Secure Shell — протокол защищённого удалённого доступа) 22 и использование Cloudflare в качестве DNS-инфраструктуры.
Группировка арендовала серверы у разных провайдеров, включая площадки с обязательной проверкой клиентов, и регистрировалась по вымышленным данным. Для доступа к инфраструктуре часто использовался сервис Mullvad VPN (защищённая виртуальная частная сеть). Каждый сервер обычно работал от семи до 60 дней, после чего операторы переходили на новый адрес.
Flowerbed временно складывал украденные данные в каталог на VPS. Примерно раз в минуту автоматизированный процесс устанавливал короткое SSH-соединение и, предположительно, переносил собранные файлы на закрытую внутреннюю инфраструктуру для долгосрочного хранения. Раз в час команда очистки удаляла файлы, которые находились во временном каталоге дольше двух дней.
Авторы совместного отчёта нашли в простом коде Flowerbed признаки помощи генеративного ИИ . По оценке аналитиков, разработчики могли использовать ИИ для создания отдельных компонентов. Зависимость от готовых открытых инструментов и сгенерированного кода одновременно указывает на ограниченный опыт самостоятельной разработки сложного программного обеспечения.
Следов финансового вымогательства исследователи не обнаружили. Laundry Bear старалась незаметно читать переписку и как можно дольше сохранять доступ к почтовым учётным записям. Масштабный интерес к украинским организациям предшествовал атакам на цели в США и других странах НАТО. Авторы предупреждения считают Украину одновременно приоритетной целью и площадкой для испытания новых методов перед более широким применением.
Новая кампания продолжает давно сложившуюся охоту на независимые веб-почтовые платформы. Такие серверы часто выбирают государственные учреждения, университеты, оборонные предприятия и другие организации, которым требуется локальное хранение данных или полный контроль над почтовой инфраструктурой. Меньшая распространённость по сравнению с Microsoft 365 и Google Workspace не делает подобные системы менее привлекательными для разведывательных группировок.
В рамках Operation RoundPress исследователи ESET ранее наблюдали атаки на Roundcube, Horde, MDaemon и Zimbra. В 2026 году Proofpoint добавила к перечню Kerio и SOGo. В большинстве случаев злоумышленники использовали XSS-ошибки в веб-интерфейсе и запускали JavaScript после просмотра специально подготовленного сообщения.
RoundPress не следует автоматически объединять с нынешней кампанией. Proofpoint связывает операцию с отдельным кластером TA458 и прямо указывает, что не наблюдала применения CVE-2025-66376 этой группировкой. Laundry Bear отслеживается как TA488. Общая техника и сходные цели могут указывать на обмен эксплойтами, централизованную постановку задач или использование общего поставщика уязвимостей, но прямых доказательств исследователи не опубликовали.
Пример похожей атаки появился ещё в октябре 2023 года. Winter Vivern использовала уязвимость нулевого дня CVE-2023-5631 в Roundcube против европейских государственных организаций и аналитического центра. Жертве также требовалось лишь открыть письмо, после чего JavaScript получал доступ к папкам и сообщениям текущей почтовой сессии.
Администраторам Zimbra следует проверить версию сервера и немедленно установить последний поддерживаемый выпуск. Минимальными версиями, закрывающими CVE-2025-66376, остаются 10.0.18 и 10.1.13, однако останавливаться на старом минимальном исправлении рискованно. До обновления сотрудники должны отказаться от классического веб-интерфейса и пользоваться отдельным почтовым клиентом.
Организациям также рекомендуют рассмотреть внешний сервис аутентификации с поддержкой ключей доступа (passkey), поскольку эта технология снижает риск кражи повторно используемого пароля через автозаполнение. Пароли приложений потребуется контролировать отдельно, так как некоторые почтовые клиенты по-прежнему не поддерживают обычную двухфакторную авторизацию Zimbra.
При расследовании нужно изучить <code>/opt/zimbra/log/mailbox.log</code> и <code>/opt/zimbra/log/audit.log</code>. Подозрение должны вызвать многочисленные запросы <code>SearchGalRequest</code> от одного пользователя за короткое время, вызовы <code>GetScratchCodesRequest</code>, создание пароля приложения через <code>CreateAppSpecificPasswordRequest</code> и любое появление имени ZimbraWeb.
На компьютерах пользователей следует проверить <code>localStorage</code> страницы Zimbra на ключи формата <code>zd_comp_YYYY-MM-DD</code>. Найденные даты помогут определить возможный период утечки. Почтовые администраторы должны отыскать первоначальное вредоносное письмо, затем изолировать сообщения с похожим HTML-кодом, темой и отправителем во всех ящиках организации.
Сетевые средства мониторинга могут обнаружить необычно большие исходящие передачи на VPS, частые DNS-запросы со случайными поддоменами, резкий рост соединений с недавно зарегистрированными доменами и входы в веб-почту через Mullvad <span class="vpn-highlight" title="Использование VPN может нарушать законодательство РФ">VPN</span>. При доступе к расшифровке исходящего HTTPS-трафика специалисты могут искать пути <code>/v/p</code> и <code>/v/d</code>, необычные поддомены с компонентом <code>.i.</code> и обращения к инфраструктуре, маскирующейся под аналитику Zimbra.
После подтверждённого взлома недостаточно сменить один пароль. Администраторы должны отозвать все пароли приложений, резервные коды 2FA и активные сессии, заставить сотрудников создать новые уникальные пароли и проверить все сохранённые в менеджерах паролей учётные данные. Сценарий мог похитить любой пароль, который браузер автоматически подставил в скрытую форму.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1400/788;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Одного просмотра письма в уязвимой Zimbra хватало, чтобы злоумышленники получили доступ к корпоративному ящику, переписке за три месяца, резервным кодам двухфакторной аутентификации и паролям из браузера. Переходить по ссылке, открывать вложение или запускать файл жертве не требовалось. Вредоносный JavaScript срабатывал при открытии письма или показе сообщения в области предварительного просмотра.
23 июля 2026 года кибербезопасность и разведывательные службы 16 стран опубликовали совместное предупреждение о продолжающейся шпионской кампании против пользователей платформы Zimbra Collaboration Suite (ZCS). Документ подготовили американские NSA (Агентство национальной безопасности), FBI (Федеральное бюро расследований), CISA (Агентство кибербезопасности и защиты инфраструктуры), DCSA (Агентство защиты контрразведки и безопасности), DC3 (Киберкриминалистический центр Министерства обороны США) и Министерство финансов, а также NCIS (Служба уголовных расследований ВМС США), нидерландские AIVD (Служба общей разведки и безопасности) и MIVD (Военная разведывательная служба), а также профильные ведомства Австралии, Великобритании, Канады, Новой Зеландии, Чехии, Дании, Эстонии, Финляндии, Франции, Италии, Молдовы, Польши, Испании и Швеции. Полная техническая версия также опубликована на сайтах Министерства обороны США и Центра приёма жалоб о киберпреступлениях ФБР (IC3) .
Западные службы связывают кампанию с группировкой Laundry Bear и считают, что предположительно русскоязычные хакеры собирают информацию в интересах России. В отраслевых отчётах та же активность фигурирует под названиями Void Blizzard , CL-STA-1114 и TA488, ранее UNK_PitStop. Авторы предупреждения отдельно оговаривают, что классификации разных компаний могут пересекаться не полностью.
Жертвами стали государственные учреждения, оборонные предприятия, подрядчики военно-промышленного комплекса, поставщики ИТ-услуг, учебные заведения, энергетические компании, правоохранительные органы, СМИ, некоммерческие организации и технологический сектор. Нидерландская AIVD сообщила о большом количестве пострадавших организаций в западных странах. В Нидерландах жертв нынешней волны атак на Zimbra не обнаружили, хотя Laundry Bear ранее взломала Национальную полицию страны в 2024 году.
Активность Laundry Bear прослеживается как минимум с апреля 2024 года. Первые операции не отличались сложной техникой. Группировка распыляла пароли по множеству учётных записей, покупала украденные данные на криминальных площадках, рассылала фишинговые письма и повторно использовала перехваченные куки-файлы и токены сессий.
Весной 2025 года злоумышленники создали поддельный сайт регистрации на европейский саммит по вопросам обороны и безопасности. Посетителям предлагали войти через учётную запись Microsoft. Модифицированная версия Evilginx перехватывала пароли и токены авторизации по схеме «противник посередине» (adversary-in-the-middle, AitM), после чего группировка массово выгружала почту через легитимные программные интерфейсы.
Примерно в июле 2025 года Laundry Bear перешла к более сложной атаке на локальные серверы Zimbra. Основой кампании стала уязвимость CVE-2025-66376 — хранимая уязвимость межсайтового скриптинга (XSS) в классическом веб-интерфейсе Zimbra Collaboration Suite. Ошибка затрагивает ветку ZCS 10 до версии 10.0.18 и ветку ZCS 10.1 до версии 10.1.13.
Первые атаки начались за несколько месяцев до выпуска исправления, поэтому CVE-2025-66376 действительно была уязвимостью нулевого дня. Zimbra закрыла проблему 6 ноября 2025 года в версиях 10.0.18 и 10.1.13, а запись CVE появилась 5 января 2026 года. Кампания продолжилась после выпуска исправления, поскольку многие администраторы не обновили серверы.
Злоумышленники отправляли обычные на вид письма с нейтральными деловыми предложениями, приглашениями к сотрудничеству и обсуждением встреч. В сообщениях не было вредоносных ссылок, макросов или подозрительных вложений. Эксплойт находился непосредственно внутри HTML-кода письма и запускался в любом браузере, если пользователь открывал сообщение через уязвимый классический клиент Zimbra.
Proofpoint называет подобный приём «эксплойтом с полукликом». Термин точнее распространённого определения zero-click («без единого клика»), поскольку пользователь всё же должен открыть письмо или увидеть его в окне предварительного просмотра. Нажимать элементы внутри сообщения уже не требуется.
После ноября 2025 года часть писем приходила с ранее взломанных адресов. Получатель видел знакомый или правдоподобный домен, а системы фильтрации реже воспринимали сообщение как фишинг. Захваченные ящики одновременно становились источниками новых атак.
CVE-2025-66376 возникла из-за неправильной очистки директив CSS <code>@import</code> в HTML-письмах. Атакующие помещали несколько таких директив перед элементом SVG, в атрибуте <code>onload</code> которого скрывался закодированный сценарий. Внешняя часть полезной нагрузки использовала кодировку Base64, внутренняя дополнительно шифровалась операцией XOR (логическое исключающее ИЛИ) с жёстко заданным ключом.
Сценарий расшифровывал следующую часть кода непосредственно в браузере и запускал её в контексте уже авторизованной сессии Zimbra. Группировка могла менять XOR-ключ, добавлять бессмысленные директивы <code>@import</code> и перестраивать код, чтобы обходить простые сигнатуры защиты. Работа внутри движка JavaScript не оставляла на диске традиционный исполняемый файл и заметно осложняла обнаружение антивирусами и системами класса EDR (Endpoint Detection and Response — обнаружение и реагирование на угрозы на конечных устройствах).
Инструментарий получил название Ulej, или «Улей». Proofpoint отслеживает клиентскую часть под именем ZimReaper. Весь процесс состоял из 12 асинхронных этапов. Код отправлял начальный сигнал, определял адрес пользователя, собирал параметры среды, похищал резервные коды двухфакторной аутентификации (2FA), создавал пароль приложения, проверял подключённые устройства и OAuth-приложения, пытался извлечь пароль из автозаполнения, включал почтовые протоколы, выгружал глобальную адресную книгу и архивы писем, после чего отправлял финальный сигнал.
Для обращения к внутренним функциям Zimbra сценарий забирал CSRF-токен (Cross-Site Request Forgery — защита от подделки межсайтовых запросов) из <code>localStorage</code> браузера. Без токена большинство SOAP-запросов не работало. После получения токена ZimReaper вызывал команды <code>GetIdentitiesRequest</code>, <code>GetInfoRequest</code>, <code>GetScratchCodesRequest</code>, <code>CreateAppSpecificPasswordRequest</code>, <code>GetDeviceStatusRequest</code>, <code>GetOAuthConsumersRequest</code>, <code>SearchGalRequest</code> и <code>ModifyPrefsRequest</code>.
Глобальную адресную книгу организации инструмент перебирал почти методом грубой силы. Сценарий составлял двухсимвольные сочетания из латинских букв, цифр, точки, дефиса и подчёркивания, затем отправлял 20 пакетов SOAP-запросов. Первые 19 пакетов содержали по 77 команд <code>SearchGalRequest</code>, последний содержал 58 команд. Полученные адреса могли использоваться для выбора следующих целей.
ZimReaper определял тип открытого клиента Zimbra, версию сервера и текущий адрес страницы. Сценарий распознавал расширенный, стандартный и современный интерфейсы по элементам URL. Инструмент также запрашивал сведения о зарегистрированных устройствах и OAuth-приложениях, что помогало понять конфигурацию учётной записи и доступные способы закрепления.
Затем код выгружал все письма за последние 90 дней, кроме сообщений из папки спама. Почта запрашивалась отдельно за каждый день и передавалась в виде сжатых GZIP-архивов. Вложения уходили вместе с содержимым ящика. Для каждого обработанного дня ZimReaper создавал в <code>localStorage</code> отметку формата <code>zd_comp_YYYY-MM-DD</code>, чтобы при повторном запуске не выгружать один архив дважды. Почта за текущий день собиралась при каждом запуске независимо от сохранённой отметки.
Такие отметки обычно сохраняются после закрытия браузера, если пользователь не работает в приватном режиме. Механизм помогал атакующим экономить трафик, но оставлял полезный след для расследования. По датам в ключах <code>zd_comp_YYYY-MM-DD</code> специалисты могут оценить, за какие дни почта уже была выгружена.
Для кражи сохранённого пароля сценарий добавлял за пределами видимой части страницы два скрытых поля авторизации. Браузер или менеджер паролей мог автоматически заполнить поля именем пользователя и текущим паролем. Через пять секунд ZimReaper считывал подставленное значение и отправлял его на сервер группировки. Под угрозой оказывался не только пароль Zimbra, но и другие учётные данные, если менеджер паролей ошибочно связывал скрытую форму с сохранённой записью.
Для постоянного доступа код пытался включить IMAP через параметр <code>zimbraPrefImapEnabled</code>. Затем команда <code>CreateAppSpecificPasswordRequest</code> создавала отдельный пароль приложения с названием ZimbraWeb. Такой пароль позволял подключаться к ящику через IMAP, POP3 или SMTP без обычной проверки второго фактора, читать почту вручную и рассылать новые вредоносные сообщения.
Одновременно ZimReaper запрашивал резервные коды двухфакторной аутентификации через <code>GetScratchCodesRequest</code>. Каждый найденный код отправлялся отдельно. Даже смена основного пароля могла не лишить злоумышленников доступа, если администратор не отзывал созданный пароль приложения, активные сессии и резервные коды.
Собранные данные уходили двумя каналами. Небольшие значения кодировались в Base32 и помещались в поддомены DNS-запросов типа A. Через DNS передавались адрес жертвы, тип и версия клиента, текущий URL, коды 2FA, пароль ZimbraWeb и пароль из автозаполнения. Для каждой жертвы создавался случайный идентификатор длиной 10 или 11 символов.
Тот же набор и более крупные массивы отправлялись по HTTPS. JSON-запросы шли по пути <code>/v/p</code>, двоичные данные по пути <code>/v/d</code>. Через HTTPS передавались письма, вложения, контакты, глобальная адресная книга, сведения об устройствах, OAuth-приложениях и возникающих ошибках. Сервер мог отвечать прозрачным GIF-изображением размером один на один пиксель, что маскировало часть обмена под обычную загрузку веб-ресурса.
Серверная часть Ulej называлась Flowerbed и работала на арендованных VPS (Virtual Private Server — виртуальных выделенных серверах). Фреймворк (программный каркас) представлял собой проект на Python с четырьмя контейнерами Docker. Catcher принимал DNS- и HTTP-трафик, Certbot автоматически получал сертификаты Let's Encrypt через Cloudflare, Nginx выполнял роль HTTPS-прокси, а Gardener проверял работоспособность Catcher.
Nginx пропускал соединение к Catcher только при наличии шаблона <code>*.i.*</code> в SNI (Server Name Indication — поле имени сервера при установке TLS-соединения). Остальным клиентам сервер возвращал нестандартный код 444. Catcher слушал DNS на порту 53 и HTTP на порту 8000, а Nginx принимал HTTPS на порту 443. Proofpoint также обнаружил открытый порт SSH (Secure Shell — протокол защищённого удалённого доступа) 22 и использование Cloudflare в качестве DNS-инфраструктуры.
Группировка арендовала серверы у разных провайдеров, включая площадки с обязательной проверкой клиентов, и регистрировалась по вымышленным данным. Для доступа к инфраструктуре часто использовался сервис Mullvad VPN (защищённая виртуальная частная сеть). Каждый сервер обычно работал от семи до 60 дней, после чего операторы переходили на новый адрес.
Flowerbed временно складывал украденные данные в каталог на VPS. Примерно раз в минуту автоматизированный процесс устанавливал короткое SSH-соединение и, предположительно, переносил собранные файлы на закрытую внутреннюю инфраструктуру для долгосрочного хранения. Раз в час команда очистки удаляла файлы, которые находились во временном каталоге дольше двух дней.
Авторы совместного отчёта нашли в простом коде Flowerbed признаки помощи генеративного ИИ . По оценке аналитиков, разработчики могли использовать ИИ для создания отдельных компонентов. Зависимость от готовых открытых инструментов и сгенерированного кода одновременно указывает на ограниченный опыт самостоятельной разработки сложного программного обеспечения.
Следов финансового вымогательства исследователи не обнаружили. Laundry Bear старалась незаметно читать переписку и как можно дольше сохранять доступ к почтовым учётным записям. Масштабный интерес к украинским организациям предшествовал атакам на цели в США и других странах НАТО. Авторы предупреждения считают Украину одновременно приоритетной целью и площадкой для испытания новых методов перед более широким применением.
Новая кампания продолжает давно сложившуюся охоту на независимые веб-почтовые платформы. Такие серверы часто выбирают государственные учреждения, университеты, оборонные предприятия и другие организации, которым требуется локальное хранение данных или полный контроль над почтовой инфраструктурой. Меньшая распространённость по сравнению с Microsoft 365 и Google Workspace не делает подобные системы менее привлекательными для разведывательных группировок.
В рамках Operation RoundPress исследователи ESET ранее наблюдали атаки на Roundcube, Horde, MDaemon и Zimbra. В 2026 году Proofpoint добавила к перечню Kerio и SOGo. В большинстве случаев злоумышленники использовали XSS-ошибки в веб-интерфейсе и запускали JavaScript после просмотра специально подготовленного сообщения.
RoundPress не следует автоматически объединять с нынешней кампанией. Proofpoint связывает операцию с отдельным кластером TA458 и прямо указывает, что не наблюдала применения CVE-2025-66376 этой группировкой. Laundry Bear отслеживается как TA488. Общая техника и сходные цели могут указывать на обмен эксплойтами, централизованную постановку задач или использование общего поставщика уязвимостей, но прямых доказательств исследователи не опубликовали.
Пример похожей атаки появился ещё в октябре 2023 года. Winter Vivern использовала уязвимость нулевого дня CVE-2023-5631 в Roundcube против европейских государственных организаций и аналитического центра. Жертве также требовалось лишь открыть письмо, после чего JavaScript получал доступ к папкам и сообщениям текущей почтовой сессии.
Администраторам Zimbra следует проверить версию сервера и немедленно установить последний поддерживаемый выпуск. Минимальными версиями, закрывающими CVE-2025-66376, остаются 10.0.18 и 10.1.13, однако останавливаться на старом минимальном исправлении рискованно. До обновления сотрудники должны отказаться от классического веб-интерфейса и пользоваться отдельным почтовым клиентом.
Организациям также рекомендуют рассмотреть внешний сервис аутентификации с поддержкой ключей доступа (passkey), поскольку эта технология снижает риск кражи повторно используемого пароля через автозаполнение. Пароли приложений потребуется контролировать отдельно, так как некоторые почтовые клиенты по-прежнему не поддерживают обычную двухфакторную авторизацию Zimbra.
При расследовании нужно изучить <code>/opt/zimbra/log/mailbox.log</code> и <code>/opt/zimbra/log/audit.log</code>. Подозрение должны вызвать многочисленные запросы <code>SearchGalRequest</code> от одного пользователя за короткое время, вызовы <code>GetScratchCodesRequest</code>, создание пароля приложения через <code>CreateAppSpecificPasswordRequest</code> и любое появление имени ZimbraWeb.
На компьютерах пользователей следует проверить <code>localStorage</code> страницы Zimbra на ключи формата <code>zd_comp_YYYY-MM-DD</code>. Найденные даты помогут определить возможный период утечки. Почтовые администраторы должны отыскать первоначальное вредоносное письмо, затем изолировать сообщения с похожим HTML-кодом, темой и отправителем во всех ящиках организации.
Сетевые средства мониторинга могут обнаружить необычно большие исходящие передачи на VPS, частые DNS-запросы со случайными поддоменами, резкий рост соединений с недавно зарегистрированными доменами и входы в веб-почту через Mullvad <span class="vpn-highlight" title="Использование VPN может нарушать законодательство РФ">VPN</span>. При доступе к расшифровке исходящего HTTPS-трафика специалисты могут искать пути <code>/v/p</code> и <code>/v/d</code>, необычные поддомены с компонентом <code>.i.</code> и обращения к инфраструктуре, маскирующейся под аналитику Zimbra.
После подтверждённого взлома недостаточно сменить один пароль. Администраторы должны отозвать все пароли приложений, резервные коды 2FA и активные сессии, заставить сотрудников создать новые уникальные пароли и проверить все сохранённые в менеджерах паролей учётные данные. Сценарий мог похитить любой пароль, который браузер автоматически подставил в скрытую форму.
- Источник новости
- www.securitylab.ru
