Как я проверяю почту при подозрении на взлом

Проверять почту на взлом нужно по цепочке: входы и правила ящиков, журналы и очередь исходящих сообщений, конфигурация SMTP и DNS. Один сбой или отметка в спам-листе ничего не доказывает. Я покажу, какие сигналы сопоставить и как сохранить данные, прежде чем что-либо отключать или удалять.

Что мониторинг почты не покажет

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

Тревожный сигнал ещё не равен подтверждённому взлому. Неожиданный вход может объясняться рабочим устройством, общим адресом выхода в интернет или ошибкой учёта времени. Жалоба на спам может быть связана с репутацией адреса отправителя, неверной DNS-записью или обычной ошибкой настройки. Я фиксирую время события и проверяю, совпадает ли оно с изменениями в ящике, отправкой сообщений и журналами сервера.

Само отсутствие ошибок тоже ничего не доказывает: журнал мог не собираться, храниться слишком коротко или быть недоступен для проверки. Если система позволяет, я заранее отправляю копии журналов на отдельное хранилище и ограничиваю права на их изменение. Зелёная лампочка показывает, что служба отвечает. Она не выдаёт справку о добропорядочности каждого пользователя.

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

Чтобы замечать отклонения, нужен исходный уровень: перечень почтовых доменов и шлюзов, легальных приложений-отправителей, административных ролей и ожидаемых способов входа. Я не требую сложной системы мониторинга от небольшого офиса; достаточно записать, что обычно отправляет бухгалтерская система, кто управляет общими ящиками и где хранятся журналы. Когда поступает жалоба, это позволяет сравнить событие с обычной работой, а не гадать по одному графику. Такой список стоит обновлять после смены подрядчика, почтовой платформы или бизнес-приложения.

• Зафиксируйте время и часовой пояс события.
• Сохраните журналы входов, почтовых правил и отправки.
• Сопоставьте их с обращениями сотрудников и очередью.

Какие признаки говорят о взломе ящика

Начинаю с учётной записи: проверяю недавние входы, устройства и способы аутентификации, затем — правила ящика, автоматическую пересылку, делегированный доступ и изменения прав. Особенно внимательно смотрю на неизвестные правила, которые пересылают сообщения наружу, скрывают письма или перемещают их в непривычную папку. В Microsoft 365 для расследования доступны аудит действий с почтовыми элементами и сведения о правилах; в другой системе названия журналов и доступность аудита будут другими.

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

В условном разборе для компании «Центурион-Мед» я бы начал с конкретного ящика: зафиксировал подозрительное событие, проверил историю входов, правила и список делегатов, затем сопоставил это с журналом отправки. Пока совпадений нет, это направление проверки, а не готовая история про найденный бэкдор. Если доступ подтвердится как посторонний, действия подбираю по системе: блокирую или ограничиваю учётную запись, отзываю активные сеансы и проверяю связанные способы восстановления.

Проверяю не только веб-вход. Старый почтовый клиент, мобильное приложение, интеграция с CRM или сканер могут использовать отдельные учётные данные и подключаться привычным способом, пока пользователь уже сменил пароль. Сверяю список разрешённых устройств и приложений с реальной работой сотрудника, смотрю на созданные пароли приложений и активные сессии, если платформа это показывает. После подтверждённого захвата учётной записи одного нового пароля иногда недостаточно: нужно завершить старые сеансы и проверить, не осталось ли альтернативного способа входа.

• Неизвестная внешняя пересылка или новое правило.
• Необъяснимые входы и смена способов восстановления.
• Новые делегаты или изменения административных прав.

Как отличить спам в логах от взлома

На внешнем SMTP-контуре я проверяю приветствие сервера, согласование STARTTLS, соответствие сертификата имени сервера и запрет на отправку писем посторонним получателям без авторизации. Отдельно сверяю обратную DNS-запись отправляющего узла и проверяю доставку тестового письма на внутренний и внешний адреса. Это проверка конфигурации и доступности; она не устанавливает, кто именно пользовался ящиком.

Внутри системы сопоставляю очередь исходящих писем с журналами аутентификации: время, отправитель, получатели, объём и результат доставки. В журнале полезны успешные входы и изменения правил, а не только строки с ошибкой. Для Microsoft 365 проверьте, какие действия аудита включены именно в вашем плане и как долго хранятся записи. Если расследуете компрометацию, полезен и отдельный материал о том, что делать в первый час. Для управляемой почты также сравните параметры SMTP, IMAP и POP3 в клиентах с актуальными данными поставщика: старый адрес сервера на одном устройстве легко принять за сбой всей системы.

Попадание IP-адреса в список блокировки означает, что нужно понять тип списка и причину записи. Некоторые списки отмечают диапазоны, которым по политике не следует напрямую отправлять почту на MX; это не доказывает, что почтовый ящик взломан. Проверьте, влияет ли запись на доставку, а затем ищите подтверждения в очереди, журналах SMTP и событиях входа. Разбор репутации отправителя вынесен в статью о проверке почты по чёрным спискам.

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

• Сверьте отправителя, получателей и время сообщений.
• Проверьте очередь и ответы принимающих серверов.
• Уточните тип списка и причину попадания.

Как проверить обновления и настройки SMTP

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

SPF, DKIM и DMARC относятся к проверке подлинности отправителя и политике обработки писем. Они помогают принимающей стороне оценивать, имеют ли отправитель и подпись отношение к домену в заголовке From. Отсутствие записи не доказывает компрометацию сервера, а её наличие не мешает украсть пароль и отправлять письма из настоящего ящика. Сверьте все легальные источники отправки, подписи и отчёты DMARC; политику ужесточайте после проверки, чтобы не отрезать собственные рассылки.

В SMTP проверяю, что STARTTLS действительно согласуется и сертификат подходит имени сервера. Шифрование отдельного соединения между почтовыми узлами не делает всю цепочку доставки сквозной и не подтверждает личность автора письма. Для реле важно другое: сервер принимает почту для своих доменов и не позволяет анонимному внешнему отправителю пересылать произвольные сообщения третьим лицам. Это можно проверить снаружи, не меняя конфигурацию на боевом узле. Базовый подход к защите своего почтового сервера разобран отдельно.

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

Если почта гибридная, я проверяю оба края маршрута: локальный сервер, шлюз и облачную систему. Один и тот же домен может обслуживаться разными узлами для разных потоков. Сверяю коннекторы, правила маршрутизации и DNS-записи с утверждённой схемой; иначе исправление на одном узле не устранит неучтённый маршрут. Это помогает локализовать сбой без массовой смены настроек.

• Сверьте установленную сборку с бюллетенями производителя.
• Проверьте SPF, DKIM, DMARC и источники отправки.
• Проверьте TLS, сертификат и запрет открытого реле.

Что делать при подозрительной исходящей почте

Если растёт очередь исходящих писем, сначала выясняю, какой узел, учётная запись или приложение их создало. Проверяю одинаковые темы и получателей, время отправки, результат SMTP-аутентификации и связанные входы. Затем сравниваю объём с обычной работой отдела и проверяю, не изменились ли ограничения отправки или задача, которая рассылает уведомления. Неизвестный адрес в поле From сам по себе не определяет источник: адрес отправителя можно подделать.

Тестовое письмо отправляю на контролируемые ящики внутри и вне организации. Сверяю заголовки, результаты проверок SPF/DKIM/DMARC, маршрут доставки и ответ принимающего сервера. Если письмо попало в спам, это повод исследовать репутацию, DNS и содержимое, а не сразу объявлять сервер заражённым. Если сотрудники получают странные письма от знакомого адреса, сравниваю их с исходящими событиями этого ящика; так можно отличить подделку адреса от реальной отправки.

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

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

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

Как проверить права и файлы без потери улик

Сравниваю текущие роли и делегирование с утверждённым списком: кто может читать общие ящики, отправлять от имени другого сотрудника, менять почтовые правила и управлять сервером. Затем проверяю недавние изменения конфигурации и время, когда они были внесены. Сам факт лишнего администратора — серьёзный повод разбираться, но он не объясняет, когда и каким способом появился доступ. Для расследования важны владелец изменения, журнал аудита и соседние события.

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

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

Фиксация нужна и для дальнейшего разбора: записываю, кто обнаружил объект, когда, в какой папке и что с ним сделали. Журналы и копию файла помещаю в место с ограниченным доступом; подозрительный файл не открываю на рабочем сервере. Если система не позволяет безопасно собрать данные своими силами, сохраняю доступное и зову специалиста по расследованию до переустановки. Такая последовательность оставляет проверяемую историю действий и снижает риск уничтожить единственный образец.

После локализации снова прохожу тот же список, которым обнаружил проблему: входы, активные сеансы, правила, делегаты, исходящая очередь, SMTP-реле и DNS. Отдельно проверяю соседние ящики и приложения, к которым могла обращаться затронутая учётная запись. Исправление считаю завершённым не тогда, когда исчезло предупреждение, а когда источник закрыт, старые доступы отозваны, нормальная отправка восстановлена и новые события больше не повторяются в проверяемых журналах.

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

• Зафиксируйте время, путь и владельца изменения.
• Сохраните журналы и копию подозрительного объекта.
• Ограничьте доступ и восстановите сервис из доверенного состояния.

Частые вопросы