В погоне за билетом

Де­ло было осенью 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 в пре­делах MSSQL, чем я и вос­поль­зовал­ся, что­бы вклю­чить обо­лоч­ку 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 и не вхо­дила в сос­тав домен­ных адми­нис­тра­тив­ных групп, она ока­залась вла­дель­цем учет­ных записей адми­нис­тра­торов, отве­чающих за реги­он «ОМСК».

Пра­ва локаль­ного адми­нис­тра­тора поз­волили извлечь TGT-билет Kerberos для test.local\admin-omsk из памяти сис­темно­го про­цес­са и выпол­нить ата­ку Pass the Ticket.

Пос­коль­ку учет­ная запись test.local\admin-omsk была вла­дель­цем в том чис­ле учет­ной записи test.local\omo-adminvrs, я добавил для нее при­виле­гии GenericAll. Это откры­ло воз­можность про­вес­ти ата­ку Shadow Credentials, при которой генери­рует­ся пара клю­чей и откры­тый ключ записы­вает­ся в атри­бут ms-DS-Key-Credential-Link. С помощью этой пары из откры­того и зак­рытого клю­чей уда­лось зап­росить TGT-билет Kerberos и исполь­зовать его для аутен­тифика­ции в домене.

Я уста­новил, что чле­ны груп­пы omo-admin-group, вклю­чая учет­ную запись test.local\omo-adminvrs, име­ют пра­ва (ACL) на 4507 объ­ектов в домене. Сре­ди этих прав — GenericWrite на сер­веры SRVDIRECTUM-SQL и SRV-ND-PROD-WIN. В поис­ках вари­антов ком­про­мета­ции домена и учет­ных записей с повышен­ными при­виле­гиями я про­вел ата­ку Shadow Credentials на объ­ект SRVDIRECTUM-SQL$ и получил воз­можность зап­росить для него билет TGT.

Сле­дующим шагом я извлек NTLM-хеш компь­ютер­ной учет­ной записи SRVDIRECTUM-SQL$ с помощью UnPAC the Hash.

Эта тех­нология осно­вана на исполь­зовании PKINIT, при котором кли­ент может зап­росить допол­нитель­ный тикет. В этом тикете KDC вклю­чает PAC_CREDENTIAL_INFO — спе­циаль­ную струк­туру, содер­жащую NTLM-клю­чи аутен­тифици­рующе­го поль­зовате­ля. Это дает кли­енту воз­можность перек­лючать­ся на NTLM-аутен­тифика­цию для служб, которые не под­держи­вают Kerberos.

По­лучен­ный NTLM-хеш исполь­зовал­ся в тех­нике Silver Ticket, которая поз­воля­ет генери­ровать сер­висные билеты (TGS) Kerberos для любых домен­ных учет­ных записей. Эти билеты будут обла­дать все­ми при­виле­гиями на хос­те, которы­ми обла­дал бы зашед­ший на хост поль­зователь. В резуль­тате мы сге­нери­рова­ли сер­висные билеты для домен­ного адми­нис­тра­тора test.local\d.syroezhkin, у которо­го есть пра­ва локаль­ного адми­на на хос­те SRVDIRECTUM-SQL.

С получен­ными пра­вами уда­лось соз­дать дамп про­цес­са LSASS и извлечь из него пароли еще для некото­рых домен­ных уче­ток.

Та­ким же спо­собом я получил дос­туп к хос­ту SRV-ND-PROD-WIN.

В памяти про­цес­са LSASS ничего инте­рес­ного не наш­лось. Поэто­му мы соб­рали дан­ные о локаль­ных учет­ных записях из хра­нили­ща SAM. В резуль­тате получи­ли хеш NTLM для локаль­ной учет­ной записи Administrator и перебо­ром по сло­варю извлек­ли пароль Pa******123.

В резуль­тате ата­ки Pass the Hash я уста­новил, что эта учет­ная запись с таким же паролем исполь­зует­ся на сле­дующих сер­верах:

• SRV-ND-PROD-ACCEPT.TEST.LOCAL;
• SRV-ND-PROD-AUT.TEST.LOCAL;
• SRV-ND-PROD-WIN-KODWEB.TEST.LOCAL;
• HV1-GORIZONT.TEST.LOCAL;
• SRV-WITNESS-EX.TEST.LOCAL.

Осо­бый инте­рес пред­став­ляет сер­вер SRV-WITNESS-EX. Он вхо­дит в груп­пы Exchange Trusted Subsystem и Exchange Windows Permissions как сер­вер Exchange.

В свою оче­редь, Exchange Windows Permissions может добав­лять чле­нов в груп­пу AD_Mgmt, которая име­ет пра­ва GenericWrite на кон­трол­леры домена.

Для начала, исполь­зуя пра­ва локаль­ного адми­нис­тра­тора, я извлек хеш NTLM-пароля компь­юте­ра из локаль­ного хра­нили­ща LSA на хос­те SRV-WITNESS-EX. Получен­ный хеш NTLM я исполь­зовал в ата­ке Overpass the Hash для получе­ния TGT-билета Kerberos. Это поз­волило внес­ти изме­нения в сос­тав домен­ной груп­пы AD_Mgmt. При этом исполь­зовалась домен­ная учет­ная запись wa, ском­про­мети­рован­ная ранее на хос­те SRVDIRECTUM-SQL.

В качес­тве конеч­ной цели я выб­рал кон­трол­лер домена SRVDC01. Через ата­ку Shadow Credentials уда­лось сге­нери­ровать пару клю­чей, с помощью которых я получил TGT-билет Kerberos для учет­ной записи кон­трол­лера домена. Пос­ле это­го про­вел ата­ку DCSync на учет­ную запись test.local\admin-voinov, что поз­волило извлечь хеш AES256 от ее пароля. Билет TGT так­же открыл дос­туп на сам кон­трол­лер домена.

Рекомендации

По ито­гам тес­тирова­ния я дал заказ­чику сле­дующие рекомен­дации:

• сме­нить пароль для ском­про­мети­рован­ной локаль­ной учет­ной записи LocalAdmin на всех машинах;
• сме­нить пароль для ском­про­мети­рован­ной локаль­ной учет­ной записи admin-omsk на всех машинах;
• уда­лить скрип­ты, содер­жащие пароли;
• вмес­то скрип­тов исполь­зовать тех­нологию LAPS;
• отклю­чить механизм wdigest, который поз­воля­ет хра­нить пароли в откры­том виде;
• нас­тро­ить анти­вирус на зап­рет дам­па про­цес­са LSASS;
• про­вес­ти оцен­ку прав для груп­пы omo-admin-group в отно­шении дру­гих объ­ектов домена на пред­мет их избы­точ­ности.

Выводы

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

Пос­ле получе­ния дос­тупа в домен мне уда­лось получить дос­туп к цепоч­ке про­межу­точ­ных сер­веров, что в ито­ге дало адми­нис­тра­тив­ный дос­туп к кон­трол­леру домена. К ком­про­мета­ции домена при­вели нес­коль­ко клю­чевых фак­торов: откры­тое хра­нение паролей в скрип­тах, исполь­зование сла­бых паролей для адми­нис­тра­тив­ных учет­ных записей и небезо­пас­ная нас­трой­ка ACL, которая поз­воляла зло­упот­реблять избы­точ­ными пра­вами объ­ектов домена.

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