EvilPrinter – Новый Вектор Принудительной NTLM-Аутентификации через Протоколы Печати Windows

Исследовательский центр Compliance Control обнаружил и проанализировал новый механизм Authentication Coercion в
Windows-окружениях.

Это исследование раскрывает новый и критический вектор принудительной NTLM-аутентификации, получивший название «EvilPrinter». Атака злоупотребляет поведением клиента WinHTTP (Windows HTTP Services) и настройки политики аутентификации по умолчанию, используемой компонентами службы Print Spooler при взаимодействии с IPP-принтерами и службами сетевого обнаружения (WSD/mDNS), что позволяет использовать службу обнаружения и установки сетевых IPP принтеров для Authentication Coercion.

Ключевое обнаружение заключается в том, что этот механизм игнорирует настройки безопасности, предназначенные для ограничения NTLM-аутентификации ресурсами внутренней сети (Intranet), что приводит к утечке NTLMv2-хэша Машинной Учетной Записи ($) на произвольный IP-адрес в сети Интернет.

1. Введение

Несмотря на политику Microsoft по отказу от использования NTLM-аутентификации в доменной среде, атаки, связанные с получением NTLM-хэша, по-прежнему остаются одной из наиболее критических угроз для корпоративных сетей, поскольку NTLM часто является fallback-механизмом в большинстве систем.

Особенный интерес исследователей вызывает возможность ретрансляции (relay) NTLM-хэша на внутренние сервисы, что потенциально позволяет выполнить атаку на LDAP, Центры Сертификации (AD CS), HTTP и MS SQL сервисы. При атаке типа NTLM Relay первая задача, которую необходимо решить, – найти рабочий способ принуждения к аутентификации (Authentication Coercion). Традиционно для этого используются различные coerce-методы, эксплуатирующие уязвимости (PetitPotam) или специфические RPC-вызовы сетевых протоколов (EFS-RPC, MS-RPRN) для принуждения сервера к обращению с прохождением аутентификации.

Полученный NTLM-хэш затем ретранслируется на внутренние сервисы (LDAP, MSSQL, SMB/RPC) для компрометации.

Принципиальная схема атаки, обычно, выглядит так:

Рис. 1. Упрощенная схема атаки NTLM-relay

Данное исследование иллюстрирует еще один метод инициации аутентификации по протоколу HTTP от имени Машинной Учетной Записи ($) через IPP (Internet Printing Protocol) с использованием стандартного стека Windows (WinHTTP). Это отличает его от атак, требующих сложных RPC-вызовов или специфических уязвимостей, поскольку метод злоупотребляет (Feature Abuse) штатной функциональностью клиента WinHTTP/WSD при обработке запросов на аутентификацию (HTTP 401/407). Мы рассмотрим общий принцип работы триггера, а также продемонстрируем три возможных сценария атаки.

2. Описание протокола Internet Printing Protocol (IPP)

Протокол IPP – это современный стандарт для связи между принтером и печатающим клиентом. В Windows для поддержки этого протокола используется встроенный драйвер «Microsoft IPP Class Driver». Это универсальный драйвер, который может взаимодействовать по IPP с любым Mopria-сертифицированным принтером.

Рис. 2. Производители сертифицированные Mopria

В общем случае, процесс установки принтера через IPP Directed Discovery включает следующие шаги в настройках Windows:

1. Переход в раздел «Bluetooth & devices» > «Printers & Scanners».
2. Выбор «Add device» > «Add new device manually» > «Add a printer using an IP address or hostname».
3. Для параметра «Device type» выбирается «IPP Device».
4. Для «Hostname or IP address» вводится IP-адрес принтера.

Если принтер использует нестандартный URL IPP, необходимо ввести полный IPP URL вместо простого IP-адреса, например, ipp://192.160.1.110:631/ipp/print или ipps://192.160.1.110:443/ipp/print.

Примечание: Наши тесты показывают, что именно протокол IPP в реализации WinHTTP/WSD является вектором Coercion. Использование других опций установки принтера, таких как Autodetect, TCP/IP Device или Web Services Device, не приводит к принудительной NTLM-аутентификации от имени Машинной Учетной Записи.

IPP как современный протокол печати использует стандартные сетевые и веб-сервисы, которые в среде Windows часто реализуются через WinHTTP и WSDAPI (Microsoft Web Services on Devices API). WSDAPI поддерживает реализацию устройств и служб, соответствующих Devices Profile for Web Services (DPWS).

Нас интересует, как реализован процесс аутентификации:

Windows WSD-клиент получает метаданные по HTTP, используя WinHTTP. Если требуется аутентификация (например, при получении статуса HTTP 401 или 407), WinHTTP поддерживает автоматическую повторную попытку авторизации и может обрабатывать схемы Challenge-Response, такие как Negotiate, NTLM или Kerberos. Фактическая «автоматическая попытка авторизации» реализуется на уровне стека WinHTTP/HTTP.

При этом для WinHTTP поведение при аутентификации определяется параметром политики автоматического входа, и для Inranet зоны по умолчанию установлен WINHTTP_AUTOLOGON_SECURITY_LEVEL_MEDIUM. Этот параметр позволяет использовать учетные данные по умолчанию при запросах по внутренней сети.

Техническое Примечание: Механизм Автологина WinHTTP Автоматическое использование учетных данных (Autologon) при запросах по внутренней сети является поведением, закодированным в приложении, использующем стек WinHTTP. Уровень безопасности аутентификации устанавливается функцией WinHttpSetOption с флагом WINHTTP_OPTION_AUTOLOGON_POLICY.

В нашем случае, компонент службы Print Spooler (или WSDAPI), инициирующий IPP-запрос, использует уровень безопасности по умолчанию: WINHTTP_AUTOLOGON_SECURITY_LEVEL_MEDIUM. Этот уровень программно разрешает автоматическую передачу учетных данных по умолчанию (включая Машинную Учетную Запись) для ресурсов, которые операционная система считает «Интранетом».

Важно: Поскольку это поведение задано на уровне кода компонента Windows, оно не регулируется общими настройками зон безопасности, заданными в GUI Windows (Internet Properties), и не может быть легко изменено администратором с помощью стандартных GPO или реестра, напрямую не связанных с WinHTTP. (https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/WinHttp/authentication-in-winhttp.md)

Таким образом, проблема заключается в дефолтном поведении системной службы, а не в ее неправильной настройке администратором. Единственный надежный способ защиты от этой атаки – это внешние контроли на целевых сервисах (например, LDAP Signing/Channel Binding).

Несмотря на то, что закодированный уровень WINHTTP_AUTOLOGON_SECURITY_LEVEL_MEDIUM должен ограничивать автоматическую аутентификацию только ресурсами «Интранета», наши тесты показали, что NTLMv2-хэш машинной учетной записи успешно передается на внешний хост с публичным IP-адресом (в сети Интернет). Это указывает на недокументированное поведение или ошибку логики в компоненте Print Spooler/WSDAPI, который либо некорректно определяет зону безопасности при IPP-запросе, либо игнорирует ограничение «Интранет». Это критически увеличивает риск. Реализовать сценарий атаки с использованием внешнего адреса удалось не только в лабораторной среде, но и в реальном проекте тестирования на проникновение.

IPP является протоколом прикладного уровня для печати, который в средах Windows интегрирован через системный драйвер (Microsoft IPP Class Driver) и использует механизмы WinHTTP/WSDAPI для обеспечения коммуникации по сети, основанной на стандартах веб-сервисов (DPWS) и HTTPS/TLS.

Типичный диалог IPP клиент  IPP сервер выглядит так:

Рис. 3. Запросы при подключении нового IPP устройства

Рис. 4. Запросы при подключении нового IPP устройства

Как мы видим, при подключении к IPP устройству, клиент Windows запрашивает описание устройства – выполняет POST запрос к каталогу /ipp/print. Наш тестовый IPP-принтер настроен на свободный доступ и по умолчанию отправляет техническую информацию о себе.

Но что будет, если наше устройство не будет отдавать информацию всем подряд, а будет настроено на подключение только после аутентификации?

Запустим на хостеVictim под управлением Windows 11 простой HTTP-сервер, который будет прослушивать TCP-порт 631 и запрашивать аутентификацию при входящих обращениях.

Если мы попробуем установить IPP-принтер по адресу localhost, то получим такой диалог:

Рис. 5. IPP устройство требует аутентификацию для получения атрибутов

Как мы видим, если наш сервер в ответ на POST запрос к каталогу /ipp/printer возвращает ответ HTTP/1.1 401 Unauthorized, то клиент (наш Windows 11) начинает проходить NTLM-аутентификацию от имени служебной учетной записи NT AUTHORITY\NETWORK SERVICE.

Безусловно, служба NT AUTHORITY\NETWORK SERVICE обладает ограниченными правами на локальном хосте. Однако при обращении к сетевым ресурсам эта служба использует Машинную Учетную Запись хоста.

Если мы обратимся к нашему тестовому HTTP-сервису с другого хоста (redpc), мы увидим, что при аутентификации уже используется Машинная Учетная Запись REDPC$:

Рис. 6. Аутентификация от машинной УЗ при обращении к другому устройству в сети

Таким образом, мы делаем вывод, что, имея возможность запустить процесс установки нового IPP-принтера (а это по дефолту может сделать любой непривилегированный пользователь), – мы получаем возможность получить HTTP-аутентификацию от имени Машинной Учетной Записи хоста, на котором мы запускаем процесс.

Это открывает возможность использования процесса поиска IPP-принтера в качестве «coerce»-триггера при атаках типа NTLM Relay.

В ходе отработки вариантов эксплуатации удалось реализовать четыре сценария атаки:

• Сценарий 1 – Локальное повышение привилегий
• Сценарий 2 – Удаленное повышение привилегий
• Сценарий 3 – Удаленное повышение привилегий, без доступа к атакуемому хосту (частный случай Сценария 2)
• Сценарий 4 – Удаленное повышение привилегий, с утечкой NTLM-хэша Машинной Учетной Записи на внешний хост (Internet)

3. Описание Стенда

• Victim Host: 192.168.83.187, имя хоста win11Canary, Windows 11 Pro Insider Preview Build 10.0.27924.1000.
• AD Domain: hydra.local
• Domain Administrator: hydra\drevil
• Domain Controller (DC) / LDAP Server: 192.168.83.200 — LDAP Channel Binding и signing policies отключены.
• Non-Privileged User: attacker (локальная не привилегированная учетная запись)
• Attacker Host: 192.168.83.178, Kali Linux
• IPP Printer (эмуляция): 192.168.83.149, Kali Linux + ippsample (https://github.com/istopwg/ippsample)

3.1. Сценарий 1: Локальное повышение привилегий (LPE)

Рис. 7. Схема атаки

Non-Privileged User имеет доступ к Victim Host под учётной записью обычного пользователя. Для получения привилегий локального администратора на Victim Host мы можем использовать атаку Shadow Credentials.

В рамках атаки с помощью NTLM Relay от имени Машинной Учётной Записи выполняется обращение к LDAP и модификация атрибута msDS-KeyCredentialLink машинного аккаунта. После этого злоумышленник использует свой приватный ключ для получения Kerberos-билетов через PKINIT, фактически аутентифицируясь от имени жертвы и получая TGS на имя доменного администратора для последующей аутентификации на Victim Host.

Для выполнения атаки используем сборку под Windows утилиты ntlmrelayx. (https://github.com/LuemmelSec/ntlmrelayx.py_to_exe/releases)

1. Запуск ntlmrelayx: Запустим утилиту со следующими параметрами (—http-port 631 — указываем на каком порту ловим обращения IPP протокола):

ntlmrelayx_new.exe -t ldap://192.168.83.200 --no-smb --http-port 631 --shadow-credentials

2. Инициация обращения: Для инициации обращения используем панель управления для добавления нового принтера по протоколу IPP:

• Переход в раздел «Bluetooth & devices» > «Printers & Scanners».
• Выбор «Add device» > «Add new device manually» > «Add a printer using an IP address or hostname».
• Для параметра «Device type» выбирается «IPP Device».
• Для «Hostname or IP address» вводится IP-адрес принтера (адрес Attacker Host). В нашем случае это localhost

Рис. 8. Получение pfx файла для Victim Host

В результате атаки мы получаем файл n7lcwmcs.pfx, который можно использовать для получения TGS билета. Дальнейшие действия стандартны и широко описаны, поэтому приведем краткое описание:

1. Получение Kerberos TGT для хоста hydra.local\win11Canary:

Rubeus.exe asktgt /user:win11Canary$ /certificate:n7lcwmcs.pfx /password: Fr2Ds9Z0jx6IGHXrH6eu /domain:hydra.local /nowrap

2. Получение TGS для администратора домена drevil для SPN host/win11Canary.hydra.local

Rubeus.exe s4u /self /nowrap /user:win11Canary$ /impersonateuser:drevil /altservice:HOST/win11Canary.hydra.local /ptt /ticket::<base64_ticket>

3. Импортируем TGS билет в память:

Rubeus.exe ptt /ticket:<base64_ticket>

4. Подключаемся к хосту win11Canary под учетной записью доменного администратора (его TGS необходимый для подключения мы импортировали на шаге 3 и добавляем учетную запись локального пользователя ‘attacker’ в группу локальных администраторов:

Enter-PSSession -ComputerName win11Canary.hydra.local
net localgroup Administrators attacker /add

В итоге мы реализовали цепочку LPE: Non-Privileged User -> IPP coerce -> ntlmrelayx -> LDAP -> Shadow Credentials attack -> Get TGT Victim Host -> GET TGS от domain admin для SPN host -> TGS import -> Enter-PSSession -> подключение к cmd от имени domain admin с привилегиями локального администратора на Victim Host

Дальнейшие сценарии описывают возможные варианты с использованием в цепочке атаки еще одного подконтрольного хоста Attacker Host, например, под управлением ОС Kali Linux. Применение такого хоста позволит избежать использования утилит ntlmrelayx и Rubeus на VictimHost и избавит от необходимости решения задачи обхода хостовых AV-средств.

3.2. Сценарий 2: Удаленное повышение привилегий

В этом случае Атакующий скомпрометировал учетную запись доменного пользователя с правом доступа по RDP на VictimHost.

Рис. 9. Схема атаки

Мы запускаем подключение к IPP-принтеру и в качестве IP-адреса указываем адрес нашего Attacker Host. На Attacker Host запускаем ntlmrelayx:

python3 ./ntlmrelayx.py -t ldap://192.168.83.200 --http-port 631 --shadow-credentials --shadow-target 'win11Canary$'

В результате также получаем файл pfx для Victim Host

Рис. 10. Получение файла PFX для Victim Host

Дальнейшие действия аналогичны описанным в Сценарии 1 с поправкой на инструментарий Kali Linux.

3.3. Сценарий 3: Атакующий не имеет доступа к Victim Host, но находится в том же сетевом сегменте

Прежде чем описывать схему атаки, предлагаю посмотреть, что происходит, когда при установки принтера мы доходим до этапа «Add device».

После того как мы выбираем «Add device», хост начинает искать доступные сетевые устройства печати.

Рис. 11. Поиск IPP устройств при добавлении нового устройства

Нас интересует, что для поиска устройств IPP в сети хост рассылает mDNS запросы с указанием нужного PTR _ipp._tcp.local. Если такое устройство в сети есть, оно ответит информацией о своем IP-адресе.

И если это устройство не установлено в системе, то ОС Windows запросит информацию об устройстве (IPP Get-Printer-Attributs).

Рис. 12. Запрос конфигурации нового IPP устройства

На нашем примере в сети есть IPP принтер, который отвечает на запрос и отправляет информацию о своих параметрах:

Рис. 13. Запрос конфигурации нового IPP устройства

Но если устройство попросит авторизацию, клиент выполнит аутентификацию. Этот механизм позволяет автоматически инициировать атаку, исключая необходимость ручного ввода IP-адреса (при условии размещения Attacker Host и VictimHost в одном сетевом сегменте)

Таким образом, если пользователь хочет добавить новое сетевое устройство, хост выполняет поиск доступных устройств и инициирует HTTP-запрос к анонсированному WSD устройству для получение метаданных. Если устройство вернет код 401 — запустится процесс аутентификации

Осталось только научить объявлять наш Attacker Host в сети как IPP-принтер.

Для этого была создана утилита evilPrinter которая отправляет mDNS анонсы и отвечает за запросы PTR _ipp._tcp.local нужным нам IP адресом (доступна на https://github.com/dram-beep/evilPrinter).

Рис. 14. Отправка mDNS анонса с IP адресом атакующего

После запустим ntlmrelayx. В нашем сценарии после некоего времени ожидания, пользователь решил установить новый сетевой принтер, выбрал пункт «Add device».

На скриншоте видно, как VictimHostзапустил широковещательные mDNS-запросы в поиске ipp-устройств. На эти запросы ответил легальный принтер «My IPP Printer» (который уже настроен наVictimHost) и наш evilPrinter «Virtual IPP Printer», который сообщил, что работает на 631 порту. Та как в системе нет информации об устройстве «Virtual IPP Printer» —VictimHostотправил запрос на получение описания устройства. На Attacker Host на этом порту ждет обращений ntlmrelayx, который и начал NTLM Challenge при обращении VictimHost.

Рис. 15. Прохождение NTLM аутентификации на IPP устройстве

Результат успешной атаки ntlmrelay

Рис. 16. Получение pfx файла Victin Host

3.4. Сценарий 4: Атакующий не имеет доступа к Victim Host и находится во внешней сети

Если мы при установки нового IPP принтера обратимся к внешнему IP адресу (из сети Internet) — мы так же сможем получить NTLM-хеш Машинной Учетной Записи

Рис. 17. Утечка NTLM-хеша машинной учетной записи за пределы периметра

Это уже выглядит достаточно интересным, но есть ли возможность реализовать этот сценарий без прямого доступа к VictimHost?

Такой вариант атаки технически реализуем, если атакующий вынудит пользователя запустить эту утилиту evilPrinter (из сценария 3) на своем хосте. Это может быть результатом фишинговой атаки или, используя методы социальной инженерии, атакующий убедит пользователя запустить нужный файл на хосте в корпоративной сети.

Для демонстрации концепции атаки, мы запустили на VictimHostутилитуevilPrinter.exe, которая отвечает на mDNS запросы PTR _ipp._tcp.local ответами, содержавшими в A-записи IP адрес хоста в сети Internet.

После того как пользователь запустит процесс установки принтера и нажмет на кнопку «Add device», VictimHostначнет процесс поиска устройств в локальной сети иполучит информацию о наличии IPP принтера по IP адресу в Internet, после чего обратится к этому ресурсу по прежнему алгоритму установки IPP принтера. В результате атакующий получит обращение содержащие NTLM-хеш Машинной Учетной Записи VictimHost.

Рис. 18. Утечка NTLM-хеша на хост в Internet

Как показала практика, при наличии сетевого доступа с хоста атакующего во внутреннюю сеть, становятся возможными сценарии NTLM-relay атак на внутренние ресурсы.

Итоговая цепочка атаки в этом случае будет выглядеть так:

Coerce (IPP) -> Эксфильтрация (InternetIP) -> Релей (например SSHReverseProxy + proxychain) -> Компрометация (LDAP/ShadowCredentials)

4. Итоги

Описанные методы атаки были проверены и на реальных проектах при проведении тестирования на проникновение внутренней инфраструктуры наших заказчиков.

Сценарий 1 был разработан и реализован при тестировании по модели нарушителя «нелояльный сотрудник». Терминальный хост, к которому у нас был доступ под стандартной учетной записью, был защищен антивирусом, который удалось обойти после соответствующей адаптации инструментов. После использования цепочки IPP coerce -> ntlmrelay -> ldap -> pxf был атакован Центр Сертификации с уязвимыми шаблонами, и в результате удалось получить привилегии администратора домена.

Сценарий 2 был реализован после компрометации непривилегированного доменного пользователя. Из-за ограничений в безопасности, провести атаку Shadow Credentials не удалось, но мы использовали ntlmrelayx с опцией —socks. В результате удалось получить прокси-соединение к LDAP-серверу, и, используя proxychain-подключение, выполнили атаку RBCD и получили TGS билет доменного администратора для доступа к атакуемому терминальному серверу.

Сценарий 4 был реализован при тестировании по модели нарушителя «нелояльный сотрудник». На выделенной типовой рабочей станции был открыт доступ в интернет. Мы использовали reverse ssh прокси для получения сетевого доступа с нашей станции Kali (за переделами периметра) во внутреннюю сеть. Используя сценарий установки IPP принтера мы отправили NTLM-хеш Машинной Учетной Записи на Internet IP адрес нашей Кали. Используя связку proxychain + ntlmrelayx мы успешно ретранслировали машинную учетную запись на внутренний LDAP сервер и выполнили атаку Shadow Credentials. В результате удалось получить привилегии локального администратора на рабочей станции и в ходе дальнейшего исследования сети успешно получить привилегии администратора домена.

Практический опыт применения сценария EvilPrinter говорит о жизнеспособности этой атаки. Несмотря на рекомендации Microsoft по защите от NTLM Relay-атак, на практике IT-службы часто пренебрегают рекомендациями, и возможности для атаки в реальной инфраструктуре можно найти.

Информация об описанном способе получения обращения Машинной Учетной Записи была отправлена в Microsoft, и был получен официальный ответ, что этот механизм не считается уязвимостью. Microsoft указала, что рекомендации по безопасной настройке LDAP (например, LDAP Channel Binding и LDAP Signing) и применению антивирусных средств достаточны для предотвращения описанных сценариев атак.

5. Защита & Детект

Ниже — набор мер, которые уменьшают риск сценариев класса authentication coercion → принудительная NTLM-аутентификация (в т.ч. от имени компьютерной учётной записи) → relay в AD/LDAP и развитие атаки.

1. Сократите использование NTLM
   Там, где возможно, переводите сервисы на Kerberos и поэтапно ужесточайте политику NTLM (сначала аудит, затем ограничение, затем запрет на критичных узлах).
2. Включите LDAP signing и LDAP channel binding на контроллерах домена
   Это базовая мера против relay-атак на LDAP/LDAPS и один из самых эффективных способов “сломать” цепочку после принуждённой аутентификации.
3. Ужесточите SMB signing
   Включайте подпись SMB и по возможности требуйте её на серверах. Это снижает число направлений, куда можно “приземлить” принудительную аутентификацию.
4. Ограничьте исходящие подключения (egress filtering)
   Coercion-атаки часто упираются в то, что хост-жертва должен подключиться к ресурсу атакующего. Ограничьте исходящий HTTP/SMB/прочие протоколы из серверных сегментов и рабочих станций до необходимого минимума.
5. Сведите поверхность печати/IPP к необходимой
   Если печать не нужна на сервере/узле — отключайте связанные компоненты и службы. Где печать нужна — ограничьте доступ к печатным сервисам сетевыми ACL/Firewall (только от доверенных подсетей/хостов).
6. Проверьте и зачистите делегирование прав в AD
   Убедитесь, что у “лишних” групп/аккаунтов нет прав на изменение чувствительных атрибутов объектов, особенно тех, которые могут быть использованы для закрепления и обхода аутентификации.
7. Контролируйте изменения msDS-KeyCredentialLink (shadow credentials)
   Включите аудит изменений объектов Directory Service и алертите любые записи/изменения msDS-KeyCredentialLink, особенно для компьютерных объектов, серверов и привилегированных учётных записей.
8. Включите аудит NTLM и мониторьте “неожиданную” NTLM-аутентификацию
   Собирайте события аудита NTLM и отслеживайте: рост доли NTLM, появление NTLM на критичных серверах, новые направления аутентификации между сегментами, нетипичные источники/получатели.
9. Мониторьте сетевые аномалии вокруг HTTP/WinHTTP и печати
   SOC/NetOps стоит обращать внимание на неожиданные HTTP(S)-подключения от серверов/рабочих станций к нетипичным внутренним адресам, особенно если после этого наблюдается активность в сторону доменных сервисов.
10. Усильте контроль привилегий и изоляцию критичных ролей
    Разделяйте роли администрирования, минимизируйте интерактивные входы на DC и другие критичные системы, используйте отдельные административные рабочие места (PAW/SAW) и сегментацию. Это снижает “ценность” успешного relay и упрощает локализацию инцидента.

Эти меры не требуют “волшебных” продуктов и хорошо работают в комплексе: снижают вероятность принуждённой аутентификации, уменьшают число путей для relay, и дают SOC достаточные сигналы для раннего обнаружения.