8126 подписчиков

Domain Persistence: атака Golden Certificate

11 минут

20 прочтений

2 февраля 2022

В данной статье пойдет речь об атаке Golden Certificate. Читатели узнают особенности ее осуществления, возможности которые она предоставляет хакерам.

Введение

Аналитики в сфере ИБ, которые знакомы с Active Directory и тестированием на проникновение, должны понимать «концепцию билетов». Kerberos, механизм аутентификации по умолчанию в AD, использует аутентификацию на основе «билетов», при которой Key Distribution Center (KDC) предоставляет пользователю, запрашивающему доступ к службе или учетной записи, Ticket-Granting Ticket (TGT). Его затем можно использовать для создания Service Ticket (ST) для получения доступа к определенной службе, например аккаунту SQL. Атаки, такие как Golden Ticket, дают возможность хакеру сохранить за собой доступ к аккаунту администратора домена, заполучив NTLM-хеш учетной записи “krbtgt”. Сохранение постоянного доступа к аккаунту админа необходимо аналитикам ИБ в случае изменения пароля. Domain Persistence может быть осуществлено и с помощью проверки подлинности на основе сертификатов, развернутой в Active Directory Certificate Service.

Одной из таких методик является атака Golden Certificate. При ее осуществлении используется аутентификация на основе сертификатов в AD, включенная по умолчанию при установке ADCS (Active Directory Certificate Services). Хакер создает новый сертификат с использованием специального ключа для сертификата CA. Эта атака была на практике осуществлена Benjamin Delpy в Mimikatz. Теоретические основы осуществления атаки можно почитать в работе Will Schroeder и Lee Christensen.

Особенности работы ADCS и что собой представляет Certificate

ADCS обеспечивает аутентификацию в лесу. Она повышает общий уровень безопасности во время идентификации (учетной записи пользователя или службы), привязывая данный процесс к соответствующему ключу. Certificate – это документ с цифровой подписью в формате X.509, используемый для шифрования, подписи сообщений и аутентификации. Он содержит в себе следующие данные:

Subject – владелец сертификата
Public Key – связывает Subject со специальным конфиденциальным ключом, хранящимся отдельно
NotBefore и NotAfter dates – определяют срок действия сертификата
Serial Number – идентификатор сертификата, присвоенный центром сертификации
Issuer – указывает на того, кто выдал сертификат (обычно – на центр сертификации)
SubjectAlternativeName – включает в себя одно или несколько альтернативных имен, которыми может обозначаться Subject
Basic Constraints – указывает на тип сертификата, существуют ли какие-либо ограничения при его использовании
Extended Key Usages (EKUs) – идентификаторы объектов (OID), которые указывают на то, как будет использоваться сертификат
Signature Algorithm – определяет алгоритм, используемый для подписи сертификата
Signature – подпись центра сертификации, которая создается с использованием конфиденциального ключа

Центры сертификации (CA) отвечают за выдачу сертификатов. После установки ADCS, CA создает свою собственную пару публичного и конфиденциального ключей и подписывает root CA, используя конфиденциальный ключ. Хосты добавляют этот root CA в свои системы для создания системы доверия.

Регистрация сертификата (Certificate Enrollment) – это процесс получения клиентом сертификата от ADCS. При этом осуществляются следующие шаги:

Клиент генерирует пару публичного и конфиденциального ключей.
Клиент помещает публичный ключ в Certificate Signing Request, который содержит в себе такие сведения, как название и имя шаблона сертификата.
Клиенты подписывают CSR с помощью конфиденциального ключа и отправляют его на корпоративный сервер CA.
Сервер CA проверяет шаблон запрошенного клиентом сертификата.
CA генерирует сертификат и подписывает его, используя свой собственный конфиденциальный ключ.

В данной статье можно встретить следующие расширения сертификатов:

.p12 – представляет собой двоичный формат для хранения сертификата сервера, любых промежуточных сертификатов и конфиденциального ключа в одном зашифрованном файле. Всякий раз, когда пользователь экспортирует сертификат с помощью msc, он выводится в формате .p12.
.pfx – также является двоичными сертификатами формата PKCS#12. Разница лишь в том, что .pdx был разработан Microsoft, а .p12 — Netscape. Можно конвертировать файл в формате .p12 в .pfx.
.pem – представляет собой сертификат в кодировке Base64 + пару конфиденциальных ключей в этом контексте. В целом, .pem может содержать все, что угодно, в зависимости от нужд создателя файла.

Установка ADCS в локальной среде AD

Чтобы настроить ADCS в тестовой среде, нужно выполнить следующие действия:

Перейти в Server Manager и выбрать параметр «Add roles and features»

Здесь следует ознакомиться с предустановками Windows, выполнить их и нажать на кнопку «Next»

Теперь нужно выбрать сервер из пула серверов. Пользователь выбирает DC1.ignite.local

В разделе «Server Roles» пользователь отмечает галочкой «Active Directory Certificate Services» и нажимает на кнопку «Next»

Можно нажать на кнопку «Next» или добавить некоторые функции. Для данного практического примера доп. функции не нужны

Пользователь выбирает роль – «Certificate Authority». CA является основным средством для подписывания сертификатов пользователей и предоставляет доступ к ресурсам в соответствии со схемой аутентификации на основе сертификатов

Пользователь кликает на кнопку «Install»

Теперь следует нажать на кнопку «Configure Active Directory Certificate Services on the server»

Далее нужно указать учетную запись администратора, которую следует использовать в качестве CA

Следует отметить «Certification Authority»

Выбрать «Enterprise CA»

Выбрать «Root CA», так как администратор домена находится на вершине структуры PKI

Необходимо создать новый конфиденциальный ключ. Как уже было сказано выше, для подписи любого сертификата пользователя, включая Root CA, необходим конфиденциальный ключ. Его можно использовать для подделки Golden Certificate

В следующем окне можно изменить настройки (по своему усмотрению). В данном практическом примере они остаются по умолчанию

Далее можно добавить общее имя для установленного СA Сertificate

После этого указывается срок действия сертификата. В данном практическом примере срок действия не будет изменен

Пользователь изменяет путь сохранения на свое усмотрение

Кликает на «Configure»

СA был успешно настроен

Теперь, когда пользователь настроил ADCS и аутентификацию на основе сертификатов, пора приступать к атаке.

Есть следующая архитектура для тестирования:

Контроллер домена – DC1@ignite.local – администратор
Пользователь (Клиент) – harshit@ignite.local – подключенный клиент Windows 10
Атакующая машина – Kali Linux (автономная)

Извлечение CA Certificate

Хакер уже скомпрометировал компьютер жертвы и получил права администратора домена. Теперь он хочет, чтобы его соединение сохранялось в течение длительного периода времени. Вот тут-то ему и потребуется Golden Certificate. Чтобы подделать его, хакер сначала извлекает CA Certificate + конфиденциальный ключ, используя файл с конфиденциальным ключом. Будет создан новый сертификат для конкретного пользователя (в данном случае, DC), а затем хакер использует этот сертификат для запроса «билетов», дампа хешей.

Первый шаг – извлечение CA. Можно использовать команду «certsrv.msc» в скомпрометированной системе администратора домена.

Откроется окно со списком всех CA в пуле сервера. Следует выбрать параметр «Back up CA», а потом кликнуть на «Next».

В следующем окне пользователь отметит пункт «Private Key and CA certificate» и укажет каталог, в котором он хочет создать резервную копию этого сертификата.

Можно также добавить пароль для защиты этой резервной копии. Это необязательно, но пользователь указывает самый простой пароль – «12345».

Сертификат был успешно извлечен. Существуют и другие способы извлечения CA Certificate. Это можно сделать и с помощью mimikatz.

Создание нового CA Certificate

Как можно заметить, извлеченный сертификат имеет формат .p12. Он эквивалентен формату .pfx, и теоретически простое изменение расширения должно было преобразовать .p12 в .pfx, но из-за некоторых ошибок пользователю пришлось использовать openssl для корректной конвертации.

Во-первых, нужно скачать Openssl. После установки следует перейти в папку, в которой была создана резервная копия сертификата, и выполнить следующую команду, чтобы преобразовать файл .p12 в файл .pem:

"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -in ignite-DC1-CA.p12 -out newfile.pem

Нужно также ввести пароль для импорта – «12345». Пользователь может установить новый пароль для этого файла .pem. Хакер оставил его прежним для простоты. Как можно увидеть, был создан «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. Подробнее об этом можно прочитать здесь.

Можно увидеть, что «cer.pfx» теперь экспортирован в нужный каталог.

Используя конфиденциальный ключ, доступный в файле «cert.pfx», пользователь подделает сертификат. Инструмент, который он будет использовать, — это ForgeCert. Эту программу можно скомпилировать в Visual Studio 2022, просто импортировав файл .sln и создав исполняемый файл. Стоит отметить, что вместе с exe-файлом понадобится 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».

Теперь Golden Certificate сроком действия 1 год получен! Это означает, что у хакера есть доступ к домену на протяжении следующего года.

Получение TGT администратора домена

Теперь, когда хакер подделал Golden Certificate, он может выполнить ряд атак. Хакер моделирует сценарий, при котором пароль администратора был изменен. Он больше не сможет получить доступ к аккаунту администратора домена, но у него все еще есть в распоряжении пользовательская система (клиент Windows 10). Кроме того, у хакера все еще есть с собой Golden Certificate! Он может использовать Rubeus, чтобы получить TGT администратора:

Rubeus.exe asktgt /user:DC1 /certificate:admincert.pfx /password:ignite@123

Так будет получен билет .kirby, который представляет собой TGT в кодировке base64.

Таким образом, пользователь может преобразовать его в декодированный формат base64 с помощью команды в Kali:

echo "<ticket value>" | base64 --decode > ticket.kirb

Получение NTLM-хеша администратора

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

Для этого хакер запустит mimikatz (скомпрометированная система Windows 10), импортирует билет .kirby с помощью модуля «Kerberos::ptt», а затем выполнит атаку DCSync. Поскольку билет является билетом администратора домена, хакер может выполнять функции в системе, которые требуют высоких привилегий.

kerberos::ptt ticket.kirbi
lsadump::dcsync /domain:ignite.local /user:administrator

После выполнения команды хакер получает NTLM-хеш администратора.

Осуществление атаки PtH (Pass the Hash)

В дальнейшем можно выполнить хеш-атаку с использованием этих учетных данных или взломать аккаунт с помощью john / hashcat. Пользователь открывает свой терминал Kali и использует двоичный файл «pth-winexe», который является частью набора инструментов для передачи хеша от byt3bl33d3r.

pth-winexe -U Administrator%00000000000000000000000000000000:32196B56FFE6F45E294117B91A83BF38 //192.168.1.188 cmd.exe

Как можно увидеть, пользователь добавил нули перед полученным хешем. Начиная с Windows 10, Microsoft внесла изменения в свою ОС, согласно которым хеши LM больше не используются. Но инструменты, которые пользователь использует в практическом примере, существуют еще со старых времен NT и LM. Итак, в этих инструментах следует использовать строку из 32 нулей вместо хеша LM.

Следует отметить, что когда речь идет о NTLM, имеется в виду NTHash. NTLM – это просто распространенное название.

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

Заключение

95% компаний из списка Fortune 500 так или иначе используют Active Directory. Специалисты ИБ часто осуществляют тестирование на проникновение. Атака Golden Certificate – это атака на сохранение доступа к домену; с помощью нее можно иметь доступ к домену долгое время, даже если пароль администратора был изменен или были добавлены новые администраторы. Применение данной практики в дальнейшем может привести к появлению целого ряда новых атак с задействованием Active Directory.

Автор переведенной статьи: Raj Chandel.

Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.