Уязвимости нулевого дня опасны не только тем, что для них еще нет исправления.
Для бизнеса это момент, когда привычная логика защиты ломается: патча нет, сигнатуры могут появиться позже, а сервисы должны продолжать работать. При этом злоумышленник уже может использовать уязвимость, получать доступ к системе, закрепляться внутри сети и готовить следующий этап атаки.
Поэтому Zero-Day — это не только техническая проблема для инженеров. Это период неопределенности, в котором компании нужно быстро решить, какие сервисы изолировать, какие временные меры включить, какие данные сохранить для расследования и что нельзя возвращать в работу без проверки.
Искать нужно поведение, а не «тот самый файл»
Главная сложность Zero-Day в том, что защитные средства могут еще не знать конкретный эксплойт. Но после проникновения атакующий обычно действует не хаотично. Ему нужно выполнить команды, закрепиться, выйти на управляющую инфраструктуру, найти учетные записи, изучить сеть и подготовить движение дальше.
Именно поэтому в таких сценариях важнее поведенческие признаки. Например, веб-сервис внезапно запускает командную оболочку, загружает .NET-сборки, создает файлы в системных каталогах или инициирует исходящие соединения, которых раньше не было. Для легитимного сервиса такое поведение нетипично, даже если точной сигнатуры под конкретную уязвимость еще нет.
«Самые надежные индикаторы — поведенческие, а не сигнатурные. Злоумышленник может использовать новый эксплойт, но его действия после проникновения часто следуют предсказуемым сценариям», — говорит Иван Бурмистров, пресейл-инженер UDV Group.
На практике команде ИТ и ИБ стоит смотреть сразу на несколько зон. В процессах важны действия, которые не соответствуют роли сервиса. В сети — нестандартные исходящие соединения: неизвестные адреса, динамические домены, подключения в нехарактерное время или в регионы, с которыми компания обычно не работает. На хосте — новые файлы в системных каталогах, подозрительные операции сервисных учетных записей, изменения в реестре и планировщике задач.
Ключевой принцип здесь простой: вопрос не в том, как называется файл, а в том, что делает процесс. Если поведение не соответствует роли системы, это повод для расследования.
До патча нужно снижать поверхность атаки
Ожидание исправления не должно превращаться в паузу. Между публикацией информации об уязвимости и установкой патча всегда есть окно риска. В сложной инфраструктуре оно может длиться не часы, а дни: нужно протестировать обновление, понять влияние на сервисы, согласовать окно работ и провести установку.
В этот период задача компании — снизить вероятность эксплуатации и ограничить последствия, если атака уже началась. На периметре нужно усилить правила NGFW и WAF, чтобы блокировать подозрительные запросы по характерным паттернам. На конечных точках — включить более строгий режим мониторинга и блокировки в EDR. Такие решения могут реагировать не на конкретную уязвимость, а на техники: внедрение кода, подозрительную работу с памятью, попытки обхода защиты.
Отдельно важна сегментация. При Zero-Day нельзя гарантировать, что первичный доступ не будет получен. Но можно сделать так, чтобы компрометация одного сервиса не открывала путь к домену, базам данных, резервным копиям или системам управления инфраструктурой.
Базовые механизмы защиты операционной системы тоже нельзя оставлять «на потом». В период ожидания патча стоит проверить, включены ли штатные защитные функции ОС, как настроен EDR, где разрешено выполнение скриптов, какие права есть у сервисных учетных записей и насколько ограничены маршруты между сегментами.
Первый час решает, останутся ли доказательства
Если есть подозрение, что уязвимость уже использовали, самая опасная реакция — начать «чистить» систему сразу. В панике инженеры могут выключить сервер, удалить подозрительные файлы или быстро восстановить сервис из бэкапа. Иногда это останавливает видимый симптом, но уничтожает следы, которые нужны для расследования.
При Zero-Day особенно важны оперативная память и активные процессы. Эксплойт может работать без записи полезной нагрузки на диск, выполнять команды внутри живого процесса и оставлять минимум следов в файловой системе. Если сервер просто выключить, значительная часть картины исчезнет.
«Правило “золотого часа” для Zero-Day — сначала сохранить, потом чистить», — подчеркивает Иван Бурмистров, пресейл-инженер UDV Group.
Оптимальная последовательность начинается с изоляции хоста на уровне сети. Можно отключить порт коммутатора, перевести устройство в отдельную VLAN или заблокировать коммуникации на межсетевом экране. Но питание лучше не выключать, если нет прямой угрозы для бизнеса или оборудования.
Дальше нужно снять дамп оперативной памяти, собрать логи веб-сервера, ОС, EDR, NTA и NGFW хотя бы за последние 48 часов. Это помогает восстановить цепочку событий: кто подключался, какие запросы приходили, какие процессы запускались, куда уходили соединения и какие учетные данные могли быть затронуты.
Найденные IP-адреса, домены и хэши стоит временно блокировать на периметре, даже если атакующий потом сменит инфраструктуру. Такая блокировка не решает проблему полностью, но помогает остановить текущую активность и выиграть время.
Бэкап может вернуть злоумышленника обратно
После Zero-Day нельзя слепо доверять самому свежему бэкапу. Если резервная копия была создана уже после проникновения, восстановление может вернуть в систему тот же бэкдор, измененные настройки или следы закрепления. Поэтому перед возвратом сервисов важно понять, когда именно началась атака и какие точки восстановления могли быть «грязными».
Еще одна частая ошибка — включить систему после удаления вредоносного файла, не сменив учетные данные. Если атакующий успел получить привилегированные пароли или сервисные аккаунты, он может вернуться легитимным способом. В таком случае удаление файла не закрывает инцидент.
Перед восстановлением нужно проверить механизмы закрепления, сервисные учетные записи, сетевые соединения, задачи планировщика, изменения в реестре и доступ к критичным сегментам. Пароли учетных записей с высокими привилегиями должны быть заменены, а резервные копии — защищены от изменения и удаления со стороны атакующего.
Zero-Day проверяет не патч-менеджмент, а готовность к неопределенности
Патч закрывает уязвимость, но не отвечает на вопрос, что уже произошло до его установки. Именно поэтому защита от Zero-Day не сводится к скорости обновления. Компании нужны заранее подготовленные временные меры, понятный порядок изоляции, сбор артефактов, сетевая сегментация, контроль поведения процессов и проверенный сценарий восстановления.
Главная ошибка бизнеса — ждать инструкции от вендора как единственного решения. При неизвестной уязвимости времени на идеальный сценарий не будет. Работает то, что подготовлено заранее: кто принимает решение об изоляции, какие логи собираются, как сохраняется память, где проверяются исходящие соединения, какие бэкапы можно использовать и какие учетные данные нужно сменить до возврата системы в работу.
Zero-Day невозможно полностью исключить. Но можно не дать одной неизвестной уязвимости превратиться в потерю контроля над сетью. Для этого компания должна искать не только эксплойт, а поведение атакующего, и сохранять доказательства раньше, чем начнет чистить последствия.
Комментарии