Кража токенов OAuth (multilogin и consent-фишинг)

Когда большинство пользователей слышат "аккаунт Google скомпрометирован", они привычно меняют пароль, сбрасывают активные сессии и считают инцидент исчерпанным. Эта ментальная модель перестала работать ещё в конце 2023 года. Два класса атак, массово внедрённых в коммерческие вредоносы и фишинговые наборы к 2024-2025 годам, полностью обходят смену пароля. Они упоминаются в треде the_smart_ape "don't sign in with google".

1. Multilogin и повторное использование refresh-токенов

В конце 2023 года исследователи обнаружили недокументированный эндпоинт Google OAuth под названием multilogin. Получив валидный refresh-токен, он генерирует свежие сессионные cookie - в том числе те, которые пользователь считал аннулированными после сброса пароля. В течение нескольких месяцев эту технику взяли на вооружение более десяти семейств вредоносного ПО: её содержат Lumma, Rhadamanthys и ряд других массовых инфостилеров.

Схема атаки:

1. Инфостилер попадает на машину жертвы обычными путями (взломанный софт, вредоносный npm-пакет, компрометация цепочки поставок расширений для браузера и т. д.).
2. Он извлекает refresh-токены Google из локального хранилища Chrome.
3. Токены отправляются атакующему.
4. Даже после того как жертва сменила пароль Google и вышла со всех устройств, атакующий отправляет украденный refresh-токен на multilogin и получает свежие валидные сессионные cookie. Доступ сохраняется.

Единственный способ защиты - вручную отозвать каждую активную сессию и каждое выданное сторонним приложениям разрешение OAuth на странице безопасности Google (myaccount.google.com/security -> "Ваши устройства" и "Сторонние приложения с доступом к аккаунту"). Сам по себе сброс пароля по умолчанию не аннулирует ранее выпущенные refresh-токены. Большинство пользователей об этой разнице не подозревает.

Это современное проявление проблемы долгоживущих ключей: refresh-токены представляют собой долгосрочные учетные данные, жизненный цикл которых отвязан от пароля. Сброс пароля создаёт иллюзию защиты, но проблемы не решает.

2. Consent-фишинг

Более глубокий обход защиты. При consent-фишинге атакующий не пытается аутентифицироваться от лица жертвы - он просит жертву авторизовать его приложение.

Атакующий регистрирует OAuth-приложение в Google с правдоподобным именем вроде "Mail Backup Pro" или "Drive Sync Helper". Переходя по фишинговой ссылке, жертва попадает на настоящий экран подтверждения доступа Google: подлинный домен accounts.google.com, валидный TLS-сертификат, а вход в собственный аккаунт уже выполнен. На экране написано: "Приложение Mail Backup Pro запрашивает доступ к чтению вашей почты". Пользователь, привыкший, что фишинг - это поддельные страницы входа, видит настоящий интерфейс Google и нажимает "Разрешить".

В итоге атакующий получает подписанный Google токен OAuth с запрошенными правами - gmail.readonly, drive.full или любыми другими - сроком действия на несколько месяцев. Пароль не запрашивался. 2FA не срабатывала. Пользователю вообще не предлагали пройти аутентификацию. Его попросили выдать авторизацию. Это принципиально другой механизм.

Почему стандартные средства защиты здесь бессильны:

• Менеджер паролей - не реагирует, так как пользователь уже авторизован.
• 2FA и аппаратные ключи - не запрашиваются, поскольку нового входа в систему не происходит.
• Проверка TLS и домена - настоящий домен Google и валидный сертификат пройдут любые проверки.
• Устойчивая к фишингу 2FA (FIDO2) - не помогает, так как атака направлена не на этап аутентификации.

Единственная защита здесь снова сводится к разделу myaccount.google.com/connections: регулярно проверять список приложений с доступом и отзывать неизвестные или неиспользуемые разрешения. Мало кто из пользователей когда-либо открывал эту страницу.

Данные по индустрии

В треде приводятся три факта (первоисточники не указаны, перед цитированием стоит перепроверить):

• 31% инцидентов с компрометацией Microsoft 365 в 2025 году пришлись на кражу токенов.
• Март 2025: атакующие адаптировали фишинг через device-code (давно известный по M365) под экосистему Google.
• Август 2025: в результате утечки данных Salesloft / Drift токены OAuth для интеграций с Salesforce и Google Workspace были скомпрометированы в промышленных масштабах.

Эти цифры подтверждают общую тенденцию: кража токенов вытеснила фишинг учётных данных и стала основным вектором компрометации в экосистемах, завязанных на внешних провайдеров идентификации.

Почему это важно в контексте рисков SSO

Оба класса атак обусловлены архитектурой самого OAuth, а не особенностями реализации у Google. Apple, Microsoft, Okta, Auth0 - любой сервис, выпускающий refresh-токены, сталкивается с аналогом проблемы multilogin, если механизм отзыва токенов не привязан к смене пароля. И у любого сервиса с экраном согласия существует риск consent-фишинга.

Однако масштаб ущерба от компрометации напрямую зависит от того, сколько сервисов завязано на одну учётную запись. Токен gmail.readonly, полученный через consent-фишинг, открывает доступ к переписке за многие годы и становится универсальным ключом ко всем письмам со ссылками для сброса паролей. А перехваченная через multilogin сессия Google даёт доступ ко всем внешним SaaS-сервисам с кнопкой "Войти с помощью Google" - что, как описано в sso-concentration-risk, часто покрывает всю рабочую инфраструктуру.

Рекомендации по защите здесь совпадают с общими мерами против концентрации рисков в SSO: не завязывать критически важные для бизнеса и финансов сервисы на одного провайдера идентификации и регулярно проводить аудит выданных разрешений на странице myaccount.google.com/connections.

См. также

• smart-ape-dont-sign-in-with-google - исходный тред.
• sso-concentration-risk - общая концепция концентрации рисков единого входа.
• google-oauth-domain-takeover - другой вектор (перехват идентификатора через покупку домена), но схожий общий паттерн.
• long-lived-keys - базовая проблема жизненного цикла долгоживущих ключей.
• supply-chain-security - векторы проникновения инфостилеров на целевые устройства.