CodeKitHubЧто это за инструмент?
NTLM (NT LAN Manager) — устаревший протокол аутентификации Microsoft по схеме «запрос-ответ», всё ещё используемый сегодня для локальных входов в Windows и в качестве резервного варианта во многих средах Active Directory. Его верификатор пароля — обычно называемый «NTLM-хешем» — определён в собственной спецификации Microsoft MS-NLMP как `MD4(UTF-16-LE(пароль))`: пароль сначала кодируется в UTF-16 little-endian (каждый символ становится 2 байтами, в отличие от UTF-8), а затем эта последовательность байт один раз хешируется алгоритмом MD4 из RFC 1320.
Шаг кодирования UTF-16LE — деталь, которую чаще всего упускают при собственной реализации NTLM: хеширование байт UTF-8 строки вместо байт UTF-16LE даёт совершенно другой, некорректный дайджест, даже если видимый текст выглядит одинаково. Этот инструмент кодирует правильно, поэтому его вывод совпадает с тем, что хранит сама Windows, и с тем, что ожидают такие инструменты, как hashcat (режим 1000) и Mimikatz.
Поскольку NTLM появился раньше современного подхода к хешированию паролей, в нём нет ни одной из защит, придуманных специально для замедления подбора: ни соли для каждого пользователя, ни настраиваемого фактора трудоёмкости, ни намеренных итераций. Это единственный проход MD4, из-за чего вычисление происходит крайне быстро — удобно для совместимости со старыми системами, но губительно с точки зрения устойчивости к перебору и словарным атакам.
Зачем его использовать?
- Вы только что извлекли партию хешей из NTDS.dit клиента в ходе санкционированного пентеста и хотите быстро проверить, что ваш собственный скрипт парсинга выдал корректный формат хеша, прежде чем скормить полный дамп в hashcat.
- Вы разрабатываете собственный инструмент аудита учётных данных и только что написали свою реализацию MD4(UTF-16LE) по спецификации MS-NLMP — вставьте сюда известный тестовый вектор вроде «password», чтобы убедиться, что вывод вашего кода совпадает с правильным значением 8846F7EAEE8FB117AD06BDD830B7586C, прежде чем доверять ему на реальных данных.
- Вы разбираете задачу CTF или домашнюю лабораторную работу по аутентификации Windows, и нужно быстро вычислить, каким должен быть NTLM-хеш конкретного пароля, не поднимая Windows-виртуалку ради одного значения.
- Вы преподаёте курс по безопасности, посвящённый слабостям устаревшей аутентификации, и хотите наглядно показать студентам, почему отсутствие соли в NTLM приводит к тому, что один и тот же пароль всегда даёт одинаковый хеш — независимо от того, какой это аккаунт или домен.
- 100% локально: ваш ввод никогда не покидает браузер, поэтому инструмент безопасен даже для чувствительных учётных данных в рамках санкционированной оценки.
Как использовать
- Введите пароль или строку, которую нужно захешировать, в поле ввода.
- Нажмите «Generate NTLM Hash».
- Прочитайте 32-символьный шестнадцатеричный NTLM-хеш (вывод в верхнем регистре включён по умолчанию — так его показывают Windows и большинство инструментов подбора; снимите галочку для нижнего регистра).
- Нажмите «Copy», чтобы скопировать хеш в буфер обмена.
Пример
Ввод
passwordРезультат
8846F7EAEE8FB117AD06BDD830B7586CЭто широко известный, независимо проверяемый тестовый вектор: NTLM-хеш строки «password» всегда равен 8846F7EAEE8FB117AD06BDD830B7586C. Вы можете сверить вывод этого инструмента с любой другой корректной реализацией NTLM.
NTLM в сравнении с современным хешированием паролей
Таблица ниже показывает, почему NTLM считается устаревшим для защиты новых систем, хотя он по-прежнему встроен в устаревшую инфраструктуру Windows и Active Directory.
| Свойство | NTLM | bcrypt / scrypt / Argon2 |
|---|---|---|
| Базовый примитив | Один проход MD4 | Специально созданный медленный хеш с настраиваемой стоимостью |
| Соль | Отсутствует — одинаковые пароли всегда дают одинаковый хеш | Уникальная случайная соль на каждый пароль |
| Итерации / растягивание | Отсутствуют | Настраиваемый фактор трудоёмкости, увеличиваемый со временем |
| Устойчивость к перебору | Очень слабая — миллиарды попыток в секунду на современных GPU | Намеренно дорогая каждая попытка |
| Где всё ещё встречается | Устаревшая аутентификация Windows, резерв Active Directory | Новые приложения, актуальная лучшая практика |
Похожие инструменты
Если вам нужен универсальный криптографический хеш, а не специфичная для NTLM конструкция MD4(UTF-16LE), эти инструменты могут подойти лучше.
→ Генератор хеша для нескольких алгоритмов · Генератор MD5 · Генератор паролей
Типичные рабочие процессы проверки NTLM
Этот инструмент наиболее полезен как быстрая проверка на здравый смысл внутри более крупного санкционированного рабочего процесса — подтверждение значения перед тем, как довериться ему в большом пайплайне, а не замена этого пайплайна целиком.
| Сценарий | Что вы проверяете | Почему это важно |
|---|---|---|
| Проверка собственного скрипта | Ваша реализация MS-NLMP против известного тестового вектора | Позволяет поймать ошибку UTF-8 против UTF-16LE до того, как она незаметно испортит весь набор данных |
| Точечная проверка выгруженного хеша | Одна извлечённая запись SAM/NTDS.dit против ожидаемого открытого текста | Подтверждает, что ваш инструмент извлечения корректно разобрал формат |
| Проверка формата hashcat/Mimikatz | Соответствие структуры вывода ожиданиям режима 1000 | Предотвращает бесполезные запуски подбора против некорректно сформированного списка хешей |
| Обучение и задачи CTF | Хеш, вычисленный вручную, против вывода инструмента | Формирует интуитивное понимание того, как на самом деле работает MS-NLMP, шаг за шагом |
Часто задаваемые вопросы
Что такое NTLM-хеш?
Это верификатор пароля, который Windows вычисляет и хранит для аутентификации NT LAN Manager; определён в спецификации Microsoft MS-NLMP как MD4(UTF-16LE(пароль)) — единственный проход MD4 по байтовому представлению пароля в UTF-16 little-endian. Всегда 128 бит, отображается как 32 шестнадцатеричных символа.
Почему именно UTF-16LE, а не UTF-8 или ASCII?
Windows хранит текст внутренне в UTF-16LE ещё со времён разработки NT, поэтому и пароли перед хешированием кодируются так же. Каждый символ становится 2 байтами (порядок little-endian), включая обычные символы ASCII вроде «a», которые превращаются в 0x61 0x00, а не просто 0x61. Хеширование байт UTF-8 той же строки даёт совершенно другой, неверный результат — это самая распространённая ошибка в реализациях NTLM «с нуля».
Безопасно ли использовать NTLM сегодня?
Нет, и сама Microsoft рекомендует переходить от него на Kerberos, где это возможно. У NTLM нет соли, поэтому одинаковые пароли всегда дают одинаковые хеши у любого пользователя и в любой системе, что делает возможным поиск по заранее вычисленным радужным таблицам. Также нет итераций или фактора трудоёмкости — единственный проход MD4 без соли, — поэтому современные GPU способны перебирать миллиарды вариантов в секунду против перехваченного хеша. NTLM держится в основном ради совместимости со старыми системами и приложениями Windows.
Чем NTLM отличается от современного хеширования паролей вроде bcrypt, scrypt или Argon2?
Современные средства хеширования паролей намеренно медленные и используют соль: bcrypt, scrypt и Argon2 добавляют уникальную случайную соль на каждый пароль и настраиваемый фактор трудоёмкости, который можно увеличивать со временем по мере роста производительности оборудования, — специально чтобы сделать перебор дорогим даже в больших масштабах. NTLM не делает ни того, ни другого — он разрабатывался в эпоху, когда офлайн-перебор ещё не был практической угрозой, и это заметно. Именно поэтому NTLM никогда не следует использовать для защиты чего-либо создаваемого сегодня; реальное назначение этого инструмента — совместимость с существующей инфраструктурой Windows и санкционированное тестирование безопасности, а не построение новых систем.
Каковы легитимные способы применения генератора NTLM-хеша?
Проверка хешей, извлечённых из базы SAM или NTDS.dit в ходе санкционированного пентеста или аудита учётных данных; проверка того, что ваши собственные инструменты или скрипты корректно реализуют MS-NLMP; генерация тестовых хешей для проверки совместимости с форматом hashcat (режим 1000) или Mimikatz в подконтрольной вам лаборатории; и выполнение упражнений CTF или учебных заданий, явно связанных с NTLM. Использование этого инструмента для атак на учётные записи или системы, которыми вы не владеете или на тестирование которых у вас нет письменного разрешения, легитимным применением не является.
Отправляется ли мой пароль или ввод на сервер?
Нет. Вычисление MD4 полностью выполняется на JavaScript в вашем браузере — нативного браузерного API для MD4 не существует, поэтому он реализован прямо в клиентском коде этой страницы, и ничто из введённого никуда не передаётся.
Обрабатывает ли этот инструмент также LM-хеш, или только NTLM?
Только NTLM. Более старый LM-хеш использует совершенно другую, более слабую схему (пароль делится на две половины по 7 символов, каждая хешируется алгоритмом DES), и Microsoft отключила хранение LM-хеша по умолчанию начиная с Windows Vista. Если вам нужно работать конкретно с устаревшими LM-хешами, потребуется отдельный инструмент, созданный именно для этого алгоритма.
Почему один и тот же ввод всегда даёт абсолютно одинаковый хеш, без какой-либо случайности?
Это ожидаемо и точно соответствует реальному поведению NTLM — у NTLM нет соли, поэтому MD4(UTF-16LE(ввод)) является чисто детерминированной функцией. Одинаковый ввод всегда даёт одинаковый вывод, и именно эта слабость делает NTLM уязвимым для атак по заранее вычисленным радужным таблицам.
Можно ли использовать это для хеширования чего-то помимо пароля, например имени пользователя или значения challenge?
Технически да — инструмент просто вычисляет MD4(UTF-16LE(ввод)) для любого введённого текста, так что он работает с любой строкой. Но если вы работаете с полным рукопожатием challenge-response NTLMv2 (которое включает NTLM-хеш плюс challenge сервера, nonce клиента и HMAC-MD5), потребуются дополнительные шаги помимо этого простого калькулятора одного хеша.
Как проверить, что вывод этого инструмента действительно корректен?
Используйте встроенный пример: NTLM-хеш строки «password» — это широко известный, независимо опубликованный тестовый вектор — 8846F7EAEE8FB117AD06BDD830B7586C. Введите его и убедитесь, что получаете точно такой же результат, а для дополнительной уверенности сверьтесь с другой доверенной реализацией, например с собственными тестовыми векторами hashcat.