Статья CVE эксплойт разработка: полный цикл от публикации уязвимости до рабочего шелла — методология и инструменты 2025–2026

Исследователь безопасности со спины за тёмной рабочей станцией с двумя мониторами. Экраны светятся зелёным терминалом и янтарным дизассемблером, отбрасывая синеватый отсвет на капюшон.


В 2025 году 28,96% уязвимостей из каталога Known Exploited Vulnerabilities эксплуатировались в день публикации CVE или раньше. Вдумайтесь: атакующий уже внутри, а защитник ещё advisory не дочитал. По данным VulnCheck - 884 подтверждённых случая за год. Unit 42 фиксирует: сканирование на свежую CVE стартует через 15 минут после появления записи. А CrowdStrike замерил среднее время латерального перемещения после первичного доступа - 29 минут. Промежуток между раскрытием уязвимости и её эксплуатацией сократился с 756 дней в 2018 году до считанных часов. Если вы в offensive security - вам нужно понимать весь конвейер: от строчки в NVD до рабочего PoC. Если вы защитник - вам нужно знать этот конвейер ещё лучше, чем атакующий.

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

Карта темы: от CVE к рабочему эксплойту за 7 фаз​

#ФазаЧто происходитПодробный разбор
1Мониторинг и отбор CVEТриаж потока уязвимостей, фильтрация по CVSS, EPSS, affected productsАнализ CVE уязвимостей: от строчки в NVD до рабочей гипотезы эксплуатации
2Анализ advisory и patch diffingЧтение бюллетеня, скачивание патча, diff изменённого кодаАнализ CVE уязвимостей: от строчки в NVD до рабочей гипотезы эксплуатации
3Воспроизведение и crashНастройка окружения, триггер уязвимости, получение crashРазработка эксплойта для CVE: пример полного цикла от crash до рабочего PoC
4Разработка PoCКонтроль EIP/RIP, построение ROP-цепочки, обход митигацийРазработка эксплойта для CVE: пример полного цикла от crash до рабочего PoC
5Эксплуатация в вебеДесериализация, SSTI, SSRF-to-RCE для веб-CVEЭксплуатация CVE в веб-приложениях: от чтения advisory до RCE за три шага
6Weaponization: gadget chains и десериализацияysoserial, phpggc, построение цепочек гаджетовУязвимости десериализации: эксплуатация через ysoserial, phpggc и построение gadget chain
7Интеграция в пентест: стабильный шелл через EDRАдаптация публичного PoC, обход детектов, стабилизацияЭксплуатация CVE в пентесте: от публичного PoC до стабильного шелла в обход EDR

1777153218724.webp

Почему окно эксплуатации схлопнулось до нуля: цифры 2025–2026​

В 2018 году от публикации CVE до первого зафиксированного эксплойта проходило в среднем 756 дней. К 2023 - уже недели. В 2025, по данным VulnCheck, почти треть (28,96%) уязвимостей из каталога KEV эксплуатировались в день публикации или раньше - рост с 23,6% годом ранее. 55% zero-day отрабатывали в течение первой недели после раскрытия.

Три причины, почему всё так ускорилось (и данные из отчётов 2026 года это подтверждают):

Patch diffing стал тривиальным. Вендор публикует патч - атакующий скачивает коммит, запускает diff, находит изменённые функции и строит гипотезу эксплуатации. Я наблюдаю, как AI-ассистированный анализ сократил этот процесс до часов. По данным HiveSecurity, AI-агенты сгенерировали более 40 рабочих эксплойтов для одной уязвимости за $50. Пятьдесят долларов - и у тебя пачка рабочих PoC.

Периметровые устройства - приоритетная цель. VulnCheck зафиксировал: сетевые устройства периметра (файрволы, VPN, прокси) возглавляют список атакуемых технологий в 2025 году. Greenbone в мартовском отчёте 2026 года описывает CitrixBleed 3 (CVE-2026-3055, CVSS 9.3) - активная разведка эндпоинта /cgi/GetAuthMethods началась через 3 дня после disclosure, а ещё через несколько дней CVE попал в CISA KEV.

Вендор патчит в среднем за 15 дней. По данным HiveSecurity, от обнаружения активной эксплуатации до выхода патча - 15 дней. Разрыв между «эксплойт в дикой природе» и «патч доступен» измеряется неделями. И эти недели - в пользу атакующего.

Если вы строите vulnerability management только на CVSS-скоре и ежемесячных циклах патчинга - вы структурно опаздываете. Приоритизация по факту эксплуатации (CISA KEV, VulnCheck KEV) критичнее теоретической оценки серьёзности. Точка.

Фаза 1: Мониторинг и триаж - как не утонуть в 70 CVE в день​

По данным Инфратех, в год регистрируется более 25 000 новых CVE - в среднем по 70 в день. Securelist, наблюдается стабильный квартальный рост. При таком потоке ключевой навык - не чтение каждой записи, а быстрый триаж по критериям, релевантным вашему скоупу.

Что содержит запись CVE и почему этого недостаточно​

Каждая CVE-запись включает идентификатор (формат CVE-год-номер), текстовое описание, ссылки на advisory/патчи и, после обогащения в NVD, оценку CVSS и классификацию CWE. Возьмём CVE-2021-44228 (Log4Shell): CVSS 10.0 (CRITICAL), вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H и сразу четыре CWE: CWE-20, CWE-400, CWE-502, CWE-917 - что отражает многослойность проблемы.

Но CVSS - это теоретическая серьёзность. CVSS 9.8 без единого эксплойта в дикой природе менее опасна, чем CVSS 6.0 с активной эксплуатацией. Поэтому нужны дополнительные сигналы.

Инструменты мониторинга: конвейер для offensive-исследователя​

Мой рабочий конвейер триажа:
  1. cvemap от ProjectDiscovery - CLI-утилита для быстрого поиска по CVE с фильтрацией по CVSS, EPSS, наличию в KEV, наличию PoC.
  2. CISA KEV - авторитетный каталог реально эксплуатируемых уязвимостей. Обновляется ежедневно. Любая CVE из этого списка = подтверждённая эксплуатация в дикой природе.
  3. VulnCheck KEV - расширенный каталог с 884 KEV за 2025 год (против 245 у CISA), покрывает 518 вендоров и 672 продукта. Есть alerting через email и Slack.
  4. EPSS (Exploit Prediction Scoring System) - вероятностная модель, предсказывающая шанс эксплуатации в ближайшие 30 дней. EPSS ≥ 90-го перцентиля - красный сигнал.

Связка CVE, CVSS, CWE и EPSS: чек-лист триажа​

КритерийЗначениеДействие
В CISA/VulnCheck KEVДаНемедленная реакция (Track A: SLA 24–48 часов)
EPSS ≥ 90-й перцентильВысокая вероятностьПриоритет в sprint
CVSS ≥ 9.0, AV:N, AC:LКритичный, удалённый, простойРесёрч-кандидат
CWE-502 / CWE-787 / CWE-416Десериализация / memory corruptionВысокий потенциал для RCE
Есть публичный PoCGitHub/ExploitDBАнализировать немедленно

Как перейти от строчки в NVD к рабочей гипотезе эксплуатации - детально разобрано в гайде Анализ CVE уязвимостей: от строчки в NVD до рабочей гипотезы эксплуатации.

Фаза 2: Patch diffing и root-cause analysis - где рождается эксплойт​

Patch diffing - техника, которая превращает исправление вендора в дорожную карту к уязвимости. Берёшь коммит, закрывающий CVE, сравниваешь с предыдущей версией - и получаешь точное местоположение бага. По MITRE ATT&CK это этап Resource Development: получение или разработка эксплойтов (T1588.005, T1587.004).
📚 Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме


1777153260440.webp

Фаза 4: эксплуатация CVE в веб-приложениях - от advisory до RCE​

Веб-уязвимости стоят особняком: тут обычно не нужен binary exploitation, но нужен глубокий анализ логики приложения. По данным VulnCheck, CMS (в первую очередь WordPress со всем его хозяйством плагинов) - вторая по популярности категория атакуемых технологий после периметровых устройств.

Классические векторы веб-CVE в 2025–2026​

Десериализация без валидации. CVE-2026-20963 (SharePoint, CVSS 8.8, EPSS ≥ 91-й перцентиль) - improper deserialization of untrusted data (CWE-502), RCE для аутентифицированного атакующего. Множественные публичные PoC и подтверждённая активная эксплуатация.

Race condition в файловой системе. BlueHammer (CVE-2026-33825) - TOCTOU race condition в Windows Defender: цепочка из oplocks, NTFS junctions и Cloud Files API перенаправляет чтение Defender с легитимного обновления на копию SAM-базы. Результат - извлечение NTLM-хэшей и SYSTEM shell. Без повреждения памяти, без kernel exploit - только злоупотребление доверенным workflow. Изящно, чёрт возьми.

Три шага от advisory до RCE для типичной веб-CVE​

  1. Чтение advisory - определяем affected endpoint, тип уязвимости (CWE), версии.
  2. Настройка окружения - разворачиваем уязвимую версию в Docker/VM, проверяем, что endpoint отвечает.
  3. Crafting payload - формируем HTTP-запрос, эксплуатирующий уязвимость. Для десериализации - генерируем gadget chain, для инъекции - формируем payload с учётом контекста исполнения.
Пошаговый разбор на реальных CVE - в гайде Эксплуатация CVE в веб-приложениях: от чтения advisory до RCE за три шага.

Фаза 5: стабилизация эксплойта и интеграция в пентест - обход EDR и надёжный шелл​

Публичный PoC с GitHub - не рабочий инструмент пентестера. Это proof-of-concept, часто нестабильный, палящийся на первом же EDR. Между «PoC крашит целевой сервис» и «стабильный reverse shell на проекте» - пропасть.

Почему публичные PoC не работают «из коробки»​

Типичные проблемы:
  • Hardcoded offsets - PoC написан под конкретный билд, на другой версии ломается.
  • Нет обработки ошибок - crash вместо graceful failure.
  • Детектируемость - сигнатуры добавлены в EDR/AV в первые часы после публикации. Vectra AI описывает, как исследователь Will Dormann показал: простое переименование бинарника (с RedSun.exe на z.exe) с шифрованием EICAR-строки радикально снижает детекты на VirusTotal. Казалось бы - детский трюк. А работает.
  • Одноразовость - эксплойт работает один раз, после чего сервис падает.

Конвейер стабилизации​

  1. Адаптация offsets - пересчитываем под целевую версию. Для binary exploit - ищем гаджеты через ropper в конкретных DLL/SO целевой системы.
  2. Обфускация payload - не копируем shellcode из msfvenom «как есть». Кодируем, шифруем, пишем custom loader.
  3. Тестирование на защищённом окружении - собираем лабораторию с включённым Defender/CrowdStrike/другим EDR. Проверяем каждую итерацию.
  4. Стабилизация - обработка ошибок, поддержка нескольких версий, retry-логика.
По данным Huntress (описанным в отчёте Vectra AI), реальные атаки с использованием свежих CVE выглядят как «hands-on-keyboard intrusion»: ручные команды разведки (whoami /priv), стейджинг бинарников в пользовательских каталогах (Pictures, Downloads), целенаправленное размещение в low-noise директориях. Никакой автоматизации - руками, аккуратно, тихо.

Полный workflow адаптации публичного PoC до стабильного шелла с обходом EDR - в гайде Эксплуатация CVE в пентесте: от публичного PoC до стабильного шелла в обход EDR.

Маппинг на MITRE ATT&CK: где эксплуатация CVE в kill chain​

Эксплуатация CVE не привязана к одной фазе kill chain. В зависимости от типа уязвимости и контекста, она маппится на разные тактики:

Фаза ATT&CKТехникаКогда применяется
ReconnaissanceT1595.002 - Vulnerability ScanningМассовое сканирование (Shodan, Censys, custom scanners)
Resource DevelopmentT1588.005 - Obtain ExploitsСкачивание публичного PoC с GitHub, ExploitDB
Resource DevelopmentT1587.004 - Develop ExploitsРазработка эксплойта через patch diffing
Resource DevelopmentT1588.006 - VulnerabilitiesПокупка или получение информации о zero-day
Initial AccessT1190 - Exploit Public-Facing ApplicationЭксплуатация веб-приложения, VPN, файрвола
ExecutionT1203 - Exploitation for Client ExecutionВредоносный документ (CVE-2017-11882, CVE-2018-0802)
Privilege EscalationT1068 - Exploitation for Privilege EscalationLPE через kernel-уязвимость (CVE-2022-0847, CVE-2024-35250)
Lateral MovementT1210 - Exploitation of Remote ServicesЭксплуатация сетевого сервиса для перемещения по сети

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

Реальные CVE 2025–2026: что эксплуатируется прямо сейчас​

Самые эксплуатируемые CVE на Windows (Q1 2025)​

По данным «Лаборатории Касперского», тройка лидеров не меняется годами - и это говорит о состоянии патч-менеджмента красноречивее любого отчёта:
  • CVE-2018-0802 (CVSS 7.8) - memory corruption в Equation Editor, Microsoft Office. CWE-787. Требует открытия вредоносного документа.
  • CVE-2017-11882 (CVSS 7.8) - ещё одна memory corruption в Equation Editor. CWE-119. Аналогичный вектор.
  • CVE-2017-0199 (CVSS 7.8) - RCE через OLE-объекты в Microsoft Office/WordPad.
За ними - CVE-2023-38831 (WinRAR, CVSS 7.8, CWE-345), CVE-2024-35250 (драйвер ks.sys, CWE-822 - untrusted pointer dereference), CVE-2022-3699 (драйвер Lenovo Diagnostics, CWE-787 - прямой доступ к памяти ядра).

Самые эксплуатируемые CVE на Linux (Q1 2025)​

  • CVE-2022-0847 Dirty Pipe (CVSS 7.8, CWE-665) - перезапись read-only файлов через pipe buffer, LPE до root.
  • CVE-2019-13272 (CVSS 7.8) - некорректное наследование привилегий в ptrace, LPE.
  • CVE-2021-3156 Baron Samedit (CVSS 7.8, CWE-193) - off-by-one heap overflow в sudo, LPE до root через sudoedit -s. Эксплуатация без аутентификации, добавлен в CISA KEV. Используется в ransomware-кампаниях.

Свежие CVE 2026​

  • CVE-2026-33017 (CVSS 9.8) - RCE в Langflow через exec() без песочницы.
  • CVE-2026-22557 (CVSS 10) - unauthenticated account takeover в Ubiquiti UniFi через path traversal (CWE-22).
  • CVE-2026-33825 BlueHammer - TOCTOU race condition в Windows Defender, извлечение NTLM-хэшей через злоупотребление процессом обновления сигнатур.
Securelist фиксирует: CWE-типы из TOP-10 для Windows и Linux совпадают или аналогичны. Злоумышленники «портируют» механизмы атак между платформами, адаптируя рабочие эксплойты. Написал heap overflow под Linux - адаптировал под Windows. Конвейер.

Инструментарий offensive-исследователя: от мониторинга до шелла​

Фаза мониторинга и анализа​

ИнструментНазначениеКогда использовать
cvemapCLI-поиск по CVE, фильтр по EPSS/KEV/PoCПервичный триаж
NVD API / cve.orgОфициальные данные CVE, CVSS, CWEВерификация данных
CISA KEV / VulnCheck KEVКаталог реально эксплуатируемых CVEПриоритизация
Shodan / CensysПоиск уязвимых экземпляров в интернетеОценка attack surface

Фаза реверса и patch diffing​

ИнструментНазначениеКогда использовать
Ghidra + BinDiffДекомпиляция и visual diff бинарниковПроприетарное ПО
IDA Free + DiaphoraАльтернативная связка для binary diffКогда нужен IDA FLIRT
git diffSource-level diffOpen-source проекты

Фаза разработки и отладки​

ИнструментНазначениеКогда использовать
GDB + pwndbg/GEFДинамический анализ, визуализация heapОтладка crash/exploit
AFL++ / libFuzzerФаззинг для нахождения оптимального inputПоиск триггера
ropper / ROPgadgetПоиск ROP-гаджетовОбход DEP
Docker / QEMUИзолированное окружение для воспроизведенияЛюбой PoC
ysoserial / phpggcГенерация gadget chains для десериализацииJava / PHP CVE
Metasploit FrameworkГотовые модули + разработка custom exploitИнтеграция в пентест

Защитная перспектива: детекция до начала эксплуатации​

Понимание offensive workflow - фундамент грамотной обороны. По данным Unit 42, в 2025 году phishing и vulnerability exploitation - наиболее частые векторы первичного доступа (по 22% каждый). В более чем 90% расследованных инцидентов предотвратимые бреши - ограниченная видимость, непоследовательно применённые контроли, избыточное доверие - существенно способствовали компрометации.

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

По рекомендации HiveSecurity, разделите процесс на два трека:

Track A - активно эксплуатируемые (в KEV). SLA: 24–48 часов для internet-facing активов. Экстренное изменение, ускоренное тестирование, немедленное развёртывание. Да, это больно. Но альтернатива - больнее.

Track B - пока не эксплуатируемые. SLA: стандартный цикл (1–4 недели в зависимости от CVSS).

Что детектировать, если патч ещё не установлен​

Для каждой критической CVE на internet-facing системах задавайте вопрос: «была ли система скомпрометирована между disclosure и установкой патча?»

Паттерны для мониторинга:
  • Процесс веб-сервера (httpd, nginx, IIS) порождает неожиданный дочерний процесс (bash, cmd.exe, powershell).
  • Исходящие соединения от сервисов, которые не должны инициировать outbound-трафик.
  • Аномалии аутентификации на VPN/remote access инфраструктуре.
  • Новые scheduled tasks или сервисы, созданные вскоре после даты disclosure.
YAML:
# Мониторинг подозрительных child-процессов от веб-сервера
# Sigma-подобное правило (концепция)
detection:
  selection:
    ParentImage|endswith:
      - '/httpd'
      - '/nginx'
      - 'w3wp.exe'
    Image|endswith:
      - '/bash'
      - '/sh'
      - 'cmd.exe'
      - 'powershell.exe'
  condition: selection

N-day vs zero-day: экономика эксплуатации в 2025–2026​

Различие, которое стоит держать в голове:

Zero-day (0-day) - уязвимость, для которой нет патча. По данным VulnCheck, 67,2% эксплуатируемых CVE в 2026 году - zero-day, против 16,1% в 2018. Рост, объясняется увеличением bug bounty программ, автоматизацией фаззинга и AI-ассистированным ресёрчем.

N-day - уязвимость, для которой патч существует, но не установлен. Тройка самых эксплуатируемых CVE на Windows в 2025 году (CVE-2018-0802, CVE-2017-11882, CVE-2017-0199) - n-day, которым 7–8 лет. Они работают, потому что десятки тысяч систем не обновлены. Семь лет, Карл.

Для offensive-исследователя n-day - low-hanging fruit: патч уже содержит всю информацию для написания эксплойта, а цели гарантированно существуют. Для защитника - это приговор процессу patch management.

По данным VulnCheck, атрибуция ransomware-атак к конкретным CVE систематически запаздывает. Реальное число CVE, используемых в ransomware-кампаниях, выше, чем известно на момент disclosure.

AI в exploit development: ускоритель, а не «волшебная кнопка»​

Тренд 2025 года, который нельзя игнорировать. По данным Unit 42, AI уже используется threat-акторами операционно: для ускорения цикла «мониторинг → diff → тест → вооружение». Исследователь Мэтт Кили публично показал создание рабочего эксплойта для CVE-2025-32433 (SSH-сервер Erlang/OTP) с помощью GPT-4 - модель не только поняла описание CVE, но и нашла исправляющий коммит, сравнила код и сгенерировала эксплойт.

По данным HiveSecurity, AI-агенты сгенерировали более 40 рабочих эксплойтов для одной уязвимости за $50, а AI-агентные «рои» нашли 100+ эксплуатируемых уязвимостей за $4 за баг.

Что это меняет на практике:

Барьер входа снижается. Exploit development, ранее требовавший годов опыта в реверсе и системном программировании, постепенно автоматизируется. Это не хорошо и не плохо - это факт.

Скорость растёт. AI сжимает жизненный цикл атаки на этапах разведки, анализа кода и генерации payload.

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

При этом AI - не замена пониманию. Сгенерированный эксплойт нужно валидировать, стабилизировать, адаптировать. Модель может ошибиться в offsets, не учесть митигации, выдать нерабочий код. У меня был случай, когда AI-сгенерированный PoC красиво выглядел на бумаге, но ронял целевой сервис без полезного выхлопа - пришлось переписывать руками. «AI-assisted» не означает «AI-generated» - человек остаётся в петле.

Куда движется exploit development: прогноз на 2026–2027​

Три вектора, которые определят ситуацию в ближайший год:

Окно эксплуатации продолжит сжиматься. Данные VulnCheck показывают стабильный рост доли zero-day и same-day exploitation год к году. При текущих темпах к концу 2026 года более трети KEV будут эксплуатироваться до публикации CVE.

Supply chain станет основным вектором. Unit 42 фиксирует расширение рисков за пределы уязвимого кода - к злоупотреблению доверенными SaaS-интеграциями, vendor tools и application dependencies. Цепочка поставок - это новый периметр. Атакуют не вас - атакуют вашего подрядчика, а вы получаете «бонус».

Identity как поверхность атаки. По данным Unit 42, слабости идентификации сыграли роль в почти 90% расследований 2025 года. Атакующие всё чаще «залогиниваются» с украденными кредами, а не «взламывают» через эксплойт. Цепочка «CVE → initial access → credential theft → lateral movement» становится стандартной, а не исключением.

Вопрос к читателям​

При анализе CVE-2026-3055 (CitrixBleed 3, CVSS 9.3, CWE-125) разведка шла через эндпоинт /cgi/GetAuthMethods - полный технический анализ с exploit code был опубликован в считанные дни. Для тех, кто работает с NetScaler ADC/Gateway в продакшене: какой набор Suricata/Snort-правил вы применили для детекции обращений к этому эндпоинту до установки патча? Интересует конкретная сигнатура - SID, content-match, flow-направление. Если строили кастомное правило - поделитесь конфигом. Если использовали YARA для анализа памяти на предмет утёкших данных - тоже ценно. Цель: собрать рабочий detection kit для CitrixBleed 3 из опыта комьюнити.
 
Последнее редактирование модератором:
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab