После подозрения на взлом корпоративной почты администратор обычно спешит закрыть доступ и восстановить работу. Это необходимо, но перезапуск сервера, удаление подозрительных файлов и замена системы могут уничтожить следы. Рассказываем, какие материалы сохранить до изменений и какие выводы из них действительно можно сделать.
Сначала зафиксируйте состояние системы
Запишите, когда и кто обнаружил признаки инцидента, часовой пояс сервера, его имя, адреса, версию почтовой платформы и состав установленных компонентов. Отдельно фиксируйте каждое действие администратора: время, исполнителя, команду, результат и причину. Если сервер остаётся под контролем злоумышленника, решение об изоляции принимают без промедления, но порядок действий и состояние до вмешательства всё равно документируют насколько возможно.
Для виртуальной машины может пригодиться снимок состояния и копия дисков, для физического сервера — образ носителей. Способ получения зависит от инфраструктуры и риска потери оперативных данных. Исходные копии хранят отдельно от рабочих, записывают контрольные суммы, дату получения и передачи. Эти меры помогают впоследствии отличить обнаруженные артефакты от изменений в ходе восстановления.
Какие данные собрать
- Почтовые и системные журналы. События приёма и отправки сообщений, входы в учётные записи, действия администратора, журналы веб-сервера, системы и средств защиты. Сохраните исходные файлы с их временем и метаданными, включая архивы ротации.
- Конфигурация и версии. Версия продукта, установленные пакеты, параметры доступных служб и уведомлений, настройки доступа, сведения об обновлениях и резервных копиях. Секреты и ключи защищают от лишнего доступа.
- Следы исполнения и закрепления. Список процессов и соединений на момент обнаружения, запущенные службы, задания планировщика, новые учётные записи, ключи SSH, необычные файлы в каталогах приложения и изменённые права доступа.
- Внешние источники. Журналы межсетевого экрана, прокси, почтового шлюза, DNS, EDR и централизованного мониторинга. Они особенно важны, если локальные журналы могли быть очищены.
Передача материалов специалисту должна включать происхождение каждой копии: с какого узла она получена, каким способом, кем и когда. Ограниченный срок хранения журналов — повод выгрузить их сразу, даже если анализ начнётся позднее.
Что показывает пример Zimbra
В исследовании от 30 сентября 2026 года Microsoft описала эксплуатацию CVE-2026-73570 в определённых конфигурациях Zimbra: при установленном дополнительном пакете zimbra-snmp и включённых SNMP-уведомлениях. Исследователи наблюдали внедрение веб-оболочек, удалённый доступ, обращение к учётным данным и подготовку архивов данных на отдельных скомпрометированных серверах. Описание объединяет разные случаи: оно не означает, что каждый затронутый сервер прошёл все стадии атаки.
Для конкретной организации наличие уязвимой версии или подозрительного файла само по себе не устанавливает факт утечки почты. Чтобы оценить объём доступа, сопоставляют события исполнения команд, журналы почтовой платформы, обращения к файлам, создание архивов и исходящие соединения. Даже зафиксированная передача данных требует проверки, что именно передавалось и с какого узла.
Когда обновлять и менять доступы
Уязвимые системы нужно изолировать и обновлять в соответствии с рекомендациями производителя. Для указанной проблемы Zimbra сообщает об исправлении в версии 10.1.20. Если расследование необходимо, до очистки и переустановки по возможности сохраняют доступные следы; это не повод откладывать срочное сдерживание атаки. После фиксации состояния проверяют учётные записи, токены, ключи и механизмы закрепления, затем меняют скомпрометированные секреты и восстанавливают сервер из доверенного источника.
Если нужно установить последовательность действий на почтовом сервере и границы возможного доступа к данным, можно обратиться за расследованием инцидента информационной безопасности или компьютерно-технической экспертизой. Выводы зависят от сохранности исходных материалов и поставленных вопросов.
Источники: Microsoft Security Research, 30.09.2026; Zimbra Security Advisories; NIST SP 800-61 Rev. 3. Материал подготовлен 05.10.2026.