Когда недостаточно проверить URL: атака Device Code Phishing через ресурс Microsoft

Одна из наиболее распространенных рекомендаций по защите от фишинга — проверять доменное имя сайта, который запрашивает учетные данные. Как правило, нелегитимный домен можно распознать невооруженным взглядом: он будет отличаться от официального хотя бы несколькими символами. Однако недавно мы столкнулись со схемой, где злоумышленник предлагает жертве вводить данные на легитимном ресурсе известной компании. Речь о «Платформе удостоверений Microsoft» (Microsoft Identity Platform), в которой поддерживается спецификация протокола OAuth 2.0 под названием Device Authorization Grant.

Эта спецификация разрабатывалась для удобства пользователей умных телевизоров, IoT-девайсов, принтеров и других устройств с ограниченным вводом, без полноценного браузера или клавиатуры. Она позволяет авторизовать такое устройство для доступа к ресурсам пользователя через смартфон или ПК. Для этого пользователю нужно ввести одноразовый код на специальной странице авторизации. Этот код вместе со ссылкой, где нужно его ввести, выдает 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, предлагая пройти авторизацию на другом устройстве. К примеру, Smart TV показывает код и ссылку, чтобы их ввели на смартфоне, при этом ссылка 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, что указывает на использование метода Device Authorization Grant. Этот параметр указывает серверу авторизации, какой метод используется для получения токенов доступа. Сервер ждет, пока пользователь введет user_code на другом устройстве и подтвердит доступ к своим ресурсам/данным. Пока пользователь не подтвердил это, сервер возвращает authorization_pending (ждите) или slow_down (слишком часто спрашиваете).

5. Получение токенов доступа

После того как пользователь подтвердил доступ приложению, сервер возвращает приложению access_token (ключ доступа к данным), refresh_token (ключ для обновления доступа) и id_token (токен с информацией о пользователе: имя, email и другие данные) и ряд других служебных параметров.

6. Автоматическое обновление доступа

Устройство, в данном случае наш умный телевизор, использует refresh_token для обновления access_token без повторной авторизации пользователя. Когда срок текущего access_token истекает (как правило, через 1 час), устройство отправляет запрос с параметром refresh_token на конечную точку /token и получает новые access_token и refresh_token, чтобы пользователю не пришлось заново проходить аутентификацию.

Эта схема действительно удобна для устройств, у которых отсутствует или ограничена форма ввода. Однако злоумышленники могут злоупотребить ею и получить доступ к учетной записи пользователя, а также поддерживать такой доступ долгое время, используя refresh_token. Разберем этот вектор атаки на примере.

Анализ атаки Device Code Phishing

Фишинговое письмо

В фишинговой кампании, которую мы наблюдали с начала апреля по середину мая 2026 года, письмо было стилизовано под уведомление от юридической фирмы. К письму был приложен PDF-файл, защищенный паролем.

После открытия PDF-файла и ввода пароля пользователь видел страницу со списком документов, но для их просмотра нужно было перейти по ссылке.

PDF-файл с вредоносной ссылкой

Если обратить внимание на ссылку, по которой предлагалось перейти, то вместо привычного фишингового ресурса мы увидим легальный адрес Microsoft. Но в параметры ссылки включена переадресация на фишинговый ресурс.

Ссылка в документе ведет не на сайт Microsoft, а переадресовывает на фишинговый ресурс

Ссылка перенаправляла пользователя на фишинговую страницу, мимикрирующую под юридический портал.

Фишинговая страница

Интересно, что на такой странице было несколько капчей, — видимо, чтобы отсекать краулеры. После их прохождения пользователь попадал еще на одну страницу, на которой предлагалось скопировать одноразовый код. Этот код — user_code, который приложение на сервере/стороне злоумышленников получило путем запроса на https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, как мы описывали ранее.

Одноразовый код

Когда пользователь нажимал на отображаемый одноразовый код, тот копировался в буфер обмена, а сам пользователь перенаправлялся на подлинную страницу авторизации Microsoft (verification_uri), где и предлагалось ввести полученный код.

Официальная страница Microsoft

Если пользователь вводил код, начинался процесс Device Authorization Grant, который мы расписывали выше. Ничего не подозревающая жертва проходила полную MFA-авторизацию на официальной странице Microsoft. После завершения этого процесса злоумышленник получал доступ к access_token, refresh_token и id_token, что позволяло ему, например, читать и отсылать письма с почтового ящика жертвы, а также получить доступ к файлам OneDrive и сообщениям в Teams.

Адаптация метода атаки

Описанная фишинговая рассылка была не очень массовой и длилась чуть больше месяца. Однако сам метод злоумышленники используют до сих пор, адаптируя под конкретные регионы. Мы зафиксировали немного модифицированные атаки класса Device Code Phishing, нацеленные, например, на бразильских пользователей.

Фишинг по-бразильски

В этом письме не было вложенного PDF-файла. Вместо этого в нем была ссылка на легитимный ресурс cacoo.com (платформа компании Nulab для создания диаграмм), которая, как и в ранее описанной схеме, перенаправляла пользователя на фишинговый сайт.

Прокси-ссылка ведет на легитимный ресурс Cacoo.com с переадресацией на фишинговый сайт

При переходе по ссылке пользователь попадал на знакомую страницу с одноразовым кодом.

Страница с кодом

А дальше потенциальную жертву вновь ждала официальная страница Microsoft и процесс авторизации при помощи Device Authorization Grant.

Страница Microsoft для ввода кода

Как защититься от атаки Device Code Phishing

Как показывает наше исследование, для доступа к конфиденциальным данным злоумышленники не всегда полагаются на кражу логинов и паролей с помощью вредоносного ПО — они могут злоупотреблять и легитимными инструментами. Поэтому пользователям необходимо проявлять бдительность не только в отношении подозрительных ресурсов и веб-сайтов, но и на официальных ресурсах, таких как страницы Microsoft или Cacoo.com.

Рекомендации для пользователей:

• • Если вы не инициировали вход на устройство с помощью Microsoft Device Authorization Grant, не подтверждайте авторизацию.
  • Никогда не вводите коды авторизации, полученные в неожиданных письмах или сообщениях, даже если ссылка ведет на официальный сайт Microsoft.
  • Злоумышленники используют ссылки на легитимные домены, добавляя в параметры URL-переадресации (redirect_uri, return_url, next после знака «?») адрес вредоносного ресурса. Прежде чем перейти по ссылке, наведите на нее курсор и проверьте не только основной домен, но и подозрительные параметры переадресации, а после перехода убедитесь, что конечный URL соответствует ожидаемому ресурсу — это обязательный минимум перед вводом учетных данных.

Организациям рекомендуем оценить необходимость применения Device Code Flow в корпоративной среде. Этот сценарий лучше отключить через политики Conditional Access в Microsoft Entra ID, если он не используется бизнесом. Также следует настроить мониторинг событий DeviceCodeSignIn, статуса соответствия устройств (device compliance) и аномалий входа из необычных локаций.

Дополнительную защиту от атак Device Code Phishing помогут обеспечить надежные решения для электронной почты, гарантирующие безопасность корпоративной и личной переписки.