HTB Anubis. Захватываем домен через сертификаты Active Directory

Разведка. Сканирование портов

До­бав­ляем IP-адрес машины в /etc/hosts, что­бы было удоб­нее обра­щать­ся к ней:

И запус­каем ска­ниро­вание пор­тов.

На­ходим четыре откры­тых пор­та:

• 135 — служ­ба уда­лен­ного вызова про­цедур (Microsoft RPC). Исполь­зует­ся для опе­раций вза­имо­дей­ствия кон­трол­лер — кон­трол­лер и кон­трол­лер — кли­ент;
• 443 — веб‑сер­вер Microsoft HTTPAPI;
• 445 — служ­ба SMB;
• 593 — служ­ба уда­лен­ного вызова про­цедур (Microsoft RPC над HTTPS).

Порт 443 обес­печива­ет соеди­нение по HTTPS, а это зна­чит, что пер­вым делом сто­ит изу­чить сер­тификат. Его поле commonName содер­жит домен­ные име­на, для которых он дей­стви­телен (Nmap тут же отоб­разит это в резуль­татах ска­ниро­вания). Сра­зу добав­ляем най­ден­ные домены в /etc/hosts.

Те­перь перей­дем к веб‑сер­веру, где нас встре­тит однос­тра­нич­ный сайт.

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

Что прив­лекло мое вни­мание — это отоб­ражение всех вве­ден­ных дан­ных на стра­нице https://www.windcorp.htb/preview.asp.

По­луча­ется, что сайт не однос­тра­нич­ный! Давай поп­робу­ем най­ти дру­гие скры­тые стра­ницы сай­та.

Так как уже обна­руже­на одна стра­ница в фор­мате ASP, осталь­ные будем переби­рать с таким же рас­ширени­ем. Запус­каем ffuf:

Спус­тя нес­коль­ко минут мы узна­ем еще о нес­коль­ких стра­ницах. Самая инте­рес­ная из них — test.asp, которая прос­то фор­матиру­ет наши дан­ные.

Это мес­то для тес­та!

Захват контейнера

Так как дан­ные попада­ют в исполня­емый файл ASP, то самая прос­тая идея — это поп­робовать записать в поле ком­мента­рия какой‑нибудь шелл на ASP. К при­меру, этот:

И уже на стра­нице под­твержде­ния видим некото­рый вывод. Неп­лохо, одну уяз­вимую стра­ницу уже наш­ли!

Ко­неч­но, удоб­нее все­го получить какую‑нибудь прод­винутую обо­лоч­ку, к при­меру Meretpreter. Сна­чала сге­нери­руем исполня­емый файл с помощью msfvenom, для которо­го исполь­зуем сле­дующие парамет­ры:

• -p [] — наг­рузка;
• LHOST=[] — IP локаль­ного хос­та;
• LPORT=[] — локаль­ный порт;
• -f [] — фор­мат, в котором будет пред­став­лена наг­рузка;
• -o — ито­говый файл.

Сле­дующий шаг — запуск лис­тенера MSF.

Из катало­га, где находит­ся файл с наг­рузкой, запус­каем прос­той веб‑сер­вер на осно­ве Python 3.

И через веб‑шелл ска­чива­ем нашу наг­рузку, а вто­рой коман­дой — запус­каем. Это при­ведет к соз­данию сес­сии Meterpreter в Metasploit. Коман­дой getuid про­веря­ем текуще­го поль­зовате­ля, от име­ни которо­го запущен файл.

Мы работа­ем в кон­тек­сте System, а для даль­нейше­го прод­вижения могут понадо­бить­ся учет­ные дан­ные. Дам­пим хеши из локаль­ной базы SAM с помощью hashdump, вдруг где‑то при­годит­ся.

Продвижение

Поиск хостов

Прос­матри­ваем фай­лы на хос­те и находим на рабочем сто­ле адми­нис­тра­тора сер­тификат.

Ко­пиру­ем его содер­жимое на локаль­ную машину и сох­раня­ем с рас­ширени­ем crt. Затем мож­но прос­то открыть этот файл (любая сис­тема дол­жна рас­познать и отоб­разить содер­жимое сер­тифика­та).

Так мы узна­ем еще одно домен­ное имя — softwareportal.windcorp.htb. Попыта­емся получить дос­туп к это­му хос­ту, но спер­ва выяс­ним его реаль­ный адрес. Пер­вым делом орга­низу­ем SOCKS-прок­си с помощью прог­раммы chisel. Нам пот­ребу­ется и вер­сия для Windows, и вер­сия для Linux. Запус­тим на локаль­ном хос­те сер­вер, ука­зав порт для под­клю­чения (опция -p), тип прок­си (--socks5) и то, что он дол­жен ожи­дать под­клю­чения.

За­тем заг­рузим на уда­лен­ный хост вер­сию для Windows и под­клю­чим­ся. В логах сер­вера уви­дим сооб­щение о под­клю­чении кли­ент­ской час­ти.

Те­перь добавим домен­ное имя в файл /etc/hosts. А в качес­тве адре­са будем исполь­зовать Gateway-адрес сис­темы.

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

На сай­те есть спи­сок прог­рам­мно­го обес­печения. Если выб­рать любой пункт, ты перей­дешь по ссыл­ке и уви­дишь сооб­щение о начале уста­нов­ки ПО.

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

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

Для удобс­тва прос­мотра тра­фика мож­но акти­виро­вать филь­тр, я исполь­зовал not tcp.port == 80, что­бы отсе­ять обра­щения к уда­лен­ному хос­ту. В выводе видим пакеты чер­ного цве­та, что говорит о сбро­се соеди­нения (зак­рытый порт). Про­исхо­дит обра­щение к нашему хос­ту на порт 5985 — там работа­ет служ­ба WinRM. Таким обра­зом, уда­лен­ный хост для уста­нов­ки ПО пыта­ется под­клю­чить­ся к служ­бе WinRM хос­та, адрес которо­го передан в парамет­ре client при зап­росе на уста­нов­ку ПО.