Атака Kerberoasting в Active Directory: механика, обнаружение и защита

Атака Kerberoasting эксплуатирует стандартный механизм запроса сервисных билетов в Active Directory. Злоумышленник, находясь внутри сети как обычный пользователь домена, запрашивает тикет для учетной записи с SPN и расшифровывает его офлайн. Защита требует отключения устаревших шифров, внедрения управляемых сервисных учетных записей и постоянного мониторинга событий 4769.

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

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

Словарь терминов: что нужно понимать перед чтением

Active Directory (AD) — служба каталогов Microsoft, хранящая информацию обо всех объектах корпоративной сети: пользователях, компьютерах, группах, политиках. Является центром управления идентификацией в большинстве Windows-инфраструктур.

Kerberos — протокол сетевой аутентификации. Работает на основе «билетов» (tickets), которые выдает доверенный центр — контроллер домена. Клиент доказывает свою личность через билет, а не через передачу пароля по сети.

KDC (Key Distribution Center) — служба на контроллере домена, выдающая билеты Kerberos. Состоит из двух компонентов: AS (Authentication Service) и TGS (Ticket Granting Service).

TGT (Ticket Granting Ticket) — «главный» билет, который пользователь получает при входе в систему. Используется для запроса сервисных билетов без повторного ввода пароля.

TGS (Ticket Granting Service ticket / Service Ticket) — сервисный билет, который KDC выдает для доступа к конкретному ресурсу. Зашифрован ключом, производным от пароля сервисной учетной записи.

SPN (Service Principal Name) — уникальное имя, связывающее учетную запись с конкретным сетевым сервисом. Пример: MSSQLSvc/sql01.corp.local:1433. Без SPN Kerberos не знает, какой учетной записью обслуживается данный сервис.

Kerberoasting — атака, при которой любой аутентифицированный пользователь домена запрашивает сервисные билеты TGS для учетных записей с SPN, а затем пытается взломать эти билеты офлайн, подбирая пароль.

RC4_HMAC_MD5 — устаревший алгоритм симметричного шифрования. Ключом служит NT-хеш пароля. Низкая стойкость к брутфорсу делает его главной целью Kerberoasting.

AES256_HMAC_SHA1 — современный алгоритм шифрования Kerberos. Использует 256-битный ключ, производный от пароля через PBKDF2. Взлом в разы сложнее RC4.

GMSA (Group Managed Service Account) — управляемая сервисная учетная запись. AD автоматически генерирует и ротирует 120-символьный случайный пароль. Kerberoasting против GMSA практически бессмысленен.

msDS-SupportedEncryptionTypes — атрибут объекта AD, определяющий поддерживаемые типы шифрования Kerberos. Если не задан или равен 0, контроллер домена использует настройки домена по умолчанию, которые часто включают RC4.

Когда пользователь входит в домен, он сначала получает от контроллера домена (KDC) специальный билет Ticket Granting Ticket. Этот билет не даёт доступ к сервисам напрямую, а лишь подтверждает, что пользователь уже аутентифицирован и может запрашивать доступ к другим ресурсам. Далее, когда пользователь пытается подключиться, например, к SQL Server, он не обращается напрямую к серверу с логином и паролем. Вместо этого он отправляет запрос в KDC с просьбой выдать билет к конкретному сервису, и в этом запросе указывает именно SPN, например MSSQLSvc/sql01.corp.local:1433.

Контроллер домена ищет указанный SPN в Active Directory и определяет, к какой учетной записи он привязан. Это может быть либо учетная запись компьютера, либо отдельная сервисная учетная запись. Найдя её, KDC использует связанный с ней секрет (пароль или его производный ключ), чтобы зашифровать сервисный билет. Таким образом создаётся Service Ticket, который предназначен строго для конкретного сервиса.

Далее билет передаётся клиенту, и клиент уже обращается к самому сервису, например к SQL Server, передавая ему полученный билет. Сервис, в свою очередь, пытается расшифровать этот билет, используя свой собственный ключ — то есть тот же самый пароль учетной записи, к которой привязан SPN. Если билет успешно расшифровывается, это означает, что он был выдан доверенным KDC и что клиент действительно аутентифицирован. В этом случае доступ предоставляется без передачи пароля по сети.

SPN определяет, каким именно ключом будет зашифрован билет. Если SPN отсутствует в Active Directory, контроллер домена просто не сможет понять, какой учетной записью обслуживается сервис, и не сможет выдать корректный билет Kerberos. В результате либо возникнет ошибка, либо система попытается перейти на NTLM, если это возможно. Если же SPN настроен неправильно и указывает на неверную учетную запись, ситуация становится ещё более сложной: билет будет зашифрован “чужим” ключом, и сервис не сможет его расшифровать. Что приводит к типичным ошибкам Kerberos, невозможность проверки подлинности или сообщения о некорректном имени принципала.

Как развивается атака: типичный сценарий

Злоумышленник уже находится внутри сети. Права минимальны: обычная учетная запись пользователя домена. Но этого достаточно — права на чтение атрибутов объектов AD есть у каждого аутентифицированного пользователя по умолчанию.

Шаг 1: Разведка. Скрипт сканирует AD и находит объекты с заполненным атрибутом servicePrincipalName. Это легитимный LDAP-запрос, неотличимый от штатных операций управления.

Шаг 2: Запрос TGS-билета. Для каждой найденной учетной записи атакующий запрашивает сервисный билет через стандартный механизм Kerberos. Контроллер домена выдает его без лишних вопросов — запрос синтаксически корректен.

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

Шаг 4: Офлайн-взлом. Перебор происходит на мощном оборудовании вне целевой сети. Сетевые системы защиты не участвуют — подбор полностью локален. Только факт запроса билета фиксируется в логах. Время подбора: от нескольких минут (слабый пароль + RC4 + GPU) до нескольких месяцев (сложный пароль + AES256).

Шаг 5: Использование. Пароль получен. Если сервисная учетная запись входит в привилегированные группы — атакующий получает административный доступ к части или всей инфраструктуре.

Как проверить наличие SPN в Active Directory

Поиск уязвимых учетных записей начинается с аудита текущей конфигурации. Главная цель Kerberoasting — пользовательские учетные записи с SPN: именно их пароли задает человек, и именно они часто слабы или давно не менялись.

Важное уточнение: компьютерные учетные записи тоже имеют SPN (регистрируются автоматически при вступлении в домен), но их пароли — случайные строки длиной 120+ символов, сменяемые каждые 30 дней. Взлом таких паролей практически нереален. Реальная угроза исходит от пользовательских сервисных учетных записей.

# Поиск уязвимых пользовательских учетных записей с SPN
Get-ADUser -Filter {servicePrincipalName -ne "$null"} `
    -Properties servicePrincipalName, PasswordLastSet, MemberOf |
    Select-Object Name, servicePrincipalName, PasswordLastSet, MemberOf |
    Sort-Object PasswordLastSet

Вывод содержит критически важную информацию: имя учетной записи, сервисное имя и — особенно важно — дату последней смены пароля. Если PasswordLastSet показывает трехлетнюю давность, это первоочередная цель.

Для полного охвата стоит проверить и компьютерные учетные записи (хотя практического риска они не несут):

# Все объекты с SPN, включая компьютеры — для полноты аудита
Get-ADObject -Filter {servicePrincipalName -ne "$null"} `
    -Properties servicePrincipalName, objectClass |
    Select-Object Name, objectClass, servicePrincipalName

Опасная ситуация — когда пользовательская сервисная учетная запись входит в группу Domain Admins. Это создает критический риск: компрометация пароля дает полный контроль над инфраструктурой.

# Поиск сервисных учетных записей с высокими привилегиями
Get-ADUser -Filter {servicePrincipalName -ne "$null"} `
    -Properties servicePrincipalName, MemberOf |
    Where-Object {
        $_.MemberOf -match "Domain Admins|Enterprise Admins|Schema Admins"
    } |
    Select-Object Name, servicePrincipalName, MemberOf

Часто в списке попадаются объекты, которых там быть не должно: тестовые учетные записи разработчиков, SPN-записи давно удаленных приложений, забытые технические аккаунты. Очистка таких записей — первый и самый дешевый шаг снижения поверхности атаки.

Почему шифрование RC4 повышает риски

Протокол Kerberos поддерживает несколько типов шифрования. Старые стандарты сохраняются для обратной совместимости. Алгоритм RC4_HMAC_MD5 считается устаревшим: стойкость ключа недостаточна для современных вычислительных мощностей. Видеокарты уровня NVIDIA RTX 4090 перебирают сотни миллионов комбинаций в секунду.

Настройка типа шифрования хранится в атрибуте msDS-SupportedEncryptionTypes. Если атрибут не задан или равен 0, контроллер домена ориентируется на реестровый параметр DefaultDomainSupportedEncTypes — и нередко выбирает RC4 для совместимости. В Windows Server 2019+ поведение по умолчанию изменилось в сторону AES, но в реальных доменах, мигрировавших с более старых версий, RC4 часто остается активным.

Сравнение алгоритмов по практической стойкости:

Тип шифрования	Битовая маска	Стойкость к офлайн-взлому	Комментарий
RC4_HMAC_MD5	0x4	Низкая	Ключ = NT-хеш пароля. GPU взламывает за часы
AES128_HMAC_SHA1	0x8	Средняя	В 10–100 раз медленнее RC4 при взломе
AES256_HMAC_SHA1	0x10	Высокая	Рекомендуется для всех сервисных аккаунтов
Не задан (0)	—	Зависит от домена	Опасно: может включать RC4

Проверить текущий тип шифрования конкретной учетной записи:

Get-ADUser -Identity "ServiceAccount" -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

Значение 24 (0x18 = 0x8 + 0x10) означает поддержку только AES128 и AES256. Значение 4 означает только RC4. Пустое значение или 0 — нужно проверять реестр DC.

Принудительное включение только AES для конкретной учетной записи:

# Правильная команда: только Set-ADUser для атрибута шифрования
Set-ADUser -Identity "ServiceAccount" `
    -Replace @{"msDS-SupportedEncryptionTypes" = 24}

Распространенная ошибка: использование Set-ADAccountControl перед этой командой — лишнее действие. Set-ADAccountControl управляет флагами UserAccountControl (истечение пароля, преаутентификация и т.д.), но не типами шифрования Kerberos. Для атрибута msDS-SupportedEncryptionTypes достаточно только Set-ADUser или Set-ADComputer.

Применение изменения требует тестирования. Сначала — на одной учетной записи, затем мониторинг ошибок аутентификации в течение нескольких часов. Ошибки Kerberos с кодом KDC_ERR_ETYPE_NOSUPP (Event ID 14 в журнале System на DC, источник Microsoft-Windows-Kerberos-Key-Distribution-Center) указывают на несовместимость клиента. Обратите внимание: это событие из журнала System, не Security.

Какие инструменты используют для получения тикетов

Существует набор утилит для работы с билетами Kerberos. Большинство открыты и доступны публично. Использование легально в рамках авторизованного тестирования на проникновение. Злоумышленники применяют те же методы — разница только в наличии письменного разрешения.

Rubeus

Современный инструмент на C#, работающий без зависимости от стандартных библиотек Microsoft. Умеет запрашивать тикеты, передавать хеши, выполнять AS-REP Roasting.

Rubeus.exe kerberoast /outputfile:hashes.txt /format:hashcat

Флаг /format:hashcat сразу выдает хеши в формате, совместимом с Hashcat (режим 13100). Дополнительная конвертация не нужна.

Для таргетированного запроса только RC4-тикетов (более быстрый взлом):

Rubeus.exe kerberoast /rc4opsec /outputfile:hashes_rc4.txt

Impacket: GetUserSPNs.py

Набор Python-скриптов, запускаемых с Linux-машины. Удобен для интеграции в пентест-пайплайны.

python3 GetUserSPNs.py -request -dc-ip 192.168.1.10 DOMAIN/user:password

Вывод содержит хеши сразу в формате Hashcat или John the Ripper — выбирается флагом -outputfile и форматом файла.

Взлом через Hashcat

# Режим 13100 — Kerberos 5 TGS-REP RC4
hashcat -m 13100 hashes.txt wordlist.txt -r rules/best64.rule

# Режим 19700 — Kerberos 5 TGS-REP AES128
hashcat -m 19700 hashes.txt wordlist.txt

# Режим 19800 — Kerberos 5 TGS-REP AES256
hashcat -m 19800 hashes.txt wordlist.txt

AES-тикеты взламываются значительно медленнее RC4 — именно поэтому отключение RC4 так важно.

BloodHound

Инструмент визуализации связей в AD. Граф показывает пути эскалации привилегий: какие сервисные учетные записи имеют доступ к критическим ресурсам, могут ли они использоваться для получения прав Domain Admin через цепочку ACL.

Признаки компрометации через инструменты

Один пользователь не запрашивает TGS-билеты для SQL, Exchange, IIS и десяти других сервисов одновременно. Если такая активность зафиксирована — это сигнал. Штатные приложения запрашивают тикеты ровно для тех сервисов, с которыми работают, и делают это предсказуемо.

Как настроить групповые политики для защиты

Централизованное управление упрощает внедрение стандартов шифрования на весь домен.

Путь в GPMC: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Configure encryption types allowed for Kerberos

Рекомендуемая конфигурация: снять галочки с DES и RC4, оставить только AES128 и AES256. Это принудит все компьютеры в области действия объекта групповой политики использовать только современные алгоритмы.

Поэтапное внедрение

Резкое отключение RC4 на всем домене без подготовки приведет к ошибкам аутентификации. Правильный порядок:

Аудит текущих настроек. Выгрузить список учетных записей и их msDS-SupportedEncryptionTypes. Выявить системы с Windows Server 2012 и старше — они могут не поддерживать AES по умолчанию.
Обновление клиентских библиотек и ОС. Windows XP и Server 2003 используют RC4 принудительно; их наличие в сети создает неустранимую брешь, пока они не заменены.
Применение GPO в режиме аудита. Включить расширенный аудит событий Kerberos: фиксировать попытки использования RC4 без блокировки.
Мониторинг событий в течение 1–2 недель. Анализировать Event ID 14 (System лог) на DC. Выявить проблемные системы.
Переключение GPO в режим принудительного применения. Блокировать RC4.
Мониторинг ошибок аутентификации после переключения. Исключения потребуют индивидуальной обработки.
Регулярная проверка соответствия — автоматизированные скрипты каждые 2 недели.

Групповые управляемые сервисные учетные записи (GMSA)

GMSA — оптимальное решение проблемы паролей сервисных учетных записей. Система генерирует случайный пароль длиной 120+ символов и автоматически ротирует его каждые 30 дней. Пароль недоступен для чтения даже владельцу учетной записи. Kerberoasting против GMSA практически бессмысленен: даже получив хеш, злоумышленник не сможет взломать 120-символьный случайный пароль в разумное время.

Создание GMSA:

# Шаг 1: Убедиться, что корень службы KDS настроен
Add-KdsRootKey -EffectiveImmediately

# Шаг 2: Создать GMSA (правильный командлет — New-ADServiceAccount)
New-ADServiceAccount `
    -Name "GMSA_SQLService" `
    -DNSHostName "sql01.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQL01$" `
    -ServicePrincipalNames "MSSQLSvc/sql01.corp.local:1433"

# Шаг 3: Установить учетную запись на целевом сервере
Install-ADServiceAccount -Identity "GMSA_SQLService"

# Шаг 4: Проверить корректность установки
Test-ADServiceAccount -Identity "GMSA_SQLService"

Критическое замечание: командлет Add-ADServiceAccount не создает GMSA — он устанавливает уже существующую учетную запись на конкретный хост (аналог Install-ADServiceAccount). Для создания используется New-ADServiceAccount. Путаница между этими командлетами — одна из самых частых ошибок при настройке GMSA.

Привязка службы к GMSA в Windows Services: в свойствах службы указывается имя учетной записи в формате DOMAIN\GMSA_SQLService$ (знак доллара обязателен) без пароля — система получает credentials автоматически.

Где искать следы атаки в логах событий

Контроллер домена регистрирует события аутентификации в журнале Security. Правильная фильтрация и корреляция позволяют выявить Kerberoasting на ранней стадии.

Event ID 4769 — запрос сервисного билета

Ключевое событие для обнаружения Kerberoasting.

Поле	Значение	Интерпретация
Service Name	Имя учетной записи	Для кого запрошен тикет
Ticket Encryption Type	0x17	RC4 — подозрительно
Ticket Encryption Type	0x12	AES256 — норма
Failure Code	0x0	Успешный запрос
Client Address	IP клиента	Источник запроса

Event ID 4768 — запрос TGT (AS-REQ)

Связан с AS-REP Roasting — смежной атакой для учетных записей без предварительной аутентификации.

Поле	Значение	Интерпретация
Pre-Authentication Type	0	Уязвимость: preauth отключен
Pre-Authentication Type	2	Норма

Признаки Kerberoasting в логах

Паттерны, требующие немедленного внимания:

Множественные события 4769 от одного клиента за короткий промежуток времени (несколько TGS-запросов за секунды или минуты)
Запросы для разных сервисных учетных записей от одного источника
Тип шифрования 0x17 (RC4) для учетных записей, где это не ожидается
Запросы вне рабочих часов
Запросы от рабочих станций, а не от серверов
Отсутствие последующего успешного входа в соответствующие сервисы (тикет запрошен, но не использован)

PowerShell для быстрого анализа логов

# Поиск подозрительных TGS-запросов с RC4 за последние 24 часа
$StartTime = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4769
    StartTime = $StartTime
} | Where-Object {
    $_.Properties[5].Value -eq '0x17'  # RC4
} | Select-Object TimeCreated,
    @{N='AccountName'; E={$_.Properties[0].Value}},
    @{N='ServiceName'; E={$_.Properties[2].Value}},
    @{N='ClientIP';    E={$_.Properties[6].Value}} |
    Group-Object ClientIP | Sort-Object Count -Descending

Группировка по IP-адресу сразу показывает, с какого хоста идет массовый сбор тикетов.

Экспорт и архивирование логов

# Экспорт журнала безопасности для ретроспективного анализа
wevtutil epl Security "C:\Logs\Security_$(Get-Date -Format 'yyyyMMdd').evtx"

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

Защита целостности логов

Очистка журнала событий фиксируется как Event ID 1102 (Security). Это явный признак сокрытия следов. Для защиты от локального удаления логи должны централизованно отправляться на SIEM или syslog-сервер в режиме реального времени: локальное удаление не затрагивает уже переданные записи.

Корреляционные правила для SIEM

Пример правила для обнаружения Kerberoasting на основе событий 4769:

ПРАВИЛО: Подозрительный массовый сбор TGS-тикетов

УСЛОВИЕ:
  Событие 4769
  И TicketEncryptionType = 0x17 (RC4)
  И ServiceName НЕ заканчивается на "$" (исключить компьютеры)
  И более 5 таких событий от одного ClientAddress за 60 секунд

ДЕЙСТВИЕ:
  Высокий приоритет
  Уведомить аналитика SOC
  Запросить изоляцию рабочей станции-источника

ИСКЛЮЧЕНИЯ:
  ClientAddress в белом списке серверов мониторинга
  ServiceName из доверенного списка сервисов резервного копирования

Реагирование на обнаруженную атаку

При подтверждении Kerberoasting немедленные действия:

1. Изоляция источника. Ограничить сетевой доступ рабочей станции-источника. Не выключать — сохранить образ памяти для криминалистического анализа.

2. Сброс паролей скомпрометированных учетных записей. Тикет Kerberos имеет ограниченное время жизни (по умолчанию 10 часов), но атакующий мог уже получить пароль и использовать его. Смена пароля аннулирует все существующие TGS-тикеты, выданные на основе старого ключа.

3. Уведомление владельцев сервисов. Приложения, использующие скомпрометированную учетную запись, временно потеряют доступ. Координация с разработчиками и эксплуатацией минимизирует простой.

4. Анализ использования. Проверить логи доступа к ресурсам, привязанным к скомпрометированной учетной записи. Установить, были ли реально использованы полученные права, и оценить возможный ущерб.

5. Перевод учетных записей на GMSA. Долгосрочная мера: исключить человеческие пароли из уравнения сервисных учетных записей.

Активная проверка защиты: имитация атаки

Регулярное самотестирование подтверждает эффективность настроек. Запуск проводится только с письменного разрешения и с предварительным уведомлением команды безопасности.

# Внутренний аудит: список учетных записей, уязвимых для Kerberoasting
Import-Module ActiveDirectory

$VulnerableAccounts = Get-ADUser -Filter {
    servicePrincipalName -ne "$null"
} -Properties servicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes |
    Select-Object Name, servicePrincipalName, PasswordLastSet,
        @{N='EncryptionTypes'; E={
            switch ($_.msDS-SupportedEncryptionTypes) {
                4       { "RC4 only — CRITICAL" }
                8       { "AES128 only — OK" }
                24      { "AES128+AES256 — OK" }
                0       { "Not set — check domain default" }
                $null   { "Not set — check domain default" }
                default { "Mixed: $_" }
            }
        }},
        @{N='PasswordAgeDays'; E={
            (New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days
        }} |
    Sort-Object PasswordAgeDays -Descending

$VulnerableAccounts | Where-Object { $_.EncryptionTypes -match "RC4|Not set" } |
    Format-Table -AutoSize

Если в выводе есть учетные записи с RC4 и паролем, которому более 90 дней — это приоритетные задачи на исправление.

Сводная таблица мер защиты

Мера	Сложность	Эффект	Первоочередность
Перевод сервисных аккаунтов на GMSA	Средняя	Устраняет угрозу полностью	Высокая
Отключение RC4 в GPO	Средняя	Резко усложняет взлом	Высокая
Установить `msDS-SupportedEncryptionTypes = 24`	Низкая	Форсирует AES для конкретных аккаунтов	Высокая
Удаление устаревших SPN	Низкая	Снижает поверхность атаки	Средняя
Мониторинг Event ID 4769 (RC4)	Низкая	Обнаружение атаки	Высокая
Включение SIEM-правил корреляции	Средняя	Автоматическое обнаружение	Средняя
Регулярная ротация паролей сервисных аккаунтов	Низкая	Ограничивает окно использования	Средняя
Принцип наименьших привилегий для сервисных аккаунтов	Средняя	Ограничивает ущерб от компрометации	Высокая
Сегментация сети	Высокая	Ограничивает горизонтальное движение	Средняя
Аудит членства в привилегированных группах	Низкая	Выявляет критические конфигурации	Высокая

Итоговая модель угрозы

Kerberoasting — это не эксплойт уязвимости в классическом смысле. Это злоупотребление легитимным механизмом протокола. Контроллер домена не делает ничего неправильного, выдавая тикет. Проблема возникает на стыке трёх факторов:

Слабые пароли — пользовательские сервисные учетные записи с паролями, поддающимися перебору
Устаревшее шифрование — RC4 позволяет взламывать тикеты в разы быстрее, чем AES256
Избыточные привилегии — сервисные учетные записи с правами выше необходимых

Устранение любого из трёх факторов значительно усложняет или делает невозможным успешную атаку. Устранение всех трёх — строгий минимум для современной AD-инфраструктуры.

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