Persisting Active Directory, part 1

Всем привет!

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

Эта статья является логическим продолжением статей Breaching AD, Enumerating AD и Exploiting AD.

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

Схема сети с не изменилась, поменялась только адресация (третий октет):

Приступим!

Введение

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

Закрепление в AD

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

Цели

В этой сети мы рассмотрим несколько методов, которые можно использовать для закрепления в AD:

Учетные данные AD и DCSync;
Серебряные и золотые билеты;
Сертификаты AD;
Идентификаторы безопасности (SIDs);
Списки контроля доступа (ACLs);
Объекты групповой политики (GPOs).

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

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

Эта пара учетных данных предоставит нам доступ RDP и SSH к THMWRK1.za.tryhackme.loc. THMWRK1 можно рассматривать как точку входа в сеть, имитирующий достигнутую точку опоры.

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

ssh za\\louis.cole@thmwrk1.za.tryhackme.loc

Закрепление через учетные данные

В прошлой статье мы скомпрометировали весь домен, получив доступ к контроллеру домена родительского домена с правами EA. Поэтому при обсуждении методов закрепления мы будем использовать привилегированные учетные данные для закрепления в отношении нашей непривилегированной УЗ.

Username:Administrator

Password:tryhackmewouldnotguess1@

Domain:ZA

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

DC Sync

В крупных организациях недостаточно иметь один контроллер домена (особенно при наличии нескольких отделений), поэтому организации используют несколько контроллеров домена. Тогда возникает вопрос, как мы можем пройти аутентификацию, используя одни и те же учетные данные в двух разных офисах?

Ответ на этот вопрос — репликация домена. Каждый контроллер домена запускает процесс проверки согласованности знаний (Knowledge Consistency Checker, KCC). KCC создает топологию репликации для леса AD и автоматически подключается к другим контроллерам домена с помощью Remote Procedure Calls (RPC) для синхронизации информации. Информация включает в себя обновленные данные, такие как новый пароль пользователя и новые объекты, например, когда создается новый пользователь. Вот почему обычно приходится ждать пару минут перед аутентификацией после смены пароля, поскольку контроллер домена, на котором произошло изменение пароля, возможно, не тот, на котором мы проходим аутентификацию.

Процесс репликации называется DC Synchronisation. Инициировать репликацию могут не только контроллеры домена. Учетные записи, например принадлежащие к группам администраторов домена, также могут это делать (например, при создании нового контроллера домена).

Здесь мы плавно подошли к популярной атаке, которая называется DC Sync. Если у нас есть доступ к учетной записи с разрешениями на репликацию домена, мы можем организовать атаку DC Sync для получения учетных данных от контроллера домена.

Не все учетные данные одинаковы

Прежде чем начать нашу атаку DC Sync, давайте сначала обсудим, какие учетные данные мы потенциально можем искать. Несмотря на то, что мы всегда должны стремиться дампить привилегированные учетные данные (например, члены группы «Domain Admins»), в случае компрометации это будут первые УЗ, от которых сотрудники ИБ поменяют пароли. Таким образом, если у нас есть только привилегированные учетные данные, можно с уверенностью сказать, что как только синяя команда обнаружит нас, они изменять пароли этих учетных записей, и мы потенциально можем потерять доступ к домену.

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

Учетные данные с правами локального администратора на нескольких машинах. Обычно в организациях есть группа или две с правами локального администратора почти на всех компьютерах. Эти группы обычно делятся на одну для рабочих станций и одну для серверов. Собрав учетные данные членов этих групп, мы по-прежнему будем иметь доступ к большинству компьютеров в домене;
Учетные записи служб с разрешениями на делегирование. С помощью этих учетных записей мы могли бы осуществлять атаки Silver и Golden Ticket;
Учетные записи, используемые для привилегированных служб AD. Если мы скомпрометируем учетные записи привилегированных служб, таких как Exchange, службы Windows Server Update Services (WSUS) или System Center Configuration Manager (SCCM), мы можем злоупотребить особенностями конфигурации домена, чтобы снова получить привилегированное положение.

DCSync All

Мы будем использовать Mimikatz для дампа учетных данных из-под УЗ доменного администратора. Для этого подключимся по RDP на THMWRK1:

xfreerdp /v:10.200.61.248 /u:Administrator /p:tryhackmewouldnotguess1@ /d:za.tryhackme.loc +clipboard /dynamic-resolution /cert:ignore

Запустим Mimikatz:

Давайте начнем с выполнения DC Sync одной учетной записи, нашей собственной:

mimikatz # lsadump::dcsync /domain:za.tryhackme.loc /user:louis.cole

Мы видим обширный вывод, включая текущий NTLM-хэш учетной записи.

Это, конечно, здорово, но мы хотим, чтобы DC синхронизировал каждую учетную запись. Для этого нам нужно будет включить ведение журнала в Mimikatz:

mimikatz # log cherepawwka_dcdump.txt

Теперь вместо указания нашей учетной записи мы будем использовать флаг /all:

mimikatz # lsadump::dcsync /domain:za.tryhackme.loc /all

Атака займет немного времени. Теперь мы можем выгрузить дамп (я для этого использовал meterpreter, но можно и SMB-шару с Impacket). Если мы используем cat cherepawwka_dcdump.txt | grep "SAM Username", то сможем получить всех пользователей домена. cat cherepawwka_dcdump.txt | grep "Hash NTLM" даст нам все NTLM хэши. Теперь мы можем либо выполнить атаку взлома пароля в автономном режиме, чтобы восстановить учетные данные в виде открытого текста, либо просто выполнить атаку с передачей хэша с помощью Mimikatz.

Закрепление через билеты

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

Подробнее о билетах

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

Пользователь отправляет AS-REQ в центр распространения ключей (Key Distribution Centre, KDC) на контроллере домена, который включает отметку времени, зашифрованную с помощью хэша NTLM пользователя. По сути, это запрос на выдачу Ticket Granting Ticket (TGT). DC проверяет информацию и отправляет TGT пользователю. Этот TGT подписан хэшем пароля учетной записи KRBTGT, который хранится только на контроллере домена. Теперь пользователь может отправить этот TGT в контроллер домена, чтобы запросить Ticket Granting Service (TGS) для ресурса, к которому пользователь хочет получить доступ. Если TGT валидный, контроллер домена отдаёт TGS, который зашифрован NTLM-хэшем службы, для которой пользователь запрашивает доступ. Затем пользователь предоставляет этот TGS службе, которая может проверить TGS, поскольку она знает свой собственный хэш и может предоставить пользователю доступ.

Зная всё это, пришло время изучить золотые и серебряные билеты.

Golden Tickets

Золотые билеты — это поддельные TGT. Это означает, что мы пропускаем шаги 1 и 2 на приведенной выше диаграмме, где мы доказываем DC, кто мы есть. Имея действительный TGT привилегированной учетной записи, теперь мы можем запросить TGS практически для любой службы, которую захотим. Чтобы подделать золотой билет, нам нужен хэш пароля учетной записи KRBTGT, чтобы мы могли подписать TGT для любой учетной записи пользователя, которую захотим. Несколько интересных заметок о Golden Tickets:

На этом этапе нам не нужен хэш пароля учетной записи, которую мы хотим олицетворять, поскольку мы обходим этот шаг. TGT используется только для подтверждения того, что KDC на контроллере домена подписал его. Поскольку TGT был подписан хэшем KRBTGT, проверка проходит, и TGT объявляется действительным независимо от его содержимого;
Говоря о содержании, KDC будет проверять учетную запись пользователя, указанную в TGT, только если билет старше 20 минут. Это означает, что мы можем поместить отключенную, удаленную или несуществующую учетную запись в TGT, и билет будет действителен до тех пор, пока мы гарантируем, что отметка времени не старше 20 минут;
Поскольку политики и правила для билетов устанавливаются в самом TGT, мы можем перезаписать значения, введенные KDC, например, что билеты должны быть действительны только в течение 10 часов. Например, мы могли бы гарантировать, что наш TGT действителен в течение 10 лет, что позволит нам закрепиться;
По умолчанию пароль учетной записи KRBTGT никогда не меняется (если только он не будет изменен вручную), а это означает, что как только он у нас есть, у нас будет постоянный доступ за счет создания TGT на долгое время;
Сотрудникам отдела ИБ придется дважды сменить пароль учетной записи KRBTGT, поскольку текущий и предыдущий пароли остаются действительными для учетной записи. Это делается для того, чтобы случайное изменение пароля не повлияло на службы;
Смена пароля учетной записи KRBTGT — невероятно болезненный процесс для сотрудников ИБ, поскольку это приведет к прекращению работы значительного количества служб в сети, так как службы в течении нескольких часов "думают", что у них есть действующий TGT, но этот TGT больше недействителен. Не все сервисы достаточно "умны", чтобы перевыпустить TGT, который больше не действителен (поскольку временная метка все еще действительна), и, следовательно, не будут автоматически запрашивать новый TGT;
Золотые билеты позволяют даже обойти проверку подлинности смарт-карты, поскольку смарт-карта проверяется контроллером домена до создания TGT;
Мы можем сгенерировать золотой билет на любой машине, даже если она не присоединена к домену (например, на нашей собственной атакующей машине), что затрудняет обнаружение такой активности сотрудниками группы мониторинга.

Помимо хэша пароля учетной записи KRBTGT, нам нужны только имя домена, SID домена и идентификатор пользователя, которого мы хотим имперсонифицировать. Если мы сможем восстановить хэш пароля учетной записи KRBTGT, мы уже сможем восстановить другие части необходимой информации.

Silver Tickets

Серебряные билеты — это поддельные билеты TGS. Итак, теперь мы пропускаем всё общение с KDC на DC (шаги 1-4 на схеме выше), и просто взаимодействуем со службой, к которой мы хотим получить доступ напрямую. Несколько интересных заметок о серебряных билетах:

Сгенерированный TGS подписывается учетной записью компьютера хоста, на который мы нацеливаемся;
Основное различие между золотыми и серебряными билетами заключается в количестве получаемых нами привилегий. Если у нас есть хэш пароля учетной записи KRBTGT, мы можем получить доступ ко всему. С Silver Ticket, поскольку у нас есть доступ только к хэшу пароля учетной записи компьютера сервера, который мы атакуем, мы можем выдавать себя только за пользователей на самом этом хосте. Область действия серебряного билета ограничена любой службой, предназначенной для конкретного сервера;
Поскольку TGS подделан, связанный с ним TGT отсутствует, а это означает, что с DC не связывались. Это делает атаку невероятно опасной, поскольку единственные доступные журналы будут находиться на целевом сервере. Таким образом, хотя область действия более ограничена, специалистам SOC значительно труднее ее обнаружить;
Поскольку разрешения определяются через SID, мы можем снова создать несуществующего пользователя для нашего серебряного билета, гарантируя, что билет имеет соответствующие SID, которые поместят пользователя в группу локальных администраторов хоста;
Пароль учетной записи компьютера обычно меняется каждые 30 дней, что плохо для закрепления. Однако мы могли бы использовать доступ, который предоставляет наш TGS, чтобы получить доступ к реестру хоста и изменить параметр, отвечающий за смену пароля учетной записи компьютера. Тем самым мы гарантируем, что учетная запись компьютера остается статической, что дает нам закрепиться на хосте;
Хотя наличие доступа только к одному хосту может показаться значительным понижением нашего положения в домене, учетные записи компьютеров можно использовать как обычные учетные записи AD, что дает вам не только административный доступ к хосту, но и средства для продолжения перечисления и эксплуатации AD, как если бы мы использовали учетную запись пользователя.

Подделка билетов

Теперь, когда мы узнали основную информацию о золотых и серебряных билетах, давайте сгенерируем их. Для этого понадобится NTLM-хэш учетной записи KRBTGT, который теперь у нас есть после DC Sync. Кроме того, запишем NTLM-хэш учетной записи компьютера THMSERVER1, так как он понадобится для серебряного билета:

KRBTGT: 16f9af38fca3ada405386b3b57366082

THMSERVER1: 4c02d970f7b3da7f8ab6fa4dc77438f4

Последняя часть информации, которая нам нужна, — это SID домена. Используя наш терминал SSH с низким уровнем привилегий на THMWRK1, мы можем использовать командлет AD-RSAT для получения этой информации:

Get-ADDomain

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

kerberos::golden /admin:ReallyNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:S-1-5-21-3885271727-2693558621-2658995185 /krbtgt:16f9af38fca3ada405386b3b57366082 /endin:600 /renewmax:10080 /ptt

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

/admin — имя пользователя, которого мы хотим имперсонифицировать. Это не обязательно должен быть действительный пользователь;
/domain — полное доменное имя домена, для которого мы хотим сгенерировать билет;
/id — RID пользователя. По умолчанию Mimikatz использует RID 500, который является RID учетной записи администратора по умолчанию;
/sid — SID домена, для которого мы хотим сгенерировать билет;
/krbtgt — NTLM-хэш учетной записи KRBTGT;
/endin — срок жизни билета. По умолчанию Mimikatz создает билет, действительный в течение 10 лет. Политика Kerberos по умолчанию для AD составляет 10 часов (600 минут);
/renewmax — максимальное время жизни билета с продлением. По умолчанию Mimikatz создает билет, действительный в течение 10 лет. Политика Kerberos по умолчанию для AD составляет 7 дней (10080 минут);
/ptt — этот флаг указывает Mimikatz ввести билет непосредственно в сеанс, что означает, что он готов к использованию.

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

dir \\thmdc.za.tryhackme.loc\c$\

Даже если у золотого билета установлено невероятно долгое время, сотрудники отдела ИБ все равно могут защититься от такой атаки, просто дважды сменив пароль KRBTGT.

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

mimikatz # kerberos::golden /admin:StillNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<Domain SID> /target:<Hostname of server being targeted> /rc4:<NTLM Hash of machine account of target> /service:cifs /ptt

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

/admin — имя пользователя, которого мы хотим имперсонифицировать. Это не обязательно должен быть действительный пользователь;
/domain — полное доменное имя домена, для которого мы хотим сгенерировать билет;
/id — RID пользователя. По умолчанию Mimikatz использует RID 500, который является RID учетной записи администратора по умолчанию;
/sid — SID домена, для которого мы хотим сгенерировать билет;
/target — имя хоста нашего целевого сервера. В нашем случае THMSERVER1.za.tryhackme.loc, но тут может быть любой хост, присоединенный к домену;
/rc4 — NTLM-хэш учетной записи компьютера нашей цели (в дампе после DC Sync находим NTLM-хеш THMSERVER1$; $ указывает, что это учетная запись компьютера);
/service — сервис, который мы запрашиваем в нашем TGS. CIFS — беспроигрышный вариант, поскольку он разрешает доступ к файлам;
/ptt — этот флаг указывает Mimikatz ввести билет непосредственно в сеанс, что означает, что он готов к использованию.