В погоне за билетом. Как мы дважды проникли в домен, который считался неприступным

Де­ло было осенью 2022 года. Мы работа­ли вдво­ем с кол­легой: он отве­чал за веб‑уяз­вимос­ти, а я за ана­лиз инфраструк­туры — сер­висы, домен и про­чее.

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

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

И дей­стви­тель­но, про­ект ока­зал­ся неп­ростым, учет­ную запись в домене мне не пре­дос­тавили. Я про­верил воз­можность LLMNR poisoning и про­чие вари­ации этой ата­ки, поп­робовал слу­шать тра­фик, ска­ниро­вал на пред­мет наличия популяр­ных уяз­вимос­тей (Bluekeep, EternalBlue и тому подоб­ных), про­верил ано­ним­ные фай­ловые ресур­сы, нашел и изу­чил прин­теры и МФУ. Веб тоже не дал никаких надежд.

В один прек­расный момент мне повез­ло: я нашел три хос­та с активным сер­висом DameWare, из них домен­ный был толь­ко один. В некото­рых вер­сиях это­го про­дук­та есть уяз­вимость CVE-2019-3980, поз­воля­ющая получить несан­кци­они­рован­ный уда­лен­ный дос­туп к ата­куемой сис­теме.

Вер­сия DameWare ока­залась уяз­вимой, и мне уда­лось соз­дать локаль­ную учет­ную запись адми­нис­тра­тора, извлечь учет­ные дан­ные из памяти про­цес­са LSASS и раз­вить ата­ку до пол­ной ком­про­мета­ции домена. Опу­щу под­робнос­ти это­го век­тора, они не пред­став­ляют осо­бого инте­реса, он был дос­таточ­но три­виален. Дру­гих век­торов нам обна­ружить тог­да не уда­лось. Самое инте­рес­ное было даль­ше.

Ход атаки

С заказ­чиком у нас был зак­лючен договор сра­зу на два про­екта, и вес­ной 2023 года мы вер­нулись к нему сно­ва, в ту же самую инфраструк­туру, с той же самой точ­кой под­клю­чения, сер­висов DameWare в сети уже не наш­ли. Заказ­чик с еще боль­шей уве­рен­ностью стал заяв­лять, что в этот раз у нас точ­но ничего не получит­ся, так как все замеча­ния и единс­твен­ный най­ден­ный нами баг они устра­нили. Даже спор сно­ва пред­ложил, а мы сно­ва отка­зались. И сно­ва пожале­ли об этом!

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

И тут на одном из веб‑ресур­сов мне попалось опуб­ликован­ное .NET-при­ложе­ние.

Пос­ле нажатия кноп­ки Start на стра­нице http://ppo-app.test.local/ про­исхо­дит ска­чива­ние исполня­емых фай­лов при­ложе­ния во вре­мен­ную дирек­торию на компь­юте­ре поль­зовате­ля. Я под­робно изу­чил ска­чан­ное при­ложе­ние и выяс­нил, что оно под­клю­чает­ся к базе дан­ных Microsoft SQL, раз­мещен­ной на хос­те PPO-BD.test.local. Учет­ные дан­ные для под­клю­чения к базе находят­ся в фай­ле star.exe.config, который ска­чива­ется вмес­те с при­ложе­нием.

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

Для рас­шифров­ки пароля я деком­пилиро­вал при­ложе­ние с помощью ILSpy. В динами­чес­кой биб­лиоте­ке Star.Wpf.Controls.dll наш­лась фун­кция EncryptionLogic, содер­жащая ключ шиф­рования и алго­ритм рас­шифров­ки. В резуль­тате мне уда­лось получить пароль от учет­ной записи базы дан­ных asabrys (это не домен­ная учет­ная запись). Затем с помощью DBeaver я под­клю­чил­ся к базе дан­ных.

У ском­про­мети­рован­ной учет­ки были пра­ва sysadmin в пре­делах MS SQL, чем я и вос­поль­зовал­ся, что­бы вклю­чить обо­лоч­ку xp_cmdshell, поз­воля­ющую исполнять коман­ды опе­раци­онной сис­темы.

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

Что­бы заг­рузить необ­ходимые инс­тру­мен­ты на хост PPO-BD.test.local, я раз­вернул FTP-сер­вер на рабочей стан­ции, с которой про­водил тес­тирова­ние. Для эска­лации при­виле­гий до уров­ня SYSTEM я исполь­зовал инс­тру­мент SharpImpersonation. С его помощью соз­дал учет­ку локаль­ного адми­нис­тра­тора itadmin. Затем со сво­его компь­юте­ра под­клю­чил­ся к хос­ту PPO-BD.test.local по про­токо­лу RDP и с помощью обфусци­рован­ной сбор­ки Mimikatz соз­дал дамп памяти сис­темно­го про­цес­са lsass.exe и извлек хра­нящи­еся там учет­ные дан­ные.

В дам­пе памяти нашел­ся NTLM-хеш пароля учет­ной записи компь­юте­ра test.local\PPO-BD$. Дру­гих акту­аль­ных домен­ных уче­ток на хос­те PPO-BD.test.local не было.

Я исполь­зовал Rubeus, что­бы зап­росить TGT-билет Kerberos для учет­ной записи test.local\PPO-BD$, исполь­зуя NTLM-хеш ее пароля. Это поз­волило получить дос­туп в домен test.local.

Ис­поль­зуя учет­ную запись компь­юте­ра PPO-BD$, я соб­рал информа­цию о домене, вклю­чая дан­ные о груп­повых полити­ках. При ана­лизе скрип­тов, запус­каемых эти­ми полити­ками, уда­лось най­ти нес­коль­ко фай­лов, в которых был про­писан пароль для локаль­ной учет­ной записи LocalAdmin.

Я под­клю­чил­ся к сер­веру OMO-FSCHANGE.test.local от име­ни учет­ной записи LocalAdmin. Быс­трый осмотр содер­жимого дис­ков не при­нес ничего полез­ного — цен­ных дан­ных не наш­лось, активных сес­сий адми­нис­тра­торов тоже не было. Зато уда­лось сде­лать дамп хра­нили­ща локаль­ных учет­ных записей (LSA).

Из­вле­чен­ные из LSA локаль­ные учет­ные дан­ные вклю­чали NTLM-хеш локаль­ной учет­ки admin-omsk, которая сос­тоит в груп­пе локаль­ных адми­нис­тра­торов. Пос­ле перебо­ра хеша по сло­варю уда­лось вос­ста­новить пароль — 16010916.

С помощью локаль­ной учет­ной записи admin-omsk я получил дос­туп к сер­веру OMO-TECH.test.local. На этом сер­вере нашел активную сес­сию учет­ной записи с таким же име­нем, но уже домен­ной — test.local\admin-omsk.

Хоть учет­ная запись test.local\admin-omsk и не вхо­дила в сос­тав домен­ных адми­нис­тра­тив­ных групп, она ока­залась вла­дель­цем учет­ных записей адми­нис­тра­торов, отве­чающих за реги­он «ОМСК».