SMB Signing и Protected Users: закрываем вектор NTLM relay после волны атак

Последние несколько недель в профессиональных чатах и конференциях активно обсуждают NTLM relay и pass-the-hash - не как теоретические упражнения из учебников, а как вектор, которым реально пользуются. Инструменты вроде Responder и ntlmrelayx делают атаку доступной людям без глубокой экспертизы: поймал NTLM-challenge в локальной сети, прокинул на другую машину - готово. Нас это натолкнуло на вопрос: а у текущих заказчиков с этим как?

Провели небольшой аудит на одном из проектов - средний бизнес, Active Directory, несколько сотен рабочих станций, смешанный парк Windows 7 и Windows 10. Картина оказалась типичной настолько, что стало слегка грустно.

Что обнаружили

Проверили настройки SMB Signing через групповые политики и непосредственно с машин через скрипт. Результат: подписывание SMB-трафика обязательно только на контроллерах домена - там это включено по умолчанию ещё с незапамятных времён. На рабочих станциях параметр Microsoft network client: Digitally sign communications (always) установлен в Not Defined или явно в Disabled. Примерно у 60% машин SMB Signing не просто не обязателен - он не включён вообще.

Для атакующего это означает: если удалось захватить NTLM-аутентификацию (через Responder, через вредоносный UNC-путь в документе, через любой другой вектор получения challenge/response), её можно прокинуть на другую машину без контроллера домена в цепочке. SMB Signing разрывает эту механику: подписанный пакет нельзя переиспользовать для аутентификации на чужой машине, потому что подпись привязана к конкретной сессии.

Параллельно проверили группу Protected Users - она появилась ещё в Windows Server 2012 R2 и призвана ограничить набор разрешённых механизмов аутентификации для членов группы. Для учёток в Protected Users NTLM-аутентификация отключается полностью, Kerberos-делегирование ограничено, кэшированные credentials не сохраняются на рабочих станциях. В группе не было ни одной учётной записи - ни сервисных, ни административных.

Что сделали

Работу разбили на два направления.

Первое - SMB Signing через GPO. Создали отдельную политику и применили на все рабочие станции через OU. Два параметра в Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options:

• Microsoft network client: Digitally sign communications (always) - включить
• Microsoft network server: Digitally sign communications (always) - включить

Включили в режиме Enabled, не If client agrees - именно обязательное подписывание, а не опциональное. Опциональный режим от relay не защищает: атакующий просто подключается без подписания, и сервер соглашается.

Перед раскаткой проверили, нет ли в инфраструктуре старого железа или специфического ПО, которое SMB Signing не потянет. На практике это актуально для совсем древних принтеров и встроенного ПО сканеров - они иногда используют SMB для отправки скана на папку и с обязательным подписанием ломаются. Нашли три сетевых МФУ, их обработали отдельно: для соответствующих серверов-назначений создали исключающую политику. Остальная инфраструктура справилась без сюрпризов.

Второе - Protected Users для критичных учёток. Определили список: члены Domain Admins, Enterprise Admins, несколько сервисных учёток с повышенными правами на файловых серверах. Перед добавлением в группу проверили, нет ли среди кандидатов учёток, которые используют NTLM-аутентификацию для интеграций - некоторые старые приложения и мониторинг ходят через NTLM, и для них переезд в Protected Users сломает аутентификацию. Нашли два таких случая - они остались за бортом группы с пометкой на ревью.

Добавление прошло без инцидентов. Тихо и незаметно для пользователей - членов группы там не было, оперативного доступа к машинам с сохранёнными credentials эти учётки не давали.

Как проверили результат

Проверили через Responder в тестовом режиме - запустили с флагом --analyze (без перехвата, только детектирование) внутри сегмента. До изменений Responder видел NTLM-трафик и фиксировал потенциальные жертвы. После включения обязательного SMB Signing захваченные challenge/response стали непригодны для relay: попытка прокинуть их на другую машину возвращает ошибку подписи.

Для учёток в Protected Users проверили попытку NTLM-аутентификации через тестовый стенд - получили ожидаемый отказ с кодом ошибки, указывающим на принудительный Kerberos.

Что это даёт и что не даёт

SMB Signing закрывает relay, но не закрывает сам захват учётных данных. Если атакующий получил NTLM-hash, он может пытаться его взломать офлайн - подписывание тут не поможет. Это отдельная история про сложность паролей и политику их ротации.

Protected Users убирает NTLM-аутентификацию для привилегированных учёток, что существенно сужает поверхность pass-the-hash атак. Но требует внимательной инвентаризации: добавить не ту учётку - получить неработающую интеграцию в неудобный момент.

В целом получился не радикальный разворот в архитектуре, а точечная работа с конкретным вектором. Для аудита - нормальный результат: нашли, оценили, закрыли без реорганизации всего AD.

Следующим шагом смотрим на Credential Guard для машин на Windows 10 - он защищает от извлечения учётных данных из памяти lsass, что дополняет уже сделанное. Но это уже отдельный разговор: там есть свои ограничения на совместимость с виртуализацией.