Атака Key List Kerberos при пентесте контроллера домена

В этой статье, мы рассмотрим атаку Key List Kerberos при пентесте контроллера домена. Данная ата­ка поз­воля­ет извлечь NTLM-хеши поль­зовате­лей.

Еще по теме: Атака RBCD для захвата домена Active Directory

Что такое Read-only Domain Controller

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

Внут­ри Read-only Domain Controller хра­нит­ся копия базы Active Directory, но слегка изме­нен­ная.

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

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

При­чем Read-only Domain Controller не соз­дает домен, а добав­ляет­ся в сущес­тву­ющий. Происходите это еще на эта­пе уста­нов­ки.

Особенности работы 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 Kerberos при пентесте контроллера домена

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

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

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

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

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

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

Заключение

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

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

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

ПОЛЕЗНЫЕ ССЫЛКИ:

• Атаки на службы сертификатов Active Directory
• Захват Active Directory на виртуальной машине с HackTheBox
• Использование Kerbrute для атаки на Kerberos Active Directory