Представьте: обычное рабочее утро, сотрудник открывает письмо, которое выглядит как безобидный запрос. Никаких ссылок, никаких вложений. Однако это действие может стать началом инцидента, в результате которого злоумышленники получают доступ к почтовому ящику, включая архивы за несколько месяцев.
Сценарии, подобные атаке GhostMail, демонстрируют, как эксплуатация уязвимостей в популярных почтовых системах позволяет обойти классические средства защиты. В материале разбирается механика таких атак и даются рекомендации по защите инфраструктуры.
Обычный день, который мог стать катастрофой
В практике реагирования на инциденты встречаются случаи, когда сотрудник крупной компании получает письмо, внешне не вызывающее подозрений. В его HTML-коде может содержаться вредоносный скрипт. Подобные механизмы использовались в атаке GhostMail. В одном из случаев система мониторинга зафиксировала подозрительные SOAP-запросы к API почтового сервера. Это позволило предотвратить возможную утечку данных, включая переписку и доступы к корпоративным сервисам.
По данным открытых источников, атаки такого типа эксплуатируют уязвимость XSS в Zimbra Collaboration Suite. Информация об уязвимости и способах её устранения была опубликована производителем, а исправления вышли ещё в ноябре 2025 года. Однако на многих объектах, включая организации госсектора и коммерческие компании, обновления могут не применяться своевременно, что создаёт предпосылки для реализации угроз.
Для организаций, использующих веб-почту на базе Zimbra, это означает наличие потенциального вектора атаки, особенно если администрирование системы осуществляется по принципу минимальной необходимости обновлений.
Анализ механики атаки GhostMail
Рассмотрим, как была организована эта атака, основываясь на данных открытых исследований.
Согласно сообщениям, целью атаки стал сотрудник одной из государственных структур. Письмо было составлено на местном языке, отправитель представлялся студентом. В письме отсутствовали файлы или ссылки, однако внутри HTML-разметки в скрытом блоке содержался JavaScript-код в кодировке Base64.
При открытии письма в браузере скрипт автоматически выполнялся, используя уязвимость XSS. В данном случае не требовалось кликать по ссылке — достаточно было просмотра сообщения.
Функционал кода включал несколько этапов:
- Загрузчик проверял, был ли уже активирован основной модуль, затем декодировал полезную нагрузку и выполнял её в памяти браузера.
- Основной модуль работал в контексте открытой сессии почты и мог взаимодействовать с данными пользователя.
Важно отметить, что такая активность может оставаться незамеченной для классических антивирусных решений, ориентированных на сигнатурное обнаружение исполняемых файлов, так как вредоносный код выполняется в среде браузера.
Используемые методы обхода защиты
Атакующие применяли несколько способов для вывода данных и закрепления в системе.
Вредоносный код использовал штатные SOAP-запросы к интерфейсу почтовой системы. Для легитимизации запросов применялись украденные CSRF-токены, которые в классическом интерфейсе хранятся в localStorage.
Передача данных, по имеющимся данным, могла осуществляться по двум каналам:
- HTTPS — прямое соединение с внешним сервером.
- DNS — через запросы к поддоменам. Этот метод используется для обхода фильтрации веб-трафика. Данные кодировались, разбивались на части и преобразовывались в имена поддоменов, которые затем декодировались на стороне злоумышленника.
В ряде организаций, особенно в сегменте критической информационной инфраструктуры, мониторинг DNS-туннелей может быть недостаточным, что делает этот канал эффективным для скрытой передачи данных.
Закрепление доступа: создание постоянных паролей и изменение настроек
Одним из элементов атаки, описанных в открытых источниках, было создание постоянного пароля приложения. В Zimbra предусмотрена возможность создания отдельных паролей для внешних клиентов. Важной особенностью является то, что такие пароли не изменяются при смене основного пароля учётной записи.
Кроме того, в ходе атаки могла изменяться настройка IMAP, что позволяло злоумышленнику подключаться к ящику через любой IMAP-клиент, минуя веб-интерфейс.
Такой подход создаёт риск долгосрочного сохранения доступа к почтовому ящику даже после того, как пользователь сменит пароль.
Риски, связанные с выгрузкой архивов переписки
Согласно описанию, в атаке присутствовал модуль для выгрузки архива переписки за 90 дней. Для этого использовалась встроенная функция экспорта Zimbra.
Доступ к переписке за длительный период может раскрывать значительный объём конфиденциальной информации: внутренние решения, данные о партнёрах, финансовые сведения. В реальных инцидентах такая утечка может использоваться для конкурентной разведки или последующих атак.
Для любой организации важно оценивать, какой объём критической информации хранится в почтовых архивах сотрудников, особенно тех, кто работает с финансами, закупками или юридическими вопросами.
Рекомендации по защите от почтовых атак
На основе анализа подобных инцидентов можно сформулировать ряд мер, направленных на снижение рисков.
- Своевременное обновление почтового сервера.
Уязвимости, подобные использованной в GhostMail, закрываются обновлениями производителя. Отсутствие актуальных обновлений увеличивает зону риска. Для организаций, поднадзорных регуляторам (ФСТЭК, Банк России), несвоевременное обновление может рассматриваться как нарушение требований. - Настройка Content Security Policy (CSP) для веб-интерфейса.
Корректно настроенный CSP позволяет блокировать выполнение неподписанных скриптов, что снижает риск эксплуатации XSS-уязвимостей. - Мониторинг API-активности.
Внедрение правил корреляции в SIEM для выявления аномальных запросов к API, в частности, к /service/soap/, а также отслеживание событий создания паролей приложений. - Контроль DNS-трафика.
Настройка детекции запросов к поддоменам с высокой энтропией (хаотичные имена), что может свидетельствовать о кодированной передаче данных. - Управление функцией паролей приложений.
Рассмотреть возможность отключения или ограничения функции создания паролей приложений для определённых групп пользователей. - Анализ поведения сессий.
Отслеживание аномалий, таких как вход с разных IP-адресов в короткий промежуток времени или запросы на экспорт архивов. - Повышение осведомлённости сотрудников.
Регулярное информирование о современных методах атак, включая сценарии, где вредоносный код может содержаться непосредственно в теле письма. - Обязательное использование двухфакторной аутентификации (2FA).
2FA является важным барьером, но не абсолютной защитой, особенно если резервные коды хранятся в почтовом ящике. - Регулярные проверки учётных записей.
Периодический аудит на наличие активных паролей приложений и нестандартных настроек доступа. - Пересмотр модели угроз.
Современные атаки не ограничиваются классическим фишингом со ссылками. Риск может представлять уже сам факт открытия письма.
Пример из практики реагирования
В одном из случаев при проведении аудита почтовой инфраструктуры финансовой организации были выявлены признаки компрометации. В логах веб-сервера присутствовали подозрительные POST-запросы к API, а в DNS-логах — запросы к доменам с высокой энтропией. Анализ показал, что несколько учётных записей были скомпрометированы, и злоумышленники в течение некоторого времени выгружали переписку.
В результате были выполнены мероприятия по обновлению системы, смене паролей и отзыву скомпрометированных ключей доступа. Этот случай подтверждает, что своевременное обнаружение аномалий позволяет предотвратить более серьёзные последствия.
Часто задаваемые вопросы о почтовых атаках
- Может ли атака обойти двухфакторную аутентификацию?
Да, в описанных сценариях злоумышленники получали токены сессии и резервные коды, что позволяло обойти 2FA. Это не отменяет необходимость её использования, но требует дополнительных мер защиты. - Как обнаружить признаки компрометации?
Следует анализировать логи API на предмет необычных запросов, проверять настройки IMAP и наличие неизвестных паролей приложений. - Что делать при обнаружении чужого пароля приложения?
Необходимо отозвать все пароли приложений через административную панель, сменить основной пароль, завершить все активные сессии и проверить настройки пересылки почты. - Могут ли такие атаки происходить на других почтовых системах?
Любая веб-почта, имеющая уязвимости XSS, потенциально подвержена подобным рискам. Однако конкретные методы эксплуатации зависят от архитектуры системы. - Как организовать мониторинг DNS-туннелей?
Могут использоваться специализированные инструменты с правилами на выявление поддоменов с высокой энтропией. В качестве базовой меры можно настроить алерты на поддомены с нестандартной структурой. - Что делать, если невозможно обновить почтовую систему?
В таких случаях требуется компенсирующие меры: изоляция веб-интерфейса, ограничение доступа к API из внешних сетей, использование Web Application Firewall (WAF) и строгих политик CSP. - Какие требования регуляторов применимы к защите веб-почты в России?
Для объектов КИИ — требования ФСТЭК России к защите информации. Для финансовых организаций — требования Банка России, включая необходимость использования систем обнаружения вторжений и защиты от вредоносного кода. Несоблюдение может влечь административную ответственность.
Заключение
Многие организации недооценивают риски, связанные с использованием веб-почты, полагаясь на встроенные средства безопасности. Однако инциденты, подобные GhostMail, демонстрируют, что злоумышленники активно эксплуатируют уязвимости и используют легитимные функции систем для скрытого доступа к данным.
Регулярный аудит настроек, мониторинг активности и своевременное обновление программного обеспечения являются критически важными для поддержания необходимого уровня защищённости.
Если вы заинтересованы в проведении оценки защищённости вашей почтовой инфраструктуры или внедрении систем мониторинга угроз, вы можете обратиться к профильным специалистам.
🛡️ Оценка защищённости почтовой инфраструктуры
Мы помогаем организациям различных секторов выявлять скрытые уязвимости и выстраивать эффективную защиту. Если вам необходимо проверить свою почтовую систему или внедрить комплексный мониторинг, вы можете оставить заявку на нашем сайте.
══════
Больше материалов: Центр знаний SecureDefence.
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]
══════
⚖️ Данный материал носит информационно-аналитический характер. Все выводы основаны на открытых источниках и не являются утверждением фактов, не подтверждённых официально. Материал не является юридической или технической рекомендацией. Любые решения принимаются читателем самостоятельно.