Так уж вышло, что я сел писать статью о нашем с Саней (@MrKaban4ik) приключении в багбаунти. Сразу предупреждаю: бывалым исследователям наша история покажется не самой захватывающей. Она не о сложных цепных эксплойтах, а о самом начале пути — о том, как ты делаешь первый шаг на площадке и, затаив дыхание, ждешь вердикта по своему первому отчету. Именно эти первые «хваты» вселяют ту самую уверенность, что ты на правильном пути.

{Багбаунти-кидди презенс}

Чуть предыстории. НЕБОЛЬШАЯ ИСТОРИЧЕСКАЯ СПРАВКА НА 5 МИНУТ. Февраль 2025 года.

Мы с Александром часто участвуем в CTF в рамках студенческой команды Capybaras. Недавно закончился Чемпионат России по спорт проге ИБ, мы написали квалы на чемпионат банка РФ и нас зовут в Екатеринбург на Уральский форум. Вуз платит - едем. К этому моменту мы знаем о вебе что он существует и что если нет никаких ограничений на загрузку можно загрузить файлик .php который может быть шелом и как то магически команды на OS исполняет. О багбаунти мы слышали, но не седели особо - потому что просто не знаешь что искать. Мы с Александром собираем вещи, едем в Сочи и оттуда летим в Екатиб. Хотя давайте меньше деталей, вы же тут не до вечера собрались читать. В общем-то первый наш форум по ИБ, много вендоров и лекций в молодежной программе. Знакомлюсь с ДВФУ-шниками, до сих пор {heart}. Но вернемся к форуму. Среди вендоров был и BI.ZONE. Интерес конечно же у меня к нему был потому что они недавно выпускают Threat Zone и как только открылась выставка, а у нас шла кибербитва - я решаю незаметно сбежать и сходить залутать заветный журнальчик. Подхожу к стенду, решаю потыкать стендик и подходит какой-то тип в черном костюме и начинает спрашивать знаком ли я с продуктами компании, я жестко говорю что знаю EDR и какой то прикол с жуками, называемый bugbounty. А этот тип говорит : "Я глава этого продукта". Таким образом мы познакомились с человеком по имени Андрей Левкин - который сыграет на самом деле большую роль в том, чтоб мы начали багхантить. Форум заканчивается и мы едем домой.

Позже я вернусь к Андрею с фича реквестом и на этом завяжется наше общение, которое приведет меня на платформу BI.ZONE Bugbounty. В начале получалось не слишком хорошо, тыкалось все подряд. Первой уязвимостью стала 2-click xss на программе, которая оказывается уже была закрыта:) Ну то есть было понимание что успех неизбежен. В Апреле состоялся 4 Bug$Zone - ивент от площадке BI.ZONE BugBounty, где выбирают 25 лучших за сезон и зовут хантить на приватном скоупе программ, а потом еще и приватное афтепати устраивают с докладами. И Саню туда позвал. На bugbounty party был доклад shdw об использовании nuclei и я чета так загорелся, что решил начать использовать в багбаунти. Спойлер - дело пошло и первые мои отчеты были найдены именно таким способом. Вообще в целом скажу - самое главное это начать. Первые оплаченные отчеты помогают перейти вот этот барьер того что ты можешь. После все идет легче значительно.

Немного о Российском ББ как вижу его я

Ну для начала — у нас есть 3 основных площадки: BI.ZONE BugBounty, Standoff365 и bugbounty.ru. Последняя существует давно и сейчас как будто бы не в лучшем своем состоянии, хотя недавно поменяла дизайн, активно отвечает на сообщения, фича реквесты и там есть по меньшей мере 1 уникальная программа — Securitm. Советую присмотреться, так как триаж достаточно приятный, программа направлена на багхантеров и не плохие выплаты. Лично у меня была ситуация когда ситуацию решили в мою пользу. Помимо этого у нас есть селфхост программы — например Яндекс Bugbounty и программы Контура, которые размещены на их сайтах. Мое мнение — селф хост очень не удобно, был бы рад чтоб программы аккумулировались на площадках. В целом по вендорам у нас так: Госуха, Финтех, Бигтех, хотя бывают и небольшие компании — им прям респект. А ну еще есть НСки на Standoff — но это ваще другая история. Есть вендора которые направляют свою программу на своих хантеров — ВК и МКБ как хороший пример. Когда‑то ТБанк мне увеличил критичность в следствии своего ресерча — за это респект, я все помню :-)

Есть еще несколько в приватке, но не могу к сожалению вам респектнуть, хотя сильно люблю пиццу :-) В целом хотелось бы верить что будут больше выходить компании, хотел бы увидеть Вкусно и Точка, сети Магнит и Пятерочка, КБ, Читаю город, конечно же РЖД и авиакомпании, сервисы Whosh и Urent. Хотелось бы чтоб вендоры понимали что багхантеры это как их сотрудники, с ними можно поддерживать деловую среду и совместо заниматься улучшением приложения. А еще респект тем, кто в воскресенье триажит:-)

@MrKaban4ik [https://t.me/MrKaban4ik]
В CTF моей любимой категорией была стеганография, поэтому решать я умел только её. Со временем я начал понимать, что это направление не принесёт плодов, и решил, что пора сменить род деятельности. В качестве альтернативы я выбрал веб.

Буквально через несколько дней изучения материалов и решения задач на платформах, после усвоения основных уязвимостей, я выделил для себя наиболее интересную — LFI. Тогда же я решил проверить её на реальных сайтах. Именно с этой целью мной был зарегистрирован аккаунт на площадке Bug Bounty.

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

И в конце концов мне повезло — но не совсем так, как я планировал. В один из дней я заметил, что на площадке появилась новая программа. Это был «СберАнтифрод». Программа была уникальна в своём роде, так как не была связана с привычными техническими уязвимостями. Поскольку это было что-то новое, никто не знал, что туда можно сдавать — в программе не было буквально ни одного отчета.

Тогда я решил рискнуть. Я поискал в интернете актуальные схемы мошенничества, которые часто публикуют в Telegram-каналах, и отправил две из них. Ответа от Сбера долго не было, но спустя два месяца мне пришли две крупные выплаты — на 30 и 80 тысяч. В тот момент моему счастью не было предела. Появилась огромная мотивация двигаться дальше и развиваться в баг-баунти.

Поэтому первый совет, который я хотел бы дать: не стоит бояться пробовать что-то новое или ошибаться. Если продолжать пытаться, рано или поздно получится.

Теперь продолжу рассказ. Вернувшись с уже упомянутого мероприятия в Екатеринбурге, я сдал ещё один отчет, связанный с открытым редиректом, и в итоге занял 26 место в квартальном рейтинге. Этого было недостаточно, чтобы попасть на Bugs Zone, но Андрей дал мне шанс и пригласил поучаствовать. За что ему огромное спасибо.

На BugZone был интересный scope, но в то же время я понимал, что вместе со мной баги ищут профессионалы с многолетним опытом. Поэтому во время мероприятия я вывел для себя ещё одно правило: искать то, что не ищут другие. Мне помогал Влад, и общими усилиями мы смогли сдать 5 уязвимостей. Это были очень простые, но непопулярные уязвимости, о которых знают немногие.

Благодаря правильно выбранному вендору и нестандартному мышлению я занял 5 место на мероприятии. Это было очень круто.

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

В баг-баунти, как и во всей сфере информационной безопасности, важно постоянно развиваться, изучать что-то новое — именно так можно находить баги раньше других.

Для всех, кто хочет начать.

Надо хантить. Да — все просто. Ко мне буквально заходили пару людей с вопросом — «как понять что готов?». Чуваки, я веб тыкать начал тогда, когда бб начал заниматься, я весь иб путь форензикой занимался:) Как говорил один товарищ — если ты думаешь что готов, ты уже опоздал. Есть желание — сейчас же рега��мся на площадке и начинаем Но некоторые советы мы Саней все же дадим:

1. Старайся делать то, что другие не делают.

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

2. Bugspraying - путь к обогащению.

Bugspraying — это методология поиска уязвимостей, при которой исследователь кибербезопасности (например, участник программы bug bounty), обнаружив специфическую ошибку (баг) в одном приложении, продукте или веб-сайте, целенаправленно ищет аналогичную ошибку в других, часто похожих или конкурирующих продуктах или сервисах.

На моем опыте была уже одна бага которую я сдавал во все программы, что видел и она мне принесла более 8 валидных отчетов на сумму около 250к, хотя ее эксплуатация это несколько кнопок. Суть в том что данный риск был миттигирован в общем и не представлял опасности, но я вспомнил об этой возможности, которая появилась еще когда современное иб только строилось и в таком виде вендора оценивали багу зачастую сильнее чем SQL, LFI, или даже RCE. А дальше я просто пошел сдавать ее везде.

3. Читать ресерчи и отчеты других хантеров

В уже упомянутом BugZone все баги, что были найдены - были вдохновлены какими-то отчетами. В частности статьей Slonser и Kaspersky. Часто из статьи можно взять реализацию, где-то endpoint, а где-то узнать что это вообще так работает.

4. Комьюнити.

Обязательно становитесь частью комьюнити. Комьюнити - это когда ты не один и вас много. И вот это много часто помогает. Когда-то Илья может закинуть перерыв на кошку, кто-то кинуть сберовский ковер и тем самым поднять тебе настроение - а иногда бывают моменты, когда ты познакомился с кем-то из комьюнити и можешь у опытного товарища спросить совет по баге. Комьюнити делает тебя сильней, это возможность - которой нужно пользоваться.

5. Автоматизация. Скрипткиди

Что можно автоматизировать? Очевидно рекон. Есть большое количество инструментов для поиска субдоменов. Можно автоматизировать проверку багов через большое количество сканеров. Еще что я встречал реже, но мне кажется этим кто-то да занимается - мониторинг ресурсов компании. Ты можешь смотреть скоуп и замечать изменения на нем. Выкатили новый сервис и никому не сказали? - вперед.

Инструментарий Багбаунти

Предположим вам дан скоуп

*.domain.ru

Это означает что все домены 2 уровня входят в скоуп, но как их найти? Существует просто огромное количество способов реализовать поиск поддоменов. Я люблю использовать Findomain.

Что делает: быстрый сбор поддоменов и OSINT-разведка (Certificate Transparency, APIs и т.п.). GitHub Когда: на этапе рекона — получить «список» субдоменов для дальнейшего сканирования. Пример: findomain -t example.com -o domains.txt Совет: комбинируй с httpx/nuclei и мониторингом (оповещения при появлении новых субдоменов).

В случае когда даны ip адреса лучше конечно использовать nmap

Что делает: сканирование портов/сервисов/OS — классика сетевого рекона и проверки открытых сервисов. Nmap Когда: нужно понять, какие сервисы доступны на хосте (например для атак на админ-панели, устаревшие сервисы и пр.). Пример: nmap -sS -sV -p- target.com Совет: используй NSE-скрипты для обнаружения уязвимостей (--script), не шуми в пределах scope и правил программы.

Чтобы провалидировать домены которые были найдены я использую httpx.

Что делает: быстрый HTTP-пробник/фильтр для списка доменов/URL — проверяет доступность, коды ответа, заголовки, TLS и т.д. GitHub Когда: после сбора поддоменов — чтобы убрать мёртвые хосты и получить живые пути для дальнейшего сканирования. Пример: cat domains.txt | httpx -silent -status-code -o live.txt Совет: комбинируй с waybackurls/gau для поиска интересных путей, и с nuclei/ffuf дальше.

После того как домены собраны, проанализированы - настало время работать.

В первую очередь можно запустить Nuclei - счастье если у тебя есть кастомные шаблоны.

Что делает: шаблонный (YAML) высокопроизводительный сканер уязвимостей — миллионы шаблонов (templates) сообщества/ProjectDiscovery. GitHub Когда: массовое/быстрое выявление известных проблем по списку URL/поддоменов. Пример: nuclei -l urls.txt -t cves/ -o nuclei_out.txt Совет: держи локальную копию шаблонов (nuclei -ut) и фильтруй по severity; модульно подключай CI.

Для ручного тестирования всегда есть многофункциональный Burp Suite Pro - его кстати можно зарегистрировать по корпоративной почте на месяц бесплатно.

Что делает: «швейцарский нож» для ручного и автоматизированного тестирования веб-приложений (Proxy, Intruder, Scanner — Pro/Enterprise/Community). PortSwigger Когда: глубокий ручной анализ, интерактивная проверка логики, цепочки запросов, модификация сессий и обнаружение сложных XSS/IDOR/CSRF. Совет: используй расширения BApp Store, Repeater/Intruder для exploitation и Collaborator для OOB; Pro даёт автоматический сканер и расширенные возможности.

Если нашел интересные параметры - то SSTImap.

Что делает: автомат/интерактивный сканер и эксплойтер для Server-Side Template Injection (основан на tplmap). (репозиторий и демо-материалы — в открытом доступе). GitHub Когда: есть подозрение на шаблонные переменные в выводе (например {{ }} в HTML) — запускаешь SSTImap для быстрого обнаружения/эксплуатации. Пример: обычно python3 sstimap.py -u "https://target/path" (см. README проекта). Совет: тестируй на разных шаблонизаторах (Jinja2, Twig, Freemarker) — SSTImap умеет подбирать полезные полез-строки.

Есть подозрение на скулю? sqlmap.

Что делает: автоматизированное обнаружение и эксплуатация SQLi + расширенные возможности (данные, файловая система, OOB). sqlmap Когда: есть входные параметры/параметры GET/POST и подозрение на SQL-инъекцию. Пример: sqlmap -u "https://target/?id=1" --batch --dbs Совет: начинай с --level/--risk пониженных, используй --threads аккуратно; логируй результаты и работай в рамках разрешённого scope.

Еще особое место в моем сердце занимает grapql endpoint - тут конечно лучше всего GraphQL Cop

Что делает: утилита на Python для автоматических базовых тестов GraphQL (информационные утечки, DoS/complexity и т.п.). GitHub Когда: целевой endpoint — GraphQL; быстро проверить стандартные анти-паттерны и экспозиции. Пример: git clone https://github.com/dolevf/graphql-cop && python3 graphql-cop.py -u https://target/graphql Совет: комбинируй с ручной проверкой схемы (introspection) и обращай внимание на rate/complexity.

Каждый багхантер - это уникальная боевая единица. Я лишь дал то - чем сам пользуюсь.

Как определить критичность найденной уязвимости?

У нас тут есть 2 основных понятия - Критичность уязвимости и Бизнес риски.

Критичность уязвимости — это уровень её опасности. Он показывает, насколько серьёзные последствия могут быть при эксплуатации и насколько легко злоумышленнику её использовать. Чтобы разные специалисты говорили «на одном языке», придумали систему CVSS (Common Vulnerability Scoring System).

CVSS даёт числовую оценку (от 0 до 10), которая строится из нескольких параметров:

  • Базовые (что может дать уязвимость: RCE, доступ к данным, нужна ли авторизация и т. д.),

  • Временные (например, есть ли публичный эксплойт),

  • Контекстные (важность именно для конкретной системы).

Так появляется итоговый балл и «ярлык» — Низкая, Средняя, Высокая или Критическая. Это удобно: можно быстро приоритизировать исправления, не споря «на глаз».

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

  • потеря денег (например, доступ к платёжной системе),

  • утечка клиентских данных (штрафы, потеря доверия),

  • остановка работы сервиса (срыв SLA, репутационные потери),

  • юридические последствия (GDPR, PCI DSS).

Пример:

  • SQL-инъекция с доступом к базе пользователей. По CVSS это будет «высокая/критическая», а по бизнес-рискам — критическая, потому что задевает персональные данные и может ударить по репутации и финансам.

  • Отображение версии веб-сервера в заголовке. По CVSS скорее «низкая». Бизнес-риск тут почти нулевой, потому что сама по себе эта информация мало что даёт.

Итог: критичность по CVSS = техническая серьёзность, а бизнес-риск = реальное влияние на компанию. Вместе они помогают понять, что чинить в первую очередь.

Есть и контрпример:

Сценарий
На тестовом сервере, который не подключён к продакшен-данным и закрыт от клиентов, ты находишь RCE (удалённое исполнение кода).
По CVSS — это критическая уязвимость (RCE без авторизации, полный контроль над системой).

Бизнес-риск

Минимальный, потому что:

  • сервер не содержит клиентских или финансовых данных,

  • нет выхода в основную инфраструктуру,

  • нет доступа у внешних пользователей (например, стоит VPN и это только тестовый стенд разработчиков).

Полезные ссылки

В первую очередь мой канал - https://t.me/thxpluxury и канал Александра - https://t.me/MrKaban4ik

  1. BI.ZONE Bugbounty — https://bugbounty.bi.zone/

  2. Standoff Bugbounty —https://bugbounty.standoff365.com/

  3. Bugbounty.ru — https://bugbounty.ru/

  4. Securitm Bugbounty — https://bugbounty.ru/app/user/programs/servis‑upravleniia‑protsessami‑informatsionnoi‑bezopasnosti‑securitm

  5. Академия портсвигера — https://portswigger.net/web‑security

  6. Тулзы для пентеста — https://github.com/topics/pentesting‑tools

  7. HackTricks — https://book.hacktricks.wiki/en/index.html

  8. Github:)

  9. Google Dorks

  10. И вообще зачем тебе этот список, ты ж багхантер — сам все найдешь.