Новые угрозы для пользователей Microsoft 365: как работают фишинг и поддельные звонки от IT

Цель — получить не только логин и пароль, но и код MFA либо действующий сеансовый cookie, после чего использовать учетную запись для доступа к Outlook, Teams, SharePoint и OneDrive. Для администраторов это означает необходимость проверять не только почтовую фильтрацию, но и сценарии аутентификации и удалённой поддержки.

Атака начинается не с письма

Злоумышленники представляются сотрудниками IT-службы и ссылаются на конкретную проблему, которую якобы требуется устранить. Контакт может проходить по телефону, через Teams или по электронной почте. Дальше используется один из двух сценариев:

• жертву убеждают предоставить удалённый доступ;
• пользователя переводят на поддельную страницу входа Microsoft 365.

На фальшивой странице запрашиваются имя пользователя, пароль и код двухфакторной аутентификации. В описываемой кампании упоминается фреймворк BigBear 2.0 — PhaaS-инфраструктура, предназначенная для перехвата учетных данных и сеансов авторизации.

Схема работает через AiTM-прокси. Он располагается между пользователем и легитимной инфраструктурой Microsoft, перехватывает введённые данные и cookie сессии, а затем воспроизводит их через API. Поэтому сам факт включённой MFA не означает, что учетная запись защищена от такого сценария.

Проверьте отдельно:

1. Разрешён ли удалённый доступ со стороны внешних или неизвестных операторов.

2. Кто имеет право инициировать обращения службы поддержки через Teams.

3. Есть ли входы в Microsoft 365 с нетипичных IP-адресов и устройств.

4. Не появились ли новые правила пересылки, подозрительные приложения OAuth и дополнительные методы аутентификации.

5. Какие пользователи имеют доступ к данным в SharePoint и OneDrive.

Масштаб кампании требует корреляции

По данным, приведённым TechRadar со ссылкой на CloudSEK, инфраструктура BigBear 2.0 использовалась для кражи более 5000 записей, включая 474 аутентификации с обходом MFA, 1032 пароля в открытом виде и 4148 сеансовых cookie. В операции фигурировали 3331 уникальный IP-адрес в более чем 40 странах. На момент публикации кампании она оставалась активной.

CloudSEK также сообщала о 461 атакованной организации. Для 258 из них была зафиксирована компрометация как минимум одного набора учетных данных. Эти данные нельзя трактовать как полный реестр всех пострадавших: речь идёт о результатах отслеживания конкретной кампании.

Отдельно исследователи Arctic Wolf описывают оператора PREY-0058. По данным TechRadar, он использует методы, пересекающиеся с другими группами, но не считается переименованной старой организацией. Различия между операторами размыты: несколько аффилированных групп и отдельных команд могут использовать одну и ту же фишинговую инфраструктуру.

Основной интерес атакующих — данные Microsoft 365. В фокусе находятся почта, переписка в Teams, документы SharePoint и файлы OneDrive. Развёртывание ransomware в описанном сценарии встречается редко. Это не снижает ущерб: украденная сессия позволяет действовать внутри доверенного аккаунта и использовать его для дальнейшего доступа к корпоративным данным.

Что изменить в конфигурации

Настройте Conditional Access для ограничения входов по риску, устройству, географии и другим доступным условиям. Применяйте phishing-resistant MFA. Обычные коды MFA и push-подтверждения не перекрывают все сценарии AiTM-перехвата.

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

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

Почтовые шлюзы также требуют проверки. В заголовках кампаний, описанных The Hacker News и Rescana, отдельно упоминается использование невидимых Unicode-символов для обхода фильтров. Не ограничивайтесь анализом отображаемого текста. Проверяйте нормализацию Unicode, URL, HTML-структуру и фактическое назначение ссылок.

Зафиксируйте инцидент как компрометацию сессии, если пользователь уже ввёл данные на подозрительной странице. Сброс пароля в этом случае недостаточен: отзовите активные сессии, проверьте методы MFA, приложения и правила пересылки, затем пересмотрите журналы доступа к Outlook, Teams, SharePoint и OneDrive.