В коротком посте я рассказал о находке на сервере оптовой компании: старая, давно забытая программа для резервного копирования и клонирования дисков продолжала жить в системе через свой драйвер — с правами уровня ядра. Здесь разберу техническую сторону подробнее: как именно такие драйверы эксплуатируются, почему антивирус здесь бессилен и что конкретно нужно сделать, чтобы закрыть этот класс уязвимостей, а не одну конкретную программу.
Суть проблемы: driver, а не приложение
Программы для клонирования и бэкапа дисков работают с носителем на низком уровне — им нужен прямой доступ к секторам диска, к физической памяти, иногда к прошивке. Для этого производитель ставит в систему kernel-mode драйвер: он подписан (WHQL/EV-подпись), поэтому Windows Driver Signature Enforcement и Secure Boot ему доверяют по умолчанию. Проблема в том, что такой драйвер часто открывает интерфейс IOCTL, доступный любому процессу в системе, без проверки, кто и с какими правами к нему обращается.
Это классический сценарий BYOVD — Bring Your Own Vulnerable Driver. Атакующему не нужно писать свой драйвер и подписывать его — он использует уже установленный и легитимно подписанный, но уязвимый драйвер третьей стороны как отмычку в ядро.
Как это эксплуатируется
Ниже — типичная последовательность действий для такого класса уязвимостей, без привязки к конкретной жертве.
1. Разведка окружения
Первым делом атакующий (либо пентестер) собирает список загруженных драйверов и служб — вручную или через легитимные утилиты, что не вызывает подозрений у EDR:
driverquery /v /fo table
Имя модуля Отображаемое имя Тип драйвера Путь к драйверу
---------- ----------------------- ------------ ----------------------------------------
aomdrv AOMEI Image Deploy Drv Ядро C:\Windows\System32\drivers\aomdrv.sys
Дальше — проверка через Sysinternals Autoruns или sigcheck, чтобы убедиться, что драйвер подписан и стартует автоматически при загрузке (Boot/System start), а не по требованию:
sigcheck64.exe -a C:\Windows\System32\drivers\aomdrv.sys
Verified: Signed
Signing date: ...
Publisher: AOMEI Tech Co., Ltd.
Start Type: BOOT_START
Hash драйвера сверяется с публичной базой известных уязвимых драйверов (проект loldrivers.io) — если он там уже есть, эксплойт скорее всего публичный и стабильный.
2. Поиск и подтверждение уязвимого IOCTL-интерфейса
Драйвер общается с userspace через DeviceIoControl. Исследователь фаззит доступные IOCTL-коды и смотрит, какие из них дают чтение/запись физической памяти без проверки привилегий вызывающего процесса — типовой паттерн через MmMapIoSpace или прямой доступ к \\Device\\PhysicalMemory:
PS C:\> .\ioctlfuzz.exe --device \\.\aomdrv --range 0x9C402000-0x9C402FFF
[+] IOCTL 0x9C402010 accepted, no ACL check
[+] Response indicates raw physical memory write primitive
Если DACL устройства разрешает доступ группе Everyone (а не только SYSTEM/Administrators), любой процесс без прав администратора и без запроса UAC получает примитив чтения/записи произвольной физической памяти — а значит, и памяти ядра.
3. Эскалация до кода в ядре и обход Secure Boot
Имея arbitrary read/write в память ядра, атакующий может подделать структуры токенов процесса (token stealing, классика для LPE), либо пойти дальше — записать код в область, из которой он выполнится ещё до старта Windows: в NVRAM UEFI-переменные или в EFI System Partition.
# Монтирование скрытого EFI-раздела
mountvol S: /S
dir S:\EFI\Microsoft\Boot\
bootmgfw.efi
bootx64.efi
Для прямого доступа к SPI-флешу материнской платы и NVRAM в таких сценариях используются инструменты вроде RWEverything или CHIPSEC (фреймворк для аудита прошивки от Intel), которые как раз и опираются на подобные легитимные, но уязвимые драйверы как на транспорт:
chipsec_main.py -m tools.uefi.decode -a spi_efi.bin
[CHIPSEC] Reading SPI flash region... OK
[CHIPSEC] Found UEFI DXE driver volume at offset 0x00A12000
Дальше — модификация загрузочного драйвера/DXE-модуля или подмена bootmgfw.efi на модифицированный. Код исполняется на этапе, когда операционной системы физически ещё нет — ни антивирус, ни EDR, ни Defender не запущены в принципе.
Что и почему сработало бы дальше
- Персистентность вне диска с ОС. Переустановка Windows не помогает — заражённая область находится в SPI-флеше или в NVRAM материнской платы, а не на системном разделе.
- Невидимость для средств защиты. Antivirus/EDR стартуют вместе с ОС, то есть заведомо позже точки закрепления кода. Это тот же класс угроз, что и известные UEFI-буткиты (BlackLotus, MosaicRegressor, LogoFAIL) — все они держались именно на предзагрузочном уровне.
- Готовая платформа для шифровальщика или шпиона. Из закреплённого на этом уровне кода можно на каждой загрузке подгружать полезную нагрузку — например, дроппер шифровальщика, который срабатывает уже внутри свежепереустановленной, «чистой» Windows.
- Масштаб на весь парк техники. Если уязвимая утилита ставилась централизованно (что типично для бэкап- и клонирующего ПО в компаниях), под угрозой не один компьютер, а весь парк — десятки машин одновременно.
Полутехнические пруфы: на что смотреть
- Путь и тип старта: драйверы такого класса лежат в
C:\Windows\System32\drivers\*.sysи часто прописаны как BOOT_START или SYSTEM_START в реестре —HKLM\SYSTEM\