Атака Kerberoasting использует стандартный механизм запроса сервисных билетов в Active Directory. Злоумышленник, действуя под учетной записью обычного пользователя домена, запрашивает сервисный билет (TGS) для учетной записи с SPN и впоследствии может провести подбор пароля в офлайн-режиме. Защита требует выключения устаревших алгоритмов шифрования, внедрения управляемых сервисных учетных записей (GMSA) и непрерывного мониторинга событий 4769 в логах безопасности.
В корпоративных сетях часто можно встретить ситуации, когда инфраструктура работает годами без существенных изменений. Сервисы настраиваются, учетные записи регистрируются и со временем забываются. Однако устаревшие и невостребованные службы и учетные записи нередко становятся точкой входа для атакующих внутри периметра.
Протокол Kerberos разработан для безопасной аутентификации в распределенных сетях. В реализации Windows любой пользователь домена может без ограничений запросить Kerberos-билет (TGS) для любого объекта с заполненным атрибутом servicePrincipalName. Такая механика не требует эскалированных прав и позволяет получить хеш пароля, зашифрованный сервисной учетной записью, — материал для последующего офлайн-взлома.
Словарь терминов
Active Directory (AD): служба каталогов Microsoft, хранящая сведения обо всех объектах корпоративной сети, включая пользователей, компьютеры, группы и политики. Является центром управления идентификацией для Windows-инфраструктур.
Kerberos: протокол аутентификации, реализующий схему с билетами, которые выдает контроллер домена. Аутентификация проходит без передачи пароля по сети.
KDC (Key Distribution Center): компонент на контроллере домена, выдающий Kerberos-билеты путем взаимодействия сервисов AS (Authentication Service) и TGS (Ticket Granting Service).
TGT (Ticket Granting Ticket): основной билет, выдаваемый пользователю при входе. Служит для получения сервисных билетов без повторной аутентификации.
TGS (Service Ticket): билет на доступ к конкретному сервису. Шифруется ключом сервисной учетной записи.
SPN (Service Principal Name): уникальное имя, привязывающее учетную запись к конкретному сетевому сервису. Например: MSSQLSvc/sql01.corp.local:1433. Kerberos не сможет обработать запрос к сервису без корректного SPN.
Kerberoasting: атака, при которой пользователь домена получает Kerberos-билеты сервисных учетных записей с SPN, затем осуществляет подбор пароля в офлайн-режиме.
RC4_HMAC_MD5: устаревший алгоритм симметричного шифрования. Использует NT-хеш пароля как ключ. Отличается уязвимостью к перебору.
AES256_HMAC_SHA1: современный алгоритм шифрования с использованием 256-битных ключей, получаемых через PBKDF2. Крайне устойчив к атаке перебором.
GMSA (Group Managed Service Account): управляемая сервисная учетная запись с автоматически генерируемым и ротируемым длинным паролем. Kerberoasting для GMSA практически невозможен из-за сложности пароля.
msDS-SupportedEncryptionTypes: атрибут объекта AD, указывающий поддерживаемые алгоритмы шифрования для Kerberos. Если не задан, используется политика домена по умолчанию, которая может включать RC4.
Аутентификация Kerberos начинается с получения пользователем TGT у контроллера домена. Для доступа к сервису (например, SQL Server), клиент отправляет запрос в KDC с указанием нужного SPN. KDC находит в AD учетную запись с соответствующим SPN, шифрует сервисный билет её ключом и возвращает билет клиенту. Дальнейшее взаимодействие с сервисом происходит по этому билету: сервис расшифровывает билет своим ключом и, в случае успеха, предоставляет доступ без передачи пароля по сети.
При отсутствии SPN в AD KDC не сможет определить целевую учетную запись и выдаст ошибку, либо система может переключиться на устаревший протокол NTLM. Неправильная или устаревшая регистрация SPN приводит к ошибкам аутентификации и рискам безопасности.
Сценарий атаки Kerberoasting
Злоумышленник оказывается внутри корпоративной сети с минимальными правами рядового пользователя домена. Но права на запрос атрибутов объектов AD (в т.ч. SPN) есть у любого аутентифицированного пользователя по умолчанию.
- Шаг 1: Разведка. Сканирование объектов Active Directory на наличие учетных записей с заполненным SPN (легитимный LDAP-запрос).
- Шаг 2: Запрос TGS-билета. Запрос Kerberos-билета на каждый найденный SPN через стандартный TGS-запрос.
- Шаг 3: Извлечение хеша. Сохранение зашифрованной части билета (TGS), связанной с паролем сервисного аккаунта.
- Шаг 4: Офлайн-взлом. Перебор пароля офлайн при помощи мощного оборудования (GPU), вне зоны действия сетевых средств защиты.
- Шаг 5: Использование пароля. Компрометация сервисной учетной записи, часто с привилегиями администратора.
Проверка наличия SPN в Active Directory
Анализ конфигурации начинается с поиска учетных записей пользователей с SPN. Их пароли часто задаются вручную, редко меняются и обычно слабее автоматически сгенерированных.
Важно: Компьютерные учетные записи также имеют SPN и длинные случайные пароли, сменяемые автоматически каждые 30 дней. Риск взлома минимален. Главную угрозу представляют пользовательские сервисные учетные записи.
# Поиск пользовательских учетных записей с SPN
Get-ADUser -Filter {servicePrincipalName -ne "$null"} `
-Properties servicePrincipalName, PasswordLastSet, MemberOf |
Select-Object Name, servicePrincipalName, PasswordLastSet, MemberOf |
Sort-Object PasswordLastSet
Результат содержит имена, SPN и дату смены пароля. Особое внимание стоит уделить учетным записям, у которых пароль давно не изменялся.
Для комплексного аудита дополнительно проверяются компьютерные учетные записи:
# Все объекты с 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
В ходе аудита часто обнаруживаются устаревшие или тестовые учетные записи. Их удаление значительно снижает поверхность атаки.
Устаревшее шифрование RC4: почему это риск
Kerberos поддерживает несколько алгоритмов шифрования, но RC4_HMAC_MD5 признан устаревшим из-за низкой криптостойкости, особенно перед современными мощностями GPU. Брутфорс проверенных словарей с использованием RC4 занимает считанные часы.
Значение атрибута msDS-SupportedEncryptionTypes определяет поддерживаемые алгоритмы для каждой учетной записи. Если он пуст или равен 0, используется политика по умолчанию, где RC4 обычно включен для совместимости. В новых Windows Server (2019+) по умолчанию выбран AES, но в доменах с историей миграции RC4 может оставаться активным.
| Тип шифрования | Битовая маска | Стойкость к офлайн-взлому | Комментарий |
|---|---|---|---|
| RC4_HMAC_MD5 | 0x4 | Низкая | Рост скорости перебора на GPU |
| AES128_HMAC_SHA1 | 0x8 | Средняя | В 10–100 раз сложнее взлом |
| AES256_HMAC_SHA1 | 0x10 | Высокая | Рекомендуемый вариант |
| Не задан (0) | — | Зависит от домена | Может включать RC4 |
Проверка атрибута шифрования для конкретной учетной записи:
Get-ADUser -Identity "ServiceAccount" -Properties msDS-SupportedEncryptionTypes |
Select-Object Name, msDS-SupportedEncryptionTypes
Значения: 24 — только AES; 4 — только RC4; 0 или пусто — потребуется проверка политики домена.
Включить только AES для сервисного аккаунта:
# Обновление алгоритмов шифрования
Set-ADUser -Identity "ServiceAccount" `
-Replace @{"msDS-SupportedEncryptionTypes" = 24}
Замечание: для обновления
msDS-SupportedEncryptionTypesиспользуйте толькоSet-ADUserилиSet-ADComputer.Set-ADAccountControlне подходит для этой задачи.
Перед массовым внедрением — тестирование на одной учетной записи. Оценивать логи на ошибки Kerberos с кодом KDC_ERR_ETYPE_NOSUPP (Event ID 14 в журнале System).
Инструменты для получения тикетов и взлома паролей
Для Kerberoasting применяются специализированные open-source-инструменты. В большинстве случаев их используют как пентестеры, так и злоумышленники.
Rubeus
Современный инструмент на C#. Позволяет запрашивать Kerberos-билеты, экспортировать их для перебора и выполнять различные атаки на Kerberos.
Rubeus.exe kerberoast /outputfile:hashes.txt /format:hashcatДля запроса билетов только с RC4-шифрованием:
Rubeus.exe kerberoast /rc4opsec /outputfile:hashes_rc4.txtImpacket: GetUserSPNs.py
Набор Python-утилит, работающих с Linux. Скрипт GetUserSPNs.py позволяет получать Kerberos-билеты целевых учетных записей.
python3 GetUserSPNs.py -request -dc-ip 192.168.1.10 DOMAIN/user:passwordРезультаты сразу можно использовать для перебора в Hashcat/John the Ripper.
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
BloodHound
Инструмент для анализа и визуализации связей и путей эскалации привилегий в AD. Позволяет строить графы доступа сервисных учетных записей и критических точек инфраструктуры.
Признаки компрометации через инструменты
Массированные запросы TGS-билетов к разным сервисам одномоментно с одной рабочей станции — подозрительны. Корреляция аномалий в поведении сервисных аккаунтов помогает выявить атаку на ранней стадии.
Настройка групповых политик для защиты
Для управления используемыми алгоритмами шифрования Kerberos рекомендуется применять групповые политики:
Путь: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Configure encryption types allowed for Kerberos
Отключение DES и RC4, включение только AES128 и AES256 гарантирует отказ от устаревших схем шифрования на всем домене.
Этапы внедрения
- Аудит: Выгрузить список аккаунтов и проверить их
msDS-SupportedEncryptionTypes. Выявить устаревшие системы (Windows Server 2012 и старше). - Обновление клиентов: Исключить использование Windows XP/2003 и старых драйверов, не поддерживающих AES.
- Пилотный запуск GPO с аудитом: Включить расширенный аудит Kerberos, отслеживая попытки обращения к RC4.
- Мониторинг: Анализировать ошибки аутентификации и выявлять несовместимые системы.
- Перевод в enforcing: Запретить RC4.
- Реакция на инциденты: Локализовать и обновлять проблемные системы.
- Регулярный аудит: Автоматизированные проверки раз в две недели.
GMSA (Group Managed Service Accounts)
GMSA обеспечивает автоматическую смену длинных (120+) случайных паролей сервисных учетных записей — идеальное средство защиты от Kerberoasting.
Создание и внедрение GMSA:
# Настройка корня службы KDS
Add-KdsRootKey -EffectiveImmediately
# Создание учетной записи GMSA
New-ADServiceAccount `
-Name "GMSA_SQLService" `
-DNSHostName "sql01.corp.local" `
-PrincipalsAllowedToRetrieveManagedPassword "SQL01$" `
-ServicePrincipalNames "MSSQLSvc/sql01.corp.local:1433"
# Установка на цели
Install-ADServiceAccount -Identity "GMSA_SQLService"
# Проверка
Test-ADServiceAccount -Identity "GMSA_SQLService"
Важный момент:
Add-ADServiceAccountне создает GMSA! ИспользуйтеNew-ADServiceAccountдля создания.
Привязка осуществляется в свойствах службы: DOMAINGMSA_SQLService$ (с символом доллара), без ввода пароля вручную.
Анализ логов событий на Kerberoasting
Все попытки преступного Kerberoasting можно выявить через анализ событий в журнале Security на контроллере домена.
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.
| Pre-Authentication Type | Значение | Интерпретация |
|---|---|---|
| 0 | Отключено | Уязвимость |
| 2 | Включено | Норма |
Типичные признаки Kerberoasting
- Серии событий 4769 от одного клиента за малый промежуток времени
- Запросы TGS для разных сервисных аккаунтов одним источником
- RC4 (0x17) для учетных записей, где это не ожидается
- Активность вне рабочих часов
- Запросы кидаются не с серверов, а с рабочих станций
- Отсутствуют успешные аутентификации по запрошенным билетам
Быстрая аналитика на PowerShell
# Поиск массовых RC4-запросов за сутки
$StartTime = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4769
StartTime = $StartTime
} | Where-Object {
$_.Properties[5].Value -eq '0x17'
} | 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
Выявляются источники массового сбора тикетов.
Экспорт и архивирование логов
# Экспорт журнала безопасности
wevtutil epl Security "C:LogsSecurity_$(Get-Date -Format 'yyyyMMdd').evtx"
Архивы хранятся минимум 90 дней для ретроспективной аналитики.
Контроль целостности логов
Очистка журнала (Event ID 1102) — повод для расследования. Чтобы исключить подмену и удаление, логи должны отправляться централизованно (SIEM, syslog) в реальном времени.
Корреляционные правила для SIEM
Правила корреляции — необходимая мера для автоматического реагирования:
ПРАВИЛО: Массовый сбор Kerberos-билетов (4769, шифрование RC4)
УСЛОВИЕ:
Event ID = 4769
TicketEncryptionType = 0x17 (RC4)
ServiceName НЕ заканчивается на "$"
>5 событий от одного ClientAddress за 1 минуту
ДЕЙСТВИЕ:
Уведомление аналитика
Изоляция источника
ИСКЛЮЧЕНИЯ:
Серверы мониторинга и легальные сервисы
Реагирование на Kerberoasting
- Изоляция источника: Блокировка сетевого доступа рабочей станции, forensic сохранение образа памяти.
- Сброс паролей сервисных аккаунтов: Все компрометированные тикеты аннулируются после смены пароля.
- Оповещение владельцев сервисов: Минимизировать простой легальных ресурсов.
- Анализ журналов: Проверка последующего использования учетных записей и оценка потенциального ущерба.
- Переход на GMSA: Устранить человеческий фактор паролей сервисных учетных записей.
Имитация атаки для проверки защиты
Рекомендовано проводить аудит уязвимых сервисных аккаунтов с письменного разрешения.
# Выявление уязвимых учетных записей
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-правила корреляции | Средняя | Автоматизация реагирования | Средний |
| Ротация паролей сервисных аккаунтов | Низкая | Ограниченный срок действия пароля | Средний |
| Минимальные привилегии для сервисов | Средняя | Ограничение ущерба | Высокий |
| Сегментация сети | Высокая | Сужение возможности lateral movement | Средний |
| Аудит членства в привилегированных группах | Низкая | Контроль критичных конфигураций | Высокий |
Модель угроз: причины успеха атаки
Kerberoasting, это злоупотребление стандартным поведением Kerberos, а не результат эксплуатации уязвимости. Проблема возникает в результате сочетания следующих факторов:
- Слабые пароли сервисных учетных записей, часто подвергающиеся перебору.
- Устаревшее (RC4) шифрование, что делает перебор легким и быстрым.
- Избыточные привилегии сервисных учетных записей (например, членство в Domain Admins).
Исключение хотя бы одного из этих факторов существенно снижает риск. Комплексное решение всех — минимальный стандарт безопасности для современных AD-доменов.
Осознанное понимание механики Kerberos обеспечивает не формальное соответствие чеклисту, а действительно эффективную защиту инфраструктуры.