Как три подозреваемые российские группы используют обычные функции входа для захвата аккаунтов

Такой подход способен обойти привычное представление о защите с помощью многофакторной аутентификации. Пользователь может не сообщать основной пароль — вместо этого он одобряет приложение OAuth, создает пароль приложения или подтверждает подключение устройства. Для злоумышленника это легитимно выглядящий путь к аккаунту.

Что известно о трех кластерах

UNC6293: подмена чиновников, пароли приложений и OAuth

По данным GTIG, UNC6293 выдавал себя за сотрудников Государственного департамента США и других доверенных лиц. Жертв убеждали создать и передать пароли приложений — отдельные учетные данные, которые могут предоставить доступ к аккаунту в обход обычного запроса второго фактора. Кластер также использовал фишинг с согласием OAuth, добиваясь авторизованных токенов, а не просто кражи пароля.

С умеренной степенью уверенности GTIG оценивает UNC6293 как кластер первоначального доступа, связанный с ICE RELIC — названием Google для группы, ранее известной как APT29.

UNC7005, также известный как STORM-2945: WhatsApp и многоэтапные приманки

UNC7005 применял несколько меняющихся сценариев:

• Мошенническая привязка устройств WhatsApp. Жертву убеждали подключить к аккаунту устройство, контролируемое атакующими.
• Поддельные голосовые звонки и приглашения в зашифрованные чаты. Такие контакты помогали установить доверие перед отправкой вредоносной ссылки или кода.
• Подмена сообщений от организаций. В частности, использовались приманки с упоминанием Финского операционного центра, а также поддельные страницы входа Microsoft.
• OAuth и доставка вредоносного ПО. Через Google OAuth злоумышленники добивались токенов или доступа к аккаунтам, параллельно используя стилеры VIDAR и ATOMIC для кражи данных.

UNC7005 отслеживается отдельно от UNC6293: при сходных целях и интересе к легитимным механизмам авторизации у кластеров различаются инфраструктура и набор приемов.

UNC5976: OAuth-фишинг против оборонных целей

По оценке GTIG, UNC5976 сосредоточился на военнослужащих, сотрудниках аэрокосмической отрасли и других представителях оборонного сектора, включая людей и организации, связанные с Украиной и Арменией. Фишинговые атаки были направлены на получение OAuth-разрешений для доступа к аккаунтам или данным жертв.

Что Google говорит о российском следе

GTIG с высокой степенью уверенности оценивает всю описанную активность как связанную с Россией. Это именно аналитическая оценка атрибуции: она не означает, что каждая деталь операций или взаимосвязь между кластерами доказана с одинаковой уверенностью.

В доступных публикациях также описываются возможные связи части активности с ICE RELIC/APT29. При этом связь UNC6293 с ICE RELIC оценена GTIG лишь с умеренной степенью уверенности, а сами кластеры продолжают отслеживаться раздельно из-за различий в тактике и инфраструктуре.

Почему одной многофакторной аутентификации недостаточно

Многофакторная аутентификация не гарантирует защиту, если пользователя удается заставить подтвердить неправильное действие. Неожиданное окно согласия OAuth, просьба создать пароль приложения или код для привязки WhatsApp могут быть частью захвата аккаунта — даже если основной пароль никто не крадет.

Поэтому запросы авторизации стоит воспринимать как операции, требующие проверки, а не как автоматически безопасные шаги только потому, что они появляются внутри знакомого сервиса.

Как снизить риск

Рекомендации GTIG сводятся к тому, чтобы не позволять злоумышленнику ускорять процесс:

• Проверяйте полный адрес сайта в браузере перед входом и выдачей разрешений OAuth.
• Подтверждайте приглашения и запросы по независимому каналу. Перезвоните по известному номеру или свяжитесь с отправителем другим способом, если речь идет о конференции, голосовом звонке, зашифрованном чате или сообщении от госорганизации.
• Никому не передавайте пароли приложений, одноразовые коды, QR-коды и коды привязки устройств. Не подтверждайте неожиданные входы и запросы OAuth.
• Регулярно проверяйте список подключенных устройств в WhatsApp и других мессенджерах и удаляйте незнакомые.
• Используйте устойчивую к фишингу MFA. Организациям стоит отдавать приоритет аппаратным ключам безопасности и passkeys, а также по возможности ограничивать рискованные OAuth-приложения и пароли приложений.

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