Обращение пришло стандартное: «С нашей почты кому-то ушло странное письмо, проверьте». В итоге выяснилось, что злоумышленники больше недели имели доступ к трём корпоративным ящикам, скачивали переписку и получали копию каждого нового письма. Ниже — как восстанавливалась картина по логам почтового сервера и что из этого стоит вынести любой компании.

Инцидент полностью обезличен: названия организаций, адреса, IP-адреса и точные даты не приводятся. Время указано относительно начала атаки.

Исходные данные

  • Почтовый сервер клиента на хостинге: IMAP/SMTP и веб-почта на Roundcube.
  • Жалоба: письмо, которое сотрудник не отправлял.
  • Что было доступно для анализа: логи IMAP, SMTP и веб-почты, включая журнал действий в Roundcube.

Первое правило расследования — сначала сохранить логи, потом что-то менять. Ротация легко сотрёт самое важное — момент первого входа.

Как искать: от аномалии к хронологии

Отправная точка — подозрительное письмо. От него раскручивается цепочка:

  1. SMTP-лог: кто и с какого IP прошёл SMTP AUTH и отправил письмо.
  2. Этот IP — в логах IMAP и веб-почты: куда ещё он заходил.
  3. Все входы в затронутые ящики за большой период: какие IP и страны для них обычны, а какие — нет.
  4. Новые IP — снова по всем логам, пока круг не замкнётся.

На практике хорошо работает простое правило: для небольшой компании, где все сотрудники работают из одной страны, любой успешный вход из-за рубежа через датацентр или VPN — красный флаг. Проверка по GeoIP и ASN сразу отделила легитимные входы от чужих: все подозрительные адреса принадлежали хостингам и VPN-сервисам в разных странах.

Хронология атаки

ВремяЧто произошло
День 1, утроПервый успешный вход по IMAP сразу во все три ящика — IP датацентра за рубежом
День 1, +3 часаПовторные IMAP-входы с другого зарубежного IP
День 1, следующие 2 часаМассовое скачивание писем через IMAP с третьего адреса (VPN)
День 1В одном из ящиков создано правило пересылки Sieve — копия всех входящих уходит на внешний адрес
День 3, вечерЧерез SMTP AUTH с одного из ящиков отправлено письмо деловому контрагенту с вложением — тот самый «странный» мейл
День 8Вход в веб-почту из ещё одной страны: просмотр настроек, фильтров пересылки, смены пароля и подписей
День 8, +1 часПовторный вход в веб-почту, просмотр писем, похожих на уведомления европейских банков

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

Что делали злоумышленники и зачем

  1. Скачивание почты по IMAP. Протокол удобен атакующему: не нужно открывать веб-интерфейс, и пользователь ничего не замечает.
  2. Скрытая пересылка через Sieve. Самый опасный элемент: даже после смены пароля копия переписки продолжает уходить наружу, пока правило не удалено. В интерфейсе почты такое правило легко не заметить.
  3. Отправка письма контрагенту. Классика BEC: письмо от настоящего ящика, в живой цепочке переписки, с вложением. Получатель доверяет отправителю, потому что ящик настоящий.
  4. Изучение настроек через веб-почту. Атакующий проверял, на месте ли пересылка, можно ли сменить пароль и подпись — то есть закреплялся и готовился к следующему шагу.

Тип атаки — BEC (Business Email Compromise): компрометация деловой переписки с целью финансового мошенничества — подмены реквизитов в счетах, «срочных» платежей от имени руководителя, рассылки вредоносных вложений партнёрам.

Масштаб последствий

  • переписка трёх сотрудников за длительный период — у атакующего;
  • все входящие письма с первого дня атаки пересылались наружу;
  • под угрозой деловая переписка, счета, персональные данные и контрагенты, которым могли уйти письма от имени компании.

Что делать при таком инциденте

Немедленно:

  • сменить пароли всех затронутых ящиков и всех ящиков с похожими паролями;
  • удалить правила пересылки и фильтры Sieve — проверить не только затронутые ящики, но и все остальные;
  • завершить активные сессии IMAP и веб-почты;
  • заблокировать IP-адреса атакующих на уровне файрвола почтового сервера;
  • предупредить контрагентов, которым могли прийти письма от имени компании: не проводить платежи по реквизитам из этих писем без звонка.

Затем:

  • проверить рабочие станции владельцев ящиков на вредоносное ПО — пароли могли украсть с них;
  • выяснить, откуда утекли пароли: фишинговые письма, утечки, повторное использование;
  • сохранить индикаторы компрометации (IP, адреса пересылки, темы писем) и поставить их на мониторинг.

Как не допустить

  • Двухфакторная аутентификация для веб-почты и запрет «простых» протоколов без неё там, где это возможно.
  • Оповещения о входе из необычной страны или с IP датацентров — это ловится даже простыми правилами в SIEM.
  • Запрет или контроль автоматической пересылки на внешние адреса на уровне почтового сервера.
  • Уникальные сложные пароли и менеджер паролей.
  • Обучение сотрудников: письмо от «банка» или «партнёра» с просьбой срочно ввести пароль или оплатить счёт — повод перезвонить.
  • SPF, DKIM и DMARC — не защитят от входа в настоящий ящик, но мешают подделывать ваш домен в других атаках.

Выводы

  • Самые опасные взломы почты — тихие. Атакующему выгодно не рассылать спам, а неделями читать переписку и ждать момента для мошенничества.
  • Смена пароля не закрывает инцидент, если не удалить правила пересылки.
  • Логи почтового сервера позволяют восстановить почти всю картину — если их сохранить до того, как их сотрёт ротация.
  • Вход из-за рубежа через VPN или датацентр в ящик сотрудника локальной компании — один из самых дешёвых и надёжных сигналов для мониторинга.

Похожие сигналы я собираю в SIEM — подробнее в статье «SOC на Wazuh с нуля».