Французька компанія Lexfo виявила три активні фішингові кампанії проти Microsoft 365, скориставшись помилкою одного з операторів: той залишив на атакувальному сервері Python-вебсервер з відкритим лістингом каталогів. У кампаніях використовували два принципово різні методи обходу багатофакторної автентифікації — проксування сесій через Evilginx і зловживання легітимним потоком OAuth device code. Критично важливо, що ці два вектори потребують різних заходів захисту: ключі FIDO2 блокують перший, але безсилі проти другого. Організаціям, які використовують Microsoft 365, необхідно перевірити політики Conditional Access на предмет блокування device code flow.
Як було розкрито інфраструктуру
За даними дослідників Lexfo, наприкінці квітня 2026 року під час рутинного інтернет-сканування був виявлений сервер за адресою 185.163.204[.]7 (Будапешт), на якому працював Python-вебсервер, запущений командою python3 -m http.server 8080 — вона ж збереглася у файлі .bash_history. Відкритий лістинг каталогів містив конфігурації фішингу, логи перехоплених облікових даних, інсталятори засобів віддаленого керування (RMM), комбіновані списки паролів, архіви резервних копій і файли Telegram-сесій оператора. На тому ж хості працювали проксі Evilginx (adversary-in-the-middle) і консоль віддаленого доступу SimpleHelp.
Відштовхуючись від цієї знахідки, дослідники ідентифікували три окремі кампанії, кожна з яких використовувала власну модифікацію Evilginx, клоновану з публічних репозиторіїв на GitHub. За даними Lexfo, наймасштабніша з них діяла понад рік, а близько 94% скомпрометованих облікових записів належали до корпоративних поштових скриньок.
Два методи обходу MFA
Adversary-in-the-middle через Evilginx
Перший метод — класичне проксування: модифікований Evilginx перехоплює сесію автентифікації між жертвою та Microsoft, отримуючи сесійні cookie після того, як користувач сам проходить MFA. Одна з виявлених модифікацій (дослідники називають її «red-queen») містила низку технічних удосконалень: перейменування HTML-атрибутів crossorigin і integrity для обходу перевірок Subresource Integrity, рушій перезапису URL в http_proxy.go для обходу детектування за шляхами, а також попереднє заповнення адреси електронної пошти жертви для зниження відсотка відмов.
Особливо показовою є установка TTL перехоплених сесійних cookie Microsoft у 31 536 000 секунд (один рік). За оцінкою Lexfo, це означає, що перехоплена сесія може пережити навіть скидання пароля і залишатися активною місяцями — за відсутності політики Continuous Access Evaluation (CAE). У репозиторії був виявлений перехоплений cookie Microsoft 365 зі строком дії до 30 червня 2027 року. Там же лежав передкомпільований бінарник evilginx2.exe, який дозволяє покупцеві запустити атаку без будь-якої збірки.
Зловживання OAuth device code flow
Другий метод принципово відрізняється і становить більшу загрозу для організацій, що впровадили FIDO2 або passkeys. Третя модифікація («black-queen») взагалі не перехоплює паролі. Замість цього вона експлуатує легітимний механізм Microsoft — OAuth device code flow, призначений для пристроїв без повноцінного інтерфейсу введення.
Атака працює так: бекенд генерує справжній device code, обгортає його у фішингову сторінку, стилізовану під Microsoft Authenticator, і спрямовує жертву на справжню сторінку microsoft.com/devicelogin. Жертва вводить код, проходить реальну MFA-автентифікацію на справжньому сайті Microsoft і тим самим авторизує сесію зловмисника. Бекенд опитує кінцеву точку токенів і забирає токен у момент завершення автентифікації.
Ключовий момент: ключ FIDO2 або passkey тут не допомагають, тому що жертва проходить автентифікацію на справжній інфраструктурі Microsoft. Прив’язка до домену (origin binding), яка зупиняє Evilginx, спрацьовує коректно — адже origin справді належить Microsoft. Microsoft задокументувала цю техніку в лютому 2025 року в контексті кампанії Storm-2372, яку з помірним ступенем упевненості пов’язали з Росією. Відтоді техніка поширилася далеко за межі операцій державного рівня.
За даними Lexfo, у логах Telegram-бота цієї кампанії зафіксовано 218 скомпрометованих облікових записів із десятка країн за період із червня 2025 по липень 2026 року. В історії git-репозиторію був виявлений файл із 97 активними токенами Microsoft, прив’язаними до трьох жертв, — усі з прапорцем autoRefresh, деякі оновлювалися до 25 разів. Фреймворк автоматично підтримував сесії «живими».
Контекст: екосистема та масштаб
Усі три оператори використовували модифікації публічно доступного Evilginx, а не власні розробки. Дослідники виявили ознаки використання ШІ під час розробки допоміжного коду: в двох комітах одного з операторів зазначено співавторство моделей Claude, інший зберіг у репозиторії файл instructions.txt — дослівний запис сесії з ШІ-асистентом, що документує створення функції перезапису URL. Microsoft окремо задокументувала використання ШІ в аналогічних кампаніях із device code phishing у квітні 2026 року.
У червні 2026 року компанія SOCRadar описала екосистему «фішинг як послуга» під назвою The Quarry, яка, за їхньою оцінкою, обслуговувала близько 200 операторів. Інструменти, виявлені в цьому розслідуванні, фігурували в каналах цієї екосистеми, що вказує на зв’язки з постачальником, хоча пряме членство підтвердити неможливо.
Практичні рекомендації
Два вектори атаки потребують двох різних ліній захисту:
- Проти Evilginx (AiTM-проксування): впровадження стійкої до фішингу MFA — ключів FIDO2 або passkeys. Прив’язка автентифікації до домену робить проксування марним.
- Проти device code phishing: блокування device code flow через політику Conditional Access усюди, де цей потік не потрібен. Винятки — пристрої Teams Rooms і деякі CLI-інструменти. Перед застосуванням протестуйте політику в режимі report-only.
- Обмеження за IP і CAE: налаштуйте політики Conditional Access на основі розташування та увімкніть Continuous Access Evaluation, щоб токен, який використовується з несанкціонованої IP-адреси, проходив повторну перевірку, а не відпрацьовував увесь строк дії.
Для виявлення:
- Відстежуйте в журналах входу Entra ID видачу refresh-токенів від ідентифікатора клієнта Microsoft Office
d3590ed6-52b3-4102-aeff-aad2292ab01c, особливо якщо цей десктопний клієнт не використовується в організації. Зіставляйте з нетиповими вихідними IP-адресами. - Використовуйте поле
Original transfer methodу журналах входу: сесія, розпочата через device code flow, зберігає цю позначку під час подальших оновлень токена, навіть якщо поточний протокол автентифікації її не відображає. - На кінцевих точках шукайте агент XEOX за шляхом
C:\Program Files (x86)\XEOX\xeox-agent_x64.exeі заплановані завдання за маскою*XEOX*Agent*Watchdog*— цей RMM-інструмент використовувався для закріплення.
Індикатори компрометації з звіту: IP-адреса 185.163.204[.]7, домени picis[.]net і romnor[.]ca. Інфраструктура ротуються, тому IOC слід розглядати як засіб локалізації, а не як довгостроковий захист.
Головний висновок цього розслідування — не в конкретних операторах, а в системній проблемі: організація, повністю захищена від AiTM-фішингу за допомогою passkeys, залишається вразливою до device code phishing, якщо не заблоковано відповідний потік автентифікації. Перевірте наявність політики Conditional Access, що блокує device code flow для всіх користувачів, окрім тих, кому він об’єктивно необхідний, — це одна політика, яка закриває вектор, непідвладний навіть FIDO2.
