«Пастка закупівель»: нова хвиля фішингу Microsoft 365, що обходить MFA через зламані поштові скриньки Outlook

• Вектор атаки: Зловмисники зламують легітимні сайти малих підприємств та облікові записи Outlook, щоб розміщувати та поширювати фішингові посилання, що виглядають як надійна інфраструктура .
• Цілі: Кампанія цілеспрямовано атакує університети, великі підприємства та міжнародні інституції, включно з установами Європейського Союзу та Організації Об'єднаних Націй .
• Використання наборів AiTM: Зловмисники чергують кілька наборів Phishing-as-a-Service (PhaaS):
  • EvilProxy – набір, який перехоплює сесійні cookie, щоб обійти SMS-коди, застосунки-автентифікатори та push-сповіщення .
  • FlowerStorm – широко поширена PhaaS-операція, яка нещодавно почала використовувати обфускацію на основі віртуальної машини в браузері для обходу захисту електронної пошти .
  • Kali365 – PhaaS-платформа, вперше виявлена у квітні 2026 року, яка поширюється через Telegram і використовує фішинг кодів пристроїв (device code phishing) для захоплення токенів сесії без необхідності знати пароль або код MFA .
• Алгоритмічні домени (RDGA): Для створення великої кількості фішингових URL, які швидко змінюються, використовуються масово зареєстровані алгоритмічні домени, що ускладнює їх блокування .

Як працює атака (технічний механізм)

Зловмисник налаштовує проміжний фішинговий сайт, який діє як живий зворотний проксі між жертвою та легітимним сервісом автентифікації Microsoft 365 . Коли жертва вводить облікові дані та завершує MFA, проксі перехоплює отриманий сесійний cookie, перш ніж він потрапить у браузер жертви. Потім зловмисник імпортує цей cookie у свій власний браузер і отримує повний доступ до Exchange Online, SharePoint, OneDrive та будь-яких федеративних застосунків жертви .

Численні джерела описують однаковий базовий механізм: проксі створює двосторонній зв'язок у реальному часі, тоді як традиційний фішинг лише клонує сторінки входу та викрадає облікові дані . Оскільки токен сесії підтверджує, що користувач уже пройшов MFA, зловмиснику не потрібно зламувати саму MFA .

Чому стандартна MFA недостатня

У документації Microsoft зазначається, що AiTM-фішинг долає поширені методи MFA, такі як SMS-коди, push-сповіщення застосунків-автентифікаторів та TOTP-токени . Сесійний cookie, виданий після завершення MFA, є головною ціллю: якщо його викрадено, його можна використати з будь-якого пристрою, з будь-якої точки світу, доки токен не закінчиться або не буде адміністративно відкликаний.

Звіт Infoblox наголошує, що традиційна MFA недостатня, оскільки AiTM-проксі крадуть токен сесії, виданий після завершення MFA . Основна проблема архітектурна: проксі розташований між користувачем і реальною кінцевою точкою автентифікації, і класична MFA не може цього виявити.

Захист понад MFA: рекомендації Infoblox

Infoblox рекомендує багаторівневу стратегію захисту, яка не покладається на MFA як єдину точку відмови. Основні рекомендації:

1. Захист на рівні DNS – блокувати відомі шкідливі домени та новозареєстровані алгоритмічні домени (RDGA) на рівні DNS, щоб перешкодити фішинговій інфраструктурі до того, як користувачі зможуть до неї звернутися .
2. Стійкі до фішингу облікові дані – впровадити апаратні ключі безпеки FIDO2/WebAuthn або Windows Hello для бізнесу. Вони використовують криптографію з відкритим ключем, прив'язану до конкретного походження. AiTM-проксі не може переслати виклики FIDO2, оскільки криптографічне підтвердження прив'язане до домену легітимного сайту, а не до проксі.
3. Політики умовного доступу – впровадити суворі політики ризику входу в Microsoft Entra ID, такі як вимога прив'язки токена, блокування входів з незвичних місць або пристроїв, а також скорочення тривалості сесій, щоб зменшити вікно для повторного використання cookie.
4. Управління ризиками та моніторинг бренду – активно виявляти фішингові домени, які імітують організацію, та ліквідовувати інфраструктуру до того, як користувачі зіткнуться з приманками .
5. Підвищення обізнаності та звітність – навчати користувачів розпізнавати фішингові приманки на тему закупівель і повідомляти про підозрілі листи, що дозволить швидше реагувати службі безпеки (SOC).

ФБР також спеціально попередило про Kali365, радячи організаціям перевірити свої методи MFA, проаналізувати журнали входу на предмет аномальних потоків кодів пристроїв та розглянути можливість блокування автентифікації за кодом пристрою для всіх користувачів, крім довірених застосунків .

Обмеження доказів та обсяг

Звіт Infoblox є первинним джерелом для назви кампанії, націлювання на установи ЄС/ООН та використання зламаних поштових скриньок Outlook і сайтів малих підприємств. Вторинні репортажі незалежно підтверджують цілі та зміну наборів.

Компонент Kali365 незалежно підтверджено публічним попередженням ФБР та вендорами безпеки Huntress і Paubox , але звіт Infoblox групує його разом з EvilProxy та FlowerStorm під однією інфраструктурою на тему закупівель.

Рекомендації із захисту поєднують прямі твердження зі звіту Infoblox з усталеними галузевими практиками, задокументованими в різних джерелах . Жоден окремий абзац у джерелах не перелічує кожен пункт захисту в маркованому списку; наведений вище перелік синтезує рекомендації, знайдені в цитованих матеріалах.

Висновок

«Пастка закупівель» ілюструє зростаючу тенденцію: зловмисники не намагаються зламати MFA — вони повністю її оминають, викрадаючи сесійні cookie, видані після успішної автентифікації. Технічні контрзаходи, такі як апаратні ключі FIDO2 та блокування доменів на рівні DNS, можуть значно знизити ризик, але першою лінією захисту залишається пильність користувачів. Організаціям, які використовують Microsoft 365, слід перевірити журнали автентифікації на предмет несподіваних кодів пристроїв або шаблонів AiTM та в першу чергу впровадити стійкі до фішингу облікові дані.