Фишинг под внутренние домены: DMARC, SPF и Office 365

Кратко: Акторы, занимающиеся фишингом, всё чаще используют сложные схемы маршрутизации и неправильно настроенные средства защиты от подделки доменов, чтобы отправлять правдоподобные электронные письма, выглядещие как сообщения из внутренних доменов организации. Эти кампании, иногда реализуемые через платформы Tycoon2FA и другие решения phishing as a service, нацелены на кражу учетных данных и организационные финансовые потоки.

Как работают атаки

Атакующие комбинируют несколько приёмов, чтобы повысить вероятность успеха фишинга:

• сложная маршрутизация писем и использование сторонних почтовых соединителей;
• эксплуатация неправильно настроенных MX-записей и слабых политик подделки (DMARC, SPF);
• маскировка под легитимные сервисы и внутренние роли — например, DocuSign или сообщения отдела кадров;
• многообразие приманок: голосовая почта, общие документы, запросы на сброс пароля или изменение льгот;
• побуждение к переходу по ссылкам или сканированию QR-кодов, ведущих на фишинговые сайты.

Ключевые индикаторы компрометации

В наблюдаемых письмах часто встречаются характерные признаки, повышающие их успех:

• в полях «От» и «Кому» указываются один и тот же внутренний адрес, что создаёт иллюзию внутренней переписки;
• отсутствие принудительной аутентификации из‑за разрешающих настроек DMARC и «мягких» SPF-политик;
• темы, связанные с финансами или деловой перепиской между руководителями — используемые для финансовых афер.

Microsoft Threat Intelligence задокументировала случаи, когда такие поддельные письма использовались для финансовых афёр и запросов, маскирующихся под обсуждения между топ‑менеджерами.

Почему это работает: уязвимые места в инфраструктуре

Главные технические проблемы, которыми пользуются злоумышленники:

• Неперенаправленные MX‑записи: если MX-записи не указывают на Office 365 или другой защищённый сервис, письма могут обходить внутренние фильтры.
• Слабые или отсутствующие DMARC‑политики: при разрешающей (например, none) политике подделанные сообщения доходят до почтовых ящиков.
• «Мягкий» SPF (~all) вместо строгого fail (-all) даёт злоумышленникам шанс проходить проверку.
• Неправильная конфигурация сторонних почтовых соединителей, позволяющая отправлять письма от имени корпоративного домена.

Риски и последствия

Эти кампании ориентированы на два основных результата:

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

Рекомендации по защите (пошаговый план)

Организациям следует реализовать сочетание конфигурационных и детекционных мер:

• Внедрить строгие DMARC‑политики с параметром reject для предотвращения доставки поддельных писем;
• Установить жёсткий SPF (использовать -all) и регулярно проверять список разрешённых отправителей;
• проверить и корректно настроить все сторонние почтовые соединители и маршрутизацию MX‑записей (особенно при использовании Office 365);
• внедрить принудительную аутентификацию и многофакторную аутентификацию (MFA) для критичных учётных записей;
• усилить мониторинг почтового трафика и внедрить корреляцию событий между почтой и конечными точками;
• использовать современные средства XDR/EDR для обнаружения сложных атак и автоматизации реагирования — например, Microsoft Defender XDR;
• обучать сотрудников распознаванию фишинга: внимание к совпадению «От» и «Кому», ссылкам, QR‑кодам и неожиданным финансовым запросам;
• внедрить процедуры проверки финансовых операций вне электронной почты (телефонная верификация, многоступенчатые утверждения).

Вывод

Актуальные фишинговые кампании демонстрируют, что даже при кажущейся внутренней легитимности письмо может быть частью продуманной атаки. Ключ к снижению риска — сочетание корректных конфигураций почтовой инфраструктуры (DMARC, SPF, MX и соединителей), строгих политик аутентификации и эффективных средств детекции и реагирования. Скоординированные меры безопасности на уровне почты и конечных точек, а также использование интегрированных платформ защиты значительно снижают вероятность успешной компрометации.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.