Заработок для хакера. Полностью переработанное издание 2025—2026

Они не банили старые российские аккаунты так агрессивно, но вывод денег оттуда в российские банки невозможен из-за санкций. Если у тебя есть ВНЖ или счёт в зарубежном банке — это отличные платформы с более низкой конкуренцией, чем на HackerOne. Если зарубежного счёта нет — ты будешь ломать за «фантики», которые не сможешь потратить.

3. Standoff 365 Bug Bounty: Российский лидер и золотая жила 2026 года

Когда западные платформы ушли, в России образовался вакуум. Российский бигтех (Яндекс, VK, Госуслуги, банки) остался без легальных каналов для проверки безопасности тысячами хакеров. Эту нишу молниеносно заняли отечественные платформы.

Безоговорочный лидер рынка в 2026 году — Standoff 365 (от Positive Technologies).

Почему тебе нужно быть здесь:

Масштаб и деньги: К началу 2026 года на платформе зарегистрировано более 32 000 багхантеров. Суммарные выплаты за всё время перевалили за 242 миллиона рублей, а за один только 2025 год багхантеры заработали 160 миллионов (рост почти на 50% к прошлому году).

Рекордные чеки: Забудь про миф, что в РФ платят копейки. Максимальная разовая выплата на Standoff 365 в 2025 году приблизилась к 5 миллионам рублей (4,97 млн руб.) за одну уязвимость. Средний чек за принятый валидный репорт сейчас составляет около 65 000 рублей.

Кто там есть: Практически весь крупный бизнес РФ. Госсектор (Минцифры), VK, Тинькофф, Азбука Вкуса, HeadHunter (который предлагает до 500 000 рублей за крит) и десятки других.

Легальность: Все выплаты абсолютно белые. Деньги приходят на карту российского банка, налоги (НДФЛ для самозанятых) платятся автоматически. Никаких проблем с Финмониторингом.

4. BI. ZONE Bug Bounty: Комфорт и скорость

Платформа от BI. ZONE (дочерняя структура Сбера) — главный конкурент Standoff 365. Она была запущена в 2022 году и сейчас занимает прочную вторую строчку на рынке.

Фишки платформы:

Сверхбыстрые выплаты: BI. ZONE решила главную боль хакеров — долгое ожидание денег. Через интеграцию с платформой «Консоль» (для самозанятых) деньги падают на твою обычную банковскую карту в течение 30 часов после подтверждения уязвимости вендором. На западных платформах иногда приходится ждать месяц.

Интересный скоуп: Кроме самого Сбера и BI. ZONE, здесь много среднего и крупного бизнеса, ритейла и промышленных компаний, чья инфраструктура часто тестировалась хуже, чем у классических IT-гигантов.

Триаж (Triage): У BI. ZONE отличная команда аналитиков, которые проверяют твои репорты перед отправкой клиенту. Если ты написал что-то непонятно, они помогут докрутить репорт, а не просто влепят статус N/A.

5. Частные программы (Self-Hosted)

Не все компании хотят платить комиссию платформам (которая составляет 20—30% сверху от суммы баунти). Многие крупные игроки (например, Яндекс со своей программой «Охота за ошибками» или Ozon) держат свои программы на собственных сайтах.

Плюсы: Вся сумма выплаты идёт тебе, нет конкуренции с толпой сканеров, которые мониторят платформы через API. Минусы: Тебе придётся подписывать договор с каждой компанией отдельно, а в случае спора (если компания скажет «это не баг») у тебя не будет платформы-арбитра, которая могла бы защитить твои интересы.

Стратегия багхантера в 2026 году

Твоя стратегия должна быть прагматичной:

Если ты живёшь в РФ/РБ и не хочешь играть в шпиона: Иди на Standoff 365 и BI. ZONE. Рынок горячий, бюджеты на импортозамещение огромные, вендоры отечественного ПО (Astra Linux, МойОфис и т.д.) сейчас активно покупают услуги багхантеров, чтобы доказать свою надёжность.

Регистрируйся как самозанятый: Это займёт 10 минут, но это обязательное условие для получения легальных выплат на российских платформах.

Не распыляйся: Не нужно регистрироваться на 10 программах сразу. Выбери одну компанию на Standoff или BI. ZONE с широким скоупом, и потрать на неё минимум месяц. Успех в BB — это не широта охвата, это глубина погружения.

Практическое задание

Легализация и выбор первой цели.

Открой файл «Мой хакерский трек». Создай раздел «Мой Bug Bounty Старт».

Шаг 1: Зайди на сайты bugbounty.standoff365.com и bugbounty.bi.zone. Зарегистрируй аккаунты.

Шаг 2: Если у тебя ещё нет статуса самозанятого (НПД) — скачай приложение «Мой налог» и зарегистрируйся. Это бесплатно и не обязывает тебя платить налоги, пока у тебя нет дохода. Без этого ты не сможешь вывести заработанные деньги. Запиши в файл: «Статус самозанятого: Оформлен».

Шаг 3: Открой список программ на обеих платформах. Найди две программы, которые существуют больше года, но где выплаты за Critical уязвимость составляют не менее 150 000 рублей.

Запиши названия этих компаний в файл. Это твои мишени на ближайший месяц.

Никакого взлома Пентагона через прокси. Мы работаем там, где платят реальные рубли прямо на твою карту без риска сесть в тюрьму.

— Методология поиска: разведка, перебор, эксплуатация, репорт

Bug Bounty — это не творчество. Это завод. А на заводе должен быть конвейер. Если ты пытаешься найти RCE (Remote Code Execution) до того, как понял, какие технологии использует сервер, ты пытаешься собрать машину, не имея чертежей.

Профессиональная охота за уязвимостями всегда делится на четыре чётких этапа: Recon (Разведка), Fuzzing/Discovery (Перебор и поиск), Exploitation (Эксплуатация) и Reporting (Отчётность). Давай разберём каждый этап так, чтобы ты перестал тратить время впустую.

Этап 1. Recon (Разведка): Кто владеет информацией, тот владеет деньгами

Разведка — это 70% успеха в Bug Bounty, особенно на программах с широким scope (например, *.target.com). Твоя задача на этом этапе — найти то, о чём забыли админы компании. Старый тестовый сервер, забытую панель администратора без пароля, открытый API-эндпоинт для мобильного приложения, которое уже удалили из AppStore.

Что мы ищем:

Субдомены (Subdomains). Чем больше субдоменов ты найдёшь, тем шире твоя поверхность атаки.

Инструменты: Amass (медленный, но находит всё), Subfinder (молниеносный), assetfinder. Не забудь про dnsx для резолва (проверки, живы ли эти домены).

IP-адреса и порты. Субдомен может вести на балансировщик нагрузки (Cloudflare), за которым прячется реальный сервер (Origin IP). Если ты найдёшь Origin IP, ты сможешь атаковать сервер напрямую, обойдя WAF (Web Application Firewall).

Инструменты: Nmap (для точечного сканирования), Masscan или Naabu (для сканирования тысяч IP за минуты). Ищи открытые порты, отличные от 80 и 443 (например, 8080, 8443, 3306 для баз данных).

Технологический стек. На чём написан сайт? PHP, Java, Ruby, Node. js? Какая версия веб-сервера (Nginx 1.14)? Используются ли старые версии фреймворков (например, уязвимый Apache Struts)?

Инструменты: Wappalyzer (расширение для браузера), httpx (с флагами -tech-detect и -status-code).

Скрытые директории и файлы (Content Discovery). Поиск административных панелей (/admin), бэкапов конфигурации (/.git/, config.bak,.env), старых версий API (/api/v1/).

Инструменты: ffuf (самый быстрый фаззер на Go), dirsearch, gobuster. Главное здесь — не инструмент, а хороший словарь (wordlist). Используй словари от SecLists.

Лайфхак: Настрой уведомления в Telegram на появление новых поддоменов у твоей цели. Компании постоянно выкатывают новые фичи. Если ты отсканируешь новый сервер в первые 10 минут после его запуска, ты соберёшь все лёгкие баги до того, как туда придут конкуренты.

Этап 2. Перебор и поиск (Fuzzing & Discovery): Где тонко, там и рвётся

У тебя есть список живых адресов и технологий. Теперь нужно понять, как приложение реагирует на неадекватное поведение. На этом этапе в игру вступает Burp Suite (твой главный рабочий инструмент).

Что мы делаем:

Маппинг приложения (Spidering). Пройдись по всему сайту руками. Кликай на все ссылки, заполняй все формы, регистрируй аккаунты с разными ролями. Твоя задача — заставить Burp Suite записать в свою историю (HTTP History) максимальное количество уникальных запросов.

Поиск параметров (Parameter Discovery). Иногда разработчики оставляют скрытые параметры, которые включают дебаг-режим или меняют логику. Например, /user/profile? debug=true.

Инструменты: Arjun, ParamMiner (плагин для Burp).

Тестирование бизнес-логики. Это то, что не могут сделать автоматические сканеры. Задай себе вопросы:

Могу ли я добавить товар в корзину с отрицательной ценой?

Могу ли я обойти шаг оплаты в процессе оформления заказа?

Что будет, если я отправлю запрос на изменение пароля для пользователя ID=2, будучи авторизованным под ID=1 (это и есть IDOR)?

Фаззинг входов (Input Fuzzing). Отправляй спецсимволы (»,», <,>, %00, \x00) в каждый параметр каждого запроса (в URL, в тело POST-запроса, в заголовки). Смотри на реакцию сервера. Упал с 500 ошибкой? Отлично, копаем глубже. Вывел твой пейлоад на страницу без фильтрации? Привет, XSS.

Этап 3. Эксплуатация (Exploitation): Превращаем ошибку в чек

Ты нашёл аномалию. Сервер вернул ошибку синтаксиса SQL при вводе кавычки. Это ещё не баг, за который платят. Это зацепка. Теперь тебе нужно доказать Impact (ущерб).

Что мы делаем:

Раскрутка уязвимости.

Была ошибка SQL? Напиши запрос, который вытащит версию базы данных (например, UNION SELECT @@version), а лучше — имя текущего пользователя БД. (Не сливай таблицы с данными пользователей, помни про правила!).

Был XSS? Напиши пейлоад, который не просто вызывает окошко alert (1), а ворует CSRF-токен или отправляет запрос на смену email-адреса жертвы.

Был SSRF? Попробуй обратиться к внутренним метаданным облака (например, http://169.254.169.254/latest/meta-data/ в AWS) и вытащить ключи доступа.

Обход защиты (Bypass). Если твой пейлоад блокирует WAF (Cloudflare, Qrator), не сдавайся сразу. Изучи техники обхода. Закодируй пейлоад (URL-encoding, Base64, Unicode), используй альтернативные HTML-теги для XSS, разбей SQL-запрос комментариями (UNI/**/ON).

Создание PoC (Proof of Concept). Это скрипт (обычно на Python) или чёткая последовательность действий в Burp Suite Repeater, которая гарантированно и без сбоев воспроизводит уязвимость. Твой PoC должен работать как швейцарские часы. Если триажер платформы не сможет его повторить, ты получишь статус N/A.

Этап 4. Отчёт (Reporting): Как продать свой взлом дорого

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

Структура идеального репорта (Золотой стандарт):

Title (Заголовок). Должен быть чётким. Формат: [Тип уязвимости] в [Эндпоинт/Функция] позволяет [Импакт].

Плохо: Нашёл баг на сайте.

Хорошо: IDOR в эндпоинте /api/v2/user_docs позволяет неавторизованному пользователю читать чужие паспорта.

Vulnerability Description (Описание уязвимости). Кратко объясни суть проблемы (2—3 предложения).

Steps to Reproduce (Шаги для воспроизведения). Это самая важная часть. Пиши так, будто объясняешь стажёру.

Шаг 1: Авторизуйтесь под пользователем А.

Шаг 2: Перехватите запрос на редактирование профиля в Burp Suite.

Шаг 3: Измените параметр user_id с 100 на 101.

Шаг 4: Отправьте запрос. Вы получите данные пользователя Б.

Proof of Concept (PoC). Приложи скриншоты (обязательно с видимым URL и реакцией сервера) или короткое видео (MP4/GIF). Приложи HTTP-запрос и ответ текстом.

Impact (Влияние на бизнес). Объясни, что будет, если этот баг найдёт хакер из даркнета. «Данная уязвимость позволяет злоумышленнику массово выгрузить персональные данные 100 000 клиентов, что приведёт к нарушению 152-ФЗ, оборотному штрафу и репутационным потерям для компании».

Remediation (Рекомендации по устранению). (Опционально, но сильно повышает лояльность). Напиши, как это исправить. Например: «Необходимо реализовать проверку прав доступа на уровне сервера (Access Control), проверяя, принадлежит ли запрашиваемый user_id текущей сессии».

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

Практическое задание

Собери свой первый Recon-pipeline.

Открой файл «Мой хакерский трек». Создай раздел «Мой Конвейер».

Если ты работаешь в Linux (Kali/Ubuntu) или MacOS, открой терминал.

Скачай и установи три базовых инструмента от ProjectDiscovery (они написаны на Go и ставятся одной командой, если у тебя установлен язык Go):

go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest

go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

Свяжи их в один пайплайн (однострочник):

Выбери публичную программу со Standoff 365, разрешающую сканирование (например, программу самого Standoff 365 или Give Me Public). Допустим, их домен — target.com.

Запусти команду: subfinder -d target.com -silent | httpx -silent -status-code -title | tee alive_subdomains. txt

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

Запиши в свой трек: сколько живых поддоменов ты нашёл? Какие из них возвращают 200 OK, а какие 403 Forbidden?

Это твой первый шаг к автоматизации. В следующей главе мы будем учиться, как превращать этот сырой список в репорты на $1000+.

Глава 4. Прокачка репутации на Bug Bounty

— Как писать репорты, чтобы не получить N/A

Давай представим рабочий день триажера (Triage Engineer) на платформе вроде Standoff 365 или BI. ZONE. Этот человек сидит на зарплате. В его очереди (queue) висит 150 новых репортов от багхантеров.

50 из них — это автоматический мусор со сканеров (отсутствие заголовка Strict-Transport-Security).

Ещё 40 — это попытки выдать фичу за баг («Я могу зарегистрировать 100 аккаунтов с одного IP! Платите мне за отсутствие Rate Limit!»).

Ещё 30 — это нечитаемый текст через Google Translate без скриншотов и внятных шагов воспроизведения.

Триажер устал. Он хочет закрыть смену и пойти пить пиво. И тут он открывает твой репорт. Твоя главная задача — сделать так, чтобы проверка твоего бага заняла у него ровно две минуты, после которых он с облегчением нажмёт кнопку «Triage» (Передано вендору на исправление).

Если триажер не понял твой баг за две минуты, если у него не получилось воспроизвести твой эксплойт с первого раза — он не будет разбираться. Он не будет звонить тебе и просить: «Слушай, бро, а какой пейлоад ты тут использовал?». Он просто нажмёт N/A (Not Applicable) или Needs More Info, и твой чек отложится на недели, а то и навсегда (если за это время баг найдёт кто-то другой).

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

1. Title (Заголовок): Продаём с первой строчки

Заголовок — это тема письма. Он должен мгновенно отвечать на три вопроса: Что случилось? Где случилось? Чем это грозит?

Ужасный заголовок: Уязвимость на сайте, SQL injection найдена, Я могу взломать вашего пользователя. Почему это плохо: Триажер не понимает приоритет. Он оставит этот репорт на потом.

Идеальный заголовок: [IDOR] Уязвимость в эндпоинте /api/v2/profile позволяет неавторизованному пользователю менять email любого клиента (Account Takeover). Почему это хорошо: Ты сразу назвал класс уязвимости (IDOR), указал точное место (/api/v2/profile) и продал импакт (Account Takeover — полный угон аккаунта). Этот репорт триажер откроет первым, потому что это критическая угроза (P1).

2. Summary (Резюме): Для ленивых менеджеров

Summary читает не только триажер, но и менеджер со стороны компании-заказчика, который будет согласовывать выплату. Этот человек может вообще не понимать технический сленг.

В Summary (2—3 предложения) ты должен объяснить суть проблемы простым языком.

Пример: «В ходе тестирования веб-приложения app.target.com была обнаружена уязвимость типа Insecure Direct Object Reference (IDOR). Приложение не проверяет права доступа при обновлении профиля пользователя. Это позволяет любому зарегистрированному клиенту (Attacker) изменить адрес электронной почты любого другого клиента (Victim), зная только его числовой ID. После смены email атакующий может запросить восстановление пароля и получить полный контроль над чужим аккаунтом.»

Всё. Никаких дампов HTTP-запросов на этом этапе. Только чистая бизнес-логика.

3. Steps to Reproduce (Шаги воспроизведения): Защита от дурака

Это ядро твоего репорта. Если шаги написаны криво — ты получишь N/A с комментарием «Не воспроизводится» (Can’t Reproduce).

Правило: Пиши шаги так, будто ты пишешь инструкцию для своей бабушки, которая первый раз открыла Burp Suite. Каждый клик, каждый перехваченный запрос, каждое изменённое значение должно быть задокументировано.

Пример идеальных шагов:

Зарегистрируйте два аккаунта на сайте target.com:

Account A (Attacker): [e-mail]

Account B (Victim): [e-mail] (запомните его User ID, например, 1054)

Авторизуйтесь под Account B, перейдите в раздел «Настройки» и убедитесь, что профиль работает штатно.

Откройте другой браузер (или приватное окно), авторизуйтесь под Account A.

Включите перехват трафика в Burp Suite (Intercept is On).

Нажмите кнопку «Изменить Email» в профиле Account A и введите [e-mail].

В Burp Suite поймайте POST-запрос к https://api.target.com/v1/update_email.

В теле JSON-запроса найдите параметр «user_id»: 1053 (ID Attacker) и измените его на «user_id»: 1054 (ID Victim).

Отправьте изменённый запрос (Forward).

Обратите внимание, что сервер вернул ответ 200 OK.

Обновите страницу профиля Account B — email успешно изменён на [e-mail].

Важно: Если твой эксплойт требует специфических настроек (например, старой версии Firefox или отключённого JavaScript), обязательно укажи это в шагах.

4. Proof of Concept (PoC): Бетонные доказательства

Словам не верят. Верят логам.

В блоке PoC ты должен прикрепить сырые HTTP-запросы и ответы.

Пример:

POST /v1/update_email HTTP/1.1 Host: api.target.com Authorization: Bearer Content-Type: application/json

{«user_id»: 1054, «new_email»: "[e-mail]»}

И ответ сервера:

HTTP/1.1 200 OK Content-Type: application/json

{«status»: «success», «message»: «Email updated for user 1054»}

Скриншоты и Видео:

Прикладывай скриншоты из Burp Suite. Обведи красным маркером изменённый параметр в запросе и статус 200 OK в ответе.

Для сложных цепочек уязвимостей (Chained Bugs) всегда записывай короткое видео (до 1 минуты) без звука. Это снимает 99% вопросов у триажеров. Загрузи видео на защищённый хостинг (или прикрепи прямо в репорт на платформе). Ни в коем случае не выкладывай видео на публичный YouTube!

5. Impact (Влияние на бизнес): Как выбить максимальный чек

Триажеры и вендоры часто пытаются занизить уровень критичности уязвимости (Severity), чтобы сэкономить бюджет. Например, назвать IDOR не High, а Medium, потому что «ну это же нужно знать ID пользователя, его сложно угадать».

Твоя задача в блоке Impact — доказать, что баг смертельно опасен. Переведи техническую ошибку в деньги и юридические риски.

Пример: «Данная уязвимость позволяет полностью скомпрометировать аккаунт любого клиента платформы. Поскольку User ID является последовательным целым числом (Sequential ID), атакующий может написать простой скрипт на Python и за 10 минут изменить email у всех 50 000 зарегистрированных пользователей, перехватив их аккаунты. Это приведёт к:

Массовой краже персональных данных (нарушение 152-ФЗ и GDPR).

Полной остановке бизнес-процессов платформы.

Огромным репутационным и финансовым потерям.»

Когда безопасник компании читает такой Impact, он понимает, что не может закрыть репорт как Informative. Он обязан выдать тебе премию по максимальному тарифу.

6. Remediation (Рекомендации): Бонус в карму

Это не обязательно, но если ты напишешь, как исправить баг, вендор может накинуть тебе бонус (Bounty Bonus) просто за сэкономленное время разработчиков.

Пример: «Не доверяйте параметру user_id, передаваемому со стороны клиента (Client-Side). Для обновления данных профиля берите ID пользователя исключительно из валидного JWT-токена (Server-Side сессии).»

Почему репорты всё равно получают N/A? (Чеклист самопроверки)

Прежде чем нажать кнопку «Submit», проверь свой репорт по этому списку:

Баг действительно в Scope? Точно ли домен blog.target.com разрешён к тестированию?

Это реальная уязвимость, а не фича? Отсутствие лимита на количество символов в поле «О себе» — это не баг, если оно не приводит к отказу в обслуживании сервера (DoS).

Требуется ли взаимодействие с пользователем (User Interaction)? Если твой XSS работает, только если жертва сама вставит вредоносный код в консоль разработчика (Self-XSS) — это 100% N/A. Тебе за это не заплатят. Эксплойт должен работать без участия жертвы (или с минимальным участием, например, клик по ссылке).

Не сломал ли ты реальные данные? Если ты для демонстрации SQLi удалил (DROP) таблицу пользователей в продакшене — ты получишь не баунти, а повестку в суд. Всегда используй команду SELECT (чтение), а лучше SLEEP (10) (задержка по времени) для безопасной демонстрации.