В 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 за три шага |
| 6 | Weaponization: gadget chains и десериализация | ysoserial, phpggc, построение цепочек гаджетов | Уязвимости десериализации: эксплуатация через ysoserial, phpggc и построение gadget chain |
| 7 | Интеграция в пентест: стабильный шелл через EDR | Адаптация публичного PoC, обход детектов, стабилизация | Эксплуатация CVE в пентесте: от публичного PoC до стабильного шелла в обход EDR |
Почему окно эксплуатации схлопнулось до нуля: цифры 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-исследователя
Мой рабочий конвейер триажа:- cvemap от ProjectDiscovery - CLI-утилита для быстрого поиска по CVE с фильтрацией по CVSS, EPSS, наличию в KEV, наличию PoC.
- CISA KEV - авторитетный каталог реально эксплуатируемых уязвимостей. Обновляется ежедневно. Любая CVE из этого списка = подтверждённая эксплуатация в дикой природе.
- VulnCheck KEV - расширенный каталог с 884 KEV за 2025 год (против 245 у CISA), покрывает 518 вендоров и 672 продукта. Есть alerting через email и Slack.
- 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 |
| Есть публичный PoC | GitHub/ExploitDB | Анализировать немедленно |
Как перейти от строчки в NVD к рабочей гипотезе эксплуатации - детально разобрано в гайде Анализ CVE уязвимостей: от строчки в NVD до рабочей гипотезы эксплуатации.
Фаза 2: Patch diffing и root-cause analysis - где рождается эксплойт
Patch diffing - техника, которая превращает исправление вендора в дорожную карту к уязвимости. Берёшь коммит, закрывающий CVE, сравниваешь с предыдущей версией - и получаешь точное местоположение бага. По MITRE ATT&CK это этап Resource Development: получение или разработка эксплойтов (T1588.005, T1587.004).
📚 Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Фаза 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
- Чтение advisory - определяем affected endpoint, тип уязвимости (CWE), версии.
- Настройка окружения - разворачиваем уязвимую версию в Docker/VM, проверяем, что endpoint отвечает.
- Crafting payload - формируем HTTP-запрос, эксплуатирующий уязвимость. Для десериализации - генерируем gadget chain, для инъекции - формируем payload с учётом контекста исполнения.
Фаза 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. Казалось бы - детский трюк. А работает. - Одноразовость - эксплойт работает один раз, после чего сервис падает.
Конвейер стабилизации
- Адаптация offsets - пересчитываем под целевую версию. Для binary exploit - ищем гаджеты через
ropperв конкретных DLL/SO целевой системы. - Обфускация payload - не копируем shellcode из msfvenom «как есть». Кодируем, шифруем, пишем custom loader.
- Тестирование на защищённом окружении - собираем лабораторию с включённым Defender/CrowdStrike/другим EDR. Проверяем каждую итерацию.
- Стабилизация - обработка ошибок, поддержка нескольких версий, retry-логика.
whoami /priv), стейджинг бинарников в пользовательских каталогах (Pictures, Downloads), целенаправленное размещение в low-noise директориях. Никакой автоматизации - руками, аккуратно, тихо.Полный workflow адаптации публичного PoC до стабильного шелла с обходом EDR - в гайде Эксплуатация CVE в пентесте: от публичного PoC до стабильного шелла в обход EDR.
Маппинг на MITRE ATT&CK: где эксплуатация CVE в kill chain
Эксплуатация CVE не привязана к одной фазе kill chain. В зависимости от типа уязвимости и контекста, она маппится на разные тактики:| Фаза ATT&CK | Техника | Когда применяется |
|---|---|---|
| Reconnaissance | T1595.002 - Vulnerability Scanning | Массовое сканирование (Shodan, Censys, custom scanners) |
| Resource Development | T1588.005 - Obtain Exploits | Скачивание публичного PoC с GitHub, ExploitDB |
| Resource Development | T1587.004 - Develop Exploits | Разработка эксплойта через patch diffing |
| Resource Development | T1588.006 - Vulnerabilities | Покупка или получение информации о zero-day |
| Initial Access | T1190 - Exploit Public-Facing Application | Эксплуатация веб-приложения, VPN, файрвола |
| Execution | T1203 - Exploitation for Client Execution | Вредоносный документ (CVE-2017-11882, CVE-2018-0802) |
| Privilege Escalation | T1068 - Exploitation for Privilege Escalation | LPE через kernel-уязвимость (CVE-2022-0847, CVE-2024-35250) |
| Lateral Movement | T1210 - 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 на 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-хэшей через злоупотребление процессом обновления сигнатур.
Инструментарий offensive-исследователя: от мониторинга до шелла
Фаза мониторинга и анализа
| Инструмент | Назначение | Когда использовать |
|---|---|---|
cvemap | CLI-поиск по 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 diff | Source-level diff | Open-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 из опыта комьюнити.
Последнее редактирование модератором: