Чем плох NTLM в 2025 году?

NTLM уязвим к pass-the-hash и relay-атакам, не поддерживает взаимную аутентификацию, использует устаревшие алгоритмы. Microsoft официально рекомендует отключать NTLM и переходить на Kerberos, где возможно.

Можно ли полностью отключить NTLM в среднем офисе?

Да, но после тщательного аудита. Обычно 95% трафика можно увести в Kerberos, а оставшиеся 5% (старое ПО, подключения по IP, сканеры документов) — занести в список исключений политики «Add server exceptions».

Сколько времени занимает миграция?

В среднем офисе на 100–200 ПК — от 2 до 6 недель. Две недели на сбор аудита, 1–2 недели на исправление SPN и настройку исключений, неделя на блокировку в режиме «audit» и ещё неделя на финальный «deny».

Что такое SPN и зачем он нужен?

Service Principal Name — уникальное имя сервиса в AD, привязанное к учётной записи компьютера или сервисной учётки. Без корректного SPN клиент не сможет получить Kerberos-тикет и упадёт на NTLM, что нам нежелательно.

Как включить аудит NTLM?

Через GPO «Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Restrict NTLM». Три параметра: Audit Incoming, Audit NTLM authentication, Audit Outgoing NTLM. Логи появляются в Event Viewer → Applications and Services → Microsoft → Windows → NTLM.

Безопасность AD 18 сентября 2025 · 17 мин чтения

Блокировка NTLM и миграция на Kerberos: как безопасно уйти от наследия 90-х

Семёнов Евгений Сергеевич, директор АйТи Фреш, 15+ лет в корпоративных AD-инфраструктурах. Из последних десяти аудитов у восьми клиентов Windows NTLMv1 всё ещё обрабатывался контроллерами домена. Это 2025 год, а не 2005-й. NTLM — открытая дверь для pass-the-hash и NTLM-relay атак, которыми атакующие успешно пользуются в 90% инцидентов с компрометацией AD. Я всегда настаиваю на полной миграции на Kerberos, и в этой статье — пошаговый план, как сделать это без простоя бизнеса.

Чем опасен NTLM и зачем его отключать

NTLM появился в Windows NT в середине 90-х как улучшение LAN Manager. Даже «современный» NTLMv2 страдает от архитектурных проблем: нет взаимной аутентификации (клиент не проверяет сервер), нет защиты от relay (злоумышленник перехватывает challenge-response и проигрывает его на третьей машине), используются слабые хэши без соли.

Классические атаки, которые работают против NTLM в 2025 году:

Pass-the-Hash — злоумышленник снимает NTLM-хэш из LSASS и логинится на другие машины без знания пароля.
NTLM Relay — перехватывает аутентификацию с одной машины и пересылает на другую, получая доступ под перехваченной учёткой.
Kerberoasting на NTLM-путях — если сервис отказывается от Kerberos, сыпется TGS через NTLM и хэши ловятся оффлайн-брутом.
Downgrade — принудительный откат от Kerberos к NTLM через манипуляции с сетевыми именами.

Kerberos, в свою очередь, поддерживает mutual authentication, MIC (Message Integrity Code), привязку к именам сервисов через SPN и шифрование AES256. Это стандарт аутентификации в AD с 2000 года — пора использовать его везде.

Этап 1: Аудит существующего NTLM-трафика

Сначала нужно понять, кто в сети всё ещё говорит на NTLM. Для этого включаем аудит на всех контроллерах домена и рядовых серверах через GPO. У нас на практике я всегда делаю это минимум на 14 дней — чтобы поймать месячные задачи, backup-задания и квартальные отчёты.

# На DC — GPO "NTLM Audit"
Computer Configuration → Policies → Windows Settings → Security Settings →
  Local Policies → Security Options:

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

После применения политики в Event Viewer появляется специальный журнал: Applications and Services Logs → Microsoft → Windows → NTLM → Operational. Ключевые события:

8001 — исходящий NTLM-запрос. Видно, с какого клиента, на какой сервер, какая учётка.
8002 — входящий NTLM-запрос на сервер.
8003 — доменный DC обработал NTLM-запрос. Это главный источник истины на DC.

Я собираю эти события в Elasticsearch или Graylog, группирую по parой client+server+user и получаю список источников NTLM. Типичная картина: 50–200 уникальных источников, из которых 80% — это три-четыре категории: старые сканеры с SMBv1, самописное ПО на VBScript, обращения по IP вместо FQDN, вложенные скрипты со скрытыми учётками.

Этап 2: Разбор источников и починка SPN

Первая типовая причина NTLM — обращение к серверу по IP-адресу. Kerberos-клиент проверяет SPN вида HOST/server.domain.ru, и если в запросе IP — SPN не находится, тикет не выпускается, клиент откатывается на NTLM. Лечение: фиксируем обращения по DNS-именам.

Вторая причина — отсутствие SPN у сервисной учётки. Например, SQL Server запущен под доменной учёткой svc_sql1c, а SPN MSSQLSvc/sql01.corp.ru:1433 на эту учётку не зарегистрирован. Клиент 1С спрашивает Kerberos-тикет для сервиса, не находит его и падает на NTLM.

# Проверка SPN для учётки
setspn -L svc_sql1c

# Регистрация SPN
setspn -S MSSQLSvc/sql01.corp.ru:1433 CORP\svc_sql1c
setspn -S MSSQLSvc/sql01.corp.ru CORP\svc_sql1c

# Проверка дубликатов SPN — главный враг Kerberos
setspn -X -F

Дубликаты SPN (когда одно и то же имя сервиса зарегистрировано на двух учётках) — классическая причина отказа Kerberos. setspn -X показывает конфликты, их нужно чистить в обязательном порядке.

Этап 3: Типовые источники NTLM и их лечение

Источник	Причина	Как починить
Старые сканеры Kyocera/Ricoh	Scan-to-SMB с SMBv1 и NTLMv1	Обновить прошивку, включить SMBv2, создать отдельную учётку с Kerberos
Самописные скрипты VBS/PowerShell	Обращение по IP или NetBIOS-имени	Переписать с использованием FQDN
Приложения с runas /netonly	Принудительный NTLM	Использовать gMSA или CredSSP с Kerberos
IIS с Anonymous + NTLM	Дефолтная конфигурация	Включить Negotiate, SPN на app pool identity
Сервисные учётки без SPN	Администратор не прописал	setspn -S для всех клиентских подключений
Подключение SMB по IP	Fallback на NTLM	Исправить скрипты/GPO, DNS-алиасы

Этап 4: Исключения для того, что починить нельзя

Всегда остаётся 3–5% трафика, который починить невозможно. Старый робот, самописный контроллер, унаследованный MSSQL 2008. Для них в GPO есть параметр «Add server exceptions in this domain» и «Add server exceptions for NTLM authentication».

# GPO "NTLM Exceptions"
Network security: Restrict NTLM: Add server exceptions in this domain:
  scanner01.corp.ru
  scanner02.corp.ru
  legacyapp.corp.ru
  10.10.5.42  # если действительно нужен IP

# После добавления — делаем аудит ещё неделю, чтобы убедиться,
# что список полный

Я всегда веду исключения как отдельный GPO-объект, отдельно от основной политики блокировки. Так при необходимости их проще отозвать, и видно кто, когда и зачем добавил исключение.

Этап 5: Переход в режим «deny audit only»

Следующий шаг — включаем режим «отказывать, но только логировать». Это промежуточная фаза: все NTLM-запросы, не попавшие в исключения, помечаются в логе как «would be blocked», но по факту ещё проходят. Пару недель в этом режиме — и видно, какие ещё источники случайно просочились.

Network security: Restrict NTLM: NTLM authentication in this domain
  = Deny all except for server exceptions — Audit only

Network security: Restrict NTLM: Incoming NTLM traffic
  = Deny all except for server exceptions — Audit only

После двух недель без новых событий «would be blocked» — переключаем на финальный режим «Deny». Это блокирующая политика, NTLM больше не работает, всё что не Kerberos — отказ.

Мини-кейс: миграция для юридической фирмы, 120 РМ

В марте 2026 года к нам на аудит пришла юридическая фирма в центре Москвы. Два DC на Windows Server 2019, 120 рабочих мест, файловый сервер, 1С, MSSQL, Exchange 2016. Задача — подготовиться к проверке регулятора и закрыть все NTLM-подключения. Сроки — два месяца.

Неделя 1–2: включили аудит, собрали 43 000 событий NTLM. Группировка показала 18 уникальных источников: 4 сканера Kyocera, 7 самописных скриптов планировщика, 3 службы 1С, 2 старых сервера под MSSQL 2012, пара подключений удалёнщиков через неправильно настроенный VPN.

Неделя 3–4: зарегистрировали SPN для MSSQL и 1С (5 записей), переписали 7 скриптов с IP на FQDN, обновили прошивку 3 из 4 сканеров. Четвёртый сканер не обновлялся — занесли в список исключений.

Неделя 5: включили «Audit only deny». Поймали ещё 3 источника (неочевидные скрипты на Linux-машинах с samba-клиентом). Починили.

Неделя 6: финальный режим «Deny all». В первые 2 часа — 4 обращения в саппорт, все решены консультацией по правильному URL. На Dell Xeon Platinum 8280 наш контроллер домена обрабатывает входящие тикеты Kerberos на порядок быстрее, чем раньше NTLM-хэши. Стоимость работ — 180 000 руб. за 6 недель сопровождения.

Подводные камни и как их обойти

За много проектов собрал список граблей, на которые часто наступают:

NTLM на трастах между доменами. При наличии лес-траста NTLM может идти по межлесовым запросам. Нужно настраивать Selective Authentication и разрешать Kerberos-through-trust.
UPN suffix не совпадает с FQDN. Kerberos ищет SPN по FQDN из UPN, при несоответствии ломается.
Machine account password более 30 дней. У локальных учёток компьютеров пароль меняется автоматически, но если машина долго не в сети — password mismatch, Kerberos не работает.
Использование NetBIOS-имён. NetBIOS даёт короткое имя без домена, SPN не находится. Лечится запретом использования NetBIOS в корпоративной сети и переходом на полные имена.
Старые принтеры с NTLMv1. В сети это последний источник, не отдаёт NTLMv2. Либо меняем на современное железо, либо заносим в исключения и ограничиваем VLAN.
LmCompatibilityLevel на клиентах. Убедитесь, что на всех ПК уровень 5 (Send NTLMv2 only, refuse LM and NTLMv1).

Мониторинг после миграции

Закончили миграцию — не расслабляйтесь. Я всегда держу включённым continuous-аудит по NTLM в рамках SIEM, чтобы ловить попытки downgrade-атак:

Алерт на любое событие 8001/8002 на доменных контроллерах — каждую неделю проверяем и разбираемся.
Отдельный дашборд с графиком «NTLM attempts over time» — падение до нуля означает, что всё работает.
Аудит добавления записей в исключения — любое изменение фиксируется и согласовывается с IT-отделом.
Квартальный пересмотр списка исключений — уходит ли старое железо, обновилось ли ПО, можно ли убрать запись.

Поможем уйти от NTLM без простоя бизнеса

Проведу полный аудит NTLM-трафика, найду все источники, починю SPN и скрипты, настрою GPO и проконтролирую миграцию до финального Deny-режима. Работаю с офисами от 50 рабочих мест, срок — от 4 до 8 недель в зависимости от сложности.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

FAQ — частые вопросы по миграции NTLM → Kerberos

Чем плох NTLM в 2025 году?: NTLM уязвим к pass-the-hash и relay-атакам, не поддерживает взаимную аутентификацию, использует устаревшие алгоритмы. Microsoft официально рекомендует отключать NTLM и переходить на Kerberos, где возможно.
Можно ли полностью отключить NTLM в среднем офисе?: Да, но после тщательного аудита. Обычно 95% трафика можно увести в Kerberos, а оставшиеся 5% (старое ПО, подключения по IP, сканеры документов) — занести в список исключений политики «Add server exceptions».
Сколько времени занимает миграция?: В среднем офисе на 100–200 ПК — от 2 до 6 недель. Две недели на сбор аудита, 1–2 недели на исправление SPN и настройку исключений, неделя на блокировку в режиме «audit» и ещё неделя на финальный «deny».
Что такое SPN и зачем он нужен?: Service Principal Name — уникальное имя сервиса в AD, привязанное к учётной записи компьютера или сервисной учётки. Без корректного SPN клиент не сможет получить Kerberos-тикет и упадёт на NTLM, что нам нежелательно.
Как включить аудит NTLM?: Через GPO «Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Restrict NTLM». Три параметра: Audit Incoming, Audit NTLM authentication, Audit Outgoing NTLM. Логи появляются в Event Viewer → Applications and Services → Microsoft → Windows → NTLM.