Статья Bug Bounty с нуля: как начать зарабатывать на поиске уязвимостей в 2026 году

Помню свой первый отправленный отчёт на HackerOne. Reflected XSS, найденный за три часа сканирования - красиво оформленный, с PoC, со скриншотами. Через два дня пришёл ответ: «Duplicate». Кто-то нашёл его на шесть часов раньше. Второй отчёт - «Out of Scope». Третий - «Informational, not a security issue». Три недели работы, ноль на счету.

Статья записана со слов нашего с вами коллеги. Далее от первого лица.

Спустя полтора года регулярной практики у меня были подтверждённые выплаты за IDOR, SSRF, логические баги в авторизации и несколько stored XSS. Не миллионы, но стабильный доход и приглашения в приватные программы. Разница между первым месяцем и первым баунти - не талант и не удача. Это методология.

Дальше - конкретный план: как начать bug bounty с нуля в 2026 году, с командами, чеклистами и планом на 90 дней. Без мотивационной воды про «просто учись и верь в себя».

Почему bug bounty в 2026 - это не «запусти сканер и получи деньги»​

Если поискать мнения о bug bounty, увидишь два полюса: «bug bounty мертво» и «я заработал $100k новичком». Оба - враньё. Индустрия изменилась, но не умерла.

В 2018–2020 годах хватало запустить автоматический сканер на крупную цель - и получить выплату за стандартный баг. Сейчас компании сами прогоняют nuclei-шаблоны, встраивают SAST/DAST в CI/CD, и типовые уязвимости закрываются до того, как багхантер откроет Burp Suite. По данным HackerOne Annual Report и Bugcrowd State of Bug Bounty - «low-effort hunting no longer works». Охота без усилий больше не кормит.

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

Bug bounty в 2026 работает для тех, кто:

• Фокусируется на одной цели, а не сканирует двадцать программ параллельно
• Читает документацию приложения как обычный пользователь, прежде чем атаковать
• Тратит 70% времени на разведку и 30% на тестирование
• Готов к неделям без результата перед первой находкой

Это не «два часа в день на фрилансе». Это полноценная исследовательская работа, где с точки зрения

Ссылка скрыта от гостей

вы проходите те же этапы, что и реальный атакующий - от пассивной разведки (Search Open Technical Databases, T1596, Reconnaissance) до эксплуатации (Exploit Public-Facing Application, T1190, Initial Access). Разница в том, что вы делаете это легально и с разрешения владельца системы.

Что нужно знать до первого отчёта​

Не стоит начинать охоту на баги без фундамента. Но и тратить год на «подготовку» - ошибка. Вот минимальный набор, с которым можно выходить на реальные программы.

Сетевые основы и веб-технологии​

Вы должны понимать, что происходит, когда вводите URL в браузер: DNS-резолвинг, TCP-подключение, HTTP-запрос, ответ сервера, рендеринг страницы. Без этого вы не поймёте, что перехватывает Burp Suite и зачем.

Конкретный минимум:

• HTTP-методы (GET, POST, PUT, DELETE) и коды ответов (200, 301, 403, 500)
• Заголовки: Cookie, Authorization, Content-Type, CORS-заголовки
• Как работают сессии: cookie vs JWT vs OAuth-токены
• Базовый JavaScript - не для написания фреймворков, а чтобы ковыряться во фронтенд-коде в поисках скрытых эндпоинтов и API-ключей
• Разница между клиентской и серверной стороной

Для начала этого хватит за глаза.

Типы уязвимостей, которые реально находят новички​

Забудьте про RCE на Google - это не ваша первая цель. Вот классы багов, с которых начинается путь:
IDOR (Insecure Direct Object Reference) - самый частый первый баунти у начинающих. Меняете ID объекта в запросе (номер заказа, ID пользователя) и получаете доступ к чужим данным. Никаких сложных инструментов - Burp Suite и наблюдательность.

XSS (Cross-Site Scripting) - reflected и stored. Найти XSS на зрелой программе уже непросто, но на менее популярных целях и в свежем функционале - вполне реально.

Information Disclosure - утечки через открытые конфиги, debug-режимы, незакрытые эндпоинты. В терминах MITRE ATT&CK это

Ссылка скрыта от гостей

(T1552.001, Credential Access) - когда учётные данные или API-ключи валяются в доступных файлах.

Subdomain Takeover - поддомен указывает на сервис (AWS S3, Heroku, GitHub Pages), который больше не существует. Вы регистрируете этот сервис и получаете контроль над поддоменом.

Broken Link Hijacking - приложение ссылается на внешний ресурс, который можно перерегистрировать.

Как выбрать первую bug bounty программу и не потратить месяц впустую​

Здесь большинство новичков совершают критическую ошибку. Видят программы Google, Apple, Meta - и бросаются туда, потому что «выплаты огромные». На этих программах пасутся тысячи опытных охотников, и шанс найти что-то раньше них стремится к нулю.

VDP как стартовая площадка​

VDP (Vulnerability Disclosure Programs) - программы без денежных выплат, но с признанием (Hall of Fame). Опытные багхантеры их игнорируют - нет денег, нет интереса. Для вас это идеально:

• Минимальная конкуренция
• Реальный шанс найти валидный баг
• Репутационные очки на платформе, которые открывают приватные программы

На HackerOne и Bugcrowd есть фильтры для VDP. Начните с них.

Google Dorks для поиска малоизвестных программ​

Не все программы сидят на крупных платформах. Многие компании публикуют политику ответственного раскрытия (responsible disclosure) прямо на своём сайте. Используйте поисковые дорки - тот же принцип, что в технике Search Engines (T1593.002, Reconnaissance) из MITRE ATT&CK, где атакующий ищет информацию о цели через поисковики. На подготовительном этапе вы ищете программы, а при разведке конкретной цели - дорки вроде site:target.com filetype:pdf уже напрямую соответствуют T1593.002:

inurl:/security.txt
inurl:/responsible-disclosure
inurl:"bug bounty"
inurl:security reward
inurl:/.well-known/security.txt

Такие программы часто не попадают в поле зрения массовой аудитории - конкуренция на них заметно ниже.

Критерии выбора цели​

При сравнении программ составьте таблицу:

Критерий	На что смотреть
Scope	Широкий (wildcard *.target.com) лучше для новичков - больше поверхность атаки
Время ответа	Проверьте среднее response time на платформе. Меньше 7 дней - хороший знак
Тип приложения	Веб-приложения и API проще для старта, чем мобильные или IoT
Раскрытые отчёты	Есть disclosed reports? Читайте их - это ваш учебник по программе
Свежесть	Новые программы или недавно расширенный scope - лучшие окна для входа

Разведка цели: пошаговая методология с командами​

Разведка (recon) - это 70% успеха в bug bounty. Баги не ищутся на ровном месте - они ищутся на тщательно исследованной поверхности.

Перечисление поддоменов​

Я никогда не полагаюсь на один инструмент. Каждый источник знает что-то своё - чем больше агрегируете, тем полнее картина. Классическое применение техник Search Open Technical Databases (T1596, Reconnaissance) - поиск поддоменов через пассивные DNS-агрегаторы (T1596.001), Certificate Transparency логи (T1596.003) и поисковые движки (T1593.002).

# Пассивное перечисление из нескольких источников
subfinder -d target.com -o subfinder_subs.txt
assetfinder --subs-only target.com > assetfinder_subs.txt

# Объединение и дедупликация
cat subfinder_subs.txt assetfinder_subs.txt | sort -u > all_subs.txt

# Результат: единый список уникальных поддоменов
wc -l all_subs.txt

На практике я запускаю subfinder и assetfinder параллельно, затем объединяю результаты утилитой anew (если стоит) или классической связкой sort -u.

Проверка живых хостов и визуальная разведка​

Список в тысячу поддоменов бесполезен, если вы не знаете, какие из них отдают HTTP-ответ.

# Проверка живых хостов
cat all_subs.txt | httpx -o alive.txt

# Визуальный скриншот всех живых поддоменов (gowitness v3+)
gowitness scan file -f alive.txt --screenshot-path screenshots/

Gowitness генерирует HTML-отчёт со скриншотами каждого живого поддомена. Вместо того чтобы открывать сотню вкладок, листайте скриншоты и ищете: панели авторизации, старый UI (часто = старый код), страницы с ошибками 403/500, нестандартные сервисы. Например, у меня этот этап не раз вытаскивал забытые админки, которые основной скоуп даже не подразумевал.

Определение стека технологий​

Зная стек, вы понимаете, какие уязвимости искать:

# Фаззинг директорий на конкретном живом хосте
ffuf -u https://app.target.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302,403

# Проверка заголовков ответа (стек)
curl -sI https://app.target.com | grep -iE "server|x-powered|x-aspnet|x-generator"

В Burp Suite я включаю Passive Scanner и просто хожу по приложению как обычный пользователь - регистрация, логин, создание контента, загрузка файлов. Прокси перехватывает каждый запрос и подсвечивает потенциальные точки интереса. Тут торопиться не надо - иногда самые жирные баги находятся в самом банальном функционале.

Ручное тестирование: чеклист для первых находок​

Автоматические сканеры - не зло, но полагаться только на них - путь к дубликатам. Компании сами запускают nuclei и Burp Scanner. Ваше преимущество - ручное тестирование логики приложения, которое автоматика не понимает.

IDOR - самый частый первый баунти​

Пошаговый процесс:

1. Откройте Burp Suite, включите перехват прокси
2. Зарегистрируйте два аккаунта в приложении (User A и User B)
3. Под User A создайте ресурс (заказ, профиль, документ)
4. Перехватите запрос к этому ресурсу - найдите числовой или предсказуемый ID
5. Переключитесь на сессию User B
6. Повторите запрос с ID ресурса User A
7. Если User B получает доступ к ресурсу User A - это IDOR

GET /api/v1/orders/1337 HTTP/1.1
Host: app.target.com
Cookie: session=USER_B_SESSION_TOKEN

Если ответ содержит данные заказа User A - поздравляю, вы нашли IDOR. Запишите все шаги воспроизведения. На одном проекте я так нашёл утечку полных данных заказов - просто перебрал ID от 1 до 100 и получил чужие ФИО, адреса и суммы.

XSS - не так просто, как кажется​

Отправлять <script>alert(1)</script> в каждое поле - не тестирование, а спам. На зрелых программах стандартные пейлоады режутся на уровне WAF.

Мой подход:

1. Найдите все точки ввода: поля поиска, комментарии, параметры URL, загрузка файлов (имя файла!)
2. Отправьте маркер codeby12345 - проверьте, где он отражается в ответе
3. Определите контекст: внутри HTML-тега, атрибута, JavaScript-блока, JSON-ответа
4. Подберите пейлоад под контекст. Для атрибута: " onfocus=alert(document.domain) autofocus=". Для JavaScript-блока: '-alert(1)-'
5. Проверьте, обходит ли пейлоад фильтрацию. Если нет - ищите обход через кодирование, альтернативные обработчики событий, DOM-based вектора

Контекст решает всё. Один и тот же пейлоад может быть бесполезен в одном месте и критичен в другом.

Information Disclosure и чувствительные файлы​

Простой, но рабочий чеклист:

# Проверка стандартных путей
ffuf -u https://target.com/FUZZ -w /path/to/sensitive-files.txt -mc 200

# Что искать:
# /.env - переменные окружения с ключами
# /debug - debug-панели
# /.git/config - открытый Git-репозиторий
# /server-status - Apache server-status
# /actuator/env - Spring Boot actuator
# /swagger-ui.html - документация API (часто с рабочими эндпоинтами)
# /graphql - интроспекция GraphQL без авторизации

Найденный открытый .env с API-ключами - валидный баг класса Information Disclosure. На многих программах он тянет на Medium или High в зависимости от того, что именно утекло. Сам видел случай, когда в .env лежали ключи от Stripe - это сразу Critical.

Как написать отчёт, за который платят​

Плохой отчёт убивает валидный баг. Я видел исследователей, которые находили настоящие уязвимости, но получали «N/A» из-за невнятного описания. Triage-команда тратит на каждый отчёт минуты, не часы - если непонятно с первого прочтения, отчёт уходит вниз очереди.

Анатомия принятого отчёта​

Каждый отчёт должен содержать пять элементов:

1. Заголовок - краткий, конкретный, с типом бага и затронутым активом:
IDOR in /api/v1/orders/{id} allows any authenticated user to access other users' order details

2. Описание - что именно не так, в одном абзаце.

3. Шаги воспроизведения - пронумерованный список, который может повторить человек, впервые видящий приложение:

1. Зарегистрируйте аккаунт A на https://app.target.com/signup
2. Под аккаунтом A создайте заказ - запомните ID (например, 1337)
3. Зарегистрируйте аккаунт B
4. Под аккаунтом B отправьте запрос:
   GET /api/v1/orders/1337
   Cookie: session=<токен_аккаунта_B>
5. Ответ содержит полные данные заказа аккаунта A

4. Воздействие (Impact) - не «можно украсть данные», а конкретно: «Атакующий может получить ФИО, email и историю покупок любого пользователя, что открывает дорогу для целенаправленного фишинга». Привяжите к бизнес-риску - именно это отличает отчёт за $200 от отчёта за $2000.

5. PoC (Proof of Concept) - скриншоты, cURL-команда, HTTP-запрос/ответ из Burp Suite. Чем нагляднее, тем быстрее примут.

Рекомендация по исправлению - необязательно, но повышает качество отчёта и вашу репутацию. Например: «Добавить проверку принадлежности ресурса текущему пользователю на уровне бэкенда».

Ошибки, которые крадут месяцы у новичков​

Я совершил каждую из этих ошибок. Вот что вынес:

Ловушка автоматизации. Новички запускают nuclei с полным набором шаблонов на основную цель и ждут чудес. Проблема: компания уже делает это сама. Всё, что найдёт ваш сканер, с высокой вероятностью уже в базе. Автоматизация нужна для разведки (перечисление поддоменов, проверка живых хостов), а не для самого поиска уязвимостей.

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

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

Игнорирование scope. Это не просто «правило» - это граница между ответственным раскрытием уязвимостей и нарушением закона. Тестирование за пределами scope может привести к блокировке аккаунта и юридическим последствиям. В России действует статья 272 УК РФ о неправомерном доступе к компьютерной информации - официальное соглашение через bug bounty программу и есть ваша правовая защита.

Непонимание бизнес-импакта. Self-XSS, который срабатывает только у самого пользователя - не уязвимость. Open redirect без дополнительной цепочки - часто «Informational». Учитесь смотреть на находку глазами бизнеса: может ли атакующий реально навредить компании или её пользователям?

Bug bounty платформы: какую выбрать в 2026 году​

Международные платформы​

Платформа	Для кого	Особенности
HackerOne	Все уровни	Крупнейшая, Hacker101 для обучения, широкий выбор VDP
Bugcrowd	Все уровни	CrowdMatch подбирает программы под навыки, Bugcrowd University
Intigriti	Средний уровень	Европейская, DOJO для тренировки, программы средней сложности
YesWeHack	Начинающие	Fastlane Program с низкой конкуренцией

Российские bug bounty платформы​

Российский рынок bug bounty серьёзно вырос за последние годы. По данным Positive Technologies на конец 2024 года (последние доступные на момент написания), на Standoff 365 зарегистрировано более 27 тысяч исследователей, размещено более 200 программ, а суммарные выплаты превысили 274 миллиона рублей. Актуальную статистику проверяйте на сайте платформы.

Standoff 365 Bug Bounty (Positive Technologies) - крупнейшая российская платформа. Здесь размещались программы Минцифры для «Госуслуг» / ЕСИА. Упор на «результативную безопасность» и сценарии, приближённые к реальным атакам.

BI.ZONE Bug Bounty - быстрый триаж и удобные инструменты для отчётов. По заявлениям BI.ZONE, среднее время первого ответа (триажа) - около 30 часов. Реальное время до получения выплаты зависит от сложности отчёта, программы и формы оформления (самозанятый/ИП).

bugbounty.ru - первая российская публичная платформа. Подходит как стартовая точка с базовыми публичными программами.

Из свежих кейсов - мессенджер Max (VK) включён в bug bounty на трёх платформах (Standoff 365, BI.ZONE, bugbounty.ru) с выплатами до 5 миллионов рублей за критичные находки. Неплохая мотивация копнуть поглубже.

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

90-дневный план: от нуля до первого баунти​

Этот план - на основе моего собственного пути, адаптированный под реалии 2026 года. Он не гарантирует выплату через 90 дней, но гарантирует, что вы не потратите эти 90 дней впустую.

Фаза 1: Фундамент (недели 1–3)​

Неделя 1–2. Пройдите бесплатные лаборатории

Ссылка скрыта от гостей

. Начните с разделов: Access Control (IDOR), XSS (reflected, stored), Authentication. Не пытайтесь пройти всё - фокус на трёх типах уязвимостей.

Неделя 3. Установите и настройте рабочее окружение:

# Установка Go (apt-версия часто устаревшая; рекомендуется Go 1.21+ с https://go.dev/dl/)
wget https://go.dev/dl/go1.23.0.linux-amd64.tar.gz && sudo tar -C /usr/local -xzf go1.23.0.linux-amd64.tar.gz
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
go install -v github.com/tomnomnom/assetfinder@latest
go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest
go install -v github.com/ffuf/ffuf/v2@latest

# Добавление Go-бинарников в PATH
echo 'export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin' >> ~/.bashrc
source ~/.bashrc

Установите

Ссылка скрыта от гостей

. Настройте браузер для работы через прокси (127.0.0.1:8080). Научитесь перехватывать и модифицировать запросы - потренировавшись «на кошках» (тот же PortSwigger), прежде чем лезть на реальные цели.

Фаза 2: Инструменты и практика (недели 4–6)​

Неделя 4. Зарегистрируйтесь на HackerOne и Bugcrowd. Заполните профили, включите 2FA. Найдите 3–5 VDP-программ с широким scope (wildcard-домены).

Неделя 5. Проведите полную разведку одной цели. Не переключайтесь. Перечислите поддомены, проверьте живые хосты, просмотрите скриншоты, определите стек. Составьте карту приложения.

Неделя 6. Ручное тестирование: пройдите чеклист IDOR, XSS, Information Disclosure на каждом эндпоинте. Читайте JavaScript-код фронтенда - ищите скрытые API-эндпоинты, hardcoded ключи, внутренние URL.

// Пример: поиск API-эндпоинтов в минифицированном JS
// Откройте DevTools → Sources → ищите паттерны:
// "/api/v1/", "/api/v2/", "/internal/", "/graphql"
// fetch(", axios.get(", $.ajax(
// Каждый найденный эндпоинт - потенциальная точка входа

Фаза 3: Реальная охота (недели 7–12)​

Недели 7–8. Отправьте первые отчёты. Даже если находка кажется слабой - отправляйте. Обратная связь от triage-команды бесценна. Читайте раскрытые (disclosed) отчёты на Hacktivity - это реальные примеры принятых багов.

Недели 9–10. Проанализируйте отказы. «Duplicate» - вы ищете правильные вещи, но медленно. «Informational» - работайте над оценкой бизнес-импакта. «Out of Scope» - перечитайте policy внимательнее.

Недели 11–12. Расширьте методологию. Добавьте тестирование: логики авторизации (повышение привилегий), race conditions, SSRF через параметры URL (callback, redirect, avatar upload). Попробуйте вторую цель, но не бросайте первую.

Что дальше: приватные программы и стабильный заработок​

Первый принятый баг - начало, не конец. На HackerOne и Bugcrowd существуют приватные bug bounty программы, доступные только по приглашению. Приглашения приходят автоматически на основе вашей репутации - количества валидных отчётов, их критичности и качества.

Приватные программы - главный источник стабильного дохода для bug bounty hunter: меньше конкуренция (только приглашённые), быстрее ответ от команды безопасности, часто выше выплаты.

Путь к приватным программам:

1. Отправляйте качественные отчёты в публичные программы - даже в VDP без денежных выплат
2. Не спамьте невалидными находками - это снижает репутационные баллы
3. Будьте профессиональны в коммуникации с triage-командой
4. На HackerOne дополнительно можно получать приглашения за прохождение CTF-задач Hacker101

Bug bounty - не лотерея и не пассивный доход. Это навык, который требует методичной работы, глубокого понимания веб-технологий и терпения. Но в отличие от большинства профессий в IT, здесь платят за результат, а не за отсиженные часы. Попробуйте прогнать разведку на любой VDP-программе по чеклисту из этой статьи. Если нашли хотя бы один живой поддомен с интересным сервисом - вы уже на правильном пути.