В середине апреля 2026 года компания-производитель, использующая почтовый шлюз Proofpoint, стала целью масштабной фишинговой кампании, нацеленной на кражу учётных данных. За три дня, с 17 по 20 апреля, злоумышленники отправили пятнадцать хорошо составленных писем, которые все доставили в почтовые ящики сотрудников. Причиной успеха атаки стал единственный конфигурационный пробел: политика DMARC жертвы была установлена в режим p=none. Этот случай наглядно демонстрирует, почему защита на уровне шлюза недостаточна, если не настроены механизмы аутентификации электронной почты.
Описание
Кампания была обнаружена с помощью AI-движка поведенческого анализа компании ZeroBEC. Специалисты выяснили, что все пятнадцать писем не были заблокированы Proofpoint - шлюз действовал строго в рамках заданной конфигурации. Публичная DNS-запись DMARC клиента содержала директиву p=none, которая предписывает не принимать никаких мер против писем, не прошедших проверку DMARC. При этом организация оплачивала сервис Proofpoint Email Fraud Defense для агрегации отчётов DMARC, но так и не перевела политику в режим карантина или отклонения, опасаясь блокировки легитимной почты от сторонних отправителей.
Атакующие построили всю атаку вокруг этой уязвимости конфигурации. Каждое письмо было отправлено с внешнего IP-адреса 104.161.36.39 с подменой поля From, Return-Path и Message-ID на домен жертвы. Microsoft Exchange Online корректно отметил, что SPF-проверка не пройдена (softfail), DKIM-подпись отсутствует, а DMARC дал сбой. Однако из-за политики p=none действие не было выполнено, и почта попала в ящик. Более того, поскольку внутренние политики безопасных отправителей организации активно пропускали такие сообщения, письмо отображалось с зелёным баннером "Этот отправитель проверен из списка безопасных отправителей [организации]". Системы, которые должны были защищать, начали работать на злоумышленника.
Большинство писем использовали технику "от себя к себе" (self-to-self): адрес отправителя совпадал с адресом получателя. Это психологический приём - пользователь видит письмо от своего собственного адреса, теряет бдительность и воспринимает сообщение как внутреннее уведомление. Каждое письмо имело уникальный 40-символьный шестнадцатеричный идентификатор в теме, что не позволяло почтовым шлюзам группировать их как одну кампанию. Для SOC-аналитиков отсутствие общего шаблона темы делало невозможным быстрый поиск по всем инцидентам.
Визуальное оформление писем варьировалось: использовались кнопки с надписями вроде "RE-ACTIVATE SAME PASSWORD", "View Document", "View Receipt", имитировавшие уведомления от Microsoft 365, Trello, DocuSign, LienStar Portal и других сервисов. По нажатию на кнопку жертва попадала в цепочку перенаправлений, где каждое звено было легитимным сервисом: Google redirectors, Trend Micro URL protect, Inky shared-link domain, EdgePilot, Esvalabs URL sandbox, Cognito Forms, Monday.com tracker и независимые редиректоры. Все эти ресурсы имели безупречную репутацию, и шлюз не блокировал переходы на них. Как показала телеметрия ZeroBEC, атакующий эксплуатировал доверие к вендорам защиты электронной почты, чьи ссылки на обёртку URL считались надежными.
После прохождения цепочки редиректов пользователь попадал на подконтрольный атакующему домен, например microsoftsecure.splnappliances.com. Но перед отображением страницы ввода пароля жертву встречал CAPTCHA-челлендж ("Security Checkpoint: Verify You Are Human") или запрос одноразового кода, отправленного легитимным сервисом (в данном случае Atlassian/Trello) на реальный почтовый ящик пользователя. CAPTCHA исключает возможность автоматического анализа URL в песочнице, поскольку ни один современный шлюз не решает капчи массово. Запрос OOB-кода через сторонний сервис делает детонацию ссылки в изолированной среде принципиально невозможной - код приходит только на настоящий ящик, а не в песочницу.
Только после преодоления этих преград открывалась точная копия формы входа Microsoft с предзаполненным адресом электронной почты жертвы. Эта страница работает как Adversary-in-the-Middle (AiTM) прокси: введённые учётные данные и сессионные токены после успешного прохождения MFA (многофакторной аутентификации) перехватываются злоумышленником. MFA при этом не обходится, а проксируется - пользователь сам подтверждает вход на своём устройстве, и атакующий получает действующую аутентифицированную сессию.
В этой кампании один из пятнадцати адресатов прошёл все шаги. Действия атакующего после успешного входа стали современным сценарием закрепления. В течение десяти секунд после захвата сессии злоумышленник зарегистрировал собственное приложение-аутентификатор в качестве метода MFA в учётной записи жертвы. Сессионный куки-файл истекает, но новый MFA-метод остаётся навсегда. Даже если пароль пользователя сброшен, злоумышленник может повторно войти, используя свой аутентификатор для прохождения MFA. Стандартная процедура восстановления учётной записи - сброс пароля - оказывается недостаточной. Для полной эвакуации необходимо сбросить все активные токены обновления и сессионные куки, а также удалить все MFA-методы, добавленные в период атаки. Любое упущение даёт злоумышленнику возможность вернуть доступ.
Атака не была остановлена Proofpoint по четырём независимым причинам. Во-первых, политика DMARC p=none отключала основной антиспуфинговый сигнал. Во-вторых, уникальные гекс-токены не позволяли кластеризовать сообщения. В-третьих, цепочка перенаправлений через доверенные вендоры делала URL-репутацию бесполезной. В-четвёртых, CAPTCHA и OOB-коды блокировали детонацию URL в песочницах. По отдельности каждый из этих методов преодолим, но в совокупности они обходят любой почтовый шлюз, включая Proofpoint и аналоги. Поведенческий анализ, в отличие от сигнатурного, выявляет аномалии, которые невозможно скрыть: self-to-self письма от внешнего IP, массовое появление одинаковых структур у пятнадцати получателей, аномальный вход с незнакомого IP и моментальная регистрация нового аутентификатора. Именно такой подход позволил ZeroBEC обнаружить кампанию и предотвратить более серьёзные последствия.
Индикаторы компрометации
IPv4
- 104.161.36.39
Domain
- cdr.websitescare.com
- gateway.exwa.org
- hairsystemlab.com
- microsoftsecure.splnappliances.com
