Механика Kerberos: от выдачи TGT до компрометации домена и практические методы защиты
Дисклеймер
Материал предназначен для специалистов по информационной безопасности, системных администраторов и разработчиков. Рассматриваются исключительно технологии и методики — принципы работы, архитектура, способы обнаружения и нейтрализации угроз. Статья носит образовательный характер, не содержит инструкций по созданию или распространению вредоносного ПО и не призывает к нарушению законодательства РФ. Ответственность за применение описанных методов лежит на читателе в рамках действующего законодательства.
Протокол Kerberos управляет аутентификацией в корпоративных сетях через систему билетов и симметричного шифрования. Администраторы часто воспринимают этот механизм как черный ящик, обеспечивающий фоновую работу. На практике именно в логике выдачи TGT и TGS скрываются векторы, позволяющие получить полный контроль над доменом при наличии всего одного слабого пароля сервисной учетной записи. Понимание внутренней механики протокола необходимо для построения эффективной защиты и настройки детектирования аномалий.
Архитектура KDC и структура шифрования билетов
Центр распределения ключей (KDC) в Active Directory разделяется на два логических компонента: сервер аутентификации (AS) и сервер выдачи билетов (TGS). Взаимодействие строится на криптографических билетах, содержащих сессионные ключи и временные метки.
Билет на выдачу билетов (TGT) позволяет клиенту запрашивать доступ к конкретным сетевым ресурсам без повторного ввода пароля. Структура TGT состоит из двух частей. Первая часть зашифрована секретным ключом учетной записи krbtgt. Клиент не обладает возможностью расшифровать этот блок, но обязан передать его при каждом последующем запросе. Вторая часть зашифрована хэшем пароля пользователя. Клиент расшифровывает её, извлекает сессионный ключ и применяет его для шифрования аутентификатора (временной метки).
Сервисный билет (TGS) предоставляет право на подключение к конкретной службе, например, к базе данных SQL или файловому хранилищу. Данный билет шифруется секретным ключом (NTLM-хэшем) целевой сервисной учетной записи.
Трехэтапная аутентификация: разбор сетевого обмена
Процесс входа в доменную учетную запись и получения доступа к ресурсу проходит через три строгих этапа по порту UDP/TCP 88.
На первом этапе клиент отправляет запрос AS-REQ, содержащий имя пользователя и временную метку, зашифрованную хэшем пароля. Центр распределения ключей проверяет метку и возвращает ответ AS-REP. Ответ содержит TGT, зашифрованный ключом krbtgt, и копию сессионного ключа, зашифрованную хэшем пароля пользователя.
На втором этапе клиенту требуется доступ к конкретному сервису. Клиент формирует запрос TGS-REQ, прикладывая полученный ранее TGT и новый аутентификатор, зашифрованный сессионным ключом. Сервер TGS проверяет валидность TGT и возвращает ответ TGS-REP. Этот ответ содержит сервисный билет, зашифрованный хэшем пароля целевой сервисной учетной записи, и новый сессионный ключ для общения с сервисом.
На третьем этапе клиент предъявляет сервисный билет непосредственно целевой службе в запросе AP-REQ. Сервис расшифровывает билет своим хэшем, проверяет временную метку в аутентификаторе и предоставляет доступ. Вся цепочка происходит незаметно для пользователя за доли секунды.
Kerberoasting: извлечение хэшей сервисных учетных записей
Атакующие редко пытаются взломать сам криптографический алгоритм. Они атакуют слабые места в конфигурации и управлении паролями. Атака Kerberoasting нацелена на сервисные учетные записи, имеющие зарегистрированное имя участника службы (SPN).
Любой аутентифицированный пользователь домена может запросить сервисный билет для любого известного SPN, не имея специальных привилегий. Сервер TGS вернет билет, зашифрованный хэшем пароля сервисной учетной записи. Злоумышленник сохраняет этот билет и подбирает пароль в офлайн-режиме. Успех атаки полностью зависит от сложности пароля и используемого алгоритма шифрования. Алгоритмы RC4_HMAC_MD5 ломаются за секунды на современных видеокартах. Стандарты AES256 требуют колоссальных вычислительных мощностей, что делает подбор экономически нецелесообразным.
Сетевые средства защиты и политики блокировки учетных записей не срабатывают, поскольку запрос TGS является легитимной операцией протокола. Злоумышленник перебирает миллиарды комбинаций локально, не вызывая подозрений у систем мониторинга.
Практическое применение и инструменты
Для извлечения билетов используются стандартные системные утилиты или специализированные фреймворки.
Пример использования Impacket для получения билетов всех пользователей с SPN:
python3 GetUserSPNs.py -request -dc-ip 192.168.1.10 domain.local/user:Password123
Пример использования Rubeus для запроса и извлечения билетов в формате, пригодном для Hashcat:
Rubeus.exe kerberoast /outfile:hashes.txt /nowrap
Полученный хэш передается в Hashcat. Для типа шифрования RC4 (etype 23) используется режим 13100:
hashcat -m 13100 hashes.txt rockyou.txt -O
AS-REP Roasting: обход предварительной аутентификации
Атака AS-REP Roasting эксплуатирует учетные записи с отключенной предварительной аутентификацией (флаг DONT_REQ_PREAUTH). Предварительная аутентификация требует от клиента доказать знание пароля еще до получения TGT, предотвращая офлайн-атаки на хэш.
Администраторы иногда отключают эту функцию для совместимости со старыми приложениями или скриптами автоматизации. В таком случае злоумышленник может запросить ответ от сервера аутентификации без знания пароля. Ответ будет содержать часть данных, зашифрованную хэшем пароля целевого пользователя. Подбор происходит локально и не вызывает срабатывания политик блокировки, так как запрос не требует проверки пароля на стороне KDC.
Практическое применение и инструменты
Поиск уязвимых учетных записей и извлечение хэшей выполняется через Impacket:
python3 GetNPUsers.py domain.local/ -usersfile users.txt -format hashcat -outputfile hashes.txt
Для взлома полученного хэша в Hashcat применяется режим 18200:
hashcat -m 18200 hashes.txt rockyou.txt
Подделка билетов: Golden Ticket и Silver Ticket
Получение хэшей паролей открывает путь к созданию поддельных билетов, позволяющих закрепиться в сети и обойти стандартные механизмы сброса паролей.
Золотой билет (Golden Ticket) предоставляет полный контроль над доменом. Для его создания требуется хэш пароля учетной записи krbtgt. Злоумышленники получают этот хэш с помощью атаки DCSync, имитируя запрос репликации от контроллера домена. Создав поддельный TGT, атакующий авторизуется от имени любого пользователя, включая администраторов, и получает доступ к любым ресурсам. Билет остается валидным даже после смены паролей всех пользователей, поскольку сервер проверки подлинности доверяет подписи krbtgt.
Атака DCSync заслуживает отдельного внимания, поскольку она часто предшествует созданию золотых билетов. Механизм репликации контроллеров домена позволяет запросить актуальные хэши паролей. Злоумышленник, обладающий правами синхронизации каталога (например, член группы Domain Admins или Account Operators), отправляет запрос на репликацию, имитируя поведение другого контроллера. Active Directory возвращает запрошенные данные, включая хэш krbtgt.
Серебряный билет (Silver Ticket) работает более точечно. Для его создания нужен хэш пароля конкретной сервисной учетной записи. Злоумышленник формирует поддельный сервисный билет и предъявляет его целевой службе. Сервис проверяет подпись, видит валидный хэш своей учетной записи и предоставляет доступ. Серебряные билеты не обращаются к контроллерам домена, поэтому их сложнее обнаружить средствами мониторинга репликации. Скомпрометировав учетную запись службы SQL Server, атакующий создает поддельный билет для доступа к базе данных, оставаясь невидимым для стандартных средств анализа трафика.
Практическое применение и инструменты
Создание Golden Ticket через Mimikatz требует SID домена, имени домена, SID пользователя и хэша krbtgt:
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... /krbtgt:HASH_KRBTGT /id:500 /ptt
Создание Silver Ticket требует хэша целевого сервиса и его SPN:
kerberos::silver /user:sql_service /domain:domain.local /sid:S-1-5-21-... /target:sql01.domain.local /service:MSSQLSvc /rc4:HASH_SERVICE /ptt
Кража сессий Pass-the-Ticket и защита процесса LSASS
Иногда злоумышленникам не нужно подбирать пароли или подделывать билеты. Они крадут уже существующие сессии.
Процесс локальной службы безопасности (LSASS) хранит в оперативной памяти все текущие билеты Kerberos. Любая программа, запущенная с правами локального администратора, может прочитать память этого процесса. Извлекая TGT или сервисные билеты, атакующий экспортирует их и использует на своей машине. Техника Pass-the-Ticket позволяет перемещаться по сети, выдавая себя за легитимного пользователя, без знания его пароля.
Практическое применение и инструменты
Экспорт билетов из памяти с помощью Rubeus:
Rubeus.exe triage Rubeus.exe dump /luid:0x12345 /nowrap
Импорт билета в текущую сессию:
Rubeus.exe ptt /ticket:doIF...base64string...
Как выстроить защиту от компрометации Kerberos
Защита протокола требует комплексного подхода и регулярного аудита конфигураций.
Базовый уровень защиты начинается с управления паролями. Сервисные учетные записи должны иметь сложные пароли длиной от 25 символов. Принудительное использование алгоритмов шифрования AES вместо RC4 критически необходимо для всех сервисов. В Group Policy Management это настраивается через параметр «Network security: Configure encryption types allowed for Kerberos».
Предварительная аутентификация должна быть включена для всех учетных записей без исключений. Отключение этой функции допустимо только в редких случаях, когда этого требуют специфические устаревшие приложения.
Защита учетной записи krbtgt требует регулярной смены пароля. Пароль нужно менять дважды с интервалом, превышающим время жизни билета (по умолчанию 10 часов), чтобы гарантированно аннулировать старые хэши, которые могли быть скомпрометированы и использованы для создания золотых билетов. Active Directory хранит два предыдущих хэша для обратной совместимости.
Защита процесса LSASS требует включения виртуализации учетных данных (Credential Guard). Эта функция изолирует процессы, работающие с секретами, в защищенную среду на базе виртуализации (VSM). Современные средства защиты конечных точек должны блокировать любые попытки чтения памяти LSASS несанкционированными процессами.
Регулярный аудит SPN помогает выявить забытые сервисные учетные записи. Удаление неиспользуемых SPN сокращает поверхность для атак Kerberoasting.
Внедрение строгих политик паролей часто сталкивается с сопротивлением бизнеса. Сервисные учетные записи используются в скриптах, конфигурационных файлах и планировщиках задач. Смена сложного пароля требует остановки служб и ручного обновления конфигураций на десятках серверов. Инженеры откладывают эту задачу, оставляя уязвимое звено в системе безопасности. Автоматизация управления секретами через специализированные хранилища становится стандартом для корпоративных сред.
Скрипт для аудита уязвимых учетных записей
Следующий PowerShell-скрипт позволяет выявить учетные записи с отключенной предварительной аутентификацией и учетные записи с SPN, подверженные Kerberoasting:
# Поиск учетных записей с отключенной пре-аутентификацией (AS-REP Roasting) Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth | Select-Object Name, SamAccountName # Поиск учетных записей с назначенным SPN (Kerberoasting) Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName | Select-Object Name, SamAccountName, ServicePrincipalName
Настройка мониторинга событий безопасности
Интеграция логов контроллеров домена в SIEM позволяет автоматизировать обнаружение подозрительной активности.
Аналитики должны отслеживать следующие события:
- Event ID 4769 (Запрос билета службы Kerberos). Фильтр по полю Ticket Encryption Type со значением 0x17 (RC4_HMAC_MD5) указывает на использование устаревшего шифрования, характерного для Kerberoasting.
- Event ID 4768 (Запрос билета Kerberos TGT). Поле Pre-Auth Type со значением 0 указывает на попытку аутентификации без предварительной проверки, что является прямым индикатором AS-REP Roasting.
- Event ID 4662 (Выполнена операция с объектом). Мониторинг запросов репликации к объекту krbtgt со стороны нестандартных учетных записей помогает выявить атаку DCSync.
Попробуйте прямо сейчас проверить в своей сети наличие учетных записей с отключенной предварительной аутентификацией. Результаты такого аудита часто вызывают искреннее удивление даже у опытных инженеров.