BYOVD расшифровывается как Bring Your Own Vulnerable Driver, то есть «принеси свой уязвимый драйвер». В этой схеме злоумышленнику не нужна свежая брешь нулевого дня в Windows. Хакер приносит вполне себе легитимный подписанный драйвер, но зачастую устаревший и уязвимый, а затем заставляет систему его загрузить.
Проблема в том, что драйверы живут в самом привилегированном слое ОС. Ошибка или небезопасная функция внутри драйвера может дать универсальный рычаг: чтение и запись памяти ядра, выключение защитных механизмов, завершение процессов EDR, маскировку активности. На фоне этого обычные пользовательские трюки выглядят почти невинно.
BYOVD редко бывает «первым шагом». Чаще к нему приходят после фишинга, кражи учётных данных или эксплуатации уязвимости, которая уже дала права администратора. Установка драйвера почти всегда требует повышенных привилегий, и атакующие это учитывают, выстраивая цепочку так, чтобы BYOVD стал ускорителем во второй половине атаки.
Есть и психологический бонус: снаружи всё выглядит легально. Драйвер подписан, имя вендора знакомое, на диске лежит обычный .sys. Поэтому защита сводится не только к сигнатурам, но и к дисциплине: какие драйверы допускаются в инфраструктуру и кто имеет право их ставить.
Далее рассматривается, почему BYOVD работает, как выглядит типовая цепочка атаки и какие меры реально снижают риск. В конце есть ссылки на ресурсы, которые помогают держать руку на пульсе.
Почему уязвимый драйвер открывает дверь в ядро
Драйвер ядра выполняется в ring 0 и взаимодействует с внутренними структурами Windows. Если в драйвере есть небезопасная обработка управляющих кодов IOCTL, он может по запросу из пользовательского режима делать то, что обычной программе недоступно. Фактически пользовательский процесс получает «пульт управления» к опасным операциям, которые задуманы для обслуживания железа, диагностики или администрирования.
Самые частые возможности для атакующего: примитивы записи в память ядра, доступ к физической памяти или регистрам, слабая проверка прав на опасные операции, а иногда и прямые функции вроде завершения процессов или отключения отдельных защитных компонентов. Иногда это баг, а иногда наследие «диагностических» режимов, которые когда-то упрощали жизнь техподдержке, но в итоге упростили жизнь совсем другим людям.
Подпись драйвера добавляет веса атаке. Windows блокирует неподписанные компоненты, а BYOVD использует доверие к подписи как транспорт. Драйвер может входить в состав утилит для мониторинга железа, прошивки устройств, низкоуровневой диагностики, и потому выглядит как фон. Особенно в среде, где сотрудники любят «полезные тулзы», а ИТ отделу проще закрыть глаза, чем каждый раз спорить.
Ещё один практический плюс для атакующего: уязвимость в драйвере часто стабильнее, чем уязвимость в самой ОС. Драйвер годами не меняется, продолжает принимать опасные IOCTL, и одинаково хорошо работает на разных версиях Windows. Это делает BYOVD приятным инструментом для масштабирования атак, когда нужен предсказуемый результат, а не сложная комбинация условий.
В итоге атакующий получает воспроизводимый способ уйти в kernel. Для вымогателей и операторов вредоносов это прагматика: меньше сложной эксплуатации, больше контроля над машиной и больше шансов тихо выключить защиту до того, как она успеет «пожаловаться» в консоль.
Как выглядит атака BYOVD шаг за шагом
На машину попадает драйвер и небольшой пользовательский компонент, который общается с ним через IOCTL. Затем драйвер регистрируется как служба и загружается стандартными средствами Windows. Иногда это делается в открытую, иногда маскируется под установку легитимного ПО, иногда просто прячется в нетипичном каталоге с именем, похожим на что-то системное.
Ключевой момент для детекта — загрузка драйвера. До перехода в ring 0 защитникам проще реагировать: видны создание службы драйвера, появление нового .sys, попытки загрузки, события целостности кода. В этот момент многие EDR ещё способны остановить развитие атаки или хотя бы оставить заметный след в телеметрии.
Дальше злоумышленник использует уязвимость, чтобы выполнить операции в ядре. Типовые цели: выключить или ослепить EDR/AV, снять защитные флаги, подменить права процесса, подготовить скрытую загрузку другого драйвера или закрепление. Отдельно неприятный сценарий — когда уязвимый драйвер используется как трамплин, а затем в систему заносится уже откровенно вредоносный драйвер, который без этой подготовки не смог бы закрепиться.
После успешного «переезда» в kernel следы становятся более размазанными. Защитный агент может внезапно упасть или перестать видеть события, а система при этом внешне будет работать нормально. Поэтому BYOVD часто играет роль технической прокладки перед шифрованием или эксфильтрацией: сначала выключается «сигнализация», потом происходит всё остальное.
Схема чаще всего укладывается в короткую последовательность:
- Получение прав администратора.
- Доставка и регистрация уязвимого подписанного драйвера.
- Эксплуатация IOCTL для операций в режиме ядра.
- Отключение защиты и дальнейшие действия (шифрование, кража данных, устойчивость).
BYOVD не привязан к одной конкретной группировке. Он повторяется потому, что похожие драйверы встречаются в разных нишах, а эффект для атакующего почти всегда одинаковый: быстрый контроль над машиной на уровне ядра.
Где берут уязвимые драйверы и как защититься
Первый источник — публичные каталоги и исследования. Проект LOLDrivers собирает известные уязвимые и вредоносные драйверы и даёт материалы для детекта, а каталог драйверов удобен для поиска по имени и хэшам. Для расширения кругозора полезен разбор Cisco Talos.
Второй источник — анализ популярного софта. Драйвер может иметь опасные IOCTL просто потому, что разработчик когда-то сделал «удобный» интерфейс к железу. Для атакующего это почти готовая библиотека функций ядра, без необходимости писать свой драйвер с нуля. И да, это тот случай, когда «удобно» и «безопасно» оказываются по разные стороны баррикад.
Самая практичная защита — блокирование известных проблемных драйверов. Майкрософт развивает Microsoft Vulnerable Driver Blocklist и регулярно обновляет файл DriverSiPolicy.p7b. Начать стоит с документации по рекомендованным правилам блокировки драйверов, а также со справки, как управлять блоклистом через Windows Security: KB5020779.
Поверх блоклистов важна «гигиена прав»: меньше локальных администраторов, контроль установки драйверов, включённая изоляция ядра и HVCI, мониторинг нетипичных запусков sc.exe и pnputil.exe. Если ради совместимости блоклист отключали, лучше фиксировать исключения и пересматривать их регулярно, а не жить в режиме «потом разберёмся».
Для мониторинга полезны признаки, которые не зависят от имени драйвера:
- создание службы драйвера и последующая загрузка нового .sys;
- драйвер в нестандартном каталоге или с «одноразовым» именем;
- серия завершений процессов EDR/AV или отключение их компонентов;
- события Code Integrity, связанные с блокировкой или попыткой загрузки драйвера.
Для общего понимания контекста пригодятся разборы. У Elastic описана логика BYOVD и типовые сценарии применения. А у Майкрософт есть материал про центр отчётности по уязвимым и вредоносным драйверам, который помогает экосистеме быстрее реагировать.
Заключение
BYOVD держится на парадоксе доверия: подпись драйвера облегчает его попадание в систему, но не гарантирует безопасность функций. Если внутри есть опасный примитив, подпись превращается в пропуск в kernel, а не в барьер.
Поэтому защита должна быть скучной и системной: обновления Windows, включённый блоклист уязвимых драйверов, контроль администраторов и установка драйверов по правилам. Чем меньше в инфраструктуре «левых» утилит, которым нужен драйвер ради удобства, тем сложнее атакующему найти подходящую отмычку.
И последний практический вывод: новая служба драйвера или попытка загрузки неизвестного .sys файла заслуживает такого же внимания, как запуск подозрительного .exe. В эпоху BYOVD это часто один и тот же инцидент, просто на разных этажах системы, и лучше поймать его до того, как он станет заголовком отчёта об очередном «внезапном шифровании».
