Статья Отключить NTLMv1 через GPO — и всё равно увидеть его в pcap: обход LmCompatibilityLevel и аудит legacy-трафика

Внутренний пентест финансовой организации, конец 2024. Домен на Windows Server 2019, GPO Network security: LAN Manager authentication level выставлен в уровень 5 - Send NTLMv2 response only. Refuse LM & NTLM. Я поднял Responder в серверном VLAN и через двадцать минут получил NetNTLMv1-хеш от сервисной учётки с правами на файловом сервере.

Администратор был уверен: NTLMv1 он отключил три года назад.

Хеш прилетел от legacy-приложения на старом IIS, которое запрашивало NTLMv1 через собственные NTLM-флаги в CHALLENGE-сообщении. Контроллер домена валидировал этот хеш через MS-NRPC, не глядя на LmCompatibilityLevel. Исследование Silverfort, опубликованное в январе 2025, подтвердило: это не частный баг, а архитектурная проблема Active Directory, затрагивающая любую среду с on-prem приложениями. Ниже - разбор механизма, практический аудит и сценарий эксплуатации.

Место NTLMv1 в цепочке атаки на Active Directory​

NTLMv1 - не самостоятельный exploit. Это слабое звено аутентификации, которое атакующий дёргает на нескольких этапах kill chain. Понимание позиции NTLMv1 в цепочке определяет, какой инструмент брать и что искать. Подробнее - в нашем обзоре атаки на аутентификацию.

Credential Access - перехват NetNTLMv1-хешей. Responder отвечает на LLMNR/NBT-NS-запросы и собирает хеши через Forced Authentication (T1187) или Network Sniffing (T1040). NTLMv1 использует DES - перебор challenge-response на GPU занимает минуты.

Password Cracking (T1110.002) - NetNTLMv1-хеш конвертируется в NT-хеш через rainbow tables. Сервисы вроде crack.sh справляются за время от минут до 24 часов (DES keyspace полностью покрыт rainbow tables). NTLMv2 таким способом не ломается - разница принципиальная.

Lateral Movement - Pass the Hash (T1550.002). Полученный NT-хеш работает для аутентификации на других серверах без знания пароля. CrackMapExec, impacket-psexec, impacket-wmiexec - выбор зависит от целевой машины.

NTLM Relay - Name Resolution Poisoning and SMB Relay (T1557.001). NTLMv1-сессия перенаправляется на другой сервер. В NTLMv2 AV_PAIRS привязывают ответ к конкретному серверу, и relay усложняется. В NTLMv1 такой привязки нет - relay тривиален.

Отдельный вектор - Downgrade Attack (T1689, Defense Evasion): атакующий принудительно понижает версию NTLM, заставляя клиента отправить NTLMv1. Достаточно контролировать сервер или поднять rogue-сервис, который в CHALLENGE запросит NTLMv1.

Контекст угрозы: по данным CrowdStrike Global Threat Report 2025, 75% вторжений за 2024 год использовали действительные учётные данные. IBM X-Force фиксирует рост атак на credentials на 71% год к году. NTLMv1 - один из самых дешёвых путей к credentials внутри сети: не нужен phishing, не нужен 0-day. Поднял Responder - жди.

Почему GPO LmCompatibilityLevel = 5 не отключает NTLMv1​

Политика Network security: LAN Manager authentication level управляет ключом реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel. Уровни 0–3 определяют, что отправляет клиент (NEGOTIATE_MESSAGE). Уровни 4–5 - что принимает сервер при прямой аутентификации (CHALLENGE_MESSAGE). Уровень 5: клиент шлёт только NTLMv2, сервер отказывает LM и NTLMv1.

А теперь - где ломается логика.

«Сервер» здесь - Windows-машина, обрабатывающая NTLM-запрос напрямую. В реальной AD аутентификация идёт через посредника: клиент -> сервер приложения -> контроллер домена (через Netlogon/MS-NRPC). LmCompatibilityLevel управляет первой стрелкой и поведением сервера как прямого участника. Он не управляет тем, что DC получает от сервера приложения через MS-NRPC для валидации.

Исследование Silverfort (январь 2025) раскрыло механизм обхода: on-prem приложения настраиваются так, что запрашивают NTLMv1 у клиентов через NTLM-флаги в CHALLENGE, игнорируя LmCompatibilityLevel на клиентской машине. Клиент подчиняется серверу приложения: если CHALLENGE просит NTLMv1 - клиент отвечает NTLMv1. Затем сервер пересылает NTLMv1-ответ контроллеру домена через MS-NRPC. DC выполняет валидацию и принимает NTLMv1, потому что LmCompatibilityLevel контролирует его поведение как сервера при прямой аутентификации, а не при валидации через Netlogon.

По данным Silverfort, 64% учётных записей Active Directory регулярно аутентифицируются через NTLM. Доля NTLMv1 зависит от конкретной среды, но даже одно on-prem приложение с неправильной конфигурацией превращает LmCompatibilityLevel = 5 в фикцию.

MSRC при ответе на disclosure указал: обход - не уязвимость, а ожидаемое поведение. Тем не менее в течение двух месяцев Microsoft объявил полное удаление NTLMv1 из Windows 11 24H2 и Windows Server 2025. Нюанс: Server 2025 больше не поддерживает запрос NTLMv1, но контроллеры домена на Server 2025 по-прежнему принимают NTLMv1 при валидации через MS-NRPC. Если в сети есть хотя бы один сервер не на 2025 с legacy-приложением или non-Windows клиент - атака работает.

Ещё один вектор, о котором часто забывают: ключ LmCompatibilityLevel расположен вне стандартного пути GPO (HKLM\SOFTWARE\Policies). Если политика была применена, а затем переведена в «Not Defined» - значение в реестре остаётся (так называемый tattoo-эффект). Старая GPO с LmCompatibilityLevel = 0 или 1 может годами жить в реестре машин, давно выведенных из-под этой политики. По данным Microsoft (Active Directory Hardening Series), изменение LmCompatibilityLevel вступает в силу немедленно, без перезагрузки - но только если ключ реально обновлён.

В зоне риска:

• Организации с самописными или сторонними on-prem приложениями, использующими NTLM
• Сети с non-Windows клиентами (macOS, GNU/Linux), подключающимися к Windows-сервисам
• Инфраструктуры с legacy-устройствами: принтеры, NAS, промышленные контроллеры

Обнаружение NTLMv1: аудит NTLM аутентификации и сетевой трафик​

Windows Event ID 4624 и NTLM Operational Log​

Основной источник для обнаружения NTLMv1 - Event ID 4624 (An account was successfully logged on) в Security Log. Поле Package Name (NTLM only) содержит версию: NTLM V1 или NTLM V2. Поле Authentication Package - NTLM.

И вот тут момент, который на практике упускают почти все: 4624 логируется на машине, где произошёл logon, а не на контроллере домена. DC логирует Event ID 4776 (The computer attempted to validate the credentials for an account), но 4776 не содержит версию NTLM. Для полной картины нужно собирать 4624 со всех серверов и рабочих станций домена.

PowerShell для поиска NTLMv1-аутентификаций на контроллерах домена за неделю:

$DCs = Get-ADDomainController -Filter *
foreach ($DC in $DCs) {
    Get-WinEvent -ComputerName $DC.HostName -FilterHashtable @{
        LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)
    } -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -match 'NTLM V1' } |
    Select-Object TimeCreated, MachineName,
        @{N='User';E={$_.Properties[5].Value}}
}

Этот скрипт ищет 4624 только на DC. Для полного покрытия нужно запускать аналогичный запрос на каждом member-сервере - или централизовать сбор через SIEM. На моих проектах именно member-серверы оказывались источником NTLMv1, а не DC.

Дополнительный уровень: три политики NTLM-аудита в Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options:

• Network Security: Restrict NTLM: Audit NTLM authentication in this domain -> Enable all
• Network Security: Restrict NTLM: Audit Incoming NTLM Traffic -> Enable auditing for domain accounts
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers -> Audit all

После включения события пишутся в Applications and Services Logs -> Microsoft -> Windows -> NTLM -> Operational:

Event ID	Где логируется	Что показывает
8001	Клиент	Целевой сервер, процесс, учётная запись
8003	Сервер	Учётная запись, имя клиента, процесс
8004	DC	Учётная запись, клиент, имя сервера

Эти события показывают где используется NTLM, но не версию (v1/v2). Для определения версии по-прежнему нужен 4624 на конечной машине.

Windows 11 24H2 и Server 2025 меняют ситуацию: добавлены новые события NTLM-аудита, позволяющие определять версию NTLM (v1/v2) в том числе на уровне DC - раньше это было возможно только через разбор pcap. Конкретные Event ID - в актуальной документации Microsoft (серия анонсов NTLM deprecation). Обратная совместимость не планируется - события доступны только на новых версиях ОС.

Wireshark: фильтры для NTLMv1 трафика в сети​

Event Log показывает результат. Wireshark показывает процесс - и не зависит от версии ОС.

Для фильтрации всего NTLM-трафика: display filter ntlmssp. Для выделения AUTHENTICATE-сообщений (содержат хеш): ntlmssp.messagetype == 0x00000003.

Как определить версию в GUI: разверните NTLMSSP -> NTLM Response в AUTHENTICATE-пакете. Ровно 24 байта - NTLMv1. Больше 24 байт (содержит NTLMv2 blob с AV_PAIRS, timestamp, target info) - NTLMv2. Просто считаете длину - и всё понятно.

Для автоматизации на большом pcap:

tshark -r capture.pcap -Y "ntlmssp.messagetype == 0x00000003" \
  -T fields -e ip.src -e ntlmssp.auth.username \
  -e ntlmssp.auth.domain -e ntlmssp.ntlmv2_response

Строки с пустым полем ntlmssp.ntlmv2_response при непустом auth - кандидаты на NTLMv1. Пустое NTLMv2-поле означает, что клиент отправил NTLMv1-ответ.

NTLM relay атака: от перехвата NTLMv1 до lateral movement​

Требования к окружению​

• Сценарий: внутренний пентест, grey box (выданы доменные учётные данные low-privileged пользователя)
• ОС атакующего: Kali Linux 2024.x+ или любой GNU/Linux с Python 3.10+
• Инструменты: Responder (github.com/lgandx/Responder, активно поддерживается), Impacket (github.com/fortra/impacket, активно поддерживается), CrackMapExec/NetExec
• Сетевые условия: L2-доступ в целевой VLAN, отсутствие 802.1X на порту подключения
• Целевая инфра: Active Directory, хотя бы один on-prem legacy-сервис или non-Windows клиент

Сценарий grey box: fingerprinting и эксплуатация​

Шаг 1. Pre-exploitation fingerprinting (T1615, Group Policy Discovery)

Перед запуском Responder определяем LmCompatibilityLevel на доступных хостах. С low-priv доменными кредами можно попробовать:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Чеклист: устранение legacy authentication в Active Directory​

Чеклист для включения в отчёт о пентесте или передачи администратору:

1. Включить NTLM-аудит через GPO: три политики Restrict NTLM (Audit NTLM authentication, Audit Incoming NTLM Traffic, Outgoing NTLM traffic) - собирать минимум 14 дней
2. Собрать Event ID 4624 со всех серверов и DC, фильтр по Package Name = NTLM V1 - составить полный список источников NTLMv1 (имя машины + процесс + учётная запись)
3. Выставить LmCompatibilityLevel = 5 через GPO на DC и всех member-серверах: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: LAN Manager authentication level -> «Send NTLMv2 response only. Refuse LM & NTLM»
4. Проверить реестр на tattooed-значения: ключ HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel - если отсутствует, ОС использует умолчание (уровень 3 для Win7+, уровень 0 для более старых ОС); если значение < 5, GPO не применилась или переопределена другой политикой; если политика удалена, но значение осталось - ручная очистка на каждой машине
5. Аудит on-prem приложений: любое приложение с собственными настройками NTLM может обходить GPO - проверить конфигурацию IIS, legacy ERP, самописных сервисов
6. Отключить LLMNR (Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off Multicast Name Resolution) и NBT-NS (через настройки сетевого адаптера) - устраняет основной вектор перехвата
7. Включить SMB Signing на всех серверах - блокирует NTLM relay
8. Включить Credential Guard: изолирует NTLM-секреты в LSAIso и затрудняет извлечение NT-хешей из памяти (mitigates Pass the Hash), но не блокирует NTLMv1-аутентификацию по сети - LmCompatibilityLevel и NTLM-блокировки остаются необходимыми
9. Идентифицировать Kerberos fallback: причины - отсутствующие SPN, дублирующиеся SPN, обращение по IP вместо hostname. Event ID 4769 с failure code на DC покажет неудачные попытки Kerberos
10. Планировать миграцию на Server 2025: единственная версия, где NTLMv1 невозможен на уровне ОС (но DC валидирует NTLMv1 от старых серверов через MS-NRPC)

Заключение​

Большинство отчётов о пентесте AD содержат рекомендацию «отключить NTLMv1 через GPO». Большинство заказчиков уверены, что давно это сделали. Проблема не в GPO и не в администраторах.

Проблема в ментальной модели: LmCompatibilityLevel = 5 воспринимается как забор вокруг всего домена. На практике это замок на одной двери, а application-level NTLM-конфигурация - открытое окно рядом. Silverfort подтвердил то, что мы видели на проектах годами: ни один стандартный SIEM-дашборд не покажет, что конкретное on-prem приложение запрашивает NTLMv1 у клиентов. Event ID 4624 с полем NTLM V1 - единственный достоверный индикатор, и его нужно собирать со ВСЕХ member-серверов, а не только с DC. На моих проектах ни одна из обследованных организаций не делала этого систематически - собирали только с контроллеров домена, где информации о версии NTLM нет.

Microsoft удалит NTLMv1 из Windows за ближайшие пару лет. Legacy-устройства - принтеры, NAS, OT-контроллеры - будут генерировать NTLMv1-трафик ещё пять-семь лет. Организации, которые сегодня не вкладываются в мониторинг NTLM на уровне сети (не GPO-галочек, а реального pcap и сбора 4624 со всех хостов), через год обнаружат, что «защитились» от протокола, который продолжает летать по их VLAN.

Единственный честный способ проверить - поднять Responder в режиме анализа и посмотреть, что прилетит за сутки. Результат обычно отличается от ожиданий. На WAPT эту цепочку - от обнаружения NTLMv1 до lateral movement через relay - проходят в течение двух модулей с лабами.