CVE-2026 уязвимость драйвера Windows: как подписанный бинарник прячет инъекцию в .rsrc секции

В апреле 2026 CISA добавила CVE-2026-33825 в каталог KEV (Known Exploited Vulnerabilities — список уязвимостей, которые УЖЕ эксплуатируются в реальных атаках) с пометкой «ransomware». На GitHub появился публичный PoC (Joe1sn/CVE-2026-33825, «RedSun PoC for self use»); по описанию NVD — повышение привилегий локально для авторизованного атакующего. Подпись Microsoft Defender валидна, антивирус работает, а атакующий получает полный контроль над системой. Звучит как баг в матрице.

Но проблема глубже конкретного CVE. Windows проверяет наличие и корректность подписи драйвера — но не анализирует каждый байт содержимого. Ресурсная секция PE-файла (.rsrc) — одно из тех мест, где вредоносная нагрузка проходит мимо проверки. Уточнение: CVE-2026-33825 — уязвимость логики контроля доступа в Defender, а не обход подписи через .rsrc. Технику инъекции в ресурсные секции мы рассмотрим как самостоятельный класс угроз, дополняющий картину.

Подпись кода Windows и загрузчик драйверов: что проверяется при загрузке

Чтобы понять, где прячется инъекция, нужно разобраться, что именно Windows проверяет при загрузке драйвера в ядро — и где проверка заканчивается.

PE-формат: скелет любого бинарника Windows. Каждый .exe, .dll или .sys в Windows — PE-файл (Portable Executable). Внутри он разбит на секции, у каждой своя роль:

• .text — машинный код, основные инструкции
• .data — глобальные переменные программы
• .rdata — таблицы импорта и константы
• .rsrc — ресурсы: иконки, строки, информация о версии, манифесты и произвольные бинарные данные
• .reloc — таблица релокаций для загрузки по разным адресам памяти

У каждой секции свой заголовок: виртуальный адрес, размер на диске (SizeOfRawData), размер в памяти (VirtualSize), флаги доступа (чтение, запись, исполнение). Эти заголовки — первое, на что смотрит реверс-инженер при анализе PE-секций.

Authenticode: что подписывается, а что нет. Authenticode — технология цифровой подписи кода Microsoft. При подписании утилита вычисляет хеш PE-файла и связывает его с сертификатом разработчика. Критический момент: хеш Authenticode охватывает не весь файл целиком. Из расчёта исключаются поле Checksum в Optional Header, запись Certificate Table в Data Directory и сами данные сертификата.

Следствие: данные, добавленные после таблицы сертификатов (overlay — область за пределами секций файла), не влияют на валидность подписи. Подпись зелёная — а в хвосте файла лежит шеллкод.

Driver Signature Enforcement (DSE). Начиная с 64-битных Windows Vista, загрузить .sys без валидной подписи в ядро нельзя — система заблокирует его на этапе инициализации. DSE проверяет наличие и криптографическую валидность подписи, но не сканирует содержимое секций на предмет вредоносного кода. Валидная подпись — необходимое, но недостаточное условие безопасности.

Зачем атакующему лезть в .rsrc. Монетизация доступа к ядру — вот ради чего всё затевается. Загрузив код на уровне ядра, атакующий может отключить EDR (Endpoint Detection and Response — система обнаружения и реагирования на угрозы на конечных точках), установить руткит, развернуть шифровальщик или перехватывать сетевой трафик. По данным CrowdStrike, 79% атак в 2024 году проводились без традиционного вредоносного ПО — через hands-on-keyboard активность и легитимные инструменты (living-off-the-land), частью которых могут быть подписанные бинарники.

Ресурсная секция PE файла: как в ней прячут вредоносный код

Ресурсная секция — как приложения к письму: основной текст (код в .text) проверяют тщательно, а вложения часто пролистывают. При реверсе вредоносного ПО Windows именно .rsrc нередко содержит скрытую нагрузку.

Что в .rsrc у легитимного драйвера. Обычно — иконка (RT_ICON), информация о версии (RT_VERSION), манифест совместимости (RT_MANIFEST), строки локализации (RT_STRING). Размер ресурсной секции у типичного WDM/KMDF-драйвера (WDM — Windows Driver Model, KMDF — Kernel-Mode Driver Framework — два стандарта написания драйверов ядра) — от нескольких сотен байт до пары килобайт.

Как прячут payload. Три основных подхода:

Первый — зашифрованный payload до подписания. Малварь компилируется с зашифрованным шеллкодом в ресурсах, затем подписывается скомпрометированным или украденным сертификатом. Подпись валидна, .rsrc содержит payload — всё формально корректно.

Второй — BYOVD (Bring Your Own Vulnerable Driver). Атакующий берёт легитимно подписанный драйвер с известной уязвимостью, загружает его штатным путём и эксплуатирует уже в ядре. Подпись не ломается — драйвер-то подлинный.

Третий — overlay-данные. Payload добавляется за пределами секций, после таблицы сертификатов, где Authenticode-хеш его не покрывает.

Красные флаги при анализе PE-секций. На что обращать внимание, когда .sys-файл попал на стол:

Обфускация в PE файлах через ресурсы устойчива к детектированию: антивирусные движки фокусируются на инструкциях в .text, а содержимое .rsrc часто проходит по касательной.

CVE-2026-33825 — BlueHammer и путь от Defender до SYSTEM

По данным NVD: Insufficient Granularity of Access Control (CWE-1220 — слишком грубый контроль доступа, когда политика не различает операции с достаточной точностью) в Microsoft Defender Antimalware Platform. CVSS 7.8 HIGH с вектором:

• AV:L — атака локальная, нужен доступ к машине
• AC:L — низкая сложность эксплуатации
• PR:L — достаточно обычного пользователя
• UI:N — жертве ничего делать не нужно
• C:H / I:H / A:H — полный импакт на конфиденциальность, целостность и доступность

По MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1068 — идентификаторы конкретных техник) тип уязвимости (локальное повышение привилегий) соответствует технике Exploitation for Privilege Escalation (T1068, тактика Privilege Escalation). Маппинг основан на классе уязвимости (EoP), а не на подтверждении конкретного механизма эксплуатации.

Пометка ransomware означает, что в каталоге CISA KEV поле knownRansomwareCampaignUse = Known — уязвимость зафиксирована в ransomware-кампаниях. Это не автоматическое подтверждение конкретного PoC или механизма эксплуатации.

Официальные источники (NVD, MSRC) описывают уязвимость только как «insufficient granularity of access control» в Microsoft Defender Antimalware Platform без раскрытия деталей механизма. Конкретная цепочка атаки на момент публикации не документирована в открытых источниках. Публичный PoC (Joe1sn/CVE-2026-33825) доступен на GitHub, но его механика не верифицирована независимыми исследователями.

Патч — обновление Defender Antimalware Platform до актуальной версии (см. https://www.microsoft.com/en-us/wdsi/defenderupdates). Проверить версию: Get-MpComputerStatus | Select-Object AMProductVersion.

EPSS (Exploit Prediction Scoring System — оценка вероятности от 0 до 1, что уязвимость начнут эксплуатировать в ближайшие 30 дней) для этого CVE — 0.0040, перцентиль 0.32 (ниже медианы). Показательный разрыв: уязвимость уже в KEV с пометкой ransomware, а EPSS — низкий. Дело в том, что EPSS оценивает вероятность начала эксплуатации, а не текущий статус — когда атаки уже идут, метрика может отставать. На практике это означает: не полагайтесь на один скоринг, смотрите KEV и EPSS вместе.

CVE-2026-21709 — обход Driver Signature Enforcement через инъекцию команд

CVE-2026-21709 — уязвимость типа Command Injection (CWE-77 — инъекция команд через спецсимволы) в механизме проверки подписи драйверов Windows [источник атрибуции SentinelOne требует независимой проверки]. CVSS 6.7 MEDIUM (вектор AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). Обратите внимание на PR:H — требуются права локального администратора. Атакующий обходит DSE и загружает неподписанный или вредоносно подписанный драйвер в ядро.

Это пост-компрометационная техника: сначала атакующий получает admin-права другим способом, затем использует CVE-2026-21709 для закрепления на уровне ядра — установки руткита, отключения EDR или развёртывания бэкдора. Другими словами, сама по себе эта уязвимость не даёт первоначальный доступ — она нужна, чтобы «вкопаться» глубже после взлома.

Среди возможных индикаторов компрометации [атрибуция SentinelOne требует проверки]: неподписанные драйверы в %SystemRoot%\System32\drivers\, изменения BCD (Boot Configuration Data — данные конфигурации загрузки) и вызовы bcdedit.exe с параметрами, влияющими на DSE. Детектирование: Event ID 7045 (установка сервиса/драйвера) и Event ID 3077 (блокировка Code Integrity).

Mitigation — включение HVCI (Hypervisor-Protected Code Integrity): гипервизор дополнительно верифицирует каждый загружаемый драйвер. По документации Microsoft, это один из самых эффективных механизмов защиты от обхода DSE.

BYOVD и Microsoft Vulnerable Driver Blocklist

Microsoft периодически обновляет Driver Blocklist, добавляя драйверы с известными уязвимостями. Например, CVE-2023-43896 (CWE-120 — переполнение буфера в Macrium Reflect 8.1.7544 и ниже) — один из кандидатов на блокировку [конкретный драйвер и дата добавления в блоклист требуют проверки по официальному списку Microsoft]. По данным Microsoft Support, при загрузке заблокированного драйвера Windows записывает Event ID 3077 в лог Code Integrity (конкретный Policy ID зависит от применённой политики).

Подключать модем не нужно: само наличие драйвера на диске делает систему уязвимой.

Масштаб проблемы: по данным IBM X-Force, среднее время между публикацией CVE и устранением в организации — 29 месяцев. Подписанные уязвимые драйверы живут в продакшене годами после раскрытия. Два с половиной года — за это время можно дважды сменить работу, а драйвер всё ещё на месте.

Статический анализ PE-секций подозрительного драйвера: делай раз, делай два, делай три

Практический блок для тех, кто хочет руками проверить .sys-файл. Предпосылки: Windows 10/11, установленный Sysinternals Suite (бесплатный пакет Microsoft), опционально Visual Studio Build Tools для dumpbin.

Шаг 1. Проверить подпись. Запустите PowerShell от обычного пользователя:

# Проверка Authenticode-подписи драйвера
Get-AuthenticodeSignature "C:\path\to\driver.sys" | Format-List *
# Ожидаемый вывод: Status = Valid / NotSigned / HashMismatch
# Обратите внимание на SignerCertificate — кем подписан

Если Status = Valid — подпись формально корректна, но это не гарантия безопасности. Посмотрите на поле SignerCertificate: если сертификат выдан неизвестному вендору или истёк — повод копать дальше. Альтернатива: sigcheck -a -h driver.sys из Sysinternals покажет хеши файла и расширенную информацию о подписи.

Шаг 2. Сравнить размеры секций. Запустите dumpbin /headers driver.sys (из Visual Studio Developer Command Prompt) или откройте файл в CFF Explorer (бесплатный PE-редактор) и перейдите в Section Headers. Что сравнивать:

• SizeOfRawData у .rsrc больше .text в 5+ раз — аномалия; драйверу ядра не нужны ресурсы размером в сотни килобайт
• VirtualSize значительно отличается от SizeOfRawData — возможны скрытые данные в padding
• Флаг IMAGE_SCN_MEM_EXECUTE (0x20000000) у .rsrc — ресурсная секция помечена как исполняемая, чего быть не должно

Шаг 3. Проанализировать содержимое ресурсов. Откройте файл в Resource Hacker или PE Explorer. Нормальный драйвер содержит RT_VERSION и возможно RT_MANIFEST. Если видите RT_RCDATA с нестандартным идентификатором — это кастомный ресурс, потенциально содержащий payload. Проверьте энтропию секции: значение близкое к 8.0 указывает на зашифрованные или сжатые данные. Утилиты pestudio и Detect It Easy показывают энтропию по секциям автоматически.

Шаг 4. Проверить overlay. В sigcheck -a driver.sys сравните размер файла на диске с суммарным размером всех секций. Значительная разница означает наличие overlay-данных — области за пределами PE-структуры, не покрытой Authenticode.

Шаг 5. Свериться с блоклистом. Откройте Event Viewer → Applications and Service Logs → Microsoft → Windows → CodeIntegrity → Operational. Ищите Event ID 3077 — он фиксирует блокировку драйвера политикой Code Integrity.

Детектирование скрытых инъекций в исполняемые файлы: Sigma-правила и мониторинг

Для работы на стороне защиты — мониторинг загрузки драйверов входит в базовый набор задач Blue Team.

Event ID для мониторинга. Ключевые события Windows:

Sigma-правила. В репозитории SigmaHQ (github.com/SigmaHQ/sigma — открытая библиотека правил детектирования в YAML-формате) есть готовые правила для этого класса угроз:

• driver_load_win_vuln_dell_driver.yml — детектирует загрузку известных уязвимых драйверов Dell (типичный BYOVD-сценарий)
• driver_load_win_mal_poortry_driver.yml — ловит драйвер Poortry, который использовался в реальных атаках
• proc_creation_win_reg_service_imagepath_change.yml — отслеживает изменение ImagePath сервиса через реестр (техника T1574.011 — Services Registry Permissions Weakness)

Для тестирования детектирования: в Atomic Red Team (redcanaryco/atomic-red-team — открытый набор эмуляций MITRE ATT&CK) есть сценарий «Scattered Spider BYOVD (CVE-2015-2291 for Intel Ethernet Diagnostics Driver)» для T1068 — эмуляция загрузки уязвимого драйвера Intel Ethernet Diagnostics (CWE-20, Improper Input Validation), который по NVD может вызвать отказ в обслуживании или потенциально выполнение кода с правами ядра. Подтверждённый публичный эксплойт (Exploit-DB #36392) ограничен DoS-эффектом.

D3FEND-контрмеры. MITRE D3FEND (d3fend.mitre.org — knowledge graph защитных техник, зеркальный ATT&CK, но для обороны) рекомендует для противодействия T1068:

• D3-PSEP (Process Segment Execution Prevention) — запрет исполнения данных: DEP/NX не даст выполнить шеллкод, извлечённый из .rsrc и загруженный в память
• D3-SAOR (Segment Address Offset Randomization) — ASLR, рандомизация адресов, затрудняющая предсказание расположения кода в памяти
• D3-SICA (System Init Config Analysis) — анализ конфигурации при загрузке, позволяющий обнаружить подменённые или добавленные драйверы до инициализации системы

Главная проблема не в конкретных CVE — они приходят и уходят с каждым Patch Tuesday. Проблема в модели доверия: Windows до сих пор работает по принципу «подписано — значит допущено», а индустрия строит детектирование вокруг .text секции и известных сигнатур. По данным Mandiant, эксплойты — вектор начального доступа номер один (38% инцидентов в 2024 году), и значительная доля из них задействует подписанные компоненты. BYOVD-атаки стали настолько частыми, что Microsoft пришлось вести и регулярно обновлять блоклист уязвимых драйверов — по сути признав: модель «подпись = доверие» в одиночку не работает.

Мой прогноз: в ближайшие год-два атаки через ресурсные секции PE-файлов будут расти — не потому что техника новая (ей десятилетия), а потому что EDR-вендоры сосредоточились на поведенческом анализе runtime, а статический анализ ресурсов оставили на откуп устаревшим YARA-правилам. Тот, кто разбирает PE-структуру руками — через Ghidra, IDA, CFF Explorer — и понимает, что именно Authenticode не проверяет, будет востребован в ближайшие годы. Если хочешь не просто читать разборы, а пройти базу системно — IB Basics на codeby.school закрывает фундамент за пару месяцев, дальше уже можно прицельно идти в реверс или форензику.