Крадіжка токенів Microsoft 365: чому одного MFA недостатньо

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

Що таке token spraying

Token spraying у Microsoft 365 — це назва методу, який постачальник безпекових рішень Huntress спостерігав у межах однієї кампанії. Зловмисники не підбирають паролі. Вони крадуть сесійні токени після того, як працівник коректно увійшов за допомогою пароля та багатофакторної автентифікації (MFA), і невдовзі відтворюють ці токени зі своєї інфраструктури. Назва нагадує password spraying, коли один пароль пробують проти багатьох облікових записів. Тут викрадені облікові дані широко розсіюються й використовуються повторно.

Відомості про кампанію походять від Huntress і зі звіту The Hacker News. Вони ґрунтуються на спостереженнях серед клієнтів одного постачальника безпекових рішень і нічого не говорять про всі тенанти.

Крадіжка токенів Microsoft 365: що спостерігав Huntress

Huntress описує кампанію у звіті Token Replay and Spray. Точна дата публікації звіту невідома; задокументовано період спостереження з 14.07.2026 по 22.09.2026. Протягом цього часу Huntress бачив атаки на 79 організацій, понад 200 000 невдалих спроб входу та 497 успішних входів. У каталогах Entra створили щонайменше 48 підроблених пристроїв. У 19 організаціях наявні методи MFA було видалено й замінено новим.

Наскільки відомо, цифру в 97 скомпрометованих облікових записів наводить лише The Hacker News. У звіті Huntress її підтвердити не вдалося, тому тут вона подається як дані цього видання. Кількості для окремих хвиль атак у викладі Huntress також дещо розходяться. Для оцінки достатньо порядку величин: 79 уражених організацій, 497 успішних входів і кілька хвиль атак протягом приблизно десяти тижнів — це не поодинокий випадок, а серія.

Чим token spraying відрізняється від password spraying

Password spraying створює багато невдалих спроб, бо більшість паролів хибні. У token spraying облікові дані дійсні. За даними Huntress, невдалі спроби в кампанії надходили з мереж зловмисників, значна частина — від хостинг-провайдера в Німеччині. Це нічого не говорить про інших клієнтів цього провайдера. Блокування окремих адрес також мало допомагає, бо зловмисники змінювали адреси хвилями, а між хвилями була тиша в один-два тижні.

Як повторне відтворення токенів підриває MFA

Цей метод називають також token replay, тобто повторне відтворення викраденого токена. Процес можна описати чотирма кроками.

1. Принада: працівник отримує фішинговий лист або через соціальну інженерію потрапляє на стороній сайт. Як такі листи здобувають довіру, описано в статті про автентичність електронних повідомлень.
2. Перехоплення: ретранслятор adversary-in-the-middle (AiTM) стоїть між працівником і справжньою сторінкою входу Microsoft. Пароль і запит MFA проходять через ретранслятор, який потім зберігає токен. У device code phishing жертву натомість змушують ввести код на справжній сторінці Microsoft, за допомогою якого зловмисник отримує токен.
3. Повторне відтворення (replay): через кілька хвилин або приблизно за годину зловмисник використовує токен зі своїх серверів. Ні пароль, ні другий запит MFA не потрібні.
4. Закріплення: зловмисник реєструє власний застосунок-автентифікатор, видаляє наявні методи MFA або створює підроблений пристрій. І те, й інше переживає зміну пароля.

Ключовий момент такий: MFA не зламали. Працівник виконав її правильно. Викрадають результат — токен. Тому MFA тут можна обійти лише тоді, коли токен працює й поза пристроєм працівника. Коди, SMS і push-підтвердження допомагають проти підбору паролів, але не проти такого виду крадіжки.

Huntress виявив дві родини інструментів. Перша — скрипт, який відрекомендовується user agent «node» і запитує токени через застосунки Office та Authentication Broker. Друга відтворює сесії браузера. Входи другого типу виглядають як звичайний доступ із браузера і відповідно менш помітні.

Монокультура Microsoft: чому Microsoft 365 — найвигідніша ціль

Microsoft 365 використовують у незліченних компаніях у Німеччині та світі. З погляду зловмисників це економічний аргумент: атаку, створену один раз, можна повторити проти дуже великої кількості тенантів. Сторінки входу скрізь однакові, ідентифікатори застосунків ті самі, коди помилок також. Те, що працює в одній компанії, з невеликими змінами працює в багатьох інших.

Кампанія демонструє таке масштабування. Викрадені токени використовували автоматично й упродовж кількох хвилин, розподіливши їх між 79 організаціями. За даними Huntress, зловмисники розставляли пріоритети не за кількістю невдалих спроб, а за наявністю дійсних облікових даних. Так працює масовий бізнес, а не цілеспрямована операція проти однієї компанії.

Поширеність підсилює ризик, але не є єдиною причиною

Це не загальне засудження. Microsoft сама надає протидію: Conditional Access, Security Defaults і Token Protection. Ризик виникає, коли ці засоби не використовують або використовують лише частково. Зловмисники налаштовують автоматизацію під типові параметри, бо вони діють у більшості тенантів. Кожне відхилення, як-от вхід, прив'язаний до пристрою, або заблокований потік device code, коштує зловмисникам зусиль і позбавляє масову експлуатацію основи.

Поширення Copilot та інших сервісів за тими самими обліковими записами також збільшує вплив скомпрометованого акаунта. Критичну оцінку подано в статті Copilot під лупою. У Microsoft 365 один обліковий запис одночасно відкриває пошту, файли, календар і чат.

Шахрайство із зарплатою як мета: що відбувається після захоплення

Після захоплення зловмисники в кампанії створювали приховані правила вхідної пошти. Вони переміщували або видаляли листи з термінами, пов'язаними з платежами, такими як зарплата, внески чи премія. Цільові папки мали непомітні назви, наприклад «RSS Feeds» або «Conversation History». В одному випадку лист про зарплату було надіслано зовнішньому податковому консультанту. Відповіді позначали прочитаними й відсували вбік, щоб жертва їх не помітила.

За цим стоїть business email compromise (BEC): мета — перенаправити перекази або змусити змінити зарплатні рахунки. В іншому випадку поштову скриньку використали для розсилання спаму сотням зовнішніх одержувачів, доки Entra ID Protection не визнала обліковий запис високоризиковим.

Для малих компаній це особливо чутливо. У бухгалтерії та відділі кадрів часто працює лише кілька людей. Змінений обліковий запис помічають пізно, а нарахування зарплати нерідко виконують треті сторони. Тоді керівництво вирішує, як відкликати платежі й повідомити банк, податкового консультанта та бюро розрахунку зарплат. Це має бути в плані дій на випадок надзвичайної ситуації, а не лише в кризі.

Типові сліди: новий застосунок-автентифікатор, невідомі пристрої Entra, правила вхідної пошти

Кампанія залишає сліди в Microsoft Entra ID, системі керування користувачами за Microsoft 365, які можна перевірити без спеціальних інструментів. У таблиці нижче підсумовано найважливіші. Шаблони назв походять зі звіту Huntress і можуть змінитися.

Код помилки 53003 заслуговує на увагу. Блокування через Conditional Access зазвичай вважають успіхом політики. Але воно також показує, що хтось поза компанією має дійсні облікові дані або дійсний токен. Такий запис — привід перевірити обліковий запис. Правила вхідної пошти, створені через API, не завжди відображаються в інтерфейсі користувача. Їх видно через центр адміністрування Exchange або PowerShell.

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

Conditional Access: заблокувати потік device code і вимагати MFA для всіх типів клієнтів

Потік device code — це спосіб входу для пристроїв без клавіатури чи браузера. Зловмисники зловживають ним у device code phishing, змушуючи користувачів вводити код на іншому пристрої. У документації про блокування потоків автентифікації Microsoft радить максимально наблизитися до повного блокування і дозволяти цей потік лише у добре задокументованих винятках, як-от застарілі інструменти, які неможливо оновити.

Політику створюють у центрі адміністрування Entra: Entra ID, Conditional Access, Політики. Умова — «Потоки автентифікації» з вибором «Device code flow», елемент керування доступом — «Заблокувати доступ». Microsoft радить спершу запустити політику в режимі «Лише звіт» і лише потім увімкнути. Два аварійні облікові записи виключають, а їхній перелік слід регулярно переглядати.

Ліцензія: Conditional Access чи Security Defaults

Згідно з Microsoft Learn, Conditional Access потребує щонайменше Microsoft Entra ID P1 (передумова за документацією про рівні автентифікації). Компанії без такої ліцензії мають Security Defaults, які за даними Microsoft не потребують ліцензії. Серед перелічених там заходів захисту — реєстрація MFA для всіх користувачів, блокування застарілих протоколів і блокування потоку device code. Microsoft також зазначає, що з 01.07.2026 усі нові тенанти Entra блокують потік device code в межах Security Defaults. За даними Microsoft, Security Defaults не можна налаштовувати, лише вмикати або вимикати. Кому потрібні винятки чи точніші правила, тому потрібен Conditional Access.

MFA для всіх, без винятків для застосунків чи клієнтів

Базова політика має вимагати MFA для всіх користувачів, усіх ресурсів і всіх типів клієнтів або блокувати доступ. Саме цю вимогу висуває звіт Huntress, а прогалини часто виникають через добронамірені винятки на кшталт «лише адмінпортали» чи «лише браузер». Застарілі протоколи, як-от IMAP, POP3 та автентифікація SMTP, не підтримують MFA і їх слід блокувати.

Стійкі до фішингу методи, як-от ключі безпеки FIDO2 або Windows Hello for Business, захищають від AiTM-перехоплення значно краще, ніж коди, SMS чи push-підтвердження. Microsoft називає характерною ознакою рівня «Phishing-resistant MFA» взаємодію між методом автентифікації та поверхнею входу (рівні автентифікації). Явного твердження про AiTM ця сторінка не містить, тож така оцінка — висновок автора. Як створити базову політику з рівнем автентифікації, описано на сторінці MFA для всіх користувачів. Доцільно почати з адміністраторів.

Token Protection та його межі

Token Protection — це елемент керування сесією в Conditional Access. Він приймає лише токени входу, криптографічно прив'язані до зареєстрованого пристрою. Викрадений токен тоді не працює на іншому пристрої. За Microsoft Learn (стан сторінки на серпень 2026 року) функція загальнодоступна для нативних застосунків у Windows, iOS, iPadOS і macOS та діє для Exchange Online, SharePoint Online і Teams. У Windows додаються Windows 365 і Azure Virtual Desktop. Окремих відомостей про ліцензування сторінка не містить, тому вимогу до ліцензії потрібно з'ясувати окремо. Як функція Conditional Access, Token Protection вимагає щонайменше Entra ID P1, і це власний висновок автора, а не цитата з Microsoft.

Межі чітко окреслені. Браузерні застосунки підтримуються лише в попередньому перегляді й лише для вибраних вебзастосунків, що використовують Azure Resource Manager. Отже, Outlook в інтернеті не охоплений. Крім того, пристрої мають бути зареєстровані в Entra, приєднані або гібридно приєднані. Пристрої Apple мають бути керованими з розширенням єдиного входу. Для компаній з особистими пристроями це реальна перешкода.

Token Protection зменшує token replay, але не усуває ризик. Microsoft радить пілотну групу, режим «Лише звіт» та аналіз журналів входу перед широким запровадженням. Також допомагають сумісний пристрій як умова доступу, обмеження згоди на нові застосунки та регулярна перевірка нових корпоративних застосунків. Стійка до фішингу MFA та доступ на основі пристроїв зменшують ризик, а моніторинг виявляє те, що все ж прослизнуло.

Порядок дій у надзвичайній ситуації: відкликати сесії, очистити пристрої та методи MFA

Наведена послідовність — рекомендація автора, виведена з документації Microsoft про відкликання доступу та зі звіту Huntress. Це не офіційна вимога. Загальний порядок дій після успішної атаки описано в статті Ransomware: план дій на перші 60 хвилин, і частину його можна застосувати тут.

1. Заблокувати обліковий запис і відкликати сесії: у центрі адміністрування Entra в розділі «Користувачі» знімають позначку «Обліковий запис увімкнено» і вибирають «Відкликати сесії», або через PowerShell командою Revoke-MgUserSignInSession. Це запобігає видачі нових токенів.
2. Скинути пароль: у гібридних середовищах Microsoft радить двічі скинути пароль у локальному Active Directory. Після цього сесії відкликають знову.
3. Перевірити методи MFA: невідомі методи, особливо новий застосунок-автентифікатор, видаляють. Справжній користувач налаштовує свої методи лише після цього, бажано із зворотним підтвердженням телефоном.
4. Перевірити пристрої: невідомі зареєстровані пристрої вимикають і видаляють. Вони — ознака закріплення.
5. Очистити поштову скриньку: правила, пересилання, делегування й правила транспорту перевіряють і видаляють. Надіслані та видалені елементи переглядають на предмет підозрілого.
6. Перевірити застосунки: невідомі корпоративні застосунки та згоди застосунків видаляють.
7. З'ясувати масштаб: журнали входу, починаючи з найранішого підозрілого моменту, аналізують. Слід також розглянути інші облікові записи того ж відділу, адже кампанія часто зачіпала кілька облікових записів в одній організації.
8. Оцінити наслідки для бізнесу: чи змінювали банківські реквізити, дані про зарплату або рахунки? Банк, податкового консультанта та бюро розрахунку зарплат інформують, платежі зупиняють, запити на зміни підтверджують телефоном. Це рішення ухвалює керівництво.
9. Оцінити обов'язок повідомлення: чи потрібне повідомлення наглядовому органу, залежить від ризику. Строк — 72 години після того, як стало відомо (стаття 33 GDPR). Це не юридична консультація.

Чому відкликання не діє негайно

За даними Microsoft, токени доступу за замовчуванням дійсні одну годину. Відкликання блокує нові токени й робить недійсними токени оновлення, але вже видані токени доступу залишаються дійсними до закінчення терміну. Для застосунків з власними сесійними cookie сам застосунок має припинити доступ. Continuous Access Evaluation (CAE) скорочує цей час до кількох хвилин для Exchange Online, SharePoint Online і Teams, за даними Microsoft із затримкою до 15 хвилин. Huntress повідомляє, що токени доступу залишалися дійсними приблизно до 90 хвилин, а скидання пароля саме по собі не видаляє ні підроблені пристрої, ні методи MFA. Обидва кроки йдуть разом: натиснути «Відкликати сесії» — це початок, а не кінець.

Що адміністратори й керівники можуть перевірити цього тижня

• Чи заблоковано потік device code, чи ввімкнено Security Defaults?
• Чи вимагає політика MFA для всіх користувачів, ресурсів і типів клієнтів без винятків для застосунків?
• Чи заблоковано застарілі протоколи, як-от IMAP, POP3 та автентифікацію SMTP?
• Чи є два аварійні облікові записи, виключені з політик і захищені окремо?
• Чи переглянуто методи автентифікації, пристрої та правила вхідної пошти в бухгалтерії та відділі кадрів?
• Чи зрозуміло, хто ухвалює рішення в разі підозри і який постачальник послуг доступний поза робочим часом?

Щодо ІТ-постачальника важливі час реакції, доступ до журналів, знання політик і письмова документація винятків. Зовнішній погляд на конфігурацію може бути корисним, наприклад через перевірки безпеки. Власний вебсайт і поштовий домен також є частиною поверхні атаки. Перевірка вебсайту розглядає сайт ззовні, але не перевіряє налаштувань Entra.

Широке поширення робить Microsoft 365 типовою ціллю. Хто посилює типові налаштування, стежить за пристроями та методами й наперед обговорює порядок дій у надзвичайній ситуації, той позбавляє автоматизацію основи. Тверезо кажучи, це менше питання паніки, ніж конфігурації та рутини.