5 шокирующих фактов о фишинговой атаке OAuth, которые вы не знали

Вступление

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

Тени в сети спят,
Только клик – и вор открывает
Тихий путь к свету.

Пересказ Reddit‑поста своими словами

На Reddit обсуждалась недавняя фишинговая кампания, использующая цепочку переадресаций OAuth. Пользователи получали письма с ссылкой, которая «прокручивает» их через десятки поддельных страниц входа, имитируя настоящие сервисы Microsoft. После ввода учётных данных злоумышленники получали действительные токены доступа, позволяющие им действовать от имени жертвы.

В комментариях участники высказали разные мнения:

• cliffx – если бы страницы входа Microsoft выглядели одинаково, атака была бы сложнее.
• sweetno – создание 20‑ти переадресаций в правильном порядке – настоящая работа.
• dabestgoat – удивительно, что даже мощные защитные системы не могут остановить такие письма, а компании вместо этого «открывают» HR‑системы для Copilot.
• AlasPoorZathras – призывает сосредоточиться на реальных угрозах, а не на политических спорах.
• Kiss‑cyber – подчёркивает, что это уже не проблема аутентификации, а авторизации: после согласия пользователя на вредоносное приложение MFA уже не спасает.

Суть проблемы, хакерский подход, основные тенденции

Ключевая идея фишинга OAuth – заставить пользователя дать согласие на приложение, которое выглядит легитимным. После этого злоумышленник получает токен с теми же правами, что и у обычного пользователя, и может выполнять любые действия, разрешённые этим токеном.

Тенденции:

• Рост количества «многошаговых» переадресаций, имитирующих реальный процесс входа.
• Перенос фокуса с MFA на контроль согласий и прав приложений.
• Увеличение количества сервисов, интегрированных через Entra (ранее Azure AD), что расширяет поверхность атаки.

Детальный разбор проблемы с разных сторон

Техническая сторона

OAuth 2.0 подразумевает три основных элемента: клиент (приложение), ресурсный сервер и сервер авторизации. При фишинге злоумышленник подменяет клиент, получая authorization code, который затем меняет на токен доступа. Токен может включать широкие scopes (права), позволяющие читать почту, управлять пользователями и т.д.

Организационная сторона

Многие компании позволяют пользователям самостоятельно давать согласие на сторонние приложения. Это упрощает работу, но открывает дверь для атак. Как отметил Kiss‑cyber, «самый сильный контроль – это управление согласиями приложений, а не отдельные политики Conditional Access».

Психологическая сторона

Пользователи привыкли к множеству переадресаций в процессе входа в облачные сервисы. Поэтому цепочка из 20‑ти редиректов выглядит «нормально», а не подозрительно.

Практические примеры и кейсы

• Кейс 1: Компания X получила несколько жалоб от сотрудников, которые после клика по ссылке в письме увидели «вход в Microsoft», но после ввода пароля их аккаунт был взломан. Анализ показал, что злоумышленник использовал OAuth‑фишинг с 18 переадресациями.
• Кейс 2: В одном из крупных университетов злоумышленник создал поддельное приложение, запросившее права Mail.ReadWrite и User.Read.All. После согласия студентов приложение получило доступ к их почте и учебным материалам.

Экспертные мнения из комментариев

«This would be much harder for the attackers if the Microsoft login page had a consistent look and feel to them» – cliffx

«Faking all those 20 redirects in an authentic order must be a chore» – sweetno

«You'd think the all mighty defender would be able to prevent these from entering your inbox, you know, with AI. But NO...» – dabestgoat

«Has modern Russia govern anything to the world other than omniphobic governments... Maybe we should stop murdering fishermen in South America and focus on an actual risk to liberal democracy.» – AlasPoorZathras

«What most people miss with these OAuth phishing campaigns is that this isn’t really an authentication problem anymore, it’s an authorization one...» – Kiss‑cyber

Возможные решения и рекомендации

• Ограничить пользовательское согласие: По умолчанию запрещать пользователям давать согласие на новые приложения; требовать одобрения администратором для чувствительных scopes.
• Регулярный аудит сервис‑принципалов: Проводить автоматический обзор всех зарегистрированных приложений, удалять неиспользуемые и проверять права.
• Усилить Conditional Access: Ограничить, кто может инициировать процесс согласия (например, только из корпоративной сети или с MFA).
• Обучение пользователей: Проводить тренинги, показывая, как выглядит настоящая страница входа Microsoft и как проверять URL.
• Мониторинг аномалий токенов: Настроить оповещения о выдаче токенов с необычными правами или из неизвестных приложений.

Заключение с прогнозом развития

Фишинг OAuth уже перешёл из «узкой ниши» в массовую угрозу. По мере роста количества облачных сервисов и интеграций, количество точек входа будет только увеличиваться. Ожидается, что к 2026 году более 30 % всех инцидентов компрометации учётных записей будет связанно именно с неправильным управлением согласиями OAuth.

Для защиты необходимо переосмыслить подход: от «защищаем пароль» к «контролируем права приложений». Только так можно остановить злоумышленников, которые уже умеют обходить MFA.

Практический пример (моделирование OAuth‑фишинга)

Ниже – простой скрипт, который имитирует процесс получения токена по коду авторизации. В реальном мире такой запрос может использовать злоумышленник после того, как пользователь ввёл свои учётные данные на поддельной странице.

import requests

def oauth_authorization(token_endpoint, client_id, client_secret, auth_code):
    """
    Имитирует запрос обмена кода авторизации на токен доступа.
    
    Параметры:
        token_endpoint: URL сервера токенов (например, https://login.microsoftonline.com/.../oauth2/v2.0/token)
        client_id: Идентификатор клиента (приложения)
        client_secret: Секрет клиента
        auth_code: Код авторизации, полученный после «входа» пользователя
    
    Возвращает:
        dict с данными токена или сообщение об ошибке.
    """
    headers = {"Content-Type": "application/x-www-form-urlencoded"}
    payload = {
        "grant_type": "authorization_code",
        "code": auth_code,
        "redirect_uri": "https://localhost/callback",
        "client_id": client_id,
        "client_secret": client_secret,
    }
    try:
        response = requests.post(token_endpoint, data=payload, headers=headers, timeout=10)
        response.raise_for_status()
        return response.json()
    except requests.RequestException as exc:
        return {"error": str(exc)}

# Пример использования (данные вымышленные)
if __name__ == "__main__":
    token_url = "https://login.microsoftonline.com/common/oauth2/v2.0/token"
    cid = "example-client-id"
    csecret = "example-client-secret"
    code = "example-auth-code"

    token_info = oauth_authorization(token_url, cid, csecret, code)
    if "access_token" in token_info:
        print("Токен получен:", token_info["access_token"][:30], "...")
    else:
        print("Ошибка получения токена:", token_info.get("error"))

Скрипт демонстрирует, как простой HTTP‑запрос может превратить «код авторизации», полученный от пользователя, в полноценный токен доступа. Защищать такие запросы можно только ограничивая возможность получения кода (т.е. контролируя согласия и проверяя URL‑адреса).