NTLM-аутентификация — это семейство протоколов проверки подлинности в Windows, основанное на схеме «вызов-ответ» без передачи открытого пароля, применяемое для входа в локальные учетные записи и в доменные сервисы, когда Kerberos недоступен. 🔐 NTLM поддерживает взаимную защиту канала и подпись сообщений, но считается устаревшим из-за известных рисков (relay, pass-the-hash, downgrade). Рекомендуется по возможности заменять NTLM на Kerberos или современные протоколы с TLS.
NTLM (NT LAN Manager) — исторически основной механизм аутентификации в семействах Windows NT/2000/XP/Server, который все еще встречается в современных средах для совместимости: в рабочих группах, при доступе к SMB-шарам, печати, DCOM, WinRM/HTTP-проксировании, а также как резервный вариант в домене Active Directory, если Kerberos недоступен. 🧩 Через SSPI/Negotiate NTLM может автоматически выбираться клиентом без участия пользователя, что объясняет его устойчивую «живучесть» в корпоративных сетях.
Протокол строится на модели «challenge-response»: сервер выдает клиенту случайную задачу (nonce), клиент формирует ответ, вычисленный из хэша пароля и полученного вызова, не раскрывая сам пароль. ⚙️ Базовая последовательность сообщений состоит из трех типов: NEGOTIATE, CHALLENGE, AUTHENTICATE. Для защиты целостности и конфиденциальности на сеанс может устанавливаться «session security» (подпись и шифрование трафика), применяемая, например, в SMB. Для веб-сценариев NTLM инкапсулируется в HTTP-заголовки Authorization/WWW-Authenticate.
Версии и развитие NTLM 💡
- LM (LAN Manager): крайне слабый предшественник, использует DES и разделение пароля на 7-символьные блоки; фактически компрометирован. Никогда не включайте и не храните LM-хэши.
- NTLMv1: применяет NT-хэш (MD4 от UTF-16LE пароля) и DES-операции поверх вызова; уязвим к ряду атак (relay, downgrade, крипто-слабости).
- NTLM2 Session: улучшение поверх NTLMv1 с дополнительными клиентскими данными, но это не NTLMv2.
- NTLMv2: HMAC-MD5 на основе NT-хэша, включает таймстемп и «Target Info» (AV-пары), MIC; устойчивее к воспроизведению и некоторым даунгрейдам.
- NTLM SSP (via SSPI): реализация протокола в рамках Windows SSPI и пакета Negotiate (SPNEGO), который выбирает Kerberos либо NTLM.
Как это работает под капотом 🔬
У клиента уже есть NT-хэш пароля (MD4 от Unicode-пароля); он никогда не отправляется по сети. При аутентификации сервер высылает «challenge» (8 байт). В NTLMv2 клиент собирает «blob» со временем, AV-парами (имя сервера, домен, DNS-имена), вычисляет HMAC-MD5 от этого blob и challenge с ключом, производным от NT-хэша, и отправляет ответ. Сервер, имея доступ к эталонному хэшу (через контроллер домена или локальную SAM/NTDS), воспроизводит вычисления и подтверждает подлинность. 🛡️ При успешной аутентификации стороны могут договориться о подписи/шифровании (RC4 или AES в новых реализациях SMB3) для защиты последующего трафика.
Сравнение NTLM и Kerberos (для ориентира) 📊
| Критерий | NTLM | Kerberos |
|---|---|---|
| Модель | Challenge-response, без третьей стороны | Билеты TGT/TGS через KDC (DC) |
| Взаимная аутентификация | Ограниченная (NTLMv2 с MIC/EPA) | Да, по умолчанию |
| Устойчивость к relay | Слабее; возможны NTLM relay-атаки 🚧 | Сильнее, особенно с каналами и SPN |
| Зависимость от времени | Меньше, но есть timestamp в v2 | Критична (синхронизация часов) |
| Производительность | Выше нагрузка на DC при частых проверках | Эффективнее при многократном доступе (кэш билетов) |
| Поддержка в облаке | Ограничена; чаще внутри сети | Широкая интеграция с AAD/федерацией ☁️ |
| Совместимость | Высокая с устаревшими сервисами | Требует SPN, правильно настроенных служб |
| Рекомендация | Оставлять только где иначе никак | Использовать по умолчанию |
| Шифрование трафика | Опционально (подпись/шифр. сеанса) | Чаще встроено в билетный процесс |
Где NTLM встречается на практике 🧭
- Локальные входы на рабочие станции и серверы вне домена (WORKGROUP) 🖥️.
- SMB/CIFS доступ к файловым шарам и печати, особенно между старыми устройствами.
- HTTP-прокси и веб-приложения с «Windows Integrated Authentication» (IWA), если Kerberos не сконфигурирован.
- WinRM/PowerShell Remoting при падении на Negotiate/NTLM; DCOM/Remote Registry.
- Смешанные среды с устройствами и ПО без поддержки Kerberos или SPN.
Безопасность: известные риски и защитные меры 🛡️
Классические угрозы включают relay (перепроксирование NTLM на другой сервис), pass-the-hash (использование украденного NT-хэша), даунгрейд от NTLMv2 к NTLMv1/LM, отсутствие подписи трафика SMB, слабую конфигурацию прокси/HTTP. Для снижения рисков применяют SMB Signing, Extended Protection for Authentication (EPA) с Channel Binding Token (CBT), ограничение NTLM по политикам, Kerberos-by-default, защита учетных данных LSASS (Credential Guard), и мониторинг событий аутентификации. Ключевая стратегия — минимизировать поверхности, где NTLM вообще необходим.
Настройка и ограничение NTLM в Windows ⚙️
Групповые политики (локальные или доменные):
- Конфигурация компьютера → Конфигурации Windows → Параметры безопасности → Локальные политики → Параметры безопасности:
- Сетевая безопасность: Уровень аутентификации LAN Manager (LmCompatibilityLevel)
- Сетевая безопасность: Запретить хранение значения хэша LAN Manager (NoLMHash)
- Сетевая безопасность: Ограничить NTLM: Аудит NTLM-аутентификации в этом домене/на этом компьютере
- Сетевая безопасность: Ограничить NTLM: Входящие/Исходящие NTLM-трафик
- Microsoft network server/client: Digitally sign communications (always/when possible)
Ключевые реестра и значения:
reg query HKLMSYSTEMCurrentControlSetControlLsa /v LmCompatibilityLevel
; Рекомендуемые уровни: 5 (NTLMv2 only; refuse LM & NTLMv1) или 3/4 в переходный период
reg add HKLMSYSTEMCurrentControlSetControlLsa /v NoLMHash /t REG_DWORD /d 1 /f
; Запретить хранение LM-хэша
reg add HKLMSYSTEMCurrentControlSetServicesLanmanServerParameters /v RequireSecuritySignature /t REG_DWORD /d 1 /f
reg add HKLMSYSTEMCurrentControlSetServicesLanmanWorkstationParameters /v RequireSecuritySignature /t REG_DWORD /d 1 /f
; Требовать SMB-подпись
reg add HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemKerberosParameters /v SupportedEncryptionTypes /t REG_DWORD /d 0x7fffffff /f
; Современные шифры Kerberos для приоритета над NTLM
Аудит и журналирование:
- Журнал Безопасности: события 4624 (Logon), поле Authentication Package = NTLM; 4776 (NTLM-аутентификация).
- Журналы приложений и служб → Microsoft → Windows → NTLM/Operational — детализированный аудит при включении политики «Audit NTLM».
- Netlogon/Operational: диагностика подписания и защищенного канала.
Примеры протокольных обменов и кода 🛠️
HTTP-обмен (схематично):
GET /resource HTTP/1.1
Host: app.local
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM
GET /resource HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADgAAAAFgomi...
GET /resource HTTP/1.1
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAEgAAAAYABgAWAAA...
HTTP/1.1 200 OK
PowerShell (встроенные учетные данные доменного пользователя, Negotiate → Kerberos/NTLM):
Invoke-WebRequest https://app.local -UseDefaultCredentials
# Для SMB уже будут задействованы SSPI и возможен NTLM при недоступности Kerberos
cURL с явным указанием NTLM (для теста, не для прод):
curl --ntlm -u "DOMAINUser:Password" http://app.local/protected
Практическая стратегия миграции с NTLM на Kerberos и дальше 🧭
- Включить аудит NTLM на контроллерах домена и серверах; собрать инвентарь сервисов и хостов, где NTLM встречается часто.
- Отладить SPN для сервисов (HTTP/host, MSSQLSvc, CIFS и т.д.); настроить доверие к делегированию, если нужно.
- Обновить клиенты/агенты/принтеры/СУБД-драйверы, которые не поддерживают Kerberos; для неподдерживаемых спланировать сегментацию и исключения.
- Включить SMB Signing и Extended Protection (EPA/CBT) на IIS/HTTP-проксах и SMB-серверах.
- Последовательно повышать LmCompatibilityLevel, блокировать LM и NTLMv1; переводить приложения на TLS-клиент/серверную аутентификацию, OIDC/SAML, где уместно.
- Внедрить Credential Guard/LSA Protection, ограничить доступ к учётным данным, мониторить 4776/4624 по критическим системам.
Частые вопросы (FAQ) ❓
Почему NTLM до сих пор включен в современных версиях Windows? 🧠
Основная причина — совместимость. Во многих организациях есть устройства, приложения и протоколы, которые не поддерживают Kerberos или не умеют работать со SPN, особенно в рабочих группах и смешанных средах. NTLM выступает «страховочной сеткой», чтобы не ломать доступ при сбоях KDC или ошибках конфигурации DNS/SPN. Вторая причина — привычка: многие администраторы полагаются на «просто работает» через SSPI/Negotiate. Однако Microsoft последовательно продвигает отказ от NTLM, добавляя политики «Restrict NTLM», аудит и улучшения Kerberos/SSL. На практике переход требует инвентаризации и планирования, поэтому занимает время. Грамотный путь — постепенная миграция с контролируемым отключением.
Чем опасен NTLM relay и как ему противостоять? 🛡️
NTLM relay перенаправляет законный challenge-response на другой сервис, позволяя атакующему аутентифицироваться без знания пароля. Это возможно, когда целевой сервис не требует подписи/шифрования и не выполняет привязку к каналу (channel binding) или к хосту (SPN). Классический пример — relay из HTTP на SMB или наоборот, что даёт доступ к ресурсам от имени жертвы. Защита включает обязательную SMB-подпись, Extended Protection for Authentication (EPA) в IIS/HTTP, Channel Binding Tokens и отключение NTLM там, где Kerberos доступен. Сегментация сети и ограничение привилегий учетных записей уменьшают масштаб потенциального ущерба. Стоит также отслеживать аномальные 4776/4624 и события в журнале NTLM/Operational. В связке с Defender for Identity можно обнаруживать подозрительные релейные потоки.
Как понять, что конкретный вход или сетевой доступ прошёл по NTLM, а не Kerberos? 🔎
Посмотрите события журнала Безопасности: 4624 (тип входа) содержит «Authentication Package: NTLM» или «Kerberos». Событие 4776 явно указывает на проверку учетных данных через NTLM. В SMB можно увидеть, требует ли сервер подпись и был ли установлен защищенный сеанс. На клиенте инструменты like klist покажут выданные Kerberos-билеты; их отсутствие при успешном доступе намекает на NTLM. В вебе заголовки WWW-Authenticate/Authorization укажут схему NTLM. Наконец, включенный аудит NTLM в домене даст целевые события в канале Microsoft-Windows-NTLM/Operational с деталями запроса. Это помогает локализовать сервисы, которые нужно мигрировать на Kerberos.
Можно ли «сделать NTLM безопасным» вместо отключения? 🛠️
Частично можно снизить риски, но полностью «безопасным» NTLM не станет. Включите NTLMv2 only (LmCompatibilityLevel ≥ 5) и запретите LM/NTLMv1. Требуйте SMB Signing на клиентах и серверах, включите Extended Protection/CBT на веб-сервисах. Примените Credential Guard, LSA Protection и минимизацию локальных администраторов, чтобы усложнить пасс-дэ-хэш. Ограничьте входящие/исходящие NTLM политиками и заведите Allow-листы только для строго нужных хостов. Следите за журналами 4776, 4624, NTLM/Operational и реагируйте на аномалии. Но стратегически лучше заменить NTLM на Kerberos или другие современные механизмы с TLS и взаимной аутентификацией.
Как мигрировать веб-приложение с NTLM на более современную схему аутентификации? 🌐
Если приложение уже использует «Windows Integrated Authentication» через IIS, настройте SPN для HTTP/имени сервиса и включите Negotiate/Kerberos как приоритет; это позволит клиентам автоматически перейти на Kerberos. Для внешних пользователей переходите к протоколам уровня приложения: OpenID Connect/OAuth 2.0 или SAML через федерацию (например, ADFS или облачный провайдер). Обязательно включайте TLS с современными наборами шифров и проверяйте channel binding для снижения риска relay. Проведите инвентаризацию зависимостей (прокси, балансировщики, reverse proxy), чтобы они корректно проксировали контекст Kerberos/headers. Выполните поэтапный rollout: сначала пилотная группа, затем расширение и, наконец, отключение NTLM. Тщательно протестируйте сценарии SSO, SPN, SPNego и проверку PAC/групповых претензий, если приложение на них опирается.
Снипы и документы по теме (названия для поиска) 📚
- Microsoft Docs: NTLM Authentication Protocol
- Security Policy Settings: Network security: LAN Manager authentication level
- IIS: Extended Protection for Authentication (EPA) and Channel Binding
- SMB Security: SMB Signing and Encryption
- Detecting Pass-the-Hash and NTLM Relay in Windows Event Logs
- Kerberos SPNs: SetSPN and Service Principal Names