Гид по NTLM Relay, часть 2. Проводим Relay-атаки

Содержание статьи

• Клиенты
• SMB (445/TCP)
• LDAP (389/TCP, 636/TCP)
• RPC (135/TCP)
• HTTP (80/TCP)
• Выводы
• Бонус
• Защита
• Итог

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

info

О том, как получить NTLM-аутен­тифика­цию, пред­шес­тву­ющую Relay-ата­ке, под­робно рас­ска­зано в статье «Гид по NTLM Relay. Зах­ватыва­ем NTLM-аутен­тифика­цию для Relay-ата­ки». NTLM Relay-ата­ки мож­но про­водить не толь­ко в Active Directory, но еще, нап­ример, в ALD и FreeIPA-доменах.

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

До­пус­тим, кли­ент хочет прой­ти аутен­тифика­цию с машины Work1 на SMB, ата­кующий перех­ватыва­ет эту сес­сию и хочет прой­ти аутен­тифика­цию на LDAP. Такой кейс мы будем называть Relay с SMB на LDAP.

Еще один при­мер, что­бы зак­репить наше понима­ние. Кли­ент хочет прой­ти аутен­тифика­цию с машины Work1 на HTTP, ата­кующий перех­ватыва­ет эту сес­сию и хочет прой­ти аутен­тифика­цию на SMB. Такой кейс мы будем называть Relay с HTTP на SMB.

Клиенты

Для реали­зации ата­ки нам нужен кли­ент и сер­вер, ntlmrelayx как раз по такой модели и пос­тро­ен. Про RelayServers мы говори­ли в прош­лой статье, в этой будем говорить про RelayClients.

SMB (445/TCP)

На SMB аутен­тифика­цию мож­но пересы­лать с любого дру­гого про­токо­ла. Глав­ное усло­вие успешнос­ти Relay-ата­ки — это отсутс­твие тре­бова­ния под­писи SMB-сооб­щений на машине, куда мы выпол­няем Relay. Что­бы про­верить это, мож­но вос­поль­зовать­ся сле­дующей коман­дой:

crackmapexec smb -u '' -p '' --shares <target IP or nets or file>


На рисун­ке тре­бова­ние под­писи вклю­чено, на этой машине выпол­нить ата­ку на SMB Relay не получит­ся.

SMB Signing: True

А в этом при­мере на машине тре­бова­ние отклю­чено, на нее Relay делать мож­но.

SMB Signing: False

Для авто­мати­зации мож­но исполь­зовать сле­дующую коман­ду:

crackmapexec smb --gen-relay-list targets.txt <nets>


Соз­дание спис­ка целей для Relay на SMB

Рас­смот­рим вари­анты выпол­нения Relay на SMB. Самый прос­той вари­ант — выпол­нить Relay на машину с SMB, ког­да пересы­лаемая нами учет­ная запись име­ет пра­ва локаль­ного адми­нис­тра­тора на целевом хос­те. При выпол­нении такой пересыл­ки сдам­пятся хеши SAM, и мы получим NT-хеш локаль­ного адми­нис­тра­тора и зак­репим­ся на машине.

impacket-ntlmrelyx -t smb://<IP>


Ус­пешный Relay на SMB

Но если прав нет, мы получим ошиб­ку, и на этом ата­ка закон­чится.

Не­удач­ный Relay на SMB

В ситу­ации, ког­да у нас исполь­зует­ся SMBv2, всег­да необ­ходимо добав­лять флаг -smb2support. В качес­тве цели мож­но ука­зать файл, где перечис­ляют­ся в поряд­ке при­ори­тета цели и про­токол, на который надо выпол­нить ата­ку, при­мер­но в сле­дующем фор­мате:

smb://IP1
ldap://IP2
smb://IP3
rpc://IP4


Что­бы подать на вход этот файл со спис­ком целей, исполь­зуем флаг -tf:

impacket-ntlmrelayx -tf targt.txt


И тут сто­ит ска­зать, что обыч­но аутен­тифика­ция при­лета­ет не одна, а сра­зу нес­коль­ко, поэто­му мож­но поп­робовать Relay в нес­коль­ко мест. Но так­же в ntlmrelayx есть механизм multirelay, суть которо­го сос­тоит в том, что он может одну условную аутен­тифика­цию прев­ратить в десять. Это дей­стви­тель­но работа­ет, но не ста­биль­но. При пер­вой же ошиб­ке или отка­зе дос­тупа про­цесс оста­новит­ся. Что­бы отклю­чить этот механизм в слу­чае с нес­коль­кими целями, нуж­но добавить в коман­ду параметр --no-multirelay:

impacket-ntlmrelayx -tf targt.txt -smb2support --no-multirelay

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

Для вза­имо­дей­ствия с сетевы­ми пап­ками целевой машины от име­ни пересы­лаемой учет­ной записи можем исполь­зовать инте­рак­тивный режим:

impacket-ntlmrelyx -t smb://<IP> -i

Relay на SMB в инте­рак­тивном режиме

Пос­ле это­го у нас под­нима­ется обо­лоч­ка на локаль­ном интерфей­се, к которой мож­но при­соеди­нить­ся сле­дующей коман­дой:

nc 127.0.0.1 11000


Пос­ле под­клю­чения нам дос­тупен обыч­ный smbclient из Impacket с точ­но таким же син­такси­сом.

Обо­лоч­ка smbclient в резуль­тате Relay на SMB

Спо­соб получе­ния инте­рак­тивно­го режима может быть полезен, ког­да мы не зна­ем, есть у нас при­виле­гиро­ван­ные пра­ва на целевой машине или нет. Если прав нет и мы поль­зуем­ся стан­дар­тным режимом — ничего не про­изой­дет. Если пра­ва есть, мы хотя бы получим дос­туп ко всей фай­ловой сис­теме и, может быть, суме­ем най­ти что‑то инте­рес­ное. Но в целом есть еще более уни­вер­саль­ный спо­соб.

Мо­жет сло­жить­ся ситу­ация, ког­да мы не име­ем прав локаль­ного адми­нис­тра­тора, но можем зак­репить­ся на целевой машине от име­ни пересы­лаемой учет­ной записи с помощью фла­га -socks:

impacket-ntlmrelyx -t smb://<IP> -socks

В этом режиме мож­но реали­зовать при­мер­но сле­дующую схе­му.

Схе­ма Relay на SMB в режиме socks

Пос­ле успешной Relay-ата­ки мы получа­ем SMB-сес­сию и можем исполь­зовать ее мно­гок­ратно с помощью proxychains4. Для это­го редак­тиру­ем кон­фигура­цион­ный файл /etc/proxychains4.conf. В конец добав­ляем строч­ку:

socks4 127.0.0.1 1080


Для исполь­зования уже соз­данно­го соеди­нения пос­ле нас­трой­ки кон­фига proxychains подой­дет сле­дующий син­таксис:

proxychains4 impacket-smbclient 'domain/username@<target IP>' -no-pass

Сто­ит обра­тить вни­мание, что про­ходить аутен­тифика­цию таким обра­зом мож­но толь­ко на машине, куда был совер­шен Relay. Запус­каем ntlmrelayx с фла­гом socks, в качес­тве целей ука­зыва­ем машины без SMB Signing.

Relay на SMB в режиме socks

Ре­дак­тиру­ем кон­фиг proxychains. Мы можем запус­кать smbclient без пароля через proxychains.

smbclient в кон­тек­сте socks

Та­кой спо­соб может поз­волить зак­репить­ся на целевой машине даже не при­виле­гиро­ван­ному поль­зовате­лю, что исполь­зует­ся в опре­делен­ных ситу­ациях. Но если сес­сия ока­жет­ся при­виле­гиро­ван­ной, мож­но запус­тить secretsdump и получить NT-хеши.

secretsdump в кон­тек­сте sock

Та­ким обра­зом мы можем запус­кать весь софт из Impacket, а так­же осно­ван­ные на нем скрип­ты. С помощью это­го спо­соба мож­но делать дей­стви­тель­но уди­витель­ные вещи, но об этом чуть поз­же, а пока плав­но перехо­дим к сле­дующе­му про­токо­лу.

LDAP (389/TCP, 636/TCP)

Источник: xakep.ru