Статья Защита от zero-day уязвимостей: playbook для SOC, когда патча ещё нет

Понедельник, 9:15 утра. Эксплуатация активна, автоматизируема, патча нет. EPSS 0.5895 - Top 5% по вероятности эксплуатации. У SOC несколько часов до массовой волны сканирования, и ни одного обновления от вендора. В ту же неделю прилетает CVE-2026-22769 - hardcoded credentials в Dell RecoverPoint, тоже CVSS 10.0, тоже CISA KEV, тоже без исправления. Компания, у которой выстроен бэкап-процесс и стоит EDR на endpoint'ах, обнаруживает неприятное: оба уязвимых актива - инфраструктурные appliance, на которых агент не стоит и стоять не может. Playbook, рассчитанный на «получили CVE - накатили патч», разваливается на втором шаге.

Окно уязвимости схлопывается: цифры zero-day реагирования​

Среднее время от раскрытия уязвимости до первого эксплойта (time-to-exploit) упало до 5 дней - Mandiant проанализировал 138 эксплуатируемых уязвимостей за 2023 год (из них 97 были zero-day). В 2018–2019 этот показатель составлял 63 дней. По данным KnowBe4, в 2025 году TTE опустился ниже двух дней и продолжает падать.

А теперь посмотрим на другую сторону: организации тратят от 60 до 150 дней на установку патча после его выхода. IBM X-Force Threat Intelligence Index 2025 даёт ещё более мрачную цифру - среднее время между публикацией CVE и устранением составляет 29 месяцев. Разрыв между скоростью атакующих и реакцией защитников - не «окно», а пропасть.

Google Threat Intelligence Group (GTIG) зафиксировал 75 zero-day уязвимостей, эксплуатировавшихся in the wild в 2024 году. 44% из них были направлены на enterprise-технологии - максимальная доля за всё время наблюдений. Security и networking продукты составили более 60% всех enterprise-targeted zero-day: 20 уязвимостей из 33.

При этом менее 2% всех публично известных CVE когда-либо эксплуатируются на практике. Задача SOC - не закрыть все дырки, а определить, какие из этих 2% прямо сейчас направлены на вашу инфраструктуру.

Старая модель patch management - «месяц на тестирование, квартал на раскатку» - не работает, когда патча не существует в природе. Защита от zero-day уязвимостей требует другого операционного подхода: компенсирующие контроли, виртуальный патчинг, поведенческая детекция. Об этом и поговорим.

Первые 6 часов без патча: decision tree для SOC​

Ниже - playbook, проверенный на инфраструктуре финтеха при появлении zero-day в сетевом оборудовании. Временные метки - ориентир, не догма. У вас может быть быстрее или медленнее, но последовательность важна.

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

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

Отдельная история - скомпрометированные легитимные хосты. Если zero-day в SD-WAN-контроллере позволил добавить rogue peer (как в кейсе CVE-2026-20127), атакующий уже внутри сети и выглядит как доверенное устройство с валидными сессиями. Сегментация после компрометации - не изоляция, а ограничение lateral movement. Искать нужно не внешние атаки, а аномальное поведение «своих» хостов.

Час 3–6: threat hunting на следы компрометации​

Не ждите алерта. Если уязвимость эксплуатировалась in the wild до публикации advisory, атакующие могли побывать в инфраструктуре задолго до того, как вы узнали о CVE. Mandiant M-Trends 2025 даёт медианное время нахождения злоумышленника в сети - 11 дней (исторический минимум), а 57% организаций узнали об инциденте от внешней стороны, а не от собственного SOC. Это к вопросу о зрелости детекции.

Что искать в ретроспективе за 30–90 дней:

• Новые административные учётные записи
• Аномальные сессии к management-интерфейсам (нехарактерные IP, время, user-agent)
• Diff текущей конфигурации сетевого оборудования с эталонной
• Исходящие подключения к нехарактерным IP/доменам (C2-индикаторы)
• Для оборудования без EDR: нетиповой трафик в NetFlow/sFlow

Виртуальный патчинг и exploit mitigation без обновления​

Виртуальный патч WAF/IPS - не «закрыл дырку», а «уменьшил поверхность эксплуатации». Он работает при известном векторе атаки и бесполезен, когда вектор неизвестен. Эффективность сильно зависит от класса уязвимости, и тут начинается самое интересное.

CWE-287 (Improper Authentication) - CVE-2026-20127. Проблема в логике аутентификации, а не в формате запроса. Виртуальный патч на WAF/IPS тут малоэффективен - нечего фильтровать. Работающие временные меры: ACL на management-интерфейс, отключение протокола peering, network segmentation. Эта категория соответствует OWASP A07 (Identification and Authentication Failures) - защита строится не на фильтрации payload, а на архитектурном ограничении доступа.

CWE-798 (Use of Hard-coded Credentials) - CVE-2026-22769. Credential зашит в firmware. Пока нет обновления прошивки - полная сетевая изоляция уязвимого актива. Классический OWASP A05 (Security Misconfiguration): hardcoded пароли и дефолтные конфигурации, которые WAF не в состоянии закрыть. Тут без вариантов.

CWE-20 (Improper Input Validation) - а вот здесь виртуальный патчинг работает лучше всего. Injection-векторы, некорректная обработка входных данных - WAF/IPS может фильтровать вредоносный payload до того, как он достигнет уязвимого компонента. Для таких случаев правила ModSecurity или F5 ASM дают реальную защиту.

Пример Suricata-правила для детекции попыток взаимодействия с management-интерфейсом SD-WAN из нехарактерных подсетей:

alert tcp !$MGMT_NETS any -> $SD_WAN_MGMT 443 (msg:"Unauthorized SD-WAN Management Access Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/dataservice/"; http_uri; classtype:attempted-admin; sid:2026001; rev:1;)

Это детектирующая, а не блокирующая сигнатура. Разница принципиальная: блокирующее правило в inline IPS может сломать легитимный трафик; алертирующее правило в SIEM даёт сигнал для расследования без операционного риска. В продакшене я бы начинал именно с алерта, и только после отладки false positive переводил в блок.

Для EDR-based containment - специфика зависит от вендора. CrowdStrike Falcon позволяет изолировать хост от сети, сохраняя канал управления агента. SentinelOne предлагает аналогичную функцию Network Quarantine. Но для edge-устройств - роутеров, SD-WAN-контроллеров, backup-appliance - EDR-агент отсутствует. Это ключевая слепая зона, подтверждённая GTIG: edge devices typically lack EDR coverage, и компрометация через zero-day в таких устройствах может оставаться незамеченной годами.

Detection без сигнатур: поведенческие корреляции в SIEM​

Когда патча нет и сигнатур нет - остаётся поведенческая аналитика. По MITRE ATT&CK, типичная цепочка при эксплуатации zero-day в enterprise-инфраструктуре выглядит так:

1. Exploit Public-Facing Application (T1190, Initial Access) - эксплуатация management-интерфейса
2. Exploitation for Privilege Escalation (T1068, Privilege Escalation) - эскалация до root/admin
3. Process Injection (T1055, Defense Evasion) - инъекция в легитимные процессы
4. Disable or Modify Tools (T1562.001, Defense Evasion) - отключение логирования или security-агентов

Атакующие также используют этап подготовки: Vulnerability Scanning (T1595.002, Reconnaissance) для обнаружения уязвимых целей и Exploits (T1588.005, Resource Development) для приобретения или разработки эксплойтов.

Корреляции для SIEM на каждом этапе:

T1190 - initial access: всплеск 4xx/5xx ответов от management-интерфейса, переходящий в успешную 200-сессию с нового IP; POST-запросы к admin-эндпоинтам из нехарактерных подсетей; вход без предшествующей MFA-сессии.

T1068 - privilege escalation: появление нового пользователя с admin-правами; изменение membership в привилегированных группах; выполнение root/admin команд из-под сервисной учётной записи без истории таких действий.

T1562.001 - defense evasion: остановка syslog-forwarding или смена syslog-destination; удаление или ротация log-файлов вне расписания; изменение конфигурации SNMP/NetFlow. Если syslog-destination поменялся в 3 ночи без тикета в ITSM - это не баг, это проблема.

Sigma-правило для обнаружения создания административного аккаунта на сетевом оборудовании:

title: Suspicious Admin Account Creation on Network Device
logsource:
  category: network_device
detection:
  selection:
    EventType|contains: 'user_create'
    PrivilegeLevel|contains: 'admin'
  condition: selection
level: critical
falsepositives:
  - Scheduled infrastructure maintenance

Два кейса CVSS 10.0: CVE-2026-20127 и CVE-2026-22769​

Оба zero-day добавлены в CISA KEV как actively exploited, оба - SSVC Act, оба - инфраструктурные appliance без EDR-покрытия. Разберём каждый.

CVE-2026-20127 - Cisco Catalyst SD-WAN, Authentication Bypass. CWE-287. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. EPSS 0.5895. KEV due date: 2026-02-27 (двое суток). Affected: Cisco Catalyst SD-WAN Manager (множество версий). CVSS-вектор читается так: неаутентифицированный удалённый атакующий (PR:N, UI:N) с минимальной сложностью (AC:L) получает полный контроль, а scope changed (S:C) - компрометация распространяется за пределы контроллера. По данным расследований, уязвимость эксплуатировалась как минимум с 2023 года: атакующие компрометировали контроллеры и добавляли malicious rogue peers в целевые сети. SD-WAN-контроллеры не покрываются EDR - компрометация оставалась незамеченной годами.

CVE-2026-22769 - Dell RecoverPoint for VMs, Hardcoded Credentials. CWE-798. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. EPSS 0.2200. KEV due date: 2026-02-21. Affected: Dell RecoverPoint for Virtual Machines, versions prior to 6.0.3.1 HF1. Hardcoded credential зашит в прошивку - неаутентифицированный атакующий со знанием этого пароля получает root-level persistence в ОС. Mandiant обнаружил уязвимость при расследовании инцидента: системы Dell RecoverPoint взаимодействовали с C2-серверами атакующих. Не сканер нашёл, не аудит - живой инцидент.

Общая черта: оба уязвимых продукта - не рабочие станции с EDR-агентом, а инфраструктурные appliance, где единственный источник телеметрии - сетевой трафик и логи самого устройства. Для таких активов incident response без патча строится исключительно на network-level visibility и ручной проверке конфигураций.

Чеклист: временные меры защиты при zero-day​

1. Проверить наличие CVE в CISA KEV - присутствие = автоматический P1
2. Оценить EPSS и SSVC - при EPSS > 0.3 и SSVC Act начинать реагирование немедленно
3. Идентифицировать все экземпляры уязвимого ПО через CMDB / asset inventory
4. Ограничить сетевой доступ к management-интерфейсам: ACL + MFA через jump-хосты
5. Принудительно сбросить учётные данные (кроме hardcoded credentials в firmware - смена пароля ОС их не устраняет)
6. Включить расширенное логирование и направить в SIEM
7. Провести ретроспективный IoC-поиск за 30–90 дней
8. Настроить поведенческие алерты: новые admin-аккаунты, изменения конфигурации, нетиповые исходящие подключения
9. Запросить у вендора timeline выхода hotfix
10. Задокументировать все компенсирующие меры для аудита и postmortem

Для организаций под ФЗ-152 и требованиями по защите КИИ: отсутствие документированных компенсирующих мер при known-exploited уязвимости - не просто операционный риск, а основание для оборотных штрафов. Документирование - такая же часть zero-day реагирования, как и сама изоляция.

В большинстве разобранных мной инцидентов с zero-day начальный вектор был одинаков: инфраструктурный appliance с management-интерфейсом, торчащим в интернет, без MFA, без ограничения по IP. Даже без знания о конкретной CVE базовый hardening закрыл бы значительную часть вектора.

Управление уязвимостями zero-day - не проблема скорости патчинга. Это проблема того, что большинство инфраструктур не готовы к ситуации, когда патча не существует в принципе. Выстроенный baseline поведения, микросегментация, мониторинг конфигураций, прописанный playbook на incident response без патча - не «продвинутая зрелость», а минимально достаточный уровень для организации, у которой хотя бы один edge-device доступен из интернета.

Mandiant M-Trends 2025: exploits остаются вектором начального доступа номер один - 38% всех расследованных инцидентов. Тренд не меняется третий год. Если процесс управления уязвимостями сводится к «ждём патч и накатываем», он сломается в первый же zero-day-инцидент. Тематический тред с playbook'ом по этой группе TTP - на codeby.net, там обсуждают адаптацию Sigma-правил и containment-процедур под конкретные SIEM-бэкенды.