Как отлавливать BYOVD-атаки: чек-лист детектирования с примерами

EDR кладут на лопатки через легитимный подписанный драйвер — разбираем, как работает BYOVD, смотрим на реальные кейсы Lazarus и RansomHub и даём готовые правила детектирования для SIEM KUMA.

Альфа-Банк

, отредактировано

Роман Мгоев

Специалист по анализу киберугроз в Альфа-Банке

EDR — Endpoint Detection and Response (EDR) — технология кибербезопасности для мониторинга, обнаружения и реагирования на угрозы на конечных устройствах (рабочие ноутбуки, серверы, смартфоны сотрудников). Это ПО непрерывно собирает данные о процессах, взаимодействии с реестром, запуске программ, файлов, сетевых подключениях на устройствах и если, допустим, некий процесс выглядит подозрительно, система не только бьёт тревогу, но и нейтрализует опасность, например, изолирует устройство от сети или откатывает изменений.

EDR — это очень мощное ПО. Можно сказать, что это основа современной безопасности.

Но есть такая техника, при которой EDR лежит кверху лапками, как безобидный щеночек, а не как сторожевой пес размером с трактор. Эта техника называется BYOVD (Bring Your Own Vulnerable Driver), посредством которой злоумышленники проникают в систему, повышают привилегии и потом делают то, что им нужно.

В статье разберу чем опасны BYOVD-атаки и поделюсь готовыми правилами детектирования, которые можно распечатать и всегда держать под рукой.

Теоретическая часть: как работает BYOVD-атака

BYOVD очень опасная техника.

Программы-вымогатели BlackByte и AvosLocker использовали BYOVD для обхода средств защиты.
По данным Huntress, в 2024 году значительная доля атак шифровальщиков включала обход EDR — в том числе через уязвимые драйверы.
BYOVD — типовая фаза ransomware-операций, а ransomware — главная киберугроза для российского бизнеса. В 2024 году шифровальщики парализовали СДЭК на трое суток (300 тыс. посылок в день), положили платёжные терминалы сети «Верный» по всей стране (убытки 120–140 млн руб./день), а в июле 2025-го хакеры уничтожили ИТ-инфраструктуру «Аэрофлота», вынудив отменить более 100 рейсов. Во всех этих инцидентах ключевым этапом было отключение защиты — и именно BYOVD остаётся самой распространённой техникой для этого. По данным Symantec, в 2026 году BYOVD стал наиболее частым методом обхода EDR в ransomware-атаках.
BYOVD — обязательный компонент в кибершпионаже. К слову, в процессе знаменитой масштабной операции по кибершпионажу, называемой Operation DreamJob, проводимой группировкой Lazarus, использовался BYOVD. Группировка создавала фейковые профили рекрутеров в LinkedIn и рассылала жертвам «вакансии» — ISO-файлы с вредоносной начинкой: многоступенчатой цепочкой загрузчиков (RollFling → RollSling → RollMid → KaolinRAT), финальным звеном которой был FudModule — руткит, работающий на уровне ядра.

Практически во всех крупных ransomware-инцидентах ключевой этап — отключение EDR перед шифрованием. Если описать BYOVD в двух словах, то Bring Your Own Vulnerable Driver (BYOVD) — это техника, при которой злоумышленник использует уязвимость Windows, чтобы обойти EDR и получить привилегированный доступ к системе.

Дело в том, что Windows делит весь исполняемый код на два уровня доверия — в архитектуре x86 они называются кольцами защиты (protection rings): Ring 3 пользовательский режим, и Ring 0 режим ядра.

Обычные программы, вроде браузера, работают в Ring 3 и имеют ограниченный набор привилегий. А в ядре (Ring 0) работают ntoskrnl.exe (само ядро), HAL, файловая система, сетевой стек и все драйверы. А имея доступ к Ring 0 можно модифицировать любые структуры данных, завершать любые процессы и отключать любую телеметрию, что и делают BYOVD программы.

Доступ к Ring 0 можно получить посредством драйвера, потому что драйверы в Windows работают в ring 0 — то есть на уровне ядра, с максимальными привилегиями. Чтобы обезопасить ядро от нелегитимных пользователей, Microsoft ввёл обязательную подпись драйверов (DSE — Driver Signature Enforcement) и в теории, загрузить произвольный код в ядро нельзя — драйвер должен быть подписан сертификатом, которому доверяет Microsoft.

На деле в BYOVD-атаках используются именно легитимные подписанные драйверы, потому что Windows не проверяет списки отзыва сертификатов (CRL) при загрузке драйверов — на этом этапе загрузки ОС сеть ещё недоступна. Например, в феврале 2026 года Huntress обнаружил атаку, где 20-летний драйвер EnCase (драйвер EnCase подписан сертификатом от 15 декабря 2006 года) с отозванным сертификатом мог убивать 59 EDR-процессов.

EDR — это такой гибрид, у которого пользовательский интерфейс работает в Ring 3, а для мониторинга он устанавливает свой kernel-mode драйвер в Ring 0. Мониторинг EDR основан на kernel callbacks — специальных функциях- уведомлениях, которые ядро вызывает при определённых событиях, например, когда создаётся процесс — срабатывает PsSetCreateProcessNotifyRoutine, а когда загружается DLL — PsSetLoadImageNotifyRoutine.

Коллбэки регистрируются EDR-драйвером при загрузке, и ядро хранит их адреса в служебных структурах — таких как CallbackListHead.

Помимо kernel callbacks, EDR перехватывает вызовы API-функций через function-hooking DLL, которая инжектируется в каждый процесс. Эти хуки работают в user mode и подменяют первые байты функций ntdll.dll (например, NtAllocateVirtualMemory) на переход в код EDR.

Поэтому даже после отключения kernel callbacks EDR может получать телеметрию через user-mode хуки — и наоборот. Продвинутые руткиты атакуют оба уровня одновременно.

Если атакующий получает возможность писать в память ядра, он может обнулить адреса коллбэков или флаги их активности — и ядро перестанет уведомлять EDR о любых событиях. Процесс антивируса при этом продолжает работать, но по факту ничего не видит. А дальше можно делать что угодно.

Microsoft поддерживает встроенный блок-лист уязвимых драйверов, но он покрывает лишь малую часть из сотен известных уязвимых драйверов в базе LOLDrivers.

Как так происходит? Есть три подхода к получению kernel-доступа, в том числе через BYOVD и смежные техники.

Подход 1: N-day уязвимости в сторонних драйверах

Атакующий берёт драйвер известного производителя (Dell, Intel, Realtek, MSI и десятки других) с уже обнаруженной уязвимостью. Драйвер подписан валидным сертификатом, DSE его пропускает. Через уязвимость (обычно это IOCTL, который позволяет произвольное чтение/запись физической или виртуальной памяти) атакующий получает примитивы для модификации ядра.

Примечание. Проект LOLDrivers.io на сегодня каталогизирует сотни таких драйверов.

Например, таким образом действовал инструмент FudModule группировки Lazarus (HIDDEN COBRA, APT38) — одной из самых технически продвинутых APT-группировок, связанных с КНДР. Первая версия FudModule (обнаружена ESET в 2022 году) эксплуатировала уязвимость CVE-2021-21551 в драйвере Dell dbutil_2_3.sys. Этот драйвер, предназначенный для обновления BIOS и firmware ноутбуков Dell, содержал критическую уязвимость: он принимал IOCTL-запросы, позволяющие читать и записывать произвольную физическую память без каких-либо проверок вызывающего процесса.

Для атакующего — находка: драйвер подписан Dell, Microsoft ему доверяет, а через IOCTL можно получить полный контроль над памятью ядра. Lazarus сбрасывали этот драйвер на диск, загружали через sc.exe create / sc.exe start и получали примитивы чтения/записи ядра.

Подход 2: Злоупотребление PreviousMode

Через эксплуатацию уязвимости атакующий меняет поле PreviousMode в структуре _KTHREAD текущего потока с UserMode (1) на KernelMode (0). После этого системные вызовы NtWriteVirtualMemory и NtReadVirtualMemory перестают проверять границы памяти и позволяют напрямую модифицировать пространство ядра из user mode.

[Схема: Архитектура Windows (User Mode ↔ Kernel Mode) и BYOVD-атака с отключением EDR через уязвимый драйвер]

Подход 3: 0-day в компонентах Windows

Более сложный путь: атакующий находит уязвимость в штатном драйвере операционной системы. Именно так поступила (опять же) группировка Lazarus с CVE- 2024-21338 в appid.sys (компонент AppLocker). В 2024 году группировка обновила FudModule до версии 2.0 и вместо стороннего драйвера Dell они нашли и проэксплуатировали 0-day уязвимость в appid.sys, штатном компоненте Windows, отвечающем за AppLocker.

Уязвимость имеет номер CVE-2024-21338 и её суть в том, что драйвер appid.sys содержал IOCTL, позволяющий вызвать произвольную функцию ядра с частичным контролем над первым аргументом. Для эксплуатации требовался LOCAL_SERVICE account — Lazarus получал его через имперсонацию.

Цепочка эксплуатации выглядела так:

Имперсонация LOCAL_SERVICE через стандартные механизмы Windows.
Вызов уязвимого IOCTL в appid.sys для исполнения произвольной функции ядра.
Через полученный примитив — модификация поля PreviousMode в _KTHREAD текущего потока (с UserMode на KernelMode).
Теперь NtWriteVirtualMemory / NtReadVirtualMemory можно вызывать из user mode без проверки границ → полный R/W доступ к памяти ядра.

Преимущество перед классическим BYOVD очевидно: не нужно сбрасывать файл на диск, не нужно загружать сторонний драйвер — appid.sys уже есть в каждой системе с включённым AppLocker. Это существенно снижает IoC и затрудняет детектирование.

Публичные тулкиты: BYOVD для всех

При этом BYOVD — это дешевый вид атаки — в 2024–2025 года готовые инструменты появились как грибы после дождя: на даркнет-форумах за несколько сотен долларов можно купить EDRKillShifter, AuKill, Blackout и прочее ПО для атак.

И при этом нет нужды обладать глубокими знаниями ядра Windows, достаточно скачать готовый тулкит. Поэтому атаки стали повсеместными, что я продемонстрирую на примерах реальных кейсов последних двух лет.

№1. BYOVD встраивается ВНУТРЬ ransomware

В феврале 2026 года Symantec зафиксировал новый паттерн: группировка Reynolds встроила уязвимый драйвер NSecKrnl прямо в payload шифровальщика. Раньше BYOVD-компонент и ransomware были отдельными файлами с временным зазором между ними — этот зазор давал SOC шанс среагировать. Теперь одного бинарника достаточно для отключения EDR и шифрования. По оценке Symantec, BYOVD стал самой частой техникой обхода защиты в ransomware-атаках 2026 года.

№2. POORTRY: кастомный вредоносный драйвер

Ещё интереснее POORTRY (Abyssworker) — не уязвимый легитимный драйвер, а специально написанный вредоносный драйвер, к которому атакующие получили валидную подпись через украденные сертификаты WHCP. Он маскировался под антивирусный компонент (например, драйвер Malwarebytes) и использовался в атаках Medusa и Osiris.

№3. RansomHub и EDRKillShifter

Группировка RansomHub разработала собственный инструмент EDRKillShifter, эксплуатирующий уязвимый драйвер TrueSight.sys. Инструмент стал стандартным компонентом их ransomware-набора и использовался для отключения EDR перед развёртыванием шифровальщика. По данным исследователей, EDRKillShifter применялся в десятках инцидентов в 2024 году.

№4. Kasseika: антивирусный драйвер против антивируса

Группировка Kasseika использовала ироничный подход — уязвимый драйвер антивирусного продукта (Martini.sys от TG Soft’s VirIT) для отключения конкурирующих EDR-решений. Цепочка атаки: через PsExec распространялся загрузчик, который сбрасывал уязвимый антивирусный драйвер, загружал его и через IOCTL завершал процессы защитных решений. После этого развёртывался шифровальщик.

№5. Deadlock: Baidu против безопасности

В декабре 2025 года Cisco Talos задокументировал новый вариант вымогателя Deadlock, использующий уязвимый драйвер Baidu Antivirus (BdApiUtil.sys, CVE- 2024-51324).

Атакующие использовали лоадер EDRGay.exe, который сбрасывал драйвер под именем DriverGay.sys в директорию Videos жертвы. Через IOCTL 0x800024b4 лоадер вызывал ZwTerminateProcess() для завершения всех EDR-процессов. Уязвимость квалифицирована как Improper Privilege Management — непривилегированный пользователь мог завершить любой системный процесс.

№6. BlackByte : систематический подход

BlackByte продемонстрировал системный подход к BYOVD: группировка использовала несколько уязвимых драйверов в разных кампаниях, включая RTCore64.sys и драйверы из базы LOLDrivers. Особенность их подхода — интеграция BYOVD-компонента непосредственно в цепочку развёртывания ransomware, с автоматическим выбором драйвера в зависимости от целевой системы.

Список ransomware-групп, использующих BYOVD, продолжает расти: Qilin (драйверы Zemana и Toshiba), Akira (драйвер Intel), Play, BianLian, Medusa, Rhysida, Cuba, GhostLocker, INC, Interlock (GameDriverx64.sys, CVE-2025- 61155). BYOVD стал стандартной фазой операции ransomware.

Разберём BYOVD-тулкит на примере Blackout

С точки зрения детектирования публичные тулкиты — это одновременно проблема и возможность. Проблема в том, что порог входа для атакующего стал минимальным, а возможность, потому что их поведение предсказуемо и создаёт чёткие IoC: фиксированные хэши драйверов, характерные паттерны создания сервисов, списки процессов для убийства.

Большинство BYOVD-инструментов следуют одному паттерну: сбросить уязвимый драйвер на диск (часто в %TEMP% или %APPDATA%), создать и запустить сервис для его загрузки, через IOCTL получить примитив завершения произвольного процесса и последовательно убить все EDR/AV процессы по списку.

Разберем цепочку событий, которую генерирует типичная BYOVD-атака на примере публичного тулкита Blackout (ZeroMemoryEx) в тестовой среде (даже если атака не завершилась успехом)

Что такое Blackout? Это открытый инструмент на GitHub, реализующий классический паттерн BYOVD: сбросить на диск подписанный уязвимый драйвер, загрузить его через SCM (Service Control Manager) и через IOCTL-запрос завершить целевой процесс из Ring 0. Использование тривиально — достаточно указать PID жертвы:

Blackout.exe -p <PID_процесса>

Запуск в тестовой среде. Находим PID Sysmon и запускаем Blackout:

			C:\Blackout> Blackout.exe -p 2792
 driver path: C:\Blackout\Blackout.sys
 Loading Blackout.sys driver ..
 Service created successfully.
 faild to load driver, try to run the program as administrator!!

Blackout успешно создал сервис для загрузки kernel-драйвера,

...но сам драйвер не загрузился, потому что сертификат подписи драйвера (GMEREK Systemy Komputerowe, Польша) отозван Microsoft и внесён в Certificate Trust List операционной системы:

			sc start TestBlackout
 [SC] StartService: ошибка: 2148204812:
 Сертификат был отозван поставщиком этого сертификата.

Скриншот cs start — ошибка отзыва сертификата.

Драйвер Blackout.sys подписан валидной цифровой подписью — но Microsoft, узнав об использовании этого драйвера в атаках, отозвал сертификат и добавил его хэш в системный блок-лист (Disallowed Certificate Store). Windows проверяет этот список при каждой загрузке драйвера — даже без доступа к интернету, потому что CTL вшит в ОС.

Это один из механизмов защиты от BYOVD, но с существенным ограничением: он работает только для уже известных драйверов. А база LOLDrivers.io содержит сотни уязвимых драйверов, и Microsoft физически не успевает отзывать все сертификаты. Поэтому атакующие просто берут менее известный драйвер — и блокировка не срабатывает.

Что увидит SOC. Несмотря на неудачную загрузку, попытка атаки оставила чёткие следы в телеметрии:

Event ID 7045 (System log — Service Control Manager).

Это событие — ключевой индикатор. Создание нового сервиса с типом «драйвер режима ядра», где путь к файлу указывает за пределы System32\drivers\ — аномалия, которая должна вызывать алерт максимального приоритета.

Хэш драйвера (SHA256): 18C909A2B8C5E16821D6EF908F56881AA0ECCEEACCB5FA1E54995935FCFD1 2F7

https://www.loldrivers.io/

Есть хорошие новости: каждый этап BYOVD оставляет следы — надо знать, куда смотреть. Давайте приступим к финальной части статьи — к выстраиванию эшелонированного детектирования, не привязанного к конкретной SIEM-платформе.

Детектирование BYOVD: что и как мониторить

Правила детектирования BYOVD делятся на два типа.

Brittle-детекты — ловят конкретные IoC: хэш известного уязвимого драйвера, имя файла, путь. Они дают минимальный false positive, но обходятся простой заменой драйвера.
Robust-детекты — ловят поведение: цепочка «файл .sys → сервис → завершение EDR» сработает на любой неизвестный тулкит, но может дать ложные срабатывания на легитимную установку драйверов.

Эшелонированная стратегия строится на комбинации обоих типов.

Детект 1. Загрузка известного уязвимого драйвера

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation), T1562.001 (Impair Defenses: Disable or Modify Tools).

Самый базовый и эффективный детект — сопоставление хэшей загружаемых драйверов с базой LOLDrivers.io. Проект предоставляет актуальный список хэшей (SHA256, MD5, SHA1) всех известных уязвимых и вредоносных драйверов, а также готовые Sigma-правила.

Логика алерта:

Событие: загрузка драйвера (Sysmon Event ID 6 или аналог). Условие: SHA256-хэш загруженного файла совпадает с записью в базе LOLDrivers. Severity: Critical.

Дополнительные индикаторы, усиливающие уверенность:

Драйвер загружается из нетипичного расположения (%TEMP%, %APPDATA%, %USERPROFILE%, директория Downloads).
Имя драйвера не соответствует ожидаемому для данной системы (например, Dell dbutil на машине без оборудования Dell).
Драйвер сбрасывается на диск непосредственно перед загрузкой (создание файла + загрузка драйвера в окне < 60 секунд).
LOLDrivers.io отдаёт готовые Sigma-правила и CSV с хэшами для импорта в SIEM — не нужно собирать вручную.

Учти ограничение: хэш-детекты обходятся через CVE-2013-3900 (см. ниже).

			detection:
  selection:
    EventType: DriverLoad
    Hashes|contains_any:
      - <SHA256 из LOLDrivers.io>
  condition: selection
 
# Усиление: драйвер из подозрительной директории
  filter_path:
    DriverPath|startswith:
      - 'C:\\Windows\\System32\\drivers\\'
      - 'C:\\Windows\\SysWOW64\\'
  condition: selection AND NOT filter_path

Ограничение хэш-детектов: CVE-2013-3900 и Authenticode padding

Детект по SHA256 из LOLDrivers — необходимый минимум, но у него есть серьёзная слабость. CVE-2013-3900 — уязвимость в Windows Authenticode, которая позволяет менять байты в PE-файле за пределами подписанной области. Файловый хэш (SHA256) меняется, а подпись остаётся валидной. Windows загрузит такой драйвер без вопросов.

На практике это означает: атакующий берёт уязвимый драйвер из LOLDrivers, меняет пару байт — и получает файл, которого нет ни в одной хэш-базе. Check Point обнаружил более 2500 уникальных вариантов драйвера TrueSight.sys, созданных именно так: все с разными SHA256, все с одной подписью, все рабочие.

Есть два способа бороться с этим:

Authentihash — это хэш, который считается только по подписанным областям PE-файла. У всех 2500 вариантов TrueSight.sys один и тот же Authentihash, потому что подписанная часть не менялась. Если SIEM или EDR умеет работать с Authentihash — детект становится устойчивым к CVE-2013-3900.
Сертификат подписи — вместо хэша файла можно строить детект на сертификате, которым подписан драйвер (Subject, Issuer, Serial Number). Даже после модификации байтов сертификат остаётся тем же. Для Sysmon EID 6 доступны поля SignatureStatus и Signature — их можно использовать для фильтрации.

В KUMA это реализуется через дополнительную lookup-таблицу с Authentihash-значениями (доступны на LOLDrivers.io в формате CSV) или через проверку сертификата подписи в событиях Sysmon EID 6.

			WHERE DeviceProduct = 'Sysmon'
  AND DeviceEventClassID = '6'
  AND Authentihash IN (lookup: loldrivers_authentihash)

По сертификату подписи:

			WHERE DeviceProduct = 'Sysmon'
  AND DeviceEventClassID = '6'
  AND SignatureSubject IN (lookup: loldrivers_revoked_certs)

Митигация CVE-2013-3900 на уровне ОС — включить строгую проверку Authenticode через реестр:

			HKLM\Software\Microsoft\Cryptography\Wintrust\Config
  "EnableCertPaddingCheck"="1"
HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config
  "EnableCertPaddingCheck"="1"

После этого модифицированные драйверы с padding перестанут считаться подписанными. Фикс существует с 2013 года, но не включён по умолчанию — Microsoft боится сломать совместимость.

Детект 2. Подозрительное создание сервиса для драйвера

MITRE ATT&CK: T1543.003 (Create or Modify System Process: Windows Service)

Загрузка драйвера в Windows происходит через создание сервиса типа «kernel driver». Это генерирует события Windows Security (Event ID 4697 — A service was installed in the system) и System (Event ID 7045 — A new service was installed). Детект фокусируется на аномалиях:

Логика алерта:

Событие: создание нового сервиса с типом kernel driver (Event ID 7045). Условие: ImagePath указывает на файл вне стандартных директорий драйверов.

EID 7045 не содержит информации о родительском процессе — SCM логирует только параметры сервиса. Поэтому детектирование разбито на два правила: первое ловит аномальный путь в самом событии создания сервиса, второе — запуск sc.exe create type=kernel через Sysmon EID 1.

			WHERE DeviceEventClassID = '7045'
 AND DeviceCustomString1 LIKE '%kernel%'
 AND NOT ImagePath LIKE 'C:\\Windows\\System32\\drivers\\%'
 AND NOT ImagePath LIKE 'C:\\Windows\\System32\\DriverStore\\%'
 AND NOT ImagePath LIKE 'C:\\Program Files%'

			WHERE DeviceProduct = 'Sysmon'
 AND DeviceEventClassID = '1'
 AND FileName LIKE '%\\sc.exe'
 AND CommandLine LIKE '%create%'
 AND CommandLine LIKE '%kernel%'

Детект 3. Создание символической ссылки на драйверы/файлы security-вендоров

MITRE ATT&CK: T1036 (Masquerading), T1562.001 (Impair Defenses)

Для детектирования техники Symbolic Link + BYOVD необходимо мониторить создание символических ссылок (junction points, reparse points) в системных директориях или указывающих на файлы security-вендоров.

Логика алерта:

Событие создания файла типа symbolic link, где компания-производитель целевого файла — security-вендор, а путь указывает на системную директорию драйверов.

На каком событии строить детект: Sysmon Event ID 11 (FileCreate) — срабатывает при создании файлов, включая reparse points (junction/symlink).

Правило в логическом виде:

			WHERE DeviceProduct = 'Sysmon'
  AND DeviceEventClassID = '11'
  AND TargetFilename LIKE 'C:\\Windows\\System32\\drivers\\%'
  AND NOT SourceProcessName LIKE '%\\drvinst.exe'
  AND NOT SourceProcessName LIKE '%\\TrustedInstaller.exe'
  AND NOT SourceProcessName LIKE '%\\poqexec.exe'
  AND NOT SourceProcessName LIKE '%\\DismHost.exe'

Проще говоря: кто-то создал что-то в папке drivers\ и это не установщик драйверов Windows — подозрительно.

Детектирование Symbolic Link + BYOVD возможно на двух уровнях.

Базовый — через Sysmon Event ID 11: любое создание файла в C:\Windows\System32\drivers\ процессом, не являющимся штатным установщиком, генерирует алерт.

Продвинутый — через EDR-телеметрию, где доступен тип файла (symlink) и метаданные целевого объекта (File Company Name). Это позволяет точно детектировать создание символической ссылки, подменяющей компонент security-вендора, с минимальным уровнем false positive.

Логика реализуема в EDR-решениях с расширенной файловой телеметрией (Kaspersky KEDR Expert, BIZONE EDR) где доступны поля типа файла (symlink/junction) и метаданные PE-заголовка целевого объекта (CompanyName, FileDescription).

Детект 4. Исчезновение kernel callbacks / молчание EDR

MITRE ATT&CK: T1562.001 (Impair Defenses: Disable or Modify Tools)

Один из самых сложных, но самых ценных детектов — обнаружение факта отключения kernel callbacks. Прямой мониторинг невозможен (если ETW отключён, события не генерируются), но можно использовать косвенные индикаторы:

Heartbeat-мониторинг EDR: если EDR-агент перестал отправлять телеметрию (или отправляет, но количество событий аномально снизилось) — это критический индикатор. SOC должен мониторить поток событий от каждого агента.
ETW consumer watchdog: периодический опрос состояния ETW-сессий через logman query. Если системные ETW-сессии внезапно прекратились — это сигнал.
Kernel callback verification: специализированные инструменты (или кастомный драйвер мониторинга) могут периодически проверять целостность массивов PspCreateProcessNotifyRoutine и CallbackListHead.

Логика алерта:

Условие: EDR-агент на хосте X не отправлял телеметрию более N минут (порог зависит от нормальной частоты). ИЛИ количество событий от агента снизилось более чем на 90% по сравнению с базовой линией за аналогичный период. Severity: Critical.

В KUMA это реализуется правилом на отсутствие событий: создаём корреляцию с типом «отсутствие события» (absence), где условие — от конкретного хоста не поступало ни одного события Sysmon за последние 10 минут. Порог подбирается под среду: для рабочих станций 10 минут, для серверов с высокой активностью — 5 минут.

			# KUMA: правило на молчание агента (absence-тип корреляции)
# Условие: отсутствие событий от хоста за 10 минут
WHERE DeviceProduct = 'Sysmon'
  GROUP BY DeviceAddress
  HAVING COUNT(*) = 0
  WITHIN 600s

Детект 5. Нетипичный процесс открывает хэндл к драйверу

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation)

При эксплуатации уязвимого драйвера атакующий вызывает CreateFile("\\\\.\\<DeviceName>") для получения хэндла, а затем DeviceIoControl() для отправки IOCTL-команд. В случае успешной загрузки обращение шло бы к устройству \\.\Blackout — объекту, зарегистрированному загруженным драйвером Blackout.sys.

Логика алерта:

Событие: если к устройству драйвера Dell (\\.\DBUtil_2_3) обращается не процесс Dell, а неизвестный бинарник из C:\Users\Downloads\ — это аномалии.

Реализация этого детекта требует расширенной телеметрии: аудита доступа к объектам ядра (Windows Security Policy → Object Access) или EDR с мониторингом device handle operations. Стандартный Sysmon этот уровень не покрывает — это один из аргументов в пользу EDR-решений с kernel-level телеметрией, даже с учётом рисков BYOVD.

В KEDR Expert и BI.ZONE EDR операции DeviceIoControl логируются через kernel-level телеметрию.

Если таких EDR нет — можно включить Object Access Auditing через GPO (Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Object Access → Audit Kernel Object), но это генерирует большой объём событий и требует тщательной фильтрации.

Детект 6. Аномалии PreviousMode

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation)

Этот детект — скорее гипотеза для threat hunting, чем правило для автоматического алертинга. Прямой мониторинг PreviousMode из user mode невозможен, но косвенные признаки могут указать на эксплуатацию:

PreviousMode это поле в структуре потока, которое говорит ядру: «Этот запрос пришёл из user mode или из kernel mode?»

			PreviousMode = 1 (UserMode)  → ядро ПРОВЕРЯЕТ границы памяти
PreviousMode = 0 (KernelMode) → ядро НЕ ПРОВЕРЯЕТ, доверяет полностью

Lazarus через CVE-2024-21338 менял это значение с 1 на 0. После этого обычный процесс мог вызывать NtWriteVirtualMemory и писать прямо в память ядра — ядро думало что запрос от компонента ядра.

Изменение PreviousMode в _KTHREAD — ключевой примитив атак CVE-2024- 21338 и аналогичных. Напрямую мониторить это из user mode невозможно, но можно детектировать косвенные признаки:

Процесс из user mode успешно вызывает NtWriteVirtualMemory / NtReadVirtualMemory для адресов пространства ядра системы (> 0x7FFFFFFFFFFF) — это аномалия, которую можно детектировать через ETW-провайдер Microsoft-Windows-Kernel-Audit-API-Calls (если он ещё не отключён)
Процесс LOCAL_SERVICE внезапно выполняет операции, не характерные для этого аккаунта — например, создаёт файлы, загружает DLL, устанавливает сетевые соединения.

Детект 7. Загрузка драйвера с отозванным или истёкшим сертификатом

MITRE ATT&CK: T1553.002 (Subvert Trust Controls: Code Signing)

Sysmon EID 6 при загрузке драйвера фиксирует статус подписи. Если подпись невалидна, отозвана или просрочена — это повод для алерта.

В конфигурации Sysmon должен быть включён тег <CheckRevocation/>.

Логика алерта:

Событие: загрузка драйвера (Sysmon EID 6). Условие: SignatureStatus не равен 'Valid'.

			WHERE DeviceProduct = 'Sysmon'
  AND DeviceEventClassID = '6'
  AND SignatureStatus != 'Valid'

Дополнительный фильтр для снижения FP: исключить драйверы Microsoft, подписанные в тестовом режиме (если на хосте включён testsigning).

Этот детект ловит атаки типа EnCase BYOVD (Huntress, 2026): драйвер с сертификатом 2010 года, отозванным 15 лет назад, но всё ещё загружаемым Windows.

Детект 8. Комплексный подход: корреляция событий

Самый мощный детект — корреляция слабых сигналов в рамках одного инцидента. Типичная цепочка BYOVD-атаки генерирует следующую последовательность:

Файл .sys появляется в нетипичной директории (File Create)
Создаётся новый сервис типа kernel driver (Event ID 7045)
Загружается драйвер с хэшем из базы LOLDrivers (Sysmon ID 6)
Процесс открывает хэндл к устройству драйвера (File/Object Access)
Один или несколько EDR/AV процессов завершаются (Event ID 4689) или перестают генерировать телеметрию
Загруженный драйвер имеет невалидную, отозванную или просроченную подпись (Sysmon EID 6, SignatureStatus ≠ Valid)

Логика корреляционного правила:

Если на одном хосте в течение 5 минут происходят события #1 + #2 + (#3 ИЛИ #5 ИЛИ #6) — это с высокой вероятностью BYOVD-атака.

Готовые правила для SIEM KUMA

Для тех, кто работает с KUMA — пять правил корреляции, адаптированных под синтаксис платформы. Время внедрения — 15–20 минут на правило.

Правило 1. Загрузка драйвера из нестандартного пути

Тип: простое | Источник: Sysmon | Severity: HIGH | MITRE: T1068, T1543.003

			WHERE DeviceProduct = 'Sysmon'
  AND DeviceEventClassID = '6'
  AND NOT FileName LIKE 'C:\\Windows\\System32\\drivers\\%'
  AND NOT FileName LIKE 'C:\\Windows\\System32\\DriverStore\\%'
  AND NOT FileName LIKE 'C:\\Program Files%'

Реакция: проверить хэш на loldrivers.io, найти источник файла (EID 11).

Правило 2. Создание kernel-mode сервиса

Тип: простое | Источник: Windows System Log | Severity: HIGH | MITRE: T1543.003

			WHERE DeviceEventClassID = '7045'
  AND DeviceCustomString1 LIKE '%kernel%'

FP: установка драйверов ПО/принтеров. Коррелировать с EID 6.

Правило 3. sc.exe create type=kernel

Тип: простое | Источник: Windows Security / Sysmon | Severity: HIGH | MITRE: T1543.003

			WHERE (DeviceEventClassID = '4688' OR DeviceEventClassID = '1')
  AND SourceProcessName LIKE '%\\sc.exe'
  AND Message LIKE '%create%'
  AND Message LIKE '%kernel%'

Правило 4. Массовое завершение защитных процессов

Тип: агрегация (count) | Источник: Sysmon | Severity: CRITICAL | MITRE: T1562.001

			WHERE DeviceEventClassID = '5'
  AND TargetProcessName IN (
    'MsMpEng.exe','MsSense.exe',         -- Defender
    'kavfs.exe','avp.exe','klnagent.exe', -- Kaspersky
    'Sysmon.exe','Sysmon64.exe',          -- Sysmon
    'elastic-endpoint.exe'               -- Elastic
  )
AGGREGATE: COUNT >= 2 per HostName within 120s

Реакция: НЕМЕДЛЕННАЯ ИЗОЛЯЦИЯ хоста!

Правило 5. ETW tampering через CLI

Тип: простое | Источник: Windows Security / Sysmon | Severity: HIGH | MITRE: T1562.006

			WHERE (DeviceEventClassID = '4688' OR DeviceEventClassID = '1')
  AND (
    (SourceProcessName LIKE '%\\logman.exe'
     AND (Message LIKE '%stop%' OR Message LIKE '%delete%'))
    OR
    (SourceProcessName LIKE '%\\wevtutil.exe'
     AND (Message LIKE '% cl %' OR Message LIKE '%clear-log%')))

Митигации: как снизить риск BYOVD

BYOVD не закрывается одним патчем — уязвимых подписанных драйверов сотни. Но усложнить атаку можно.

№1. HVCI (Hypervisor-Protected Code Integrity)

HVCI (также известный как Memory Integrity) использует гипервизор для контроля целостности кода ядра. С включённым HVCI загрузка драйверов проверяется на уровне VTL1, что значительно затрудняет эксплуатацию уязвимых драйверов. Ограничение: HVCI может вызывать проблемы совместимости со старым оборудованием и драйверами.

HVCI защищает ключевые структуры ядра, включая ci!g_CiOptions — переменную, контролирующую проверку подписей драйверов. Без HVCI атакующий с BYOVD-примитивом может перезаписать ci!g_CiOptions и загрузить вообще любой неподписанный драйвер. С включённым HVCI эта переменная находится под защитой гипервизора (VTL1), и попытка записи вызовет исключение. Это делает HVCI единственной митигацей, защищающей ci!g_CiOptions на уровне гипервизора.

№2. Microsoft Vulnerable Driver Blocklist

Microsoft поддерживает список заблокированных уязвимых драйверов, который может применяться через WDAC (Windows Defender Application Control) или ASR (Attack Surface Reduction) правила. Важно убедиться, что этот список обновляется регулярно — по умолчанию он обновляется только с крупными обновлениями Windows.

			Проверка статуса блок-листа
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
Ключевые свойства:
VirtualizationBasedSecurityStatus
CodeIntegrityPolicyEnforcementStatus

№3. ASR Rules

ASR (Attack Surface Reduction) — это набор правил в Windows Defender, которые блокируют типичные действия атакующих. Одно из правил специально для BYOVD.

Attack Surface Reduction правило «Block abuse of exploited vulnerable signed drivers» (GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5) может блокировать загрузку известных уязвимых драйверов. Рекомендуется включить в режиме аудита, а затем перевести в блокировку после проверки совместимости.

№4. Мониторинг сервисов и драйверов

Настроить аудит создания сервисов (Event ID 7045, 4697).

Мониторить загрузку драйверов через Sysmon (Event ID 6) с автоматической проверкой хэшей по LOLDrivers.
Внедрить EDR heartbeat-мониторинг с алертом на молчание агента.
Ограничить права на создание сервисов типа kernel driver — минимизировать число учётных записей с привилегией SeLoadDriverPrivilege.

№5. Принцип наименьших привилегий

BYOVD-атака требует привилегий администратора (для загрузки драйвера) или LOCAL_SERVICE (для CVE-2024-21338). Меньше админов на эндпоинтах — меньше шансов у атакующего загрузить драйвер. Audit и контроль использования привилегированных учётных записей (PAM, JIT-доступ) остаются критически важными.

№6 Проактивный аудит: как находить уязвимые драйверы до атакующих

Все детекты и митигации выше работают реактивно — мы ловим атаку, которая уже происходит, или блокируем драйверы, которые уже попали в базы. Но в инфраструктуре любой крупной компании десятки или сотни драйверов от разных вендоров, и далеко не все из них проверены на уязвимости. Промышленные контроллеры, банковское оборудование, принтеры, сканеры, специализированное ПО — всё это ставит свои драйверы, которые работают в Ring 0 и могут содержать IOCTL-обработчики с классическими багами.

В 2023 году исследователи из TeamT5 представили на HITCON инструмент IOCTLance, который решает именно эту задачу: автоматический поиск уязвимостей в WDM-драйверах без необходимости запускать их на реальной системе. За счёт комбинации символьного выполнения и taint-анализа IOCTLance нашёл 117 ранее неизвестных уязвимостей в 26 драйверах, что привело к назначению 41 CVE — среди затронутых вендоров оказались AMD, Dell, IObit, Microsoft (Visual Studio).

Подход работает так. Инструмент берёт бинарник драйвера, находит в нём IOCTL-обработчики и вместо реальных данных подаёт на вход символьные переменные. Затем прослеживает все пути выполнения кода и проверяет, попадают ли контролируемые пользователем данные в опасные функции: MmMapIoSpace (маппинг физической памяти), ZwOpenProcess без OBJ_FORCE_ACCESS_CHECK (открытие хэндла к произвольному процессу), memcpy с контролируемым размером (переполнение буфера), вызов функции по указателю из input buffer (выполнение произвольного кода в ядре) и ещё пять типов уязвимостей. На выходе — конкретный IOCTL-код, адрес уязвимой инструкции и описание, какие именно поля входного буфера контролирует атакующий.

Почему это применимо на практике? База LOLDrivers.io каталогизирует сотни уязвимых драйверов, но покрывает только те, которые уже кто-то исследовал. Драйвер от условного вендора банковских терминалов или системы контроля доступа может содержать точно такие же баги (произвольное чтение/запись памяти через IOCTL), но никто его не проверял, и в LOLDrivers его нет. Атакующий, который получит этот драйвер, сможет использовать его для BYOVD — а детекты по хэшам не сработают, потому что драйвера нет ни в одной базе.

Заключение

BYOVD — это стандартный этап ransomware-операций, доступный через готовые тулкиты и базы уязвимых драйверов, так как публичные инструменты снизили порог входа до минимума.

Для SOC-команд и detection-инженеров это означает необходимость пересмотра подходов к мониторингу:

Хэш-детектирование загрузки уязвимых драйверов (LOLDrivers.io) — базовый, обязательный детект.
Мониторинг создания сервисов типа kernel driver из нетипичных источников.
Heartbeat-мониторинг EDR-агентов с алертом на молчание.
Корреляция: файл .sys + сервис + завершение EDR = автоматическая изоляция.
Технические митигации: HVCI, ASR rules, Microsoft Vulnerable Driver Blocklist.

Если ваша стратегия безопасности начинается и заканчивается на EDR, BYOVD-атака может оставить вас полностью слепыми. Сетевой мониторинг, контроль привилегий, HVCI и проверка живости агентов — надёжнее любого отдельного EDR.

Чек-лист: защита от BYOVD

Оставляю чек-лист — распечатайте и держите рядом.

Предотвращение

☐ HVCI (Memory Integrity) включён на рабочих станциях и серверах.

☐ Microsoft Vulnerable Driver Blocklist актуален.

☐ ASR-правило «Block abuse of exploited vulnerable signed drivers» активно.

☐ SeLoadDriverPrivilege ограничена минимальным числом учётных записей.

☐ MFA на VPN и всех внешних точках входа

Обнаружение

☐ Sysmon установлен, EID 6 собирается без агрессивной фильтрации.

☐ <CheckRevocation/> включён в конфигурации Sysmon.

☐ LOLDrivers-хэши импортированы как lookup-таблица в SIEM

☐ Командная строка логируется в EID 4688 (GPO → Include command line) ☐ Правило на sc.exe create type=kernel в SIEM

☐ Правило на массовое завершение EDR-процессов в SIEM

Контроль

☐ Heartbeat-мониторинг EDR-агентов настроен (алерт при молчании > 5 мин).

☐ Корреляция: файл .sys + сервис + завершение EDR = автоизоляция.

☐ Периодическая проверка целостности ETW-сессий (logman query).