Охота на эксплойты: зачем и как это делать специалистам по ИБ

Для чего нам искать эксплойты? Это помогает защититься от потенциальных атак: чем раньше найдешь и разберёшься, как он работает, тем быстрее напишешь детектирующие логики на различные средства защиты информации, например: WAF, IDS. А они уже, в свою очередь, защитят компанию от возможных атак. Как говорится, предупреждён – значит, вооружён. Особенно важно отслеживать уязвимости в open-source-продуктах, используемых в инфраструктуре (таких в России сейчас много), так как их код является открытым для анализа и поиска уязвимостей, и множество энтузиастов практической безопасности ежедневно занимаются именно этим. В этой статье мы разберем, как и где искать эксплойты и какие подводные камни могут встретиться на этом пути. Если вы только начинаете карьеру специалиста по корпоративной защите, то статья будет полезной!

NIST

Первый источник, о котором, наверное, слышали все — это NIST (Национальный институт стандартов и технологий США). Он является отправной точкой поиска. Но что может дать NIST, кроме на первый взгляд непонятного технического описания уязвимости, маркера критичности, CWE, распределения вектора атаки и прочих метрик? Ответ: ссылки на источники. Особенно если уязвимость найдена в open-source-решении. Какие источники могут помочь? Конечно, лучшей практикой будет ознакомиться со всеми приложенными источниками, но пристальное внимание стоит уделить ссылкам на коммиты исправлений, GitHub-репозитории, и источникам, содержащим идентификатор GHSA (GitHub Security Advisory). Выглядит он так: GHSA-xxxx-xxxx-xxxx и помогает в случаях, когда PoC не имеет отдельного репозитория на GitHub, но может иметь ссылку с GHSA идентификатором с детальным описанием и доказательством уязвимости.

Небольшой пример:

CVE-2026-42048 Уязвимость в Langflow. NIST дает всего один источник с тем самым идентификатором GHSA.

Если перейти на источник, мы сразу получим готовую PoC-концепцию. Это готовое основание для создания детектирующей логики.

Исследователи и Telegram-каналы

Больших команд и частных исследователей безопасностей в мире ИБ немало, и они являются ценнейшими источниками данных об эксплойтах. Как только вы начнете заниматься поиском, вы очень скоро наткнетесь на подобные статьи и составите свой список избранных. Для примера рассмотрим статью об CVE-2026–41940 в cPanel от watchTowr Labs (центра экспертизы по наступательной безопасности).

В статье они детально описывают причины уязвимости с демонстрацией уязвимого кода, описывают логическую цепочку, в результате которой удалось выполнить RCE. Так же к публикации приложены HTTP запросы и ссылка на их PoC-эксплойт.

Другой пример – CVE-2026–41873 в Apache Pony Mail. Star labs сделали обзор с инструкцией для моделирования. Все это – готовая основа для детектов!

Следить за обновлениями статей от подобных авторов, также является полезной практикой. Впрочем, у подобных статей есть негативный для специалистов в области информационной безопасности эффект: если публикация набирает большой резонанс (например, если уязвимость обнаружена в популярном продукте), это приводит к появлению еще большего числа эксплойтов. Новые эксплойты зачастую представляют собой не просто proof-of-concept, а полноценные инструменты с функциональностью обхода СЗИ. То есть работы у “защитников” прибавляется.

Исследователи безопасности часто публикуют полезную информацию в своих собственных каналах в Telegram, а кроме того, существуют каналы-аккумуляторы полезной информации. У каждого “охотника” за уязвимостями список полезных каналов свой, и нарабатывается он со временем. Примеры довольно популярных каналов: Proxy bar и Freedom Fox.

GitHub

GitHub – наверное, самый обильный источник эксплойтов и PoC. Как искать на GitHub? Можно поступить несколькими методами:

1. Поиск по конкретной CVE.

2. Парсинг всего GitHub через API запросы c применением фильтров.

3. Парсинг GIT на основании новых записей в NIST.

Если с поиском по конкретной CVE все понятно, (наткнулись на CVE, ввели эту CVE в поисковую строку GitHub, получили результат), то с другими методами немного сложнее. В ручном режиме собирать и обрабатывать информацию – довольно скучное занятие, особенно если за день было создано более десятка репозиториев, посвященных той или иной уязвимости. Усложняет этот процесс еще то, что на одну уязвимость может приходиться несколько репозиториев. Например, на CVE-2026–41940 на сегодняшний момент приходится более сорока (40!) репозиториев. Поэтому на помощь приходят языки программирования. Проще всего использовать Python в паре с библиотеку requests. В интернете достаточно много информации о том, как написать простой парсер. Но если структурно описывать, то шаблон такой:

• импортируем библиотеку requests

• -> задаем ей URL API конечной точки https://api.github.com/search/repositories

• -> задаём нужные фильтры

• -> отправляем запрос

• -> обрабатываем ответ.

Но если самому писать и парсить лень, то можно воспользоваться мудростью “кто-то наверняка уже сделал это за меня.

Например, Sploitus или Exploit DB занимаются подобной агрегацией. У коллег из PT есть собственный инструмент с похожей функциональностью. Так же есть отдельные репозитории (пример) на самом GitHub . Другими словами, готовые инструменты есть, нужно лишь выбрать понравившийся, но лучше быть независимым и написать свое!

Google

Google-поиск или любая другая поисковая система, как бы банально это ни звучало, могут стать источником полезной информации о конкретных эксплойтах, Главное – заглядывать глубже первой страницы выдачи, где могут быть скрыты обзоры уязвимостей на иностранных ресурсах, например, – от азиатских исследователей. Поиск в Google можно прокачать, используя google dorks.

Google Dork — это специальный поисковый запрос, использующий расширенные операторы. Он позволяет находить скрытую, конфиденциальную или труднодоступную информацию.

Например так: "CVE-2026-45321" site:github.com что бы ваш запрос искался только на github.com, без лишнего шума.

“Экзотические” источники данных

Ценную информацию об эксплойтах можно найти и в совсем неочевидных источниках:

• YouTube – там иногда попадают записи реальных демонстраций эксплуатаций уязвимостей, которые можно использовать для создания логик. Вот пример: CVE-2026-22812.

• X – может стать хорошим триггером для проверки наличия эксплойтов. Например, если аккаунт Fofa в своем X, сообщает о большом количестве уязвимых хостов к какой-то CVE, то стоит проверить эту CVE на GitHub.

• LinkedIn, Reddit — исследователи публикуют анонсы своих находок на самых разных площадках. Полезно мониторить хэштеги типа #CVE, #bugbounty, #exploit.

Подводные камни

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

NIST

Из-за большой загруженности NIST, эксплойт на CVE может выйти раньше, чем появится запись в NIST. Это не редкость, особенно это касается различных XSS-уязвимостей или уязвимостей невысокого уровня критичности. У них даже появилось специальное предупреждение:

Пример:

Поэтому, если на NIST информации об уязвимости нет, это не значит, что уязвимости вообще нет. Стоит перепроверить в других источниках.

GitHub

У GitHub как источника информации об эксплойтах есть сразу несколько особенностей, которые стоит иметь ввиду при поиске. Например, не все эксплойты являются эксплойтами, которые можно использовать в создании защиты:

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

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

3. Иногда код может всего лишь эмулировать уязвимость. Так было с React2shell: первые PoC репозитории представляли собой лабораторные стенды, в коде которых была внедрена exec () функция, выполняющая RCE. Реальный PoC с загрязнением прототипов вышел позже.

4. Иногда код может не работать – по разным причинам, например, вы нашли репозиторий слишком рано, а исследователь все еще его разрабатывает.

5. Существуют эксплойты которые действительно эксплуатируют уязвимость, но используют вас как бота. Вы запускаете эксплойт, например для сканирования своей инфраструктуры, а информация об этом со всеми деталями отправляется автору эксплойта, например, в Телеграм.

6. Не все эксплойты являются конечным вариантом реализации инструмента, эксплуатирующего уязвимость.

   Проще объяснить на простом примере.

   Представим, что у нас есть конечная точка, которая принимает параметр file содержащим имя файла, сервер обрабатывает его и выполняет cat имя файла. Добавив ; мы можем выполнить дополнительный код. Классическая RCE, но мы же можем заменить ; на & или на | или на %00 и так же выполнить дополнительный код. Чаще всего PoC эксплойты представляют из себя минимальную рабочую версию необходимую для эксплуатации. Они могут не учитывать, например, возможность обфускации.

7. Авторы эксплойтов могут ошибаться в названиях CVE. Путать последовательность цифр, вместо “–“ использовать 0, дописывать лишние 0 и так далее.

8. Авторы эксплойтов могут создавать тестовые репозитории, например для тестирования какой-то концепции.

   Интересный пример из практики. Однажды мы обнаружили репозиторий, который имел название несуществующей CVE - CVE-2025-99999. Репозиторий представлял собой простой readme-файл, содержащий ссылку на внешний IP-адрес. Если перейти по ней, можно было увидеть простое сообщение: “я учусь программировать помоги мне с этим” и новая ссылка. Таких ссылок было несколько, с постепенно усложняющимися заданиями, конечным заданием была задача скопировать токен и передать его на внешний ресурс. Получилось ли реализовать атаку мы не знаем, но репозиторий сейчас удален. По нашему мнению, данный проект существовал для того, чтобы заставить ИИ-агента выполнить вредоносное действие (выполнить на сервере код, который передал бы токен), а репозиторий использовался в качестве платформы для этого.

9. Не покупайте эксплойты. Часто встречаются репозитории ссылкой на покупку эксплойта. Обычно эти эксплойты направлены на максимально критичные CVE найденные у очень популярных вендоров, например Citrix, Fortinet, Azure, Oracle и т.д. Гарантии что вы купите рабочий эксплойт нет.

Полезные советы по поиску эксплойтов

За годы в threat-hunting мы выработали несколько лайфхаков, которые помогают нам искать информацию об уязвимостях, которую можно применить для защиты. Вот они:

1. Моделируйте все, что можете моделировать. Если продукт open-source, то на странице проекта есть релизы, из которых можно взять docker-compose файл, который поможет протестировать эксплойт. Так же уязвимую версию можно “загуглить” или найти на том же GitHub, некоторые авторы PoC репозиториев прикладывают уже готовый docker-compose файл для тестирования.

   Обратите внимание что разработчики могут использовать docker-compose файл с установленным значением версией - latest. При развертывании такого файла установится последняя версия проекта.

2. Анализ кода эксплойта: какой вектор эксплуатируется, какая полезная нагрузка передается, какие параметры используются и тд. Для Web в python-эксплойтах характерны библиотеки requests, asyncio, иногда sockets. Также встречались эксплойты? которые запускали curl-запрос через библиотеку sys. Через ctrl+F можно искать вхождения методов get, post и т.д. Все это помогает понять, какие HTTP-запросы формирует скрипт, какая у них последовательность и где именно передается нагрузка.

3. Захват трафика реально помогает разобраться, как работает эксплойт, и написать детектитующую логику. Как это можно сделать:

   • Прописать в самом коде эксплойта proxy, например локальный proxy burp suite.

   • Удалить из кода лишние проверки, оставить часть, где отправляется запрос с эксплуатацией, в качестве сервера можно использовать nginx плюс tcpdump или wireshark для захвата трафика.

4. Большинство AI сервисов, наподобие DeepSeek, ChatGPT, спокойно соберут вам HTTP-запрос из любого кода. Сложности могут возникнуть только если запрос большой и содержит много обфусцированной информации. Они также могут собирать и корректировать docker-файлы.

5. Ведение таблицы с проанализированными PoС это поможет в дальнейшей аналитике и избавит от повторного просмотра репозиториев и сделает работу более структурированной.  

6. Клонироуйте PoC/exploit репозиториев на CVE, которые вы откладываете в бэклог, потому что репозитории могут быть удалены.

Надеемся, наши советы помогут вам лучше искать эксплойты и быстрее писать качественные детектирующие правила! Удачной охоты!

Команда центра исследования киберугроз Solar 4RAYS

Еще больше полезных материалов по теме читайте в блоге Solar 4RAYS