Введение
Аналитики безопасности, имеющие некоторое представление об Active Directory и пентесте, должны знать концепцию билетов. Kerberos, механизм аутентификации по умолчанию в AD, использует аутентификацию на основе билетов, где центр распространения ключей (KDC) предоставляет Ticket-Granting Ticket (TGT) пользователю, запрашивающему доступ к службе или учетной записи, который затем можно активировать для создания сервисного билета (ST) для доступа к определенной службе, например учетной записи SQL. Такие атаки, как Golden Ticket, демонстрируют, как злоумышленник может сохранить доступ к администратору домена, получив NTLM-хэш учетной записи "krbtgt". Сохранение домена необходимо для аналитика в случае изменения пароля администратора. Персистенса также можно добиться с помощью проверки подлинности на основе сертификатов, развернутой в службе сертификатов Active Directory. Одним из таких методов является атака "Золотой сертификат". Этот метод использует аутентификацию на основе сертификатов в AD, включенную по умолчанию, с установкой ADCS (службы сертификатов Active Directory) путем подделки нового сертификата с использованием закрытого ключа сертификата CA. Техника была реализована Бенджамином Дельпи в Mimikatz. Уилл Шредер и Ли Кристенсен написали исследовательскую работу по этой технике, на которую можно посмотреть здесь.
Основы ADCS и сертификатов
ADCS обеспечивает аутентификацию в лесу. Он повышает общую безопасность удостоверения участника (пользователя или учетной записи службы), привязывая его к соответствующему закрытому ключу. Сертификат — это документ с цифровой подписью в формате X.509, используемый для шифрования, подписи сообщений и/или проверки подлинности. Он содержит следующие детали:
- Субъект – владелец сертификата.
- Открытый ключ — связывает субъект с закрытым ключом, хранящимся отдельно.
- Даты NotBefore и NotAfter — указывают продолжительность действия сертификата.
- Серийный номер — идентификатор сертификата, присвоенный ЦС.
- Издатель — указывает, кто выдал сертификат (обычно ЦС).
- SubjectAlternativeName — определяет одно или несколько альтернативных имен, под которыми может работать субъект.
- Базовые ограничения — определяет, является ли сертификат ЦС или конечным объектом, и существуют ли какие-либо ограничения при использовании сертификата.
- Использование расширенных ключей (EKU) — идентификаторы объектов (OID), которые описывают, как будет использоваться сертификат. Также известно как Enhanced Key Usage на языке Microsoft.
- Алгоритм подписи — указывает алгоритм, используемый для подписи сертификата.
- Подпись - Подпись органа сертификации выполняется с использованием закрытого ключа эмитента (например, ЦС).
Центры сертификации (ЦС) отвечают за выдачу сертификатов. После установки ADCS ЦС сначала создает собственную пару открытого и закрытого ключей и подписывает собственный корневой ЦС, используя свой закрытый ключ. Хосты добавляют этот корневой ЦС в свои системы для создания системы доверия.
Регистрация сертификата — процесс получения клиентом сертификата от AD CS называется регистрацией сертификата, в котором выполняются следующие шаги:
- Клиент генерирует пару открытый/закрытый ключ
- Клиент размещает открытый ключ в запросе на подпись сертификата, который включает такие сведения, как тема сертификата и имя шаблона сертификата.
- Клиенты подписывают CSR с помощью закрытого ключа и отправляют CSR на корпоративный сервер CA.
- CA-сервер проверяет запрошенный клиентом шаблон сертификата
- ЦС генерирует сертификат и подписывает его с помощью собственного закрытого ключа.
Типы расширений в сертификатах. В этой статье можно найти следующие расширения:
- *.p12 — PKCS#12 — это двоичный формат для хранения сертификата сервера, любых промежуточных сертификатов и закрытого ключа в одном зашифрованном файле. Всякий раз, когда вы экспортируете сертификат с помощью msc, он выходит в формате p12.
- *.pfx — то же самое, что и *.p12. Файлы *.pfx также являются двоичными сертификатами формата PKCS#12. Разница лишь в том, что *.pfx был разработан Microsoft, а *.p12 — Netscape. Итак, из соображений совместимости вы увидите, как мы конвертируем *.p12 в формат *.pfx.
- *.pem — в этом контексте содержит пару сертификат + закрытый ключ в кодировке Base64.
В противном случае файл pem может иметь что угодно в зависимости от разработки.
Установка ADCS в локальной среде AD
Чтобы настроить ADCS в нашей тестовой среде, мы выполнили следующие шаги.
Шаг 1. Перейдите в диспетчер серверов и выберите "добавить роли и функции".
Шаг 2. Вы можете прочитать о предварительных требованиях, которые рекомендует Windows, и нажать "Далее".
Шаг 3: Выберите сервер из пула серверов. В вашей среде может быть несколько пулов, мы выберем DC1.ignite.local.
Шаг 4. В разделе "Роли сервера" выберите "Службы сертификатов Active Directory' и нажмите "Далее".
Шаг 5: Вы можете нажать "Далее" на этом шаге или добавить некоторые функции. Для этой демонстрации нам не нужно ничего дополнительно, поэтому нажмите "Далее".
Шаг 6: Выберите свою роль центра сертификации. Центр сертификации является основным лицом, подписывающим сертификаты пользователей, и разрешает им доступ к ресурсам в соответствии со схемой проверки подлинности на основе сертификатов.
Шаг 7: Нажмите "Установить".
Шаг 8: Под флажками (уведомление) нажмите "Настроить службы сертификатов Active Directory на сервере".
Шаг 9: Здесь вы можете указать учетную запись администратора, которую вы хотите использовать в качестве ЦС.
Шаг 10: Выберите CA (избыточный шаг, но все равно нажмите)
Шаг 11. Выберите ЦС предприятия
Шаг 12. Выберите корневой ЦС, поскольку администратор домена находится на вершине структуры PKI.
Шаг 13: Создайте новый закрытый ключ. Как объяснялось выше, для подписи любого пользовательского сертификата, включая корневой ЦС, требуется закрытый ключ. Этот ключ можно использовать для подделки золотого сертификата, как будет объяснено позже.
Шаг 14: Вы можете изменить по своему желанию. Мы оставляем все с настройками по умолчанию.
Шаг 15: Здесь вы можете добавить общее имя для этого сертификата CA, который вы установили.
Шаг 16: Укажите срок действия сертификата. В демонстрационных целях оставьте их по умолчанию
Шаг 17: Настройте расположение сертификата и нажмите "Далее".
Шаг 18: Нажмите "Настроить".
Шаг 19: Как видите, сертификат успешно настроен.
Теперь, когда мы настроили ADCS и аутентификацию на основе сертификатов, мы готовы к работе.
Теперь у нас есть следующая архитектура для тестирования:
Контроллер домена — DC1@ignite.local — администратор
Пользователь (Клиент) — hardit@ignite.local — клиент Windows 10 подключен
Машина злоумышленника — автономная версия Kali Linux
Извлечение сертификата ЦС
В этой статье демонстрируется персистенс домена. Следовательно, мы предполагаем, что злоумышленник уже скомпрометировал компьютер пользователя в домене и повысил свои привилегии до администратора домена. Теперь злоумышленник хочет, чтобы его соединение сохранялось в течение длительного периода времени. Вот где золотой сертификат вступает в игру. Чтобы подделать золотой сертификат, мы сначала извлечем комбинацию сертификат CA + закрытый ключ, используя этот файл (закрытый ключ), мы создадим новый сертификат для определенного пользователя (здесь, DC), а затем используем этот сертификат для запроса билетов, дамп хэшей и т.д.
Первый шаг — извлечение ЦС. Мы можем использовать команду запуска certsrv.msc в скомпрометированной системе администрирования домена.
Откроется окно со списком всех центров сертификации в пуле серверов. Выбираем резервный CA
Нажмите "Далее"
Здесь нажмите "Закрытый ключ и сертификат ЦС" и укажите местоположение каталога, в котором вы хотите создать резервную копию этого сертификата. Наше местоположение C:\cert
Вы можете ввести пароль для защиты этого файла резервной копии. Это необязательно, но мы можем оставить простой пароль, например 12345.
Теперь сертификат успешно извлечен. Существуют и другие способы извлечения сертификата ЦС. Вы также можете сделать это с помощью mimikatz.
Подделка нового сертификата ЦС
Как вы заметили, извлеченный сертификат имеет формат p12. Это эквивалентно формату pfx, и теоретически простое изменение расширения должно было преобразовать p12 в pfx, но из-за некоторых ошибок мы использовали openssl для правильного преобразования p12 в pfx с помощью двухэтапного процесса.
Во-первых, вам нужно скачать Openssl отсюда (https://slproweb.com/download/Win64OpenSSL_Light-3_0_1.exe). После установки вы можете перейти в папку C:\cert (папка, в которой была создана резервная копия сертификата) и выполнить следующую команду, чтобы преобразовать этот сертификат p12 в файл pem.
"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -in ignite-DC1-CA.p12 -out newfile.pem
Здесь вам нужно ввести пароль импорта 12345. Вы можете установить новый пароль для этого pem-файла. Мы сохранили его как 12345 только для простоты. Как видите, «newfile.pem» создан.
Теперь вам нужно запустить другую команду openssl, чтобы преобразовать этот pem в pfx.
"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -in newfile.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
Обратите внимание, здесь мы добавили два дополнительных параметра.
-keyex: указывает, что закрытый ключ должен использоваться для обмена ключами или просто для подписи.
-CSP: обозначает поставщика криптографических услуг. Эта команда указывает, что выходной файл имеет стандартный формат Microsoft CSP. Вы можете прочитать больше об этом здесь (https://docs.microsoft.com/en-us/windows/win32/seccrypto/microsoft-enhanced-cryptographic-provider).
Вы можете видеть, что файл cer.pfx теперь экспортирован в этот каталог.
Используя закрытый ключ, доступный в этом cert.pfx (комбинация CA и закрытый ключ), мы подделаем сертификат. Инструмент, который мы будем использовать, — ForgeCert. Эту программу можно скомпилировать в Visual Studio 2022, просто импортировав файл *.sln и создав исполняемый файл. Обратите внимание, что вместе с исполняемым файлом нам понадобится BouncyCastle.dll и некоторые файлы конфигурации. Эти файлы будут выводиться в папку проекта/bin/debug. Скопируйте эти файлы как есть в папку C:\cert.
Теперь мы подделаем наш новый сертификат с помощью следующей команды:
ForgeCert.exe --CaCertPath cert.pfx --CaCertPassword 12345 --Subject CN=User --SubjectAltName DC1@ignite.local --NewCertPath admincert.pfx --NewCertPassword ignite@123
Вы можете оставить здесь сложный пароль, но мы оставляем простой ignite@123
Теперь золотой сертификат со сроком действия 1 год сохранен! Это означает, что у меня есть доступ к домену уже как минимум год!
Получение TGT администратора домена
Теперь, когда я подделал свой золотой сертификат, я могу выполнить ряд атак. Мы моделируем сценарий, в котором пароль администратора изменился. Злоумышленник больше не может получить доступ к администратору домена, но у него все еще есть пользовательская система (клиент Windows 10 здесь). Также у злоумышленника остался с собой золотой сертификат! Он может использовать Rubeus, чтобы запросить TGT администратора следующим образом:
Rubeus.exe asktgt /user
C1 /certificate:admincert.pfx /password:ignite@123
Он дает билет *.kirbi, который представляет собой закодированный в base64 формат TGT.
Итак, мы можем преобразовать этот TGT в декодированный формат base64 с помощью команды kali:
echo "<ticket value>" | base64 --decode > ticket.kirb
Извлечение хэша администратора NTLM
С помощью этого ticket.kirbi мы можем проводить атаки на билеты, среди прочего извлекать хэши NTLM. Поскольку мы не знаем новый пароль администратора, давайте попробуем извлечь его учетные данные.
Для этого мы запустим mimikatz для пользователя (Windows 10 имеет прав не-администратора в AD), импортируем ticket.kirbi с помощью модуля Kerberos::ptt, а затем выполним атаку DCSync. Поскольку билет является билетом администратора домена, мы можем выполнять функции, требующие повышенных привилегий.
kerberos::ptt ticket.kirbi
lsadump::dcsync /domain:ignite.local /user:administrator
Это дает нам свежий набор хэшей NTLM администратора.
Выполнение атаки PtH (Pass the Hash)
Далее мы можем выполнить Pass the hash, используя эти учетные данные, или взломать их, используя john/hashcat. Мы переходим к нашему терминалу Kali и используем двоичный файл pth-winexe, который является частью инструментария передачи хэша от byt3bl33d3r. Он встроен в новую ОС kali.
pth-winexe -U Administrator%00000000000000000000000000000000:32196B56FFE6F45E294117B91A83BF38 //192.168.1.188 cmd.exe
Как видите, мы добавили 32 бита 0 перед хэшем, который мы сдампили. Начиная с выпуска Windows 10 Microsoft внесла изменение, согласно которому хэши LM больше не используются. Но инструменты, которые мы собираемся использовать на практике, используются еще со времен старых NT и LM. Итак, в этих инструментах мы будем использовать строку из 32 нулей вместо хэша LM. Также следует отметить, что когда мы говорим NTLM в наше время, мы имеем в виду NTHash.
NTLM — это распространенное имя, которое закрепилось.
Итак, как вы можете видеть с помощью золотого сертификата, мы смогли извлечь административные билеты, выгрузить хэши и выполнить атаки Pass the hash or pass the ticket.
Вывод
95% компаний из списка Fortune 500 так или иначе используют Active Directory. Злоумышленники или аналитики часто проводят пентесты в корпоративной AD. Атака с золотым сертификатом — это атака на сохранение домена, которая может позволить злоумышленнику до года сохраняться на скомпрометированной машине, даже если пароль администратора был изменен или были добавлены новые администраторы. Это полезный метод, который потенциально может использовать различные дополнительные атаки в будущем на ADCS. Надеюсь, вам понравилась статья. Спасибо за чтение.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://www.hackingarticles.in/domain-persistence-golden-certificate-attack/
Аналитики безопасности, имеющие некоторое представление об Active Directory и пентесте, должны знать концепцию билетов. Kerberos, механизм аутентификации по умолчанию в AD, использует аутентификацию на основе билетов, где центр распространения ключей (KDC) предоставляет Ticket-Granting Ticket (TGT) пользователю, запрашивающему доступ к службе или учетной записи, который затем можно активировать для создания сервисного билета (ST) для доступа к определенной службе, например учетной записи SQL. Такие атаки, как Golden Ticket, демонстрируют, как злоумышленник может сохранить доступ к администратору домена, получив NTLM-хэш учетной записи "krbtgt". Сохранение домена необходимо для аналитика в случае изменения пароля администратора. Персистенса также можно добиться с помощью проверки подлинности на основе сертификатов, развернутой в службе сертификатов Active Directory. Одним из таких методов является атака "Золотой сертификат". Этот метод использует аутентификацию на основе сертификатов в AD, включенную по умолчанию, с установкой ADCS (службы сертификатов Active Directory) путем подделки нового сертификата с использованием закрытого ключа сертификата CA. Техника была реализована Бенджамином Дельпи в Mimikatz. Уилл Шредер и Ли Кристенсен написали исследовательскую работу по этой технике, на которую можно посмотреть здесь.
Основы ADCS и сертификатов
ADCS обеспечивает аутентификацию в лесу. Он повышает общую безопасность удостоверения участника (пользователя или учетной записи службы), привязывая его к соответствующему закрытому ключу. Сертификат — это документ с цифровой подписью в формате X.509, используемый для шифрования, подписи сообщений и/или проверки подлинности. Он содержит следующие детали:
- Субъект – владелец сертификата.
- Открытый ключ — связывает субъект с закрытым ключом, хранящимся отдельно.
- Даты NotBefore и NotAfter — указывают продолжительность действия сертификата.
- Серийный номер — идентификатор сертификата, присвоенный ЦС.
- Издатель — указывает, кто выдал сертификат (обычно ЦС).
- SubjectAlternativeName — определяет одно или несколько альтернативных имен, под которыми может работать субъект.
- Базовые ограничения — определяет, является ли сертификат ЦС или конечным объектом, и существуют ли какие-либо ограничения при использовании сертификата.
- Использование расширенных ключей (EKU) — идентификаторы объектов (OID), которые описывают, как будет использоваться сертификат. Также известно как Enhanced Key Usage на языке Microsoft.
- Алгоритм подписи — указывает алгоритм, используемый для подписи сертификата.
- Подпись - Подпись органа сертификации выполняется с использованием закрытого ключа эмитента (например, ЦС).
Центры сертификации (ЦС) отвечают за выдачу сертификатов. После установки ADCS ЦС сначала создает собственную пару открытого и закрытого ключей и подписывает собственный корневой ЦС, используя свой закрытый ключ. Хосты добавляют этот корневой ЦС в свои системы для создания системы доверия.
Регистрация сертификата — процесс получения клиентом сертификата от AD CS называется регистрацией сертификата, в котором выполняются следующие шаги:
- Клиент генерирует пару открытый/закрытый ключ
- Клиент размещает открытый ключ в запросе на подпись сертификата, который включает такие сведения, как тема сертификата и имя шаблона сертификата.
- Клиенты подписывают CSR с помощью закрытого ключа и отправляют CSR на корпоративный сервер CA.
- CA-сервер проверяет запрошенный клиентом шаблон сертификата
- ЦС генерирует сертификат и подписывает его с помощью собственного закрытого ключа.
Типы расширений в сертификатах. В этой статье можно найти следующие расширения:
- *.p12 — PKCS#12 — это двоичный формат для хранения сертификата сервера, любых промежуточных сертификатов и закрытого ключа в одном зашифрованном файле. Всякий раз, когда вы экспортируете сертификат с помощью msc, он выходит в формате p12.
- *.pfx — то же самое, что и *.p12. Файлы *.pfx также являются двоичными сертификатами формата PKCS#12. Разница лишь в том, что *.pfx был разработан Microsoft, а *.p12 — Netscape. Итак, из соображений совместимости вы увидите, как мы конвертируем *.p12 в формат *.pfx.
- *.pem — в этом контексте содержит пару сертификат + закрытый ключ в кодировке Base64.
В противном случае файл pem может иметь что угодно в зависимости от разработки.
Установка ADCS в локальной среде AD
Чтобы настроить ADCS в нашей тестовой среде, мы выполнили следующие шаги.
Шаг 1. Перейдите в диспетчер серверов и выберите "добавить роли и функции".
Шаг 2. Вы можете прочитать о предварительных требованиях, которые рекомендует Windows, и нажать "Далее".
Шаг 3: Выберите сервер из пула серверов. В вашей среде может быть несколько пулов, мы выберем DC1.ignite.local.
Шаг 4. В разделе "Роли сервера" выберите "Службы сертификатов Active Directory' и нажмите "Далее".
Шаг 5: Вы можете нажать "Далее" на этом шаге или добавить некоторые функции. Для этой демонстрации нам не нужно ничего дополнительно, поэтому нажмите "Далее".
Шаг 6: Выберите свою роль центра сертификации. Центр сертификации является основным лицом, подписывающим сертификаты пользователей, и разрешает им доступ к ресурсам в соответствии со схемой проверки подлинности на основе сертификатов.
Шаг 7: Нажмите "Установить".
Шаг 8: Под флажками (уведомление) нажмите "Настроить службы сертификатов Active Directory на сервере".
Шаг 9: Здесь вы можете указать учетную запись администратора, которую вы хотите использовать в качестве ЦС.
Шаг 10: Выберите CA (избыточный шаг, но все равно нажмите)
Шаг 11. Выберите ЦС предприятия
Шаг 12. Выберите корневой ЦС, поскольку администратор домена находится на вершине структуры PKI.
Шаг 13: Создайте новый закрытый ключ. Как объяснялось выше, для подписи любого пользовательского сертификата, включая корневой ЦС, требуется закрытый ключ. Этот ключ можно использовать для подделки золотого сертификата, как будет объяснено позже.
Шаг 14: Вы можете изменить по своему желанию. Мы оставляем все с настройками по умолчанию.
Шаг 15: Здесь вы можете добавить общее имя для этого сертификата CA, который вы установили.
Шаг 16: Укажите срок действия сертификата. В демонстрационных целях оставьте их по умолчанию
Шаг 17: Настройте расположение сертификата и нажмите "Далее".
Шаг 18: Нажмите "Настроить".
Шаг 19: Как видите, сертификат успешно настроен.
Теперь, когда мы настроили ADCS и аутентификацию на основе сертификатов, мы готовы к работе.
Теперь у нас есть следующая архитектура для тестирования:
Контроллер домена — DC1@ignite.local — администратор
Пользователь (Клиент) — hardit@ignite.local — клиент Windows 10 подключен
Машина злоумышленника — автономная версия Kali Linux
Извлечение сертификата ЦС
В этой статье демонстрируется персистенс домена. Следовательно, мы предполагаем, что злоумышленник уже скомпрометировал компьютер пользователя в домене и повысил свои привилегии до администратора домена. Теперь злоумышленник хочет, чтобы его соединение сохранялось в течение длительного периода времени. Вот где золотой сертификат вступает в игру. Чтобы подделать золотой сертификат, мы сначала извлечем комбинацию сертификат CA + закрытый ключ, используя этот файл (закрытый ключ), мы создадим новый сертификат для определенного пользователя (здесь, DC), а затем используем этот сертификат для запроса билетов, дамп хэшей и т.д.
Первый шаг — извлечение ЦС. Мы можем использовать команду запуска certsrv.msc в скомпрометированной системе администрирования домена.
Откроется окно со списком всех центров сертификации в пуле серверов. Выбираем резервный CA
Нажмите "Далее"
Здесь нажмите "Закрытый ключ и сертификат ЦС" и укажите местоположение каталога, в котором вы хотите создать резервную копию этого сертификата. Наше местоположение C:\cert
Вы можете ввести пароль для защиты этого файла резервной копии. Это необязательно, но мы можем оставить простой пароль, например 12345.
Теперь сертификат успешно извлечен. Существуют и другие способы извлечения сертификата ЦС. Вы также можете сделать это с помощью mimikatz.
Подделка нового сертификата ЦС
Как вы заметили, извлеченный сертификат имеет формат p12. Это эквивалентно формату pfx, и теоретически простое изменение расширения должно было преобразовать p12 в pfx, но из-за некоторых ошибок мы использовали openssl для правильного преобразования p12 в pfx с помощью двухэтапного процесса.
Во-первых, вам нужно скачать Openssl отсюда (https://slproweb.com/download/Win64OpenSSL_Light-3_0_1.exe). После установки вы можете перейти в папку C:\cert (папка, в которой была создана резервная копия сертификата) и выполнить следующую команду, чтобы преобразовать этот сертификат p12 в файл pem.
"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -in ignite-DC1-CA.p12 -out newfile.pem
Здесь вам нужно ввести пароль импорта 12345. Вы можете установить новый пароль для этого pem-файла. Мы сохранили его как 12345 только для простоты. Как видите, «newfile.pem» создан.
Теперь вам нужно запустить другую команду openssl, чтобы преобразовать этот pem в pfx.
"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -in newfile.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
Обратите внимание, здесь мы добавили два дополнительных параметра.
-keyex: указывает, что закрытый ключ должен использоваться для обмена ключами или просто для подписи.
-CSP: обозначает поставщика криптографических услуг. Эта команда указывает, что выходной файл имеет стандартный формат Microsoft CSP. Вы можете прочитать больше об этом здесь (https://docs.microsoft.com/en-us/windows/win32/seccrypto/microsoft-enhanced-cryptographic-provider).
Вы можете видеть, что файл cer.pfx теперь экспортирован в этот каталог.
Используя закрытый ключ, доступный в этом cert.pfx (комбинация CA и закрытый ключ), мы подделаем сертификат. Инструмент, который мы будем использовать, — ForgeCert. Эту программу можно скомпилировать в Visual Studio 2022, просто импортировав файл *.sln и создав исполняемый файл. Обратите внимание, что вместе с исполняемым файлом нам понадобится BouncyCastle.dll и некоторые файлы конфигурации. Эти файлы будут выводиться в папку проекта/bin/debug. Скопируйте эти файлы как есть в папку C:\cert.
Теперь мы подделаем наш новый сертификат с помощью следующей команды:
ForgeCert.exe --CaCertPath cert.pfx --CaCertPassword 12345 --Subject CN=User --SubjectAltName DC1@ignite.local --NewCertPath admincert.pfx --NewCertPassword ignite@123
Вы можете оставить здесь сложный пароль, но мы оставляем простой ignite@123
Теперь золотой сертификат со сроком действия 1 год сохранен! Это означает, что у меня есть доступ к домену уже как минимум год!
Получение TGT администратора домена
Теперь, когда я подделал свой золотой сертификат, я могу выполнить ряд атак. Мы моделируем сценарий, в котором пароль администратора изменился. Злоумышленник больше не может получить доступ к администратору домена, но у него все еще есть пользовательская система (клиент Windows 10 здесь). Также у злоумышленника остался с собой золотой сертификат! Он может использовать Rubeus, чтобы запросить TGT администратора следующим образом:
Rubeus.exe asktgt /user
C1 /certificate:admincert.pfx /password:ignite@123Он дает билет *.kirbi, который представляет собой закодированный в base64 формат TGT.
Итак, мы можем преобразовать этот TGT в декодированный формат base64 с помощью команды kali:
echo "<ticket value>" | base64 --decode > ticket.kirb
Извлечение хэша администратора NTLM
С помощью этого ticket.kirbi мы можем проводить атаки на билеты, среди прочего извлекать хэши NTLM. Поскольку мы не знаем новый пароль администратора, давайте попробуем извлечь его учетные данные.
Для этого мы запустим mimikatz для пользователя (Windows 10 имеет прав не-администратора в AD), импортируем ticket.kirbi с помощью модуля Kerberos::ptt, а затем выполним атаку DCSync. Поскольку билет является билетом администратора домена, мы можем выполнять функции, требующие повышенных привилегий.
kerberos::ptt ticket.kirbi
lsadump::dcsync /domain:ignite.local /user:administrator
Это дает нам свежий набор хэшей NTLM администратора.
Выполнение атаки PtH (Pass the Hash)
Далее мы можем выполнить Pass the hash, используя эти учетные данные, или взломать их, используя john/hashcat. Мы переходим к нашему терминалу Kali и используем двоичный файл pth-winexe, который является частью инструментария передачи хэша от byt3bl33d3r. Он встроен в новую ОС kali.
pth-winexe -U Administrator%00000000000000000000000000000000:32196B56FFE6F45E294117B91A83BF38 //192.168.1.188 cmd.exe
Как видите, мы добавили 32 бита 0 перед хэшем, который мы сдампили. Начиная с выпуска Windows 10 Microsoft внесла изменение, согласно которому хэши LM больше не используются. Но инструменты, которые мы собираемся использовать на практике, используются еще со времен старых NT и LM. Итак, в этих инструментах мы будем использовать строку из 32 нулей вместо хэша LM. Также следует отметить, что когда мы говорим NTLM в наше время, мы имеем в виду NTHash.
NTLM — это распространенное имя, которое закрепилось.
Итак, как вы можете видеть с помощью золотого сертификата, мы смогли извлечь административные билеты, выгрузить хэши и выполнить атаки Pass the hash or pass the ticket.
Вывод
95% компаний из списка Fortune 500 так или иначе используют Active Directory. Злоумышленники или аналитики часто проводят пентесты в корпоративной AD. Атака с золотым сертификатом — это атака на сохранение домена, которая может позволить злоумышленнику до года сохраняться на скомпрометированной машине, даже если пароль администратора был изменен или были добавлены новые администраторы. Это полезный метод, который потенциально может использовать различные дополнительные атаки в будущем на ADCS. Надеюсь, вам понравилась статья. Спасибо за чтение.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://www.hackingarticles.in/domain-persistence-golden-certificate-attack/