Техника NTLMRelay – реальная имба на пентесте

Содержание

1 Что за стенд
2 Как проверить требуется ли цифровая подпись пакетов или нет?
3 В чём суть атаки
4 Собираем связку Responder + NTLMRelay

Всем привет. В ходе аудита информационной безопасности частенько (да в 100% случаев) сталкиваюсь с тем, что на сетевых узлах отключено требование обязательной цифровой подписи протокола SMB. Ну отключено и отключено, плохо конечно, но чем это чревато?

И всё никак не удавалось продемонстировать последствия такого недостатка в дикой среде. Скажем так, описывать его дольше, чем просто прочекать. А тут вот всё-таки собрался с мыслями, собрал стенд из нескольких виртуалок и решил продемонстрировать. Тем более, что получилось очень показательно.

Что за стенд

В качестве стенда буду использовать сборку Game of Active Directory. Скажу сразу – стенд очень прикольный, есть множество различных техник и потестить инструменты прям самое оно.

Установить его – отдельный квест, я пол-дня мучился, пришлось даже апгрейд компьютера делать, но оно того стоило. Если нужно будет, в отдельном посте расскажу как его разворачивать.

Итак, погнали дальше.

Как проверить требуется ли цифровая подпись пакетов или нет?

Лично я проверяю через CrackMapExec – этот инструмент стал уже настолько привычным, что уже наверное занимает 1-ое место в рейтинге моих любимых hack tool.

# crackmapexec smb 192.168.56.0/24

Указываем целую подсеть и ищем упоминания (signing:False). В нашем стенде всего 5 серверов. Однако в организации, как правило, там будут десятки и сотни узлов. Теперь бы хорошо список IP-адресов с отключенной цифровой подписью сохранить в файлик для последующего использования.

# crackmapexec smb 192.168.56.0/24 --gen-relay-list smb_sign_off.txt

У CrackMapExec существует отдельная опция, которая сохраняет найденные хосты с отключенной подписью в отдельный файл (в нашем случае – smb_sign_off.txt).

В чём суть атаки

Вспоминаем одну из статей, когда мы ловили хеш NetNTLM в сети через Responder. В общем виде напрямую использовать этот хеш через какой-нибудь Pass-the-Hash нельзя, только восстанавливать методом перебора через Hashcat.

Но скажем так, есть ещё один вариантик, в случае если отсутствует проверка подлинности отправителя (как раз цифровая подпись), можно перенаправить от своего имени хеш на целевую машину и выполнить произвольные действия от имени конкретного пользователя. Особенно уместно будет, если пользователь состоит в группе администраторов хотябы на каком-нибудь узле с отключенной проверкой цифровой подписи) На стенде как раз есть такая сборочка, но из опыта – в организациях тоже встречается нередко.

Собираем связку Responder + NTLMRelay

Для начала убедимся, что нам вообще есть что там ловить) а именно, циркулируют ли широковещательные запросы разрешения имён. Для этого запустим resonder на прослушивание интерфейса.
# responder -I eth1
(где eth1 – интерфейс, смотрящий в корпоративную сеть)
Внимание, эта процедура в режиме “poisoning” может навести шороху в сети и вызвать проблемы с некоторыми сервисами)

Должны через некоторое время увидеть что-то типа такого:

Пролетел хеш NTLMv2 пользователя NORTH\eddard.stark. Мы можем уже повесить его на перебор, а можем…. (читать дальше).
Вот что мне нравится в этом стенде – там на уровне запланированной задачи запрограммировано, что будет пролетать два хеша. Один – обычного пользователя, с легким паролем, который можно подобрать. Второй – с паролем юзера с правами админа, пароль сбрутить нереально. Так что долго ждать не придётся. Ну ладно, сейчас проведём атаку.
Отменяем респондер и идём в его конфиг: (/usr/share/responder/Responder.conf)
Нам нужно отключить запуск SMB и HTTP-серверов при старте. Чтобы не было конфликта с NTLMRelay. Сохраняем конфиг и идём дальше.
Далее я для удобства разобью консоль на три экрана – при помощи tmux.
В первом экране запустим NTLMRelayX из состава Impacket (сейчас уже есть “из коробки”, но можно скачать с гитхаба)
# ntlmrelayx.py -tf smb_sign_off.txt -of hashes -smb2support -socks
где -tf – путь к файлу целей (хосты с отключенной проверкой цифровой подписи), -of – выходной файлик, куда полетят хеши; -socks – режим проксирования, когда поднимается socks-сервер и через который можно перенаправлять запросы. Обратите внимание на каком порту он поднялся, я подвёл
Во втором окне стартуем Responder тот же самый, ожидаем захват хеша
# responder -I eth1
Когда хеш наконец пролетит, ntlmrelay проще говоря попробует прозрачно авторизоваться на каждой из целевых систем (в списке IP всего 2 станции), а также создаст socks-подключения к каждой из них, в случае успеха.
Для проверки введём в окне ntlmrelayx команду “socks” и увидим куда можно проксироваться, под какой учётной записью и есть ли у нас права администратора:
Повезло! Есть одна админская учётка. Мы не знаем её пароль, только NTLMv2-хеш, который ещё нужно подобрать (но мы не будем). Также не сможем по NTLMv2 выполнить Pass-The-Hash. Но это и не надо.
Проксируемся! Для этого используем штатный proxychains, которые требуется чуток поднастроить.
Открываем конфиг: /etc/proxychains4.conf
И прописываем там наш порт – в случае с ntlmrelayx – 1080 (я обводил на скрине выше). Ну ещё можно раскомментировать строчку quiet_mode, чтобы не моросили служебные сообщения в консоль. Я лично не люблю) Да, кстати, Responder уже можно выключить!
Проксируемся!
# proxychains secretsdump.py -no-pass NORTH/EDDARD.STARK@192.168.56.22
Если всё сделано правильно – вот нам и дамп SAM-базы пользователей, с NT-хешем локального администратора (вот его уже можно PtH-кнуть).
Дальше DCC2-кеширование учётки (брутить смысла нет – слишком сложное шифрование, скорость будет – ну тока ТОП10к паролей проверить разве что.
И ниже будет ещё дамп LSA-кредсов,
Вон, даже пароль SPN-учётки “sql_svc” в открытом виде – пароль длиннющий, перебрать невозможно будет. Кстати, не помню, писал ли про SPN-учётки или нет, но напишу. Механизм – огонь!
Всё, точка уже хакнута – есть права админа. Кроме secretsdump можно использовать и другие утилиты, тот же lsassy, donpapi и т.д. Всё, где можно авторизоваться.