Инфра в огне. Как мы пентестили сети двух крупных российских компаний

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

• Кейс 1: небезопасная конфигурация RDWeb
• Собираем инфу о внешнем периметре
• Компрометация домена
• Узел 2
• Недопустимое событие
• Кейс 2: от SQL-инъекции до NTLM-relay через туннель
• Узел 1
• Узел 2
• Узел 3
• Выводы

В этой статье я рас­ска­жу про два кей­са из моей прак­тики пен­тестов внеш­него перимет­ра, в которых уда­лось при­менить нес­коль­ко нес­тандар­тных под­ходов с пос­леду­ющим «клас­сичес­ким» получе­нием при­виле­гий адми­нис­тра­тора домена. Pentest Award

Этот текст получил чет­вертое мес­то на пре­мии Pentest Award 2024 в катего­рии «Про­бив инфры». Это сорев­нование еже­год­но про­водит ком­пания Awilix.

Кейс 1: небезопасная конфигурация RDWeb

За­каз­чиком была ком­пания, которая сущес­тву­ет с 2009 года и занима­ется финан­совой деятель­ностью. Ее выруч­ка за 2023 год — 12 мил­лиар­дов руб­лей, количес­тво сот­рудни­ков — свы­ше 2 тысяч, кли­ентов — боль­ше 3 мил­лионов. У ком­пании зре­лая ИТ- и ИБ‑инфраструк­тура, еже­год­но про­ходят тес­тирова­ния на про­ник­новение.

Этот кейс инте­ресен тем, что нам попалась небезо­пас­ная кон­фигура­ция Remote Desktop Gateway: валид­ный поль­зователь домена в веб‑интерфей­се RDWeb не име­ет при­ложе­ний для уда­лен­ного дос­тупа, но может исполь­зовать RDWeb как шлюз для RDP-под­клю­чения к некото­рым хос­там внут­ри сети.

Для экс­плу­ата­ции мы написа­ли на Python сце­нарий авто­мати­зации, который спре­ит учет­ные дан­ные валид­ных поль­зовате­лей по хос­там внут­ренней сети и ищет раз­решения на под­клю­чение по RDP.

Собираем инфу о внешнем периметре

Ни­какой информа­ции о сис­теме у нас не было, поэто­му пол­ный «чер­ный ящик».

Сна­чала я покопал­ся в интерне­те, что­бы соб­рать всё, что свя­зано с сис­темами ком­пании: IP-адре­са, домены и про­чее. Выш­ло боль­ше 50 адре­сов, и я наметил самые пер­спек­тивные цели.

Даль­ше я прос­каниро­вал откры­тые пор­ты TCP и UDP. Пос­мотрел, какие сер­висы там работа­ют, и выписал вер­сии. Заод­но про­бежал­ся по под­доменам и порыл­ся в откры­тых источни­ках: репози­тории, сли­вы баз — всё, что кто‑то где‑то мог оста­вить на вид­ном мес­те.

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

Компрометация домена

Схе­ма ком­про­мета­ции домена

Про­веряя внеш­ний периметр, я нат­кнул­ся на инте­рес­ный узел. Там висело веб‑при­ложе­ние и отве­чало по адре­су https://mx02.*********.ru. Вход — толь­ко через NTLM-аутен­тифика­цию. Но, как ты понима­ешь, с NTLM воз­можно мно­го инте­рес­ного.

Веб‑при­ложе­ние

Я пус­тил в ход NTLM_challenger, и он выдал мне внут­ренний домен заказ­чика — *********.int, а так­же уда­лось опре­делить имя NetBIOS одно­го из сер­веров во внут­ренней инфраструк­туре — serv154.

Внут­ренний домен

Про­дол­жаем копать внеш­ний периметр. На одном из хос­тов отве­чал 443-й порт. На нем работал интерфейс для уда­лен­ки — Microsoft RD Web Login. А там, как это час­то быва­ет, уяз­вимость, которая дает рас­кру­тить име­на поль­зовате­лей через тай­минг зап­росов. Дер­гаешь логины и смот­ришь, где вре­мя откли­ка чуть длин­нее. Так мож­но узнать, какие из них сущес­тву­ют в сис­теме.

Я исполь­зовал модуль auxiliary/scanner/http/rdp_web_login из Metasploit и сло­варь с популяр­ными име­нами поль­зовате­лей. Что делать с най­ден­ными логина­ми, ты, я думаю, зна­ешь.

В ход, конеч­но же, пошел спре­инг паролей: берем один популяр­ный пароль и гоня­ем по все­му спис­ку уче­ток. Один из паролей <домен компании>123 подошел сра­зу к четырем поль­зовате­лям: support, expert, inform, robot.

Ре­зуль­тат под­бора пароля юзе­ра support

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

Веб‑интерфейс служ­бы уда­лен­ных рабочих сто­лов

Под­клю­чения к служ­бе уда­лен­ных рабочих сто­лов

Итак, име­ем NetBIOS-имя serv154. Логика под­ска­зыва­ет: ско­рее все­го, и осталь­ные ресур­сы наз­ваны по схе­ме serv + поряд­ковый номер.

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

Под­бор сетевых узлов

И бин­го! Есть дос­тупные для уда­лен­ного дос­тупа хос­ты. Даль­ше я под­клю­чил­ся по RDP к рабочей стан­ции ***serv130.

Под­клю­чение к serv130 от име­ни support 

Узел 2

Мне уда­лось най­ти IP-адрес Microsoft Exchange Server, куда я вошел от име­ни expert всё с тем же паролем. В резуль­тате получи­лось вытащить спи­сок всех поч­товых адре­сов Exchange.

Из­вле­каем поль­зовате­лей Exchange с помощью Ruler

Сле­дом я пус­тил в ход Exchanger.py. Запус­тил коман­ду dnt-lookup и через зап­росы DNT вытащил поболь­ше инфы про поль­зовате­лей — уже из Active Directory. Самое инте­рес­ное, что уда­лось най­ти, — это учет­ка L****H***D***. В ее поле description лежал пароль в откры­том виде.

Про­веря­ем под­клю­чение из Microsoft Outlook, и да, дей­стви­тель­но, пароль под­ходит.

Вход в учет­ку 

Недопустимое событие

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

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