Контекст: зловмисникам більше не обов’язково зламувати систему
Кіберзлочинці, які атакують Microsoft 365 та Azure, значною мірою відійшли від використання шкідливого ПЗ і атак підбору облікових даних. Нова схема дій простіша: знайти діючу функцію Microsoft, яку можна використати для атаки, поєднати її з приманкою соціальної інженерії та маскуватися під звичайну ІТ-активність, доки шкоди вже буде завдано.
Дві кампанії, задокументовані в травні 2026 року, чітко показують, як це працює. ФБР попередило про Kali365, платформу Phishing-as-a-Service, яка викрадає токени OAuth та надає постійний доступ до M365 без запиту пароля. Microsoft детально описала, як Storm-2949 використала фальшивий дзвінок від ІТ-підтримки та одне підтвердження MFA, щоб здійснити розширення атаки в усьому середовищі Azure.
💡 Жодна з цих атак не потребувала вразливості програмного забезпечення. Обидві почалися з того, що користувач ухвалив рішення, яке виглядало цілком логічним, але спиралося на неправдиві передумови.
Розбір атак
Kali365: фішингова система, яка викрадає доступ до M365 без пароля користувача
Kali365 – це платформа PhaaS, яка поширюється через Telegram із квітня 2026 року. Вона надає малодосвідченим зловмисникам усе необхідне для проведення кампанії з обходом MFA: приманки, створені за допомогою ШІ, автоматизовані шаблони, дешборди відстеження та перехоплення OAuth-токенів. Технічна експертиза не потрібна.
Ланцюг атаки:
- Фішинговий лист імітує довірений хмарний сервіс і пропонує отримувачу ввести код пристрою на справжній сторінці Microsoft.
- Жертва переходить за URL-адресою Microsoft і вставляє код. При цьому вона несвідомо авторизує пристрій зловмисника.
- Kali365 перехоплює отримані OAuth-токени доступу та оновлення.
- Зловмисник отримує постійний доступ до Outlook, Teams і OneDrive. Пароль не потрібен, а подальше підтвердження MFA не вимагається.
Потік коду пристрою Microsoft – це функція, створена для пристроїв, які не можуть відображати сторінку входу. Kali365 використовує її проти звичайних корпоративних користувачів. Оскільки ціль виконує дію на справжній сторінці Microsoft, стандартне MFA вже проходить успішно ще до того, як зловмисник отримує токен.
Storm-2949: один телефонний дзвінок, одне підтвердження MFA та повний компрометований доступ до Azure
Storm-2949 – фінансово мотивований зловмисник, який перетворив одну взаємодію із застосуванням соціальної інженерії на масштабну ексфільтрацію даних з Azure. При цьому не було розгорнуто жодного шкідливого ПЗ.
Ланцюг атаки:
- Зловмисник видає себе за представника внутрішньої ІТ-служби підтримки та зв’язується з цільовим користувачем. Наприклад співробітником ІТ-відділу або представником вищого керівництва.
- Користувача переконують підтвердити запит MFA у межах «планового скидання пароля».
- Зловмисник використовує Microsoft SSPR, щоб скинути пароль облікового запису, видалити методи автентифікації користувача та зареєструвати власний пристрій. У результаті користувач втрачає доступ до свого облікового запису.
- Процес повторюється ще для трьох облікових записів із привілейованими ролями Azure RBAC.
- Маючи ці облікові записи, зловмисник вільно переміщується в середовищі: масово завантажує дані з OneDrive і SharePoint, витягує секрети з Azure Key Vault, отримує доступ до баз даних SQL, ексфільтрує дані з облікового запису Storage та встановлює ScreenConnect на віртуальні машини для постійного віддаленого доступу.
Уся операція виглядала як звичайна адміністративна активність. Для виявлення потрібно було одночасно корелювати сигнали з облікових записів, M365 та Azure. Дзвінок із використанням соціальної інженерії був єдиною вразливістю, яка мала значення. Усе інше стало наслідком того, що один користувач підтвердив один запит MFA, який сам не ініціював.
Дізнайтеся більше про те, як зловмисники зловживають MFA та системами керування обліковими записами за цим посиланням.
Практичні заходи запобігання
Чи можуть користувачі розпізнавати такі атаки?
Це перше питання, з якого варто починати. Обидві атаки починаються із соціальної інженерії: фішингового листа або фальшивого дзвінка від ІТ-підтримки. Технічні засоби контролю не зупиняють користувача, який справді вважає, що допомагає ІТ-відділу скинути пароль облікового запису. Фішингові симуляції, які охоплюють сценарії з приманками на основі коду пристрою, навчають співробітників зупинятися перед вставленням коду на будь-якому сайті, незалежно від того, наскільки легітимним він виглядає.
Чи достатньо MFA?
Для таких атак – ні. Стандартне MFA на основі push-сповіщень проходить успішно в межах схеми викрадення токенів Kali365, а Storm-2949 обманом змушує користувачів самостійно підтверджувати запити. MFA, стійке до фішингу, наприклад ключі FIDO2 або ключі доступу (passkeys), усуває цю прогалину. Воно прив’язане до домену й не може бути повторно використане зловмисником, який отримав перехоплений токен.
Чи є SSPR ризиком у середовищі організації?
Так, якщо облікові записи можуть ініціювати скидання без попередньо зареєстрованого методу MFA. Щоб заблокувати початковий вектор Storm-2949, потрібно вимагати наявності вже зареєстрованого MFA перед запуском SSPR.
Чи правильно обмежені дозволи Azure?
Масштаб впливу Storm-2949 (від одного облікового запису до Key Vault, SQL, Storage та віртуальних машин) був безпосередньо зумовлений надмірними дозволами ролей RBAC. Потрібно перевірити користувацькі призначення ролей Azure RBAC, застосувати принцип найменших привілеїв і обмежити операції з високим рівнем ризику, зокрема отримання профілю публікації, розгортання розширень віртуальних машин і Run Command, лише тими обліковими записами, яким вони справді потрібні.
Чи відстежуються правильні сигнали?
Реєстрація нового пристрою MFA одразу після скидання пароля є індикатором компрометації з високим рівнем достовірності. Масове завантаження файлів із кількох облікових записів OneDrive протягом короткого проміжку часу – ще один такий сигнал. Кореляція подій SSPR, аномалій автентифікації та доступу до хмарних ресурсів в одному поданні дає змогу виявляти такі кампанії до їх поширення. Моніторинг загроз надає командам безпеки таку міждоменну видимість.
Чи заблоковано потік коду пристрою?
Якщо ні, його потрібно заблокувати. Необхідно створити політику Conditional Access, яка блокує коди автентифікації пристроїв для всіх користувачів, із чітко обмеженими винятками лише для процесів, яким це справді потрібно. Це найбільш прямий спосіб зниження ризику атак у стилі Kali365.
Перевірте, наскільки ваша команда стійка до соціальної інженерії
Обидві атаки, описані в цій статті, починалися однаково: користувач ухвалював рішення, якого від нього очікував зловмисник. Найліпший спосіб знизити цей ризик – перевірити й навчити ваших користувачів до того, як їх випробує реальна загроза. Щоб отримати демо рішення Arsen для навчання користувачів протидії фішингу, вішингу та смішингу залиште свої контактні дані у формі нижче.
