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

https://t.me/hacker_frei

DrieVlad

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

• Клиенты
• 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 не получит­ся.

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

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

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

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

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

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

В ситу­ации, ког­да у нас исполь­зует­ся 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

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

nc 127.0.0.1 11000

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

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

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

impacket-ntlmrelyx -t smb://<IP> -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.

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

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

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

LDAP (389/TCP, 636/TCP)

Вы­пол­нять Relay на LDAP мож­но толь­ко в слу­чае, если на сер­вере отклю­чено тре­бова­ние под­писи сооб­щений. Про­верить мож­но с помощью скрип­та LdapRelayScan.py.

python3 LdapRelayScan.py -dc-ip <target IP>

Relay-ата­ки на LDAP могут быть край­не импак­тны­ми для ата­кующе­го, поэто­му Microsoft пыта­ется это­му вся­чес­ки пре­пятс­тво­вать. Есть нес­коль­ко глав­ных усло­вий, при которых воз­можна пересыл­ка NTLM-аутен­тифика­ции на LDAP:

1. Аутен­тифика­ция с HTTP всег­да пересы­лает­ся на LDAP.
2. Аутен­тифика­ция с SMB пересы­лает­ся на LDAP в сле­дующих слу­чаях:ис­поль­зование NetNTLMv1-хеша кли­ентом;
3. уяз­вимос­ти CVE-2019-1040 и CVE-2019-1166 на кон­трол­лерах домена;
4. Экс­плу­ата­ция RemotePotato0.

Для экс­плу­ата­ции пересыл­ки с HTTP на LDAP никаких фла­гов добав­лять не надо:

impacket-ntlmrelayx -t ldap://<DC IP>

Из резуль­тата вид­но, что ntlmrelayx про­веря­ет при­виле­гии поль­зовате­ля в домене, добав­ляет нового, если может, и накиды­вает ему при­виле­гии на DCSync, а так­же соз­дает дамп домена. Если поль­зователь не обла­дает никаки­ми при­виле­гиями, то прос­то соз­дает­ся дамп домена.

Дам­пим ntds.dit с помощью соз­данной в резуль­тате Relay-ата­ки учет­ки.

Дамп домена, получен­ный в резуль­тате успешной Relay-ата­ки на LDAP, показан на рисун­ке ниже.

Те­перь нес­коль­ко слов мож­но ска­зать про Relay с SMB на LDAP. Углублять­ся в струк­туру каж­дого из хешей не будем, все‑таки раз­говор идет не про это, но пару слов про раз­ницу имен­но в кон­тек­сте такой ата­ки ска­зать сто­ит:

• NetNTLMv1-хеш будет при­ятным подар­ком для ата­кующе­го, потому что у него есть недос­таток дизай­на — отсутс­твие зна­чения MIC (зна­чение для про­вер­ки целос­тнос­ти), которое поз­воля­ет выпол­нять Relay с SMB на LDAP.
• В NetNTLMv2 исправ­лен этот недос­таток, но все‑таки в реали­зации были обна­руже­ны уяз­вимос­ти 2019-1040 и CVE-2019-1166, которые поз­воля­ют уда­лить MIC и выпол­нить Relay с SMB на LDAP.

Во всех опи­сан­ных слу­чаях при­меня­ем флаг --remove-mic в ntlmrelayx:

impacket-ntlmrelayx -t ldap://<DC IP> -smb2support --remove-mic

В слу­чае аутен­тифика­ции с NetNTLMv2-хешем на кон­трол­лер с пат­чем получа­ем ошиб­ку.

В слу­чае аутен­тифика­ции с NetNTLMv2-хешем на кон­трол­лер без пат­ча получа­ем про­фит.

Ана­логич­ная ситу­ация будет с NetNTLMv1-хешем при Relay-ата­ке на кон­трол­лер с пат­чем — получа­ем про­фит.

Так­же полез­ным может ока­зать­ся инте­рак­тивный режим:

impacket-ntlmrelayx -t ldap://<DC IP> -i

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

А вот один из клас­сных при­меров исполь­зование RAW-сер­вера, о котором мы говори­ли в пре­дыду­щей статье с Relay-ата­кой на LDAP.

Ре­зуль­тат пересыл­ки аутен­тифика­ции на LDAP — соз­данная учет­ная запись, не админ­ская, но с при­виле­гией DCsync.

RPC (135/TCP)

Так­же воз­можна пересыл­ка NTLM-аутен­тифика­ции на DCE/RPC. В основном эта тема рас­кры­вает­ся в кон­тек­сте Potato-атак. Но так­же есть уяз­вимос­ти, которые поз­воля­ют выпол­нять коман­ды на узле вне зависи­мос­ти от тре­бова­ний под­писи SMB, потому что SMB там не исполь­зует­ся сов­сем.

Пер­вые иссле­дова­ния на эту тему опуб­ликова­ли CompasSecurity в сво­ем бло­ге. Более того, три года под­ряд они находят все новые век­торы экс­плу­ата­ции Relay на RPC. Пер­вой была уяз­вимость CVE-2020-1113, потом CVE-2021-26414, и в 2022 году они откры­ли миру ата­ку на AD CS ESC11.

Для экс­плу­ата­ции CVE-2020-1113 (при­сутс­тву­ет в Impacket 0.10.0) исполь­зуем сле­дующую коман­ду:

impacket-ntlmrelayx -t rpc://<target IP> -c ’whoami’

В качес­тве при­мера выпол­ним код на кон­трол­лере домена с вклю­чен­ным тре­бова­нием под­писи SMB-сооб­щений.

Да­же если в домене нас­тро­ено тре­бова­ние под­писи SMB, мож­но про­бовать Relay на RPC, пос­коль­ку один‑единс­твен­ный непос­тавлен­ный патч может дать пре­иму­щес­тво ата­кующе­му.

Что­бы иметь воз­можность экс­плу­ата­ции ESC11, необ­ходимо в свой Impacket добавить нем­ного кода, который мож­но най­ти на GitHub.

INFO

ESC11 — это одна из тех­ник для повыше­ния при­виле­гий в AD через центр сер­тифика­ции, осно­ван­ная на выпус­ке сер­тифика­та через RPC.

Вот cсыл­ка на пер­воис­точник опи­сания тех­ники.

Для экс­плу­ата­ции ESC11 дос­таточ­но сле­дующей коман­ды:

impacket-ntlmrelayx -t rpc://<CA IP> -rpc-mode ICPR -icpr-ca-name <CA name> --template "template name"

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

HTTP (80/TCP)

Пе­ресыл­ка аутен­тифика­ции на HTTP воз­можна с любого дру­гого про­токо­ла, основной век­тор экс­плу­ата­ции — это AD CS ESC8.

INFO

ESC8 — это одна из тех­ник для повыше­ния при­виле­гий в AD через центр сер­тифика­ции, осно­ван­ная на выпус­ке сер­тифика­та через WEB. Вот ссыл­ка на пер­воис­точник опи­сания тех­ники.

При поис­ке AD CS без учет­ной записи мож­но про­верить все кон­трол­леры, а так­же все обна­ружен­ные Windows Server на дос­тупность URL вида http://<CA IP>/certsrv. С учет­ной записью все гораз­до про­ще, мож­но вос­поль­зовать­ся удоб­ным инс­тру­мен­том Certipy.

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

impacket-ntlmrelayx -t "http://<CA IP>/certsrv/certfnsh.asp" --adcs --template "template name"

На рисун­ке ниже при­веден при­мер Relay с RPC на HTTP.

Вот при­мер пересыл­ки аутен­тифика­ции с RAW на HTTP и реали­зация ата­ки ESC8.

INFO

По­мимо повыше­ния при­виле­гий, дан­ную тех­нику мож­но исполь­зовать для получе­ния началь­ного дос­тупа в домене. Если на эта­пе раз­ведки уда­лось обна­ружить AD CS с вклю­чен­ным WebEnroll, то при получе­нии NTLM-аутен­тифика­ций мож­но сра­зу нацелить­ся на получе­ние сер­тифика­та и таким обра­зом получить зак­репле­ние. 

ВЫВОДЫ

Ес­ли с бру­том все ясно: находишь тип хеша и запус­каешь hashcat, то с Relay не все так однознач­но. Из‑за раз­личных осо­бен­ностей не всег­да понят­но, куда мож­но пересы­лать аутен­тифика­цию.

Для начала прос­то при­ведем таб­лицу экспе­римен­тов с Relay-ата­ками. Все экспе­римен­ты были про­веде­ны с помощью ntlmrelayx v0.10.0.

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

Аутен­тифика­цию с DCE RPC точ­но мож­но перес­лать на HTTP, SMB, RPC. В сочета­нии с тех­никами RemotePotato0 мож­но получить HTTP-аутен­тифика­цию от име­ни при­виле­гиро­ван­ного поль­зовате­ля и выпол­нить Relay на LDAP.

Аутен­тифика­цию с HTTP мож­но перес­лать куда угод­но, без огра­ниче­ний.

Аутен­тифика­цию с WCF точ­но мож­но пересы­лать на HTTP, SMB, RPC. С LDAP надо раз­бирать­ся отдель­но, с нас­кока не получи­лось. 

БОНУС

Мо­жет сло­жить­ся ситу­ация, ког­да на внут­реннем пен­тесте будет открыт дос­туп по VPN, который зап­реща­ет обратные соеди­нения — то есть при при­нуж­дении ни одна аутен­тифика­ция до ата­кующе­го долететь не смо­жет.

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

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

В слу­чае с дос­тупом к сетевым пап­кам все дос­таточ­но прос­то: выпол­няем Coerce на машину ата­кующе­го, далее Relay на SMB в инте­рак­тивном режиме на любой домен­ный узел без тре­бова­ния под­писи SMB. На схе­ме этот алго­ритм выг­лядит нем­ного понят­нее.

Ины­ми сло­вами, имея толь­ко локаль­ную учет­ку, впол­не реаль­но получить дос­туп к некото­рым домен­ным ресур­сам. Но мож­но выжать из это­го боль­ше. С помощью такого хит­рого спо­соба есть воз­можность при­нудить дру­гую машину пос­ле успешно­го Relay. Корот­ко схе­ма получит­ся такой: Coerce + Relay + Coerce + Relay = Admin.

А если кон­крет­нее, то такой кейс воз­можен, если на Exchange отклю­чен SMB Signing и Exchange находят­ся друг у дру­га в адми­нах, как это час­то быва­ет. С помощью локаль­ной учет­ки получа­ем домен­ную учет­ку машины и дела­ем Relay на SMB на Exchange1, пос­ле чего при­нудим его прой­ти аутен­тифика­цию на машине ата­кующе­го. Пос­ле получе­ния аутен­тифика­ции выпол­няем Relay на Exchange2 на SMB уже от име­ни Exchange1. На схе­ме это выг­лядит при­мер­но так.

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

ЗАЩИТА

В при­веден­ной таб­лице хорошо прос­лежива­ется тен­денция, что для защиты надо зак­рывать эндпо­инты, куда может быть совер­шен Relay. Если корот­ко:

1. Вклю­чить тре­бова­ние под­писи SMB-сооб­щений.
2. Вклю­чить тре­бова­ние под­писи LDAP.
3. Отклю­чить WebEnroll в AD CS.
4. Выс­тавить в AD CS флаг IF_ENFORCEENCRYPTICERTREQUEST в положе­ние True.
5. Регуляр­но уста­нав­ливать обновле­ния безопас­ности.

В боль­шинс­тве слу­чаев Relay воз­можен из‑за неболь­ших недос­татков в нас­трой­ках инфраструк­туры, поэто­му защитить свой домен мож­но прос­тыми метода­ми.

ИТОГ

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

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei