Введение
Responder является широко используемым инструментом в сценариях тестирования на проникновение и может использоваться для бокового перемещения по сети сотрудниками Red Team. Инструмент содержит множество полезных функций, таких как отравление LLMNR, NT-NS и MDNS. Он используется в практических сценариях для таких целей, как захват хэшей или пересылка отравленных ответов, поддерживающих различные атаки AD. Инструмент содержит различные встроенные серверы, такие как HTTP, SMB, LDAP, сервер аутентификации DCE-RPC и т. д. В этой статье мы рассмотрим большинство этих атак, которые могут быть выполнены при помощи респондента.
LLMNR, NBT-NS, MDNS и DHCP
LLMNR: LLMNR — это протокол, который позволяет разрешать имена без использования DNS-сервера. Он может предоставить имя хоста для IP на основе многоадресного пакета, отправленного по сети, с просьбой ответить всем прослушивающим сетевым интерфейсам, если они официально известны как имя хоста в запросе. Он делает это, отправляя сетевой пакет на порт UDP 5355 на многоадресный сетевой адрес. Он позволяет использовать хосты IPv4 и IPv6 и поддерживает все текущие и будущие форматы, типы и классы DNS. Это преемник NBT-NS.
NBT-NS: Служба имен NetBIOS (NBT-NS) — это протокол Windows, который используется для преобразования имен NetBIOS в IP-адреса в локальной сети. Это аналогично тому, что DNS делает в Интернете. Каждому компьютеру служба NBT-NS назначает имя NetBIOS. Работает через UDP-порт 137. Это предшественник LLMNR.
MDNS:
Многоадресный DNS (mDNS) — это протокол, предназначенный для помощи в разрешении имен в сетях. Он не запрашивает сервер имен, а, скорее, выполняет многоадресную рассылку запросов всем клиентам в сети напрямую. В многоадресной рассылке отдельное сообщение адресовано непосредственно группе получателей. Когда соединение между отправителем и получателем установлено, все участники информируются о связи между именем и IP-адресом и могут сделать соответствующую запись в своем кэше mDNS.
LLMNR/NBT-NS отравление: Допустим, жертва хочет подключиться к общему диску \\wow и отправляет запрос на DNS-сервер. Единственная проблема в том, что DNS не может подключиться к \\wow, так как его не существует. Поэтому сервер отвечает, что не может подключить жертву к \\wow. После этого жертва будет рассылать этот запрос по всей сети (используя LLMNR), если какой-либо конкретный пользователь знает маршрут к общему диску (\\wow).
Злоумышленник может подделать авторитетный источник для разрешения имени, ответив на этот многоадресный запрос жертвы, как если бы он знал идентификатор общего диска, к которому жертва хочет подключиться, и, в свою очередь, запросив его хэш NTLM. Это означает, что теперь злоумышленник отравил сервис!
Отравление DHCP: Протокол Dynamic Host Client Protocol (DHCP) используется для предоставления хосту его IP-адреса, маски подсети, шлюза и т. д. Windows использует несколько настраиваемых параметров DHCP, таких как NetBIOS, WPAD и т. д. Отравляя ответ DHCP, злоумышленник сможет помочь жертве определить свой собственный мошеннический сервер для любой аутентификации. В свою очередь, компрометация учетных данных.
Установка респондера
Первоначально разработанный SpiderLabs, а теперь разрабатываемый Лораном Гаффи (lgandx), респондер представляет собой инструмент, написанный на Python, который можно найти здесь (https://github.com/lgandx/Responder). Инструмент поставляется со встроенной ОС Kali. Responder.exe (версия для Windows) можно найти здесь (https://github.com/lgandx/Responder-Windows).
Его можно запустить с помощью команды:
responder -h
Атака 1: отравление LLMNR/NBT-NS через SMB
По сути, когда система пытается получить доступ к общему ресурсу SMB, она отправляет запрос на DNS-сервер, который затем преобразует имя общего ресурса в соответствующий IP-адрес, и запрашивающая система может получить к нему доступ. Однако, если указанное имя общего ресурса не существует, система отправляет запрос LLMNR по всей сети. Таким образом, если какой-либо пользователь (IP-адрес) имеет доступ к этому общему ресурсу, он может ответить и предоставить сообщение запрашивающей стороне.
Давайте посмотрим на шару "wow", которой в настоящее время не существует. Если общий ресурс существует в той же сети, к wow можно получить доступ, набрав "\\ wow" в адресной строке проводника. Его не существует, поэтому Windows выдает ошибку.
Запускаем респондер. В этот момент запрашивающая машина (Windows 10) отправляет запрос LLMNR. Мы настраиваем ответчик, чтобы отравить этот запрос. Нам нужно сообщить ответчику сетевой адаптер, на котором мы хотим прослушивать запросы LLMNR.Вот, eth0. Запуск ответчика по умолчанию должен запускать отравление LLMNR и NBT-NS по умолчанию.
responder -I eth0
Теперь, когда жертва пытается получить доступ к общему диску, "wow" она видит это! Wow внезапно стал доступен, и отравитель запросил учетные данные пользователя.
"wow" вообще недоступен! Это просто наш отравленный ответ, чтобы получить хэши NTLM. Даже если пользователь не введет учетные данные, хэши будут получены.
Теперь мы можем сохранить эти хеши в файле hash.txt и использовать hashcat для его взлома. Обратите внимание, что модуль номер 5600 подходит для взлома NTLMv2. Если вы получили какую-либо другую версию NTLM, следуйте приведенным здесь модулям hashcat, чтобы указать правильную версию.
hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt
Как видите, теперь получен пароль: Password@1.
Кроме того, респондер создает журналы каждой сессии, и все сброшенные таким образом хэши можно увидеть в папке /usr/share/responder/logs.
Атака 2: отравление LLMNR/NBT-NS через WPAD
WPAD: Протокол автообнаружения веб-прокси — это метод, используемый браузером для автоматического обнаружения и взаимодействия со службами кэширования в сети для быстрой доставки информации. WPAD по умолчанию использует DHCP для поиска службы кэширования, чтобы упростить подключение и разрешение имен.
В организации, использующей сервер WPAD, предоставьте каждому браузеру одинаковые конфигурации прокси-сервера, используя файл с именем wpad.dat. Следовательно, любой запрос, поступающий из любого браузера в домене компании, сначала находит wpad.dat, затем считывает конфигурацию и, наконец, отправляет запрос по назначению.
Когда в браузер вводится недопустимый URL-адрес, браузер не может загрузить эту страницу с помощью DNS и, следовательно, отправляет запрос LLMNR для поиска прокси-сервера WPAD. Такое поведение по умолчанию присутствует в браузерах, в которых включено "автоматическое определение конфигурации" — опция, часто используемая в корпоративных сетях для маршрутизации трафика через прокси. Затем он запрашивает wpad.dat, который содержит данные автоматической настройки прокси.
Ответчик (отравитель LLMNR) создает мошеннический прокси-сервер WPAD, отравляет запрос и сообщает браузеру, что у него есть файл wpad.dat, и запрашивает аутентификацию. Когда пользователь вводит свои учетные данные, хэши проходят через злоумышленника!
Атака: Чтобы настроить мошеннический прокси-сервер WPAD, мы используем параметр -w. Кроме того, мы добавили опциональный параметр DHCP-инъекции. Этот параметр будет вводить адрес мошеннического прокси-сервера (kali IP) в ответ DHCP. Атака могла работать и без этого параметра.
responder -I eth0 -wd
Как вы можете видеть выше, отравитель DHCP и прокси-сервер WPAD теперь включены. Теперь, когда пользователь вводит какой-либо неверный URL-адрес, скажем, randomurl.local, браузер не может его найти. Ответчик отравляет и вводит ответ DHCP с IP-адресом WPAD, а браузер пытается аутентифицироваться на сервере WPAD и выдает запрос на вход.
Как только клиент вводит свои учетные данные, мы получаем их хэши NTLM!
Это тоже можно посмотреть в логах, но на этот раз под названием HTTP-NTLMV2-IPV6.txt format\
Мы можем взломать его с помощью hashcat прямо сейчас.
Хэш был взломан, а текстовый пароль сброшен!
Режим анализа респондента
В режиме анализа ответчик не отравляет запросы LLMNR автоматически, а отслеживает сетевой поток запросов, сделанных для предоставления важной информации, такой как имя пользователя, используемая учетная запись компьютера, имя контроллера домена, версия ОС и т. д. Его можно включить с помощью опции -A
responder -I eth0 -A
Когда жертва пытается получить доступ к неправильному имени общего ресурса (метод атаки 1), ответчик анализирует весь поток и сообщает нам имя контроллера домена, версию ОС Windows и т. д.
Базовый режим аутентификации ответчика
Во второй атаке мы видели, как открывались окна аутентификации NTLM, когда к нашему мошенническому прокси-серверу WPAD обращались, отравляя LLMNR. В свою очередь, мы смогли получить хэши NTLMv2. Мы сымитируем ту же атаку, но на этот раз попробуем получить учетные данные пользователя открытым текстом, используя базовую аутентификацию! Этого можно добиться с помощью флага -b. Кроме того, мы используем опцию -F для принудительной базовой аутентификации!
responder -I eth0 -wdF -b
Теперь, когда пользователь пытается получить доступ к любому недопустимому URL-адресу, он видит следующую подсказку с сообщением о том, что эти учетные данные будут отправлены в виде открытого текста с использованием базовой аутентификации.
Как только пользователь вводит свои учетные данные, ответчик получает их и отображает пароль открытым текстом!
Даунгрейд респондера NTLMv2-SSP до NTLMv2
NTLM обеспечивает функциональность ESS (Extended Session Security), которая усложняет хэш NTLM. Функциональность ESS добавляет флаг "SSP" в хэш NTLM (NTLM2-SSP). Это увеличивает длину нашего хэша NTLM, что, в свою очередь, увеличивает сложность взлома хэша. Мы можем настроить Responder для использования простого NTLMv2 (без ESS), что приведет к снижению временной сложности взлома хэшей.
Флаг --disable-ess делает это. Флаг –lm пытается принудительно использовать для проверки подлинности NTLM версию 1 вместо 2, что невозможно в более поздних версиях Windows и Windows Server. Здесь мы будем использовать процедуру Attack 2 с флагом disable-ess.
responder -I eth0 -wdF --lm --disable-ess
Это даст пользователю всплывающее окно
Как только Муфаса введет свои учетные данные, мы увидим, что теперь получена более ранняя версия хэша NTLMv2.
Её можно взломать с помощью hashcat, и вы заметите, что это заняло 3 секунды по сравнению с 7 секундами в Атаке 2 (вполовину меньше, чем раньше)!
Отравление внешнего IP-адреса ответчика
Responder можно использовать для отправки зараженных запросов LLMNR жертве, которая содержит IP-адрес, отличный от того, который мы используем в настоящее время. Это создает скрытность и позволяет нам проводить более изощренные атаки. Это можно сделать с помощью опции "-e"
responder -I eth0 -e 192.168.1.2
Responder multi-relay: оболочка в системе
Ретрансляция является одним из наиболее часто используемых методов доступа к учетным данным. Ретранслятор или сервер пересылки получают действительную аутентификацию, а затем пересылают этот запрос на другой сервер/систему и пытаются аутентифицироваться на этом сервере/системе, используя полученные таким образом действительные учетные данные. В атаке 1 мы использовали недопустимый общий ресурс SMB для получения хэшей запрашивающей системы.
Что, если респондер был администратором?
Конечно, мы можем получить его учетные данные и подождать, пока hashcat взломает их, или быть умнее и использовать relay для пересылки этой аутентификации на желаемый хост и получить на нем оболочку напрямую!
Для этого lgandx включил скрипт MultiRelay.py в папку /usr/share/Responder/tools. Нам нужно установить несколько зависимостей и собрать вспомогательные двоичные файлы, которые будут работать в системе-жертве и предоставить нам обратную оболочку.
Как только это будет сделано, мы можем запустить MultiRelay.py без каких-либо ошибок или предупреждений.
Итак, первым критерием для работы этой атаки с SMB является то, что подписывание SMB должно быть отключено. По умолчанию он отключен, чтобы проверить нашу легкость использования. Его можно протестировать с помощью скрипта nmap smb-security-mode.
nmap -p445 --script=smb-security-mode 192.168.1.3
Как видите, подписывание SMB отключено. Теперь мы можем запустить MultiRelay. Чтобы запустить его, нам нужно указать цель, используя "-t", а "-u" указывает пользователей, на какой релей они должны быть перенаправлены. Вы также можете выбирать выборочно и создавать меньший шум в сети.
python3 MultiRelay.py -t 192.168.1.3 -u ALL
Как вы можете видеть выше, скрипт обнаружил ОС моей жертвы, имя учетной записи компьютера (workstation01) и статус подписи SMB. Еще одна вещь, которую следует отметить, это то, что этот скрипт использует порты HTTP и SMB. Итак, чтобы предотвратить конфликт, нам нужно отключить эти серверы в файле responseer.conf. Мы просто открываем файл в /usr/share/responder/Responder.conf и отключаем HTTP и SMB. Если все сделано правильно, когда мы в следующий раз запустим ответчик, то там должен быть такой переключатель OFF.
Теперь, согласно методологии атаки 1, мы запускаем ответчик:
responder -I eth0
Теперь администратор пытается открыть общий диск. Он терпит неудачу, так как шара wowowow не существует! Итак, ответчик вмешивается и успешно отравляет запросы.
В Атаке 1, у нас был сервер SMB, работающий в ответчике, поэтому жертва аутентифицировала нас, и мы смогли увидеть креды. Здесь ретрансляция SMB настроена в MultiRelay.py, поэтому учетные данные теперь пересылаются нашей жертве "192.168.1.3", и мы успешно получаем на ней оболочку! Мы также получили привилегию NT AUTHORITY. Это возможно, потому что у администратора были необходимые права на C$, а скомпилированный ранее двоичный файл был загружен, запущен и дал нам оболочку. Это также можно сделать, чтобы получить доступ к учетной записи с более низким уровнем приватности.
Внедрение DNS ответчика в ответ DHCP
В случае, когда DHCP используется для идентификации IP-адреса, на котором размещен, скажем, SMB-диск под названием "wow " (см. атаку 1), отвечающая сторона также может внедрить мошенническую запись DNS в ответы DHCP.
У ответчика настроен мошеннический DNS-сервер. По сути, любая жертва, пытающаяся получить доступ к фальшивому общему диску, пытается разрешить имя, найдя правильный DNS-сервер. DHCP пытается определить IP-адрес, находя правильный DNS-сервер. Он отправляет запрос. Ответчик отвечает на запрос DHCP и вводит IP-адрес своего DNS-сервера в ответ DHCP, успешно отравляя ответ DHCP. Жертва получает это, видит IP-адрес нашего DNS-сервера и пытается получить доступ к общему ресурсу "wow ", подключившись к нам. Теперь жертва аутентифицируется на нашем мошенническом DNS-сервере, а не отбрасывает запрос.
Инъекцию DHCP-DNS можно настроить с помощью опции "-D":
responder -I eth0 -D
Когда жертва получает доступ к любому недействительному общему ресурсу, теперь отображается подсказка.
Хэши NTLM были успешно получены путем внедрения нашего мошеннического IP-адреса DNS-сервера!
Что это за серверы в ответчике?
Ответчик поддерживает несколько серверов, как показано ниже на снимке экрана. Это мошеннические серверы, которые могут способствовать одной или нескольким атакам.
При сканировании nmap видим, что серверы работоспособны
Например, в приведенной выше демонстрации требовался IP-адрес DNS-сервера, поэтому отвечающая сторона создала мошеннический DNS-сервер и добавила свой собственный IP-адрес, чтобы облегчить отравление DHCP-DNS. Точно так же SMB-сервер захватывает учетные данные для аутентификации непосредственно жертвы при доступе к общему ресурсу на нашей машине Kali.
Например так:
Ответчик успешно захватывает хэши NTLM
Здесь также указан FTP-сервер. Давайте попробуем получить к нему доступ через браузер жертвы.
Как видите, получаются анонимные учетные данные. Обратите внимание, что при доступе к нему с помощью браузера также могут быть указаны действительные имя пользователя и пароль, которые будут получены в виде открытого текста.
Там же есть RDP-сервер. Позволяет получить к нему доступ с машины жертвы.
После ввода учетных данных мы получаем успешно хэши NTLMv2.
Также предоставляется сервер WinRM. Это протокол, используемый для удаленного взаимодействия PowerShell. Итак, если жертва подключается к этому мошенническому серверу WinRM следующим образом:
New-PSSession -ComputerName 192.168.1.4 -Credential (get-credential)
Таким образом получается хэш!
В ЧЕМ СМЫСЛ?
Часто в сценариях пентеста для проведения бокового перемещения нам необходимо скомпрометировать учетные данные. Отправка вредоносных вложений со ссылками на наши мошеннические серверы может заставить пользователя пройти аутентификацию и, следовательно, предоставить нам свои учетные данные. В качестве альтернативы мы можем использовать ретрансляцию (инструментарий Impacket) для проведения различных других атак. Например, в этой статье мы провели ретрансляцию LDAP с использованием скрипта ntlmrelay impacket и отравление с помощью респондента для захвата рабочих станций.
Рекомендации
Для предотвращения продемонстрированных выше атак рекомендуется следующее:
- Отключите LLMNR и NBT-NS в политике компьютера → конфигурация компьютера → шаблоны администратора → сеть
- Если организация не может его отключить, она должна установить контроль доступа к сети
- Используйте надежные пароли пользователей.
- Чтобы защититься от атаки WPAD, вы можете добавить запись для "wpad" в свою зону DNS, чтобы LLMNR не отправлялся.
- Используйте подпись SMB для предотвращения ретрансляционных атак SMB.
Вывод
В статье были рассмотрены различные полезные атаки, которые можно выполнить с помощью Responder. Инструмент написан на Python и, следовательно, не зависит от платформы. Красные команды широко используют этот инструмент для бокового движения. Цель статьи — служить готовым справочником, когда речь заходит об использовании респондента в сценариях пентеста. Надеюсь, вам понравилась статья. Спасибо за чтение.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://www.hackingarticles.in/a-detailed-guide-on-responder-llmnr-poisoning/
Responder является широко используемым инструментом в сценариях тестирования на проникновение и может использоваться для бокового перемещения по сети сотрудниками Red Team. Инструмент содержит множество полезных функций, таких как отравление LLMNR, NT-NS и MDNS. Он используется в практических сценариях для таких целей, как захват хэшей или пересылка отравленных ответов, поддерживающих различные атаки AD. Инструмент содержит различные встроенные серверы, такие как HTTP, SMB, LDAP, сервер аутентификации DCE-RPC и т. д. В этой статье мы рассмотрим большинство этих атак, которые могут быть выполнены при помощи респондента.
LLMNR, NBT-NS, MDNS и DHCP
LLMNR: LLMNR — это протокол, который позволяет разрешать имена без использования DNS-сервера. Он может предоставить имя хоста для IP на основе многоадресного пакета, отправленного по сети, с просьбой ответить всем прослушивающим сетевым интерфейсам, если они официально известны как имя хоста в запросе. Он делает это, отправляя сетевой пакет на порт UDP 5355 на многоадресный сетевой адрес. Он позволяет использовать хосты IPv4 и IPv6 и поддерживает все текущие и будущие форматы, типы и классы DNS. Это преемник NBT-NS.
NBT-NS: Служба имен NetBIOS (NBT-NS) — это протокол Windows, который используется для преобразования имен NetBIOS в IP-адреса в локальной сети. Это аналогично тому, что DNS делает в Интернете. Каждому компьютеру служба NBT-NS назначает имя NetBIOS. Работает через UDP-порт 137. Это предшественник LLMNR.
MDNS:
Многоадресный DNS (mDNS) — это протокол, предназначенный для помощи в разрешении имен в сетях. Он не запрашивает сервер имен, а, скорее, выполняет многоадресную рассылку запросов всем клиентам в сети напрямую. В многоадресной рассылке отдельное сообщение адресовано непосредственно группе получателей. Когда соединение между отправителем и получателем установлено, все участники информируются о связи между именем и IP-адресом и могут сделать соответствующую запись в своем кэше mDNS.
LLMNR/NBT-NS отравление: Допустим, жертва хочет подключиться к общему диску \\wow и отправляет запрос на DNS-сервер. Единственная проблема в том, что DNS не может подключиться к \\wow, так как его не существует. Поэтому сервер отвечает, что не может подключить жертву к \\wow. После этого жертва будет рассылать этот запрос по всей сети (используя LLMNR), если какой-либо конкретный пользователь знает маршрут к общему диску (\\wow).
Злоумышленник может подделать авторитетный источник для разрешения имени, ответив на этот многоадресный запрос жертвы, как если бы он знал идентификатор общего диска, к которому жертва хочет подключиться, и, в свою очередь, запросив его хэш NTLM. Это означает, что теперь злоумышленник отравил сервис!
Отравление DHCP: Протокол Dynamic Host Client Protocol (DHCP) используется для предоставления хосту его IP-адреса, маски подсети, шлюза и т. д. Windows использует несколько настраиваемых параметров DHCP, таких как NetBIOS, WPAD и т. д. Отравляя ответ DHCP, злоумышленник сможет помочь жертве определить свой собственный мошеннический сервер для любой аутентификации. В свою очередь, компрометация учетных данных.
Установка респондера
Первоначально разработанный SpiderLabs, а теперь разрабатываемый Лораном Гаффи (lgandx), респондер представляет собой инструмент, написанный на Python, который можно найти здесь (https://github.com/lgandx/Responder). Инструмент поставляется со встроенной ОС Kali. Responder.exe (версия для Windows) можно найти здесь (https://github.com/lgandx/Responder-Windows).
Его можно запустить с помощью команды:
responder -h
Атака 1: отравление LLMNR/NBT-NS через SMB
По сути, когда система пытается получить доступ к общему ресурсу SMB, она отправляет запрос на DNS-сервер, который затем преобразует имя общего ресурса в соответствующий IP-адрес, и запрашивающая система может получить к нему доступ. Однако, если указанное имя общего ресурса не существует, система отправляет запрос LLMNR по всей сети. Таким образом, если какой-либо пользователь (IP-адрес) имеет доступ к этому общему ресурсу, он может ответить и предоставить сообщение запрашивающей стороне.
Давайте посмотрим на шару "wow", которой в настоящее время не существует. Если общий ресурс существует в той же сети, к wow можно получить доступ, набрав "\\ wow" в адресной строке проводника. Его не существует, поэтому Windows выдает ошибку.
Запускаем респондер. В этот момент запрашивающая машина (Windows 10) отправляет запрос LLMNR. Мы настраиваем ответчик, чтобы отравить этот запрос. Нам нужно сообщить ответчику сетевой адаптер, на котором мы хотим прослушивать запросы LLMNR.Вот, eth0. Запуск ответчика по умолчанию должен запускать отравление LLMNR и NBT-NS по умолчанию.
responder -I eth0
Теперь, когда жертва пытается получить доступ к общему диску, "wow" она видит это! Wow внезапно стал доступен, и отравитель запросил учетные данные пользователя.
"wow" вообще недоступен! Это просто наш отравленный ответ, чтобы получить хэши NTLM. Даже если пользователь не введет учетные данные, хэши будут получены.
Теперь мы можем сохранить эти хеши в файле hash.txt и использовать hashcat для его взлома. Обратите внимание, что модуль номер 5600 подходит для взлома NTLMv2. Если вы получили какую-либо другую версию NTLM, следуйте приведенным здесь модулям hashcat, чтобы указать правильную версию.
hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt
Как видите, теперь получен пароль: Password@1.
Кроме того, респондер создает журналы каждой сессии, и все сброшенные таким образом хэши можно увидеть в папке /usr/share/responder/logs.
Атака 2: отравление LLMNR/NBT-NS через WPAD
WPAD: Протокол автообнаружения веб-прокси — это метод, используемый браузером для автоматического обнаружения и взаимодействия со службами кэширования в сети для быстрой доставки информации. WPAD по умолчанию использует DHCP для поиска службы кэширования, чтобы упростить подключение и разрешение имен.
В организации, использующей сервер WPAD, предоставьте каждому браузеру одинаковые конфигурации прокси-сервера, используя файл с именем wpad.dat. Следовательно, любой запрос, поступающий из любого браузера в домене компании, сначала находит wpad.dat, затем считывает конфигурацию и, наконец, отправляет запрос по назначению.
Когда в браузер вводится недопустимый URL-адрес, браузер не может загрузить эту страницу с помощью DNS и, следовательно, отправляет запрос LLMNR для поиска прокси-сервера WPAD. Такое поведение по умолчанию присутствует в браузерах, в которых включено "автоматическое определение конфигурации" — опция, часто используемая в корпоративных сетях для маршрутизации трафика через прокси. Затем он запрашивает wpad.dat, который содержит данные автоматической настройки прокси.
Ответчик (отравитель LLMNR) создает мошеннический прокси-сервер WPAD, отравляет запрос и сообщает браузеру, что у него есть файл wpad.dat, и запрашивает аутентификацию. Когда пользователь вводит свои учетные данные, хэши проходят через злоумышленника!
Атака: Чтобы настроить мошеннический прокси-сервер WPAD, мы используем параметр -w. Кроме того, мы добавили опциональный параметр DHCP-инъекции. Этот параметр будет вводить адрес мошеннического прокси-сервера (kali IP) в ответ DHCP. Атака могла работать и без этого параметра.
responder -I eth0 -wd
Как вы можете видеть выше, отравитель DHCP и прокси-сервер WPAD теперь включены. Теперь, когда пользователь вводит какой-либо неверный URL-адрес, скажем, randomurl.local, браузер не может его найти. Ответчик отравляет и вводит ответ DHCP с IP-адресом WPAD, а браузер пытается аутентифицироваться на сервере WPAD и выдает запрос на вход.
Как только клиент вводит свои учетные данные, мы получаем их хэши NTLM!
Это тоже можно посмотреть в логах, но на этот раз под названием HTTP-NTLMV2-IPV6.txt format\
Мы можем взломать его с помощью hashcat прямо сейчас.
Хэш был взломан, а текстовый пароль сброшен!
Режим анализа респондента
В режиме анализа ответчик не отравляет запросы LLMNR автоматически, а отслеживает сетевой поток запросов, сделанных для предоставления важной информации, такой как имя пользователя, используемая учетная запись компьютера, имя контроллера домена, версия ОС и т. д. Его можно включить с помощью опции -A
responder -I eth0 -A
Когда жертва пытается получить доступ к неправильному имени общего ресурса (метод атаки 1), ответчик анализирует весь поток и сообщает нам имя контроллера домена, версию ОС Windows и т. д.
Базовый режим аутентификации ответчика
Во второй атаке мы видели, как открывались окна аутентификации NTLM, когда к нашему мошенническому прокси-серверу WPAD обращались, отравляя LLMNR. В свою очередь, мы смогли получить хэши NTLMv2. Мы сымитируем ту же атаку, но на этот раз попробуем получить учетные данные пользователя открытым текстом, используя базовую аутентификацию! Этого можно добиться с помощью флага -b. Кроме того, мы используем опцию -F для принудительной базовой аутентификации!
responder -I eth0 -wdF -b
Теперь, когда пользователь пытается получить доступ к любому недопустимому URL-адресу, он видит следующую подсказку с сообщением о том, что эти учетные данные будут отправлены в виде открытого текста с использованием базовой аутентификации.
Как только пользователь вводит свои учетные данные, ответчик получает их и отображает пароль открытым текстом!
Даунгрейд респондера NTLMv2-SSP до NTLMv2
NTLM обеспечивает функциональность ESS (Extended Session Security), которая усложняет хэш NTLM. Функциональность ESS добавляет флаг "SSP" в хэш NTLM (NTLM2-SSP). Это увеличивает длину нашего хэша NTLM, что, в свою очередь, увеличивает сложность взлома хэша. Мы можем настроить Responder для использования простого NTLMv2 (без ESS), что приведет к снижению временной сложности взлома хэшей.
Флаг --disable-ess делает это. Флаг –lm пытается принудительно использовать для проверки подлинности NTLM версию 1 вместо 2, что невозможно в более поздних версиях Windows и Windows Server. Здесь мы будем использовать процедуру Attack 2 с флагом disable-ess.
responder -I eth0 -wdF --lm --disable-ess
Это даст пользователю всплывающее окно
Как только Муфаса введет свои учетные данные, мы увидим, что теперь получена более ранняя версия хэша NTLMv2.
Её можно взломать с помощью hashcat, и вы заметите, что это заняло 3 секунды по сравнению с 7 секундами в Атаке 2 (вполовину меньше, чем раньше)!
Отравление внешнего IP-адреса ответчика
Responder можно использовать для отправки зараженных запросов LLMNR жертве, которая содержит IP-адрес, отличный от того, который мы используем в настоящее время. Это создает скрытность и позволяет нам проводить более изощренные атаки. Это можно сделать с помощью опции "-e"
responder -I eth0 -e 192.168.1.2
Responder multi-relay: оболочка в системе
Ретрансляция является одним из наиболее часто используемых методов доступа к учетным данным. Ретранслятор или сервер пересылки получают действительную аутентификацию, а затем пересылают этот запрос на другой сервер/систему и пытаются аутентифицироваться на этом сервере/системе, используя полученные таким образом действительные учетные данные. В атаке 1 мы использовали недопустимый общий ресурс SMB для получения хэшей запрашивающей системы.
Что, если респондер был администратором?
Конечно, мы можем получить его учетные данные и подождать, пока hashcat взломает их, или быть умнее и использовать relay для пересылки этой аутентификации на желаемый хост и получить на нем оболочку напрямую!
Для этого lgandx включил скрипт MultiRelay.py в папку /usr/share/Responder/tools. Нам нужно установить несколько зависимостей и собрать вспомогательные двоичные файлы, которые будут работать в системе-жертве и предоставить нам обратную оболочку.
Как только это будет сделано, мы можем запустить MultiRelay.py без каких-либо ошибок или предупреждений.
Итак, первым критерием для работы этой атаки с SMB является то, что подписывание SMB должно быть отключено. По умолчанию он отключен, чтобы проверить нашу легкость использования. Его можно протестировать с помощью скрипта nmap smb-security-mode.
nmap -p445 --script=smb-security-mode 192.168.1.3
Как видите, подписывание SMB отключено. Теперь мы можем запустить MultiRelay. Чтобы запустить его, нам нужно указать цель, используя "-t", а "-u" указывает пользователей, на какой релей они должны быть перенаправлены. Вы также можете выбирать выборочно и создавать меньший шум в сети.
python3 MultiRelay.py -t 192.168.1.3 -u ALL
Как вы можете видеть выше, скрипт обнаружил ОС моей жертвы, имя учетной записи компьютера (workstation01) и статус подписи SMB. Еще одна вещь, которую следует отметить, это то, что этот скрипт использует порты HTTP и SMB. Итак, чтобы предотвратить конфликт, нам нужно отключить эти серверы в файле responseer.conf. Мы просто открываем файл в /usr/share/responder/Responder.conf и отключаем HTTP и SMB. Если все сделано правильно, когда мы в следующий раз запустим ответчик, то там должен быть такой переключатель OFF.
Теперь, согласно методологии атаки 1, мы запускаем ответчик:
responder -I eth0
Теперь администратор пытается открыть общий диск. Он терпит неудачу, так как шара wowowow не существует! Итак, ответчик вмешивается и успешно отравляет запросы.
В Атаке 1, у нас был сервер SMB, работающий в ответчике, поэтому жертва аутентифицировала нас, и мы смогли увидеть креды. Здесь ретрансляция SMB настроена в MultiRelay.py, поэтому учетные данные теперь пересылаются нашей жертве "192.168.1.3", и мы успешно получаем на ней оболочку! Мы также получили привилегию NT AUTHORITY. Это возможно, потому что у администратора были необходимые права на C$, а скомпилированный ранее двоичный файл был загружен, запущен и дал нам оболочку. Это также можно сделать, чтобы получить доступ к учетной записи с более низким уровнем приватности.
Внедрение DNS ответчика в ответ DHCP
В случае, когда DHCP используется для идентификации IP-адреса, на котором размещен, скажем, SMB-диск под названием "wow " (см. атаку 1), отвечающая сторона также может внедрить мошенническую запись DNS в ответы DHCP.
У ответчика настроен мошеннический DNS-сервер. По сути, любая жертва, пытающаяся получить доступ к фальшивому общему диску, пытается разрешить имя, найдя правильный DNS-сервер. DHCP пытается определить IP-адрес, находя правильный DNS-сервер. Он отправляет запрос. Ответчик отвечает на запрос DHCP и вводит IP-адрес своего DNS-сервера в ответ DHCP, успешно отравляя ответ DHCP. Жертва получает это, видит IP-адрес нашего DNS-сервера и пытается получить доступ к общему ресурсу "wow ", подключившись к нам. Теперь жертва аутентифицируется на нашем мошенническом DNS-сервере, а не отбрасывает запрос.
Инъекцию DHCP-DNS можно настроить с помощью опции "-D":
responder -I eth0 -D
Когда жертва получает доступ к любому недействительному общему ресурсу, теперь отображается подсказка.
Хэши NTLM были успешно получены путем внедрения нашего мошеннического IP-адреса DNS-сервера!
Что это за серверы в ответчике?
Ответчик поддерживает несколько серверов, как показано ниже на снимке экрана. Это мошеннические серверы, которые могут способствовать одной или нескольким атакам.
При сканировании nmap видим, что серверы работоспособны
Например, в приведенной выше демонстрации требовался IP-адрес DNS-сервера, поэтому отвечающая сторона создала мошеннический DNS-сервер и добавила свой собственный IP-адрес, чтобы облегчить отравление DHCP-DNS. Точно так же SMB-сервер захватывает учетные данные для аутентификации непосредственно жертвы при доступе к общему ресурсу на нашей машине Kali.
Например так:
Ответчик успешно захватывает хэши NTLM
Здесь также указан FTP-сервер. Давайте попробуем получить к нему доступ через браузер жертвы.
Как видите, получаются анонимные учетные данные. Обратите внимание, что при доступе к нему с помощью браузера также могут быть указаны действительные имя пользователя и пароль, которые будут получены в виде открытого текста.
Там же есть RDP-сервер. Позволяет получить к нему доступ с машины жертвы.
После ввода учетных данных мы получаем успешно хэши NTLMv2.
Также предоставляется сервер WinRM. Это протокол, используемый для удаленного взаимодействия PowerShell. Итак, если жертва подключается к этому мошенническому серверу WinRM следующим образом:
New-PSSession -ComputerName 192.168.1.4 -Credential (get-credential)
Таким образом получается хэш!
В ЧЕМ СМЫСЛ?
Часто в сценариях пентеста для проведения бокового перемещения нам необходимо скомпрометировать учетные данные. Отправка вредоносных вложений со ссылками на наши мошеннические серверы может заставить пользователя пройти аутентификацию и, следовательно, предоставить нам свои учетные данные. В качестве альтернативы мы можем использовать ретрансляцию (инструментарий Impacket) для проведения различных других атак. Например, в этой статье мы провели ретрансляцию LDAP с использованием скрипта ntlmrelay impacket и отравление с помощью респондента для захвата рабочих станций.
Рекомендации
Для предотвращения продемонстрированных выше атак рекомендуется следующее:
- Отключите LLMNR и NBT-NS в политике компьютера → конфигурация компьютера → шаблоны администратора → сеть
- Если организация не может его отключить, она должна установить контроль доступа к сети
- Используйте надежные пароли пользователей.
- Чтобы защититься от атаки WPAD, вы можете добавить запись для "wpad" в свою зону DNS, чтобы LLMNR не отправлялся.
- Используйте подпись SMB для предотвращения ретрансляционных атак SMB.
Вывод
В статье были рассмотрены различные полезные атаки, которые можно выполнить с помощью Responder. Инструмент написан на Python и, следовательно, не зависит от платформы. Красные команды широко используют этот инструмент для бокового движения. Цель статьи — служить готовым справочником, когда речь заходит об использовании респондента в сценариях пентеста. Надеюсь, вам понравилась статья. Спасибо за чтение.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://www.hackingarticles.in/a-detailed-guide-on-responder-llmnr-poisoning/
