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

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

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

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

Клиенты

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

SMB (445/TCP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LDAP (389/TCP, 636/TCP)