Платформа EvilTokens, що працює за моделлю «фішинг як послуга» (PhaaS), за даними Cloud Security Alliance, зловживає механізмом OAuth device code flow у Microsoft 365 для отримання довгоживучих токенів оновлення (refresh tokens). Жертви проходять легітимну автентифікацію з MFA на справжньому домені Microsoft, але при цьому несвідомо передають зловмиснику токен з доступом до пошти, файлів, календаря та контактів. Багатофакторна автентифікація не здатна заблокувати цю атаку, оскільки на момент видачі токена її вже пройдено. Організаціям, що використовують Microsoft 365, потрібно переглянути політики керування OAuth-згодами та токенами.
Механізм атаки: device code flow як вектор
Атака використовує штатний механізм автентифікації Microsoft — device code flow, призначений для пристроїв без повноцінного браузера. Жертва отримує повідомлення із проханням ввести короткий код на сторінці microsoft.com/devicelogin і пройти стандартну перевірку MFA. З точки зору користувача це виглядає як звичайна верифікація входу.
Однак після завершення автентифікації система видає токен оновлення не користувачеві, а оператору платформи EvilTokens. Як повідомляється в дослідницькій записці CSA, цей токен:
- Підписаний легітимним провайдером ідентифікації Microsoft
- Охоплює доступ до поштової скриньки, OneDrive, календаря та контактів
- Має строк дії, який визначається політикою тенанта, а не сесії
- Ймовірно, зберігає чинність навіть після скидання пароля користувача
Ключова проблема: зловмисник не перехоплює облікові дані й не відтворює сесію. Токен — це результат штатної роботи системи. Подія входу в журналах виглядає легітимною, оскільки автентифікація справді відбулася на справжньому домені Microsoft із реальним другим фактором.
Чому MFA не є захистом
Традиційний фішинг облікових даних вимагає повторного введення пароля, і саме на цьому етапі MFA створює бар’єр. Навіть атаки типу «противник посередині» (AiTM) залишають у журналах сесійні cookie, які SIEM-системи можуть корелювати з географією та пристроєм.
У випадку consent-фішингу через OAuth користувач сам завершує автентифікацію в легітимного провайдера. MFA спрацьовує та успішно проходить — до моменту видачі токена. Токен, який отримує зловмисник, не є результатом компрометації — це результат згоди, наданої користувачем. За даними дослідників, для анулювання такого доступу недостатньо змінити пароль: потрібен явний відгук токена або політика умовного доступу, що вимагає повторної згоди.
Нормалізація згоди як фактор ризику
Вектор атаки через OAuth consent існує вже давно, але його ефективність різко зросла через зміну поведінки користувачів. Кожен AI-агент, кожна інтеграція для підвищення продуктивності, кожне розширення браузера, що працює з SaaS-акаунтами, запитує OAuth-згоду. Обсяг легітимних запитів на згоду, з якими співробітник стикається протягом місяця, значно перевищує той, що закладався в первинні моделі загроз OAuth.
Формулювання запитуваних дозволів погіршують проблему. Область доступу «Читання вашої пошти» на практиці охоплює всі повідомлення, вкладення та спільні гілки листування. Область «Доступ до файлів, коли ви не в мережі» означає видачу довгоживучого токена, що діє без присутності користувача. Розрив між мовою згоди та реальним обсягом доступу — саме той простір, у якому працюють зловмисники.
Токсичні комбінації дозволів
Окремий OAuth-грант надає зловмиснику обмежений плацдарм в одному застосунку. Системний ризик виникає, коли кілька грантів перетинаються через одну користувацьку ідентичність. Наприклад: співробітник фінансового відділу надає AI-асистенту доступ до календаря та пошти, іншому інструменту — до корпоративного сховища, третьому — до клієнтської бази CRM. Кожна згода видана окремо, жоден власник застосунку не санкціонував сукупність. Компрометація одного з цих інструментів потенційно відкриває доступ до контрактів і клієнтських даних через ту саму ідентичність.
Цей ризик не видно в жодному окремому журналі аудиту застосунку, оскільки міст між ними існує на рівні ідентичності, поза периметром кожного застосунку. Аналітики відзначають, що сервери Model Context Protocol (MCP) формують аналогічну поверхню атаки, дозволяючи AI-агентам отримувати доступ через той самий механізм одноразової згоди.
Практичні рекомендації
Для захисту від consent-фішингу через OAuth необхідно перенести контроль з рівня автентифікації на рівень згоди:
- Обмежити реєстрацію застосунків в Entra ID: заборонити користувачам самостійно надавати згоду на доступ застосунків. Налаштувати робочий процес адміністративного затвердження для всіх OAuth-грантів, що запитують доступ до пошти, файлів і календаря.
- Налаштувати політики умовного доступу для токенів: скоротити строк життя refresh-токенів, увімкнути вимогу повторної автентифікації для чутливих ресурсів, налаштувати політики оцінки безперервного доступу (Continuous Access Evaluation).
- Провести аудит наявних OAuth-грантів: в Entra ID перевірити розділ «Корпоративні застосунки» → «Згоди та дозволи». Виявити застосунки з широкими областями доступу (Mail.Read, Files.ReadWrite.All, offline_access) та відкликати невикористовувані або підозрілі гранти.
- Вимкнути device code flow: якщо цей механізм автентифікації не потрібен для бізнес-процесів, заблокувати його через політики умовного доступу. Це усуває конкретний вектор, який використовує EvilTokens.
- Моніторити події надання згоди: налаштувати сповіщення в SIEM на події видачі OAuth-грантів, особливо для застосунків, зареєстрованих поза тенантом, і для грантів із широкими областями доступу.
- Інвентаризувати перетини грантів: виявити користувачів, чиї OAuth-згоди в сукупності створюють мости між критичними системами (пошта + сховище + CRM), та оцінити сукупний ризик.
Consent-фішинг через OAuth — це не теоретична загроза, а робочий вектор атаки, для якого вже існує комерційна інфраструктура. Найважливіша дія зараз — заборонити користувачам самостійно надавати OAuth-згоди в Microsoft 365 і провести ревізію всіх наявних грантів із широкими областями доступу. Організації, які й надалі покладаються виключно на MFA як на межу захисту ідентичності, залишають відкритим саме той шар, через який проходять сучасні атаки.
