Открытый каталог на сервере атакующего раскрыл три фишинговые кампании против Microsoft 365

Французская компания 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, получая сессионные куки после того, как пользователь сам проходит MFA. Одна из обнаруженных модификаций (исследователи называют её «red-queen») содержала ряд технических усовершенствований: переименование HTML-атрибутов crossorigin и integrity для обхода проверок Subresource Integrity, движок перезаписи URL в http_proxy.go для обхода детектирования по путям, а также предзаполнение адреса электронной почты жертвы для снижения процента отказов.

Особенно примечательна установка TTL перехваченных сессионных куки Microsoft в 31 536 000 секунд (один год). По оценке Lexfo, это означает, что перехваченная сессия может пережить даже сброс пароля и оставаться активной месяцами — при отсутствии политики Continuous Access Evaluation (CAE). В репозитории был обнаружен перехваченный куки 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.