вы в клирнете. перечисленные здесь адреса открываются только внутри сети tor - скачайте tor-браузер здесь »
AlphaBay.Market
RU
последняя проверка: 12 мин назад отслеживается .onion: 260
главная / новости / безопасность
28 октября 2026 безопасность 1 мин чтения

Фишинг с кодом устройства: подтверждение входа, который вы не начинали

В феврале 2025 года Microsoft Threat Intelligence Center задокументировал активную кампанию актора, отслеживаемого как Storm-2372, которая похищала сессии входа у организаций в Европе, Северной Америке, Африке и на Ближнем Востоке. Показательно в этой технике — фишинге с кодом устройства — то, чего она избегает: здесь нет поддельной страницы входа, которую можно распознать, нет пароля, который можно украсть, и нет вредоносного файла, который можно обнаружить. Жертва вообще не вводит никаких секретов. Код, предоставленный злоумышленником, вводится на настоящей странице входа Microsoft, жертва подтверждает запрос на своём же устройстве — и злоумышленник уходит с работающей сессией.

Легитимная функция, вывернутая наизнанку

Device code flow — это настоящая функция OAuth 2.0, а не подделка. Она существует для устройств без полноценной клавиатуры или браузера: принтеры, телевизоры, экраны переговорных, приставки. Устройство показывает короткий код, пользователь открывает портал входа на телефоне или ноутбуке, вводит код, авторизуется и подтверждает. Устройство получает свои токены. Storm-2372 развернул эту последовательность наоборот. По данным Microsoft, с августа 2024 года группа вела кампанию так: открывала чаты в Microsoft Teams от имени руководителей или чиновников, затем под предлогом обмена документами переводила разговор в Signal или WhatsApp. Приглашения на встречи, разосланные по почте, несли ту же наживку, замаскированную под обычный трафик Teams. Материал BleepingComputer об этой же кампании описывал жертв, которых просили «аутентифицировать» устройство, чтобы получить важный документ: они переходили по ссылке на настоящую страницу входа Microsoft, вводили присланный код и подтверждали вход — вместе с обычным шагом многофакторной аутентификации. Среди задокументированных Microsoft целей — госорганы, ИТ-провайдеры, оборонный сектор, телеком, здравоохранение, высшее образование и энергетические компании.

Почему это полностью обходит MFA

Всё решает порядок действий. Злоумышленник сначала сам инициирует легитимный запрос кода устройства и лишь потом подключает жертву. Когда жертва вводит код и подтверждает, все проверки на странице входа проходят честно: страница настоящая, код действителен, а человек за ней действительно завершает вход, включая положенную многофакторную аутентификацию. Токены, которые выдаёт Microsoft, включая долгоживущие refresh-токены, достаются тому, кто начал запрос, — то есть злоумышленнику. С точки зрения каталога пользователь просто успешно вошёл в систему. Почтовым фильтрам и веб-прокси нечего помечать, потому что вся задействованная инфраструктура совершенно легитимна. В отчёте Microsoft описано, что происходило дальше в скомпрометированных тенантах: злоумышленники искали по почтовым ящикам через Graph API запросы со словами вроде credentials, passwords и admin, выкачивали переписку и использовали доверенные внутренние аккаунты для фишинга коллег — одно подтверждение могло каскадом пройти по всей организации. В обновлении, опубликованном через день после исходного материала, Microsoft также задокументировала переход к запросам через клиент Microsoft Authentication Broker: это позволяло регистрировать контролируемые злоумышленником устройства и запрашивать primary refresh tokens. Proofpoint, наблюдавшая за техникой по мере её распространения через фишинговые наборы в 2026 году, отметила дальнейшее усовершенствование: коды генерируются по запросу в момент, когда жертва кликает по ссылке, что обходит пятнадцатиминутный срок действия заранее созданного кода.
Привычный совет — внимательно рассматривать страницу входа, прежде чем что-то вводить, — здесь не работает. Как отмечает Proofpoint в разборе более поздних кампаний, проверка URL бессмысленна, потому что портал действительно принадлежит Microsoft; злоупотребляется подтверждение жертвы, а не адресная строка.

Красные флаги, о которых стоит знать

Приметы устойчивы от кампании к кампании, и ни одна из них не требует технических знаний, чтобы их заметить.
  • вход, который вы не начинали: код устройства существует только потому, что его кто-то запросил
  • спешка и давление — «действуйте, пока код не истёк» или «до начала встречи»
  • письмо, чат или сообщение с просьбой подтвердить что-то кодом, который вы не запрашивали
  • контакт, перескакивающий между платформами: чат в Teams переезжает в Signal или WhatsApp
  • документ или приглашение на встречу, которые «разблокируются» только после ввода кода
Microsoft также отмечает, что современные интерфейсы входа Azure перед завершением device code flow просят подтвердить, в какое именно приложение вы входите. Прочитать этот экран подтверждения, а не кликнуть на автомате — часто именно здесь иллюзия ломается: приложение на той стороне — не ваше.

Что действительно ограничивает атаку

Для администраторов самый сильный контроль — узкий: разрешать device code flow только там, где есть реальная операционная потребность. В Microsoft Entra ID это политика условного доступа с условием Authentication Flows, блокирующая аутентификацию по коду устройства; Proofpoint рекомендует сначала включать её в режиме report-only, чтобы измерить влияние до принудительного применения, а там, где поток нельзя отключить полностью, — использовать белый список одобренных пользователей, платформ или именованных расположений. Руководство CISA по многофакторной аутентификации настоятельно призывает к фишингоустойчивым методам вроде ключей FIDO и пассключей, которые привязывают учётные данные к самому происходящему входу, а не к чему-то, что удалённый злоумышленник может погасить. Руководство британского NCSC по фишингу формулирует более широкую мысль: многоуровневые технические меры, культура сообщений без поиска виноватых и перепроверка необычных запросов по второму каналу дают больше, чем одно лишь обучение бдительности. Тот, кто уже ввёл код и подтвердил запрос, должен считать аккаунт скомпрометированным и действовать на уровне сессии, а не пароля: когда администратор отзывает сессии аккаунта, украденные refresh-токены теряют силу — именно этот шаг восстановления документирует Microsoft. После этого стоит проверить правила почтового ящика, выданные согласия и исходящую почту: токены могли уже использоваться для фишинга коллег. Эта схема из той же семьи, что и мошенничество с поддельными агентами поддержки, о котором мы писали раньше: злоумышленник не побеждает технологию — он на мгновение занимает авторитет самого пользователя. Вход, который никто не просил вас начинать, — именно его стоит отклонить.

ещё заметки

все новости ›

MFA fatigue и push bombing: когда окно подтверждения становится атакой

Действующий пароль позволяет заспамить телефон запросами на подтверждение, пока кто-то не нажмёт «одобрить». Как работает MFA fatigue, что показали инциденты Uber и Cisco и почему number matching и аппаратные ключи меняют исход.

Угон сессии: почему украденный cookie ценнее украденного пароля

AiTM-фреймворки для фишинга и логи инфостилеров всё чаще торгуют аутентифицированными сессиями, а не паролями: украденный session cookie уже за стеной MFA. Разбор того, как работает угон сессии и какие защиты реально держат удар.