Вы настроили Sysmon, у вас работает EDR, события летят в SIEM. Создаётся процесс, вы видите Event ID 1. Загружается DLL, Event ID 7. Всё под контролем. А теперь кто-то загружает в систему один .sys-файл. Обычный, подписанный, из прошлого века. И события пропадают. Не потому что Sysmon упал или EDR отключили. Они работают. Просто ядро Windows больше не считает нужным им что-то рассказывать.
Я залез внутрь, чтобы понять, как это устроено. Поднял WinDbg, подключился к ядру, нашёл структуры, где хранятся callback'и мониторинга. Обнулил их, повторив технику руткита Lazarus. Sysmon на месте, PID живой, но лог пустой.
Меня зовут Роман Мгоев, я специалист по анализу киберугроз в Альфа-Банке, в статье пройду этот путь целиком: начиная с архитектуры колец защиты Windows, byte-патчей в памяти ядра и разбора FudModule от Lazarus обеих версий, до свежих техник zerosalarium и разбора публичных тулкитов, а в конце поделюсь семью направлениями детектирования с готовыми правилами для SIEM. Отдельный блок — про аудит драйверов, которых ещё нет ни в одной базе.
Оглавление
Глава 1. Анатомия атаки: архитектура ядра и обход DSE
Глава 2. Lazarus FudModule: как APT-группировка хакнула ядро
Глава 3. Новые техники от zerosalarium
Глава 4. Публичные тулкиты: BYOVD для масс
Глава 5. Детектирование BYOVD: что и как мониторить
Ограничение хэш-детектов: CVE-2013-3900 и Authenticode padding
Детект 3: Создание символической ссылки на драйверы/файлы security-вендоров
Детект 7: Загрузка драйвера с отозванным или истёкшим сертификатом
Глава 6. За пределами LOLDrivers: проактивный аудит драйверов
Глава 7. Митигации: как снизить риск BYOVD
Дисклеймер: статья носит ознакомительный характер. Любые попытки злоупотребления данной информацией незаконны и могут повлечь за собой уголовное преследование в соответствии со статьями 272 и 273 УК РФ. |
BYOVD (Bring Your Own Vulnerable Driver) — техника, при которой атакующий приносит с собой легитимный подписанный драйвер с известной уязвимостью, загружает его в систему и через эту уязвимость получает возможность писать в память ядра Windows.
EDR (Endpoint Detection and Response) — технология мониторинга эндпоинтов. После BYOVD он превращается в муляж: процесс работает, иконка зелёная, а телеметрии нет. Ядро перестало отправлять уведомления.
По данным Huntress, в 2024 году значительная доля атак шифровальщиков включала обход EDR — в том числе через уязвимые драйверы. Coveware зафиксировал техники уклонения от защиты (Defense Evasion) в 60% случаев вымогательства. А в феврале 2026 года Huntress обнаружил атаку, где 16-летний драйвер EnCase с отозванным сертификатом убил 59 EDR-агентов за 30 секунд.
Проблема касается не только западных компаний. По данным F6 (образована выходцами из Group-IB) в 2025 году 27 прогосударственных APT-групп атаковали Россию и СНГ. «Инфосистемы Джет» подсчитали, что 76% критических инцидентов были направлены не на шпионаж или кражу данных, а на уничтожение ИТ-инфраструктуры. Например, Аэрофлоту пришлось отменить 100+ рейсов, у СДЭК застыло 300 тыс. посылок в день, «Верный» понёс убытки в 120–140 млн руб./день. А это всё 2024–2025 годы.
До 2023 года BYOVD был экзотикой, но когда в 2023 году русскоязычный хакер Spyboy на форуме RAMP начал продавать Terminator — от $300 за отключение одного EDR до $3000 за all-in-one. После этого всё изменилось. Появились клоны — EDRKillShifter, AuKill, Blackout — и техника стала стандартной фазой операции ransomware. Теперь практически во всех крупных ransomware-инцидентах ключевой этап — отключение EDR перед шифрованием.
В этой статье мы детально разберём механику BYOVD-атак: от принципов архитектуры ядра Windows до конкретных техник Lazarus и их последователей. Покажем всё на практике — с WinDbg, реальными тулкитами, готовыми правилами детектирования.
Анатомия атаки: архитектура ядра и обход DSE
Windows делит весь исполняемый код на два уровня доверия. В архитектуре x86 они называются кольцами защиты (protection rings), но на практике из четырёх колец используются только два: Ring 3 пользовательский режим, и Ring 0 режим ядра.
Обычные программы — браузер, 1С, Telegram — работают в Ring 3. У них ограниченный набор привилегий: они не могут напрямую обращаться к памяти других процессов, не могут работать с железом, а для системных операций вынуждены просить ядро через системные вызовы (syscalls).
Ядро (Ring 0) — фундамент. Здесь работают ntoskrnl.exe (само ядро), HAL, файловая система, сетевой стек и все драйверы. Код в Ring 0 имеет прямой доступ к физической памяти, может модифицировать любые структуры данных, завершать любые процессы и отключать любую телеметрию.
EDR — это гибрид: пользовательский интерфейс работает в Ring 3, а для мониторинга он устанавливает свой kernel-mode драйвер в Ring 0. Мониторинг EDR основан на kernel callbacks — специальных функциях-уведомлениях, которые ядро вызывает при определённых событиях:
Создаётся процесс — срабатывает PsSetCreateProcessNotifyRoutine.
Загружается DLL — PsSetLoadImageNotifyRoutine.
Открывается хэндл объекта — ObRegisterCallbacks.
Коллбэки регистрируются EDR- драйвером при загрузке, и ядро хранит их адреса в служебных структурах — таких как CallbackListHead, PspNotifyEnableMask, различные списки типа _CALLBACK_ENTRY_ITEM.
Помимо kernel callbacks, EDR перехватывает вызовы API-функций через function-hooking DLL, которая инжектируется в каждый процесс. Эти хуки работают в user mode и подменяют первые байты функций ntdll.dll (например, NtAllocateVirtualMemory) на переход в код EDR. Поэтому даже после отключения kernel callbacks EDR может получать телеметрию через user-mode хуки — и наоборот.
Продвинутые руткиты атакуют оба уровня одновременно. Если атакующий получает возможность писать в память ядра, он может обнулить адреса коллбэков или флаги их активности — и ядро перестанет уведомлять EDR о любых событиях. Процесс антивируса при этом продолжает работать, но по факту ослеп.
Попасть же в ядро можно посредством драйверов. Драйвер — это программный компонент, обеспечивающий взаимодействие ОС с аппаратным обеспечением. Драйверы в Windows работают в ring 0 — то есть на уровне ядра, с максимальными привилегиями.
Microsoft требует подпись (DSE) для загрузки драйверов в ядро. В BYOVD это не помогает: атакующий использует легитимный подписанный драйвер. Хуже того, Windows не проверяет CRL при загрузке — на этом этапе сеть ещё недоступна. Драйвер EnCase с сертификатом, отозванным в 2010 году, загружается в 2026-м без вопросов. Встроенный блок-лист Microsoft покрывает малую часть из сотен уязвимых драйверов в базе LOLDrivers.
Рассмотрим основные подходы к получению kernel-доступа. Два из них разберём здесь, третий — эксплуатацию 0-day в штатных компонентах Windows — детально покажем на примере FudModule 2.0.
Подход 1: N-day уязвимости в сторонних драйверах
Атакующий берёт драйвер известного производителя (Dell, Intel, Realtek, MSI и десятки других) с уже обнаруженной уязвимостью. Драйвер подписан валидным сертификатом, DSE его пропускает. Через уязвимость (обычно это IOCTL, который позволяет произвольное чтение/запись физической или виртуальной памяти) атакующий получает примитивы для модификации ядра. Проект LOLDrivers.io на сегодня каталогизирует сотни таких драйверов.
Отдельный случай — эксплуатация уязвимости в штатном компоненте Windows (Lazarus использовала CVE-2024-21338 в appid.sys). Техника не требует дропа стороннего файла и подробно разобрана ниже в разделе о FudModule 2.0.
Подход 2: Злоупотребление PreviousMode
Через эксплуатацию уязвимости атакующий меняет поле PreviousMode в структуре _KTHREAD текущего потока с UserMode (1) на KernelMode (0). После этого системные вызовы NtWriteVirtualMemory и NtReadVirtualMemory перестают проверять границы памяти и позволяют напрямую модифицировать пространство ядра из user mode.
А как работает третий подход, мы рассмотрим на примере работы FudModule.
Lazarus FudModule: как APT-группировка хакнула ядро
Lazarus (HIDDEN COBRA, APT38) — одна из самых технически продвинутых APT-группировок, связанных с КНДР. В кампаниях Operation DreamJob они создавали фейковые профили рекрутеров в LinkedIn и рассылали жертвам «вакансии» — ISO-файлы с вредоносной начинкой: многоступенчатой цепочкой загрузчиков (RollFling → RollSling → RollMid → KaolinRAT), финальным звеном которой был FudModule — руткит, работающий на уровне ядра.
FudModule — самый подробно задокументированный BYOVD-руткит в открытых источниках. Разберём его детально.
FudModule 1.0: CVE-2021-21551 и история с Dell
Первая версия 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 и получали примитивы чтения/записи ядра.
FudModule v1 последовательно атаковал семь механизмов мониторинга Windows. Каждый из них — отдельная структура ядра, хранящая адреса коллбэков EDR.
Механизм 1: Registry Callbacks (CmRegisterCallbackEx)
FudModule находил глобальный список CallbackListHead, содержащий все зарегистрированные коллбэки для мониторинга реестра, и очищал его. При этом делал исключения для коллбэков ntoskrnl.exe (чтобы не сломать систему). После этого ни один EDR не получал уведомлений об изменениях в реестре.
Механизм 2: Object Callbacks (ObRegisterCallbacks)
Коллбэки на операции с объектами (открытие хэндлов процессов, потоков) хранятся в двусвязном списке, доступном через ObjectType->CallbackList. FudModule проходил по _OBJECT_TYPE для типов Process и Thread и обнулял записи, принадлежащие EDR-драйверам. Это позволяло атакующему свободно открывать хэндлы к любым процессам без уведомления EDR.
Механизм 3: Process / Thread / Image Callbacks (PsSetCreateProcessNotifyRoutine и аналоги)
Это основной механизм, через который EDR узнаёт о создании процессов и загрузке библиотек. В ядре Windows за активацию этих коллбэков отвечает битовая маска PspNotifyEnableMask. FudModule обнулял эту маску, и ядро переставало вызывать все зарегистрированные notification-коллбэки. Эффект мгновенный: EDR перестаёт видеть все создания процессов.
Важный нюанс: FudModule не удалял записи коллбэков из массивов PspCreateProcessNotifyRoutine. Он отключал их все разом через одну битовую маску. Это быстрее и незаметнее, но означает, что при восстановлении маски мониторинг возобновится.
Механизм 4: Minifilter Callbacks
Minifilter-драйверы — основа файлового мониторинга EDR. Они перехватывают операции файловой системы (создание, чтение, запись, удаление файлов). FudModule итерировал список FLT_VOLUME.Callbacks.OperationsLists и патчил записи callback-узлов для конкретных файловых операций, вычисляя адреса по смещениям из структур фильтр-менеджера.
Механизм 5: WFP Callouts (Windows Filtering Platform)
Для мониторинга сетевого трафика EDR-продукты регистрируют callout’ы в WFP. FudModule устанавливал флаг FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW в структуре netio!gWfpGlobal, что фактически отключало вызов EDR-коллбэков при обработке сетевых пакетов.
Механизм 6: ETW (Event Tracing for Windows)
ETW — важнейший источник телеметрии для EDR. FudModule обнулял переменную EtwpActiveSystemLoggers, которая является битовой маской активных системных логгеров. Обнулённая маска означает, что ядро считает: нет ни одного активного ETW-потребителя. Все ETW-события перестают генерироваться.
Но также есть техника patching EtwEventWrite — атакующий перезаписывает первые 3 байта функции ntdll!EtwEventWrite() на «xor eax, eax; ret» (\x33\xc0\xc3). Функция мгновенно возвращает SUCCESS, не генерируя никаких событий. Техника работает в user mode, без BYOVD.
Механизм 7: Прямое убийство процессов
В качестве финального этапа FudModule мог напрямую завершать процессы EDR. Для этого он манипулировал структурами _EPROCESS целевых процессов: модифицировал поля, связанные с handle table и ObjectPointerBits, что приводило к аварийному завершению процесса.
Все семь механизмов FudModule v1 сведены в таблицу ниже. Каждая строка — отдельная структура ядра Windows, которую руткит модифицирует для отключения конкретного канала телеметрии EDR:
№ | Механизм | Структура ядра (Kernel Structure) | Что модифицируется | Эффект для EDR |
1 | Registry Callbacks | CallbackListHead | Очистка списка callback | EDR не видит изменения реестра |
2 | Object Callbacks | ObjectType->CallbackList | Удаление записей | Нет мониторинга handle-операций |
3 | Process / Thread / Image Notify | PspNotifyEnableMask | Обнуление битовой маски | Нет событий создания процессов |
4 | Minifilter Drivers | FLT_VOLUME.Callbacks.OperationsLists | Патчинг callback-узлов | Нет мониторинга файлов |
5 | WFP Callouts | netio!gWfpGlobal | Установка FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW | Нет сетевого мониторинга |
6 | ETW System Loggers | EtwpActiveSystemLoggers | Обнуление битовой маски | ETW перестаёт генерировать события |
7 | Direct Process Manipulation | _EPROCESS / ObjectPointerBits | Манипуляция структурой процесса | Завершение / краш EDR |
В связке — полное ослепление: ядро перестает отправлять EDR любые уведомления.
Практический пример: отключение kernel callbacks через PspNotifyEnableMask
Чтобы понять, как работает механизм FudModule, воспроизведём его ключевую технику вручную — через отладчик ядра.
Шаг 1. Исходное состояние — Sysmon\EDR видит всё
Запускаем notepad.exe. В журнале Sysmon (Microsoft-Windows- Sysmon/Operational) появляется событие Event ID 1 — Process Create со всеми деталями: путь к образу, командная строка, PID, GUID процесса. Это нормальное поведение — ядро вызывает зарегистрированные notify-коллбэки, Sysmon их получает и логирует.
Шаг 2. Подключаемся к ядру
Включаем отладку (bcdedit /debug on, перезагрузка), запускаем WinDbg x64 → Attach to Kernel → Local. Находим адрес переменной:
lkd> x nt!PspNotifyEnableMask fffff802`21d2e6a0 nt!PspNotifyEnableMask =
Читаем текущее значение:
lkd> dd nt!PspNotifyEnableMask L1 fffff802`21d2e6a0 0000001f
Значение 0x1F (бинарно 00011111) — это битовая маска, каждый бит которой отвечает за тип коллбэка: Process notify, Thread notify, Image notify и другие. Все биты установлены — ядро вызывает все зарегистрированные коллбэки. Состояние нормальное.
Шаг 3. Обнуляем маску — имитируем FudModule
lkd> ed nt!PspNotifyEnableMask 0 lkd> dd nt!PspNotifyEnableMask L1 fffff802`21d2e6a0 00000000
Одна команда — и ядро перестаёт вызывать все notification-коллбэки. Именно это делает FudModule, только не через отладчик, а через запись в память ядра из user mode через эксплуатацию уязвимого драйвера.
Шаг 4. Проверяем эффект
Снова запускаем notepad.exe — в журнале Sysmon тишина, нового события Process Create нет. Процесс Sysmon при этом работает, сервис запущен, но телеметрия не поступает.
Шаг 5. Восстанавливаем значение
lkd> ed nt!PspNotifyEnableMask 0x1f
После восстановления маски Sysmon снова видит запуск процессов — новые события появляются в журнале.
Итого: одно 4-байтовое значение в памяти ядра определяет, работает EDR или нет. FudModule делает ровно то же самое, что мы только что проделали вручную, только вместо WinDbg он пишет в память ядра через уязвимый драйвер, без всякого отладчика.
FudModule 2.0: от BYOVD к zero-day
Всё, что мы разобрали выше — это FudModule образца 2022 года. Через два года, в 2024-м, Lazarus выпустила обновлённую версию руткита и сменила подход. Вместо стороннего драйвера Dell они нашли 0-day уязвимость в appid.sys — штатном компоненте Windows, отвечающем за AppLocker.
Эту уязвимость группировка Lazarus использовала минимум с августа 2023 года. Баг применялся для получения привилегий уровня ядра и отключения защитных инструментов. Уязвимость имеет номер 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 и затрудняет детектирование.
Примечание. Microsoft исправил CVE-2024-21338 в февральском обновлении 2024 года, добавив вызов ExGetPreviousMode для проверки источника запроса. Однако до патча уязвимость эксплуатировалась in-the-wild минимум несколько месяцев. |
Новые механизмы FudModule 2.0
Помимо обновления вектора начального доступа, FudModule 2.0 добавил три новых механизма отключения защиты (нумерация по внутренним флагам).
№1. 0x80 — ETW Provider GUIDs
Если FudModule v1 отключал ETW глобально через EtwpActiveSystemLoggers, то версия 2.0 работает точечно: она содержит список из 95 захардкоженных GUID’ов ETW-провайдеров и для каждого обнуляет поля EnableMask, GroupEnableMask и HostEnableMask. Это позволяет отключить конкретные источники телеметрии (Microsoft-Windows-Threat-Intelligence, Microsoft-Windows- Kernel-Audit-API-Calls и т.д.), не ломая при этом системные ETW-сессии.
Среди 95 GUID'ов, которые отключает FudModule 2.0, особое значение имеет Microsoft-Windows-Threat-Intelligence (EtwTi). Это ETW-провайдер ядра, доступный только процессам с защитой Protected Process Light (PPL), который мониторит чувствительные операции: запись в память чужих процессов, маппинг образов, аллокацию исполняемой памяти. Отключение EtwTi лишает EDR одного из самых ценных источников телеметрии — поэтому FudModule бьёт по нему в первую очередь.
№2. 0x100 — Image Verification Callbacks
FudModule 2.0 обнулял список коллбэков, зарегистрированных через SeRegisterImageVerificationCallback — механизм, используемый некоторыми security-решениями для верификации загружаемых образов.
№3. 0x200 — Прямые атаки на процессы EDR
Самый агрессивный механизм: FudModule 2.0 содержал список конкретных EDR-процессов (AhnLab V3, Windows Defender, CrowdStrike Falcon, HitmanPro) и атаковал их напрямую. Для каждого целевого процесса руткит находил его _EPROCESS, обнулял MitigationFlags (удаляя все защитные флаги процесса) и манипулировал ObjectPointerBits в handle table, что позволяло «замораживать» процессы EDR через механизм Suspend.
Флаг | Механизм | Цель | Эффект |
0x01 | Registry Callbacks | CallbackListHead | EDR не видит изменения реестра |
0x02 | Object Callbacks | ObjectType->CallbackList | Свободное открытие хэндлов |
0x04 | Process/Thread/Image | PspNotifyEnableMask | EDR не видит создание процессов |
0x08 | Minifilter Drivers | FLT_VOLUME.Callbacks | Нет мониторинга файловых операций |
0x10 | WFP Callouts | netio!gWfpGlobal | Нет мониторинга сети |
0x40 | ETW System Loggers | EtwpActiveSystemLoggers | Глобальное отключение ETW |
0x80 | ETW Provider GUIDs (v2) | 95 GUID EnableMask | Точечное отключение ETW |
0x100 | Image Verification (v2) | SeRegisterImageVerificationCallback | Нет верификации образов |
0x200 | Direct Process Attack (v2) | _EPROCESS MitigationFlags | Заморозка/убийство EDR |
От v1 к v2 руткит перешёл от грубой силы (глобальные маски) к хирургической точности (95 ETW-провайдеров, таргетированные атаки на конкретные EDR). Полная карта механизмов — в таблице флагов выше.
Новые техники от zerosalarium
Symbolic Link + File Write: уничтожение EDR без kernel exploit
В январе 2025 года исследователь zerosalarium опубликовал технику, расширяющую понятие BYOVD. Ключевая идея: для отключения EDR не нужен драйвер с kernel exploit или IOCTL-уязвимостью. Достаточно любого легитимного драйвера, который при загрузке пишет файл (лог, трейс, дамп). Через symbolic link выходной файл драйвера перенаправляется на исполняемый файл EDR — и драйвер, выполняя легитимную операцию записи, затирает файл защитного решения.
Механика атаки Symbolic Link + File Write
Атака работает так:
1. Атакующий находит подписанный драйвер, который при загрузке записывает данные в предсказуемый файл. Пример из PoC zerosalarium — PROCMON24 (драйвер Process Monitor от Sysinternals): при включённом Boot Logging он пишет лог в C:\Windows\Procmon.pmb.
2. Через symbolic link выходной файл драйвера перенаправляется на исполняемый файл EDR/AV: mklink C:\Windows\Procmon.pmb "C:\ProgramData\Microsoft\Windows Defender\Platform\<version>\MsMpEng.exe"
3. Драйвер регистрируется как boot-сервис в группе «FSFilter Activity Monitor» (через ServiceGroupOrder в реестре). Это гарантирует загрузку раньше сервиса WinDefend.
4. При перезагрузке драйвер стартует первым и перезаписывает «свой лог» — а фактически затирает MsMpEng.exe. Файл теряет PE-структуру, WinDefend не может запуститься.
zerosalarium продемонстрировал технику на Windows 11 24H2 (Build 26100.2894), успешно отключив Windows Defender через перезапись Antimalware Service Executable.
Почему это опасно?
Техника не требует IOCTL-эксплойта. Драйвер выполняет штатную операцию (запись лога), а symlink превращает её в оружие. Драйверов с file-write функцией значительно больше, чем драйверов с memory R/W через IOCTL. Добавлять их все в блок-лист нереально — это сломает легитимное ПО.
Защита: разработчики драйверов должны проверять, не является ли целевой файл символической ссылкой, перед выполнением записи. Для SOC — мониторинг создания symlink, указывающих на файлы security-вендоров (Детект 3 в разделе «Детектирование»).
Исследование: расхождение телеметрии SCM и Sysmon
Отдельно от техники zerosalarium мы провели эксперимент с NTFS junction points, чтобы проверить, как разные источники логов видят загрузку одного и того же драйвера. Результат важен для написания детектов: правило, построенное на одном источнике, может пропустить то, что видит другой.
Для эксперимента используется легитимный подписанный драйвер NVIDIA (nvhda64v.sys), переименованный в vuln_driver.sys. В реальной атаке на его месте был бы уязвимый драйвер из базы LOLDrivers.
Шаг 1. Подготовка
Размещаем драйвер в произвольной директории — за пределами System32\drivers:
mkdir C:\TestBYOVD\real_driver copy nvhda64v.sys C:\TestBYOVD\real_driver\vuln_driver.sys
Шаг 2. Создаём NTFS Junction
Junction point — это тип reparse point в NTFS, который перенаправляет обращения к одной директории в другую на уровне файловой системы:
mklink /J "C:\Windows\System32\drivers\TrustedVendor" "C:\TestBYOVD\real_driver"
Теперь путь C:\Windows\System32\drivers\TrustedVendor\vuln_driver.sys физически ведёт к C:\TestBYOVD\real_driver\vuln_driver.sys, но для SCM и части системных компонентов выглядит как легитимный системный драйвер.
Шаг 3. Создаём и запускаем сервис
sc.exe create TestDrvJunction type= kernel start= demand binPath= "C:\Windows\System32\drivers\TrustedVendor\vuln_driver.sys" sc.exe start TestDrvJunction
Драйвер загружен: подпись валидна, Code Integrity не возражает — для ядра это обычный подписанный драйвер
Шаг 4. Анализ телеметрии — ключевое расхождение
Вся суть техники Symbolic Link + BYOVD в том, что разные источники логов видят одну и ту же загрузку по-разному. Именно это расхождение атакующий эксплуатирует. Event ID 7045 (System log, Service Control Manager) фиксирует создание нового сервиса:
SCM записал путь из binPath как есть — через junction. Для аналитика, фильтрующего по пути, это выглядит как легитимная загрузка из System32\drivers.
Правило в SIEM, проверяющее «путь начинается с C:\Windows\System32\drivers», пропустит эту загрузку.
А вот Sysmon Event ID 6 (DriverLoad) работает иначе — он разрешает reparse points и показывает реальный путь к файлу:
Один и тот же драйвер, одна и та же загрузка — а в логах два разных пути. SCM показывает «красивый» путь через junction (System32\drivers\TrustedVendor\), Sysmon — реальный (C:\TestBYOVD\real_driver\). И из-за этого, детектирование BYOVD, построенное только на SCM-событиях, ненадёжно.
Шаг 5. Выводы из эксперимента
Эксперимент показал расхождение между источниками телеметрии при загрузке драйвера через junction. Ключевые выводы для detection-инженера:
Sysmon EID 6 надёжнее SCM EID 7045 для анализа загрузки драйверов — он разрешает символические ссылки.
Детекты по пути к файлу должны учитывать возможность подмены через junction/symlink.
Хэш файла (из Sysmon EID 6) остаётся самым надёжным индикатором — junction не меняет содержимое файла.
Факт создания junction в директории drivers\ (Sysmon EID 11) — сильный индикатор сам по себе.
Это расхождение между источниками телеметрии мы учтём в разделе «Детектирование».
EDR Freeze: погружение антивируса в кому
В сентябре 2025 года тот же zerosalarium описал технику «EDR Freeze» (также называемую EDR Coma), которая позволяет «заморозить» процесс EDR/антивируса без его завершения.
Суть техники: вместо убийства процесса EDR (что само по себе генерирует алерт) атакующий запускает процесс werfault.exe, который вызывает функцию MiniDumpWriteDump() для целевого EDR-процесса. При создании дампа эта функция замораживает все потоки целевого процесса. Потоки EDR переводятся в состояние Suspend. Примитив BYOVD здесь не требуется — техника работает из user mode.
Для атакующего это удобнее прямого убийства процесса: нет события завершения процесса (Event ID 4689), нет срабатывания защиты от тамперинга (tamper protection), нет алерта об остановке сервиса. EDR выглядит работающим, но не видит ничего.
Детектирование EDR Freeze требует внешнего мониторинга: проверки, что EDR-агент продолжает отправлять телеметрию с ожидаемой частотой. Молчание агента при формально работающем процессе — критический индикатор компрометации.
Заморозка потоков через werfault.exe работает из user mode, но для полного ослепления EDR (включая kernel callbacks) по-прежнему нужен доступ к ядру. Воспроизведём полный цикл атаки на Sysmon через WinDbg — уже с модификацией структур ядра.
Практический пример: имитация FudModule через WinDbg — полный цикл атаки на Sysmon.
Воспроизведём ключевые механизмы руткита FudModule в лабораторной среде. Используем Local Kernel Debugging (WinDbg, подключение к собственному ядру) — это позволяет читать и модифицировать структуры ядра так же, как это делает FudModule через BYOVD-примитив. Цель — показать, что два изменения в памяти ядра полностью ослепляют Sysmon при формально работающем сервисе.
Среда: Windows 10 Build 19041, Sysmon установлен и активен, WinDbg x64 в режиме Local Kernel Debug.
Шаг 1. И��ходное состояние — Sysmon видит всё
Запускаем notepad.exe. В журнале Sysmon (Microsoft-Windows- Sysmon/Operational) появляется событие Event ID 1 — Process Create с полной информацией: путь к образу, командная строка, PID, хэши. Время события — 01:31. Всё работает штатно.
Шаг 2. Находим процесс Sysmon в памяти ядра
В WinDbg ищем все экземпляры Sysmon:
lkd> !process 0 0 Sysmon.exe
PROCESS ffffbc83eca72200 SessionId: 0 Cid: 0ae8 Peb: 4cf3ff7000 ParentCid: 0270 Image: Sysmon.exe PROCESS ffffbc83ed76d240 SessionId: 1 Cid: 1598 Peb: 7457f78000 ParentCid: 0ae8 Image: Sysmon.exe
Sysmon работает как два процесса: основной сервис в Session 0 (PID 2792) — он собирает телеметрию — и дочерний в Session 1. Нас интересует основной: его адрес _EPROCESS — ffffbc83eca72200.
Смотрим потоки основного процесса:
lkd> !process ffffbc83eca72200 2
17 потоков, все в состоянии WAIT — ожидают событий от ядра (создание процессов, загрузка DLL, файловые операции). Именно через эти потоки Sysmon получает и обрабатывает notify-коллбэки.
Шаг 3. Механизм 0x200 — снимаем защиту процесса (MitigationFlags)
FudModule 2.0 перед заморозкой EDR-процесса обнуляет его MitigationFlags — защитные флаги, которые Windows назначает процессу при создании. Смотрим текущие значения:
lkd> dt nt!_EPROCESS MitigationFlags ffffbc83eca72200 +0x9d0 MitigationFlags : 0x20 lkd> dt nt!_EPROCESS MitigationFlags2 ffffbc83eca72200 +0x9d4 MitigationFlags2 : 0x40000000
Что означают эти значения:
MitigationFlags: 0x20 — включён HeapTerminateOnCorruption (процесс
завершается при повреждении кучи).MitigationFlags2: 0x40000000 — включён CET User Shadow Stacks (аппаратная защита стека вызовов, если поддерживается процессором).
Обнуляем оба поля — снимаем все защитные политики процесса.
lkd> ed ffffbc83eca72200+0x9d0 0 lkd> ed ffffbc83eca72200+0x9d4 0
Проверяем:
lkd> dt nt!_EPROCESS MitigationFlags ffffbc83eca72200 +0x9d0 MitigationFlags : 0 lkd> dt nt!_EPROCESS MitigationFlags2 ffffbc83eca72200 +0x9d4 MitigationFlags2 : 0
Процесс Sysmon теперь лишён всех митигаций. В реальной атаке это делает процесс уязвимым для дальнейших манипуляций — инъекции кода, манипуляции хэндлами, заморозки потоков. Для EDR с tamper protection обнуление MitigationFlags — необходимый подготовительный шаг.
Зачем обнулять MitigationFlags? Современные EDR устанавливают ELAM-драйвер и получают статус Protected Process Light (PPL). PPL-процесс защищён от открытия хэндла с правами PROCESS_TERMINATE или PROCESS_VM_WRITE из непривилегированного контекста. Обнуление MitigationFlags — это подготовительный шаг, снимающий эту защиту перед основной атакой.
Шаг 4. Механизм 0x04 — отключаем глобальные notify-коллбэки
Теперь выполняем ключевое действие FudModule — обнуление PspNotifyEnableMask.
Это глобальная переменная ядра, битовая маска, определяющая, вызывает ли ядро зарегистрированные notification-коллбэки:
lkd> dd nt!PspNotifyEnableMask L1 fffff802`21d2e6a0 0000001f
Значение 0x1F (бинарно 00011111) — все пять типов коллбэков активны: Process, Thread, Image и дополнительные.
Обнуляем:
lkd> ed nt!PspNotifyEnableMask 0
Одна запись DWORD в память ядра — и ядро перестаёт вызывать все notification-коллбэки — не только Sysmon, но и любой другой EDR, зарегистрировавший свои функции через PsSetCreateProcessNotifyRoutine.
FudModule: обнуление PspNotifyEnableMask — отключает ВСЕ callbacks разом (грубо, но быстро).
Mimidrv / Callback Entry Overwrite: точечная перезапись конкретного callback EDR на RET (0xC3) — хирургический подход, отключает только целевой EDR, остальные продолжают работать.
Шаг 5. Проверяем результат — Sysmon ослеп
Запускаем notepad.exe несколько раз подряд. Переходим в Event Viewer → журнал Sysmon.
Результат: последнее событие Event ID 1 датировано 01:31 (до атаки). Notepad запускался в 01:35 — но Sysmon не зафиксировал ни одного запуска. Проверяем статус сервиса:
Сервис работает, процесс жив, но телеметрии уже нет. Что произошло?
Мы выполнили два действия, воспроизводящих механику FudModule:
Шаг | Действие | Структура ядра | Эффект |
|---|---|---|---|
1 | Обнуление MitigationFlags (0x200) | _EPROCESS+0x9d0, +0x9d4 | Снята защита процесса Sysmon |
2 | Обнуление PspNotifyEnableMask (0x04) | Глобальная переменная ядра | Ядро не вызывает notify-коллбэки |
Фактически мы повторили два из десяти механизмов FudModule 2.0. Разница между нашим экспериментом и реальной атакой — только в способе доступа к ядру: мы использовали WinDbg (отладочный интерфейс), FudModule использует примитив записи памяти, полученный через эксплуатацию уязвимого драйвера (BYOVD) или 0-day уязвимости (CVE-2024-21338).
Результат идентичен: EDR жив, но слеп. Сервис числится активным, процесс потребляет память и CPU — но ядро больше не отправляет ему уведомления о событиях. Для SOC-аналитика, смотрящего в консоль управления, агент выглядит «онлайн». Для атакующего — система полностью открыта.
Восстановление:
lkd> ed nt!PspNotifyEnableMask 0x1f lkd> ed ffffbc83eca72200+0x9d0 0x20 lkd> ed ffffbc83eca72200+0x9d4 0x40000000 lkd> ed ffffbc83eca72200+0x278 0
После восстановления маски Sysmon мгновенно начинает фиксировать новые события — подтверждение того, что процесс всё это время был жив и готов к работе, просто не получал данных от ядра.
Публичные тулкиты: BYOVD для масс
Мы разобрали механику FudModule и техники zerosalarium — но всё это требует глубокого понимания ядра. А что, если атакующему достаточно набрать одну команду?
На GitHub можно за 5 минут найти готовый BYOVD-фреймворк на любой вкус. Вот неполный список инструментов, которые мы видели в реальных инцидентах или в публичных репозиториях:
Тулкит | Драйвер | Метод | Язык |
Разные (LOLDrivers) | Завершение процессов EDR через IOCTL | Nim | |
Разные | Загрузка и эксплуатация уязвимых драйверов | C | |
Blackout (ZeroMemoryEx) | Разные | Универсальный BYOVD-фреймворк | C/C++ |
Разные | Убийство EDR/AV процессов | C | |
RTCore64.sys, gdrv.sys и др. | Автоматизированное отключение AV/EDR | C++ | |
Разные | BYOVD + обход tamper protection | C | |
Zemana AntiLogger | Продаётся за $3000 в даркнете | C++ |
Рассмотрим несколько примеров BYOVD-атак, в которых использовались вышеупомянутые доступные инструменты.
BYOVD встраивается ВНУТРЬ ransomware
В феврале 2026 года Symantec зафиксировал новый паттерн: группировка Reynolds встроила уязвимый драйвер NSecKrnl прямо в payload шифровальщика. Раньше BYOVD-компонент и ransomware были отдельными файлами с временным зазором между ними — этот зазор давал SOC шанс среагировать. Теперь одного бинарника достаточно для отключения EDR и шифрования. По оценке Symantec, BYOVD стал самой частой техникой обхода защиты в ransomware-атаках 2026 года.
POORTRY: кастомный вредоносный драйвер
Ещё интереснее POORTRY (Abyssworker) — не уязвимый легитимный, а специально написанный вредоносный драйвер, которому атакующие каким-то образом получили валидную подпись. Он маскируется под антивирусный компонент (например, драйвер Malwarebytes) и использовался в атаках Medusa и Osiris. Это следующий шаг эволюции: от «принеси свой уязвимый» к «принеси свой вредоносный».
RansomHub и EDRKillShifter
Группировка RansomHub разработала собственный инструмент EDRKillShifter, эксплуатирующий уязвимый драйвер TrueSight.sys. Инструмент стал стандартным компонентом их ransomware-набора и использовался для отключения EDR перед развёртыванием шифровальщика. По данным исследователей, EDRKillShifter применялся в десятках инцидентов в 2024 году.
Список ransomware-групп, использующих BYOVD, в таблице ниже. Формула у большинства одинаковая: сбросить подписанный драйвер, загрузить через SCM, через IOCTL завершить EDR, развернуть шифровальщик. Различаются только конкретные драйверы и IoC.
Тулкит | Драйвер | Метод | Язык |
blackout.sys (GMEREK) | Завершение процессов EDR через IOCTL | Nim | |
rentdrv2.sys (CVE-2023-44976) | Завершение процессов EDR через IOCTL | Rust | |
blackout.sys (GMEREK) | Завершение процессов EDR через IOCTL | C/C++ | |
wsftprm.sys (CVE-2023-52271) | Завершение процессов EDR через IOCTL | C++ | |
eb.sys (UnknownKiller.sys) | Завершение процессов EDR через IOCTL | C | |
zamguard64.sys / zam64.sys (Zemana) | Завершение процессов EDR через IOCTL | C++ |
Паттерн у всех атак одинаковый: дроп .sys в %TEMP%, создание kernel-сервиса, IOCTL для завершения EDR-процессов по списку. Для детектирования это удобно: поведение предсказуемо, IoC фиксированные. Разберём цепочку событий типичной BYOVD-атаки на примере тулкита Blackout (ZeroMemoryEx) — даже неуспешная попытка оставляет артефакты.
Рассмотрим BYOVD-тулкит на примере Blackout
Что такое 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: Сертификат был отозван поставщиком этого сертификата.
Что произошло. Драйвер Blackout.sys подписан валидной цифровой подписью — но Microsoft, узнав об использовании этого драйвера в атаках, отозвал сертификат и добавил его хэш в системный блок-лист (Disallowed Certificate Store). Windows проверяет этот список при каждой загрузке драйвера — даже без доступа к интернету, потому что CTL вшит в ОС.
Это один из механизмов защиты от BYOVD — но с существенным ограничением: он работает только для уже известных драйверов. База LOLDrivers.io содержит сотни уязвимых драйверов, и Microsoft физически не успевает отзывать все сертификаты. Атакующие просто берут менее известный драйвер и блокировка не срабатывает.
Что увидит SOC: даже несмотря на неудачную загрузку, попытка атаки оставила чёткие следы в телеметрии.
Event ID 7045 (System log — Service Control Manager):
Имя службы: Blackout Имя файла службы: C:\Blackout\Blackout.sys Тип службы: драйвер режима ядра Тип запуска службы: Вручную
Это событие — ключевой индикатор. Создание нового сервиса с типом «драйвер режима ядра», где путь к файлу указывает за пределы System32\drivers\ — аномалия, которая должна вызывать алерт максимального приоритета.
Хэш драйвера (SHA256): 18C909A2B8C5E16821D6EF908F56881AA0ECCEEACCB5FA1E54995935FCFD12F7
Детектирование BYOVD: что и как мониторить
Каждый этап BYOVD оставляет следы — надо знать, куда смотреть. Поделюсь подходом к выстраиванию эшелонированного детектирования, не привязанным к конкретной SIEM-платформе.
Правила детектирования 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 — не нужно собирать вручную.
Ограничение LOLDrivers шире, чем CVE-2013-3900: база содержит только те драйверы, которые кто-то уже исследовал. Драйвер вендора POS-терминалов или СКУД с идентичными IOCTL-примитивами (MmMapIoSpace, ZwOpenProcess без проверок) в каталог не попадёт, пока его не найдут. Об автоматизации этого поиска — в разделе "За пределами LOLDrivers".
Но учти ограничение: хэш-детекты обходятся через 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).
Когда мы ранее выполнили mklink /J "C:\Windows\System32\drivers\TrustedVendor" "C:\TestBYOVD\real_driver", Sysmon зафиксировал создание объекта в C:\Windows\System32\drivers\.
Правило в логическом виде:
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.
Комплексный подход: корреляция событий
Но самый мощный детект — корреляция слабых сигналов в рамках одного инцидента. Типичная цепочка 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-атака.
Готовые правила для KUMA SIEM
Для тех, кто работает с 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%')))
За пределами LOLDrivers: проактивный аудит драйверов
Хэш-детекты и Authentihash решают задачу обнаружения уже известных уязвимых драйверов. LOLDrivers.io — отличная база, но она покрывает только то, что кто-то уже нашел и зарепортил. А что с драйвером от вендора банковских терминалов? Или с утилитой контроля доступа, которую IT-отдел ставит на каждую рабочую станцию? Если в таком драйвере есть произвольное чтение/запись памяти через IOCTL, он ничем не отличается от RTCore64.sys с точки зрения атакующего. Только в базах его нет.
Bitdefender в 2025 году описал, как именно атакующие ищут новые драйверы для BYOVD: сканируют инсталляторы оборудования, вытаскивают .sys-файлы, проверяют IOCTL-хендлеры на типовые примитивы (маппинг физической памяти, произвольная запись, открытие процесса без проверок). Защитники могут делать то же самое.
IOCTLance: автоматический поиск уязвимостей в WDM-драйверах
IOCTLance — инструмент, созданный исследователем Zeze из TeamT5 и представленный на CODE BLUE 2023. Работает на движке символьного исполнения angr и решает конкретную задачу: берет .sys-файл WDM-драйвера и автоматически проверяет все его IOCTL-хендлеры на наличие опасных паттернов.
Алгоритм работы:
Проверяет наличие IoCreateDevice в таблице импортов — подтверждает, что файл является WDM-драйвером.
Извлекает имя устройства и символическую ссылку (DeviceName, SymbolicLink), находит dispatch-таблицу через запись в
DRIVER_OBJECT.MajorFunction[IRP_MJ_DEVICE_CONTROL].Запускает символьное исполнение по каждому IOCTL-коду, помечая входной буфер (SystemBuffer) как tainted — ненадежный.
Отслеживает, доходят ли tainted данные до опасных вызовов ядра: MmMapIoSpace, ZwOpenProcess, memcpy с контролируемым размером, __writemsr, ZwDeleteFile и других.
На выходе — тип уязвимости, адрес в коде, IOCTL-код для воспроизведения, ограничения (constraints) на входные данные.
IOCTLance покрывает 9 классов уязвимостей:
Класс уязвимости | Ключевые API | Импакт |
Map Physical Memory | MmMapIoSpace, ZwMapViewOfSection | EoP, kernel code execution |
Controllable Process Handle | ZwOpenProcess (без OBJ_FORCE_ACCESS_CHECK) | Завершение/инъекция в любой процесс |
Buffer Overflow | memcpy с tainted size | Kernel code execution |
Null Pointer Dereference | Разыменование без проверки | DoS, потенциально EoP |
Read/Write Controllable Address | Запись по адресу из input buffer | Произвольная запись в ядро |
Arbitrary Shellcode Execution | call по tainted адресу | Полный контроль ядра |
Arbitrary WRMSR | __writemsr с контролируемыми параметрами | Отключение SMEP, kernel exec |
Arbitrary Out | outbyte, outword | DoS, firmware-модификация |
Dangerous File Operation | ZwDeleteFile, ZwCreateFile без проверок | Удаление произвольных файлов |
Результаты оценки на 104 известных уязвимых драйверах и 328 неизвестных: 117 новых уязвимостей в 26 драйверах, 41 присвоенный CVE. Среди затронутых вендоров: AMD (CVE-2023-20556, CVE-2023-20561, CVE-2023-20562), DriverGenius (CVE-2023-1679), Microsoft Visual Studio (CVE-2023-36758, CVE-2023-36759), IObit, Watchdog Anti-Virus, EnTech Taiwan.
В августе 2025 Mike Bommarito выпустил enhanced fork IOCTLance: 13 классов уязвимостей вместо 9, прирост скорости 25–35%, плагинная архитектура. Ключевое отличие — форк умеет детектировать buffer overflow с контролем instruction pointer (RCE), а не только write-примитивы. Например, в драйвере ilp60x64_3.sys форк нашел 35 уязвимостей против 19 у оригинала, включая 10 критических buffer overflow с перехватом управления.
Хэши — не панацея
Проблема хэш-детектирования (включая Authentihash) не ограничивается CVE-2013-3900 и padding-модификацией. Есть более фундаментальное ограничение: в базе LOLDrivers только те драйверы, которые кто-то исследовал, нашел уязвимость, зарепортил CVE и добавил в каталог.
Драйвер от производителя POS-терминалов, системы контроля доступа (СКУД), медицинского оборудования или промышленного контроллера может содержать точно те же баги: произвольное чтение/запись памяти через IOCTL, маппинг физической памяти, открытие процесса без OBJ_FORCE_ACCESS_CHECK. Эти драйверы подписаны, DSE их загрузит, а в LOLDrivers их нет.
Для атакующего найти такой драйвер — просто праздник: нет хэша в базе, нет Sigma-правила, Authentihash неизвестен. Единственный способ поймать такую атаку — поведенческие (robust) детекты: аномальный путь загрузки, создание kernel-сервиса из нетипичного контекста, завершение EDR-процессов.
Применение в SOC: от теории к практике
Для SOC-команды IOCTLance и подобные инструменты интересны с двух сторон.
Проактивная оценка рисков. Собрать .sys-файлы со всех драйверов, установленных в инфраструктуре (KEDR, SCCM, GPO-скрипт), прогнать через IOCTLance. Результат — список драйверов с потенциальными IOCTL-уязвимостями, которые нужно проверить вручную. Это не замена penetration testing, но сужает поверхность поиска.
Пример запуска IOCTLance по директории с драйверами:
python3 analysis/ioctlance.py ./collected_drivers/ \ -T 1200 -t 40 --output results.json
Понимание вектора атаки. Зная, какие классы уязвимостей встречаются в WDM-драйверах чаще всего (map physical memory, read/write controllable address, controllable process handle), detection engineer может строить более точные поведенческие детекты.
Если IOCTLance находит в драйвере примитив ZwOpenProcess с контролируемым PID, это сигнал: этот драйвер может быть использован для завершения процесса EDR через IOCTL. Такой драйвер нужно включить в whitelist/blacklist независимо от наличия в LOLDrivers.
Другие подходы к поиску уязвимых драйверов
IOCTLance — не единственный инструмент. VMware Threat Analysis Unit (TAU) в 2023 году разработал IDAPython-скрипт для анализа WDM- и WDF-драйверов, фокусируясь на firmware-доступе (port I/O, memory-mapped I/O). Скрипт автоматически находит IOCTL-хендлеры, восстанавливает типы параметров IRP и проверяет, контролируются ли входные данные на пути к опасным API. Подход TAU покрывает не только WDM, но и WDF-драйверы (Windows Driver Framework), которые IOCTLance пока не поддерживает.
Более ранние проекты (Screwed-Drivers, POPKORN) тоже использовали символьное исполнение для поиска багов в драйверах, но страдали от path explosion и покрывали меньше классов уязвимостей. Фаззеры (ioctlfuzzer, ioctlbf) требуют реальную среду исполнения и плохо масштабируются.
Quarkslab в сентябре 2025 опубликовал пошаговый разбор CVE-2025-8061 в драйвере Lenovo: METHOD_NEITHER без валидации адресов, контролируемый IOCTL дает read/write примитив ядра. Они проделали ровно ту работу, которую IOCTLance автоматизирует: нашли хендлер, проследили путь данных, убедились, что входной буфер доходит до опасного вызова без проверок. Разница в том, что ручной анализ занял недели, а IOCTLance способен прогнать тот же драйвер за минуты.
Ограничения
IOCTLance не волшебная палочка. Символьное исполнение сталкивается с path explosion на сложных драйверах — не все пути будут исследованы за разумное время. Ложноположительные результаты требуют ручной верификации в IDA/Ghidra: IOCTLance может пропустить проверку внутри try-except блока или не учесть косвенную валидацию через RtlInitUnicodeString. Инструмент работает только с x64 WDM-драйверами и не покрывает WDF, KMDF, UMDF.
Тем не менее для задачи массового скрининга драйверов инфраструктуры на типовые BYOVD-уязвимости — это рабочий вариант. Результат не «драйвер X уязвим», а «драйвер X требует приоритетной ручной проверки».
Митигации: как снизить риск BYOVD
BYOVD не закрывается одним патчем — уязвимых подписанных драйверов сотни. Но усложнить атаку можно:
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 на уровне гипервизора.
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
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) может блокировать загрузку известных уязвимых драйверов. Рекомендуется включить в режиме аудита, а затем перевести в блокировку после проверки совместимости.
Мониторинг сервисов и драйверов:
Настроить аудит создания сервисов (Event ID 7045, 4697).
Мониторить загрузку драйверов через Sysmon (Event ID 6) с автоматической проверкой хэшей по LOLDrivers.
Внедрить EDR heartbeat-мониторинг с алертом на молчание агента.
Ограничить права на создание сервисов типа kernel driver — минимизировать число учётных записей с привилегией SeLoadDriverPrivilege.
Принцип наименьших привилегий
BYOVD-атака требует привилегий администратора (для загрузки драйвера) или LOCAL_SERVICE (для CVE-2024-21338). Меньше админов на эндпоинтах — меньше шансов у атакующего загрузить драйвер. Audit и контроль использования привилегированных учётных записей (PAM, JIT-доступ) остаются критически важными.
Заключение
BYOVD стал стандартным этапом ransomware-операций, доступным через готовые тулкиты и базы уязвимых драйверов. Группировка Lazarus показала потолок сложности — руткит FudModule, последовательно отключающий семь (а затем десять) механизмов мониторинга ядра. Публичные инструменты снизили порог входа до минимума.
Для SOC-команд и detection-инженеров это означает работу на двух уровнях.
Реактивный: хэш-детектирование загрузки уязвимых драйверов (LOLDrivers.io + Authentihash), мониторинг создания kernel-сервисов из нетипичных источников, heartbeat-мониторинг EDR-агентов с алертом на молчание, корреляция: файл .sys + сервис + завершение EDR = автоматическая изоляция, HVCI/ASR rules/Microsoft Vulnerable Driver Blocklist.
Проактивный: аудит установленных драйверов на наличие IOCTL-уязвимостей (IOCTLance, IDAPython-скрипты TAU), включение результатов в whitelist/blacklist SIEM, оценка рисков ПО до его внедрения в инфраструктуру.
Одного EDR недостаточно.
Если ваша стратегия безопасности начинается и заканчивается на EDR, BYOVD-атака
может оставить вас полностью слепыми. Сетевой мониторинг, контроль привилегий, HVCI и проверка живости агентов — надёжнее любого отдельного EDR.
Чек-лист: защита от BYOVD
Для распечатки и проверки.
Предотвращение
☐ HVCI (Memory Integrity) включён на рабочих станциях и серверах
☐ Microsoft Vulnerable Driver Blocklist актуален
☐ ASR-правило «Block abuse of exploited vulnerable signed drivers» активно
☐ SeLoadDriverPrivilege ограничена минимальным числом учётных записей
☐ MFA на VPN и всех внешних точках входа
☐ CVE-2013-3900: EnableCertPaddingCheck включён (реестр)
Обнаружение
☐ Sysmon установлен, EID 6 собирается без агрессивной фильтрации
☐ <CheckRevocation/> включён в конфигурации Sysmon
☐ LOLDrivers-хэши импортированы как lookup-таблица в SIEM
☐ EID 7045 мониторится с фильтром type=kernel
☐ Командная строка логируется в EID 4688 (GPO → Include command line)
☐ Правило на sc.exe create type=kernel в SIEM
☐ Правило на массовое завершение EDR-процессов в SIEM
☐ Authentihash из LOLDrivers импортирован в SIEM (дополнение к SHA256)
☐ Правило на загрузку драйвера с невалидной подписью (Sysmon EID 6 + SignatureStatus)
☐ Проведён аудит установленных драйверов (.sys) через IOCTLance или аналоги; результаты интегрированы в SIEM-правила
Контроль
☐ Heartbeat-мониторинг EDR-агентов настроен (алерт при молчании > 5 мин)
☐ Корреляция: файл .sys + сервис + завершение EDR = автоизоляция
☐ Периодическая проверка целостности ETW-сессий (logman query)
☐ Процесс оценки безопасности драйверов включён в процедуру приёмки нового ПО (security review)
Если понравилась статья — приглашаю вас в канал Goodman Security Lab, где я рассказываю просто и доступно о сложном в ИБ.
Источники
1. ESET Research — «Lazarus & BYOVD: Evil to the Windows Core», 2022
2. Black Hat Asia 2024 — «From BYOVD to a 0-day: Unveiling Advanced Exploits i Cyber Recruiting Scams»
3. LOLDrivers.io — Living Off The Land Drivers (loldrivers.io)
4. zerosalarium — «Symbolic Link + BYOVD: EDR Blind Spot», January 2025
5. zerosalarium — «EDR Freeze: Puts EDRs into Coma», September 2025
6. Huntress — «Top 3 Cybersecurity Threats of 2024»
7. Trend Micro — «Kasseika Ransomware Deploys BYOVD Attacks», January 2024
8. Cisco Talos — «BYOVD Loader — Deadlock Ransomware», December 2025
9. CVE-2021-21551 (Dell dbutil_2_3.sys), CVE-2024-21338 (appid.sys), CVE-2024- 51324 (BdApiUtil.sys), CVE-2025-61155 (GameDriverx64.sys)
10. GitHub: NimBlackout, GhostDriver, Blackout, Reaper, AV-EDR-Killer, UnknownKiller
11. Huntress — EnCase BYOVD EDR Killer (фев 2026)
12. Forbes — APT-группы, атакующие Россию в 2025 —forbes.ru/tekhnologii/554548
13. CNews — Хакеры перешли к уничтожению инфраструктуры (дек 2025)
14. Solar 4RAYS — Shedding Zmiy: руткит Puma (мар 2025)
15. xakep.ru — Terminator: убийца антивирусов с хакерских форумов (02.06.2023)
16. Kaspersky Securelist — Прогнозы по продвинутым угрозам 2025
17. Sophos — Terminator tool variants and EDRKillShifter (мар 2024)
18. Matt Hand, Evading EDR: The Definitive Guide to Defeating Endpoint Detection Systems, No Starch Press, 2024
19. Symantec — «Reynolds: Defense Evasion Embedded in Payload», фев 2026
20. Symantec — «Osiris Ransomware + POORTRY», янв 2026
21. Dark Reading — «Microsoft Under Pressure to Bolster BYOVD Defenses», фев 2026
22. ThreatIntelReport — «BYOVD in 2026: Signed-Driver Loophole», фев 2026
23. TeamT5 / Zeze — "Enhanced Vulnerability Hunting in WDM Drivers Using Symbolic Execution and Taint Analysis", CODE BLUE 2023 (github.com/zeze-zeze/ioctlance)
24. VMware TAU — "Hunting Vulnerable Kernel Drivers", октябрь 2023 (blogs.vmware.com/security/2023/10/hunting-vulnerable-kernel-drivers.html)
25. Quarkslab — "BYOVD to the next level: exploiting a vulnerable driver (CVE-2025-8061)", сентябрь 2025 (blog.quarkslab.com)
26. Bitdefender TechZone — "What is BYOVD", 2025 (techzone.bitdefender.com)
27. Mike Bommarito — IOCTLance Enhanced Fork, август 2025 (michaelbommarito.com)
Мы активно развиваем MLSecOps для защиты ИИ-систем. У нас открыта вакансия Специалист по защите искусственного интеллекта (MLSecOps). Будете анализировать безопасность систем, разрабатывать защиту от атак, проводить аудиты и тестирование AI-систем и разрабатывать политики и процессы безопасности. Присылайте отклики!
Читайте также:
