Дослідники Arctic Wolf Labs зафіксували масштабну фішингову кампанію, націлену на облікові записи Microsoft 365. Зловмисники застосовують техніку adversary-in-the-middle (AitM) для перехоплення облікових даних і кодів багатофакторної автентифікації, після чого використовують скомпрометовані сесії для збору листування співробітників, пов’язаних із фінансовими процесами — нарахуванням заробітної плати, платежами та банківськими операціями. За даними дослідників, протягом останнього місяця фішингові листи отримали сотні організацій із секторів охорони здоров’я, освіти, виробництва, державного управління та професійних послуг у США, Канаді та Європі.
Багатоступеневий ланцюжок атаки
Початковий вектор — фішингові листи з темою голосових повідомлень. Жертву перенаправляють через шестиступеневий ланцюжок редиректів, який задіює легітимні сервіси для обходу репутаційних фільтрів:
- Посилання-редирект Google Meet
- Інфраструктура вихідних посилань Google
- Динамічний трекер кліків Google Campaign Manager (
/ddm/clk) - HTML-об’єкт, розміщений у кошику Amazon S3
- Фінальний редирект на AitM-інфраструктуру
- Проксована сторінка авторизації Microsoft OAuth
Використання довірених доменів Google та Amazon на проміжних етапах дає змогу листам і посиланням проходити крізь засоби безпеки, орієнтовані на репутацію домена.
Фінгерпринтинг і геолокація
Фішингові сторінки виконують JavaScript-код для зняття цифрового відбитка браузера жертви: збираються дані про операційну систему, розміри екрана, мову браузера, зміщення часового пояса, підтримку cookie, статус WebDriver, вендора WebGL та доступні API браузера. Зібрана інформація надсилається на PHP-ендпоінт через HTTP POST-запит, після чого браузер перенаправляється на проксований ендпоінт авторизації Microsoft OAuth.
Додатково фішинговий набір звертається до API геолокації api.country[.]is для визначення країни жертви. Результат зберігається в cookie rcfh_country зі строком дії сім днів. За оцінкою дослідників, ці дані ймовірно використовуються для добору географічно відповідної проксі-інфраструктури під час подальших входів до скомпрометованих акаунтів.
Автоматизація постексплуатації
Після отримання початкового доступу зловмисники демонструють характерний патерн поведінки, відмінний від типових BEC-атак. Як повідомляється, через 11–24 години після первинної компрометації починаються автоматизовані входи з інтервалом приблизно вісім годин із ротацією резидентних проксі-адрес. При цьому ідентифікатор сесії (SessionID) залишається незмінним, тоді як IP-адреса, ASN і географічне розташування змінюються — що вказує на централізовану автоматизацію оновлення кожної скомпрометованої сесії.
Дослідники зафіксували низку аномалій у даних про входи:
- Малоймовірні комбінації браузера й ОС — мобільні версії Apple Safari або Google Chrome на Windows 10
- Як клієнтський застосунок указано Microsoft Outlook, але user-agent містить Firefox 131.0, Firefox 151.0 або Python Requests замість очікуваного Edge
- Використання резидентних проксі маскує шкідливі входи під звичайний споживчий трафік
Цілеспрямований збір фінансового листування
Для розвідки всередині скомпрометованих тенантів зловмисники використовують Microsoft Graph API, перелічуючи користувачів, пов’язаних із функціями розрахунку заробітної плати, HR, фінансів та адміністрування. Далі здійснюється доступ до повідомлень, що містять інформацію про зарплати, рахунки, платежі, банківські реквізити, пільги й внутрішні документи.
Показово, що в більшості розслідуваних інцидентів постексплуатаційна активність обмежувалася підтриманням сесій, розвідкою та збором вмісту поштових скриньок. Дослідники не спостерігали змін методів MFA, реєстрації пристроїв, модифікації облікових даних, латерального фішингу або створення правил для вхідних повідомлень. Така стриманість зменшує можливості раннього виявлення, заснованого на моніторингу змін облікових записів.
У поодиноких випадках зафіксовано ручну активність: створення правил, що автоматично переміщують певні повідомлення з папки «Вхідні» до «Видалені» з позначкою «прочитано». Це свідчить про гібридну модель, де оператори втручаються вибірково, а автоматизована інфраструктура забезпечує рутинні операції.
Зв’язок із відомими кампаніями
Описана активність, за даними Arctic Wolf, має тактичні перетини з кампаніями групування Payroll Pirates — фінансово вмотивованого кластера загроз, що спеціалізується на перехопленні облікових записів співробітників для перенаправлення зарплатних виплат на підконтрольні рахунки. Окремі аспекти цих кампаній документуються з початку 2025 року. Слід зауважити, що атрибуція ґрунтується на оцінці одного вендора й не підтверджена незалежними джерелами.
Рекомендації щодо виявлення й захисту
З огляду на специфіку кампанії — обхід MFA, використання резидентних проксі та мінімальну постексплуатаційну активність — стандартні механізми виявлення BEC можуть виявитися неефективними. Рекомендовані заходи:
- Моніторинг аномалій сесій: відстежуйте входи, за яких SessionID зберігається, але IP-адреса, ASN і геолокація змінюються. Восьмигодинні інтервали між входами — характерний індикатор
- Аналіз user-agent: фіксуйте невідповідності між заявленим клієнтським застосунком (Outlook) і фактичним user-agent (Firefox, Python Requests)
- Перевірка комбінацій браузер/ОС: мобільні версії Safari або Chrome на Windows 10 — явна ознака підміни
- Аудит доступу до Graph API: відстежуйте масове перерахування користувачів і доступ до поштових скриньок через Graph API, особливо до скриньок співробітників фінансових і HR-підрозділів
- Політики умовного доступу: впровадьте оцінку відповідності пристроїв (device compliance) як обов’язкову умову для доступу до Microsoft 365 — це суттєво ускладнить використання вкрадених сесій із некерованих пристроїв
- Блокування IOC: домен
api.country[.]isможе бути заблокований на рівні DNS або проксі як індикатор фішингової інфраструктури
Затримка між початковою компрометацією та початком автоматизованої активності (11–24 години), у поєднанні з навмисною відмовою від типових дій BEC, робить цю кампанію особливо складною для ретроспективного виявлення. Організаціям, що використовують Microsoft 365, слід негайно перевірити журнали входів за останні 30 днів на предмет описаних аномалій — невідповідностей user-agent, ротації IP за збереження SessionID і нетипових звернень до Graph API від імені облікових записів фінансових підрозділів.
