За полгода фишинг через код устройства (device code phishing) прошёл путь от нишевого приёма команд red team до массовой угрозы: в Push Security отслеживают более 25 отдельных наборов, тогда как прежде появление одного нового набора для AiTM-фишинга случалось раз в несколько месяцев. Атака не трогает форму входа и бьёт по слою авторизации, поэтому ключи доступа и аппаратные ключи безопасности от неё не защищают. В Barracuda за четыре недели насчитали более 7 миллионов таких атак, а в Microsoft с фиксируют по 10–15 новых кампаний в сутки. ФБР выпустило отдельное предупреждение о наборе Kali365.
Почему ключи доступа не защищают от подмены кода устройства
Атака нацелена не на форму входа, а на то, что происходит после неё – на выдачу приложению разрешений. Как правило, к моменту встречи с фишинговой страницей жертва уже авторизована в учётной записи Microsoft. Дальше нужно скопировать короткий код, ввести его на настоящей странице входа для устройств, выбрать свою учётную запись из списка и нажать кнопку подтверждения. Этим атака и исчерпывается.
Ни ключи доступа, ни ключи безопасности, ни принудительно включённая устойчивая к фишингу многофакторная проверка подлинности разницы не делают: поток кода устройства отделён от механизма аутентификации. Работает атака потому, что подтверждение личности и выдача приложению доступа к данным – две разные операции, а средства защиты в большинстве случаев прикрывают только первую.
Поток кода устройства – предусмотренный стандартом OAuth 2.0 (RFC 8628) способ входа для устройств с ограниченными возможностями ввода: телевизоров, принтеров, оборудования интернета вещей. Пользователь вводит короткий код на другом устройстве с браузером, после чего первое устройство получает токены доступа и обновления. На практике механизм чаще всего применяется при входе из командной строки, а не в тех сценариях, ради которых его задумывали.
Как EvilTokens и Kali365 поставили атаку на поток
Технику описали ещё в 2020 году, но до 2024-го дальше исследовательских публикаций дело не шло. Первыми в реальных атаках её применили проправительственные группировки, в том числе Storm-2372. В 2025 году группировка ShinyHunters начала массово использовать её против организаций, работающих с Salesforce, а в феврале 2026-го появился набор EvilTokens, после чего криминальное применение резко пошло вверх.
Сегодня это штатная функция платформ, торгующих фишингом как услугой (PhaaS). Операторы Tycoon2FA, который в Push считали самым распространённым набором для AiTM-фишинга, добавили технику в свой инструментарий: кампанию зафиксировали в конце апреля 2026 года, разбор опубликовали в мае. В Kali365 обе техники собраны на одной платформе.
Часть компаний трактует структурное сходство наборов как признак дробления экосистемы. В Push с этим не согласны: наборы, написанные независимо друг от друга по близким запросам к языковым моделям, выглядят настолько же похоже.
Возможности при этом растут. В ARToken платным операторам предлагают как товарные характеристики сразу несколько механизмов:
- закрепление через первичный маркер обновления (PRT);
- доступ к почтовым ящикам;
- автоматизацию схем с компрометацией деловой переписки (BEC);
- выгрузку данных из SharePoint.
Первичный маркер обновления (PRT) – артефакт проверки подлинности Microsoft Entra, который выдаётся брокерам токенов на зарегистрированном устройстве и обеспечивает единый вход в приложения. Зарегистрировав в чужой организации собственное устройство, атакующий получает PRT и удерживает доступ к учётной записи долгое время.
Сценарий коммерциализации повторяет историю AiTM-фишинга: сначала исследовательская диковинка, затем инструмент шпионажа, затем рядовой товар, причём каждый переход быстрее предыдущего. Для фишинга через код устройства весь путь уложился в месяцы, и сказались тут два обстоятельства – зрелость рынка PhaaS и скорость, с которой разработка при помощи ИИ позволяет собирать и распространять новые возможности.
Как ИИ ускорил выпуск новых наборов
Более 25 разных наборов в обороте – величина, немыслимая до этого года. Для сравнения: раньше появление нового набора для AiTM-фишинга считалось заметным событием и происходило раз в несколько месяцев. То, что за один год возникло свыше 25 семейств, говорит об изменении самого способа сборки фишинговых инструментов.
Порог входа снизила разработка при помощи ИИ. Многие наборы, за которыми следят в Push, схожи по вёрстке страниц и архитектуре кода, потому что сгенерированы языковыми моделями по близким запросам. Чтобы показать, насколько это просто, в компании собрали собственный набор и продемонстрировали его работу.
За пределами Microsoft: GitHub, AWS и Salesforce
На Microsoft приходится 99% фишинга через код устройства, который фиксируют в Push. Долго так не продлится: предоставление доступа устройству – часть общего стандарта OAuth 2.0, и мишенью может стать любое приложение, где эта схема реализована.
Проправительственные группировки уже применяли технику против Salesforce в точечных кампаниях. В кампании ShinyHunters против клиентов этой платформы использовалось вредоносное приложение, замаскированное под Data Loader; в Push связывают с ней более 1000 пострадавших организаций и 1,5 миллиарда похищенных записей, но обе величины восходят к заявлениям самих злоумышленников и независимого подтверждения не получили. При этом в Salesforce поток кода устройства отключили ещё в 2025 году: с заблокированы авторизации через стандартное подключённое приложение Salesforce CLI, а поддержку убрали из Data Loader.
Универсальность у техники ниже, чем у AiTM: предоставление доступа устройству реализовано не везде. Зато она обходит любую многофакторную проверку подлинности, не требует копирования страницы входа, а пользователь всё время взаимодействует с настоящими адресами поставщика услуги.
Поток кода устройства поддерживают GitHub, AWS и другие сервисы, причём в GitHub он лежит в основе авторизации инструментов командной строки и туннелей VS Code. По мере того как авторы наборов начнут выходить за пределы Microsoft, откроются именно эти цели.
AiTM-фишинг (adversary-in-the-middle, «злоумышленник посередине») – схема, при которой поддельная страница входа работает как прокси между жертвой и настоящим сервисом, перехватывая и учётные данные, и сеансовые файлы cookie. Перехваченного сеанса достаточно, чтобы обойти многофакторную проверку подлинности.
ConsentFix и общий сдвиг к атакам на авторизацию
Фишинг через код устройства не стоит особняком. Атакующие уходят со слоя аутентификации, потому что именно там сосредоточены средства защиты, тогда как механизмам авторизации внимания доставалось несравнимо меньше.
В конце 2025 года в Push обнаружили ConsentFix – браузерную технику фишинга согласия OAuth, которую сперва связали с российскими группировками, а затем нашли и в криминальных наборах. Как и фишинг через код устройства, ConsentFix бьёт по слою авторизации и по той же структурной причине сводит на нет ключи доступа: всё происходит уже после успешной аутентификации.
Пока атакующие придумывают новые способы злоупотребления согласиями, регистрацией устройств и обменом токенов, разрыв между нападением и защитой будет расти – если только защищающаяся сторона не перестроится.
Почему условный доступ закрывает не всё
Фишинговую страницу доставляют любым каналом: почтой, мессенджерами, через соцсети, поисковую выдачу, взломанные сайты. Код при этом вводится на настоящем адресе входа поставщика услуги, то есть трафик идёт через инфраструктуру, которую не заблокируют ни сетевой прокси, ни репутационные сервисы для URL, ни почтовый шлюз.
Стандартный совет для инфраструктуры Microsoft – ограничить поток кода устройства политиками условного доступа. Там, где это выполнимо, шаг разумный, но выполнимо не всегда: поток кода устройства существует не просто так, и в крупных организациях его отключение ломает инструменты разработчиков, работу через командную строку и сценарии с устройствами без полноценного ввода.
Даже выставленное ограничение ничего не даёт против атак на GitHub, AWS и другие платформы, где равноценных механизмов условного доступа может попросту не быть.
Единственная точка, откуда видно и приманку, и подтверждение кода устройства, причём у любого поставщика услуги, – браузер; на этом строит защиту сама Push. Правила там пишут под класс техники: поведенческие признаки наборов и сам процесс подтверждения кода, а не отпечатки конкретных наборов и не домены. Разница существенна, когда наборы появляются еженедельно и меняют инфраструктуру быстрее, чем её успевает отследить любой подход на основе индикаторов компрометации.
Заключение
Изменилось не количество атак, а расстановка сил: защита на уровне входа перестала решать задачу. Ключ доступа подтверждает личность, но никак не влияет на выдачу разрешений чужому приложению, и обойти его теперь можно поточным инструментом, купленным по подписке.
Администраторам Microsoft 365 имеет смысл сначала выяснить, кто в организации вообще пользуется потоком кода устройства, а затем ограничить его политикой условного доступа для всех остальных. Для GitHub, AWS и прочих сервисов равноценного рычага нет, поэтому там остаются разбор журналов входа и понятное правило для сотрудников: короткий код, пришедший вместе с письмом или ссылкой, вводить нельзя, каким бы убедительным ни выглядел повод.