Широко известная рекомендация по защите от фишинга предполагает проверку доменного имени веб-сайта, который требует введения учетных данных. Обычно подделанный домен легко заметить невооруженным глазом благодаря небольшим отличиям от оригинального адреса. Однако недавно обнаружена схема мошенничества, при которой киберпреступники предлагают пользователям вводить личные данные непосредственно на подлинном ресурсе известной компании. Речь идет о «Платформе удостоверений Microsoft» (Microsoft Identity Platform), которая поддерживает OAuth 2.0 спецификацию с названием Device Authorization Grant.
Данная спецификация была разработана для удобства работы с умными телевизорами, интернет-устройствами, принтерами и прочими гаджетами, имеющими ограниченные возможности ввода и отсутствие полноценного веб-браузера или клавиатуры. Она обеспечивает возможность авторизации такого устройства для использования ресурсов пользователя через смартфон или персональный компьютер. Для осуществления этого пользователю требуется ввести временный код на специальной странице входа. Этот код и адрес веб-страницы для его ввода передает платформа Microsoft Identity Platform в ответ на запрос к https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode. По этой причине нападение, которое злоупотребляет этим механизмом, называется Device Code Phishing.
В данной статье подробно описывается принцип функционирования спецификации Device Authorization Grant (также именуемой Device Authorization Grant Flow или Device Code Flow), проводится исследование действительных примеров кибератак, применяющих эту технологию, и предлагаются способы защиты от Device Code Phishing.
Этапы реализации Device Authorization Grant
1. Получение кода авторизации
Когда пользователь запускает приложение на устройстве-клиенте (например, видеосервис на умном телевизоре), оно обнаруживает отсутствие активной сессии и направляет POST-запрос на адрес https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, включая параметры client_id (уникальный идентификатор приложения, зарегистрированного в Microsoft Entra ID (ранее Azure AD)) и scope (набор требуемых прав доступа). В качестве ответа приложение получает параметры: device_code (конфиденциальный код для внутреннего пользования), user_code (простой код, видимый пользователю), verification_uri (адрес для входа), expires_in (период действия кода) и interval (интервал проверки статуса).
2. Демонстрация кода пользователю
Устройство отображает пользователю user_code и verification_uri, предлагая осуществить вход с использованием другого гаджета. Например, телевизор выводит код и ссылку, чтобы пользователь ввел их на своем мобильном устройстве. При этом verification_uri может быть представлена в виде QR-кода.
3. Ввод кода и одобрение доступа
Используя встроенную камеру смартфона (если это QR-код) или же введя адрес вручную, пользователь переходит на verification_uri (например, https://microsoft.com/devicelogin) и вводит user_code.
4. Периодический опрос сервера
Устройство (умный телевизор) начинает регулярно опрашивать сервер для проверки статуса авторизации (получил ли пользователь доступ), отправляя POST-запрос на эндпоинт https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. Запрос содержит параметр grant_type со значением urn:ietf:params:oauth:grant-type:device_code, который сообщает серверу авторизации о применяемом способе получения токенов. Сервер ожидает, пока пользователь вводит user_code и одобряет доступ приложению к своим ресурсам. До подтверждения пользователем сервер возвращает authorization_pending (продолжайте ожидание) либо slow_down (запросите реже).
5. Получение токенов доступа
После того как пользователь разрешает приложению доступ, сервер передает приложению access_token (средство получения доступа к данным), refresh_token (средство обновления доступа) и id_token (токен содержащий информацию о пользователе: фамилию, имя, электронную почту и прочие сведения), а также дополнительные служебные значения.
6. Автоматическое восстановление доступа
Устройство, такое как наш умный телевизор, применяет refresh_token для восстановления access_token без необходимости повторного входа пользователя. Когда действие текущего access_token завершается (как правило, спустя час), устройство передает запрос с refresh_token на эндпоинт /token и получает новые access_token и refresh_token, благодаря чему пользователю не нужно повторно проходить аутентификацию.
Эта система действительно облегчает использование устройств, в которых отсутствует или существенно ограничен ввод информации. Однако киберпреступники могут использовать эту функцию неправомерно, чтобы завладеть учетной записью пользователя и сохранять доступ на длительный период благодаря refresh_token. Проанализируем этот способ атаки на конкретном примере.
Исследование атаки Device Code Phishing
В проведенной нами фишинговой кампании, активной с начала апреля до середины мая 2026 года, письмо было оформлено в виде уведомления от律师事務所. К письму был присоединен PDF-документ, защищенный паролем.
После распаковки PDF-файла и введения пароля пользователю демонстрировалась страница со списком бумаг, однако просмотр требовал перехода по ссылке.
Если внимательно посмотреть на предложенную ссылку, то вместо типичного поддельного домена видно подлинный адрес Microsoft. Однако в параметрах URL присутствует переадресация на фишинговый ресурс.
Ссылка переводила пользователя на мошенническую страницу, стилизованную под портал юридической конторы.
Примечательно, что на этой странице находилось несколько проверок безопасности, видимо, чтобы блокировать автоматизированные боты. После их преодоления пользователь попадал на дополнительную страницу, предлагающую скопировать временный код. Этот код — это user_code, который приложение, работающее со стороны киберпреступников, получило посредством запроса к https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, как было описано выше.
Когда пользователь нажимал на отображаемый временный код, он переносился в буфер обмена, и сам пользователь перенаправлялся на реальную страницу входа Microsoft (verification_uri), где требовалось ввести полученный код.
После введения кода инициировался процесс Device Authorization Grant, описанный ранее. Ничего не подозревающий пользователь полностью проходил многофакторную аутентификацию на реальной странице Microsoft. По завершении этого процесса киберпреступник получал access_token, refresh_token и id_token, что позволяло ему, например, читать и отправлять письма с почтового ящика пострадавшего, получать доступ к файлам OneDrive и переписке в Teams.
Трансформация методики атаки
Описанная фишинговая кампания не отличалась массовым охватом и функционировала около месяца. Тем не менее сам способ киберпреступники применяют по сей день, адаптируя его под конкретные страны и регионы. Нами обнаружены немного модифицированные примеры Device Code Phishing, направленные, в частности, на жителей Бразилии.
В этом письме не было приложенного PDF-файла. Вместо этого оно содержало ссылку на подлинный портал cacoo.com (сервис компании Nulab для построения графических диаграмм), который, как в предыдущем варианте, перенаправлял пользователя на поддельный веб-сайт.
При клике по ссылке пользователь оказывался на хорошо знакомой странице с временным кодом.
Далее потенциальную жертву снова ожидала реальная страница Microsoft и процесс входа при помощи Device Authorization Grant.
Методы защиты от Device Code Phishing
Как демонстрирует проведенное исследование, для получения доступа к конфиденциальной информации киберпреступники не всегда полагаются на кражу идентификатора и кодового слова с помощью вредоноса — они могут использовать в неправомерных целях и подлинные инструменты. Таким образом, люди должны оставаться осторожными не только при обращении с сомнительными площадками и веб-сайтами, но и при взаимодействии с подлинными ресурсами, включая страницы Microsoft или Cacoo.com.
Советы для всех пользователей:
- Если вы не инициировали вход в устройство посредством Microsoft Device Authorization Grant, не одобряйте попытку входа.
- Не вводите коды входа, полученные в неожиданных писем или чатах, даже когда ссылка указывает на реальный портал Microsoft.
- Киберпреступники применяют ссылки на подлинные адреса, при этом вставляя в параметры URL-адреса переадресации (
redirect_uri,return_url, next после символа «?») ссылку на опасный ресурс. До перехода по ссылке не поленитесь посмотреть предпросмотр и исследовать не только базовый домен, но и возможные опасные параметры переадресации. После перехода удостоверьтесь, что конечный адрес совпадает с ожидаемым ресурсом — это необходимый минимум перед вводом личных данных.
Для компаний рекомендуется проанализировать целесообразность применения Device Code Flow в корпоративной инфраструктуре. При отсутствии необходимости в данной функции ее следует выключить через политики Conditional Access в Microsoft Entra ID. Также требуется организовать отслеживание событий DeviceCodeSignIn, статусов проверки устройств (device compliance) и аномальных входов с неизвестных территорий.
Дополнительную защищённость от атак Device Code Phishing способны обеспечить надежные системы защиты электронной почты, гарантирующие безопасность деловой и личной корреспонденции.
