Фишинг давно вышел за рамки кражи паролей. Один из самых показательных примеров — злоупотребление OAuth.
OAuth 2.0 — стандартный протокол делегированной авторизации, на котором сегодня держится экосистема Microsoft 365, Google Workspace и множества SaaS‑сервисов. Он позволяет приложениям получать доступ к ресурсам пользователя без хранения пароля, через выдачу access‑token и refresh‑token с определённым набором разрешений (scopes).
С точки зрения архитектуры это удобно и безопасно. С точки зрения атакующего — это идеальная точка обхода классических мер защиты.
В OAuth‑фишинге злоумышленник не пытается перехватить учётные данные. Его цель — заставить пользователя легитимно выдать токен доступа вредоносному или подконтрольному приложению. Для этого используются социально‑инженерные сценарии, максимально приближённые к рабочим процессам: доступ к документу, приглашение в Teams, подключение внешнего сервиса, служебное уведомление.
Ключевой момент: пользователь проходит аутентификацию на реальной странице Microsoft, с корректным доменом и срабатывающей MFA. С точки зрения журналов входа — это валидная авторизация. Нарушение происходит на уровне согласия (consent), а не аутентификации.
Отдельного внимания заслуживает Device Code Flow. Изначально он предназначен для устройств без браузера и клавиатуры, но в реальных атаках используется как универсальный способ обхода пользовательской настороженности. Пользователь получает код и инструкцию ввести его на официальной странице входа. Фактически он сам завершает OAuth‑процесс и авторизует приложение атакующего.
После выдачи токена злоумышленник получает устойчивый доступ к данным пользователя в рамках выданных разрешений. В Microsoft 365 это, как правило, почта, файлы, календарь, Teams и Microsoft Graph API. При этом:
— смена пароля не отзывает OAuth‑токены;
— MFA не пересматривается;
— активность выглядит как обычная работа пользователя;
— токены могут жить неделями и обновляться через refresh‑token.
Для SOC и ИБ‑подразделений такие инциденты особенно сложны в обнаружении. Нет аномального входа, нет подмены IP, нет подозрительного user‑agent. Часто единственный индикатор — появление нового OAuth‑приложения с избыточными разрешениями или нетипичное использование Graph API.
Важно подчеркнуть: это не уязвимость протокола как такового. OAuth делает ровно то, что должен — доверяет явному согласию пользователя. Проблема возникает на уровне governance и контроля: кто может регистрировать приложения, какие scopes разрешены, как устроен процесс согласия и как мониторятся выданные токены.
С практической точки зрения снижение риска начинается с инвентаризации OAuth‑приложений и регулярного аудита разрешений. Критично понимать, какие приложения имеют доступ к чувствительным данным, кто их зарегистрировал и используются ли они в бизнес‑процессах. Отдельно стоит рассматривать ограничение или дополнительный контроль Device Code Flow и пользовательского consent.
Не менее важен человеческий фактор. Пользователь не обязан понимать устройство OAuth, но он должен чётко различать: аутентификацию и выдачу доступа. Если сотрудник сам не инициировал подключение сервиса, подтверждение кода или запроса разрешений должно восприниматься как инцидент, а не как рабочая рутина.
Это хороший индикатор зрелости угроз. Атакующие используют корректные, поддерживаемые вендорами механизмы, смещая фокус защиты с «взлома» на контроль процессов и контекста. Для нас это означает одно: управление идентификацией сегодня — это не только IAM и MFA, но и прозрачность OAuth‑экосистемы внутри компании.