Когда говорят про recon в Bug Bounty, обычно вспоминают subfinder, httpx, поиск директорий, JS‑файлы и огромные списки URL. Всё это действительно используется. Но проблема в том, что сам по себе список из нескольких тысяч поддоменов почти ничего не даёт.

Главный вопрос начинается после сбора информации: что из этого действительно заслуживает внимания и почему?


Для меня recon — это не отдельный этап перед поиском уязвимостей.
Это постоянный процесс построения модели приложения: как оно устроено, какие сервисы существуют, зачем они нужны, как общаются между собой и где поведение системы отличается от ожидаемого.

1. Выбор программы — это тоже Recon

Я начинаю не с инструментов, а с самой программы. Сначала читаю policy: scope, выплаты, запрещённые действия, особенности тестирования и пожелания компании.


При выборе программы я обычно смотрю сразу на несколько вещей:

  • насколько хорошо я понимаю сам сервис

  • насколько активна программа и что находят другие исследователи

  • какие там выплаты и насколько оправданы затраты времени

  • что пишут исследователи о триаже и работе программы

  • насколько сама компания и её инфраструктура мне интересны

Количество репортов тоже не стоит воспринимать буквально. Малое число багов не означает автоматически, что программа «пустая». Возможно, там жёсткий scope, сложный триаж или огромное количество исключений. И наоборот, популярная программа может быть интереснее именно потому, что её постоянно исследуют другие люди: по их находкам можно понять, какие части инфраструктуры вообще имеют смысл изучать.

Нет также большого смысла тратить двадцать часов на систему, если потенциальная отдача минимальна и при этом она тебе вообще неинтересна. Bug Bounty — достаточно длинная игра, поэтому мотивация тоже является частью выбора цели.

2. Разведка — это не список поддоменов

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

При этом полностью отказываться от автоматизированного сбора информации тоже нельзя. Инфраструктура постоянно меняется: какие‑то домены появляются, какие‑то выключаются, старые сервисы снова становятся доступными.
Мне важна именно актуальная картина внешней инфраструктуры.


Я смотрю не только на результаты обычного passive subdomain discovery. Использую Censys, Shodan, Google и другие источники, чтобы понять:

  • какие домены и сервисы вообще существуют

  • какие из них работают постоянно

  • какие появляются или исчезают периодически

  • как разные части инфраструктуры связаны между собой

Например, периодически включающийся домен может заставить задать вопрос: почему он вообще существует и чем отличается от основной production‑инфраструктуры?

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

Например:

Большинство просто пропустит такой PNG. Но у меня сразу появляется несколько вопросов:

почему records? Что такое alabam? Что изменится, если заменить 5 на 4? Является ли records каким‑то S3 bucket?

Важен не сам PNG — важна цепочка вопросов, которую он запускает.

3. Нужно понять архитектуру, а не просто найти endpoint

Начиная изучать приложение, мне интересна не только конкретная страница или API.

Я постепенно уменьшаю масштаб: от общей архитектуры к конкретному сервису, затем к отдельному endpoint. В этот момент постоянно возникает один вопрос: как эта "ручка" вообще пашет?

Например, есть сервис авторизации. Тогда интересно не только наличие /login, а то:

  • как он создаёт сессию

  • какие параметры передаёт дальше

  • какие данные добавляет в запросы

  • кому и чему он доверяет

  • можно ли повлиять на дальнейшее поведение через эти данные

Получается примерно такая модель:


И дальше возникает уже более интересный вопрос:

кто здесь слабое звено?

Может оказаться, что напрямую обратиться к B нельзя, но A имеет к нему доступ и может передать туда данные. Тогда граница доверия между сервисами становится отдельной точкой исследования.

JS в этом процессе тоже полезен. Он помогает понять логику, но довольно часто именно непосредственное взаимодействие с endpoint показывает реальное поведение системы.

4. Ищи аномалии, а не названия уязвимостей. HackerOne Case

Одна из самых частых ошибок — увидеть знакомый паттерн и сразу назвать его уязвимостью.

Все начинается с непонятного endpoint или случайно найденного функционала. Именно того, что выбивается из общей нормальной картины.

Полный отчёт: #3578842 — SQL Injection vulnerability found on ibm.com endpoint

Во время recon я наткнулся на скрытый функционал, который вообще не был похож на обычную production‑часть приложения.

Скорее он выглядел как какой‑то старый тестовый или legacy‑сервис. Начал смотреть, что там вообще есть и какие параметры принимает endpoint.

Один из GET‑параметров показался интересным, поэтому решил просто покидать в него разные значения. В какой‑то момент обычная кавычка начала стабильно приводить сервер к 500 Internal Server Error. Сам по себе 500, конечно, ещё ничего не значит, но стало понятно, что параметр как‑то влияет на backend. Дальше уже появилась гипотеза про SQL Injection.

Запустил sqlmap — он подтвердил time‑based SQLi. Но понятное дело, если запускать автоматизированную утилиту без специльного rate limit, delay, tamper scripts, то это это приведет только к потраченному времени.

Аномалия — это скорее сигнал: я сделал что‑то, чего приложение, возможно, не ожидало. Дальше начинается проверка гипотезы разными схемами.

5. Насмотренность появляется не из чеклистов

Самый сильный буст в этом плане даёт первая настоящая находка.

В лаборатории Burp Suite ты знаешь, что где‑то существует уязвимость, и твоя задача — её найти. В реальном Bug Bounty ты можешь часами смотреть на систему и вообще не знать, есть ли там что‑нибудь интересное.
Поэтому большое количество гипотез, которые никуда не приводят, — это нормальная часть процесса.

Иногда 50–80% идей не развиваются в валидный баг. Но именно они постепенно учат не искать готовый ответ в интернете, а самостоятельно строить гипотезы:

  • изменить параметр

  • попробовать другой endpoint или HTTP‑метод

  • связать два сервиса

  • проверить другое состояние приложения

  • посмотреть, что произойдёт при неожиданных входных данных

Со временем у конкретной программы появляется собственная «насмотренность».

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

6. В Bug Bounty важнее Impact, чем название баги

Bug Bounty нельзя полностью приравнивать к пентесту. В пентесте ты можешь пройтись по определённой методологии и проверить конкретные классы уязвимостей.

Конечный вопрос немного другой: что опасного может сделать атакующий с помощью найденного поведения?

Одна проблема может пересекаться сразу с несколькими категориями уязвимостей. Но для триажа это не означает автоматически несколько отдельных находок. Важнее реальное влияние на безопасность компании.


Нельзя начинать с вопроса «какая это уязвимость?». Сначала интереснее спросить:

Что изменилось в поведении системы и что это позволяет сделать?

В Bug Bounty полезно не останавливаться на первом найденном поведении. Если оно действительно интересно, стоит попробовать понять, куда ещё оно ведёт и можно ли доказать реальный security impact / выстроить чепочку.

7. Recon никогда не заканчивается

Я не воспринимаю recon как этап, который можно однажды закончить и поставить галочку.

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

Процесс получается примерно таким:

Поэтому на знакомую программу тоже приходится периодически возвращаться.
Инфраструктура меняется, сервисы включаются и выключаются, появляются новые endpoints, меняется логика приложения. То, что месяц назад выглядело бесполезным, сегодня может стать частью интересной цепочки.

В Bug Bounty ты постоянно пытаешься ответить на один вопрос: почему приложение ведёт себя именно так? Если на него получается ответить — дальше часто находится и то, что действительно стоит отправлять в репорт.