Привет, Хабр! На связи Сергей Зыбнев aka poxek. Начинал свой путь в пентесте как сисадмин, потом заведовал WAF в «МТС», затем несколько пентестерских компаний, а теперь работаю в «Бастионе» и профессионально ломаю то, что раньше защищал. Последние четыре года веду Telegram-канал «Похек», где рассказываю про найденные уязвимости и про то, как можно было предотвратить их эксплуатацию.
В этой статье — главные инструменты для поиска уязвимостей, которые я использую в ежедневной работе. Это не подборка ради подборки: для каждого инструмента приведу пример из собственной практики, чтобы было понятно, где и как их применять.
Если хотите понять, какие инструменты выбрать и как эффективно применять их в реальных пентестах, — эта статья вам пригодится!
Если вы тоже только начинаете в багбаунти — посмотрите, как стартовали ребята из Standoff Bug Bounty. Для тех, кто уже в теме, будет полезна статья Олега Уланова про эксплуатацию SSRF — там куча рабочих инструментов и методик.
Отдельно стоит почитать про Broken Access Control — один из самых распространенных классов уязвимостей. В посте разобраны типовые сценарии и неочевидные проявления этих багов.
А теперь самое интересное — разберем 10 основных рабочих инструментов для старта в багбаунти и посмотрим, как они работают, на реальных примерах.
Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных деяний. Наша цель — рассказать о существующих уязвимостях, которыми могут воспользоваться злоумышленники, предостеречь пользователей и дать рекомендации по защите своей личной информации в Интернете. Авторы не несут ответственности за использование информации. Помните, что не стоит забывать о безопасности своих личных данных.
Burp Suite — универсальный инструмент для тестирования
Давайте начнем с главного инструмента — Burp Suite. Это must have для любого, кто работает с веб-приложениями. Burp Suite давно стал монополистом в этой сфере. Все начинали с Community Edition — бесплатной версии с ограничениями. Там нельзя сохранять проекты, что неудобно при долгой работе.
Professional Edition решает эту проблему, но даже в платной версии Burp забирает много оперативной памяти (может съедать до 30 ГБ) и периодически крашится на больших проектах.
Еще один нюанс: некоторые плагины недоступны в бесплатной версии. Например, стандартный логгер иногда не находит нужные запросы, хотя они есть. Проблема решается установкой Logger++, но он ощутимо нагружает систему.
OWASP ZAP — open-source-альтернатива Burp
Когда Burp по каким-то причинам не подходит, многие обращаются к OWASP ZAP. Этот open-source-инструмент вызывает неоднозначную реакцию: кто-то снисходительно улыбается при его упоминании, а кто-то активно использует в работе.
Главное преимущество ZAP — возможность работы в headless-режиме через API, которая делает его популярным выбором для автоматизированного тестирования. В отличие от Burp, который в основном работает через GUI, ZAP легко интегрируется в CI/CD-пайплайны. Это особенно ценно для команд AppSec, где многие решения как раз построены на этом инструменте.
ZAP поддерживает сохранение проектов в любом формате и обладает практически всей функциональностью Burp, за исключением, пожалуй, экосистемы плагинов. Хотя некоторые считают его «недостаточно production-ready», для определенных сценариев он может быть даже удобнее Burp — особенно когда нужно что-то быстро доработать или кастомизировать под конкретные задачи.
Конечно, автоматизация в ZAP тоже требует некоторых усилий, но это уже тема для отдельного разговора. Главное — помнить, что в арсенале багхантера всегда должны быть разные инструменты для разных ситуаций.
Caido — новый инструмент для багхантеров
Среди новых инструментов, появившихся за последние пару лет, Caido — мой личный фаворит. Во-первых, это облачный инструмент. Вы можете развернуть Caido как локальный сервер и работать удаленно. Несколько членов команды могут одновременно подключаться к одному проекту, что особенно удобно для совместной работы.
Во-вторых, Caido сохраняет проекты автоматически, избавляя от головной боли, которую испытываешь от Burp с его внезапными падениями. Интерфейс интуитивен и современен: не приходится разбираться в архаичных меню, как в некоторых старых инструментах.
Пока Caido не обладает всей мощью того же Burp Suite, но активно развивается. Для определенных задач — особенно при командной работе — он уже сейчас может стать отличным выбором.
Практика: тестируем на реальных примерах
Мы столкнулись с интересным кейсом во время тестирования одного сайта на Next.js. При попытке доступа к админ-панели система стабильно возвращала 403 Forbidden и перенаправляла на страницу входа. Казалось бы, тупик, но именно в такие моменты проявляется истинное мастерство багхантера.
Через Burp Suite мы перехватили запрос к защищенному разделу и начали экспериментировать. Вспомнили свежую уязвимость в Next.js под названием Middleware Bypass. Эффект был мгновенным: вместо привычной ошибки 403 сервер вернул статус 200 и содержимое админ-панели. Оказалось, фреймворк считал такие запросы внутренними и пропускал их без проверки прав доступа.
Настоящая магия началась, когда мы настроили автоматическую обработку запросов через Match and Replace в Burp. Теперь все обращения к /admin автоматически получали нужный заголовок, а в ответах подменялись критически важные параметры вроде isAdmin:false на isAdmin:true. Правда, после этого нас ждал сюрприз: админка загрузилась, но функциональные кнопки оставались неактивными. Проблема решилась после тщательного анализа дополнительных API-вызовов через плагин Logger++.
Этот случай наглядно подсветил несколько важных моментов. Во-первых, даже современные фреймворки вроде Next.js могут содержать неочевидные уязвимости. Во-вторых, без инструментов автоматизации вроде Burp Suite подобные исследования заняли бы в разы больше времени. И главное: настоящий успех часто требует анализа не только первоначального запроса, но и всей цепочки последующих взаимодействий.
FFUF — быстрый и удобный фаззинг
Когда речь заходит о фаззинге, многие сразу вспоминают FFUF — действительно быстрый и удобный инструмент. Хотя лично я последнее время им почти не пользуюсь (лень каждый раз вспоминать синтаксис), нельзя отрицать его эффективность для поиска скрытых параметров и директорий.
На практике FFUF особенно хорош:
для быстрого перебора поддоменов;
поиска скрытых GET- и POST-параметров;
фаззинга различных HTTP-методов.
Но есть и недостатки:
Долго не обновлялся.
Может некорректно работать при сложной фильтрации (когда одновременно применяешь фильтры по словам, размеру ответа и количеству строк).
Не всегда справляется с длинными URL.
Из интересных кейсов: коллеги как-то использовали Ferox Buster (альтернативу FFUF) и пропустили критически опасную уязвимость — эндпойнт, который вываливал кучу чувствительных данных. Фильтр отсеял его из-за стандартного кода ответа, хотя по содержимому это был настоящий «крит». Пришлось среди ночи созваниваться и экстренно править отчет.
Практика: ищем скрытые директории с помощью FUFF
Давайте разберем реальный пример использования FFUF на учебном стенде Fufflab (специально созданный мною стенд для тренировок). Главная фишка этого стенда: среди множества стандартных директорий спрятаны несколько действительно интересных мест, которые стоит найти.
При работе с FFUF важно правильно подойти к настройке. Во-первых, используйте свежие словари: те, что идут по умолчанию в Kali Linux, часто устаревают. Лучше брать актуальные версии с GitHub. Во-вторых, не забывайте про фильтрацию: можно отсеивать результаты по коду ответа, размеру данных или количеству слов. И главное — не перегружайте целевой сервер, особенно на реальных проектах. Сорок потоков — это слишком много, лучше ограничиться тремя–пятью.
Во время тестирования мы столкнулись с любопытной аномалией. Запрос к /admin возвращал стандартные 404, но с задержкой в полторы секунды вместо обычных 30 миллисекунд. Такие неочевидные признаки часто указывают на скрытую логику работы приложения. Дальнейший анализ подтвердил наши подозрения: обнаружилась интересная уязвимость в обработке таких запросов.
Из полезных фишек FFUF отмечу рекурсивный поиск и возможность ставить сканирование на паузу. Кстати, последнее я обнаружил случайно: просто нажал Enter во время работы инструмента. Для комплексного тестирования рекомендую пробовать разные варианты: проверять не только основные пути, но и возможные поддиректории, даже если они кажутся малоперспективными. Иногда самые интересные находки прячутся там, где их меньше всего ожидаешь увидеть.
Важный момент: всегда следите за реакцией целевой системы. Если провайдер вдруг отключит интернет во время тестирования (а такие случаи в моей практике бывали), это явный сигнал, что вы переусердствовали с нагрузкой. На реальных проектах лучше заранее предупреждать администраторов о проводимых работах.
GAU — сбор URL для тестирования
В последнее время GAU стал вести себя нестабильно: во время моих тестов он попросту перестал нормально работать. Единственное место, где мне удалось получить хоть какие-то результаты, это тестовый стенд Standoff.
Основная фишка GAU — агрегация данных из различных веб-архивов, включая Common Crawl и Wayback Machine. Но на практике количество найденных URL часто оказывается крайне низким. При этом важно помнить про ключ subs, если вам нужны не только основные пути, но и поддомены, по умолчанию эта функция отключена.
Для работы в рамках одного домена (без поддоменов) GAU может быть полезен, особенно при тестировании wildcard scope. Здесь он неплохо справляется с поиском разнообразных путей и директорий. Однако в текущем состоянии инструмент выглядит скорее как дополнительный вариант, чем как основное средство сбора информации.
Альтернативой может стать комбинация ручного тестирования с другими инструментами разведки. Особенно актуально это, когда GAU отказывается работать как положено. В целом идея инструмента хороша, но реализация в последних версиях вызывает вопросы.
Katana — краулер от ProjectDiscovery
В арсенале ProjectDiscovery есть действительно полезный инструмент — Katana. В отличие от GAU, он показывает себя куда более стабильно и эффективно, особенно при использовании ключей -d (глубина поиска) и -jc (извлечение ссылок из JavaScript). На практике Katana находит значительно больше полезных данных, что делает его незаменимым для разведки.
Правда, есть и нюансы: иногда инструмент включает в результаты совершенно посторонние домены, которые просто упоминаются в JS-файлах. Эти ложные срабатывания могут не соответствовать даже заданным регулярным выражениям, поэтому результаты всегда нужно перепроверять вручную. Особенно это актуально при тестировании закрытых систем с авторизацией, где функциональность ограничена, но Katana все равно пытается вытянуть максимум информации.
Из полезных фишек — возможность сохранять результаты в файл через параметр -output. Я всегда добавляю в название файла имя инструмента (например, «target_katana.txt»), чтобы потом было проще анализировать данные. Эти сохраненные результаты особенно пригодятся для следующего этапа тестирования, когда мы будем использовать собранные URL для более глубокого анализа.
Главное преимущество Katana — его способность заглядывать туда, куда обычные краулеры не добираются. Благодаря анализу JavaScript он находит скрытые эндпойнты и API-вызовы, которые часто становятся источником интересных уязвимостей. Хотя и здесь важно соблюдать баланс: слишком большая глубина сканирования (параметр -d) может привести к огромному количеству лишних URL.
Для багбаунти Katana подходит идеально, но требует последующей ручной фильтрации результатов. Лучшая стратегия — комбинировать его с другими инструментами разведки, чтобы получить максимально полную картину тестируемого приложения.
URLFinder — ищем URL в коде сайтов
В ProjectDiscovery появился свежий инструмент — URLFinder, который сейчас находится в версии 0.0.3. Это действительно новинка: я начал тестировать его еще в версии 0.0.1, и с тех пор изменения минимальны. На практике URLFinder показывает себя довольно интересно — по ощущениям, он находит немного больше ссылок по сравнению с другими инструментами, хотя это может быть связано с особенностями работы с внешними сервисами, где возможны тайм-ауты или ограничения доступа.
При тестировании стенда URLFinder выдал около 7000 ссылок — впечатляющий результат. Как и в Katana, здесь есть возможность сохранять результаты через параметр output, что очень удобно для последующего анализа. Особенно полезно искать в этих данных ключевые слова вроде «api»: такой простой grep часто выявляет любопытные эндпойнты, которые стоит проверить в первую очередь.
Интересный момент: среди найденных URL иногда попадаются совершенно неожиданные ссылки. Это могут быть старые версии API, забытые тестовые эндпойнты или даже критически опасные уязвимости. Например, на том же стенде обнаружилась странная апишка, связанная с аутентификацией, и какие-то user-аватарки — такие находки всегда заслуживают дополнительной проверки.
Хотя инструмент новый и сыроват, он уже сейчас может быть полезен в связке с другими утилитами. Главное — не забывать фильтровать результаты, убирая мусорные ссылки на картинки и прочий нерелевантный контент. Для этого можно использовать простые скрипты или даже стандартные grep/awk.
URLFinder хорош для первоначальной разведки, когда нужно быстро собрать максимальное количество потенциально интересных URL. А уже потом можно заняться их детальным анализом, проверяя каждый на предмет уязвимостей.
Naabu + HTTPX — скан портов + проверка HTTP
Перейдем к двум полезным инструментам от ProjectDiscovery — Naabu и HTTPX. Naabu представляет собой современный сетевой сканер, альтернативу классическому Nmap. Главное его преимущество — скорость работы и отсутствие ложных срабатываний. В отличие от Nmap, который иногда ведет себя недружелюбно (известны случаи, когда он случайно запускал печать на сетевых принтерах), Naabu работает аккуратно и выводит результаты в простом формате «IP-адрес:порт», что удобно для дальнейшей обработки.
HTTPX — это мощный инструмент для отправки HTTP-запросов с гибкой настройкой. С его помощью можно:
задавать произвольные методы запросов,
добавлять кастомные заголовки и куки,
анализировать ответы сервера.
На практике я обычно запускаю HTTPX с множеством параметров, включая отображение статус-кодов, длины ответов, редиректов и технологий сервера. Это дает полную картину перед глазами и позволяет быстро находить интересные эндпойнты через grep.
Особенно полезной оказалась функция определения технологий (webtest detect), которая помогает идентифицировать неочевидные компоненты системы. Хотя стоит учитывать, что цветной вывод в консоли может создавать проблемы при копировании результатов: для совместной работы с коллегами лучше использовать флаг --no-color.
Для работы с поддоменами эти инструменты тоже подходят отлично. HTTPX позволяет быстро отфильтровать живые хосты, а Naabu — проверить их на открытые порты. Комбинация этих инструментов значительно ускоряет процесс разведки перед полноценным тестированием.
Subfinder + Finder + Sublist3r — поиск субдоменов
Для поиска субдоменов я использую связку нескольких инструментов — Subfinder, Finder и Sublist3r. Это позволяет получить полную картину для анализа, так как каждый инструмент использует разные источники данных. Сделал даже специального Telegram-бота для коллег, который принимает файл с корневыми доменами и возвращает уже проверенные через DNSX результаты, включая DNS-записи. Это значительно ускоряет первичную разведку.
Однако важно понимать ограничения: эти инструменты работают в пассивном режиме, собирая данные из различных источников вроде веб-архивов, сертификатов (CT logs) и других открытых баз. Активный режим, доступный в некоторых из них, часто работает нестабильно. Для активного сканирования лучше подходит PureDNS, который особенно хорош для работы с wildcard-доменами.
Столкнулся с интересным кейсом, когда wildcard-домен вообще не фильтровал запросы: на любой поддомен приходил валидный ответ. Это оказалась система динамических поддоменов типа «имя.компания.com». Ни стандартные методы фильтрации по размеру ответа, ни HTTPS-ошибки не помогали: пришлось все фильтровать вручную, что было крайне трудоемко.
Практические советы по работе с этими инструментами:
Всегда проверяйте найденные субдомены через DNSX: многие могут уже не существовать.
Комбинируйте несколько инструментов для более полного покрытия.
Для сложных случаев с wildcard-доменами используйте ручную фильтрацию.
Эти инструменты особенно полезны на начальном этапе тестирования, когда нужно максимально полно определить периметр атаки. Главное — не забывать, что пассивные методы могут давать устаревшую информацию, поэтому важные находки всегда стоит перепроверять.
Skanuvaty — автоматизация рутинных задач
Этот инструмент на Rust действительно выделяется среди аналогов своей скоростью работы и функциональностью. Skanuvaty сочетает в себе возможности активного фаззинга и брутфорса, что делает его универсальным решением для автоматизации рутинных задач исследования.
Ключевые особенности:
высокая производительность благодаря многопоточности (по умолчанию использует доступные ядра процессора);
поддержка больших wordlists (3 миллиона записей и более);
удобный JSON-вывод для последующего анализа.
На практике я обычно запускаю Skanuvaty с 10–30 потоками, в зависимости от мощности сервера и политики целевого сайта. Интересно, что на VPS облачных провайдеров инструмент почему-то работает медленнее — возможно, из-за ограничений DNS-запросов или сетевых параметров.
Интеграция в рабочий процесс:
Я автоматизировал работу со Skanuvaty через Telegram-бота, который по запросу:
запускает сканирование указанного домена,
парсит результаты в JSON,
предоставляет краткую сводку.
Для крупных проектов такая автоматизация особенно полезна: можно быстро оценить масштаб инфраструктуры (количество доменов, поддоменов) перед полноценным тестированием. В одном из кейсов мы доработали бота так, чтобы он сразу рассчитывал ориентировочную стоимость проекта на основе собранных данных.
Важный нюанс:
При активном сканировании возможны false positive/negative, поэтому критически важные находки всегда стоит перепроверять вручную. Skanuvaty — это мощный, но не идеальный инструмент, который лучше всего работает в комбинации с другими исследовательскими инструментами.
Check_bitrix + Quick-tricks
Когда вы сталкиваетесь с сайтом на «1С-Битрикс» (не путать с Bitrix24, это разные системы), эти инструменты становятся незаменимыми помощниками. CheckBitrix (на Python) и QuickTricks позволяют быстро находить типовые уязвимости в этой популярной российской CMS.
Какие проблемы они помогают выявить:
классические трояны XSS и OpenRedirect,
векторы для повышения привилегий до уязвимости RCE,
проблемы с конфигурацией доступа,
старые незапатченные уязвимости.
Особенно часто встречаются случаи, когда credentials, украденные с одного сайта на «Битриксе», работают и на других сайтах этой же CMS. Для комплексной проверки я рекомендую использовать специальный словарь директорий, который включает все возможные пути и файлы, характерные для «Битрикса».
Интересный кейс:
Как-то мы обнаружили low-privileged XSS, которая срабатывала, когда администратор заходил в определенный раздел админки. При этом для эксплуатации достаточно было простой регистрации на сайте: типичная проблема неправильной настройки прав доступа.
Важно:
Эти инструменты — отнюдь не волшебные палочки, а скорее помощники для первоначальной разведки. Для глубокого тестирования Битрикс-сайтов стоит:
изучить свежие гайды по пентесту,
комбинировать автоматические проверки с ручным тестированием,
особое внимание уделять кастомным модулям: там часто кроются самые интересные уязвимости.
DotGit + XnlReveal — секреты в Git и XML
Для поиска утечек через служебные директории — такие как .git, .svn или .env — я использую специализированные инструменты. Особенно хочу выделить XnlReveal — мощное, но малоизвестное расширение для браузеров.
Важные особенности XnlReveal:
Находит скрытые директории даже при частичной доступности (например, когда корень сайта отдает 404, но внутренние пути доступны).
Требует включения Developer Mode для установки.
Работает агрессивно, поэтому лучше использовать в отдельном пентестерском браузере.
Практическое применение:
В связке с GitDumper такие инструменты позволяют полностью скачивать содержимое .git-репозиториев. Это открывает огромные возможности:
доступ к исходному коду,
просмотр истории изменений,
обнаружение конфигурационных файлов с чувствительными данными.
Реальный кейс из практики:
Как-то через найденный .git мы вышли на внутренний GitLab, через утечку паролей получили доступ к нему, а через GitLab Runner добились RCE. Все благодаря тому, что Runner был запущен в shell-режиме, а не в докере — типичная ошибка настройки.
Рекомендации по использованию:
Всегда получайте разрешение перед использованием таких инструментов.
Проверяйте не только .git, но и другие служебные директории (.env, .svn и т. п.).
Сохраняйте найденные данные для последующего анализа.
Эти методы особенно эффективны против сайтов, где разработчики забыли закрыть доступ к служебным директориям. Часто такие находки становятся отправной точкой для серьезных компрометаций.
S3BucketList — ищем открытые бакеты
В завершение хочу упомянуть полезный инструмент для тестирования S3-хранилищ, который часто остается в тени. В моей практике было несколько случаев, когда через неправильно настроенные S3-бакеты удавалось получить доступ к важным файлам. Инструмент работает как браузерное расширение, анализируя трафик и проверяя права доступа к бакетам. Главное преимущество — что он не делает лишних запросов, а лишь проверяет разрешения для обнаруженных бакетов.
На скриншоте виден пример работы: один бакет доступен для листинга, другой закрыт. Иногда попадаются бакеты с правами на запись. Инструмент помогает быстро оценить потенциал для атаки, хотя дальнейшую эксплуатацию все равно нужно проводить вручную.
Важно понимать, что такие проверки должны проводиться только с разрешения владельца системы. Хотя инструмент и выглядит безобидным, его использование без авторизации может иметь юридические последствия.
Советы от poxek для начинающих
Главное, что я хочу донести: не существует единственно правильного пути в багхантинге. Все мои рекомендации — лишь результат моего личного опыта, и ваш подход может кардинально отличаться. Я знаю маркетолога, который находит уязвимость XSS на чистой интуиции, просто вставляя теги в поля ввода. Знаю коллег, которые работают вообще без инструментов, только через браузер. Суть в том, чтобы найти свой стиль.
Английский — это must have, потому что основные материалы все еще расположены на англоязычных ресурсах. Стало появляться больше и русскоязычного контента. Например, начинающим специалистам может пригодиться карта знаний из 15 шагов. Изучение материалов будет полезно для понимания базовых принципов поиска уязвимостей, необходимых для старта в этой области.
Мой главный совет — просто начать. Не ждите идеального момента. Багов становится больше, особенно с приходом вайб/AI-разработчиков, которые часто ошибаются.
И пожалуйста, не гонитесь за инструментами. Иногда простая внимательность ценнее сотни утилит. Пробуйте, ошибайтесь, анализируйте — ваш уникальный опыт и будет тем самым инструментом.