С 14 июля по 22 сентября 2026 года Huntress наблюдала кампанию атак на Microsoft 365: злоумышленники перехватывали сеансы входа и использовали украденные токены, чтобы проникать в почтовые ящики. Под удар попали 79 организаций. Исследователи зафиксировали более 200 тысяч попыток входа, 497 успешных событий авторизации и 97 скомпрометированных аккаунтов. В каталогах Microsoft Entra обнаружили 48 посторонних устройств. Авторы разбора Huntress — Андреа Хэтчер, Сюзанна Мэтт, Мэтт Пото и Эндрю Шварц.
Атака начиналась с поддельной страницы входа, расположенной между пользователем и настоящей инфраструктурой Microsoft. Такой посредник, известный как adversary-in-the-middle (AitM), перехватывал пароль и код многофакторной аутентификации, а затем передавал их на легитимную страницу. Получив токен, подтверждающий вход, преступники воспроизводили его со своих устройств — порой всего через несколько минут.
Huntress назвала эту схему «распылением токенов»: похищенные токены массово проверяли в разных организациях, примерно так же, как при password spraying перебирают пароли. Поэтому речь шла не о простом подборе учётных данных. Более 200 тысяч неудачных попыток за период кампании исследователи связали с диапазоном IP-адресов 193.26.115[.]0/24.
Одного перехваченного сеанса злоумышленникам было мало. Получив доступ, они добавляли собственные приложения-аутентификаторы, чтобы проходить MFA при следующих входах, в том числе после истечения срока действия или отзыва украденного токена. Как минимум в 19 организациях прежние методы MFA удалили и зарегистрировали новые в течение трёх часов после первого входа. В инциденте 21 июля 2026 года приложение под названием «iPhone 13» активировали менее чем через 51 минуту после захвата сеанса.
Ещё один способ закрепиться — зарегистрировать в каталогах жертв поддельные компьютеры. Таких устройств насчитали не менее 48. В отличие от временного сеансового токена, зарегистрированное устройство могло давать более устойчивую возможность запрашивать новые токены и оставалось в каталоге, пока администратор его не удалит.
Злоумышленники меняли и работу почты. Они создавали скрытые правила с короткими или бессмысленными именами: «.», «sss», «ss», «iT», «,.», «........», «s» и «d». Правила удаляли или перенаправляли письма со словами, связанными с зарплатой, депозитами и премиями, а сообщения могли попадать в неприметные папки вроде RSS Feeds и Conversation History. В одном ящике все входящие письма автоматически помечались прочитанными и удалялись. Затем с этого аккаунта разослали спам сотням внешних адресатов, прежде чем Microsoft Entra ID Protection присвоила ему высокий уровень риска.
По данным Huntress, токены похищали не только через AitM-страницы. Среди источников были фишинг с кодом устройства и социальная инженерия во время настоящего процесса входа. Первую активность кампании заметили с румынского IP-адреса 193.26.115[.]221. VirusTotal указывает, что этот адрес используется удалённым трояном AsyncRAT; он также связан с немецким хостинг-провайдером 1337 Services GmbH. В данных GreyNoise значатся 29 IP-адресов, соответствующих этому провайдеру: 10 помечены как вредоносные, ещё 5 — как подозрительные. С ним связаны StarkRDP и rdp[.]sh, где клиенты могли арендовать виртуальные серверы.
В январе 2025 года международная операция правоохранительных органов под названием Talent закрыла домены, связанные со StarkRDP и rdp[.]sh, а также сайты Nulled, Cracked и Sellix. На момент публикации обе платформы снова работали, причём StarkRDP сменил название на exy[.]sh. Как сообщал независимый журналист по кибербезопасности Брайан Кребс, 30 января Telegram-аккаунт StarkRDP заявил, что сервис «всегда работал в рамках закона» и не причастен к предполагаемым преступлениям; там добавили, что это подтвердит судебный процесс. Представители также утверждали, что изъяли только сервер сайта и домен, не знали, кто именно это сделал и к кому обращаться, и планировали возобновить работу под другим именем.
При подозрении на компрометацию организациям следует отозвать активные сеансы и сменить пароль затронутой учётной записи, проверить устройства в Entra, методы MFA, правила почтового ящика и недавно добавленные корпоративные приложения. Рабочие процессы входа по коду устройства стоит ограничить политиками Conditional Access. Исследователи Huntress отмечают, что грамотно настроенные политики условного доступа закрывают часть пробелов, которые сама MFA не устраняет. Их рекомендация — без исключений требовать MFA или блокировать доступ для «All Users», «All Cloud Apps» и «All Client App types».
Изображение носит иллюстративный характер
Атака начиналась с поддельной страницы входа, расположенной между пользователем и настоящей инфраструктурой Microsoft. Такой посредник, известный как adversary-in-the-middle (AitM), перехватывал пароль и код многофакторной аутентификации, а затем передавал их на легитимную страницу. Получив токен, подтверждающий вход, преступники воспроизводили его со своих устройств — порой всего через несколько минут.
Huntress назвала эту схему «распылением токенов»: похищенные токены массово проверяли в разных организациях, примерно так же, как при password spraying перебирают пароли. Поэтому речь шла не о простом подборе учётных данных. Более 200 тысяч неудачных попыток за период кампании исследователи связали с диапазоном IP-адресов 193.26.115[.]0/24.
Одного перехваченного сеанса злоумышленникам было мало. Получив доступ, они добавляли собственные приложения-аутентификаторы, чтобы проходить MFA при следующих входах, в том числе после истечения срока действия или отзыва украденного токена. Как минимум в 19 организациях прежние методы MFA удалили и зарегистрировали новые в течение трёх часов после первого входа. В инциденте 21 июля 2026 года приложение под названием «iPhone 13» активировали менее чем через 51 минуту после захвата сеанса.
Ещё один способ закрепиться — зарегистрировать в каталогах жертв поддельные компьютеры. Таких устройств насчитали не менее 48. В отличие от временного сеансового токена, зарегистрированное устройство могло давать более устойчивую возможность запрашивать новые токены и оставалось в каталоге, пока администратор его не удалит.
Злоумышленники меняли и работу почты. Они создавали скрытые правила с короткими или бессмысленными именами: «.», «sss», «ss», «iT», «,.», «........», «s» и «d». Правила удаляли или перенаправляли письма со словами, связанными с зарплатой, депозитами и премиями, а сообщения могли попадать в неприметные папки вроде RSS Feeds и Conversation History. В одном ящике все входящие письма автоматически помечались прочитанными и удалялись. Затем с этого аккаунта разослали спам сотням внешних адресатов, прежде чем Microsoft Entra ID Protection присвоила ему высокий уровень риска.
По данным Huntress, токены похищали не только через AitM-страницы. Среди источников были фишинг с кодом устройства и социальная инженерия во время настоящего процесса входа. Первую активность кампании заметили с румынского IP-адреса 193.26.115[.]221. VirusTotal указывает, что этот адрес используется удалённым трояном AsyncRAT; он также связан с немецким хостинг-провайдером 1337 Services GmbH. В данных GreyNoise значатся 29 IP-адресов, соответствующих этому провайдеру: 10 помечены как вредоносные, ещё 5 — как подозрительные. С ним связаны StarkRDP и rdp[.]sh, где клиенты могли арендовать виртуальные серверы.
В январе 2025 года международная операция правоохранительных органов под названием Talent закрыла домены, связанные со StarkRDP и rdp[.]sh, а также сайты Nulled, Cracked и Sellix. На момент публикации обе платформы снова работали, причём StarkRDP сменил название на exy[.]sh. Как сообщал независимый журналист по кибербезопасности Брайан Кребс, 30 января Telegram-аккаунт StarkRDP заявил, что сервис «всегда работал в рамках закона» и не причастен к предполагаемым преступлениям; там добавили, что это подтвердит судебный процесс. Представители также утверждали, что изъяли только сервер сайта и домен, не знали, кто именно это сделал и к кому обращаться, и планировали возобновить работу под другим именем.
При подозрении на компрометацию организациям следует отозвать активные сеансы и сменить пароль затронутой учётной записи, проверить устройства в Entra, методы MFA, правила почтового ящика и недавно добавленные корпоративные приложения. Рабочие процессы входа по коду устройства стоит ограничить политиками Conditional Access. Исследователи Huntress отмечают, что грамотно настроенные политики условного доступа закрывают часть пробелов, которые сама MFA не устраняет. Их рекомендация — без исключений требовать MFA или блокировать доступ для «All Users», «All Cloud Apps» и «All Client App types».
