ntlm2 аутентификация что это
NTLM и корпоративные сети
Введение
Когда, полтора десятка лет назад, компания Microsoft начала серьезную работу над созданием централизованных сетей масштабов предприятия при работе над операционной системой Windows NT, перед разработчиками была поставлена весьма сложная, и новая по тем временам задача – реализовать технологии single sign-on, и One user – one password.
One user – one password (один пользователь – один пароль) означает, что у пользователя должен быть только один пароль. Единый пароль используется для доступа ко всем ресурсам и протоколам сети. Single sign-on (единый вход) подразумевает, что этот пароль указывается всего один раз – при входе пользователя в сеть.
Можно много спорить о преимуществах и недостатках такого подхода, но бесспорно одно – этот подход удобен как для пользователей, так и для разработчиков приложений. Пользователь избавлен от необходимости помнить много паролей и вводить их, а разработчику не надо задумываться над тем, как организовать аутентификацию пользователя.
Для этого необходимо было разработать такую схему аутентификации, которая позволила бы любому сетевому приложению передавать данные аутентификации независимо от сетевого протокола. Так родился NTLM и NTLMSSP (NTLM Security Service Provider) – подсистема позволяющая любому клиент-серверному приложению использовать NTLM ничего не зная о его внутренней структуре.
Нельзя сказать, чтобы Microsoft проигнорировал требования безопасности для протокола аутентификации. В общем-то, на тот момент протокол NTLM не был слабее многих уже использовавшихся протоколов, и в чем-то даже лучше. Но сейчас можно с уверенностью сказать, что вместе с протоколом NTLM появилось большое количество проблем связанных с его безопасностью. Часть проблем вызвана тем, что Microsoft должен был сохранить совместимость с существующими сетями LanManager для MS-DOS и Windows for Workgroups. Другие являются ошибками дизайна и объясняются новизной решаемой проблемы. Третьи являются исключительно криптографическими, т.к. тогда производители ПО редко имели в штате профессиональных криптоаналитиков.
Проблемы протокола NTLM широко дискутировались начиная с 1995 года и обсуждаются до сих пор. Существует ошибочное мнение, что протокол аутентификации Kerberos v5, используемый в сетях Windows 2000 и Windows 2003, полностью снимает проблему NTLM. Это не так, т.к. поддержка NTLM в существующих сетях Windows является обязательной и любая из сторон, принимающих участие в процессе аутентификации, может инициировать использование этого протокола. По этой причине многие проблемы протокола NTLM остаются актуальными в современных сетях Windows и должны учитываться не только в процессе администрирования сети, но и на этапе ее проектирования.
Я попытался собрать в одном месте информацию, мысли, идеи и проблемы, родившиеся в результате почти десятилетней дискуссии в открытых списках рассылки, а так же личной переписки со многими людьми, которым мне хотелось бы выразить признательность за их помощь, ответы на вопросы и терпение – Urity (urity at securityfriday.com), Jesper Johansson (jesperjo at microsoft.com), Solar Designer (solar at openwall.com), offtopic (offtopic at mail.ru) Glenn Zorn (gzorn at cisco.com) и многим другим. Так же использовались материалы из постингов Todd Sabin, Luke Kenneth Casson Leighton и Salman Niksefat. Из-за природной лени и отсутствия точных названий и постоянных URL для большинства использованных постингов я не буду делать список литературы в конце статей, пусть это сделает Google.
Мы не будем углубляться в технические детали более, чем это необходимо для понимания проблемы, тем не менее, иногда от читателя потребуются некоторые минимальные представления о процессах аутентификации и авторизации, программировании и криптографии. Чтобы облегчить жизнь читателю, в статье будут встречаться вставки «общеобразовательного» характера.
Процесс аутентификации клиент-серверных приложений в сетях Microsoft
Что происходит после нажатия на Ctrl+Alt+Del? Появляется запрос локальной подсистемы безопасности (Local Security Authority, LSA) на ввод имени пользователя и пароля. После ввода пароль хэшируется (криптографический хэш – одностороннее преобразование делающее невозможным, или по крайней мере сложным восстановление по нему оригинального пароля) и хэш помещается в хранилище LSA. В открытом виде он больше уже нигде не фигурирует (в старых версиях Windows пароль мог храниться в открытом виде или с обратимым шифрованием, т.к. старые версии LanManager использовали аутентификацию в открытом тексте, но не будем вспоминать эти времена). Кроме того, к хранилищу LSA нельзя обратиться напрямую стандартными методами. В хранилище хэши находятся до окончания сеанса работы (а иногда и после, это будет рассмотрено далее).
Протокол NTLM относится к семейству challenge-response (запрос-ответ) протоколов. Это означает, что ни пароль ни его хэш никогда не передаются «как есть», вместо этого они используются для генерации ответа (response) на случайный запрос (challenge). Аутентифицирующая сторона сравнивает полученный ответ с вычисленным локально. Генерация и проверка запроса и ответа осуществляется не приложениями, а провайдером NTLMSSP. Данные аутентификации, генерируемые NTLMSSP через специальные функции API (InitializeSecurityContext()/AcceptSecurityContext()) могут быть включены в любой протокол прикладного уровня, упаковка этих данных (называемых security blob – «начинка безопасности») это все, что требуется от приложений с точки зрения NTLMSSP. После успешной проверки подсистема безопасности генерирует токен, который может быть использован серверным приложением с правами локальной системы для имперсонирования пользователя, т.е. при подключении пользователя к серверному приложению серверное приложение может работать от его имени. В таком случае пользователь совершает вход на удаленную систему. Возникает вопрос – а может ли серверное приложение обратиться к другим сетевым ресурсам с использованием NTLM, не запрашивая дополнительной аутентификации? Если в хранилище LSA удаленного компьютера нет хэшей пароля пользователя – то это невозможно. Отсюда, например, невозможность «прозрачного» доступа к сетевому диску из telnet-сеанса или через Web-сервер если доступ через telnet или к Web происходит с NTLM аутентификацией.
Теоретически все получается замечательно и абсолютно безопасно. Даже запустив приложение с правами пользователя, все равно не возможно получить его пароль или даже хэш. И даже перехватив сеанс и подменив сервер, не получится получить доступ к другим сетевым ресурсам.
Давайте посмотрим на все это с точки зрения реализации.
В семействе протоколов NTLM (как мы увидим далее, NTLM-подобных протоколов несколько) могут использоваться 2 типа хэшей: LM (LanManager) хэш, унаследованный от предыдущих реализаций LanManager и NT (New Technology) хэш, созданный для протокола NTLM. Соответственно, при входе пользователя в систему, как правило, от пароля берутся и хранятся оба этих хэша. Первая версия протокола NTLM для совместимости поддерживала оба ключа (NT или LM ключем обычно называют соответствующий хэш пароля). В более поздних реализациях используется только NT ключ, однако по-умолчанию LM хэш все равно создается при входе и помещается в хранилище LSA. Давайте рассмотрим оба алгоритма хэширования.
LM ключ получается из пароля в 8-битной OEM кодировке (cp866 для России) с помощью алгоритма DES.
Для справки: DES является симметричным блочным шифром, использующим 56 битный ключ для шифрования 64 битного блока текста. Реально, внутри алгоритма используется 64 битный ключ, однако длина ключа искусственно занижена по непонятным соображениям – 56 битный ключ «растягивается» за счет вставки дополнительного бита через каждые 7 бит ключа. Поскольку DES обладает относительной стойкостью к атакам известного открытого текста, он может быть использован в качестве криптографической хэш функции, если в качестве открытого текста использовании какой-либо известный текст, а в качестве ключа – хэшируемое слово. Известный текст может быть либо случайным (в таком случае он называется salt – соль, и хранится в месте с паролем), либо предопределенным, в таком случае он называется Magic Word – заклинание. В классической реализации crypt() в Unix использовался первый подход, в Windows используется магическое слово KGS!@#$% (посмотрите на клавиатуру…. Наверное, это был чей-то пароль). При использовании в качестве хэш функции DES генерирует 64 битный хэш по 56 битному тексту.
Поскольку DES позволяет получить хэш лишь от 7-символьного блока, то реально используется пароль из 14 символов (более короткий пароль дополняется нулями), который разбивается на два блока по 7 символов, от каждого из которых независимо вычисляется хэш. В итоге получается 128-битный хэш «склееный» из двух частей.
Недостатки алгоритма очевидны. Независимое вычисление двух блоков позволяет и их независимый взлом, т.е. реально каждый 64 бита хэша можно атаковать с целью восстановления пароля. Причем для генерации LM ключа пароль не чувствителен к регистру символов и символы всегда используются в верхнем реестре. Это делает очень эффективной атаку на восстановление пароля методом последовательного перебора (не более 7 символов из очень ограниченного алфавита). Причем длинный пароль может быть легче восстановить чем более короткий. Например, для пароля из 12 символов, сначала за считанные секунды подбираются последние 5 символов, после чего делается предположение о структуре пароля и первые 7 символов пароля подбираются по более ограниченному алфавиту. В настоящее время известны очень быстрые реализации DES с использованием 64-битной арифметики, что делает его абсолютно непригодным для криптографии. В общем случае, восстановление пароля по LM хэшу на современной технике вопрос не более чем нескольких дней. Кроме того, фиксированное магическое слово позволяет использование таблицы заранее посчитанных значений ключей, что делает возможным восстановление пароля по LM хэшу в реальном времени.
NT ключ вычисляется с помощью стандартного алгоритма хэширования MD4. Хэш MD4 берется от пароля записанного в 16-битной кодировке Unicode с последовательностью байт low endian (т.е. первым байтом идет номер символа в странице). Пароль вычисляется с учетом регистра. MD4 имеет несколько криптографических проблем, самой большой из них является маленькое время вычисления хэша, что позволяет перебирать достаточно большое количество комбинаций в единицу времени упрощая, например, атаку по словарю или подбор слабой комбинации символов.
Подсказка: существует большое количество программ для восстановления пароля из NT или LM ключа путем подбора по словарю или перебора – John-the-Ripper, LophtCrack, Cain & Abel. При наличии обоих ключей, обычно сначала восстанавливается пароль в верхнем регистре из LM-ключа, затем по NT-ключу восстанавливается регистр пароля. Такой подход, в частности, реализован в Cain & Abel (http://www.oxid.it), являющейся на сегодня наиболее мощным и универсальным инструментом для выполнения различных задач связанных с обнаружением слабых конфигураций, в т.ч. и многих проблем NTLM. Мы еще неоднократно будем возвращаться к возможностям этой утилиты. Самая быстрая реализация алгоритма DES ориентированная на взлом LM-ключей в Solar Designer’овском John-the-Ripper.
Совет: Можно запретить генерацию LM-ключей в системе путем установки в 1 значения NoLmHash в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Несмотря на то, что будет описано ниже, сделать это настоятельно рекомендуется, хотя бы для очистки совести.
Кому нужен сломанный ключ?
Как мы уже говорили, NT и LM ключи (хэши) генерируются из пароля при входе пользователя в систему, после чего пароль нигде не хранится и никогда не используется. Возникает закономерный вопрос: если у нас есть на руках NT и LM хэши можем ли мы использовать их, например, для аутентификации по сети без восстановления пароля в открытом тексте? Очевидно, да. Начнем с простого случая открытых кодов. Попробуем модифицировать smbclient из состава SAMBA таким образом, чтобы подключаться к удаленному файловому серверу с исопльзованием NT хэша (как мы знаем, из NT хэша восстановить пароль гораздо сложнее). Было бы достаточно сложно перелопатить полтора десятка мегабайт исходников SAMBA, если бы мы не знали точно, что NT ключ это MD4 хэш. Нам будет достаточно только модифицировать библиотеку md4.c таким образом, чтобы не хэшировать что-то, что уже похоже на хэш. Например то, что состоит из 32х 16-ричных символов (как мы помним, ключ 128-битный, а пароль приходит в кодировке Unicode, т.е. каждый входящий символ занимает 2 байта, получается 64 байта на входе и 16 на выходе).
— md4.c.orig 2004-04-04 11:37:00.000000000 +0400
+++ md4.c 2004-10-27 23:01:31.000000000 +0400
+ unsigned char * hexd = (unsigned char *)»0123456789ABCDEF»;
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Взлом сетевой аутентификации Windows
Аутентификация в Windows по сети
В Windows реализовано много разнообразных протоколов аутентификации и различных сетевых служб.
Самые распространённые примеры сетевой аутентификации Windows это:
Для входа на другие компьютеры в сети Windows используются такие методы аутентификации как NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP — думаю, даже пользователям Windows с многолетним стажем эти термины непонятны. В этой статье с помощью программы Responder мы будем перехватывать хеши, используемые при аутентификации в Windows. Программа Responder весьма эффективна и для базового использования не требует знания и понимания методов аутентификации и сетевых служб Windows. Поэтому мы начнём с практики — с перехвата хеша аутентификации и его расшифровки, благодаря чему получим имя пользователя и пароль в операционных системах Windows. Тем не менее в конце статьи будет дана характеристика способов аутентификации и сетевых служб.
Кстати про сетевые службы. Responder использует принципы атаки «человек-посередине», когда атакующий выступает в роле посредника, ретранслятора процесса аутентификации между жертвой и сервером. Responder вместо привычного и хорошо знакомого многих ARP спуфинга эксплуатирует такие сетевые службы Windows как: LLMNR, NBT-NS и MDNS. Опять же, далеко не всем знакомы эти термины и принципы работы этих служб, но, к счастью, Responder и не требует их глубокого понимания, а их краткая характеристика также будет в конце статьи.
Responder это инструмент для выполнения атаки человек-посередине в отношении методов аутентификации в Windows. Эта программа включает в себя травитель LLMNR, NBT-NS и MDNS благодаря которому перенаправляется трафик с запросами и хешами аутентификации. Также в программу встроены жульнические серверы аутентификации HTTP/SMB/MSSQL/FTP/LDAP, которые поддерживают такие методы аутентификации как NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP и базовую HTTP аутентификацию, для которых Responder выполняет роль ретранслятора.
Итак, Responder умеет перенаправлять трафик жертвы на компьютер атакующего и выступает посредником во время аутентификации пользователя. Также Responder имеет встроенные сервера аутентификации.
Сбор информации о компьютерах Windows и их сетевых службах в локальной сети
Перед запуском полноценной атаки, давайте хотя бы вскользь начнём знакомство с некоторыми сетевыми службами Windows.
У Responder есть модуль Режима анализа. Этот модуль позволяет вам видеть NBT-NS, BROWSER, LLMNR, DNS запросы в сети без их травления какими либо ответами. Также вы можете пассивно составить карту доменов, серверов MSSQL и рабочих станций, увидеть, будет ли атака ICMP Редиректы иметь успех в вашей сети.
То есть мы сможем видеть сообщения сетевых служб Windows, но не будет отправлять в ответ на них фальшивые ответы для перенаправления трафика — мы будем только наблюдать.
Режим анализа включается опцией -A. Также в своих командах я буду использовать опцию -v для более подробного вывода.
Ещё нужно указать имя сетевого интерфейса — имена всех сетевых интерфейсов на своём компьютере можно посмотреть командой
Интерфейс нужно указывать с опцией -I, я буду использовать сетевой интерфейс с именем wlo1, следовательно, моя команда следующая:
На первом экране нам показана сводка, какие именно травители, сервера аутентификации и опции включены:
Рассмотрим некоторые записи:
Подтверждает, что Responder в режиме анализа и на запросы NBT-NS, LLMNR, MDNS не будут отправляться спуфленные данные для выполнения перенаправления трафика.
В следующей записи
говориться, что в этой сети будет работать ICMP Redirect.
В следующей записи:
говориться, что получен запрос от протокола NBT-NS. Слово ignoring говорит о том, что никаких действий предпринято не было — то есть атакующим не был отправлен ответ.
Информация о запросе по протоколу LLMNR:
В следующих строках:
говориться, что благодаря устаревшему протоколу LANMAN обнаружена рабочая группа с именем WORKGROUP, и что в этой рабочей группе найдены следующие рабочие станции и серверы: HACKWARE-MIAL, HACKWARE-SERVER, RT-N66U, VYACHESLAV — это имена компьютеров Windows в сети.
Пример записи о поступившем запросе по протоколу MDNS:
Для остановки программы нажмите CTRL+c.
Перехват имени пользователя и пароля Windows по сети
Теперь приступим к захвату хеша и затем его расшифровке.
Запускаем responder с набором опций -r -P -v -f, также указываем опцию -I с именем сетевого интерфейса:
Далее атака не требует каких-либо действий с нашей стороны.
Фраза Poisoned answer sent to означает, что был отправлен спуфленный ответ на запрос, результатом которого должно стать перенаправление трафика через наш компьютер. Примеры для всех трёх протоколов:
Пример удачно перехваченного хеша:
Из этих строк следует, что при подключении пользователя к сетевой общей папке по протоколу SMB использовалась аутентификация по протоколу NTLMv2-SSP. Имя компьютера HACKWARE-MIAL, а имя пользователя MiAl. Также дан перехваченный хеш, при расшифровке которого мы получим пароль пользователя.
Анализ результатов responder
Необязательно следить за выводом в консоль и копировать из неё хеши — все данные сохраняются в логи.
Файлы журналов располагаются в папке «logs/«. Хеши будут сохранены и напечатаны только один раз на одного пользователя на один тип хеша. Будет выведен каждый хеш, если вы используете Вербальный режим, то есть если вы указали опцию -v.
Вся активность будет записана в файл Responder-Session.log
Режим анализа запишет свой журнал в Analyze-Session.log
Травление будет записано в файл Poisoners-Session.log
В Kali Linux и BlackArch эти файлы размещены в директории /usr/share/responder/logs/.
можно вывести краткий итог полученных данных: имена компьютеров и имена пользователей.
покажет захваченные хеши.
Обратите внимание, NTLMV2 хеши перечислены после фразы
А NTLMv1 идут после фразы NTLMv1:
Некоторые хеши начинаются на имя пользователя, а затем через два двоеточия идёт имя компьютера:
В некоторых хешах после имени пользователя идёт имя рабочей группы — видимо, в том случае, если не получилось определить имя компьютера:
Для аккаунтов Microsoft в качестве имени пользователя указывается email, а затем через два двоеточия идёт срока «MicrosoftAccount»:
Как взломать хеш NTLMv1/NTLMv2/LMv2
Нам необходимо взломать следующий хеш:
На странице примера хешей, хеш NetNTLMv1 / NetNTLMv1+ESS (режим hashcat 5500) показан так:
А NetNTLMv2 (режим hashcat 5600) показан так:
Мой хеш заметно длиннее, и хотя responder-dumphash поместила этот хеш в группу NTLMV2, у меня возникли некоторые сомнения.
Проверяем ещё одной программой:
То есть всё таки это хеш NetNTLMv2, режим Hashcat равен 5600.
Hashcat поддерживает следующие родственные хеши:
Для запуска атаки по маске для взлома NetNTLMv2 в Hashcat нужно выполнить команду вида:
Пример моей реальной команды:
Обратите внимание на запредельную скорость брутфорса этого алгоритма: 276.9 MH/s. За примерно 0 секунд (программа не показывает доли секунды) перебрано 9,375,744 паролей. Это результат на ноуте с GeForce GTX 1050 Ti — на настольных компьютерах с топовой видеокартой результаты будут ещё более впечатляющими. Можно констатировать — если хеш перехвачен, то он практически наверняка будет взломан, причём довольно быстро.
Для взлома NTLMv2 по словарю в Hashcat запустите команду вида:
Новое в этой команде:
Проблемы запуска responder
check permissions or other servers running
При запуске Режима анализа вы могли увидеть на скриншоте надпись:
Дело в том, что Responder для выполнения функций ретранслятора прослушивает ряд портов, а именно следующие порты: UDP 137, UDP 138, UDP 53, UDP/TCP 389,TCP 1433, UDP 1434, TCP 80, TCP 139, TCP 445, TCP 21, TCP 3141,TCP 25, TCP 110, TCP 587, TCP 3128 и Multicast UDP 5553.
Соответственно, эти порты не должны быть заняты. У меня был запущен веб-сервер, который прослушивал 80й порт, поэтому и возникла эта ошибка. Убедитесь, что в вашей системе все эти порты свободны.
Если на вашей системе запущена Samba, остановите smbd и nmbd и все другие службы, прослушивающие указанные порты.
В Ubuntu по умолчанию запущена служба, которая прослушивает 53 порт, для исправления откройте для редактирования файл /etc/NetworkManager/NetworkManager.conf и закомментируйте строку:
Затем остановите dnsmasq командой:
ValueError: invalid literal for int() with base 10
Если в /etc/resolv.conf в качестве DNS серверов указаны IPv6 адреса, например:
то при запуске Responder в режиме анализа, например:
Для её исправления откройте файл LLMNR.py (в Kali Linux и в BlackArch этот файл размещён по пути /usr/share/responder/poisoners/LLMNR.py), найдите там строку
и замените её на строку:
Продвинутые возможности Responder
Мы рассмотрели такую функцию Responder как перехват хеша аутентификации. У программы имеются и другие функции и, возможно, будет написана вторая часть этой инструкции. Вы можете самостоятельно ознакомится с другими опциями и инструментами входящими в Responder на странице https://kali.tools/?p=1679
Изменить настройки программы вы можете в файле /usr/share/responder/Responder.conf
Сетевые технологии Windows
Протоколы аутентификации Windows
NTLMv1
NTLM (NT LAN Manager) — протокол сетевой аутентификации, разработанный фирмой Microsoft для Windows NT.
NTLM — это результат дальнейшего развития LANMAN.
Никакой официальной информации о нём не поступало, но многое выяснила группа разработчиков Samba во время разработки своей программы.
Для передачи на сервер аутентификации (англ. Primary Domain Controler (PDC) — главный контроллер домена) имени пользователя, хэша пароля и мандата домена в Windows 98 применяется протокол LANMAN, а в Windows NT — протокол NTLM. Windows 2000 и Windows XP по умолчанию делают попытку аутентификации Kerberos (только в случае, когда станция является членом домена), в то же время они сохраняют обратную совместимость с аутентификацией NTLM.
1. Пользователь устанавливает подключение(сетевой путь) к серверу и отправляет NEGOTIATE_MESSAGE со своими возможностями.
2. Сервер отвечает сообщением CHALLENGE_MESSAGE, которое используется для идентификации (установления личности) клиента.
3. Клиент отвечает на сообщение при помощи AUTHENTICATE_MESSAGE.
Протокол NTLM использует одно или оба значения хешированных паролей, оба из них хранятся на сервере (или контроллере домена), которые из-за отсутствия привязки эквивалентны паролю. Это означает, что хешированное значение с сервера может быть использовано для аутентификации без фактического знания пароля. Эти два значения представляют собой LM Hash (функции, основанные на стандарте шифрования данных для первых 14 символов пароля преобразованные в традиционную 8 битную кодировку для языка ПК) и NT Hash (значение функции MD4 от переведенного в кодировку little endian UTF-16 Unicode пароля). Оба хеша имеют длину в 16 байт (128 бит) каждый.
Протокол NTLM использует одну из двух односторонних функций, зависящих от версии NTLM. NT LanMan и NTLM версии 1 используют функцию LanMan на основе стандартного шифрования данных (LMOWF), в то время как NTLMv2 использует одностороннюю функцию NT MD4 (NTOWF[1][2]).
Проверка подлинности NTLM по-прежнему поддерживается и обязательна для использования на системах, работающих под управлением Windows NT Server 4.0 или более ранних версий, а также для компьютеров, настроенных как члены рабочих групп. Проверка подлинности NTLM также используется для проверки подлинности при аутентификации на изолированных системах. Начиная с Windows 2000, проверка подлинности Kerberos версии 5 является предпочтительным методом проверки подлинности для сред Active Directory.
NTLMv2
NTLMv2 (NTLM версии 2) — встроенный в операционные системы семейства Microsoft Windows протокол сетевой аутентификации. Широко применяется в различных сервисах на их базе. Изначально был предназначен для повышения безопасности аутентификации путём замены устаревших LM и NTLM v1. NTLMv2 был введён начиная с Windows NT 4.0 SP4 и используется версиями Microsoft Windows вплоть до Windows 10 включительно. С самого изобретения протоколы NTLMv1 и NTLMv2 подвергались множеству нападений и демонстрировали широкий спектр серьёзных уязвимостей.
В схеме аутентификации, реализованной при помощи SMB или SMB2 сообщений, вне зависимости от того, какой вид диалекта аутентификации будет использован (LM, LMv2, NTLM, NTLM2, NTLMv2), процесс аутентификации происходит следующим образом:
LMv2
LM-хеш, или LAN Manager хеш, — один из форматов, используемых Microsoft LAN Manager и версиями Microsoft Windows до Windows Vista для хранения пользовательских паролей длиной менее 15 символов. Это единственный вид хеширования, используемый в Microsoft LAN Manager, откуда и произошло название, и в версиях Windows до Windows Me. Он также поддерживается и более поздними версиями Windows для обратной совместимости, хотя в Windows Vista его приходится включать вручную.
Эволюция алгоритмов аутентификации LM и NTLM: LM → LMv2 → NTLM → NTLM2 → NTLMv2
Сетевые службы Windows
Теперь рассмотрим сетевые службы Windows, эксплуатируя которые становится возможным выполнить перенаправление трафика на компьютер атакующего.
LLMNR
Link-Local Multicast Name Resolution (LLMNR) — это протокол, основанный на формате пакета системы доменных имён (DNS), который позволяет хостам как IPv4, так и IPv6 выполнять разрешение имён для хостов на одном и том же локальном канале. Он включён в Windows Vista, Windows Server 2008, Windows 7, Windows 8 и Windows 10. Он также реализован с помощью systemd-resolved в GNU/Linux.
Отвечая на запросы, респонденты прослушивают порт UDP 5355 по следующему адресу многоадресной рассылки:
Ответчики также прослушивают TCP-порт 5355 по одноадресному (unicast) адресу, который хост использует для ответа на запросы.
NBT-NS
NBT-NS это NetBIOS-NS, то есть NetBIOS Name Service.
NetBIOS Name Service является одним из трёх сервисов NetBIOS: служба имён (NetBIOS-NS) для регистрации и разрешения имён. Подробности смотрите в статье NetBIOS: что это, как работает и как проверить.
Чтобы начать сеансы или распространять дейтаграммы, приложение должно зарегистрировать своё имя NetBIOS, используя службу имён. Имена NetBIOS имеют длину 16 октетов и различаются в зависимости от конкретной реализации. Часто 16-й октет, называемый суффиксом NetBIOS, обозначает тип ресурса и может использоваться для сообщения другим приложениям, какой тип услуг предлагает система. В NBT служба имён работает на UDP-порту 137 (TCP-порт 137 также может использоваться, но редко задействуется).
Примитивы службы имён, предлагаемые NetBIOS:
Разрешение имён NetBIOS не поддерживается Microsoft для Интернет-протокола версии 6 (IPv6).
MDNS
Multicast DNS — это Многоадресный DNS.
В компьютерных сетях протокол многоадресной DNS (mDNS) разрешает имена хостов в IP-адреса в небольших сетях, которые не включают локальный сервер имён. Это сервис с нулевой конфигурацией, использующий по существу те же программные интерфейсы, форматы пакетов и рабочую семантику, что и одноадресная система доменных имён (DNS). Хотя Стюарт Чешир разработал mDNS как самостоятельный протокол, он может работать совместно со стандартными DNS-серверами.
Протокол mDNS опубликован как RFC 6762, использует пакеты многоадресного протокола дейтаграмм пользователя (UDP) и используется пакетами программного обеспечения Apple Bonjour и Avahi с открытым исходным кодом. Android содержит реализацию mDNS. mDNS также был реализован в Windows 10, первоначально применение ограничивалось обнаружением сетевых принтеров, впоследствии стал способным также разрешать имена хостов.
mDNS может работать в сочетании с DNS Service Discovery (DNS-SD), сопутствующим методом нулевой конфигурации.
Когда клиенту mDNS необходимо разрешить имя хоста, он отправляет сообщение запроса в многоадресной IP рассылке, в которой просит хост, имеющий это имя, идентифицировать себя. Затем этот целевой компьютер многоадресно передаёт сообщение, которое включает его IP-адрес. Все машины в этой подсети могут затем использовать эту информацию для обновления своих кэшей mDNS. Любой хост может отказаться от своей заявки на имя, отправив ответный пакет с временем жизни (TTL), равным нулю.
Серверы Windows
HTTP
MSSQL
Система управления базами данных.
Протокол обеспечивающий работу файлового сервера.
LDAP
LDAP (англ. Lightweight Directory Access Protocol — «легкорасширяемый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.