NTLM в корпоративных сетях сегодня

«NTLM — это протокол из другой эры, доставшийся нам в наследство. Он повсюду, но его уязвимости стали системной проблемой для целых индустрий. Отказ от него — это не просто техническая модернизация, а постоянная борьба со старыми зависимостями, которые пронизывают инфраструктуру на всех уровнях.»

История и назначение

Протокол NTLM появился в середине 90-х как ответ Microsoft на потребность в безопасной аутентификации в локальных сетях. Это было время, когда основную угрозу представлял перехват паролей в открытом виде, и механизм «запрос-ответ» казался революционным. Клиент больше не отправлял пароль, а доказывал его знание, отвечая на криптографическую задачу от сервера. Это решило одну проблему, но породило другие, более фундаментальные.

NTLM не создавался для современного интернета. В его основе — собственная, закрытая криптография, а сама модель не предполагает ни сервера аутентификации как третьей доверенной стороны, ни взаимной проверки подлинности. Это протокол-«остров», который эффективно работает только внутри защищённого периметра, концепция которого сегодня всё чаще размывается.

Именно NTLM стал «клеем» для первой версии Active Directory и таких критически важных служб, как файловый обмен по SMB и удалённый рабочий стол. Многие из этих технологий со временем научились работать и с более безопасным Kerberos, но поддержка NTLM осталась для обратной совместимости — и стала «чёрным ходом» по умолчанию.

Как работает NTLM: механизм «запрос-ответ»

Аутентификация проходит в три этапа. Каждый из них открывает свои векторы для атаки, что и определяет уязвимость протокола в целом.

Negotiate

Клиент инициирует соединение, сообщая серверу, что он понимает протокол NTLM. На этом этапе не передаётся ничего секретного, но уже можно определить, что целевая система использует устаревший метод.

Challenge

Сервер генерирует случайную последовательность байт (nonce), так называемый «вызов», и отправляет её клиенту. Идея в том, чтобы каждый запрос на вход был уникальным. Однако на практике этот механизм оказался слабым звеном из-за способа использования этого «вызова» в дальнейшем.

Authenticate

Клиент берёт хеш пароля пользователя (который хранится в памяти или в локальной базе SAM), комбинирует его с полученным от сервера «вызовом» и создаёт ответ. Этот ответ и отправляется обратно. Сервер, зная хеш пароля (например, из Active Directory) и исходный «вызов», выполняет те же вычисления и сверяет результат.

Главная проблема кроется в деталях: клиент оперирует не самим паролем, а его хешем. И этот хеш — статический ключ, одинаковый для каждой сессии. Если злоумышленник получит хеш, он сможет сконструировать правильный ответ на любой «вызов» от сервера, не зная пароля.

Уязвимости: не отдельные баги, а системный недостаток

Уязвимости NTLM — не случайные ошибки реализации, а следствие устаревшей архитектуры.

Уязвимость	Принцип работы	Почему это работает в NTLM
Pass-the-Hash (PtH)	Использование украденного хеша пароля для создания валидного ответа на аутентификацию без его расшифровки.	Хеш пароля является статическим криптографическим ключом. Сервер проверяет корректность вычисления с его использованием, а не факт знания исходного пароля.
Атака повторного использования (Replay)	Перехват полного пакета аутентификации (Challenge + Response) и его отправка для доступа в той же сетевой сессии.	Отсутствие привязки к сессии (session binding) и временных меток в NTLMv1 делает пакет действительным, пока живёт «вызов» сервера.
Relay-атака (NTLM Relay)	Пересылка запроса аутентификации от жертвы на другой сервер, выдавая себя за жертву.	Отсутствие взаимной аутентификации и привязки к конкретному серверу-цели. Сервер-жертва не может отличить ретранслированный запрос от прямого.

Эти атаки — не теоретические. Они лежат в основе многих современных цепочек взлома, позволяя перемещаться по сети, повышать привилегии и захватывать контроль над доменами. PtH и Relay стали стандартными модулями в фреймворках для тестирования на проникновение.

Почему от NTLM так сложно отказаться

Приказ «отключить NTLM» технически прост, но на практике ведёт к остановке бизнес-процессов. Его поддержка зашита в тысячи мест.

Унаследованное ПО и оборудование. Промышленные контроллеры, сканеры, принтеры, кассовые аппараты, системы контроля доступа — часто они поддерживают только NTLM и SMBv1. Их замена стоит миллионов и лет миграции.
Сценарии вне домена. Kerberos блестяще работает внутри домена Active Directory, но для аутентификации на изолированных серверах рабочих групп, в гостевых сегментах или при кросс-доменном доступе без доверительных отношений системы часто откатываются к NTLM.
Некоторые реализации аутентификации в веб-приложениях (Windows Integrated Authentication) и доступ к ресурсам по IP-адресу вместо имён также могут триггерить NTLM.

Получается парадокс: инфраструктура считается современной, но критичные участки цепляются за протокол тридцатилетней давности, создавая бреши в безопасности.

NTLM и Kerberos: два разных мира

Сравнивать NTLM и Kerberos — это как сравнивать механический замок и систему электронных пропусков. Kerberos решает фундаментальные проблемы предшественника.

Аспект	NTLM	Kerberos
Архитектура	Прямая аутентификация (клиент-сервер)	Архитектура с центром распределения ключей (KDC)
Взаимная аутентификация	Нет. Клиент не проверяет сервер.	Да. Билет гарантирует подлинность сервера.
Защита от Relay	Слабая (частично улучшена в NTLMv2)	Сильная. Билеты зашифрованы для конкретного сервиса.
Delegation (делегирование прав)	Нет поддержки	Есть, включая constrained delegation
Зависимость от времени	Слабая	Строгая. Билеты имеют время жизни.

Kerberos использует билеты (tickets), которые выдает доверенный Центр распределения ключей (Key Distribution Center, KDC), обычно роль которого выполняет контроллер домена. Билет действителен только для конкретного сервиса и ограничен по времени, что делает его бесполезным в случае перехвата.

Стратегия управления рисками

Полный и мгновенный отказ от NTLM в большинстве организаций невозможен. Вместо этого нужен поэтапный план управления рисками.

Аудит и учёт. Первый шаг — понять масштаб проблемы. Необходимо включить аудит событий NTLM в политиках домена (события с ID 4624 и 4648 в журналах безопасности с указанием типа аутентификации) и проанализировать, какие системы, пользователи и приложения его используют. Инструменты вроде Netlogon с диагностическим уровнем логирования помогают собрать детальные данные.
Поэтапное ограничение. В политиках безопасности домена можно настроить ограничения для NTLM:
- Запретить NTLM для отдельных серверов.
- Ввести исключения (allow list) только для критически важных устаревших систем.
- Полностью отключить NTLMv1, оставив только более защищённый v2.
Изоляция унаследованных систем. Оборудование и ПО, требующие NTLM, следует выносить в изолированные сегменты сети (VLAN) с жёстким контролем входящего и исходящего трафика. Доступ к ним должен осуществляться через шлюзы (jump-серверы), а не напрямую.
Расширенная защита аутентификации (EPA) и привязка канала (Channel Binding). Для сценариев, где NTLM пока неизбежен (например, некоторые веб-приложения), необходимо применять механизмы Extended Protection for Authentication. Они привязывают сессию аутентификации к TLS-каналу, что блокирует классические Relay-атаки.
Контроль учетных записей. Для высокопривилегированных учётных записей (администраторы домена, Enterprise Admins) необходимо применять политику, запрещающую аутентификацию с использованием NTLM в любом виде. Это резко снижает риски компрометации всей инфраструктуры через PtH.

Ключевые выводы

NTLM — это не просто устаревший протокол, это активный вектор угрозы, глубоко интегрированный в инфраструктуру. Его повсеместное использование является результатом долгосрочной обратной совместимости.

Борьба с NTLM — это не разовая операция, а постоянный процесс аудита, контроля и миграции. Основная задача — не добиться нулевого использования (что часто недостижимо), а свести его к минимально возможному уровню в строго контролируемых сегментах, одновременно выстраивая многоуровневую защиту от атак, эксплуатирующих его слабости.

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