PrintNightmare: останавливаем Print Spooler на контроллерах домена

В конце мая в публичном пространстве начали появляться детали уязвимости в Windows Print Spooler, которую исследователи назвали PrintNightmare. CVE-2021-1675 - это повышение привилегий и удалённое выполнение кода через сервис печати Windows. То, что сначала описывалось как локальная привилегия, оказалось значительно серьёзнее: при определённых условиях атакующий с минимальными правами в домене может получить SYSTEM на контроллере домена. Патча пока нет.

Мы начали получать сигналы об активной эксплуатации - не из публичных отчётов, а от партнёров и через профессиональные каналы. Реакция одна: надо смотреть клиентов.

Почему это серьёзно

Print Spooler - сервис, который работает практически на каждом Windows-хосте по умолчанию. Включая контроллеры домена. Уязвимость позволяет атакующему загрузить произвольную DLL через механизм установки принтера: Windows доверяет этому механизму, потому что добавлять принтеры - это нормальное пользовательское действие. Только здесь пользователь добавляет не принтер, а шеллкод.

Контроллер домена с уязвимым Print Spooler - это потенциально скомпрометированный домен. Атакующий с учёткой любого пользователя домена может попробовать escalate до Domain Admin. Для большинства сред Active Directory это означает полный захват инфраструктуры.

Ещё один неприятный момент: Print Spooler слушает и на RPC-портах, и его можно достичь по сети. Это не только локальный вектор.

Что мы делаем прямо сейчас

Первый шаг - инвентаризация. Смотрим, где запущен Print Spooler, и начинаем с критичных мест:

• Контроллеры домена - приоритет первый. Принтер на DC никому не нужен. Если кто-то распечатывает на DC - это отдельная проблема, которую тоже надо решать.
• Серверы управления - jump-серверы, сервера управления бэкапами, всё, что имеет привилегированный доступ к инфраструктуре.
• Рядовые серверы - в порядке убывания критичности.

На контроллерах домена у клиентов, где есть оперативный контакт с командой, - останавливаем Spooler немедленно. Не после следующего окна обслуживания, а сейчас.

Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

Через GPO это выглядит так: Computer Configuration - Windows Settings - Security Settings - System Services - Print Spooler - Startup: Disabled.

Что ломается

Честный ответ: печать с этого хоста ломается полностью. Если на DC кто-то каким-то образом завязал печать - это выплывет. По нашему опыту, у большинства клиентов Print Spooler на DC никто не трогал годами, он просто работал в фоне, потому что такой дефолт. Останавливать его безопасно с точки зрения функциональности домена.

На рабочих станциях и серверах, где реально нужна печать, - отключать сразу нельзя. Там пока mitigation другой: ограничить доступ к функциям установки принтеров через политики, отключить входящие удалённые вызовы RPC к Spooler. Это снижает поверхность атаки, но не убирает её полностью.

Microsoft выпустил предварительные рекомендации: ограничить возможность установки принтеров через Group Policy - «Point and Print Restrictions». Конкретнее: запрет пользователям устанавливать принтеры без прав администратора, плюс ограничение доверенных серверов.

Как это выглядит на практике

Мы прошлись по нескольким клиентам с аудитом инфраструктуры в рамках регулярного обслуживания. Везде одна картина: DC работают, Print Spooler запущен, никто не задумывался. После короткого разговора с ответственным - останавливаем, отключаем автозапуск, фиксируем в журнале изменений.

Один клиент сразу спросил: «А как мы узнаем, что нас уже атаковали?» Хороший вопрос. Следы эксплуатации через Spooler можно искать в логах Windows - Event ID 316 и 808 в Microsoft-Windows-PrintService/Admin, плюс подозрительные DLL-файлы в %SystemRoot%\System32\spool\drivers. Если кто-то уже воспользовался уязвимостью - следы скорее всего есть, надо смотреть.

Что дальше

Патча от Microsoft нет. Ждём - но не пассивно. Mitigation через GPO и остановка Spooler на критичных хостах - это то, что можно сделать сегодня. Когда патч выйдет, накатим дополнительно.

История с PrintNightmare напоминает ProxyLogon из февраля - уязвимость в компоненте, который везде включён по умолчанию и никто не задумывался об его необходимости. С Exchange тогда была похожая история: сервис работает, потому что установлен, а не потому что нужен именно здесь. Отключение ненужных сервисов на критичных серверах - это не паранойя, это базовая гигиена, которую эти инциденты хорошо иллюстрируют.