Kerberos: принцип и классы атак (и защита)

Разбираем, как Kerberos выдаёт билеты вместо паролей, почему из-за устройства протокола возникают целые классы атак и как закрыть эти слабости.

Kerberos — протокол сетевой аутентификации, в котором пользователь доказывает свою личность не паролем при каждом обращении, а зашифрованными «билетами», выданными доверенным центром.

В домене Windows пароль по сети почти не передаётся: вместо этого работает Kerberos. Понимание его логики критично для защитника, потому что большинство громких техник перемещения по сети — Kerberoasting, Pass-the-Hash, Golden Ticket — это не «дыры в коде», а следствие того, как устроена сама схема билетов и как с ней обращаются администраторы.

Зачем это знать защитнику

Если вы понимаете, какие криптографические ключи участвуют в выдаче билетов и где они хранятся, вы сразу видите, на чём держится безопасность: на секретности паролей сервисных учёток и ключа служебной учётки KDC. Тогда становится ясно, какие события надо логировать и какие настройки реально снижают риск, а какие — косметика.

Как работает аутентификация по билетам

Упрощённо процесс выглядит так. Есть центр распределения ключей (KDC) на контроллере домена. Он знает пароли всех учёток (в виде хешей-ключей).

Вход. Пользователь шифрует временную метку своим ключом (производным от пароля) и отправляет KDC. KDC расшифровывает её тем же ключом — значит, пароль верный. В ответ выдаётся TGT (ticket-granting ticket) — «пропуск», зашифрованный ключом служебной учётки KDC.
Запрос сервиса. Чтобы обратиться к конкретной службе (файловый сервер, база), пользователь предъявляет TGT и просит сервисный билет. KDC выдаёт билет, зашифрованный ключом той самой службы.
Доступ. Служба расшифровывает билет своим ключом и впускает пользователя, не обращаясь к KDC повторно.

# Концептуальная схема обмена (лаборатория)
Пользователь ──(метка, шифр. ключом пароля)──▶ KDC
KDC          ──(TGT, шифр. ключом KDC)───────▶ Пользователь
Пользователь ──(TGT + запрос службы)─────────▶ KDC
KDC          ──(сервис-билет, шифр. ключом службы)▶ Пользователь
Пользователь ──(сервис-билет)────────────────▶ Служба ✓

Откуда берутся классы атак

Kerberoasting

Любой пользователь домена может запросить сервисный билет для службы, привязанной к учётной записи (через атрибут SPN). Этот билет зашифрован ключом сервисной учётки, то есть фактически её паролем. Атакующий запрашивает такой билет и в офлайне перебирает пароль: если у сервисной учётки слабый пароль, его удаётся подобрать, и атакующий получает её права. Слабость здесь не в протоколе, а в человеческой привычке ставить сервисам простые, годами не меняющиеся пароли.

Pass-the-Hash

Во многих схемах аутентификации Windows для входа достаточно не самого пароля, а его хеша. Если атакующий извлёк хеш из памяти скомпрометированной машины, он может предъявлять его и ходить от имени пользователя, не зная пароля в открытом виде. Корень проблемы — переиспользование одних и тех же привилегированных учёток на множестве машин и хранение их следов в памяти.

Golden Ticket (концептуально)

Если злоумышленник добрался до ключа служебной учётки KDC, он может сам подделывать TGT — то есть выписывать себе пропуска от имени кого угодно. Это уже признак полной компрометации домена; защита здесь — не дать дойти до этого ключа и быть готовым к смене учётных данных KDC при инциденте.

Как это работает под капотом

Вся безопасность Kerberos держится на симметричных ключах, производных от паролей. Билет, который служба «доверяет», надёжен ровно настолько, насколько секретен ключ этой службы. Поэтому два рычага защитника очевидны: делать ключи сервисов сильными и труднодоступными для перебора и оберегать ключ KDC как высшую ценность (Tier 0).

Полезно различать два типа билетов, потому что от этого зависит, что именно мониторить. TGT доказывает, «кто вы», и зашифрован ключом KDC — массовая или аномальная выдача TGT намекает на проблемы с самим центром. Сервисный билет доказывает право на конкретную службу и зашифрован её ключом — именно его выпрашивают при Kerberoasting, поэтому всплеск запросов сервисных билетов к множеству разных служб от одной учётки за короткое время — классический повод для тревоги. Ещё одна деталь: Kerberos чувствителен ко времени. Билеты содержат метку и срок жизни, а узлы должны иметь синхронизированные часы (обычно расхождение допускается в пределах нескольких минут). Это не только техническое требование — ограниченный срок жизни билета сам по себе сужает окно, в которое украденный билет полезен атакующему.

Как защититься

Сильные пароли сервисных учёток. Длинные случайные пароли (25+ символов) делают офлайн-перебор Kerberoasting нерентабельным.
Управляемые сервисные учётки (gMSA). Group Managed Service Accounts автоматически генерируют и ротируют длинный пароль — администратор его даже не видит. Это закрывает Kerberoasting радикально.
Минимизация переиспользования учёток. Привилегированные учётки не должны логиниться куда попало; тогда красть из памяти будет нечего. Здесь напрямую помогает модель уровней из прошлого урока.
Современные алгоритмы шифрования. Отключайте устаревшие слабые типы шифрования билетов — со слабым алгоритмом перебор кратно проще.
Мониторинг. Логируйте массовые запросы сервисных билетов (особенно со слабым шифрованием) и аномальную выдачу TGT — это типичные следы Kerberoasting и подделки билетов.

Извлечение чужих хешей и подделка билетов в системе без разрешения владельца — это неправомерный доступ (ст. 272 УК РФ), а использование соответствующих утилит во вред может попасть под ст. 273. Отрабатывайте техники только в своей лаборатории.

Итоги

Kerberos аутентифицирует пользователя билетами: KDC выдаёт TGT, затем сервисные билеты, зашифрованные ключами служб.
Kerberoasting и Pass-the-Hash — следствие слабых паролей сервисов и переиспользования учёток, а не «багов» протокола.
Безопасность держится на секретности ключей сервисов и особенно ключа KDC (Tier 0).
Защита: сильные пароли сервисов, gMSA с автоматической ротацией, отказ от слабого шифрования, минимизация переиспользования учёток и мониторинг аномальных запросов билетов.