# Kerberos ## Принципы работы kerberos **Kerberos** - это сетевой протокол аутентификации для распределенных сетей, основан на билетах, предотвращающий передачу паролей в открытом виде. Название протокола происходит от имени трехглавого пса Цербера из греческой мифологии, что символизирует три ключевых аспекта безопасности: AAA - Authentication, Authorization, Accounting. Kerberos широко используется в корпоративных средах, особенно в доменах Windows Active Directory, где он является основным протоколом аутентификации. Он позволяет пользователям получать доступ к сетевым ресурсам без необходимости многократного ввода пароля, обеспечивая при этом высокий уровень безопасности. \[TODO: тут, видимо что-то про SSO] {% hint style="info" %} Настроить авторизацию доменных пользователей на Unix-серверах с помощью Kerberos тоже можно. {% endhint %} ### **Процесс аутентификации в Kerberos** Kerberos работает на основе билетов (tickets), которые выдаются центром распределения ключей (Key Distribution Center, KDC). KDC состоит из двух компонентов: * **Authentication Server (AS):** Отвечает за начальную аутентификацию пользователя и выдачу TGT (Ticket Granting Ticket). * **Ticket Granting Service (TGS):** Отвечает за выдачу сервисных билетов для доступа к конкретным ресурсам. Процесс аутентификации в Kerberos состоит из нескольких этапов: 1. **Запрос TGT (AS-REQ и AS-REP):** * Клиент отправляет запрос на аутентификацию в AS (Authentication Server). * AS проверяет учетные данные клиента и, если они верны, выдает TGT (Ticket Granting Ticket). TGT зашифрован с использованием ключа KDC (хеш пароля krbtgt) и содержит информацию о клиенте и сроке действия билета. * TGT возвращается клиенту, но он не может его расшифровать, так как не знает ключа KDC. {% hint style="info" %} Учетная запись **krbtgt** — это специальная учетная запись в домене, которая используется для генерации и подписи TGT (Ticket Granting Ticket). Ключ этой учетной записи используется для шифрования всех TGT в домене. Если злоумышленник получает доступ к хэшу пароля учетной записи krbtgt, он может создавать поддельные TGT (Golden Tickets), что позволяет ему получать доступ к любым ресурсам в домене. {% endhint %} 2. **Запрос сервисного билета (TGS-REQ и TGS-REP):** * Клиент отправляет TGT в TGS (Ticket Granting Service) вместе с запросом на доступ к конкретному сервису. * TGS проверяет TGT и, если он действителен, выдает сервисный билет (Service Ticket). Сервисный билет зашифрован с использованием ключа целевого сервиса. * Сервисный билет возвращается клиенту. {% hint style="info" %} SPN (**Service Principal Name**) — это уникальный идентификатор, который связывает службу с учетной записью в домене. SPN используется для идентификации служб в Kerberos и имеет следующий формат: ``` <тип службы>/<имя хоста>:<порт>/<дополнительные параметры> ``` Пример SPN для файлового и web-сервера: ``` cifs/fileserver.example.com HTTP/web-server.domain ``` SPN позволяет клиентам находить нужные службы в домене и запрашивать сервисные билеты для доступа к ним. {% endhint %} 3. **Аутентификация на целевом сервисе (AP-REQ и AP-REP):** * Клиент отправляет сервисный билет целевому сервису. * Сервис расшифровывает билет с использованием своего ключа (хеша своего пароля) и проверяет его подлинность. * Если билет действителен, сервис предоставляет доступ клиенту. ## **Атаки на Kerberos** ### **Pass-the-Ticket (PtT)** Атака, при которой злоумышленник перехватывает или крадет TGT (Ticket Granting Ticket) или сервисный билет и использует его для доступа к ресурсам от имени легитимного пользователя. * В Windows TGT (Ticket Granting Ticket) и сервисные билеты активных пользователей хранятся в памяти LSASS * в Linux/Unix — это файлы кэша (например, `/tmp/krb5cc_*`). Используется **klist** или **ccache** для работы с файлами кэша.\ Или Keytab-файлы (например, `/etc/krb5.keytab`), которые содержат ключи для аутентификации служб через Kerberos. Они используются в Linux/Unix системах для автоматической аутентификации без ввода пароля. Атакующий может и использовать файл для генерации сервисных билетов. **Как работает:** * Злоумышленник получает билет (например, с помощью инструментов вроде Mimikatz, ProcDump). * Билет используется для аутентификации на целевом сервисе без знания пароля. Последствия зависят от привилегий пользователя, чей билет был украден. {% hint style="info" %} В целом не является атакой. Просто кража TGT пользователя должна приравниваться к краже пароля пользователя (ровно как и получение NTLM-хеша пользователя) - то есть компрометации пользователя. Существует еще такое понятие как **Overpass The Hash** - возможность получения TGT пользователя при наличии хэша его пароля. {% endhint %} ### **Kerberoasting** Атака, направленная на учетные записи служб (service accounts), которые используют Kerberos для аутентификации. Злоумышленник запрашивает сервисные билеты (TGS) и пытается взломать их офлайн, чтобы получить сервисный пароль учетной записи. **Как работает:** * Злоумышленник запрашивает TGS для учетной записи службы (например, с помощью инструмента Rubeus). * Полученный TGS (зашифрованный хэш пароля) подвергается офлайн-брутфорсу. **Обнаружение:** * Использование слабого шифрования 0x17- RC4 (необязательный артефакт, но хороший индикатор) Успешность атаки зависит от сложности пароля учетной записи службы. ### **AS-REP Roasting** Атака на учетные записи, у которых отключена предварительная аутентификация Kerberos (pre-authentication). Злоумышленник может запросить билет для таких учетных записей и попытаться взломать их офлайн. **Как работает:** * Злоумышленник отправляет AS-REQ без предварительной аутентификации. * KDC возвращает AS-REP, содержащий зашифрованный хэш пароля. * Хэш подвергается офлайн-брутфорсу. **Обнаружение:** * Мониторинг AS-REQ без предварительной аутентификации (Event ID 4768 с `Result Code 0x0` и отсутствием Pre-Auth) * Выявление учетных записей с отключенной предварительной аутентификацией. Последствия зависят от привилегий пользователя, чей билет был украден. Успешность атаки зависит от сложности пароля учетной записи службы. *** ### **Silver Ticket** Атака, при которой злоумышленник создает поддельный сервисный билет (Service Ticket) для конкретного сервиса. Это возможно, если злоумышленник знает пароль или хэш учетной записи службы. Например, может их получить в следствии атаки Kerberoasting. **Как работает:** * Злоумышленник использует хэш пароля службы для создания сервисного билета. * Билет используется для доступа к сервису без взаимодействия с KDC. **Обнаружение:** * Несоответствие SID и имени пользователя (Event ID 4624). * Получение TGS на несуществующих пользователях домена. {% hint style="info" %} Обновление [KB5008380](https://support.microsoft.com/en-gb/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041) добавляет новую информацию о том, кто запросил билет в Privilege Attribute Certificate (PAC), которая записывается в TGT. Это дало возможность прекратить выпуск билетов для несуществующих пользователей. {% endhint %} Позволяет получить доступ к конкретному сервису с правами учетной записи службы или любого доменного пользователя, т.к. позволяет выписывать любые TGS для доступа к этой службе. *** ### **Golden Ticket** Одна из самых опасных атак на Kerberos. Злоумышленник создает поддельный TGT (Ticket Granting Ticket), используя хэш пароля учетной записи **krbtgt**. Это позволяет получить доступ к любому ресурсу в домене. **Как работает:** * Злоумышленник получает хэш пароля учетной записи **krbtgt** (например, с помощью DCSync). * Создается поддельный TGT с неограниченным сроком действия. {% hint style="info" %} **Мониторинг DCSync:** Настройте аудит для обнаружения подозрительных запросов DCSync (Event ID 4662). {% endhint %} **Обнаружение:** * В теории обнаружить Golden Ticket можно мониторингом запросов TGS без предшествующего TGT. Хотя на практике это не тривиально реализовать и такой детект может сильно фолзить. В результате атакующий получает полный контроль над доменом. {% hint style="info" %} В домене Active Directory TGT (Ticket Granting Ticket) могут быть подписаны как **текущим**, так и **предыдущим** паролем учетной записи **krbtgt**. Это сделано для обеспечения отказоустойчивости: если пароль **krbtgt** меняется, старые TGT, выданные с предыдущим паролем, остаются действительными в течение некоторого времени. Если злоумышленник получил хэш пароля **krbtgt** и создал **Golden Ticket**, то даже после смены пароля **krbtgt** Golden Ticket, созданный с использованием старого пароля, останется действительным. Чтобы полностью нейтрализовать такие билеты, необходимо выполнить **двойную смену пароля**. {% endhint %} ### **SamAccountName Spoofing (CVE-2021-42278 и CVE-2021-42287)** Уязвимости, позволяющие злоумышленнику подделать SamAccountName и получить TGS для учетной записи с повышенными привилегиями (например, контроллера домена). Используя этот билет, атакующий может провести атаку DCSync и получить полный контроль над доменом. {% hint style="info" %} Машинные учетные записи с $ на конце, такие же учетные записи домена, как и пользовательские. Они также используют Kerberos для авторизации. {% endhint %} **Как работает:** 1. Злоумышленник создает новую машинную учетную запись в домене: имя совпадает с контроллером домена, но без суффикса $. 2. Запрашивает TGT для этой учетной записи. 3. Удаляет учетную запись, для которой запрошен TGT. 4. Запрашивает TGS для удаленной записи по валидному TGT. 5. Kerberos выписывает TGS на настоящую машинную учетную запись в $ на конце (так как не находит учетную запись без $ на конце). **Обнаружение:** * Создание и модификация машинных учетных записей (Event ID 4742) без $. * Запросы TGT для учетных записей, имя которых совпадает с именами контроллеров домена. Позволяет получить права администратора домена. ### Инструменты Обнаруживать атаки на Kerberos лучше по артефактам конкретных инструментов. Можно поизучать работу следующих: * **Pass-the-Ticket (PtT):** * **Mimikatz:** Извлечение TGT и сервисных билетов из памяти LSASS. * **Rubeus:** Передача и использование билетов (Pass-the-Ticket). * **Kekeo:** Работа с билетами Kerberos, включая их создание и использование. * **Impacket (ticketer.py):** Создание поддельных билетов (Golden Ticket, Silver Ticket). * **Kerberoasting:** * **Rubeus:** Запрос TGS для учетных записей служб и экспорт хэшей. * **Impacket (GetUserSPNs.py):** Запрос TGS и экспорт хэшей для офлайн-брутфорса. * **Invoke-Kerberoast:** PowerShell-скрипт для проведения атаки Kerberoasting. * **AS-REP Roasting:** * **Rubeus:** Запрос AS-REP для учетных записей с отключенной предварительной аутентификацией. * **Kerbrute:** Перебор учетных записей и проведение AS-REP Roasting. * **Silver Ticket, Golden Ticket, DCSync:** * **Mimikatz:** Создание Golden Ticket с использованием хэша **krbtgt**. * **Impacket (ticketer.py):** Генерация поддельных TGT. * **Rubeus:** Эксплуатация уязвимостей для повышения привилегий. ## **Ключевые события Windows для мониторинга** {% embed url="" %} * **4768 (TGT Request):** Аномальные запросы (например, без предварительной аутентификации и с `Result Code 0x0`). Старые версии mimikatz оставляли очень специфичные артефакты в имени и домене пользователя при запросе билетов. {% embed url="" %} * **4769 (TGS Request):** Большое количество запросов для одной учетной записи (Kerberoasting). Несовпадение SID и имени доменного пользователя. Или запрос билета на несуществующего пользователя. {% embed url="" %} * **4771 (Kerberos Pre-Auth Failed):** Подозрительные попытки входа. {% embed url="" %} * **4770 (TGS Renewal):** Отслеживайте аномальное количество запросов на обновление. TGS можно обновлять без повторного ввода пароля (до 7 дней по умолчанию). Это удобно для пользователей, но продлевает жизнь украденных билетов. Уменьшите максимальное время жизни TGT через GPO (например, до 10 часов). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://vasilisa-l.gitbook.io/blue-team-cookbook/a-d/kerberos.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.