**Responder - методы компрометации сетей в организациях**

---
## NBT-NS/LLMNR poisoning

### Теория разрешения имен в Windows

**LLMNR: LLMNR** — это протокол, позволяющий разрешать имена без использования DNS-сервера. Он может предоставить имя хоста для IP на основе многоадресного пакета, отправленного по сети, с просьбой ответить всем прослушивающим сетевым интерфейсам, если они официально известны как имя хоста в запросе. Он делает это, отправляя сетевой пакет на порт UDP 5355 на многоадресный сетевой адрес. Он позволяет использовать хосты IPv4 и IPv6 и поддерживает все текущие и будущие форматы, типы и классы DNS. Это преемник NBT-NS.


Распространенным случаем является использование LLMNR для разрешения имен в локальной ссылке путем отправки DNS-запросов. В этом случае компьютер с запрошенным именем должен ответить. Но, конечно же, на запрос может ответить кто угодно, даже злоумышленник для проведения атаки PitM. Это одна из тактик, используемых responder и Inveigh для сбора хэшей NTLM в сетях с компьютерами Windows.

**NBT-NS:** служба имен NetBIOS (NBT-NS) — это протокол Windows, который используется для преобразования имен NetBIOS в IP-адреса в локальной сети. Это аналогично тому, что DNS делает в Интернете. Каждому компьютеру служба NBT-NS назначает имя NetBIOS. Он разделен на три службы: одну, службу имен NetBIOS, используемую для разрешения имен NetBIOS, и две службы, дейтаграмму и сеанс NetBIOS, для передачи сообщений (аналогично TCP и UDP).

**Служба датаграмм NetBIOS:**

Служба датаграмм NetBIOS или NetBIOS-DGM или NBDGM аналогична UDP. Он используется в качестве транспортного уровня для прикладных протоколов, требующих связи без установления соединения. Сервер будет прослушивать порт 138/UDP.
Служба сеансов NetBIOS

**Служба сеансов NetBIOS:**

или NetBIOS-SSN или NBSSN аналогичны TCP. Его можно использовать в качестве транспорта для связи, ориентированной на подключение. Он использует порт 139/TCP.

**Служба имен NetBIOS:**

С точки зрения пентеста, возможно, наиболее интересной службой NetBIOS является NBNS (служба имен NetBIOS), которая прослушивает порт 137/UDP. Эта услуга позволяет:

- преобразовать имя NetBIOS в IP-адрес;
- узнавать статус узла NetBIOS;
- регистрировать/освобождать имя NetBIOS.


**MDNS:** Multicast DNS (mDNS) — это протокол, предназначенный для помощи в разрешении имен в сетях. Он не запрашивает сервер имен, а, скорее, выполняет многоадресную рассылку запросов всем клиентам в сети напрямую. В многоадресной рассылке отдельное сообщение адресовано непосредственно группе получателей. Когда соединение между отправителем и получателем установлено, все участники информируются о связи между именем и IP-адресом и могут сделать соответствующую запись в своем кэше mDNS.

В сети Windows компьютеры прослушивают порт 5353/UDP, и для разрешения имени клиент отправляет запрос mDNS на многоадресный адрес 224.0.0.251 (FF02::FB в IPv6). Запросы соответствуют формату DNS и могут использоваться для запроса не только имен, но и любых других вопросов, поддерживаемых DNS.


Распространенным случаем является использование mDNS для разрешения имен в локальной ссылке путем отправки DNS-запросов. В этом случае компьютер с запрошенным именем должен ответить, отправив ответ на многоадресный адрес 224.0.0.251, таким образом, любой компьютер в сети может получить ответ и кэшировать его. Но, конечно же, на запрос может ответить кто угодно, даже злоумышленник для проведения MITM-атаки. Это одна из тактик, используемых responder и Inveigh для сбора хэшей NetNTLM в сетях с компьютерами Windows.

**Отравление LLMNR/NBT-NS:** Допустим, жертва хочет подключиться к общему диску \\\\wow и отправляет запрос на DNS-сервер. Единственная проблема в том, что DNS не может подключиться к \\\\wow, так как его не существует. Поэтому сервер отвечает, что не может подключить жертву к \\\\wow. После этого жертва будет рассылать этот запрос по всей сети (используя LLMNR), если какой-либо конкретный пользователь знает маршрут к общему диску (\\\\wow).

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

DNS
mDNS
LLMNR
NBNS

### Запуск responder

> sudo responder -I eth0
>
Опции:

**--version** показать номер версии программы и выйти
**-h, --help** показать сообщение справки и выйти
**-A, --analyze** Режим анализа. Эта опция позволяет вам видеть NBT-NS,
BROWSER, LLMNR запросы без фальшивых ответов на них.
**-I eth0, --interface=eth0** Сетевой интерфейс для использования, вы можете использовать 'ALL' чтобы выбрать все интерфейсы
**-i 10.0.0.21, --ip=10.0.0.21** Локальный IP для использования (только для OSX)
**-e 10.0.0.22, --externalip=10.0.0.22** Травить все запросы с другого IP адреса нежели адрес Responder'а.
**-b, --basic** Вернуть Basic HTTP аутентификацию. По умолчанию: NTLM
**-r, --wredir** Включить ответы для запросов суффиксов netbios wredir. Ответы на wredir весьма вероятно поломают всё в сети. По умолчанию: False
**-d, --NBTNSdomain** Включить ответы для запросов суффиксов домена netbios. Ответ на доменные суффиксы весьма вероятно поломают всё в сети. По умолчанию: False
**-f, --fingerprint** Эта опция включает сбор отпечатков (информации) о хостах,отправляющих запросы NBT-NS или LLMNR.
**-w, --wpad** Запустить жульнический прокси сервер WPAD. Значением по умолчанию является: False
**-u UPSTREAM_PROXY, --upstream-proxy=UPSTREAM_PROXY** Вышестоящий HTTP прокси используемый жульническим WPAD прокси для исходящих запросов (формат: хост:порт)
**-F, --ForceWpadAuth** Принудительная NTLM/Basic аутентификация при получении файла wpad.dat retrieval. Это может привести к появлению окон запроса входа. По умолчанию: False
**-P, --ProxyAuth** Принудительная NTLM (прозрачная)/Basic (через окно входа) аутентификация для прокси. WPAD не обязательно должен быть ON. Эта опция крайне эффективна когда комбинируется с -r. По умолчанию: False
**--lm** Принудительное понижение хеша LM для Windows XP/2003 и более ранних. По умолчанию: False
**-v, --verbose** Увеличить вербальность, можем посмотреть какие порты слушает responder

**Проверить открытые порты:**
> sudo ss -plant


далее пользователь идет на какую-нибудь шару, например \\filesrv.mydomain.local\share


и responder перехватывает hash


### Основы NTLM

На самом деле, NTLM и NTLMv1/v2 это довольно разные вещи. Хеш NTLM хранится и используется локально, а хеши NTLMv1/NTLMv2 используются для сетевой аутентификации и являются производными хеша NTLM. Используя любой из этих хешей можно расшифровать пароль пользователя Windows, но это разные алгоритмы шифрования/взлома.

Для атаки Pass-the-hash (мы не будем рассматривать в этой статье) применим только хеш NTLM, а хеши NTLMv1/NTLMv2 не подходят.

Остался ещё один вопрос, что такое хеши Net-NTLMv1/v2. Хеши Net-NTLMv1/v2 это сокращённое название для хешей NTLMv1/v2, то есть NTLMv1/v2 и Net-NTLMv1/v2 это одно и то же. А NTLM это другое.

NTLMv1 менее криптостойкий чем NTLMv2

**NTLMv1**

В NTLMv1 ответ NTLM (хэш NTLMv1) на вызов сервера вычисляется с использованием хэша NT для шифрования запроса сервера с помощью алгоритма DES. Сеансовый ключ также шифруется напрямую с помощью хэша NT.

NTLMv1 можно использовать с протоколом безопасности NTLMv2, то есть не совсем NTLMv2, а расширением для повышения безопасности NTLMv1.


**NTLMv2**

В NTLMv2 используется больше данных для защиты целостности сообщения AUTHENTICATE и, следовательно, целостности сеанса. Для вычисления ответа (хэш NTLM) NTLMv2 учитывает:

- Вызов сервера;
- Случайно сгенерированный клиентский вызов;
- Текущую временную метку;
- Поле AvPairs, содержащее такую ​​информацию, как домен сервера/имя хоста или сведения о включении Mic в сообщение (MsvAvFlags).


NTLMv2 объединяет все эти данные и применяет HMAC для вычисления ответа NTLM, известного как хэш NTLMv2. Кроме того, эти данные также используются для расчета сеансового ключа.

**MIC**

Кроме того, для защиты целостности согласования NTLM сообщение AUTHENTICATE включает MIC. MIC рассчитывается путем применения HMAC ко всем сообщениям процесса NTLM с сеансовым ключом.


Следовательно, целостность 3 сообщений сохраняется. И в случае, если злоумышленник удалит MIC, аутентификация не удастся, поскольку ответ NTLMv2 защищает флаг, указывающий на наличие MIC. Тем не менее, в прошлом были обнаружены уязвимости Drop the MIC и Drop the MIC 2.

Следует отметить, что NTLMv1 не учитывает флаги NTLM для создания ответа. Следовательно, в случае использования NTLMv1 злоумышленник, выполняющий атаку NTLM Relay, может просто удалить MIC (и настроить флаги, показанные в Drop the MIC ) сообщения AUTHENTICATE, чтобы подделать данные и, например, отключить подпись сообщений приложений..

### Brute hash

После того как hash перехвачен можем попробовать его сбрутить, либо через hashcat либо через john. Основное их отличие в том что hashcat умеет для брута юзать GPU

узнаем номер hash

> hashcat -h | grep -i ntlm


примеры можем смотреть тут: https://hashcat.net/wiki/doku.php?id=example_hashes

> hashcat -a 0 -m 5600 hash.txt /usr/share/wordlists/rockyou.txt


Команда у john будет выглядеть примерно так:

> john --format=netntlmv2 hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

### Защита от NBT-NS/LLMNR poisoning

**Отключение протокола LLMNR с помощью GPO**

Можно отключить LLMNR на компьютере Windows локально через реестр с помощью следующей команды PowerShell:

New-Item "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT" -Name DNSClient -Force
New-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMultiCast -Value 0 -PropertyType DWORD -Force

В доменной среде широковещательные запросы LLMNR на компьютерах и серверах домена проще отключить с помощью групповой политики. Для этого:

1. В консоли GPMC.msc создайте новую или отредактируйте имеющуюся политику, применяемую ко всем рабочим станциям и серверам;
2. Перейдите в раздел Computer Configuration -> Administrative Templates -> Network -> DNS Client;
3. Включите политику Turn off smart multi-homed name resolution, изменив ее значение на Enabled;


4. Дождитесь обновления параметров GPO на клиентах или обновите их вручную командой gpupdate /force .

Либо вы можете через GPP распространить на компьютеры домена параметр реестра: EnableMulticast = 0 (HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient).

**Отключение протокола NetBIOS over TCP/IP в Windows 10**

Примечание. Протокол NetBIOS может использовать старыми версиями Windows и некоторыми не-Windows системами, поэтому процесс его отключения в конкретной среде стоит тестировать.

Вы можете отключить NetBIOS в Windows вручную:
1. Откройте свойства сетевого подключения;
2. Выберите протокол TCP/IPv4 и откройте его свойства;
3. Нажмите кнопку Advanced, затем перейдите на вкладку WINS и выберите опцию Disable NetBIOS over TCP (Отключить NetBIOS через TCP/IP);
4. Сохраните изменения.


Если у вас на компьютере несколько сетевых интерфейсов (или отдельных VLAN), нужно будет отключить NetBIOS в свойствах каждого их них.

Вы можете проверить статус NetBIOS over TCP/IP для сетевых адаптеров из командной строки Windows:

ipconfig /all |find "NetBIOS"

*NetBIOS over Tcpip. . . . . . . . : Disabled*


Отключить поддержку NetBIOS для конкретного сетевого адаптера можно и из реестра. Для каждого сетевого адаптера компьютера есть отдельная ветка с его TCPIP_GUID внутри HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces.

Чтобы отключить NetBIOS для конкретного сетевого адаптера, нужно открыть его ветку и изменить значение параметра NetbiosOptions на 2 (по умолчанию значение – 0).


На клиентах домена, получающих IP адреса с DHCP на Windows Server, вы можете отключить NetBIOS через настройку опций DHCP сервера.

1. Для этого откройте консоль dhcpmgmt.msc и выберите настройки зоны Scope Option (или сервера – Server Options);
2. Перейдите на вкладку Advanced, в выпадающем списке Vendor class выберите Microsoft Windows 2000 Options;
3. Включите опцию 001 Microsoft Disable Netbios Option и измените ее значение на 0x2.

**Как отключить NetBIOS через групповые политики?**

В редакторе групповых политик или последней версии административных шаблонов для Windows 10/Windows Server 2019 нет отдельного параметра, позволяющего отключить протокол NETBIOS over TCP/IP для всех сетевых адаптеров компьютера. Чтобы отключить NETBIOS для всех адаптеров компьютера воспользуйтесь таким логон скриптом PowerShell:

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

Сохраните этот код в файл disableNetbios.ps1, скопируйте его в каталог вашей GPO и запускайте на клиентах через Computer Configuration -> Policies -> Windows Settings -> Scripts -> Startup- > PowerShell Scripts.

Примечание. Если на клиентах настройки политики выполнения PowerShell блокируют запуск этого скрипта, нужно подписать PS1 скрипт или запускать его в режиме –bypass.


Примечание. Для вступления изменений в силу, нужно отключить/включить сетевые адаптеры или перезагрузить компьютер.

Затем откройте командную строку и проверьте, что NetBIOS отключен для ваших сетевых адаптеров (кроме туннельных интерфейсов):

wmic nicconfig get caption,index,TcpipNetbiosOptions


### NTLM Relay

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


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

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

Поскольку это необязательное поле, злоумышленник также может удалить MIC и изменить флаги (в AvPairs), чтобы указать, что MIC отсутствует (он не может изменить MIC, поскольку он вычисляется с помощью сеансового ключа). Следовательно, для защиты MIC NTLMv2 использует значение AvPairs (включая флаг MIC), включенное в сообщение AUTHENTICATE, для расчета ответа на вызов. Если злоумышленник изменит флаг, указывающий на наличие MIC в AvPairs, то проверка ответа на запрос на целевом сервере завершится неудачно, и сеанс будет завершен. Следует отметить, что NTLMv1 не защищает MIC, поэтому он уязвим для подделки сообщений.

Любопытно, что до CVE-2015-005 в случае использования NTLM с учетными записями домена злоумышленник мог использовать вызов Netlogon (NetrLogonSamLogonWithFlags), чтобы попросить контроллер домена проверить сообщение AUTHENTICATE и вернуть ключ сеанса, чтобы злоумышленник мог использовать это, чтобы обойти ограничение подписи.

Тем не менее, это не конец истории. NTLM позволяет согласовывать подписи с помощью флага NTLM NTLMSSP_NEGOTIATE_SIGN. Это может быть установлено клиентом и сервером. Однако то, что оба устанавливают этот флаг, не гарантирует, что будет использоваться подпись. Это зависит от протокола приложения. Кроме того, обычно существует 3 состояния подписи: Не поддерживается, Поддерживается, Требуется.

Например, в случае SMB он включает свои собственные флаги подписи (SecurityMode), которые определяют, поддерживается/требуется ли подпись или нет. Таким образом, в связи SMB установлен флаг NTLM NTLMSSP_NEGOTIATE_SIGN, указывающий, что подпись поддерживается, но необходимо проверить флаги SMB, чтобы определить, будет ли связь подписана. Кроме того, это поведение отличается в зависимости от версии SMB.

В случае SMB1 есть 3 состояния подписи: не поддерживается, поддерживается, требуется.


Однако в случае SMB2 подпись всегда включена, но есть 2 состояния: требуется и не требуется.


И в SMB1, и в SMB2 по умолчанию у клиента стоит подпись Enabled (но не обязательна), поэтому установлен флаг NTLM NTLMSSP_NEGOTIATE_SIGN. Однако на серверах установлен только флаг NTLMSSP_NEGOTIATE_SIGN в SMB2, за исключением контроллеров домена, которые всегда требуют подписи SMB. Это необходимо учитывать при выполнении кросс-протокольной атаки NTLM Relay.

Другим распространенным протоколом, использующим NTLM, является LDAP, который также имеет три уровня подписи: обязательный, включенный и отключенный. Однако, в отличие от SMB, протокол LDAP не имеет флагов подписи, поэтому согласование основано на флаге NTLMSSP_NEGOTIATE_SIGN NTLM, который устанавливается, когда LDAP по крайней мере поддерживается/включен. Следующая матрица определяет эти случаи:


Применяя объекты групповой политики, можно изменить конфигурацию подписи LDAP как для клиента, так и для сервера.

Когда и на клиенте, и на сервере включена подпись (это означает, что она поддерживается), связь подписывается. Кроме того, необходимо учитывать, что контроллеры домена по умолчанию не используют подписи LDAP, поэтому клиент может установить неподписанный сеанс с контроллером домена.
Таким образом, кросс-протокольная ретрансляционная атака может быть выполнена из LDAP в SMB2, но не из SMB2 в LDAP.


Как мы видели ранее, SMB2 всегда устанавливает NTLMSSP_NEGOTIATE_SIGN, поэтому, если мы ретранслируем эти сообщения NTLM на сервер LDAP, поддерживающий подпись, то подпись согласовывается, и атака не удается. Помните, что сообщения NTLM не могут быть изменены, так как MIC защищает их (в NTLMv2).

В противном случае злоумышленник может договориться с сервером SMB2 о том, что подпись не требуется, используя заголовки SMB и ретранслируя сообщения LDAP NTLM, что по умолчанию устанавливает флаг NTLMSSP_NEGOTIATE_SIGN. После завершения согласования NTLM, поскольку подпись не используется в SMB, если она не требуется, сеанс не требует подписи, поэтому атака успешна. Однако эта атака невозможна против контроллеров домена, поскольку по умолчанию они требуют подписи.


Собственно, протокол SMB2 можно ретранслировать сам на себя:


**NTLM Relay SMB2 в SMB2 с помощью ntlmrelayx:**


Другим протоколом, который может использовать NTLM, является HTTP, но по умолчанию подпись не используется. Таким образом, HTTP можно использовать для кросс-протокольной ретрансляционной атаки для LDAP или SMB.


Поскольку клиент не указывает, что подписание включено, подписывание LDAP не требуется. Этот сценарий использовался для эксплуатации уязвимости PrivExchange. Ретрансляция на LDAP очень полезна, поскольку можно использовать ее для изменения списков контроля доступа или объектов базы данных домена, что позволяет в некоторых случаях повышать привилегии.

Для выполнения ретрансляционных атак NTLM мы можем использовать сценарии ntlmrelayx.py или MultiRelay.py в сочетании с Responder.py, который позволяет выполнять атаки типа «человек посередине». В Windows другой вариант — использовать Inveigh для выполнения как MiTM, так и ретрансляции. Ограничение этого инструмента заключается в том, что он не позволяет выполнять ретрансляционную атаку NTLM с SMB2 на SMB2 с компьютера Windows, поскольку порт 445 используется системой.

Помимо SMB и LDAP, существуют другие протоколы, такие как MS-SQLили SMTP, которые поддерживают NTLM и могут использоваться для этой атаки.

### Защита от NTLM Relay

Cуществуют средства защиты для межпротокольной ретрансляции NTLM, привязки канала или EPA (расширенная защита для проверки подлинности). Идея привязки канала состоит в том, чтобы добавить информацию о протоколе приложения в сообщение AUTHENTICATE NTLM, которое защищено MIC. Введены два типа привязок: привязка службы и привязка TLS.

Привязка службы состоит в том, что клиент указывает SPN службы в AvPairs сообщения AUTHENTICATE (которые защищены хэшем NTLMv2), поэтому сервер может проверить, предназначался ли запрос NTLM для него. Например, если клиент указывает, что запрос NTLM предназначен для службы LDAP, а сервер, который его получает, обрабатывает SMB (поскольку в середине находится злоумышленник), он отклонит аутентификацию. Кроме того, SPN также указывает адрес сервера, поэтому, если он ретранслируется на другой сервер, аутентификация будет отклонена.

С другой стороны, при привязке TLS клиент вычисляет хэш, известный как CBT (токен привязки канала), с ключом сеанса сертификата сервера, который используется для создания канала TLS. Если злоумышленник выполняет атаку MiTM, то сертификат, предоставленный злоумышленником (ему необходимо создать новый сертификат для расшифровки/шифрования трафика TLS), будет отличаться от сертификата исходного сервера. Таким образом, сервер проверит CBT, сгенерированный клиентом, и, если он не совпадает с хэшем собственного сертификата, отклонит аутентификацию.

Как и в случае с подписью, применение привязки канала зависит от протокола приложения. Обновленные клиенты SMB и LDAP должны использовать привязку канала, однако серверы, похоже, не проверяют это.

Можно сделать проще, отключив NTLM аутентфикацию и использовать Kerberos.

### WPAD MITM

**WPAD (Web Proxy Avto Discovery Protocol)** – специальный протокол для авто настройки проксирования в системе Windows. Система всегда запрашивает файл с настройками (там опредялющие для системы правила на какой прокси как ходить) **wpad.dat**, а злоумышленник может подсунуть свой файл, став прокси-серверов для Windows и таким образом осуществив атаку “человек посередине”.

**MS16_088: Security update KB3161949 от 14.2016 - фиксит данную атаку!!!**

**Выполнение атаки** запускаем нашу атаку:

> responder -I eth0 -wFv

где:

- I eth0 – выбор интерфейса
- w – отравление WPAD (специальный протокол для настройки проксирования в системе Win. Система всегда запрашивает файл с настройками **wpad.dat**, а злоумышленник может подсунуть свой файл, став прокси-серверов для Win и таким образом осуществив атаку “человек посередине”)
- F – попробовать принудить систему использовать старые протоколы аутентификации, если возможно ( бывает не срабатывает)
- P - **вместо F можно указать ее, чтобы авторизация происходила через прокси**
- v – вывод подробной информации (в т.ч. перехваченного хэша)
После чего нам необходимо зайти в Window машину и попробовать перейти по несуществующему адресу доменного сервера, например:

\\sdfsgfsdgdfgd

После чего мы увидим следующее диалоговое окно:


Если жертва введет учетные данные, злоумышленник получит имя пользователя и пароль в открытом виде:


Вернувшись на машину атакующего мы увидим в выводе HASH пользователя(NTLNv2 аутентификацию), которую потом можно брутить через hashcat или John the ripper. В выводе будет NTLMv2 хэш.

С Wireshark видно, как жертва пытается получить файл wpad.dat и отправляет пароль, закодированный с помощью Base64:


Более того, Responder может перенаправить пользователя на поддельную веб-страницу или предоставить вредоносный исполняемый файл.

В файлe /etc/responder.conf необходимо внести следующие изменения:

*[HTTP Server]*

*; Set to On to replace any requested .exe with the custom EXE Serve-Exe = On*

*; Set to On to serve the custom HTML if the URL does not contain .exe*
*; Set to Off to inject the 'HTMLToInject' in web pages instead Serve-Html = On*

Затем запускаем Responder:

responder -I eth0 -I 10.7.7.31 -r On -w On -wFb


Теперь, когда жертва попытается воспользоваться браузером, она увидит следующую страницу:


Если случайно жертва перейдет по ссылке, будет загружена reverse shell:


Наконец, если жертва запустит вредоносный исполняемый файл, используя netcat на порту 140, злоумышленник сможет получить доступ к компьютеру жертвы:


### Защита от WPAD атак:

- Первое решение для этой атаки — создать запись DNS с «WPAD», указывающую на корпоративный прокси-сервер. Таким образом, злоумышленник не сможет манипулировать трафиком.

- Второе решение — отключить «Автоопределение настроек прокси» во всех браузерах.

### Mitm6 и NTLM Relay

Если в корпоративной сети используется IPv6, мы можем ответить на запросы DHCPv6 и установить в качестве DNS-сервера на атакуемой машине свой IP-адрес. Так как IPv6 имеет приоритет над IPv4, DNS-запросы клиента будут отправлены на наш адрес. Подробнее об атаке можно прочитать тут:

https://blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/

**Установка:**

git clone https://github.com/dirkjanm/mitm6

**Запуск утилиты mitm6**

mitm6 -i eth0 -d contoso.local

После выполнения атаки на атакуемой рабочей станции появится новый DNS-сервер с нашим IPv6-адресом:


Выполним NTLM-релей. Предварительно убедившись, что не используется SMB Signing, применяем утилиту ntlmrelayx и проводим атаку. Здесь, в зависимости от цели, выбираем нужный нам вектор. Рассмотрим некоторые из них.

ntlmrelayx.py -t 192.168.1.5 -l loot -i

**Доступ к атакуемой машине по протоколу SMB**

ntlmrelayx.py -t 192.168.1.5 -l loot -i


При удачной атаке мы сможем подключиться к удаленной машине с помощью netcat.


**Cбор информации о домене**

В данном случае выполняем релей на контроллер домена.

ntlmrelayx.py -t ldap://192.168.1.2

При успешном проведении атаки получим подробную информацию о домене:


### Защита от mitm6:

Единственная известная защита от этой атаки — отключение IPv6, если он не используется во внутренней сети. Это остановит запросы Windows-клиентов на сервер DHCPv6 и сделает невозможным захват DNS-сервера с помощью описанного выше метода.
Однако компания Майкрософт не рекомендует этого делать, в следствие чего многие администраторы забивают на это и именно поэтому эта атака очень интресна с точки зрения злоумышленника. Более подробно: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/configure-ipv6-in-windows