Relay again

Ми­нут­ка исто­ричес­кого экскур­са. В кон­це 2023 года кол­леги из Specterops опуб­ликова­ли ис­сле­дова­ние, в котором под­робно рас­кры­ли тех­ники повыше­ния при­виле­гий в домене AD через экс­плу­ата­цию сер­веров SCCM (System Center Configuration Manager). С тех пор выш­ло еще нес­коль­ко кру­тых ресер­чей на ту же тему. Если хочешь фун­дамен­таль­но во всем разоб­рать­ся — доб­ро пожало­вать в ре­пози­торий на GitHub, где соб­раны и упо­рядо­чены тех­ники получе­ния уче­ток, повыше­ния при­виле­гий и пос­тэкс­плу­ата­ции, свя­зан­ные с SCCM. Здесь же я хочу наг­лядно про­демонс­три­ровать, как мож­но поль­зовать­ся ата­ками NTLM Relay на SCCM.

Теория

Для тех, кто толь­ко пог­ружа­ется в тему и еще не зна­ет, что такое SCCM, дам неболь­шую справ­ку. Итак, System Center Configuration Manager (с 2020 года известен как Microsoft Endpoint Configuration Manager, MECM) — это ПО для цен­тра­лизо­ван­ного управле­ния. В офи­циаль­ной докумен­тации мне не уда­лось обна­ружить чет­кого опре­деле­ния, что это за сущ­ность и зачем нуж­на, поэто­му я сфор­мулиро­вал его самос­тоятель­но.

Мож­но заметить, что это опре­деле­ние, по сути, опи­сыва­ет сам Active Directory (далее AD). На самом деле — и да и нет: Configuration Manager был соз­дан для облегче­ния жиз­ни ИТ‑адми­нис­тра­торам, а так­же для сни­жения зат­рат на адми­нис­три­рова­ние.

При­веду прос­той при­мер. Ког­да в тво­ей ком­пании тысяча сот­рудни­ков, с адми­нис­три­рова­нием может спра­вить­ся условно пять человек, а что, если ком­пания вырос­ла до десяти тысяч или даже ста тысяч человек? Най­мем пять­десят или пять­сот человек соот­ветс­твен­но? Конеч­но, мы хотим избе­жать линей­ной зависи­мос­ти, для это­го и был при­думан сна­чала AD, а пос­ле Configuration Manager.

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

Для под­твержде­ния моих слов — скрин­шот из офи­циаль­ной докумен­тации.

Так­же я выделил клю­чевую мысль: «может пов­лиять на каж­дый компь­ютер в орга­низа­ции». Но ого­ворюсь: при усло­вии, если компь­ютер находит­ся под управле­нием сер­вера SCCM.

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

Вот клю­чевые сос­тавля­ющие SCCM:

• Ар­хитек­тура «кли­ент‑сер­вер». Кли­ента­ми выс­тупа­ют все узлы домена, нап­ример DC или Exchange, а сер­вером — мас­тер SCCM.
• Ре­али­зова­на отка­зоус­той­чивость. Она дос­тига­ется добав­лени­ем пас­сивно­го сер­вера, готово­го перех­ватить обя­зан­ности мас­тера в слу­чае, если тот вый­дет из строя.
• Ра­бота­ет в тер­минах сай­тов. Здесь всё из офи­циаль­ной докумен­тации, прос­то нуж­но при­вык­нуть к тер­миноло­гии: сай­тов в одном домене AD может быть нес­коль­ко.
• Ре­али­зова­на иерар­хия сай­тов. Сай­ты могут быть свя­заны меж­ду собой дочер­ними отно­шени­ями. Каж­дый сайт мож­но ата­ковать незави­симо от дру­гого.
• Ре­али­зова­на ролевая модель. В сай­тах SCCM исполь­зует­ся хорошо про­рабо­тан­ная ролевая модель как для поль­зовате­лей, так и для сер­веров. Под­робно на этом оста­нав­ливать­ся не буду, в рам­ках статьи важ­ны толь­ко две роли: Full administrator для поль­зовате­лей и Site system servers для сер­веров. Под­робнее про ролевую модель сер­веров мож­но про­читать в до­кумен­тации (так­же — в раз­деле для поль­зовате­лей).
• Ис­поль­зует MSSQL. SCCM вооб­ще не может сущес­тво­вать без MSSQL. В БД хра­нит­ся вся слу­жеб­ная информа­ция, нап­ример таб­лицы с запися­ми про роли. Оснас­тка MSSQL может быть раз­верну­та на мас­тере, но зачас­тую выделя­ется в отдель­ный сер­вер.

Разведка

На этом пора закан­чивать с теорией и прис­тупать к прак­тике. В качес­тве стен­да я взял лабу GOAD. Если у тебя воз­никнет желание поп­робовать все опи­сан­ное ниже, то ты без проб­лем раз­вернешь стенд и про­ведешь тес­ты. Схе­ма стен­да дос­таточ­но понят­ная, у меня будет SCCM/MECM, кон­трол­лер домена, который не находит­ся под управле­нием SCCM, кли­ент SCCM и сер­вер с MSSQL для хра­нения всей слу­жеб­ной информа­ции.

Все даль­нейшие дей­ствия под­разуме­вают наличие у ата­кующе­го учет­ной записи в домене AD.

В пер­вую оче­редь мы дол­жны понять, есть ли в домене SCCM. Сде­лать это мож­но с помощью одно­го нехит­рого LDAP-зап­роса:

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

Пос­ле раз­ведки через LDAP мож­но про­вес­ти раз­ведку по SMB. Это будет впол­не по силам сде­лать руками.

Но луч­ше авто­мати­зиро­вать.

Бла­года­ря этой раз­ведке мы обна­ружи­ваем SiteCode и про­веря­ем SMB Signing. Отсутс­твие тре­бова­ния под­писи SMB и SiteCode необ­ходимы для даль­нейших атак.

Сер­веры мы обна­ружи­ли, теперь повысим при­виле­гии нес­коль­кими спо­соба­ми.

TAKEOVER1

Сно­ва обра­тим­ся к схе­ме стен­да.

На ней чет­ко вид­но, что учет­ная запись компь­юте­ра MECM$ явля­ется адми­нис­тра­тором базы дан­ных на сер­вере Microsoft SQL. Единс­твен­ная проб­лема — где взять учет­ку MECM$? Но тут вспо­мина­ем про ата­ку NTLM Relay и тех­нику при­нуж­дения к аутен­тифика­ции (Coerce).

За­пус­каем ntlmrelayx.

Вы­пол­няем ата­ку при­нуж­дения к аутен­тифика­ции с помощью PetitPotam.

По­лучаю положи­тель­ный резуль­тат — уста­нов­ленную сес­сию Microsoft SQL от име­ни MECM$.

Под­клю­чаюсь к SCCM, исполь­зуя уста­нов­ленную сес­сию.

Пос­ле получе­ния шел­ла про­бую по клас­сике выпол­нить код через xp_cmdshell.

Итак, у меня есть RCE на сер­вере SCCM/MECM, но прав­да ли это конеч­ная цель? Более того, учет­ка sccm-sql — это локаль­ный адми­нис­тра­тор на сер­вере.

И тут про­вер­ка на вни­матель­ность. В самом начале статьи я упо­мянул, что сай­ты SCCM стро­ятся на Microsoft SQL и вся информа­ция о ролях хра­нит­ся в БД. Поп­робую выпол­нить нес­коль­ко SQL-зап­росов, что­бы добавить сво­ей учет­ке роль адми­нис­тра­тора и пра­ва на выпол­нение скрип­тов.

Да­вай раз­берем­ся, что про­изош­ло выше. Я встав­ляю стро­ку в таб­лицу с говоря­щим наз­вани­ем RBAC_Admins. Длин­ное зна­чение из непонят­ных сим­волов — это шес­тнад­цатерич­ное пред­став­ление SID поль­зовате­ля, которо­го надо добавить в адми­нис­тра­торы. Зна­чение SourceSite — это имя сай­та, которое обна­ружи­ли на эта­пе раз­ведки по SMB.

Да­лее еще нуж­но накинуть при­виле­гии на опре­делен­ные типы объ­ектов.

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

Для любите­лей авто­мати­зации: sccmhunter поможет соб­рать пра­виль­ные SQL-зап­росы, и оста­нет­ся их толь­ко выпол­нить.

Итак, на этом эта­пе я успешно повысил при­виле­гии в рам­ках сай­та SCCM, а как это экс­плу­ати­ровать, рас­ска­жу чуть поз­же. Сна­чала — про дру­гие методы повыше­ния при­виле­гий.

TAKEOVER2

Ты еще пом­нишь схе­му, которую я раз­бирал в начале опи­сания TAKEOVER1? Обра­тим­ся к ней сно­ва.

На схе­ме чет­ко вид­но, что учет­ная запись компь­юте­ра MECM$ находит­ся в груп­пе локаль­ных адми­нис­тра­торов на сер­вере Microsoft SQL. При такой кон­фигура­ции ата­кующий может поп­робовать реали­зовать NTLM Relay на SMB или RPC. В этом и зак­люча­ется суть TAKEOVER2, но не без нюан­сов. Впро­чем, с ними сей­час раз­берем­ся.

За­пус­каю ntlmrelayx для выпол­нения ата­ки.

Вы­пол­няю при­нуж­дение к аутен­тифика­ции с помощью PetitPotam.

По­лучаю положи­тель­ный резуль­тат.

Пос­ле успешно уста­нов­ленной SMB-сес­сии сра­зу про­бую соз­дать дамп веток реес­тра HKLM\SAM и HKLM\SECURITY.

В резуль­тате получаю учет­ную запись локаль­ного адми­нис­тра­тора на ата­куемом сер­вере, саму учет­ную запись сер­вера, а еще учет­ную запись sccm-sql с паролем в откры­том виде.

В этот момент сно­ва вспо­минаю схе­му и понимаю, что учет­ная запись sccm-sql — это адми­нис­тра­тор БД на сер­вере Microsoft SQL. Поп­робую под­клю­чить­ся к БД.

Сно­ва получаю шелл на Microsoft SQL, а даль­ше ата­ка сво­дит­ся к TAKEOVER1. По ана­логии с пре­дыду­щим кей­сом выпол­няю четыре SQL-зап­роса для повыше­ния при­виле­гий в рам­ках сай­та SCCM. Выпол­няю код на целевом устрой­стве, которым зачас­тую явля­ется кон­трол­лер домена.

TAKEOVER5

Соз­датель стен­да GOAD не зак­ладывал воз­можность демонс­тра­ции этой тех­ники, но, если очень захотеть, мож­но про­тес­тировать и ее.

Суть тех­ники зак­люча­ется в про­веде­нии ата­ки NTLM Relay на HTTP для повыше­ния при­виле­гий через WMI. Что­бы про­вес­ти ата­ку, понадо­бит­ся про­пат­чить ntlmrelayx.

Нам понадо­бит­ся любая учет­ная запись в домене AD, плюс нуж­но знать SID этой учет­ной записи. Его мож­но пос­мотреть в BloodHound в атри­бутах поль­зовате­ля или зап­росить через LDAP, нап­ример как на скрин­шоте ниже.

За­пус­каем ntlmrelayx, что­бы про­вес­ти ата­ку и повысить при­виле­гии на сай­те SCCM поль­зовате­лю eve. NTLM Relay нап­равле­на на SMS-сер­вер, который может быть нас­тро­ен на мас­тере или вынесен на отдель­ный узел.

Те­перь исполь­зуем при­нуж­дение к аутен­тифика­ции, нап­ример с помощью PetitPotam, про­тив мас­тер‑сер­вера или резер­вно­го. Но стенд не пре­дус­матри­вает наличие двух таких сер­веров, поэто­му искусс­твен­но приш­лю аутен­тифика­цию на ntlmrelayx.

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

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

Повышение привилегий в домене AD

Я триж­ды смог повысить пра­ва сво­ей учет­ке до пол­ного адми­нис­тра­тора сай­та SCCM, но что это дает? Воз­можность выпол­нения команд через SCCM API. Сде­лать это мож­но через оснас­тку с помощью SharpSCCM или sccmhunter.

Что­бы начать вза­имо­дей­ство­вать с каким‑либо компь­юте­ром в домене, сна­чала нуж­но най­ти иден­тифика­тор целево­го хос­та на сай­те SCCM. Дела­ется это в одну коман­ду через sccmhunter.

В получен­ном выводе обра­щаем вни­мание на поле ResourceId.

Те­перь поп­робу­ем выпол­нить коман­ды непос­редс­твен­но на компь­юте­ре.

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

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

В sccmhunter реали­зова­на механи­ка под­твержде­ния скрип­та вто­рым адми­нис­тра­тором, поэто­му сра­зу ука­зываю две учет­ные записи и выпол­няю нуж­ные дей­ствия.

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

Защита

В целом методы защиты от атак NTLM Relay обсужда­ются со вре­мен появ­ления самой ата­ки. Защищать­ся нуж­но от получе­ния ата­кующим NTLM-аутен­тифика­ции (spoofing, MITM, Coerce и про­чих методов), а так­же сто­ит защищать конеч­ные точ­ки, куда NTLM Relay будет нап­равле­на (SMB, MSSQL, HTTP, LDAP, RPC). Под­робнее мож­но про­читать в офи­циаль­ной статье Microsoft или в пре­дыду­щих стать­ях про NTLM Relay. Здесь же хочу под­робно разоб­рать защиту имен­но от NTLM Relay на Microsoft SQL, так как ранее эта тех­ника не была нас­толь­ко полез­ной.

Microsoft SQL

В Microsoft уже дав­но поняли, что от NTLM Relay надо защищать­ся, и раз­работа­ли штат­ные средс­тва для это­го. Называ­ются они Extended Protection и Force Encryption. Нас­тро­ить их мож­но с помощью стан­дар­тной оснас­тки SQL от Microsoft.

1. Откры­ваем оснас­тку.
2. Рас­кры­ваем SQL Server Network Configuration.
3. Нажима­ем пра­вой кноп­кой мыши на Protocols for MSSQLSERVER.
4. Выбира­ем Properties.
5. Нажима­ем Advanced.
6. Меня­ем зна­чение Extended Protocols Protection: Required.
7. Нажима­ем Flags.
8. Меня­ем зна­чение Force Encryption: Yes.
9. Нажима­ем Apply.
10. На­жима­ем OK.

Бонус

Не­боль­шой бонус для ата­кующих и защит­ников. Как мас­сово про­верить инфраструк­туру на наличие тре­бова­ния под­писи Microsoft SQL? Есть удоб­ный инс­тру­мент mssqlrelay. Он пока не уме­ет работать по под­сетям или фай­лам с тар­гетами, но всег­да мож­но запус­тить его в цик­ле.

С его помощью лег­ко про­верить, вклю­чена ли защита на конеч­ных точ­ках.

За­час­тую на реаль­ных пен­тестах защита конеч­ных точек Microsoft SQL отклю­чена.

Выводы

В статье рас­смот­рено три кей­са с NTLM Relay на SCCM, но на самом деле их сущес­тву­ет боль­ше. Но все они стро­ятся на уже извес­тных тебе по пре­дыду­щим стать­ям тех­никах, нап­ример NTLM Relay на LDAP + кейс с RBCD или ShadowCreds. Или NTLM Relay на ADCS для выпус­ка сер­тифика­та от име­ни мас­тер‑сер­вера с даль­нейшим его зах­ватом.

Вто­рой вывод — рано еще спи­сывать со сче­тов ста­рую доб­рую ата­ку NTLM Relay, я думаю, еще дол­гое вре­мя NTLM будет сущес­тво­вать в инфраструк­турах. Отка­зать­ся от него неп­росто, и даже на Windows 11 и Server 2022 его будут намерен­но вклю­чать для под­дер­жки легаси.