«Многие думают, что Kerberos — это неприступный бастион Windows-домена, но на практике всё держится на одном хеше пароля и множестве конфигурационных ошибок. Это не простая теория, а череда реальных, воспроизводимых уязвимостей, которые эксплуатируются каждый день.»
Уязвимости протоколов аутентификации в Active Directory
В основе безопасности корпоративных сетей на базе Windows лежат два протокола: Kerberos для проверки подлинности и LDAP для доступа к данным каталога. Их компрометация ведет к полному контролю над инфраструктурой.
Kerberos: как работает и где слабо
Kerberos — протокол аутентификации, определённый в RFC 4120, который используется в Windows и множестве других операционных систем и приложений. Детальная информация о Kerberos доступна на сайте консорциума: kerberos.org.
Взаимодействие в протоколе строится между тремя сторонами:
- Клиент (пользователь или служба).
- Центр распределения ключей (KDC), который в Active Directory работает на контроллере домена. Включает в себя Сервер аутентификации (AS) и Сервер выдачи тикетов (TGS).
- Целевой сервер, ресурс, к которому нужен доступ.
Процесс аутентификации
Аутентификация происходит в несколько шагов. Клиент не передаёт пароль по сети напрямую.
- Запрос TGT: Клиент шифрует метку времени своим паролем и отправляет её AS. AS проверяет данные и, если они верны, возвращает клиенту Билет на получение тикетов (TGT) и сессионный ключ. TGT зашифрован секретным ключом службы KRBTGT, известным только KDC.
- Запрос сервисного тикета: Чтобы получить доступ к конкретному серверу (например, файловому), клиент отправляет TGS свой TGT и запрос на доступ к этому серверу. TGS расшифровывает TGT ключом KRBTGT, проверяет его, и выдаёт клиенту сервисный тикет, зашифрованный уже паролем целевого сервера.
- Доступ к ресурсу: Клиент отправляет этот сервисный тикет целевому серверу. Сервер расшифровывает его своим паролем и предоставляет доступ.
Эта модель обеспечивает взаимную аутентификацию и не требует хранения паролей на серверах приложений. Однако её безопасность зависит от сохранности нескольких критически важных секретов.
LDAP: каталог и его уязвимости
Active Directory использует Lightweight Directory Access Protocol (LDAP) как протокол доступа к данным каталога. Реализация LDAP в Windows поддерживает аутентификацию Kerberos.
- Directory Information Tree (DIT): Данные в каталоге организованы в иерархическую структуру — инвертированное дерево.
- Distinguished Name (DN): Уникальный полный путь к объекту в этом дереве. Пример:
CN=Иван Петров,OU=ОтделИТ,DC=company,DC=local.
Сам по себе LDAP — это протокол запросов. Уязвимости возникают при его использовании: слабые методы привязки (binding), отсутствие подписи (LDAP signing) и защищённого канала (LDAPS), что открывает путь к атакам «человек посередине» и перехвату учетных данных.
Golden Ticket: поддельный пропуск на все этажи
Если Kerberos — это охраняемый пропускной пункт, то хеш пароля учетной записи KRBTGT — это печать и бланк для пропусков. Получив его, злоумышленник может штамповать пропуска для кого угодно и куда угодно.
Golden Ticket — это самоподписанный TGT. Для его создания нужен хеш пароля учетной записи KRBTGT, который хранится на всех контроллерах домена и никогда не меняется по умолчанию. Получить его можно, скомпрометировав контроллер домена или извлекая из памяти системы с помощью инструментов вроде Mimikatz.
Механизм атаки
- Компрометация системы в домене с правами локального администратора.
- Извлечение из памяти LSASS или из базы данных NTDS.dit хеша пароля учётной записи KRBTGT.
- Создание поддельного TGT с произвольным именем пользователя, SID домена и, что критично, членством в любых группах (например, Domain Admins). Срок жизни такого тикета также задаётся атакующим (часто устанавливается на 10 лет).
- Инъекция этого тикета в собственную сессию Kerberos. После этого система атакующего может получать сервисные тикеты и получать доступ к любым ресурсам домена от имени сфабрикованного пользователя.
Обнаружение сложно, потому что Golden Ticket валиден криптографически. KDC не может отличить его от настоящего, так как он зашифрован правильным ключом KRBTGT. Защита сводится к строгой охране контроллеров домена и регулярной (дважды) смене пароля KRBTGT.
Инструментарий: Mimikatz и не только
Создание Golden Ticket стало рутинной операцией благодаря инструментам. Mimikatz — самый известный, но существуют и другие фреймворки, включающие подобные модули. Работа часто ведётся из памяти, без записи файлов на диск.
Silver Ticket: ключ от конкретной двери
В отличие от универсального Golden Ticket, Silver Ticket — это поддельный сервисный тикет для конкретной службы на конкретном сервере. Для его создания нужен не хеш KRBTGT, а хеш пароля компьютерной учётной записи целевого сервера (оканчивается на $), который также можно извлечь.
Что нужно для создания Silver Ticket
- Хеш пароля (NTLM или AES) учётной записи целевого сервера.
- SID домена.
- Имя домена (FQDN).
- Имя целевой службы (SPN — Service Principal Name).
Примеры служб для атаки
| Служба (SPN) | Цель атаки |
|---|---|
| CIFS | Доступ к файловым ресурсам (общим папкам) сервера. |
| HOST | Выполнение команд через планировщик задач (schtasks.exe) или WMI. |
| HTTP | Доступ к веб-сервисам, например, веб-интерфейсам управления. |
| MSSQLSvc | Аутентификация в Microsoft SQL Server. |
Silver Ticket опасен тем, что для его проверки не требуется обращение к KDC. Сервер проверяет его самостоятельно, своим ключом. Обнаружить подделку на стороне KDC или по журналам событий домена невозможно.
Неограниченное делегирование: доверенный, но опасный механизм
Kerberos delegation позволяет службе (например, веб-серверу) повторно использовать тикет пользователя для доступа от его имени к другой службе (например, к базе данных). При неограниченном делегировании службе передаётся TGT пользователя, что позволяет этой службе запрашивать сервисные тикеты от его имени к любым другим ресурсам в домене.
Если злоумышленник скомпрометирует сервер с настроенным неограниченным делегированием, он может перехватить TGT высокопривилегированных пользователей, которые аутентифицируются на этом сервере, и использовать их для дальнейшего перемещения по сети.
По умолчанию эта настройка отключена. Риск возникает при её некорректном включении для недостаточно защищённых серверов.
Kerberoasting: офлайн-подбор паролей служб
Kerberoasting — это не атака на криптографию Kerberos, а эксплуатация слабой человеческой составляющей: паролей сервисных учётных записей.
Любой аутентифицированный пользователь домена может запросить сервисный тикет для любой службы. Часть этого тикета (сервисная часть) зашифрована паролем учётной записи, к которой привязана служба. Если это обычная пользовательская учётная запись, используемая как сервисная (а так часто и бывает), её пароль может быть слабым.
Атакующий запрашивает такие тикеты, извлекает зашифрованные данные и пытается взломать пароль методом офлайн-подбора. Атака почти не оставляет следов в сетевом трафике и требует минимальных исходных привилегий.
Меры защиты от Kerberoasting
- Использование Managed Service Accounts (gMSA) — групповых управляемых учётных записей с длинными автоматически меняемыми паролями.
- Назначение сервисным учётным записям сложных паролей длиной от 25 символов, устойчивых к перебору.
- Включение аудита событий Kerberos (события с ID 4769 — запрос сервисного тикета) и настройка SIEM на оповещения о большом количестве запросов TGS с одного аккаунта или для многих разных служб.
- Применение только типов шифрования AES для Kerberos, что усложняет офлайн-подбор по сравнению с устаревшим RC4.
Ключевые выводы для защиты
Безопасность Kerberos — это не только криптография, но и управление секретами, и конфигурация.
- KRBTGT — ключ от королевства. Его хеш нужно охранять как зеницу ока. Регулярная (раз в 6-12 месяцев) двойная смена его пароля — обязательная практика.
- Пароли компьютерных учётных записей тоже важны. Компрометация сервера может дать хеш для Silver Ticket, поэтому важно сегментировать сеть и защищать критические активы.
- Сервисные учётные записи — слабое звено. Переход на gMSA и строгая политика паролей сводят риск Kerberoasting к минимуму.
- Делегирование — инструмент для избранных. Следует использовать строгое, ограниченное делегирование (Constrained Delegation) и полностью отказаться от неограниченного, если это возможно.
- Обнаружение требует глубокого аудита. Нужно мониторить не только сетевые аномалии, но и события Kerberos (4769, 4624, 4672) на контроллерах домена, искать инъекции тикетов в память и подозрительную активность сервисных аккаунтов.
Понимание этих атак — первый шаг к построению эффективной обороны, где технические меры подкрепляются строгими политиками управления учётными данными.