На проверке CISA KEV каталог: workflow пентестера от парсинга до эксплуатации

[Сергей Попов]

На внешнем пентесте прошлой осенью Nessus отдал 347 находок уровня High и Critical по периметру финансовой организации. Реально эксплуатируемых из них оказалось 9 - я выяснил это за три минуты, прогнав CVE-список через CISA KEV каталог. Одна из девяти - CVE-2022-1388 на F5 BIG-IP (в KEV отмечена как используемая в ransomware-кампаниях) - дала RCE от root через двадцать минут после обнаружения. Без KEV эта CVE утонула бы среди трёхсот «критичных» записей, клиент продолжал бы латать теоретические угрозы, а рабочий вектор initial access оставался бы открытым.

Каталог known exploited vulnerabilities - не compliance-галочка. Для пентестера это фильтр, отделяющий работающий эксплойт от шума CVSS.

Почему CVSS недостаточно и зачем пентестеру CISA KEV каталог​

По данным Picus Security, в 2024 году опубликовано 41 000 новых CVE, из которых 61% получили метку High или Critical по CVSS. Проблема тут простая: CVSS оценивает теоретическую серьёзность - потенциальный импакт, вектор атаки, сложность эксплуатации. Он не отвечает на вопрос «эту CVE реально кто-то использовал?». CVE с CVSS 9.8 может не иметь публичного PoC. А CVE с CVSS 6.5 оказывается рабочим вектором lateral movement в кампаниях APT-групп.

EPSS пытается предсказать вероятность эксплуатации в ближайшие 30 дней - метрика полезная для vulnerability management, но для пентестера предсказание слабее факта. Нужен бинарный сигнал: CVE уже эксплуатировали в дикой природе - значит, PoC существует, payload работает, шанс пробить периметр не теоретический.

Именно это даёт CISA Known Exploited Vulnerabilities каталог. KEV - бинарная метрика: CVE либо подтверждённо эксплуатировалась в реальных атаках, либо нет. Без скоров, вероятностей и весов. Каждая запись означает: кто-то уже использовал эту уязвимость для компрометации продакшн-систем. Каталог ведёт CISA с 2021 года. Для федеральных агентств США записи обязательны к устранению в рамках Binding Operational Directive 22-01, часто с дедлайном две-три недели. Для пентестера вывод другой: если CVE попала в known exploited vulnerabilities list - под неё почти наверняка есть рабочий эксплойт.

Приоритизация уязвимостей для пентеста: трёхуровневая схема​

На практике я выстраиваю приоритет целей так:

1. KEV + внешний периметр. CVE из каталога на сервисах, доступных из интернета. Первое, что проверяю - прямой путь к initial access.
2. KEV + внутренние хосты. CVE из KEV на внутренней инфраструктуре. Вектор для privilege escalation и lateral movement после закрепления.
3. High CVSS + публичный PoC, но не в KEV. Эксплуатируемо в теории - проверяю, если первые два уровня не дали результата.

Такой risk-based vulnerability prioritization подход сокращает время от recon до первого shell с часов до минут. Вместо перебора сотен CVE по убыванию CVSS работаю с десятком подтверждённых целей.

Что внутри KEV-записи и как это читать пентестеру​

Каждая запись каталога содержит набор полей. Не все одинаково полезны для offensive-работы - вот что реально пригождается:

Поле	Что даёт на пентесте
CVE ID	Поиск PoC: ExploitDB, GitHub, Nuclei templates, search cve:XXXX в Metasploit
Vendor / Product	Fingerprinting: если вендор в скоупе - приоритет проверки этого актива
Vulnerability Name	Класс уязвимости: RCE, auth bypass, privilege escalation - определяет вектор
Date Added	Свежие записи (30-90 дней) = высокая вероятность непропатченных систем
Due Date	Дедлайн 7 дней (как у CVE-2025-22457) означает экстремальную срочность по оценке CISA
Required Action	«Apply vendor updates» = патч существует, но клиент мог не накатить

По данным Picus Security, CVE-2025-22457 - stack-based buffer overflow (CWE-121/CWE-787) в Ivanti Connect Secure, Policy Secure и ZTA Gateways (CVSS 9.0) - получила дедлайн 7 дней после добавления в KEV. Причина: подтверждённое использование APT-группами для initial access без аутентификации плюс отметка об использовании в ransomware-кампаниях.

Тут есть нюанс, который легко пропустить. CVSS-вектор этой CVE (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) содержит AC:H (Attack Complexity: High) и S:C (Scope: Changed). Эксплуатация технически сложнее, чем у CVE-2022-1388 (AC:L), и требует специфических условий. Но Scope:Changed означает выход за пределы уязвимого компонента - отсюда экстремальная срочность дедлайна. Если в скоупе есть Ivanti VPN - это приоритетный хост для проверки, но на быструю эксплуатацию рассчитывать не стоит.

Парсинг CISA KEV и сверка с результатами сканирования​

CISA отдаёт KEV каталог в JSON, CSV и через веб-интерфейс. Для автоматизации удобнее JSON: curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | python3 -m json.tool | head. Актуальная копия данных также лежит в репозитории cisagov/kev-data на GitHub.

Ключевая задача - сверить выгрузку сканера (Nessus, Nuclei, OpenVAS) с содержимым KEV. Нюанс, на который я наступил в первых итерациях: Nessus-экспорт в CSV не всегда содержит чистый CVE-ID в отдельной колонке - идентификатор бывает зашит в строку описания или в поле «Cross References». Поэтому извлечение через регулярное выражение обязательно.

import json, csv, re, urllib.request

kev_url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
try:
    kev_data = json.loads(urllib.request.urlopen(kev_url, timeout=10).read())
except Exception as e:
    print(f"[!] Cannot fetch KEV (no egress?): {e}. Use local copy."); exit(1)
if "vulnerabilities" not in kev_data:
    print("[!] Unexpected KEV JSON structure. Check URL or format."); exit(1)
kev_cves = {v["cveID"]: v for v in kev_data["vulnerabilities"]}

nessus_hits = []
with open("nessus_export.csv", "r") as f:
    for row in csv.DictReader(f):
        text = row.get("CVE", "") + " " + row.get("Description", "")
        for cve_id in re.findall(r"CVE-\d{4}-\d{4,7}", text):
            if cve_id in kev_cves:
                nessus_hits.append({"cve": cve_id, "host": row.get("Host", ""),
                    "port": row.get("Port", ""), "product": kev_cves[cve_id]["product"]})

for h in nessus_hits:
    print(f"[KEV] {h['cve']} | {h['product']} | {h['host']}:{h['port']}")

На выходе - список хостов с портами, где обнаружены CVE из known exploited vulnerabilities catalog. Порядок величины: на среднем внешнем пентесте из нескольких сотен находок Nessus в KEV попадают единицы-десятки. Именно эти цели идут в работу первыми.

Тот же подход работает с любым сканером - достаточно вытащить CVE-ID из отчёта и прогнать через множество kev_cves. Для Nuclei удобнее парсить JSONL-вывод (-jsonl), где CVE-ID лежит в поле info.classification.cve-id.

Практический workflow: от KEV-хита до initial access​

Fingerprinting цели перед эксплуатацией​

Допустим, скрипт показал KEV-хит: CVE-2022-1388 (F5 BIG-IP iControl REST authentication bypass). Прежде чем запускать эксплойт - подтверждаю, что на цели действительно BIG-IP, и определяю порт и путь iControl REST API.

Первый шаг - fingerprinting: nuclei -u https://target.example.com:443 -u https://target.example.com:8443 -tags bigip (путь к конкретному шаблону зависит от версии nuclei-templates; альтернативно - httpx -u https://target.example.com -title -tech-detect). Шаблон проверяет характерные эндпоинты BIG-IP и определяет, доступен ли iControl REST (обычно порт 443 или 8443, путь /mgmt/tm/). Только после подтверждения запускаю проверку CVE с указанием конкретного порта из результатов фингерпринтинга:

# Проверьте актуальный путь: nuclei -tl | grep CVE-2022-1388
nuclei -u https://target.example.com:8443 \
  -t http/cves/2022/CVE-2022-1388.yaml -v

Порт и путь берутся из результата разведки, а не из дефолтных значений. На реальных пентестах BIG-IP может висеть на нестандартном порту за reverse proxy, и слепой запуск шаблона даст false negative. Эта ошибка стоила мне пропущенного хита на одном из первых проектов, где я начал использовать KEV-workflow. Обидно было - CVE из каталога, эксплойт публичный, а я промахнулся мимо порта.

Поиск PoC и эксплуатация​

После подтверждения уязвимости через Nuclei:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Цикл от KEV-хита до shell занимает от 15 минут до часа. Методичная проработка всех 300+ находок по CVSS-приоритету заняла бы рабочий день без гарантии результата.

Актуальные эксплойты CVE: что искать в KEV для red team​

Свежие записи KEV - золотая жила для пентестера. Если CVE добавлена в каталог в последние 30-90 дней, вероятность, что клиент не успел пропатчить, максимальна. Фильтрую KEV по полю dateAdded и смотрю категории продуктов:

VPN и gateway-устройства (Ivanti, Fortinet, Palo Alto, Citrix NetScaler) - точки initial access с минимальным взаимодействием пользователя. По данным 1275.ru, Citrix NetScaler ADC и Gateway попали в KEV с уязвимостью переполнения памяти (CVSS 8.8), эксплуатируемой без аутентификации на устройствах в конфигурации SSL VPN.

Edge-инфраструктура (F5 BIG-IP, Confluence/Jira на периметре) - отстаёт по патчам на месяцы. Часто это забытые админами системы, про которые «вроде работает - не трогай».

Ядра ОС и привилегированные подсистемы - вектор privilege escalation после initial access. Тот же источник сообщает о записи для ядра Linux (out-of-bounds write в watch_queue), дающей повышение привилегий локальному пользователю.

По данным Oligo Security, анализ CWE-классов в KEV за 2024 год показал интересную картину: атакующие концентрируются на узком наборе типов уязвимостей. Injection-классы и ошибки работы с памятью (CWE-787, CWE-416) доминируют, причём их распределение отличается от стандартного CWE Top 25. Type confusion, например, редко попадает в общие рейтинги, но стабильно эксплуатируется в браузерах и JIT-движках. Для red team это ориентир: искать в инфраструктуре клиента не «всё подряд», а конкретные паттерны, которые атакующие реально используют.

Отдельный момент: CISA продолжает добавлять в KEV уязвимости, датированные 2015-2019 годами, если появляются свежие свидетельства эксплуатации. На пентесте нельзя игнорировать «старые» CVE из каталога - атакующие используют их именно потому, что организации считают угрозу устаревшей. Я видел CVE-2017-* на продакшн-серверах в 2024 году - и это были не тестовые стенды.

Использование KEV в редтиминге и пентест-отчётах​

Перед пентестом я проверяю, какие KEV-уязвимые продукты видны на периметре клиента через Shodan или Censys. Workflow: выгружаю из KEV записи по целевым вендорам, нахожу affected versions из NVD, ищу по org:"Client" product:"BIG-IP". Этот recon-этап занимает 10-15 минут и даёт картину до запуска активного сканирования. Иногда initial access начинается ещё на этапе OSINT - CVE из KEV на устаревшем Fortinet-шлюзе, который не обновлялся полгода и торчит в Shodan с баннером конкретной версии.

В отчёте KEV-ссылка переводит разговор с клиентом в другую плоскость. Фраза «CVSS 9.8» вызывает привыкание - когда всё Critical, ничто не Critical. Формулировка «CVE-XXXX включена в CISA KEV, что означает подтверждённую эксплуатацию в реальных атаках; для федеральных агентств США дедлайн устранения - N дней» работает иначе. Это переход от «теоретически опасно» к «уже ломают». По моему опыту: когда в отчёте есть ссылка на KEV, приоритизация патчей со стороны клиента ускоряется кратно.

KEV-ссылка также закрывает вопросы формата «почему вы эксплуатировали CVE-2022-1388, а не CVE-2024-XXXXX с CVSS 10.0?». Ответ прост: первая - в каталоге с подтверждённой эксплуатацией и публичным PoC, вторая - теоретический максимум CVSS без доказательств использования в дикой природе.

По данным одного из исследований на Хабре, интеграция CISA KEV в VM-платформу существенно увеличила покрытие CVE по сравнению с трендовыми сигналами коммерческого вендора. Для пентестера вывод такой: полагаться только на встроенную аналитику сканера - значит пропускать значительную часть реально эксплуатируемых уязвимостей.

Главный сдвиг, который KEV каталог вносит в offensive-методологию - переход от CVSS-сортировки к приоритизации по факту эксплуатации. Часть пентест-команд до сих пор выстраивает отчёт по убыванию CVSS, потому что так устроены шаблоны Nessus и дефолтные выгрузки. Это фундаментальная ошибка: CVSS скоринг отвечает на вопрос «насколько это может быть плохо», а не «насколько это вероятно прямо сейчас». CVE с CVSS 10.0 может оставаться неэксплуатируемой из-за отсутствия публичного PoC.

Через год-два, на мой взгляд, пентестерские методологии окончательно перестроятся: сначала KEV-хиты, потом всё остальное. Кто уже работает по этой схеме - тратит на порядок меньше времени на recon-фазу. На HackerLab есть сценарии, где эксплуатацию известных CVE нужно развернуть end-to-end без подсказок - формат, который быстро показывает разницу между «знаю про уязвимость» и «могу собрать цепочку до RCE».