Хакер - Только для чтения. Пентестим Read-only Domain Controllers

https://t.me/hacker_frei

MichelleVermishelle

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

• Теория
• Определения и особенности
• Атрибуты
• Аутентификация пользователей
• Поиск RODC
• Получение кешированных паролей с RODC
• DSRM
• Особенности работы Kerberos с RODC
• Key List
• Контроль над объектом RODC
• Заключение

В сетях на осно­ве Windows сущес­тву­ет спе­циаль­ный под­вид кон­трол­леров домена под наз­вани­ем Read-only Domain Controller. Сегод­ня мы погово­рим об уяз­вимос­тях таких кон­трол­леров и рас­смот­рим век­торы атак, которые мож­но к ним при­менить. 

ТЕОРИЯ

Определения и особенности

Read-only Domain Controller был пред­став­лен в Windows Server 2008. Его основная цель — обес­печить безопас­ное вза­имо­дей­ствие сер­вера со служ­бой катало­гов. Очень час­то подоб­ные кон­трол­леры домена ста­вят в каких‑нибудь уда­лен­ных офи­сах ком­пании, ста­рых фили­алах и про­чих мес­тах, где невоз­можно гаран­тировать дос­таточ­ную физичес­кую безопас­ность сер­вера. Получив дос­туп к такому устрой­ству, ни один зло­умыш­ленник не смо­жет тол­ком пов­лиять на домен.

Внут­ри RODC хра­нит­ся копия базы AD, но чуточ­ку изме­нен­ная. Во‑пер­вых, не сох­раня­ется мно­жес­тво атри­бутов, нап­ример ms-Mcs-AdmPwd — в этом атри­буте хра­нит­ся пароль локаль­ного адми­нис­тра­тора при нас­тро­енном LAPS. Во‑вто­рых, раз­решено кеширо­вать учет­ные дан­ные лишь кон­крет­ных поль­зовате­лей. Нап­ример, поль­зовате­лей это­го самого уда­лен­ного офи­са.

Что такое кеширо­вание? Это обыч­ное сох­ранение учет­ных дан­ных поль­зовате­лей. Сох­раня­ются они в фай­ле ntds.dit, рав­но как и на обыч­ном кон­трол­лере домена.

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

При этом исполь­зование RODC дает мно­жес­тво пре­иму­ществ в пла­не безопас­ности: отдель­ный DNS-сер­вер, изме­нения в котором никак не отра­жают­ся на основном, делеги­рова­ние роли адми­нис­тра­тора любому поль­зовате­лю (при­чем этот поль­зователь необя­затель­но дол­жен быть адми­нис­тра­тором на обыч­ных кон­трол­лерах домена).

Так­же сле­дует выделить осо­бен­ность реп­ликации (DCSYNC) — она воз­можна толь­ко со сто­роны обыч­ного кон­трол­лера домена. RODC ничего реп­лициро­вать не может. Так­же при­сутс­тву­ет изо­ляция SYSVOL — любые изме­нения в груп­повых полити­ках оста­ются на RODC и не рас­простра­няют­ся на основной домен.

Ес­ли рас­смат­ривать RODC на «тировой» архи­тек­туре Microsoft, то воз­ника­ют опре­делен­ные слож­ности, так как при­над­лежащие Tier 0 ресур­сы не могут работать в тех мес­тах, где дол­жны находить­ся RODC. А RODC не дол­жны иметь под кон­тро­лем какие‑либо ресур­сы из Tier 0. Поэто­му хос­ты RODC и учет­ные дан­ные для под­клю­чения к ним никак не могут при­над­лежать Tier 0, но вот сами компь­ютер­ные объ­екты RODC сле­дует защищать, как Tier 0.

Атрибуты

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

managedBy

Здесь ука­зыва­ется объ­ект, которо­му делеги­рова­но адми­нис­тра­тив­ное управле­ние RODC. Любой поль­зователь или груп­па, ука­зан­ные в этом атри­буте, явля­ются локаль­ными адми­нис­тра­тора­ми на RODC:

Get-ADComputer 'RODC' -prop managedBy

msDS-RevealOnDemandGroup, msDS-NeverRevealGroup

В этом атри­буте ука­зыва­ются объ­екты, учет­ные дан­ные которых могут кеширо­вать­ся. Кеширо­вание нуж­но для того, что­бы эти поль­зовате­ли мог­ли про­ходить про­вер­ку под­линнос­ти на RODC.

Get-ADComputer 'RODC' -prop msDS-RevealOnDemandGroup,msDS-NeverRevealGroup

Со­ответс­твен­но, сущес­тву­ет атри­бут, зап­реща­ющий кеширо­вание про­писан­ных в нем учет­ных дан­ных объ­ектов. Он называ­ется msDS-NeverRevealGroup.

msDS-AuthenticatedToAccountList

Здесь будут хра­нить­ся объ­екты, которые успешно аутен­тифици­рова­лись на RODC:

Get-ADComputer 'RODC' -prop msDS-AuthenticatedToAccountList

msDS-Revealed*

Это целая груп­па из нес­коль­ких атри­бутов:

• msDS-RevealedUsers — спи­сок объ­ектов, учет­ные дан­ные которых ког­да‑либо кеширо­вались на RODC;
• msDS-RevealedDSAs — спи­сок RODC, которые кеширо­вали пароль поль­зовате­ля;
• msDS-RevealedList — спи­сок объ­ектов, учет­ные дан­ные которых были успешно сох­ранены на RODC.

Get-ADComputer 'RODC' -prop msDS-RevealedList,msDS-RevealedDSAs,msDS-RevealedUsers

Аутентификация пользователей

RODC кеширу­ет учет­ные дан­ные опре­делен­ных поль­зовате­лей как раз таки, что­бы про­верить их под­линность. Пос­ле успешной аутен­тифика­ции по всем канонам дол­жен быть сге­нери­рован TGT-билет, но RODC нель­зя счи­тать надеж­ным KDC, поэто­му у него соз­дает­ся собс­твен­ная учет­ная запись krbtgt. Ее пароль исполь­зует­ся для под­писи соз­дава­емых TGT.

Упо­мяну­тая учет­ная запись име­ет необыч­ное имя: krbtgt_<цифры>. Эти самые циф­ры — спе­циаль­ный иден­тифика­тор клю­ча, который исполь­зовал­ся для шиф­рования TGT-билета. Имя новой учет­ной записи KRBTGT хра­нит­ся в атри­буте msDS-KrbTgtLink объ­екта RODC. А у этой самой новой учет­ной записи KRBTGT в атри­буте msDS-KrbTgtLinkBl содер­жится имя RODC. Таким обра­зом, обна­ружив RODC, мож­но свя­зать его с кон­крет­ным KRBTGT_XXXXX. И, соот­ветс­твен­но, обна­ружив KRBTGT_XXXXX, мож­но свя­зать его с кон­крет­ным RODC.

До­пол­нитель­но отме­чу, что RODC име­ет пра­во на сброс пароля этой самой KRBTGT_XXXXX.

Get-ADUser -filter {name -like "krbtgt*"} -prop Name,Created,PasswordLastSet,msDS-KeyVersionNumber,msDS-KrbTgtLinkBl

Get-ADComputer RODC -Properties msDS-KrbTgtLink

Get-ADUser krbtgt_19160 -Properties msDS-SecondaryKrbTgtNumber,msDS-KrbTGTLinkBl

ПОИСК RODC

Как я уже отме­тил, ты можешь обна­ружить учет­ную запись с име­нем KRBTGT_<цифры>, пос­ле чего гля­нуть ее атри­бут msDS-KrbTGTLinkBl и най­ти свя­зан­ный кон­трол­лер, но есть и иные спо­собы нахож­дения RODC.

Са­мый прос­той — исполь­зовать филь­тр:

Get-ADDomainController -filter {ISReadOnly -eq $True}

Так­же была обна­руже­на груп­па «Кон­трол­леры домена — толь­ко чте­ние» и «Кон­трол­леры домена пред­при­ятия — толь­ко чте­ние», которые име­ют RID 521 и 498 соот­ветс­твен­но. RODC вхо­дит в одну из этих групп в зависи­мос­ти от его уров­ня. Соот­ветс­твен­но, мы можем либо переб­рать все компь­юте­ры, ана­лизи­руя их атри­бут PrimaryGroupID, либо сна­чала получить GUID этих групп:

Get-ADGroup -filter {name -like "*чтен*"}

А затем извлечь учас­тни­ков:

Get-ADGroupMember -identity d876774c-474b-4a70-a3d9-e89998e5a99e

ПОЛУЧЕНИЕ КЕШИРОВАННЫХ ПАРОЛЕЙ С RODC

Пер­вым делом ты дол­жен получить прин­ципала, который име­ет пра­ва локаль­ного адми­нис­тра­тора на RODC. Это может быть ком­про­мета­ция как кого‑то при­виле­гиро­ван­ного, так и прос­то поль­зовате­ля, про­писан­ного в атри­буте managedBy. Но перед этим не забудь выяс­нить, кого вооб­ще мы можем ском­про­мети­ровать. Для это­го заг­ляни в атри­бут msDS-RevealedUsers:

Get-ADComputer 'RODC' -prop msDS-RevealedUsers,msDS-RevealOnDemandGroup,msDS-RevealedList

Столь боль­шие отли­чия не слу­чай­ны. Вро­де бы кеширо­вать раз­решено RACHAEL_LAMBERT и адми­нис­тра­тора, а закеши­рова­ны дан­ные толь­ко вто­рого, отку­да‑то взяв­шегося RODC и krbtgt_19160. Проб­лема зак­люча­ется в том, что кеширо­вания про­изой­дет толь­ко пос­ле успешной аутен­тифика­ции поль­зовате­ля в домене. То есть если RACHAEL_LAMBERT сей­час залоги­нит­ся, то дан­ные это­го поль­зовате­ля будут переда­ны RODC обыч­ным кон­трол­лером домена для кеширо­вания. Учет­ные дан­ные RODC и krbtgt_19160 лежат в кеше потому, что компь­ютер­ная учет­ная запись исполь­зует­ся, нап­ример, при работе со служ­бой катало­гов, а с помощью KRBTGT шиф­руют­ся выдава­емые TGT.

Так как все закеши­рован­ные пароли будут лежать в ntds.dit, то сме­ло дам­пим его любым удоб­ным спо­собом. Но сна­чала нуж­но получить дос­туп от лица локаль­ного адми­нис­тра­тора. Вспом­ним, что в атри­буте managedBy был про­писан некий FAUSTINO_SHERMAN.

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

Пос­ле это­го дам­пим ntds.dit как нам угод­но, нап­ример через VSS.

DSRM

У всех кон­трол­леров домена есть такая шту­ка, которая называ­ется DSRM. Она поз­воля­ет сде­лать «запас­ной» пароль для учет­ной записи локаль­ного адми­нис­тра­тора на слу­чай, если вдруг основной пароль забыт или уте­рян.

Как толь­ко мы получи­ли дос­туп к RODC, обя­затель­но нуж­но дам­пить SAM с целью поис­ка это­го пароля. Пароль свя­зан с учет­ной записью адми­нис­тра­тора, RID которой равен 500.

При­чем если мы срав­ним этот пароль со стан­дар­тным паролем адми­нис­тра­тора, то они будут отли­чать­ся.

Нам может повез­ти, а может нет. Во‑пер­вых, чаще все­го уста­нав­лива­ется один и тот же пароль DSRM на все кон­трол­леры домена, и мы смо­жем зай­ти на дру­гой кон­трол­лер домена от лица адми­нис­тра­тора. Но, во‑вто­рых, что­бы зай­ти от име­ни адми­нис­тра­тора, нуж­на осо­бая нас­трой­ка кон­трол­лера: тре­бует­ся, что­бы зна­чение DsrmAdminLogonBehaviour по пути HKLM\System\CurrentControlSet\Control\Lsa было рав­но 2.

Ес­ли нам повезет, то мы смо­жем выпол­нить вход от име­ни админ­ской учет­ки.

ОСОБЕННОСТИ РАБОТЫ KERBEROS С RODC

Са­мая глав­ная осо­бен­ность работы Kerberos с RODC в том, что RDOC не может син­хро­низи­ровать­ся с кон­трол­лером домена. Про­цесс DCSYNC воз­можен лишь в одну сто­рону — с обыч­ного кон­трол­лера на RODC. Син­хро­низи­ровать что‑либо с RODC невоз­можно.

Так­же сге­нери­рован­ный RODC TGT мож­но исполь­зовать и в домене, отдав его зап­росом TGS-REQ на служ­бу krbtgt обыч­ного кон­трол­лера домена. Ког­да обыч­ный КД получа­ет дан­ный TGT, он смот­рит атри­бут msDS-RevealOnDemandGroup RODC и про­веря­ет: если прин­ципал тикета ука­зан в этом атри­буте и не ука­зан в msDS-NeverRevealGroup, то TGT будет обновлен до «пол­ного» TGT и под­писан клю­чом обыч­ной учет­ной записи krbtgt кон­трол­лера домена. При­чем обыч­ный кон­трол­лер домена переге­нери­рует PAC билета, а не ста­нет его копиро­вать из TGT, сге­нери­рован­ного RODC.

Та­ким обра­зом, если мы хотим соз­дать «золотой», «брил­лиан­товый» или «сап­фировый» тикет, обя­затель­но сле­дить за тем, какой поль­зователь нам нужен. Прин­ципал ни в коем слу­чае не дол­жен при­сутс­тво­вать в спис­ке msDS-NeverRevealGroup. 

KEY LIST

Эта ата­ка поз­воля­ет извлечь NTLM-хеш поль­зовате­ля, зло­упот­ребляя осо­бен­ностя­ми вза­имо­дей­ствия RODC с обыч­ным кон­трол­лером домена. Сна­чала «золотой» тикет генери­рует­ся с исполь­зовани­ем клю­ча krbtgt RODC и отправ­ляет­ся в зап­росе TGS-REQ на обыч­ный кон­трол­лер домена. При этом уста­нав­лива­ется спе­циаль­ный флаг KERB-KEY-LIST-REQ. И если целевая учет­ная запись при­сутс­тву­ет в атри­буте msDS-RevealOnDemandGroup RODC и отсутс­тву­ет в атри­буте msDS-NeverRevealGroup, то TGS-REP будет содер­жать струк­туру KERB-KEY-LIST-REP с учет­ными дан­ными поль­зовате­ля.

Для выпол­нения ата­ки нам нуж­ны:

1. AES-ключ учет­ной записи krbtgt с RODC.
2. Но­мер вер­сии клю­ча (пос­ледние циф­ры в име­ни krbtgt).
3. Имя поль­зовате­ля, хеш которо­го хотим получить. Поль­зователь дол­жен быть про­писан в атри­буте msDS-RevealOnDemandGroup.

Пер­вые два объ­екта мож­но получить, исполь­зуя Mimikatz:

lsadump::lsa /inject /name:krbtgt_19160

А потом мож­но вос­поль­зовать­ся Rubeus либо Impacket для получе­ния NTLM-хеша поль­зовате­ля:

# impacket

impacket-keylistattack CRINGE/FAUSTINO_SHERMAN:pass123@dc01 -rodcNo 19160 -rodcKey fa34fec82433432f4b3e3fb8005bd369ddde8f15ee5450e92d9304ecd07bab60 -dc-ip 192.168.116.133 -debug

# Rubeus

# Сначала запрашиваем TGT

Rubeus.exe golden /rodcNumber:19160 /aes256:fa34fec82433432f4b3e3fb8005bd369ddde8f15ee5450e92d9304ecd07bab60 /user:RACHAEL_LAMBERT /id:1196 /domain:cringe.lab /sid:S-1-5-21-1437000690-1664695696-1586295871

# Отдаем TGT в запрос TGS-REQ

Rubeus.exe asktgs /enctype:aes256 /keyList /service:krbtgt/cringe.lab /dc:dc1.cringe.lab /ticket:doIFgzCCBX+gA

Лис­таем вниз и находим хеш поль­зовате­ля.

КОНТРОЛЬ НАД ОБЪЕКТОМ RODC

Ес­ли вдруг в ходе пен­теста получи­лось обна­ружить учет­ную запись, которая име­ет пра­ва GenericWrite/GenericAll/WriteProperty на msDS-RevealOnDemandGroup и желатель­но на msDS-NeverRevealGroup, то зах­ват домена обес­печен! Все сво­дит­ся к изме­нению этих самых атри­бутов msDS-RevealOnDemandGroup и msDS-NeverRevealGroup, что при­ведет к кеширо­ванию паролей новых поль­зовате­лей.

Нап­ример, мы видим, что кеширо­вание неких RAMONA_TURNER, RAMON_STEWART и RANDELL_COLON отклю­чено.

Пос­коль­ку у нас учет­ная запись име­ет кон­троль над этим атри­бутом, прос­то очи­щаем его:

Set-DomainObject -Identity RODC$ -Clear 'msDS-NeverRevealGroup'

А в атри­бут msDS-RevealOnDemandGroup, наобо­рот, добав­ляем поль­зовате­лей:

Set-DomainObject -Identity RODC$ -Set @{'msDS-RevealOnDemandGroup'=@('CN=RAMONA_TURNER,OU=Test,OU=BDE,OU=Tier 1,DC=cringe,DC=lab', 'CN=RAMON_STEWART,OU=ESM,OU=Stage,DC=cringe,DC=lab', 'CN=RANDELL_COLON,OU=TST,OU=Tier 2,DC=cringe,DC=lab')}

Да­лее при­дет­ся некото­рое вре­мя подож­дать, пока не прой­дет успешная син­хро­низа­ция RODC с обыч­ным кон­трол­лером домена и получе­ние учет­ных дан­ных поль­зовате­лей, ука­зан­ных в msDS-RevealOnDemandGroup. Для это­го мониторь содер­жимое атри­бута msDS-RevealedList: в нем хра­нит­ся спи­сок объ­ектов, учет­ные дан­ные которых успешно закеши­рова­лись на RODC. Коман­ды смот­ри в раз­деле «Поиск».

ЗАКЛЮЧЕНИЕ

RODC поль­зует­ся популяр­ностью у сис­темных адми­нис­тра­торов. Да, этот инс­тру­мент удо­бен, но мало кто зна­ет, что он соз­дает новые век­торы для атак. Самые час­тые мис­конфи­ги:

1. Ке­широ­вание RODC боль­шого чис­ла учет­ных дан­ных, нап­ример ког­да в msDS-RevealOnDemandGroup ука­зыва­ют груп­пу Authenticated Users. Ком­про­мети­рует­ся RODC, и мы получа­ем дос­туп к этим дан­ным.
2. RODC адми­нис­три­руют­ся груп­пой RODC Admins, которая чаще все­го не защище­на дол­жным обра­зом. Соот­ветс­твен­но, ата­кующий про­бива­ется в эту груп­пу, идет на RODC, а далее смот­ри пункт 1.
3. Па­роль DSRM на обыч­ном кон­трол­лере домена и на кон­трол­лере домена RODC оди­нако­вый.

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

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei