Фишинговая кампания AitM перехватывает учетные записи Microsoft 365 для кражи финансовых писем

Цель — сотрудники, связанные с финансовыми процессами, а результатом может стать перехват платежей. Параллельно Gen Threat Labs описала кампанию со скомпрометированными легитимными бизнес-аккаунтами, через которые доставлялось банковское вредоносное ПО и перехватывались финансовые сессии.

SPF и DKIM не подтверждают безопасность отправителя

Ключевая ошибка в такой ситуации — считать письмо доверенным только потому, что оно прошло SPF и DKIM. В описанной кампании злоумышленники использовали уже скомпрометированные корпоративные аккаунты. Такие учетные записи являются легитимными для почтовой инфраструктуры, поэтому базовые проверки домена не отвечают на главный вопрос: контролирует ли отправителя владелец аккаунта.

Алгоритм проверки должен быть разделен на два уровня:

1. Проверяйте домен и техническую аутентификацию. Контролируйте SPF, DKIM и DMARC. Ошибки в этих механизмах по-прежнему важны, но положительный результат не должен считаться доказательством безопасности конкретного письма.

2. Проверяйте состояние учетной записи. Если сообщение пришло с реального бизнес-адреса, это не исключает компрометацию Microsoft 365. Анализируйте необычные письма, связанные с платежами, счетами и финансовыми процессами.

3. Разделяйте доверие к адресу и доверие к содержимому. Легитимный MTA и корректный домен не делают безопасным вложение или ссылку.

Это меняет модель антиспама. Фильтр, ориентированный только на репутацию домена и прохождение SPF/DKIM, не закрывает сценарий с захваченным корпоративным ящиком.

Что проверить в Microsoft 365 и почтовом контуре

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

Проверьте:

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

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

Запретите автоматическое доверие к сообщениям от внутренних и партнерских адресов. Введите повторную верификацию финансовых изменений через отдельный канал. Не используйте SPF и DKIM как замену проверке личности отправителя и контекста сообщения.

Что отслеживать после инцидента

AitM-компрометация требует проверять не только письма, но и сами учетные записи Microsoft 365. Если один аккаунт использовался для финансовой переписки, его нельзя рассматривать как обычный почтовый ящик. Зафиксируйте подозрительные сообщения, ограничьте дальнейшее использование учетной записи для платежных операций и проведите проверку связанных финансовых сессий.

Для расследования важны три объекта:

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

Не смешивайте корпоративный контур с личными подписками и сторонними рассылками. Даже материалы о стиле и уходе должны оставаться вне рабочих адресов, используемых для платежей и доступа к бизнес-сервисам.

Главный вывод для почтового администратора: прохождение SPF и DKIM подтверждает технический маршрут сообщения, но не отсутствие захвата аккаунта. Настройте DMARC, контролируйте легитимные ящики и вынесите финансовую переписку в отдельный процесс верификации. Иначе скомпрометированный бизнес-адрес сохранит доверие системы и пользователей.