Kerberos для специалиста по тестированию на проникновение. Часть 2. Классические атаки

Вступление

Для Active Directory известно множество атак с использованием протокола Kerberos. Попробую перечислить некоторые из них:

Атаки на повышение привилегий

1. Перебор пользователей
2. Распыление / Подбор паролей
3. AS-REQ roasting
4. AS-REP roasting
5. Kerberoasting (AnySPN, целенаправленный Kerberoasting)

Атаки для дальнейшего продвижения

6. Pass-the-Key / Overpass-the-hash
7. Pass-the-Ticket / Pass-the-Cache

Атаки для закрепления

8. Silver Ticket
9. Golden Ticket
10. Skeleton Key
11. Diamond Ticket

Атаки на делегирование

12. На неограниченное делегирование
13. На ограниченное
14. На ограниченное на основе ресурсов

А также:

15. Bronze bit
16. sAMAccountName спуфинг
17. Pass the certificate
18. MS14-068 (Forged PAC)
19. Krbrelay
20. Атаки на доверие между доменами
21. …

Далее будут разобраны “классические” атаки из пунктов 1-9. Разбор остальных атак требует изложения дополнительного теоретического материала и пока только в планах на будущее.

Демонстрация некоторых атак совершалась на стенде с TryHackMe.

Атака на подбор имен пользователей

Условие для проведения атаки: сетевая доступность контроллера домена.

Результат успешной атаки: перечень, содержащий некоторые действительные имена учетных записей пользователей домена.

Kerberos позволяет узнать существует ли учетная запись при подборе имени с неверным паролем. Атака заключается в отправке KRB_AS_REQ сообщения с отключенной предварительной аутентификацией. Контроллер домена обрабатывает указанное сообщение по-разному в зависимости от наличия или отсутствия учетной записи. Возможны три варианта:

1. Если учетная запись отсутствует, то в ответе будет «пользователь не известен».
2. Если учетная запись присутствует и у нее включена предварительная аутентификация (по умолчанию в Active Directory), то в ответе будет «требуется предварительная аутентификация».
3. Если учетная запись присутствует и у нее отключена предварительная аутентификация, то в ответ будет передано KRB_AS_REP сообщение.

Примечание: неудачные попытки перебора не логируются в качестве событий неуспешного входа (ID 4625). Поэтому считается, что подбор имен пользователей через Kerberos чуть более скрытный, чем с помощью некоторых других способов. Есть и другое преимущество счетчик неверных попыток ввода пароля не увеличивается. Таким образом риск заблокировать учетную запись при повторном подборе имени пользователя отсутствует.

Команда для проведения атаки:

./kerbrute_linux_amd64 userenum -d $Domain_fqdn $users_list --output $filename

Рекомендации по противодействию:

• Отслеживать аномальные запросы на аутентификацию с неуспешной предварительной аутентификацией, например при помощи системы анализа трафика и (или) системы управления событиями информационной безопасности.

Дополнительно:

Имена пользователей можно попытаться добыть из разных источников:

• Профили в социальных сетях
• Метаданные из файлов, располагающихся в целевом домене (FOCA)
• Почтовые адреса

Имена как правило назначаются в соответствие с каким-то шаблоном. Пользователь Иванов Василий Петрович например может быть назван: pivanov, ivanov_vp, p.ivanov, ivanovp, … Полезно сначала узнать шаблон, а потом в соответствие с ним пробовать перечислять имена.

Личный комментарий: В моей практике редко доводилось проводить указанную атаку, так как обычно в ходе внутреннего тестирование на проникновение получить перечень доменных имен пользователей проще при помощи Relay на LDAP c последующим выполнением ldapdomaindump. Описание указанной атаки выходит за рамки материала, но для самообразования рекомендую следующий пост.

Для желающих попробовать провести атаку на перебор имени на HackTheBox есть стенд Sauna.

Распыление пароля

Условие для проведения атаки: сетевая доступность контроллера домена.

Результат успешной атаки: доступ с правами атакованной учетной записи.

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

• Сложность пароля - какие символы обязательно должны присутствовать в пароле. По умолчанию должны использоваться 3 из 4 следующих категорий: строчные буквы, заглавные буквы, цифры, спецсимволы (~!@#$%^&*_-+=`|(){}[]:;"’<>,.?/)
• Минимальная длина пароля. По умолчанию составляет 7 символов.
• Порог блокировки учетной записи. По умолчанию равен 0, то есть учетная запись не блокируется. Если значение равно X>0, то после достижения счетчика блокировки X, учетная запись будет заблокирована.
• Время до сброса счетчика блокировки. По умолчанию не определено, так как имеет смысл, только когда порог блокировки ненулевой.
• Длительность блокировки учетной записи. По умолчанию 30 минут.

Атаку целесообразно повторять X-1 раз за не менее чем Y + 5 минут (X - порог блокировки учетной записи, Y - время до сброса счетчика).

Команда для проведения атаки:

./kerbrute_linux_amd64 passwordspray -d $Domain_FQDN $users_list $Password

Рекомендации по противодействию:

• Реализовать строгую парольную политику:
  • Минимальная длина пароля: 10 для пользователей, 14 для администраторов.
  • Порог блокировки учетной записи: 5.
  • Время до сброса: 30 минут.
  • Длительность блокировки и сложность: по умолчанию.
  • Запретить использовать предыдущие пароли. Добавить правило, чтобы новый пароль отличался от предыдущих на не менее, чем 3 символа.
• Периодически выгружать NT-хэши из NTDS.dit и проводить инвентаризацию учетных записей на предмет наличия словарных паролей. Простенький словарь для инвентаризации можно взять здесь.
• С использованием межсетевых экранов ограничить доступ к KDC для сетевых объектов, не входящих в белый список.

Источник: Kerbrute

AS-REQ roasting

Условие для проведения атаки:

• Получение KRB_AS_REQ сообщения с включенной предварительной аутентификацией

Варианты выполнения условия:

• Сообщение можно получить в результате атаки, направленной на перехват сетевого трафика (ARP spoofing, ICMP redirect, поддельный DHCP сервер, IPv6 spoofing).
• Сообщение можно извлечь из дампа сетевого трафика (PCredz)

Результат успешной атаки:

• Доступ с правами атакованной учетной записи

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

Команды для проведения атаки в Linux:

Извлечение аутентификационных данных из pcap файла:

Pcredz -f $filepath

Извлечение аутентификационных данных из всех pcap файлов в папке:

Pcredz -d $dir_path

Извлечение аутентификационных данных при прослушивании сетевого интерфейса

Pcredz -i $interface_name -v

Hashcat:

Если штамп времени зашифрован с использованием RC4:

hashcat -m 7500 $AS_Req_rc4_hashes $dictionary

В случае AES256:

hashcat -m 19900 $AS_Req_AES256_hashes $dictionary

Рекомендация по противодействию:

• Реализовать строгую парольную политику (смотри ранее)
• С использованием встроенных возможностей телекоммуникационного оборудования реализовать защиту от атак, направленных на перехват сетевого трафика (DHCP snooping, Dynamic ARP Protection, IP Source Guard и т.д.).
• Для привилегированных учетных записей использовать двухфакторную аутентификацию.

Личный комментарий: атака не пользуется особой популярностью.

Источник

AS-REP roasting

Условие для проведения атаки: знание имени (принципала) учетной записи с отключенной предварительной аутентификацией

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

• Узнать принципал можно после Relay на контроллер домена по LDAP c последующей выгрузкой перечня всех пользователей и попыткой пройти аутентификацию без проверки подлинности от имени каждого из них.

Варианты выполнения условия при наличии прав непривилегированного пользователя домена:

• Выгрузить с помощью Ldapdomaindump
• Посмотреть в Bloodhound

Результат успешной атаки:

• Доступ с правами атакованной учетной записи

Как было рассмотрено в 1 части, при отправке атакующим на контроллер домена KRB_AS_REQ сообщения от имени пользователя, у которого отключена предварительная аутентификация, в ответ присылается KRB_AS_REP сообщение, содержащее сессионный ключ, зашифрованный с использованием секрета указанного пользователя. Таким образом можно попытаться подобрать пароль оффлайн по словарю.

Команды для реализации атаки в Linux:

При отсутствии учетной записи приходиться отправлять KRB_AS_REQ сообщения от имени каждого выявленного пользователя домена. Возьмем результат kerbrute из предыдущей атаки:

Отформатируем его надлежащим образом:

cat found_users.txt | grep "VALID" | cut -f2 > formated_found_users.txt

С использованием полученного файла, содержащего список действительных имен, проведем атаку:

impacket-GetNPUsers $Domain_FQDN/ -usersfile $users_list -outputfile $file

Примечание: получение ошибки «KRB_AP_ERR_SKEW (Clock skew too great)» означает, что время на контроллере домена и рабочей станции атакующего значительно отличаются. В Kerberos, как было рассмотрено ранее, многое зависит от значения часов. Таким образом, прежде чем повторять атаку следует синхронизировать время с помощью следующей команды:

ntpdate $DC_IP

Альтернативно, при наличии прав пользователя домена можно сразу получить список учетных записей с отключенной предварительной аутентификацией при помощи LDAP и отправить KRB_AS_REQ сообщения только от их имени:

impacket-GetNPUsers $domain_FQDN/$domain_username:$user_pass -request -outputfile $file

Также при наличии прав пользователя можно собрать информацию для Bloodhound и уже там посмотреть активные учетные записи с отключенной предварительной аутентификацией:

У выявленных учетных записей полезно проверить права доступа:

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

Команды для реализации атаки в Windows:

Для проведения атак на Kerberos с Windows существует полезный инструмент - Rubeus. Обычно подразумевается, что Rubeus запущен в контексте процесса с правами пользователя домена, поэтому в аргументах аутентификационные данные не указываются.

Лирическое отступление: название Rubeus выбрано не случайно. Это имя Хагрида из Гарри Поттера. Он любил страшных животных и умел с ними обращаться. В частности Хагрид знал, что если поиграть на арфе, то можно усыпить Цербера.

Rubeus.exe asreproast /outfile:$result_File

Получив заветные хэши, можно осуществить оффлайн подбор пароля с помощью Hashcat:

hashcat -m 18200 $asrep_hashes_file $dict_file

Рекомендация по противодействию:

• Реализовать строгую парольную политику (смотри ранее)
• Провести инвентаризацию учетных записей на предмет отключенной предварительной аутентификации. Для каждой из выявленных учетных записей рассмотреть целесообразность отключения. В случае невозможности включения предварительной аутентификации следует руководствоваться принципом минимальных привилегий и не наделять выявленные учетные записи правами уровня администратора домена.
• С использованием межсетевых экранов ограничить доступ к KDC для сетевых объектов, не входящих в белый список.

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

Для самостоятельной тренировки есть стенд Forest на HackTheBox (доступен по платной подписке).

Kerberoasting

Условие для проведения атаки: права уровня непривилегированного пользователя домена.

Некоторые варианты выполнения условия:

• AS-REP roasting
• Подбор или распыление пароля
• Эксплуатация критической уязвимости
• Обнаружить в открытом виде в общедоступной сетевой папке
• Подбор методом оффлайн перебора по NetNTLMv2 хэшу

Результат успешной атаки: доступ с правами атакованной учетной записи.

Первым делом атакующий осуществляет поиск учетных записей, обладающих SPN. Делается это при помощи LDAP, например с использованием следующего запроса:

"(&(objectClass=user)(objectCategory=user)(servicePrincipalName=*))"

Примечание 1: Для выполнения приведенного выше запроса требуются права уровня непривилегированного пользователя домена.
Примечание 2: Осуществлять поиск среди учетных записей класса “компьютер” нет смысла, так как пароль к указанным учетным записям не является словарным.

Далее атакующий отправляет KRB_TGS_REQ сообщения с указанием SPN, ассоциированными с выявленными учетными записями. Контроллер домена не занимается авторизацией, то есть не проверяет имеет ли скомпрометированная учетная запись право доступа к запрашиваемым сервисам, поэтому в ответ отправляются сообщения, содержащие TGS билеты, зашифрованные с использованием секретов сервисов. Таким образом, получив TGS-билеты, атакующий может попробовать подобрать пароль к сервисам по словарю оффлайн.

Команды для проведения атаки в Linux:

При необходимости синхронизируем время:

ntpdate $DC_IP

Осуществляем поиск всех учетных записей, имеющих SPN, и запрашиваем для них TGS:

impacket-GetUserSPNs -dc-ip $DC_IP $Domain_FQDN/$username:$password -request -outputfile $file

Команды для проведения атаки в Windows:

Rubeus.exe kerberoast /outfile:$file

Примечание 3: Извлечь TGS билеты и провести оффлайн подбор пароля также возможно в результате анализа сетевого трафика с помощью extracttgsrepfrompcap

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

В заключении выполняем перебор с Hashcat:

hashcat -m 13100 $kerberos_hashes $dictionary

Kerberoasting + AnySPN

Существуют способы выполнить Kerberoasting, не зная SPN имени сервиса. Ранее уже подробно рассматривался формат SPN: service-name/host:port@REALM.

У одной учетной записи может быть несколько сервисов, то есть несколько SPN. Проблема заключается в том, что поле “имя сервиса” в ходе KRB-запросов не зашифровывается. То есть вместо одного сервиса можно указать другой и ничего не сломается, так как все сервисы, принадлежащие одной учетной записи, обладают одинаковым секретом и могут расшифровать TGS билет, предназначенный другому сервису указанной учетной записи. Атака методом подмены SPN называется AnySPN.

Таким образом возможна следующая вариация Kerberoasting: если известно имя учетной записи (SAM Account Name, SAN) и что она обладает каким-то SPN, то все равно можно запросить TGS билет, указав SAN вместо SPN, и Kerberoasting отработает.

Подытожим: возможно получить TGS-билет, не зная названия сервиса.

Целевой Kerberoasting

Условие для проведения атаки: наличие одного из прав - GenericAll, GenericWrite, WriteProperty или Validated-SPN в отношении атакуемой учетной записи.

Результат успешной атаки: доступ с правами атакованной учетной записи

Наличие одного из перечисленных выше прав, позволяет установить SPN у атакуемой учетной записи. Таким образом указанная учетная запись становится подверженной атаке Kerberoasting.

Команда для выполнения атаки:

targetedKerberoast.py -v -d $domain_FQDN -u $username -p $password

Для выполнения целевого Kerberoasting в отношении конкретной учетной записи смотри справку targetedKerberoast.py

Рекомендация по противодействию Kerberoasting:

• Установить для сервисных учетных записей несловарные пароли длинной от 20 символов
• Использовать защищенный канал между клиентом и контроллером домена для обмена KRB-сообщениями (Flexible Authentication Secure Tunneling или Kerberos armoring).
• Использовать групповые учетные записи служб (Group Managed Service Accounts, gMSA) в качестве сервисных учетных записей.
• Создать “ложную” сервисную учетную запись, обладающую SPN, но не имеющую отношения ни к какому приложению. В дальнейшем необходимо отслеживать попытки запроса TGS к указанной службе. Пример для вдохновения.
• Руководствоваться принципом минимальных привилегий в отношении сервисных учетных записей. В частности, не наделять сервисные учетные записи правами уровня администратора домена. Удалить неиспользуемые SPN.
• Отслеживать аномальные KRB_TGS_REQ запросы с использованием системы анализа трафика.
• Отключить слабые типы шифрования Kerberos.
• С использованием межсетевых экранов ограничить доступ к KDC для сетевых объектов, не входящих в белый список.

Для самостоятельной тренировки Kerberoasting есть стенд Active на HackTheBox.

Источники:

• Хорошая статья про Kerberoasting на русском языке. Там же можно подробнее прочитать про реализацию рекомендаций на практике.

Для дальнейшего углубленного изучения:

• Статья, в которой рассматриваются типовые ошибки Red Team при Kerberoasting, а также способы остаться незамеченным.

Pass-the-key / Overpass The Hash

Условие для проведения атаки: наличие ключа пользователя.

Варианты выполнения условия:

• Извлечь ключи из памяти скомпрометированной рабочей станции (требуются права администратора)

Результат успешной атаки: дальнейшее продвижение с правами скомпрометированной учетной записи.

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

Наличие доступа с правами администратора по умолчанию означает, что вы можете сделать на рабочей станции всё, что заблагорассудиться. В теории никакие средства защиты не помещают извлечь необходимые сведения, например из памяти процесса LSASS. Обход средств защиты выходит за рамки настоящей статьи.

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

Ключ может иметь различный вид в зависимости от настроек Kerberos (см.ранее). При использовании алгоритма RC4_HMAC_MD5 ключом будет являться NT хэш пароля пользователя. В таком случае атака повторного воспроизведения указанного хэша в Kerberos является подвидом атаки Pass-the-Key и называется Overpass-The-Hash.

Когда целесообразен Pass-the-Key? Допустим в организации отключена аутентификация с использованием NTLM и Kerberos c RC4_HMAC_MD5. На практике подобное маловероятно, но в отношении ряда объектов вполне может встретиться. Тогда знание, AES-ключа все равно позволит получить необходимый доступ без знания пароля.

Команды для выполнения атаки:

При наличии NT-хэша (Overpass-the-Hash)

getTGT.py -hashes $LM:$NT $Domain_FQDN/$username@$target

При наличии ключа, сформированного по AES-алгоритмам

getTGT.py -aesKey $KerberosKey $Domain_FQDN/$username@$target

Рекомендации по противодействию Overpass-the-hash:

• Исключить использование RC4_HMAC_MD5 в Kerberos. В случае невозможности отключения отслеживать аномальные запросы с использованием указанного алгоритма шифрования.

Рекомендации по противодействию Pass-the-key:

• При распределении привилегированного доступа руководствоваться многоуровневой моделью Microsoft. Использовать для администрирования некритичных объектов домена выделенные учетные записи с ограниченными правами. Не использовать административные учетные записи для доступа к рядовым ресурсам.
• Ограничить входящие соединения на межсетевом экране для каждого конечного сетевого объекта, в первую очередь для серверов.
• Использовать Credential Guard для защиты процесса lsass.exe и противодействия извлечению аутентификационных данных на объектах сети функционирующих под управлением ОС семейства Windows.
• Ограничить входящие соединения на межсетевом экране каждого конечного узла.

Для дальнейшего углубленного изучения:

• Исследование harmj0y о возможном понижении версии алгоритма формирования ключа (AES -> RC4)

Pass-the-Ticket (PtT) / Pass-the-Cache

Условие для проведения атаки: наличие TGT или TGS билетов.

Варианты выполнения условия:

• Извлечь билеты из скомпрометированной рабочей станции при наличии прав администратора
• Извлечь билеты из резервной копии рабочей станции (без прав администратора)
• Извлечь из рабочей станции билеты только скомпрометированного пользователя (без прав администратора)
• Сформировать на своей рабочей станции самостоятельно при наличии соответствующих аутентификационных данных

Результат успешной атаки: дальнейшее продвижение с правами скомпрометированной учетной записи.

Прежде чем приступить к разбору атаки рассмотрим, как хранятся билеты Kerberos в различных операционных системах.

В Linux для хранения Kerberos используется формат ccache (от credential cache). Сами билеты могут быть обнаружены в:

• в директории /tmp в файлах с именем, имеющим вид: krb5cc_%{uid}
• в памяти ядра, специально предназначенной для хранения ключей (kernel keyrings)
• в памяти пользовательского процесса

В Windows билеты Kerberos хранятся в памяти процесса lsass в формате kirbi. Просмотреть доступные текущему пользователю билеты можно следующим образом:

PS C:\Users\Ivan> klist

Конвертировать билеты в необходимый формат можно следующим образом:

kirbi -> ccache (Windows -> Linux)

ticketConverter.py $ticket.kirbi $ticket.ccache

ccache -> kirbi (Linux -> Windows)

ticketConverter.py $ticket.ccache $ticket.kirbi

Команды для выполнения атаки:

В Linux:

export KRB5CCNAME=path_to_ticket.ccache

В Windows при помощи Mimikatz:

kerberos::ptt path_to_ticket.kirbi

В Mimikatz можно также использовать ccache формат:

kerberos::ptt path_to_ticket.ccache

В Windows при помощи Rubeus:

Rubeus.exe ptt /ticket:"base64 | file.kirbi"

В Linux для использования загруженных билетов в поддерживающих Kerberos инструментах необходимо указать соответствующие ключи (как правило: -no-pass / -k).

О каких инструментах идет речь? В первую очередь об утилитах, входящих в состав Impacket, и crackmapexec.

Пример:

psexec.py -k $Domain_FQDN/$username@$target

В Windows после загрузки в lsass билет будет использоваться по умолчанию.

.\PsExec.exe -accepteula \\<target> cmd

PtT + AnySPN

Очевидно, что больше возможностей для дальнейшего продвижения предоставляет именно TGT, ведь TGS билет используется для доступа только к одному определенному сервису.

Это действительно так, но еще раз обратимся к атаке AnySPN. В ходе Pass-the-Key возможно подменить SPN в TGS-билете и использовать модифицированный TGS-билет для доступа к другому сервису, принадлежащему той же учетной записи.

(скриншот взят отсюда)

Рекомендации по противодействию Pass-the-Ticket:

• При распределении привилегированного доступа руководствоваться многоуровневой моделью Microsoft. Использовать для администрирования некритичных объектов домена выделенные учетные записи с ограниченными правами. Не использовать административные учетные записи для доступа к рядовым ресурсам.
• Ограничить входящие соединения на межсетевом экране для каждого конечного сетевого объекта, в первую очередь для серверов.
• Использовать Credential Guard для защиты процесса lsass.exe и противодействия извлечению аутентификационных данных на объектах сети функционирующих под управлением ОС семейства Windows.
• Ограничить входящие соединения на межсетевом экране каждого конечного узла.

Источники литературы:

• Kerberos (II): How to attack Kerberos? (Eloy Pérez)

Silver Ticket

Условие для проведения атаки: наличие ключа сервиса.

Некоторые варианты выполнения условия:

• Kerberoasting
• Извлечь ключ из памяти процесса lsass.exe скомпрометированной рабочей станции (требуются права администратора)
• В результате перебора по радужным таблицам после понижение NTLMv2 -> NTLMv1 (права администратора не требуются)

Результат успешной атаки: закрепление возможности доступа к скомпрометированному сервису с правами уровня администратора домена.

При наличии ключа сервиса атакующий может самостоятельно сформировать TGS-билет для доступа к указанному сервису. Действительно, как было рассмотрено ранее [1][2], для составления TGS-билета требуется:

1. Составить произвольный PAC
2. Подписать PAC ключом сервиса
3. Придумать свой собственный сессионный ключ
4. Указать корректное время и период действия билета
5. Зашифровать получившиеся данные из пунктов 1-4 ключом сервиса
6. Составить аутентификатор от имени произвольного пользователя
7. Зашифровать аутентификатор придуманным сессионным ключом

На этом атака Silver Ticket по сути и заканчивается. Далее с использованием атаки Pass-the-Ticket атакующий обращается к скомпрометированному сервису. Что будет происходить на стороне сервиса при получении созданного лже TGS-билета:

1. Сервис при помощи своего ключа расшифровывает TGS-билет. Отправитель становится доверенным, так как он смог предоставить TGS-билет, который в теории может быть выдан только контроллером домена. Но в теории теория и практика не отличаются, а на практике они расходятся.
2. Сервис проверяет свою подпись PAC.
3. Сервис извлекает сессионный ключ и с его помощью расшифровывает аутентификатор.
4. Сервис предоставляет пользователю из аутентификатора доступ к себе с правами указанными в PAC.

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

- В PAC действительно можно указать произвольные данные?
- Да, например можно указать, что пользователь состоит в группе администраторов домена.

- Погодите, PAC подписывается два раза. Один раз сервис, один раз контроллер домена. Как быть с подписью krbtgt?
- Никак. По умолчанию сервис не отправляет полученный TGS-билет на контроллер домена для проверки подписи. Таким образом даже после смены секрета учетной записи krbtgt атакующий сохранит доступ к сервису.

Команды для выполнения атаки в Linux:

С использованием RC4 ключа (NT-хэша):

ticketer.py -nthash $NThash -domain-sid $DomainSID -domain $DOMAIN -spn $SPN $Username

spn - имя сервиса для которого формируется TGS-билет username - имя произвольной, но реальной учетной записи домена domain-sid - идентификатор безопасности домена, который можно узнать при помощи следующей команды:

lookupsid.py -hashes 'LMhash:NThash' 'DOMAIN/DomainUser@DomainController' 0

С использованием AES ключа:

ticketer.py -aesKey $AESkey -domain-sid $DomainSID -domain $DOMAIN -spn $SPN $Username

Команды для выполнения атаки в Windows:

С использованием RC4 ключа (NT-хэша) в Mimikatz:

kerberos::golden /domain:$DOMAIN /sid:$DomainSID /rc4:$krbtgt_NThash /user:$username_to_impersonate /target:$targetFQDN /service:$spn_type /ptt

С использованием AES128 ключа в Mimikatz:

kerberos::golden /domain:$DOMAIN /sid:$DomainSID /aes128:$krbtgt_aes128_key /user:$username_to_impersonate /target:$targetFQDN /service:$spn_type /ptt

С использованием AES256 ключа в Mimikatz:

kerberos::golden /domain:$DOMAIN /sid:$DomainSID /aes256:$krbtgt_aes256_key /user:$username_to_impersonate /target:$targetFQDN /service:$spn_type /ptt

Примечание: Mimikatz и Ticketer по умолчанию указывают в PAC, что пользователь состоит в административных группах с предопределенными идентификаторами (513, 512, 520, 518, 519). Крайне редко права доступа могут быть нарезаны только для специфической группы и членства в группе администраторов домена будет недостаточно. Тогда при желании более точно сформировать PAC можно воспользоваться утилитой GoldenCopy.

Также хочется отметить некоторые особенности, которые могут выдать Silver Ticket. Это может пригодится Red и Blue Team.

1. В ходе Silver Ticket отсутствует взаимодействие с контроллером домена, то есть атакующий не использует TGT для запроса TGS. Билет появляется из ниоткуда, а это можно отследить в результате анализа логов.
2. Использование алгоритма шифрования RC4 может быть рассмотрено, как аномальное. По умолчанию для рабочих станций используется AES256.
3. Запрос билета с большим временем жизни также может быть рассмотрен, как аномальное поведение.

Рекомендация по противодействию Silver Ticket:

• Использовать проверку подлинности PAC

Ссылки:

• hackndo
• hacker recipes

Материалы для дальнейшего изучения:

• Статья про проверку PAC

Golden Ticket

Условие для проведения атаки: наличие ключа учетной записи krbtgt.

Некоторые варианты выполнения условия:

• Атака DCsync

Результат успешной атаки: закрепление возможности доступа к скомпрометированному домену.

Наличие ключа учетной записи krbtgt позволяет атакующему формировать и изменять TGT по своему усмотрению. Таким образом возможно составить произвольный PAC для любого пользователя домена и получить от его имени доступ к необходимому сервису с желаемыми правами.

Команды для выполнения атаки в Linux:

С использованием RC4 ключа (NT-хэша):

ticketer.py -nthash $krbtgtNThash -domain-sid $domainSID -domain $Domain $RandomUser

С использованием AES ключа:

ticketer.py -aesKey $krbtgtAESkey -domain-sid $DomainSID -domain $Domain $RandomUser

C указанием идентификаторов групп:

ticketer.py -nthash $krbtgtNThash -domain-sid $DomainSID -domain $Domain -user-id $UserID -groups $GroupID1,$GroupID2, ... $RandomUser

Команды для выполнения атаки в Windows:

С использованием RC4 ключа (NT-хэша) в Mimikatz:

kerberos::golden /domain:$Domain /sid:$DomainSID /rc4:$krbtgt_NThash /user:$RandomUser /ptt

С использованием AES128 ключа в Mimikatz:

kerberos::golden /domain:$Domain /sid:$DomainSID /aes128:$krbtgt_aes128_key /user:$RandomUser /ptt

С использованием AES256 ключа в Mimikatz:

kerberos::golden /domain:$Domain /sid:$DomainSID /aes256:$krbtgt_aes256_key /user:$RandomUser /ptt

Заключение

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

К сожалению нельзя объять необъятное. Некоторые важные и актуальные темы, например связанные с делегированием, не были затронуты. Также не описывались атаки, создающие условия для дальнейшего проведения атак на Kerberos. Все это возможно будет рассказано позже.

Ссылки

Общие источники из которых черпал информацию по атакам на Kerberos

• Монументальный труд Eloy Pérez
• Комплексная статья Сергея Ефимова
• “Разбираем атаки на Kerberos с помощью Rubeus”. Части 1 и 2 компании T.Hunter
• Kerberoasting without SPN от Арсения Шароглазова

Полезные блоги для дальнейшего изучения, в том числе отличных от Kerberos, атак на Active Directory:

• Блог Will Schroeder (harmj0y)
• Блог Charlie Bromberg (Shutdown)
• Блог Pixis

Картинки:

• Матрешки взяты отсюда
• Скриншот экрана входа отсюда
• Цербер отсюда