Автоматическая установка USB-драйверов в Windows 11 может стать прямым мостом к правам SYSTEM - и это не теория. На DEF CON 34 исследователи Алехандро Эрнандо и Борха Мартинес показали рабочую цепочку, которая поднимает непривилегированного пользователя до максимальных полномочий за счёт штатного поведения Plug and Play (PnP). Демонстрацию проводили на полностью обновлённой Windows 11; переносить выводы на другие версии без отдельной проверки некорректно.
Где начинается проблема: Plug and Play как "загрузчик" стороннего кода
Когда к компьютеру подключают USB-устройство, Windows считывает его дескрипторы: идентификаторы производителя и продукта, класс устройства и другие параметры. На их основе система формирует аппаратные идентификаторы и подбирает соответствующий драйверный пакет: сначала в локальном хранилище, а если совпадений нет - обращается к Центру обновления Windows.
Если пакет разрешает автоматическую установку, Windows скачивает CAB-архив, помещает его в хранилище драйверов и запускает установочную последовательность. Ключевой момент: компоненты пакета (включая вспомогательные модули) выполняются от имени SYSTEM. В типичном сценарии это удобно - администратор не нужен, всё "подхватывается" само. Но ровно эта автоматизация превращается в поверхность атаки.
Дескрипторы при этом приходят от самого устройства, а Windows не проверяет их "подлинность" как факта: система просто доверяет тому, что заявлено на USB-стороне. Если атакующий управляет дескрипторами (через эмуляцию устройства), он фактически управляет тем, какие INF-пакеты будут искаться и устанавливаться.
Важно понимать: цифровая подпись подтверждает происхождение пакета и целостность поставки, но не гарантирует, что каждый соустановщик, служба или конкретный параметр реестра внутри пакета безопасен с точки зрения логики и архитектуры. Подписанное - не означает "невозможное для злоупотребления".
Соустановщики: легитимный компонент с привилегиями SYSTEM
В составе некоторых драйверов присутствует co-installer (соустановщик) - DLL или исполняемый файл, который выполняет дополнительные действия во время установки: копирует файлы, создаёт службы, меняет настройки, пишет в реестр. В контексте PnP такой соустановщик запускается с системными привилегиями. Если в нём есть логическая ошибка, её последствия автоматически становятся "ошибкой уровня SYSTEM".
Физическая цепочка: от эмуляции USB до SYSTEM за считанные минуты
В показанном сценарии атакующему достаточно "предъявить" системе эмулированное USB-устройство - без кликов и даже до входа пользователя в систему. В демонстрации целевая сторона - чистая, полностью обновлённая Windows 11 без предустановленного ПО. Со стороны атакующего - Linux-машина и плата FaceDancer, которая умеет эмулировать USB-девайсы. Полный путь от чистой ОС до оболочки SYSTEM, по словам исследователей, укладывался примерно в пять минут.
Цепочка начиналась с эмуляции устройства Sierra Wireless. При установке соответствующего пакета появлялась служба SwiService.exe, работающая как SYSTEM. Она открывала именованный канал с правами чтения и записи для группы "Все", из-за чего любой локальный или доменный пользователь мог вызвать функцию SetDNS - в том числе удалённо по сети через SMB. Это позволяло перенастроить DNS на подконтрольный сервер и подменять только нужные ответы, не ломая остальной трафик и не привлекая лишнего внимания.
Дальше эмулировалось устройство Sony FeliCa. Его co-installer felica_coinst.dll во время установки скачивал конфигурационные файлы по обычному HTTP и без проверки доверял полученному содержимому. Поскольку DNS уже был под контролем атакующего, ответы выдавались с нужного сервера.
Особенно критичной оказалась логика формирования имени локального файла: модуль выводил его из URL, "обрезая" строку до последнего прямого слэша, но не фильтруя точки и обратные слэши. Это открывало обход каталогов: файл с полностью контролируемым содержимым записывался от имени SYSTEM в произвольное место - в демонстрации его направляли прямо в System32.
Затем повторная эмуляция устройства Sierra приводила к загрузке подложенной библиотеки. Итог - выполнение кода с правами SYSTEM ещё до входа любого пользователя в систему. То есть речь не просто о повышении привилегий "после логина", а о возможности закрепиться на машине на максимально ранней стадии пользовательского сценария.
Удалённый вариант: та же логика, но без физического USB
Физическая атака упирается в необходимость что-то подключить к компьютеру. Но исследователи показали и удалённый путь, где реального устройства может не быть вовсе.
Ключевой механизм - перенаправление USB в сеансе RDP. Изначально оно предназначено для проброса подключённого к клиенту устройства в удалённый рабочий стол. Однако на серверной стороне узел Plug and Play строится из дескрипторов, которые присылает клиент. Иными словами, "на другом конце провода" не обязано существовать физическое устройство - достаточно корректно сформированных данных.
Для демонстрации авторы написали Python-клиент RDP поверх библиотеки aardwolf: без дополнительного оборудования он проходил аутентификацию обычным пользователем, открывал канал URBDRC и отправлял запросы, имитирующие подключение нужного USB-устройства. При определённых условиях это позволяло запустить ту же идею атаки по сети.
При этом подчёркивалось, что удалённый путь не обязательно "срабатывает из коробки" на дефолтных настройках: многое зависит от политики перенаправления устройств, конфигурации RDP и того, как в организации настроена установка драйверов и доступ к обновлениям.
Инструмент PNP simulate и "конструктор" из подписанных пакетов
Отдельного внимания заслуживает идея инструментальной проверки. Исследователи продемонстрировали подход с использованием инструмента PNP simulate, который помогает воспроизводить сценарии установки PnP без постоянного переподключения физических устройств и быстрее тестировать, какие пакеты подтянутся по тем или иным идентификаторам.
Показательно и то, что цепочки могут собираться из полностью подписанного ПО разных вендоров. В докладе упоминалась композиция, где элементы цепочки относились к экосистемам Wacom и Atheros. Это подчёркивает системную природу проблемы: опасность рождается не из "неподписанного драйвера", а из сочетания автоматической установки, системных привилегий и ошибок в логике сопутствующих компонентов.
Почему это важно: атака уходит в "легитимный шум"
Подобные сценарии неприятны тем, что внешне выглядят как нормальная работа Windows: система действительно скачивает драйверы, действительно ставит их через Windows Update и действительно запускает установочные части как SYSTEM. С точки зрения журналов и телеметрии это может маскироваться под стандартные операции администрирования и "обычный" жизненный цикл PnP.
А ещё это ломает привычное ожидание безопасности: "нужны права администратора, чтобы поставить драйвер". В показанном подходе администратор не требуется - достаточно инициировать установку драйвера через PnP и воспользоваться логической ошибкой внутри доверенного, подписанного пакета.
---
Что с этим делать: практические меры защиты (дополнение)
Ниже - меры, которые помогают сузить окно атаки. Они не отменяют необходимости исправлений у поставщиков, но позволяют уменьшить риск на стороне организации.
1) Пересмотрите автоматическую установку драйверов.
В корпоративной среде часто оправдано отключение или жёсткое ограничение подтягивания драйверов через Центр обновления, особенно на серверах и рабочих станциях с высокими привилегиями. Вместо "авто" - управляемый каталог одобренных драйверов.
2) Ограничьте классы устройств и идентификаторы.
Политики установки устройств (по классам, VID/PID и т. п.) позволяют запретить неожиданные USB-классы и разрешить только нужное. Это снижает вероятность того, что система сама подберёт экзотический пакет с неожиданным соустановщиком.
3) Жёстко настройте RDP: перенаправление устройств - не всем и не всегда.
Если USB redirection в удалённом рабочем столе не критичен, его лучше отключить. Если критичен - разрешать точечно, только доверенным группам и только для строго определённых типов устройств.
4) Следите за появлением новых служб и странных прав на IPC-объекты.
Служба, работающая как SYSTEM, которая создаёт именованные каналы/сокеты/объекты синхронизации с доступом "для всех", - типичный маркер опасной архитектуры. Регулярный аудит DACL на IPC-объектах и новых сервисах помогает выявлять такие ошибки раньше злоумышленника.
5) Укрепляйте контроль исполнения (allow-list подход).
Политики контроля приложений (разрешительный список) снижают ценность записи в System32 и подмены DLL, потому что выполнение/загрузка "неразрешённых" бинарей блокируется даже при удачной записи файла.
6) Минимизируйте поверхность USB на критичных машинах.
На рабочих местах администраторов, на jump-host и на серверах разумно ограничивать USB на уровне политик, вплоть до запрета неизвестных устройств. Чем меньше неожиданных PnP-событий - тем меньше шансов "случайно" подтянуть рискованный пакет.
7) Разделяйте привилегии и не используйте одну станцию для всего.
Если рабочая станция одновременно используется для веб-сёрфинга, почты, RDP и администрирования - любая цепочка повышения привилегий становится опаснее. Разделение ролей и изоляция админ-среды резко снижают потенциальный ущерб.
8) Контролируйте сетевые условия, которые помогают цепочке.
В показанной атаке важную роль играла возможность влиять на DNS и подменять ответы точечно. Защита DNS-настроек, мониторинг их изменений, ограничение SMB-доступа к чувствительным сервисам и контроль исходящего трафика уменьшают пространство для подобных трюков.
Итог
Исследование на DEF CON 34 наглядно показало: в Windows 11 сама логика Plug and Play и автоустановки драйверов может быть превращена в путь к SYSTEM, если внутри подписанных пакетов есть небезопасные решения - от чрезмерных прав на IPC до небезопасной загрузки конфигураций и ошибок в обработке путей. Проблема неприятна тем, что цепочка опирается на штатные механизмы ОС и легитимные обновления, а значит - требует не только патчей у вендоров, но и более строгих политик установки устройств, обновлений и перенаправления USB в RDP на стороне администраторов.
