Exploiting Active Directory, part 3

Всем привет!

Это третья и заключительная часть четвёртой статьи из цикла статей по атакам на домены Active Directory. В ней мы рассмотрим ещё несколько способов эксплуатации различных мисконфигураций в AD (поиграем с шаблонами сертификатов и доверием между доменами в лесу) и подведём итог.

Первая и вторая части статьи доступны по ссылке ниже:

Схема рассматриваемой сети приведена на рисунке ниже:

Продолжим!

Эксплуатация сертификатов

Когда мы получили доступ к THMSERVER2, мы продолжили наше путешествие по эксплуатации AD, эксплуатировав все Tier 1 активы сети (серверы). Однако мы снова застряли, оставшись без простых средств для перехода на следующий уровень. Придется искать более творческие пути.

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

AD Certificate Services

Службы сертификатов AD (AD Certificate Services, CS) — это реализация PKI от Microsoft. Поскольку AD обеспечивает определенный уровень доверия в организации, его можно использовать в качестве центра сертификации для подтверждения и делегирования доверия. AD CS используется для нескольких целей, таких как шифрование файловых систем, создание и проверка цифровых подписей и даже аутентификация пользователей, что делает его многообещающим средством для атак злоумышленников.

Поскольку AD CS является привилегированной функцией, она обычно выполняется на выбранных контроллерах домена. Это означает, что обычные пользователи не могут напрямую взаимодействовать со службой. С другой стороны, организации, как правило, слишком велики, чтобы администратор создавал и распространял каждый сертификат вручную. Здесь на помощь приходят шаблоны сертификатов. Администраторы AD CS могут создать несколько шаблонов, позволяющих любому пользователю с соответствующими разрешениями самостоятельно запрашивать сертификат. Эти шаблоны имеют параметры, которые говорят, какой пользователь может запросить сертификат и что для этого требуется. SpecterOps обнаружили, что определенные комбинации этих параметров могут быть невероятно опасными и использоваться для повышения привилегий и закрепления присутствия в домене.

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

PKI (Public Key Infrastructure) — инфраструктура открытых ключей — это система, которая управляет сертификатами и шифрованием с открытым ключом;
AD CS (Active Directory Certificate Services) — это реализация PKI от Microsoft, которая обычно работает на контроллерах домена;
CA (Certificate Authority) — Центр сертификации (ЦС) — это PKI, выдающая сертификаты;
Шаблон сертификата (Certificate Template) — набор настроек и политик, определяющих, как и когда сертификат может быть выдан ЦС;
CSR (Certificate Signing Request) — запрос на подпись сертификата — это сообщение, отправляемое в ЦС для запроса подписанного сертификата;
EKU (Extended/Enhanced Key Usage) — расширенное использование ключа — это идентификаторы объектов, которые определяют, как можно использовать сгенерированный сертификат.

Поиск уязвимых шаблонов сертификатов

Чтобы найти уязвимые шаблоны, мы будем использовать встроенный в Windows инструмент certutil. Используя RDP-доступ к THMSERVER2, мы можем запустить следующий сценарий Powershell для перечисления сертификатов:

C:\>certutil -Template -v > templates.txt

Это обеспечит вывод для всех настроенных шаблонов. Мы также могли бы использовать инструмент аудита сертификатов, такой как PSPKIAudit от Ghostpack. Однако ручной подход позволяет нам убедиться, что мы нашли все возможные неправильные конфигурации. Шаблон сертификата считается неправильно сконфигурированным, если комбинация значений параметров становится опасной, что позволяет инициатору запроса выполнить повышение привилегий. В нашем случае ищем шаблон со следующей "ядовитой" комбинацией параметров:

Client Authentication — сертификат можно использовать для аутентификации клиента;
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT — шаблон сертификата позволяет указать альтернативное имя субъекта (SAN);
CTPRIVATEKEY_FLAG_EXPORTABLE_KEY — сертификат можно будет экспортировать с закрытым ключом;
Certificate Permissions — у нас есть необходимые разрешения для использования шаблона сертификата.

Подробнее можно прочитать в статье SpecterOps, приведенной выше. Поскольку цель этой статьи — получить более широкое представление об атаках эксплуатации AD, мы укажем, что Template[32] является уязвимым.

В этом шаблоне мы видим, что учетная запись компьютера THMSERVER2 может выдавать CSR для шаблона, который позволяет нам указать альтернативное имя субъекта (SAN) и может использоваться для аутентификации клиента:

SpecterOps упоминает восемь распространенных неправильных конфигураций безопасности с AD CS, поэтому следует отметить, что все еще можно обнаружить значительное количество потенциальных неверных конфигураций.

Эксплуатация шаблона сертификата

Используя RDP-доступ на THMSERVER2, запросим наш сертификат. Мы будем использовать консоль управления Microsoft (MMC):

Нажимаем Start->run;
Вводим "mmc" и нажмите Enter;
Нажимаем File->Add/Remove Snap-in..;
Добавляем оснастку Certificates и обязательно выбираем Computer Account и Local computer в диалоговых окнах;
Нажимаем ОК.

Теперь мы видим оснастку Certificates:

Мы запросим персональный сертификат:

Щелкнем правой кнопкой мыши Personal и выберем All Tasks->Request New Certificate...;
Дважды щелкаем Next, чтобы выбрать AD enrollment policy;
Видим, что у нас есть один шаблон, который мы можем запросить, но сначала нам нужно предоставить дополнительную информацию;
Нажимаем на предупреждение More Information;
Изменяем параметр Subject name Type на Common Name и указываем любое значение, так как это не имеет значения, и жмём Add;
Изменяем параметр Alternative name Type на User principal name;
Указываем имя участника-пользователя, которого мы хотим олицетворять. Лучше всего использовать учетную запись DA, например Administrator@za.tryhackme.loc, и нажать Add.

После нажимаем Apply и ОК. Затем выбираем сертификат и жмём Enroll. Мы должны увидеть свой сертификат:

Последний шаг — экспортировать наш сертификат с закрытым ключом:

Щелкнем на сертификат правой кнопкой мыши и выберем All Tasks->Export...;
Нажмём Next, выберем Yes, export the private key и нажмём Next;
Нажмём Next и установим пароль для сертификата, так как закрытый ключ нельзя экспортировать без пароля;
Нажмём Next и выберем место для хранения сертификата;
Нажмём Next и, наконец, Finish.

Имитация пользователя (User Impersonation) через сертификат

Теперь мы наконец можем олицетворять пользователя. Для этого необходимо выполнить два шага:

Использовать сертификат для Kerberos ticket-granting ticket (TGT);
Загрузить Kerberos TGT в выбранную платформу для атаки.

Для первого шага используем Rubeus. Выполним следующую команду для запроса TGT:

Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate: /password: /outfile: /domain:za.tryhackme.loc /dc:

Разберем её параметры:

/user — указывает пользователя, которого мы будем олицетворять, и должен соответствовать имени участника-пользователя для созданного нами сертификата;
/enctype — указывает тип шифрования билета. Установка этого значения важна для предотвращения обнаружения, так как алгоритм шифрования по умолчанию слаб, что приведет к предупреждению о превышении хеш-значения;
/certificate — путь к сгенерированному нами сертификату;
/password — пароль для нашего файла сертификата;
/outfile — файл, в который будет выводиться наш TGT;
/domain — полное доменное имя домена, который мы сейчас атакуем;
/dc — IP-адрес контроллера домена, с которого мы запрашиваем TGT. Обычно лучше выбрать контроллер домена, на котором запущена служба ЦС.

Как только мы выполним команду, мы должны получить наш TGT :

C:\Tools> .\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:cert_cherepawwka.pfx /password:P@ssw0rd /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.86.101

Теперь мы можем использовать Mimikatz для загрузки TGT и аутентификации в THMDC:

C:\Tools>mimikatz_trunk\x64\mimikatz.exe

  .#####.   mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # kerberos::ptt administrator.kirbi

Наконец-то мы получили доступ к Tier 0 инфраструктуре и скомпрометировали весь дочерний домен!

Проверка доступа к контроллеру домена от имени администратора домена

Эксплуатация Domain Trusts

Несмотря на то, что у нас есть доступ к Tier 0 инфраструктуре, этого все равно недостаточно. Мы использовали только домен ZA.TRYHACKME.LOC. Наверняка у TRYHACKME должны быть домены и для других регионов? Что ж, если мы получим контроль над корневым доменом TRYHACKME.LOC, мы сможем скомпрометировать все эти дочерние региональные домены. В этой задаче мы рассмотрим, как можно использовать доверие домена для получения контроля над всем лесом.

Domain Trusts

Лес — это набор одного или нескольких деревьев доменов внутри сети AD. Доверительные отношения домена — это механизм, с помощью которого пользователи в сети получают доступ к другим ресурсам в домене. По большей части доверительные отношения определяют, как домены внутри леса взаимодействуют друг с другом. В некоторых средах доверительные отношения могут распространяться на внешние домены и даже леса.

Существует два основных типа доверительных отношений, которые можно настроить между доменами:

Направленный (Directional) — направление потоков доверия от доверяемого домена (trusting domain) к доверенному домену;
Транзитивный (Transitive) — доверительные отношения выходят за пределы двух доменов и включают в себя другие доверенные домены.

Обычно корневой или родительский домен находится в лесу. В нашем случае это TRYHACKME.LOC. Для каждого регионального офиса создаются дочерние домены, такие как ZA.TRYHACKME.LOC или UK.TRYHACKME.LOC. Эта конфигурация леса позволит совместно использовать ресурсы между ZA и офисом в UK. Например, если какому-то пользователю в офисе в Великобритании требуется доступ к THMSERVER1, мы можем предоставить такой доступ пользователю в домене ZA. Это делегирование разрешений работает, поскольку существует двунаправленное доверие между ZA и корневым доменом, а также между UK и корневым доменом, что по существу создает транзитивное доверие между ZA и UK.

Как упоминалось выше, доверие между родительским и дочерним доменами является двунаправленным. Это предполагаемое поведение, которое используется для совместного использования ресурсов через более транзитивные доверительные отношения. Однако, как злоумышленник, мы также можем использовать это доверие для компрометации родительского домена, если мы скомпрометировали дочерний домен.

KRBTGT и Golden Tickets

KRBTGT — это учетная запись, используемая корпорацией Майкрософт для реализации Kerberos. Название происходит от Kerberos (KRB) и Ticket Granting Ticket (TGT). По сути, эта учетная запись действует как учетная запись службы для Kerberos Distribution Center (KDC), которая обрабатывает все запросы билетов Kerberos. Эта учетная запись используется для шифрования и подписи всех билетов Kerberos для домена. Поскольку хэш пароля используется всеми контроллерами домена, они могут проверить подлинность полученного TGT, когда пользователи запрашивают доступ к ресурсам.

Однако что случится, если мы захотим сгенерировать свои собственные TGT, чтобы предоставить доступ ко всему? Это атака известна как Golden Ticket. В атаке Golden Ticket мы полностью обходим KDC и создаем свои собственные TGT, по сути становясь Ticket Granting Server (TGS). Для подделки TGT нам нужна следующая информация:

Полное доменное имя (FQDN) домена;
Идентификатор безопасности (SID) домена;
Имя пользователя учетной записи, которую мы хотим олицетворять;
Хэш пароля KRBTGT.

Первые три пункта обычно легко получить. Последний требует компрометации домена, поскольку хэш пароля KRBTGT хранится только на контроллерах домена. К счастью для нас, мы только что скомпрометировали группу Tier 0 admins с помощью поддельного сертификата, поэтому мы можем плучить хэш пароля KRBTGT.

Мы снова будем использовать Mimikatz с DC Sync для дампа хэша пароля KRBTGT на THMSERVER2:

C:\Tools>mimikatz_trunk\x64\mimikatz.exe

  .#####.   mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # lsadump::dcsync /user:za\krbtgt

Hash NTLM: 16f9af38fca3ada405386b3b57366082

Inter-Realm TGTs

Используя хэш пароля KRBTGT, мы теперь можем осуществить атаку Golden Ticket для доступа к любому ресурсу в дочернем домене. Однако мы можем сделать еще один шаг вперед, создав Inter-Realm TGT. Inter-Realm TGT используются для предоставления доступа к ресурсам в других доменах. В нашем случае мы хотим использовать двунаправленные доверительные отношения между дочерним и родительским доменами, чтобы получить полный доступ к родительскому домену.

Мы включим SIDы дополнительных учетных записей из других доменов, когда создадим Golden Ticket для выполнения этой атаки. Mimikatz может помочь с этим, позволив нам установить раздел ExtraSids структуры KERB_VALIDATION_INFO Kerberos TGT. Раздел ExtraSids описывается как «Указатель на список структур KERB_SID_AND_ATTRIBUTES, которые содержат список SID, соответствующих группам в доменах, отличных от домена учетной записи, к которому принадлежит принципал».

Ключевым моментом здесь является то, что мы будем использовать доверие родительского домена к нашему дочернему домену, добавив SID группы Enterprise Admins (EA) в качестве дополнительного SID к нашему поддельному билету для контроллера домена дочернего домена. Группа EA принадлежит родительскому домену, и членство в этой группе, по сути, дает административные привилегии для всего леса. SID по умолчанию для этой группы — S-1-5-21-<RootDomain>-519.

Прежде чем мы сможем приступить к эксплуатации, нам сначала нужно узнать два SID:

SID дочернего контроллера домена (THMDC), который мы будем имперсонифицировать в поддельном TGT;
SID группы Enterprise Admins в родительском домене, который мы добавим в качестве дополнительного SID к нашему поддельному TGT.

Чтобы получить эти SID, мы можем использовать командлеты AD-RSAT Powershell. Сначала запросим информацию о компьютере в дочернем домене, вычленив оттуда SID:

PS C:\> Get-ADComputer -Identity "THMDC"

S-1-5-21-3885271727-2693558621-2658995185-1001

SID группы Enterprise Admins можно раздобыть, используя следующую команду для запроса родительского контроллера домена:

PS C:\> Get-ADGroup -Identity "Enterprise Admins" -Server thmrootdc.tryhackme.loc

S-1-5-21-3330634377-1326264276-632209373-519

Эксплуатация доверительных отношений

Наконец-то у нас есть вся информация, необходимая для создания поддельного TGT. Мы будем использовать Mimikatz для создания golden ticket. Команда будет выглядеть примерно так:

C:\Tools>mimikatz_trunk\x64\mimikatz.exe

  .#####.   mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # kerberos::golden /user:Administrator /domain:za.tryhackme.loc /sid:S-1-5-21-3885271727-2693558621-2658995185-1001 /service:krbtgt /rc4:16f9af38fca3ada405386b3b57366082 /sids:S-1-5-21-3330634377-1326264276-632209373-519 /ptt

Проверим, что этот билет работает для доступа к THMDC, поскольку он является действительным билетом для пользователя Administrator дочернего домена:

C:\>dir \\thmdc.za.tryhackme.loc\c$

Это как минимум подтверждает, что Golden Ticket был подделан для доступа к дочернему DC. Однако, поскольку мы указали дополнительные SID, теперь у нас также должен быть доступ к родительскому контроллеру домена:

C:\>dir \\thmrootdc.tryhackme.loc\c$\

Доступ к контроллеру домена от имени администратора

Это доказывает, что теперь мы полностью скомпрометировали родительский домен исключительно путем компрометации одного из дочерних доменов!

Кстати, если мы выполним команду klist, то увидим следующее:

Тикеты нашего пользователя, свидетельствующие о наличии прав доменного администратора

Заключение

Чтобы научиться эксплуатировать AD, требуется время, а используемые методы будут сильно зависеть от конфигурации структуры атакуемого домена. Самое главное, что нужно понять, это то, что процесс цикличен. В большинстве случаев мы не сможем запустить ни одного boot-to-root эксплойта, который дает нам доступ от имени DA. Наилучший подход — выполнить атаку, которая расширяет доступ, а затем использовать полученный доступ для повторного перечисления в поисках дополнительных путей эксплуатации, которые могут быть возможны из новой позиции.

Снижение рисков

От эксплуатации AD, как и от перечисления AD, невероятно сложно защититься. Это связано с тем, что то, что может считаться неправильной конфигурацией, которую можно эксплуатировать, имеет реальное экономическое обоснование. Тем не менее, мы можем сделать несколько вещей, чтобы защититься от эксплуатации:

Нам нужно убедиться, что никакая конфигурация не нарушает нашу многоуровневую модель доступа. Учетные записи более низкого уровня не должны иметь возможности взаимодействовать с ресурсами более высокого уровня. Кроме того, учетные записи более высокого уровня никогда не должны входить на ресурсы более низкого уровня;
При делегировании разрешений следует соблюдать принцип наименьших привилегий. Кроме того, делегирование разрешений должно соответствовать многоуровневой модели, гарантируя, что объект более низкого уровня не может изменить объект более высокого уровня;
Подпись SMB должна быть принудительной, а не просто доступной. Это предотвратит попытки relay-атаки;
Объекты AD и их конфигурация — не единственные пути для эксплуатации. Службы AD, такие как AD CS, также следует рассматривать как часть поверхности атаки и защищать;
Необходимо внедрить достаточные меры безопасности для защиты Tier 0 инфраструктуры и учетных записей в дочерних доменах, поскольку компрометация одного из них может привести к компрометации всего леса.

После завершения эксплуатации AD следующий шаг, который должен предпринять злоумышленник, это закрепление, чтобы блютим не смог просто ограничить его доступ. Об этом подробнее поговорим в следующей статье.

До новых встреч!

Захватил домен — самое время пить молочко