Несколько лет подряд компаниям твердили одно и то же: включите многофакторную аутентификацию, и большинство атак на учётные записи отвалятся сами собой. Для классического фишинга с кражей пароля это правило действительно работает. Но злоумышленники подстраиваются под защиту быстрее, чем успевают выйти новые рекомендации по безопасности. Сначала появился AiTM-фишинг (Adversary-in-the-Middle) — прокси-сайт в реальном времени перехватывал сессионные куки прямо во время входа жертвы. Следующий шаг оказался куда изящнее: фишинг через device code, то есть через код авторизации устройства в протоколе OAuth 2.0. Никакого поддельного сайта создавать не нужно — жертва вводит данные на самой настоящей странице Microsoft. Единственная странность во всей схеме — короткий код, который нужно куда-то вбить, и правдоподобный повод, зачем это делать.
Механизм device code authorization придумали не для взлома, а для удобства. Он рассчитан на устройства, у которых нет нормального экрана для ввода логина и пароля — умные телевизоры, системы для переговорных комнат и подобная техника. Логика простая: устройство запрашивает у Microsoft код, показывает его пользователю, тот открывает на телефоне или ноутбуке, вводит этот код и подтверждает вход. После подтверждения токены доступа улетают обратно на то самое устройство, которое изначально запросило код. Вся система держится на одном допущении — что устройство, запросившее доступ, и человек, который его подтверждает, находятся рядом друг с другом и действуют заодно.
Именно это допущение и ломают атакующие. Сервер злоумышленника сам инициирует запрос device code у Microsoft и получает вполне легитимный, но короткоживущий код. Дальше этот код нужно как-то передать жертве под правдоподобным предлогом — например, «посмотрите общий документ» или «подтвердите свою учётную запись». Жертва заходит на настоящую страницу входа Microsoft, вводит присланный код, авторизуется, проходит проверку MFA. Поскольку она только что подтвердила запрос, который на самом деле создал атакующий, токены доступа Microsoft отправляет не жертве, а на сервер злоумышленника. Дальше в ход идут уже эти токены: с их помощью регистрируют новые устройства, входят в Microsoft 365 Outlook и создают почтовые правила для скрытности и закрепления в системе.
Один из зафиксированных случаев начинался вовсе не с письма, а с переписки. Атакующий представился партнёром юридической фирмы, несколько сообщений вёл вполне дружелюбно и только потом отправил ссылку. Сама ссылка была замаскирована в несколько слоёв: видимый текст показывал знакомый корпоративный адрес, а реальная цель вела на страницу, размещённую на Google Sites — сервисе, которому большинство систем безопасности доверяют и редко блокируют. Жертву перенаправляли через открытый редирект на скомпрометированном легитимном сайте, при этом на экране показывался один адрес-приманка, а настоящая цель пряталась в параметре URL. Финальная страница была защищена фальшивой проверкой «я не робот» в стиле CAPTCHA — чтобы автоматические сканеры безопасности её пропустили.
Посадочная страница имитировала портал для обмена документами, показывала код верификации и вела жертву через настоящий процесс входа Microsoft. Всё, что случилось дальше, уложилось буквально в несколько часов. Атакующий вошёл в систему из-за границы, зарегистрировал под скомпрометированной учётной записью сразу несколько устройств, создал скрытое правило в почтовом ящике, которое прятало ответы и уведомления о недоставке, а затем разослал новую волну фишинговых писем сотням внешних получателей уже от имени взломанного аккаунта. Отдельно стоит отметить: конечное устройство жертвы вообще не пострадало — вся атака происходила в облаке, поэтому обнаружить её только средствами защиты endpoint-устройств было практически невозможно.
Для выявления подобных атак стоит следить за несколькими сигналами на уровне идентификации. Во-первых, сами входы через device code — в большинстве организаций это редкое и легко объяснимое событие, так что любое его использование заслуживает проверки. Во-вторых, активность Microsoft Authentication Broker с необычной географией, незнакомых сетей или неуправляемых устройств. В-третьих, всплеск регистрации новых устройств за короткий промежуток времени или с незнакомых IP-адресов. В-четвёртых, изменения почтовых правил — новые правила, которые прячут, помечают как прочитанное или удаляют письма, классический признак зачистки следов после захвата аккаунта. В-пятых, нетипичные или физически невозможные перемещения — вход из региона, не характерного для обычного поведения пользователя, особенно в сочетании с перечисленными выше событиями.
Защита строится в несколько слоёв. Начинается всё с осведомлённости людей: сотрудников стоит учить воспринимать неожиданный запрос на ввод кода как тревожный сигнал, а не как рутинную процедуру, и дать им простой способ сообщить о подозрительном письме. Дальше — там, где flow device code не нужен по работе, его стоит заблокировать через политику условного доступа (Conditional Access), оставив узкие исключения только для реально нужных случаев. Также полезно ограничить и мониторить регистрацию устройств: сузить права на регистрацию, требовать управляемые и соответствующие политикам устройства для доступа к почте и данным, снизить лимит регистраций на одного пользователя. Наконец, стоит ужесточить контроль идентификации: включить политики именованных локаций, задействовать непрерывную оценку доступа (Continuous Access Evaluation), включить защиту токенов и настроить автоматический отзыв сессий при росте риска.
Device code phishing — это эксплуатация не программной уязвимости, а стыков между легитимными функциями. Легальный процесс авторизации плюс доверенная страница входа плюс правдоподобная социальная инженерия дают в сумме обход MFA без единой строчки вредоносного кода. При этом атака вполне предотвратима: достаточно заблокировать ненужный flow device code, двигаться в сторону фишинг-устойчивой многофакторной аутентификации и приучить пользователей не доверять неожиданным кодам.
Для клиентов Trend Vision One предусмотрен ряд конкретных инструментов детектирования. Web Reputation Services распознаёт фишинговые URL как опасные, а страницу для сбора учётных данных помечает под именем детектирования — блокировка таких адресов не даёт жертве вообще добраться до окна ввода кода, служа резервным барьером после осведомлённости пользователей. Threat Intelligence Hub даёт аналитику по новым угрозам и группировкам, включая эксклюзивные отчёты Trend Research и ленту Threat Intelligence Feed. Через приложение XDR Data Explorer можно искать индикаторы вредоносной активности следующими запросами:
Атаку такого типа можно разложить по матрице MITRE ATT&CK: разработка ресурсов через приобретение или компрометацию инфраструктуры (T1583/T1584) для редиректоров и хостинга; первоначальный доступ через фишинг со ссылкой (T1566.002); получение учётных данных через генерацию запроса многофакторной аутентификации с использованием device code (T1621) и через кражу токена доступа приложения (T1528); закрепление и латеральное перемещение через использование альтернативного материала аутентификации в виде токена приложения (T1550.001); персистентность через манипуляцию с учётной записью в виде регистрации устройства (T1098.005) и модификации процесса аутентификации через MFA (T1098/T1556.006); сбор данных через захват почты и правила её скрытия (T1114/T1564.008); а также уклонение от защиты через имперсонацию (T1656).
Список индикаторов компрометации включает домены отправителей и имперсонации rlcounsel[.]com и cholaw-kr[.]co; страницы-приманки на доверенном хостинге [.]com/view/businessprofileoverview, /corporateprofiledetails и /profileportfoliodetailsdata; скомпрометированные открытые редиректоры eusei[.]com/dir/redirects.php, cineuropa[.]org/nll.aspx и zrdesignlabo[.]com/st-manager/click/track; фишинговые эндпоинты up88qope1z[.]hlpadditives[.]com, zr6dgshpvf[.]flosli[.]com и profileupdate-collaboration[.]stefan-dufva[.]workers[.]dev; а также IP-адреса атакующих 104.219.238[.]253, 43.165.1[.]42, 40.124.130[.]50, 18.118.111[.]82 и 83.136.210[.]246. Стоит учитывать, что часть этих ресурсов — легитимные общие сервисы, которыми злоумышленники просто злоупотребили, поэтому перед блокировкой каждый индикатор нужно проверять в контексте собственной инфраструктуры.
Механизм device code authorization придумали не для взлома, а для удобства. Он рассчитан на устройства, у которых нет нормального экрана для ввода логина и пароля — умные телевизоры, системы для переговорных комнат и подобная техника. Логика простая: устройство запрашивает у Microsoft код, показывает его пользователю, тот открывает на телефоне или ноутбуке, вводит этот код и подтверждает вход. После подтверждения токены доступа улетают обратно на то самое устройство, которое изначально запросило код. Вся система держится на одном допущении — что устройство, запросившее доступ, и человек, который его подтверждает, находятся рядом друг с другом и действуют заодно.
Именно это допущение и ломают атакующие. Сервер злоумышленника сам инициирует запрос device code у Microsoft и получает вполне легитимный, но короткоживущий код. Дальше этот код нужно как-то передать жертве под правдоподобным предлогом — например, «посмотрите общий документ» или «подтвердите свою учётную запись». Жертва заходит на настоящую страницу входа Microsoft, вводит присланный код, авторизуется, проходит проверку MFA. Поскольку она только что подтвердила запрос, который на самом деле создал атакующий, токены доступа Microsoft отправляет не жертве, а на сервер злоумышленника. Дальше в ход идут уже эти токены: с их помощью регистрируют новые устройства, входят в Microsoft 365 Outlook и создают почтовые правила для скрытности и закрепления в системе.
Один из зафиксированных случаев начинался вовсе не с письма, а с переписки. Атакующий представился партнёром юридической фирмы, несколько сообщений вёл вполне дружелюбно и только потом отправил ссылку. Сама ссылка была замаскирована в несколько слоёв: видимый текст показывал знакомый корпоративный адрес, а реальная цель вела на страницу, размещённую на Google Sites — сервисе, которому большинство систем безопасности доверяют и редко блокируют. Жертву перенаправляли через открытый редирект на скомпрометированном легитимном сайте, при этом на экране показывался один адрес-приманка, а настоящая цель пряталась в параметре URL. Финальная страница была защищена фальшивой проверкой «я не робот» в стиле CAPTCHA — чтобы автоматические сканеры безопасности её пропустили.
Посадочная страница имитировала портал для обмена документами, показывала код верификации и вела жертву через настоящий процесс входа Microsoft. Всё, что случилось дальше, уложилось буквально в несколько часов. Атакующий вошёл в систему из-за границы, зарегистрировал под скомпрометированной учётной записью сразу несколько устройств, создал скрытое правило в почтовом ящике, которое прятало ответы и уведомления о недоставке, а затем разослал новую волну фишинговых писем сотням внешних получателей уже от имени взломанного аккаунта. Отдельно стоит отметить: конечное устройство жертвы вообще не пострадало — вся атака происходила в облаке, поэтому обнаружить её только средствами защиты endpoint-устройств было практически невозможно.
Для выявления подобных атак стоит следить за несколькими сигналами на уровне идентификации. Во-первых, сами входы через device code — в большинстве организаций это редкое и легко объяснимое событие, так что любое его использование заслуживает проверки. Во-вторых, активность Microsoft Authentication Broker с необычной географией, незнакомых сетей или неуправляемых устройств. В-третьих, всплеск регистрации новых устройств за короткий промежуток времени или с незнакомых IP-адресов. В-четвёртых, изменения почтовых правил — новые правила, которые прячут, помечают как прочитанное или удаляют письма, классический признак зачистки следов после захвата аккаунта. В-пятых, нетипичные или физически невозможные перемещения — вход из региона, не характерного для обычного поведения пользователя, особенно в сочетании с перечисленными выше событиями.
Защита строится в несколько слоёв. Начинается всё с осведомлённости людей: сотрудников стоит учить воспринимать неожиданный запрос на ввод кода как тревожный сигнал, а не как рутинную процедуру, и дать им простой способ сообщить о подозрительном письме. Дальше — там, где flow device code не нужен по работе, его стоит заблокировать через политику условного доступа (Conditional Access), оставив узкие исключения только для реально нужных случаев. Также полезно ограничить и мониторить регистрацию устройств: сузить права на регистрацию, требовать управляемые и соответствующие политикам устройства для доступа к почте и данным, снизить лимит регистраций на одного пользователя. Наконец, стоит ужесточить контроль идентификации: включить политики именованных локаций, задействовать непрерывную оценку доступа (Continuous Access Evaluation), включить защиту токенов и настроить автоматический отзыв сессий при росте риска.
Device code phishing — это эксплуатация не программной уязвимости, а стыков между легитимными функциями. Легальный процесс авторизации плюс доверенная страница входа плюс правдоподобная социальная инженерия дают в сумме обход MFA без единой строчки вредоносного кода. При этом атака вполне предотвратима: достаточно заблокировать ненужный flow device code, двигаться в сторону фишинг-устойчивой многофакторной аутентификации и приучить пользователей не доверять неожиданным кодам.
Для клиентов Trend Vision One предусмотрен ряд конкретных инструментов детектирования. Web Reputation Services распознаёт фишинговые URL как опасные, а страницу для сбора учётных данных помечает под именем детектирования — блокировка таких адресов не даёт жертве вообще добраться до окна ввода кода, служа резервным барьером после осведомлённости пользователей. Threat Intelligence Hub даёт аналитику по новым угрозам и группировкам, включая эксклюзивные отчёты Trend Research и ленту Threat Intelligence Feed. Через приложение XDR Data Explorer можно искать индикаторы вредоносной активности следующими запросами:
- []Успешные авторизации через device code (событие редкое и легко объяснимое): pname: "Microsoft Entra ID" AND authenticationProtocol: deviceCode AND eventName: IDENTITY_IAM_SIGN_INS AND status: 0
[]Недавно зарегистрированные устройства: pname: "Microsoft Entra ID" AND eventName: IDENTITY_AAD_DIR_AUDIT AND eventCategory: Device AND actionName: Add device AND initiatedByAppDisplayName: Device Registration Service AND result: success (стоит учитывать, что легитимной активности здесь ожидается много, запрос нужно уточнять методом original transfer method)
[]Токен device code, использованный для входа в Device Registration Service: pname: "Microsoft Entra ID" AND eventName: IDENTITY_IAM_SIGN_INS AND status: 0 AND rawDataStr: "\"OriginalTransferMethod":"deviceCodeFlow"" AND targetResourceDisplayName: "Device Registration Service"
Атаку такого типа можно разложить по матрице MITRE ATT&CK: разработка ресурсов через приобретение или компрометацию инфраструктуры (T1583/T1584) для редиректоров и хостинга; первоначальный доступ через фишинг со ссылкой (T1566.002); получение учётных данных через генерацию запроса многофакторной аутентификации с использованием device code (T1621) и через кражу токена доступа приложения (T1528); закрепление и латеральное перемещение через использование альтернативного материала аутентификации в виде токена приложения (T1550.001); персистентность через манипуляцию с учётной записью в виде регистрации устройства (T1098.005) и модификации процесса аутентификации через MFA (T1098/T1556.006); сбор данных через захват почты и правила её скрытия (T1114/T1564.008); а также уклонение от защиты через имперсонацию (T1656).
Список индикаторов компрометации включает домены отправителей и имперсонации rlcounsel[.]com и cholaw-kr[.]co; страницы-приманки на доверенном хостинге [.]com/view/businessprofileoverview, /corporateprofiledetails и /profileportfoliodetailsdata; скомпрометированные открытые редиректоры eusei[.]com/dir/redirects.php, cineuropa[.]org/nll.aspx и zrdesignlabo[.]com/st-manager/click/track; фишинговые эндпоинты up88qope1z[.]hlpadditives[.]com, zr6dgshpvf[.]flosli[.]com и profileupdate-collaboration[.]stefan-dufva[.]workers[.]dev; а также IP-адреса атакующих 104.219.238[.]253, 43.165.1[.]42, 40.124.130[.]50, 18.118.111[.]82 и 83.136.210[.]246. Стоит учитывать, что часть этих ресурсов — легитимные общие сервисы, которыми злоумышленники просто злоупотребили, поэтому перед блокировкой каждый индикатор нужно проверять в контексте собственной инфраструктуры.
