Запустил на интерфейсе, подождал пятнадцать минут — и в логах уже несколько NetNTLMv2-хешей. Это типичный сценарий в корпоративной сети где LLMNR и NBT-NS не отключены. Responder эксплуатирует простую механику: Windows ищет ресурс широковещательным запросом, Responder отвечает «это я» и получает попытку аутентификации.

Запуск

responder -I eth0

Только наблюдение без отравления (разведка, не атака):

responder -I eth0 -A

Я всегда начинаю с -A — посмотреть насколько «болтлива» сеть прежде чем включать отравление. В пассивном режиме Responder не вмешивается, только записывает что видит.

Что происходит под капотом

Responder поднимает набор поддельных серверов — SMB, HTTP, FTP, LDAP, MSSQL. Когда жертва пытается аутентифицироваться на «найденном» ресурсе, её NetNTLMv2-хеш оседает в логах. Хеши сохраняются в /usr/share/responder/logs/.

Взлом хешей

hashcat -m 5600 responder_hashes.txt rockyou.txt -r rules/best64.rule

Режим 5600 — NetNTLMv2. Если hashcat не берёт, хеш скорее всего от сложного пароля — тогда имеет смысл попробовать relay вместо взлома.

NTLM Relay

Если хеш не ломается, его можно ретранслировать. Для этого в Responder отключают SMB и HTTP — они нужны relay-инструменту (ntlmrelayx из impacket). В конфиге /etc/responder/Responder.conf выставляем SMB = Off, HTTP = Off, потом:

responder -I eth0 --disable-ess

Параллельно запускаем ntlmrelayx на целевые хосты.

WPAD-прокси

-w поднимает WPAD-прокси — браузеры в домене часто автоматически ищут прокси через WPAD, и это даёт дополнительный вектор перехвата HTTP. -F форсирует NTLM-аутентификацию на WPAD.

В рабочем потоке

Responder — почти всегда первый ход во внутренней сети. Пассивный режим, потом отравление. За пару часов в типичной корпоративной сети набирается несколько хешей. Дальше либо взлом через hashcat, либо relay через impacket. Один из самых надёжных способов получить первые учётки без сканирования.