НТЛМ
Набор протоколов безопасности Microsoft для аутентификации, целостности и конфиденциальности

В сети Windows NT (New Technology) LAN Manager ( NTLM ) — это набор протоколов безопасности Microsoft , предназначенных для обеспечения аутентификации, целостности и конфиденциальности для пользователей. [1] [2] [3] NTLM является преемником протокола аутентификации в Microsoft LAN Manager (LANMAN), более старом продукте Microsoft. Набор протоколов NTLM реализован в поставщике поддержки безопасности , который объединяет протокол аутентификации LAN Manager , протоколы сеансов NTLMv1, NTLMv2 и NTLM2 в одном пакете. Используются ли эти протоколы или могут ли они использоваться в системе, которая регулируется параметрами групповой политики , для которых разные версии Windows имеют разные настройки по умолчанию.

Пароли NTLM считаются слабыми, поскольку их можно очень легко подобрать с помощью современного оборудования. [4]

Протокол

NTLM — это протокол аутентификации «вызов-ответ» , который использует три сообщения для аутентификации клиента в среде с установлением соединения (без установления соединения все аналогично) и четвертое дополнительное сообщение, если требуется целостность. [5] [6] [7] [8]

  1. Сначала клиент устанавливает сетевой путь к серверу и отправляет NEGOTIATE_MESSAGE, рекламируя свои возможности. [9]
  2. Затем сервер отвечает сообщением CHALLENGE_MESSAGE, которое используется для установления личности клиента. [10]
  3. Наконец, клиент отвечает на вызов сообщением AUTHENTICATE_MESSAGE. [11]

Протокол NTLM использует одно или оба из двух хэшированных значений пароля, оба из которых также хранятся на сервере (или контроллере домена), и которые из-за отсутствия соли являются эквивалентными паролям , что означает, что если вы получаете хэш-значение с сервера, вы можете пройти аутентификацию, не зная фактического пароля. Это LM-хэш ( функция на основе DES , применяемая к первым 14 символам пароля, преобразованным в традиционную 8-битную кодировку ПК для языка) и NT-хэш ( MD4 пароля Unicode UTF-16 с прямым порядком байтов ). Оба хэш-значения имеют размер 16 байт (128 бит) каждое. [12]

Протокол NTLM также использует одну из двух односторонних функций в зависимости от версии NTLM; NT LanMan и NTLM версии 1 используют одностороннюю функцию LanMan на основе DES (LMOWF), тогда как NTLMv2 использует одностороннюю функцию на основе NT MD4 (NTOWF). [12] [13]

NTLMv1

Сервер аутентифицирует клиента, отправляя 8-байтовое случайное число, вызов. Клиент выполняет операцию, включающую вызов и секрет, общий для клиента и сервера, в частности, один из двух хэшей паролей, описанных выше. Клиент возвращает 24-байтовый результат вычисления. Фактически, в NTLMv1 вычисления обычно производятся с использованием обоих хэшей, и отправляются оба 24-байтовых результата. Сервер проверяет, что клиент вычислил правильный результат, и из этого делает вывод о владении секретом, а следовательно, и о подлинности клиента.

Оба хэша производят 16-байтовые величины. Пять байт нулей добавляются для получения 21 байта. 21 байт разделяется на три 7-байтовых (56-битовых) величины. Каждая из этих 56-битовых величин используется в качестве ключа для шифрования 64-битного вызова DES . Три шифрования вызова воссоединяются для формирования 24-байтового ответа. Как ответ с использованием LM-хеша, так и NT-хеша возвращаются в качестве ответа, но это можно настроить.

C = 8-байтовый вызов сервера, случайныйK1 | K2 | K3 = NTLM-хэш | 5-байт-0ответ = DES(K1,C) | ДЕС(К2,С) | ДЕС(К3,С)

NTLMv2

NTLMv2, представленный в Windows NT 4.0 SP4 [14] (и изначально поддерживаемый в Windows 2000), является протоколом аутентификации «вызов-ответ». Он предназначен как криптографически усиленная замена NTLMv1, повышая безопасность NTLM за счет укрепления протокола против многих атак спуфинга и добавления возможности для сервера аутентифицироваться на клиенте. [1] [15] [16]

NTLMv2 отправляет два ответа на 8-байтовый вызов сервера . Каждый ответ содержит 16-байтовый хэш HMAC - MD5 вызова сервера, полностью/частично случайно сгенерированный вызов клиента и хэш HMAC-MD5 пароля пользователя и другой идентификационной информации. Два ответа отличаются форматом вызова клиента. Более короткий ответ использует 8-байтовое случайное значение для этого вызова. Чтобы проверить ответ, сервер должен получить как часть ответа вызов клиента. Для этого более короткого ответа 8-байтовый вызов клиента, добавленный к 16-байтовому ответу, создает 24-байтовый пакет, который соответствует 24-байтовому формату ответа предыдущего протокола NTLMv1. В некоторой неофициальной документации (например, DCE/RPC Over SMB, Leighton) этот ответ называется LMv2.

Второй ответ, отправленный NTLMv2, использует вызов клиента переменной длины, который включает (1) текущее время в формате NT Time , (2) 8-байтовое случайное значение (CC2 в поле ниже), (3) доменное имя и (4) некоторые стандартные форматные данные. Ответ должен включать копию этого вызова клиента и, следовательно, имеет переменную длину. В неофициальной документации этот ответ называется NTv2.

И LMv2, и NTv2 хешируют вызов клиента и сервера с помощью NT-хеша пароля пользователя и другой идентифицирующей информации. Точная формула начинается с NT-хеша, который хранится в SAM или AD, и продолжается хешированием, используя HMAC - MD5 , имени пользователя и имени домена. В поле ниже X обозначает фиксированное содержимое поля форматирования.

SC = 8-байтовый вызов сервера, случайныйCC = 8-байтовый клиентский запрос, случайныйCC* = (X, время, CC2, доменное имя)v2-Hash = HMAC-MD5(NT-Hash, имя пользователя, доменное имя)LMv2 = HMAC-MD5(v2-хэш, SC, CC)NTv2 = HMAC-MD5(v2-хэш, SC, CC*)ответ = LMv2 | CC | NTv2 | CC*

Сессия NTLM2

Протокол сеанса NTLM2 похож на MS-CHAPv2. [17] Он состоит из аутентификации NTLMv1 в сочетании с безопасностью сеанса NTLMv2.

Вкратце, применяется алгоритм NTLMv1, за исключением того, что 8-байтовый вызов клиента добавляется к 8-байтовому вызову сервера и хэшируется MD5. Меньшая 8-байтовая половина результата хэша является вызовом, используемым в протоколе NTLMv1. Вызов клиента возвращается в одном 24-байтовом слоте ответного сообщения, 24-байтовый вычисленный ответ возвращается в другом слоте.

Это усиленная форма NTLMv1, которая сохраняет возможность использовать существующую инфраструктуру контроллера домена, но при этом избегает атаки по словарю со стороны мошеннического сервера. Для фиксированного X сервер вычисляет таблицу, где местоположение Y имеет значение K, такое что Y=DES_K(X) . Без участия клиента в выборе вызова сервер может отправить X , найти ответ Y в таблице и получить K. Эту атаку можно сделать практичной, используя радужные таблицы . [18]

Однако существующая инфраструктура NTLMv1 позволяет, чтобы пара вызов/ответ не проверялась сервером, а отправлялась на контроллер домена для проверки. Используя сеанс NTLM2, эта инфраструктура продолжает работать, если сервер заменяет вызов хэшем вызовов сервера и клиента.

NTLMv1 Клиент<-Сервер: SC Клиент->Сервер: H(P,SC) Сервер->DomCntl: H(P,SC), SC Server<-DomCntl: да или нетСессия NTLM2 Клиент<-Сервер: SC Клиент->Сервер: H(P,H'(SC,CC)), CC Сервер->DomCntl: H(P,H'(SC,CC)), H'(SC,CC) Server<-DomCntl: да или нет

Наличие и использование NTLM

С 2010 года Microsoft больше не рекомендует использовать NTLM в приложениях: [19]

Разработчики должны знать, что NTLM не поддерживает последние криптографические методы, такие как AES или SHA-256. Он использует циклические проверки избыточности (CRC) или MD5 для целостности и RC4 для шифрования.

Вывод ключа из пароля осуществляется в соответствии с RFC1320 и FIPS46-2. Поэтому приложениям обычно рекомендуется не использовать NTLM.

Несмотря на эти рекомендации, NTLM по-прежнему широко используется в системах. [ необходима цитата ] Основная причина — сохранение совместимости со старыми системами. Однако в некоторых обстоятельствах этого можно избежать. [ как? ]

Microsoft добавила хэш NTLM в свою реализацию протокола Kerberos для улучшения взаимодействия (в частности, тип шифрования RC4-HMAC). По словам независимого исследователя, это решение позволяет обмануть контроллеры домена, заставив их выдать злоумышленнику билет Kerberos, если известен хэш NTLM. [20] Microsoft приняла Kerberos в качестве предпочтительного протокола аутентификации для Windows 2000 и последующих доменов Active Directory. [16] Kerberos обычно используется, когда сервер принадлежит домену Windows Server . Microsoft рекомендует разработчикам не использовать ни Kerberos, ни поставщика поддержки безопасности NTLM (SSP) напрямую. [21]

Ваше приложение не должно напрямую обращаться к пакету безопасности NTLM; вместо этого оно должно использовать пакет безопасности Negotiate. Negotiate позволяет вашему приложению использовать преимущества более продвинутых протоколов безопасности, если они поддерживаются системами, участвующими в аутентификации. В настоящее время пакет безопасности Negotiate выбирает между Kerberos и NTLM. Negotiate выбирает Kerberos, если только он не может использоваться одной из систем, участвующих в аутентификации.

Использование поставщика поддержки безопасности NTLM

NTLM SSP используется в следующих ситуациях:

  • Клиент выполняет аутентификацию на сервере, который не принадлежит домену, или домен Active Directory не существует (обычно это называется «рабочая группа» или «одноранговая сеть»).
    • На сервере должна быть включена функция «защищенного паролем общего доступа», которая по умолчанию не включена и является взаимоисключающей с HomeGroup в некоторых версиях Windows.
    • Когда сервер и клиент принадлежат к одной и той же HomeGroup , вместо NTLM будет использоваться протокол, аналогичный Kerberos, основанный на криптографии с открытым ключом для аутентификации пользователей. [22] HomeGroup, вероятно, является самым простым способом совместного использования ресурсов в небольшой сети, требующим минимальной настройки, даже по сравнению с настройкой нескольких дополнительных пользователей для использования защищенного паролем общего доступа, что может означать, что он используется гораздо чаще, чем защищенный паролем общий доступ в небольших сетях и домашних сетях.
  • Если сервер — это устройство, поддерживающее SMB , например, устройства NAS и сетевые принтеры, NTLM SSP может предложить единственный поддерживаемый метод аутентификации. Некоторые реализации SMB или более старые дистрибутивы, например, Samba, могут заставить Windows согласовывать NTLMv1 или даже LM для исходящей аутентификации с сервером SMB, что позволяет устройству работать, хотя оно может быть загружено устаревшим, небезопасным программным обеспечением, независимо от того, является ли это новое устройство.
  • Если сервер является членом домена, но Kerberos использовать нельзя.
    • Клиент аутентифицируется на сервере, используя IP-адрес (и обратное разрешение имен недоступно)
    • Клиент проходит аутентификацию на сервере, который принадлежит другому лесу Active Directory, имеющему устаревшее доверие NTLM вместо транзитивного доверия между лесами.
    • Если в противном случае брандмауэр ограничил бы порты, требуемые Kerberos (обычно TCP 88)

Использование версий протокола

После того, как разработчик приложения или Negotiate SSP решили, что NTLM SSP будет использоваться для аутентификации, групповая политика определяет возможность использования каждого из протоколов, которые реализует NTLM SSP. Существует пять уровней аутентификации. [23]

  • Отправлять ответы LM и NTLM : клиенты используют аутентификацию LM и NTLM и никогда не используют сеансовую безопасность NTLMv2; контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправить LM и NTLM — использовать сеансовую безопасность NTLMv2, если согласовано : клиенты используют аутентификацию LM и NTLM, а также сеансовую безопасность NTLMv2, если сервер ее поддерживает; контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLM : клиенты используют только аутентификацию NTLM и используют сеансовую безопасность NTLMv2, если сервер ее поддерживает; контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLMv2 : клиенты используют только аутентификацию NTLMv2 и используют сеансовую безопасность NTLMv2, если сервер ее поддерживает; контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLMv2\отказываться от LM : клиенты используют только аутентификацию NTLMv2 и используют сеансовую безопасность NTLMv2, если сервер ее поддерживает; контроллеры домена отклоняют LM (принимают только аутентификацию NTLM и NTLMv2).
  • Отправлять только ответ NTLMv2\отклонять LM и NTLM : клиенты используют только аутентификацию NTLMv2 и используют сеансовую безопасность NTLMv2, если сервер ее поддерживает; контроллеры домена отклоняют LM и NTLM (принимают только аутентификацию NTLMv2).

DC означает контроллер домена, но использование этого термина сбивает с толку. Любой компьютер, действующий как сервер и аутентифицирующий пользователя, выполняет роль DC в этом контексте, например, компьютер Windows с локальной учетной записью, такой как Администратор, когда эта учетная запись используется во время входа в сеть.

До Windows NT 4.0 Service Pack 4 поставщик общих служб согласовывал протокол NTLMv1 и возвращался к LM, если другая машина его не поддерживала.

Начиная с Windows NT 4.0 Service Pack 4, SSP согласовывал сеанс NTLMv2 всякий раз, когда и клиент, и сервер его поддерживали. [24] Вплоть до Windows XP включительно, на компьютерах за пределами США использовалось либо 40-, либо 56-битное шифрование, поскольку в то время в США были строгие ограничения на экспорт технологий шифрования. Начиная с Windows XP SP3, 128-битное шифрование можно было добавить, установив обновление, а в Windows 7 128-битное шифрование было по умолчанию.

В Windows Vista и выше LM был отключен для входящей аутентификации. Операционные системы на базе Windows NT вплоть до Windows Server 2003 включительно хранят два хэша паролей, хэш LAN Manager (LM) и хэш Windows NT. Начиная с Windows Vista , возможность хранить оба есть, но один из них отключен по умолчанию. Это означает, что аутентификация LM больше не работает, если компьютер под управлением Windows Vista выступает в качестве сервера. Предыдущие версии Windows (вплоть до Windows NT 4.0 Service Pack 4) можно было настроить на такое поведение, но это не было значением по умолчанию. [25]

Слабости и уязвимости

NTLM остается уязвимым для атаки pass the hash , которая является вариантом атаки reflect , которая была устранена обновлением безопасности Microsoft MS08-068. Например, Metasploit может использоваться во многих случаях для получения учетных данных с одной машины, которые могут быть использованы для получения контроля над другой машиной. [3] [26] Набор инструментов Squirtle может использоваться для использования атак межсайтового скриптинга веб- сайтов в атаках на близлежащие активы через NTLM. [27]

В феврале 2010 года Amplia Security обнаружила несколько недостатков в реализации механизма аутентификации NTLM в Windows, которые нарушали безопасность протокола, позволяя злоумышленникам получать доступ на чтение/запись к файлам и удаленное выполнение кода. Одна из представленных атак включала возможность предсказывать псевдослучайные числа и запросы/ответы, генерируемые протоколом. Эти недостатки присутствовали во всех версиях Windows в течение 17 лет. Рекомендации по безопасности, объясняющие эти проблемы, включали полностью работающие эксплойты для проверки концепции. Все эти недостатки были исправлены в MS10-012. [28] [29]

В 2012 году было продемонстрировано, что каждая возможная перестановка хэша NTLM-пароля из 8 символов может быть взломана менее чем за 6 часов. [30]

В 2019 году это время сократилось примерно до 2,5 часов за счет использования более современного оборудования. [4] [31] Также доступны таблицы Rainbow для восьми- и девятисимвольных паролей NTLM. Более короткие пароли можно восстановить методом подбора. [32]

В 2019 году EvilMog [33] [34] опубликовал инструмент под названием ntlmv1-multitool [35] для форматирования ответов на вызов NTLMv1 в формате взлома, совместимом с hashcat. С hashcat и достаточной мощностью графического процессора хеш NTLM может быть получен с помощью известной атаки открытым текстом путем взлома ключей DES с режимом hashcat 14000, как продемонстрировал atom [36] на форумах hashcat.

Обратите внимание, что хэши, эквивалентные паролю, используемые в атаках pass-the-hash и взломе паролей, должны быть сначала «украдены» (например, путем взлома системы с разрешениями, достаточными для доступа к хэшам). Кроме того, эти хэши не совпадают с «хешем» NTLMSSP_AUTH, передаваемым по сети во время обычной аутентификации NTLM.

Совместимость с Linux

Реализации NTLM для Linux включают Cntlm [37] и winbind (часть Samba ) [38], которые позволяют приложениям Linux использовать прокси-серверы NTLM.

FreeBSD также поддерживает хранение паролей через Crypt (C) в незащищенной форме NT-Hash. [39]

Смотрите также

Ссылки

  1. ^ ab "Введение", Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
  2. ^ «Сведения о безопасности сеанса», Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
  3. ^ ab Takahashi, T (2009-12-17), "Reflecting on NTLM Reflection", FrequencyX Blog , IBM Internet System Security (ISS), заархивировано из оригинала 2009-12-31 , извлечено 2010-08-14
  4. ^ ab Claburn, Thomas (14 февраля 2019 г.). «Использовать 8-символьный пароль Windows NTLM? Не надо. Каждый из них можно взломать менее чем за 2,5 часа». www.theregister.co.uk . Получено 26.11.2020 .
  5. ^ "Microsoft NTLM", MSDN , Microsoft , получено 2010-08-15
  6. ^ "Синтаксис сообщения | раздел 2.2", Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
  7. ^ "Ориентированный на соединение", NT LAN Manager (NTLM) Authentication Protocol Specification (редакция 3.1.5.1), Microsoft , получено 15 августа 2010 г.
  8. ^ "Connectionless", NT LAN Manager (NTLM) Authentication Protocol Specification (редакция 3.1.5.2), Microsoft , получено 15 августа 2010 г.
  9. ^ "NEGOTIATE_MESSAGE", Спецификация протокола аутентификации NT LAN Manager (NTLM) (редакция 2.2.1.1), Microsoft , получено 15 августа 2010 г.
  10. ^ "CHALLENGE_MESSAGE", NT LAN Manager (NTLM) Authentication Protocol Specification (редакция 2.2.1.2), Microsoft , получено 15 августа 2010 г.
  11. ^ "AUTHENTICATE_MESSAGE", Спецификация протокола аутентификации NT LAN Manager (NTLM) (редакция 2.2.1.3), Microsoft , получено 15 августа 2010 г.
  12. ^ ab "NTLM v1 Authentication", NT LAN Manager (NTLM) Authentication Protocol Specification (редакция 3.3.1), Microsoft , получено 15 августа 2010 г.
  13. ^ "NTLM v2 Authentication", NT LAN Manager (NTLM) Authentication Protocol Specification (редакция 3.3.1), Microsoft , получено 15 августа 2010 г.
  14. ^ Что нового в Windows NT 4.0 Service Pack 4?
  15. ^ Как включить аутентификацию NTLM 2, Поддержка, Microsoft, 2007-01-25 , получено 2010-08-14
  16. ^ ab "Security Configuration", Руководство по усилению безопасности Microsoft Windows 2000 , TechNet, Microsoft, 24 марта 2009 г. , получено 14 августа 2010 г.
  17. ^ Гласс, Эрик, "NTLM", Дэвенпорт , Source Forge
  18. ^ Varughese, Sam (февраль 2006 г.). "Rainbow Cracking and Password Security". Palisade. Архивировано из оригинала 2010-06-01 . Получено 2010-08-14 .
  19. ^ "Security Considerations for Implementers", NT LAN Manager (NTLM) Authentication Protocol Specification , Microsoft , получено 2010-08-16
  20. ^ "Раскрытие уязвимости Active Directory: Слабое шифрование позволяет злоумышленнику изменить пароль жертвы без входа в систему - Aorato". Архивировано из оригинала 2014-10-06 . Получено 2014-10-05 .
  21. ^ "Microsoft NTLM". Библиотека TechNet . Microsoft . Получено 2 ноября 2015 г. .
  22. ^ "Обзор аутентификации пользователя между пользователями на основе криптографии с открытым ключом". Библиотека TechNet . Microsoft . Получено 2 ноября 2015 г. .
  23. ^ "Уровень аутентификации LAN Manager". Библиотека MSDN . Microsoft . Получено 2 ноября 2015 г. .
  24. ^ "Аутентификация Windows". Библиотека TechNet . Microsoft. 29 июня 2011 г. Получено 2 ноября 2015 г.
  25. ^ Йеспер Йоханссон. «Самая непонятая настройка безопасности Windows всех времен». Журнал TechNet . Microsoft . Получено 2 ноября 2015 г.
  26. ^ HD Moore. «MS08-068: Metasploit и SMB Relay».
  27. ^ Курт Груцмахер (2008-08-08). Заколотить гроб, NTLM мертв. Defcon 16.
  28. ^ Эрнан Очоа и Агустин Азубель (28.07.2010). Понимание уязвимости Windows SMB NTLM Weak Nonce (PDF) . Blackhat USA 2010.
  29. ^ Эрнан Очоа и Агустин Азубель. «Уязвимость Windows SMB NTLM Weak Nonce. Рекомендации по безопасности».
  30. ^ Гудин, Дэн (10.12.2012). «Кластер из 25 графических процессоров взламывает все стандартные пароли Windows менее чем за 6 часов». Ars Technica . Получено 23.11.2020 .
  31. ^ hashcat (13.02.2019). "настроенный вручную hashcat 6.0.0 beta и 2080Ti (стандартные частоты) преодолевают отметку скорости взлома NTLM в 100 GH/s на одном вычислительном устройстве". @hashcat . Получено 26.02.2019 .
  32. ^ Пример использования современного радужного стола
  33. ^ «Этичный хакер Дастин Хейвуд, он же EvilMog: «Моя миссия — сделать компании безопаснее». The Globe and Mail . 2019-12-09 . Получено 2023-10-12 .
  34. ^ "Дастин Хейвуд: "Злой" хакер, использующий свой нейродивергентный разум во благо". IBM Newsroom . Получено 12 октября 2023 г.
  35. ^ Хейвуд, Дастин (2023-10-11), 10 ноября, 2020 Обновления , получено 2023-10-12
  36. ^ "Как использовать режим DES KPA". hashcat.net . Получено 2023-10-12 .
  37. ^ «Cntlm: Быстрый прокси-сервер аутентификации NTLM на языке C».
  38. ^ "Аутентификация NTLM - MoodleDocs".
  39. ^ "NT MD4 password hash как новый метод шифрования паролей для FreeBSD". Mail-archive.com . Получено 2 декабря 2018 г. .
  • Онлайн взлом NTLM-хэша с использованием таблиц Rainbow
  • Спецификация протокола аутентификации NT LAN Manager (NTLM)
  • Cntlm – NTLM, NTLMSR, NTLMv2 Authentication Proxy и Accelerator Personal HTTP(S) и SOCKS5 proxy для приложений, не поддерживающих NTLM (Windows/Linux/UNIX)
  • Протокол аутентификации NTLM и поставщик поддержки безопасности Подробный анализ протокола NTLM.
  • Статья MSDN, объясняющая протокол и то, что он был переименован
  • Страница MSDN об аутентификации NTLM
  • Libntlm – бесплатная реализация.
  • Программное обеспечение прокси-сервера авторизации NTLM, позволяющее пользователям проходить аутентификацию через прокси-сервер MS.
  • Установка аутентификации NTLM – Инструкции по настройке NTLM для Samba и Midgard на Linux
  • NTLM версии 2 (NTLMv2) и параметр LMCompatibilityLevel, который им управляет
  • Jespa – Java Active Directory Integration Полный поставщик услуг безопасности NTLM с проверкой NETLOGON на стороне сервера (коммерческий, но бесплатный для 25 пользователей)
  • EasySSO — аутентификатор NTML для JIRA NTLM Authenticator, использующий библиотеку Jespa для предоставления IWA для продуктов Atlassian.
  • ntlmv2-auth API NTLMv2 и фильтр сервлетов для Java
  • Инструмент для генерации сообщений ntlm
  • WAFFLE – фреймворк аутентификации Windows Java/C#
  • objectif-securite (Радужные таблицы для ophcrack)
  • Px для Windows — HTTP-прокси-сервер для автоматической аутентификации через NTLM-прокси
  • NTLMv1 Multi Tool — инструмент для форматирования ответов на вызовы NTLMv1 в формат, который можно взломать с помощью hashcat.
Взято с "https://en.wikipedia.org/w/index.php?title=NTLM&oldid=1250242422#NTLMv2"