В BYOVD меня больше всего цепляет парадокс. Вымогателю не обязательно тащить в Windows собственный вредоносный драйвер. Гораздо удобнее принести настоящий драйвер реальной компании, который годами использовался в диагностической программе, антивирусе, утилите разгона или промышленном оборудовании. Если разработчик оставил слишком мощный интерфейс без нормальной проверки прав, легальный компонент превращается в мост из обычной программы прямо в ядро Windows.
Поэтому фраза «Windows доверяет подписанному драйверу» объясняет проблему лишь наполовину. Цифровая подпись подтверждает происхождение и целостность файла, но не доказывает безопасность каждой функции внутри. Более того, современные Windows проверяют уже не одну подпись. Работают HVCI, списки уязвимых драйверов, App Control и новая политика доверия к драйверам. Несмотря на эти барьеры, BYOVD остаётся рабочей техникой. В марте исследователи насчитали почти 90 активных EDR-killer, из которых 54 использовали BYOVD и злоупотребляли 35 различными уязвимыми драйверами.
Дисклеймер. Материал предназначен для легального анализа атак, расследования инцидентов и защиты собственных систем. Соблюдайте законы своей страны, включая российское законодательство. Описанные механизмы нельзя применять для несанкционированного доступа, отключения чужой защиты или вмешательства в работу чужих компьютеров.
Почему драйвер ядра вообще способен спорить с EDR
Сначала уберу слишком красивое, но неверное объяснение. Нельзя сказать, что «драйвер находится ниже EDR и поэтому сильнее». Современный EDR сам использует драйверы ядра. Защитный продукт обычно состоит из пользовательских служб, процессов, файловых минифильтров, драйверов и удалённой инфраструктуры, куда уходит телеметрия.
Проблема BYOVD не в условной высоте слоя, а в возможностях, которые получает атакующий. Код режима ядра работает с гораздо большими привилегиями, чем обычное приложение. Если уязвимый драйвер разрешает читать или менять физическую память, обращаться к чувствительным объектам ядра либо завершать процессы без нормальной проверки вызывающей стороны, пользовательская программа получает опасный примитив.
Обычная программа
↓
запрос к драйверу
↓
уязвимый подписанный драйвер
↓
привилегированная операция в ядре
↓
вмешательство в работу EDRСвязь между приложением и драйвером часто строится через запросы IOCTL. Сами IOCTL совершенно нормальны. Через них пользовательская программа просит драйвер выполнить определённую операцию. Ошибка появляется, когда драйвер принимает слишком мощную команду от процесса, которому не следовало давать такую возможность.
Представим утилиту диагностики оборудования. Для своей работы драйверу действительно может понадобиться доступ к физической памяти, портам ввода-вывода или регистрам процессора. Разработчик даёт приложению нужный интерфейс, но недостаточно ограничивает доступ. Спустя несколько лет кто-то замечает, что через тот же интерфейс можно добраться до памяти ядра Windows. Для атакующего готовая уязвимость намного удобнее собственного драйвера, потому что файл уже подписан и когда-то считался нормальной частью программной экосистемы.
Ещё проще выглядит класс драйверов, которые сами умеют завершать процессы. Такой функционал встречался в антивирусах, криминалистических программах и системных утилитах. Если драйвер не проверяет, кто попросил завершить процесс, EDR-killer передаёт ему идентификатор защитного процесса, а всю грязную работу выполняет доверенный код в ядре.
Сам BYOVD обычно не даёт первоначальный доступ к компьютеру. Во многих реальных атаках злоумышленник уже располагает административными привилегиями или учётной записью с достаточными правами. Драйвер нужен позднее, когда надо убрать последний серьёзный барьер перед кражей данных и шифрованием.
Как BYOVD превратился из трюка в конвейер вымогателей
Типичная цепочка выглядит довольно прозаично. Атакующий получает доступ через украденную учётную запись, уязвимый сервис или удалённое администрирование, повышает привилегии, переносит на машину EDR-killer вместе с подходящим драйвером и пытается загрузить его в ядро. Если политики Windows не запрещают конкретный файл или класс драйверов, пользовательская часть инструмента начинает обращаться к уязвимому интерфейсу.
- Компрометация уже произошла. На машине есть атакующий с высокими привилегиями.
- На диск попадает драйвер. Файл может быть настоящим компонентом известного производителя.
- Windows решает, можно ли его загрузить. На решение влияют подпись, политика целостности кода, HVCI, блок-листы и App Control.
- EDR-killer открывает интерфейс драйвера. Дальше инструмент использует опасные функции, которые оставил разработчик.
- Защита теряет часть телеметрии или процессов. Способ зависит от конкретного драйвера и EDR-killer.
- Атакующий получает короткое окно. В этот момент обычно запускают следующие стадии атаки, включая шифрование.
Хороший современный пример дала Qilin. Исследованный инструмент использовал два драйвера. Первый представлял собой переименованный драйвер ThrottleStop и предоставлял низкоуровневый доступ к физической памяти. Через полученные возможности вредонос вмешивался в механизмы наблюдения EDR в ядре. Затем второй драйвер помогал завершать защитные процессы.
В образце находился список более 300 имён драйверов продуктов безопасности. Здесь легко получить громкий, но неверный вывод, будто Qilin одновременно «выключает 300 антивирусов». Список представляет каталог потенциальных целей. На конкретном компьютере вредонос ищет установленные продукты и работает с теми компонентами, которые действительно присутствуют.
Ещё показательнее Warlock. Группировка не пыталась найти один идеальный EDR-killer. В некоторых вторжениях запускалось сразу несколько таких инструментов, иногда десятки. За всё время наблюдений операторы злоупотребляли как минимум девятью разными драйверами. Получается почти перебор вариантов. Не сработал первый способ против конкретной версии Windows и защитного агента, пробуют следующий.
Такой подход хорошо объясняет индустриализацию BYOVD. Разработчику шифровальщика не нужно каждый месяц переписывать средство обхода EDR. Вокруг ransomware сформировался отдельный слой инструментов, которые специализируются именно на подавлении защиты. Одни используют уязвимые драйверы, другие легальные anti-rootkit утилиты, третьи обходятся без драйверов и мешают связи агента с сервером. Поэтому ставить знак равенства между «EDR-killer» и «BYOVD» тоже неправильно.
Повторное использование драйверов создаёт ещё одну ловушку для расследования. Один и тот же уязвимый компонент встречается у несвязанных группировок, а один EDR-killer со временем может переехать на другой драйвер. Найти знакомый .sys и сразу назвать автора атаки нельзя.
Старый EnCase, Huawei и драйвер, которого не было ни в одном блок-листе
Кейс EnCase особенно хорошо показывает историческую проблему Windows. В начале года атакующие использовали драйвер EnPortv.sys из криминалистического ПО EnCase. Сертификат, которым подписывался компонент, выпустили ещё в 2006 году, срок его действия закончился в 2010-м, позднее сертификат отозвали. Несмотря на возраст, исследованная система разрешила загрузку.
Здесь легко исказить факт фразой «хакеры взломали Windows драйвером 2006 года». Известная дата относится прежде всего к сертификату. Главное в другом. Старые правила cross-signing позволяли ряду исторических драйверов продолжать работать благодаря совместимости, цепочке доверия и временной метке подписи. У EnCase имелась штатная функция завершения процессов из ядра, которой EDR-killer воспользовался против 59 процессов защитных продуктов. Инструмент повторял попытки каждую секунду, поэтому простой перезапуск службы проблему не решал.
Но переносить тот февральский результат на любую актуальную Windows уже нельзя. С весны Microsoft начала убирать доверие к устаревшей программе cross-signing. Новая Windows Driver Policy распространяется на современные Windows 11 и Windows Server 2025. Сначала система работает в режиме аудита. После достаточного времени работы и нескольких перезагрузок политика может перейти в режим принудительного применения. Тогда старые cross-signed драйверы, которые не входят в разрешённый список и не получили современную подпись WHCP, перестают загружаться.
Изменение сильно бьёт по старому классу BYOVD, но не закрывает всю проблему. Новый уязвимый драйвер может иметь современную подпись. Более того, защитникам заранее неизвестны все опасные драйверы.
Весной в реальной атаке обнаружили подписанный аудиодрайвер Huawei, который позволял пользовательской программе завершать процессы из режима ядра без достаточной проверки. На момент обнаружения драйвер ещё не фигурировал в известных публичных базах уязвимых драйверов и рекомендуемом блок-листе Microsoft. Для атакующего такой компонент почти идеален. Защитные продукты ещё не знают конкретный хэш или версию, а Windows видит легально подписанный файл.
Летом появился ещё более наглядный пример. Группа The Gentlemen использовала ранее публично не описанную уязвимость в драйвере ktapi.sys от Kontron. Через функции работы с физической памятью атакующие получили возможность вмешиваться в память ядра и завершать защищённые процессы Microsoft Defender, ESET, Cortex XDR и SentinelOne. На момент расследования драйвера не было в публичных списках известных BYOVD-компонентов.
История с ktapi.sys одновременно показывает пользу нового курса Microsoft. Драйвер относился к старой cross-signed категории, поэтому новая политика доверия способна заблокировать конкретный сценарий на поддерживаемых системах после перехода политики в режим принудительного применения. Но следующий найденный драйвер может быть уже WHCP-подписанным, поэтому поставить обновление Windows и забыть про BYOVD не получится.
Есть и более неприятный вариант, который формально вообще не относится к классическому BYOVD. В прошлых атаках злоумышленникам удавалось получить подпись Microsoft для специально созданных вредоносных драйверов. Такие инструменты вроде POORTRY тоже использовали привилегии ядра для борьбы с EDR. Разница принципиальная. В BYOVD преступник злоупотребляет ошибкой в нормальном драйвере, а здесь вредоносным был уже сам драйвер. Оба сценария напоминают, что подпись нельзя читать как заключение аудитора безопасности.
Почему HVCI и блок-лист помогают, но не дают абсолютной защиты
Главная системная защита от известных BYOVD-сценариев состоит из нескольких независимых слоёв.
Microsoft Vulnerable Driver Blocklist содержит известные опасные драйверы. В актуальных Windows 11 блокировка включена по умолчанию, а при работающей целостности памяти, Smart App Control или S mode список также применяется принудительно. Microsoft обновляет правила регулярно и дополнительно доставляет изменения через обновления Windows.
Проблема заложена в самой природе списка. Сначала кто-то должен найти опасный драйвер, доказать риск, передать сведения производителю или Microsoft, после чего появится блокировка. Атакующий может выбрать новый или редкий компонент быстрее. Microsoft сама предупреждает, что список не гарантирует блокировку каждого уязвимого драйвера.
Нельзя бездумно расширять такой список до всего подозрительного. Драйвер может обслуживать хранилище, резервное копирование, сетевой адаптер или специализированное промышленное оборудование. Ошибочная блокировка способна сломать приложение, отключить устройство, а в редких случаях привести к синему экрану. Именно поэтому блок-лист всегда балансирует безопасность и совместимость.
HVCI, или «Целостность памяти», решает другую часть задачи. Windows использует аппаратную виртуализацию и выносит проверки целостности кода в изолированную среду. Исполняемые страницы памяти ядра нельзя одновременно сделать записываемыми, а часть попыток изменить чувствительный код ядра становится значительно сложнее. HVCI также обеспечивает применение списка уязвимых драйверов.
Проверять лучше не только положение переключателя в интерфейсе Windows. Реальное состояние можно посмотреть через PowerShell.
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace rootMicrosoftWindowsDeviceGuardВ массиве SecurityServicesRunning наличие значения 2 означает, что целостность памяти действительно работает. Полезная проверка для корпоративного парка, потому что настроенная политика ещё не гарантирует фактический запуск HVCI. Несовместимый драйвер или конфигурация оборудования могут помешать защите включиться.
App Control for Business идёт дальше блок-листа. Вместо бесконечного вопроса «знаем ли мы этот плохой драйвер» организация ограничивает набор кода, которому вообще разрешено работать. Для серверов, рабочих станций администраторов и других чувствительных систем разрешительная модель обычно устойчивее попыток догнать каждый новый BYOVD по хэшу.
Есть ещё правило Attack Surface Reduction, которое блокирует запись известных уязвимых подписанных драйверов на диск. У правила есть принципиальное ограничение. Если опасный драйвер уже находится в системе, само ASR-правило не запрещает его загрузку. Здесь нужны блок-лист, HVCI или App Control.
- Проверить реальную работу HVCI. Не считать включённый параметр в политике доказательством.
- Установить актуальные обновления Windows. Новая политика драйверов меняет правила доверия к старым cross-signed компонентам.
- Использовать App Control на критичных системах. Разрешительная модель уменьшает зависимость от постоянно догоняющего блок-листа.
- Следить за появлением kernel-служб и новых драйверов. Неожиданная загрузка
.sysпосле удалённого административного входа заслуживает расследования даже при корректной подписи. - Отправлять телеметрию за пределы конечной машины. Сетевые журналы, SIEM, VPN и контроллеры домена сохраняют картину, когда локальный агент уже ослеплён.
- Сокращать число локальных администраторов. Большинство практических BYOVD-цепочек начинается намного раньше загрузки драйвера.
- Обновлять OEM-утилиты и старое корпоративное ПО. Опасные драйверы приезжают не только с вредоносами, но и с когда-то штатными программами.
Миф «если EDR хороший, его нельзя отключить» слишком оптимистичен. EDR серьёзно усложняет атаку, но остаётся частью той же системы, которую защищает. Когда противник уже получил административный доступ и нашёл путь к привилегированным операциям ядра, борьба идёт не между «антивирусом и вирусом», а между разными компонентами Windows с очень высокими правами.
Обратный миф тоже неверен. BYOVD не является универсальной кнопкой выключения Windows. Атакующему нужны привилегии, подходящий драйвер, рабочая уязвимость, совместимость с конкретной сборкой системы и отсутствие политики, которая запретит загрузку. HVCI, блок-лист, новая Windows Driver Policy и App Control заметно сокращают пространство для манёвра.
Я бы поэтому проверял защиту не вопросом «стоит ли у нас EDR». Гораздо полезнее спросить, сможет ли неизвестный драйвер вообще загрузиться, действительно ли работает HVCI, кто контролирует локальных администраторов, замечает ли SOC появление kernel-службы и останутся ли журналы после внезапного исчезновения агента. BYOVD опасен не потому, что Windows беззащитна. Приём опасен потому, что вымогатели научились искать слабое место между совместимостью старого программного мира и современной моделью защиты, а затем превращать найденный драйвер в готовый промышленный инструмент.
