Фишинговые атаки через OAuth: как злоумышленники крадут доступ под видом конференций

По данным Хабра, исследователи Volexity фиксируют целевые фишинговые кампании против пользователей Microsoft и Google: злоумышленники маскируют их под регистрацию и коммуникацию вокруг реальных европейских мероприятий по безопасности. Критическая точка атаки — не вредоносное вложение, а OAuth и Device Code: пользователь сам подтверждает доступ к своей учётной записи. Для почтовой инфраструктуры это означает одно: шлюз может не увидеть привычного вредоносного payload, потому что основной перехват происходит уже в браузере и мессенджере.

Легенда начинается с нормальной переписки

Наблюдаемая Volexity активность связана с субъектом UTA0355, которого исследователи относят к российским субъектам угроз. В кампаниях использовались отдельные сайты, имитирующие реальные международные мероприятия по безопасности в Европе.

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

В одном из расследованных случаев пользователь Microsoft 365 получил письмо в уже существующем диалоге о Belgrade Security Conference. Учётная запись отправителя была скомпрометирована. Далее жертву выводили на OAuth-аутентификацию и требовали передать сгенерированный Microsoft код из адресной строки браузера.

Проверяйте не только From и SPF/DKIM. Валидный отправитель не означает валидную цель авторизации. Скомпрометированный ящик проходит базовые проверки доставки штатно.

Device Code не должен уходить в чат

Отдельный индикатор кампании — «поддержка» через WhatsApp или Signal. По данным Volexity, злоумышленники сопровождали цели в реальном времени и добивались отправки URL либо кода, необходимого для завершения OAuth-фишинга. В описанном случае атакующий действовал от имени двух лиц, связанных с конференцией; обе учётные записи были скомпрометированы.

Для пользователя правило должно быть жёстким: не передавайте коды Device Code, URL из адресной строки и данные авторизации третьим лицам. Неважно, представляется ли собеседник организатором мероприятия, коллегой или технической поддержкой. Внешний контакт не участвует в штатной процедуре входа Microsoft или Google.

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

Контрольная последовательность для M365 и Google

Не сводите реакцию к блокировке одного домена. Домены и легенды меняются, а механизм атаки остаётся прежним.

Порядок действий:

• запретите передачу Device Code и URL авторизации через почту и мессенджеры внутренним регламентом;
• проверьте OAuth-согласия пользователей, особенно недавно выданные внешним приложениям;
• отзовите подозрительные токены и удалите несанкционированные разрешения;
• сопоставьте события входа с перепиской по тематике мероприятий;
• предупредите сотрудников: продолжение существующего треда не является доказательством легитимности запроса;
• изолируйте скомпрометированные почтовые ящики партнёров в правилах обработки, но не полагайтесь только на репутацию отправителя.

Главная ошибка — анализировать такое письмо как обычный phishing URL. Здесь объект защиты — цепочка доверия: почтовый диалог, внешний мессенджер, страница мероприятия и OAuth-подтверждение. Контролируйте каждый переход.